RAGを作ったのに「検索の精度がいまいち」——そんなときに効くのがリランキング(reranking/再ランク付け)だ。埋め込み(ベクトル)検索でざっくり集めた候補を、もう一段関連度で並べ替えて上位だけ残す。これだけでRAGの回答品質が大きく変わる、検索精度の"最後のひと押し"だ。

本記事では、リランキングとは何か・なぜ必要か・2段階検索の仕組み・なぜ正確なのか(bi-encoderとcross-encoder)・モデルと実装までを初心者向けに整理する。

RERANKING · 広く取得 → 賢く並べ替え

2段階で「本当に関連する」を上に

— 速い検索で集め、正確な採点で絞る

STEP 1 ・ 取得

埋め込み検索

速く・広く候補を集める(例:100件)。再現率を重視。

STEP 2 ・ 並べ替え

リランカー

関連度で採点し上位だけ残す(例:5件)。精度を重視。

1. リランキングとは

リランキングとは、一度集めた検索結果を、クエリ(質問)との関連度であらためて採点し、順位を付け直す処理だ。RAGでは、まず埋め込み検索で関連しそうな文書を大量に取得する。だがその順位は"だいたい近い順"でしかない。そこにリランカー(reranker)という専用モデルを足し、本当に関連の深いものを上位へ押し上げる。

イメージは「一次選考と最終面接」だ。一次選考(埋め込み検索)は応募者を素早くふるいにかけ、多めに通す。最終面接(リランカー)は一人ひとりをじっくり見て、本命を上位に並べる。速さの一次選考+正確さの最終面接——この2段構えが肝だ。

💡 ひとことで:リランキング=「検索結果の並べ替えで精度を上げる第2段階」。埋め込み検索の"取りこぼし防止"の後に、"本命を上に"を担う。

2. なぜ必要?埋め込み検索の限界

埋め込み検索は速くて便利だが、弱点がある。クエリと文書を別々にベクトル化して比べるため、両者の細かな関係までは見ていない。"なんとなく近い"は得意だが、"本当にこの質問に答えているか"の見極めは粗いのだ。

その結果、上位に「キーワードは近いが的外れ」な文書が混じる。RAGでは取得した上位の文書をそのままAIに渡すので、並び順が悪いと回答の質が直接落ちる。ここでリランカーが、関連度をきちんと測り直して順位を整える。研究でも、リランキングの追加でRAGの精度が大きく改善する(ある報告では約40%向上)とされる(※報告値)。

さらに、キーワード検索とベクトル検索を組み合わせるハイブリッド検索にリランキングを重ねるのが、2026年の実用RAGの定番構成だ。「広く・多様に集めて、最後にリランカーで関連度順に整える」——この流れが精度を底上げする。

3. 仕組み:2段階検索

リランキングは「2段階検索(two-stage retrieval)」として組み込む。原則は「広く取得して、賢く絞る」だ。

① 埋め込み検索で広く取得約100件
速く大量に候補を集める(再現率=取りこぼさない)
↓ リランカーで採点
② リランカーで上位に絞る上位5件
関連度で並べ替え(精度=本当に効くものだけ)
↓ 上位だけ渡す
③ LLMに渡して回答生成
厳選した文脈で回答

ポイントは役割分担だ。全文書をリランカーで採点するのは遅すぎて非現実的。だから速い埋め込み検索でまず候補を絞り(例:100件)、その少数だけをリランカーが精査する。これなら速さと精度を両立できる。これはコンテキストエンジニアリングの「最小で最も効く情報を渡す」とも一致する。

4. なぜリランカーは正確なのか

埋め込みとリランカーは、内部の作りが違う。ここが精度差の理由だ。

bi-encoder(埋め込み)

別々に見て、後で比べる

クエリと文書を個別にベクトル化してから距離を測る。事前計算できて速いが、両者の相互作用は見ない(近似的)。

cross-encoder(リランカー)

一緒に見て、直接採点

クエリと文書を一緒にモデルへ入れ、関連度スコア(0〜1)を直接出す。相互作用まで見るので正確。ただし重い。

たとえるなら、bi-encoderは「2本のレポートを別々に要約してから見比べる」のに対し、cross-encoderは「2本を並べて読み込んで関係を判断する」。後者のほうが正確なのは当然だが、その分すべての文書には掛けられない。だから速いbi-encoderで集め、正確なcross-encoderで絞るという2段構えが理にかなう。

5. モデルと実装

リランカーはゼロから作らなくてよい。専用のモデル・APIが揃っている。

API型(手軽)

Cohere Rerank、Voyage、Jina Reranker など。既存の検索の上に載せるだけで使える。APIを呼ぶだけ。

オープンソース型

BGE reranker、mixedbread、FlashRank(軽量)など。無料で自前運用でき、コスト・プライバシー重視向け。

LLMで採点(RankLLM等)

LLM自身に「どれが関連するか」を採点させる方式。柔軟だがコストは高め。

実装は驚くほど簡単だ。既存のRAG(ベクトル検索)「取得件数を多め(例:50〜100)にし、その結果をリランカーに通して上位5件に絞る」——この1工程を足すだけ。効果はAI評価(Evals)で測りながら、取得件数や絞り込み数を調整するとよい。

※モデル名・数値は各種ガイド・研究の引用(2026年6月時点)。効果はデータや設定で変動するため、実際に測って調整するのが確実。

まとめ

リランキングを3点に整理する。

  • 正体:検索結果を関連度で採点し直し、本命を上位へ並べ替える第2段階。RAG精度の"最後のひと押し"。
  • 仕組み:速い埋め込み検索で広く取得 → 正確なリランカーで上位に絞る2段階検索。「広く取って賢く絞る」。
  • 違い:埋め込み(bi-encoder)は別々に見て速い、リランカー(cross-encoder)は一緒に見て正確。役割を分けて両立。

RAGの精度に悩んだら、まずはリランカーを1つ足してみよう。既存の検索に載せるだけで、体感が変わることが多い。あわせてエンベディングRAGの実装も読むと、検索の全体像がつかめる。

FAQ

Q. 埋め込み検索だけではダメ?

A. 用途によっては十分ですが、精度が物足りないときにリランキングが効きます。埋め込みは速く広く集めるのが得意な一方、関連度の見極めは粗め。リランカーを足すと、本当に関連する文書が上位に来やすくなります。

Q. 遅くならない?

A. リランカーは重い処理ですが、全文書ではなく埋め込み検索で絞った少数(例:50〜100件)だけに掛けるので、実用的な速度に収まります。取得件数を増やしすぎないのがコツです。

Q. リランカーと埋め込みモデルは別物?

A. 別物です。埋め込みモデル(bi-encoder)は検索用にベクトルを作り、リランカー(cross-encoder)は2つを一緒に見て関連度を採点します。役割が違うので、両方を組み合わせて使います。

Q. 何件取得して何件に絞ればいい?

A. 目安は「取得50〜100件 → 上位3〜10件」ですが、最適値はデータ次第です。AI評価(Evals)で精度を測りながら、件数を増減して調整しましょう。多く取りすぎると遅く、少なすぎると取りこぼします。