リランキング(Reranker)でRAGの検索精度を上げる｜retrieve->rerankの二段構成

RAGの精度が伸び悩んだとき、埋め込みモデルを差し替えたりチャンク分割を見直したりする前に、もう一段だけ効く工夫があります。それがリランキング(reranking)です。ベクトル検索で候補を多めに拾っておき、より重い別のモデルで関連度を測り直して上位を絞る。この二段構成(retrieve->rerank)は、既存のパイプラインをほとんど壊さずに検索の質を底上げできることが多く、RAG改善の定番手として広く使われています。この記事では、なぜ二段にするのか、Cross-Encoderとbi-encoderの違い、コストとレイテンシのトレードオフ、そして効果を測る評価指標までを、実務で判断できる粒度で整理します。

なぜ検索を二段にするのか#

ベクトル検索は非常に高速です。あらかじめ全文書を埋め込みベクトルにしておき、質問のベクトルと近いものを近似最近傍探索で引く仕組みなので、大規模なコーパスからでも一瞬で候補を返せます。ただし速さと引き換えに、粗さがあります。文書と質問をそれぞれ独立に一本のベクトルへ圧縮してから比較するため、圧縮の過程で細部の情報が失われ、「なんとなく近い」候補は拾えても「本当に質問に答えている」候補を確実に一位へ持ってくるとは限りません。

かといって、取得件数(top_k)を増やして候補を大量にLLMへ渡せばよいわけでもありません。関係の薄い断片まで一緒に詰め込むと、モデルが余計な情報に引っ張られて回答がぶれます。Pineconeの解説でも、コンテキストに入れるトークンを増やすほどLLMの想起(recall)は劣化しやすいと指摘されています。つまり、検索の再現率を上げたい要求と、LLMに渡す量は絞りたい要求が、正面からぶつかります。

この矛盾を解くのが二段構成です。第一段では再現率を優先して候補を多めに拾い(取りこぼしを減らす)、第二段でその候補集合だけを精密に測り直して、本当に関連する少数へ絞り込む。速い検索で網を広げ、重い検索で選り分ける、という分業です。

bi-encoderとCross-Encoderの違い#

二段構成を理解する鍵は、埋め込みモデル(bi-encoder)とリランカー(Cross-Encoder)の構造の違いです。

bi-encoderは、質問と文書を別々にモデルへ通し、それぞれを独立したベクトルへ変換します。文書側のベクトルは事前に計算してインデックスに貯めておけるため、検索時は質問だけをベクトル化して近いものを引けば済みます。これが速さの理由です。反面、質問と文書が互いを一切見ないまま別々に圧縮されるので、両者の細かな噛み合わせは評価しきれません。

Cross-Encoderは、質問と文書のペアを一つの入力として同時にモデルへ通し、両者に注意(attention)を張り渡したうえで、そのペアがどれだけ関連するかを一つのスコアとして出力します。質問と文書を突き合わせて読むぶん精度は高くなりますが、事前計算ができません。質問が来てからペアごとに毎回モデルを走らせる必要があるため、全文書に対してこれをやると到底間に合いません。だからこそ、第一段で候補を数十件〜百件程度に絞ってから、その範囲にだけCross-Encoderをかけるのです。

リランカーの種類#

リランカーと一口に言っても、実現方法はいくつかあります。実務でよく検討されるのは次の3系統です。

専用のCross-Encoderリランカー#

リランキングに特化して学習された、比較的軽量なモデルです。オープンモデルではBAAIのbge-rerankerシリーズが広く使われており、Hugging FaceやGitHubで商用利用可能なライセンスで公開されています。同シリーズにはベース・ラージといったサイズ違いや、多言語対応の後継モデルが用意されており、モデルによってライセンスは異なるため利用前に各モデルカードで確認してください。自前でホストできるため、外部APIにデータを出せない環境や、リクエスト単価を抑えたい場合の選択肢になります。GPUがあれば数十〜百件程度の再スコアリングは実用的な速度で回せることが多いですが、必要リソースはモデルサイズと候補数に依存します。

商用のリランキングAPI#

APIとしてリランキングを提供するサービスもあります。代表例のCohere Rerankは、質問と候補テキストの配列を送ると、関連度スコア付きで並べ替えた結果を返すエンドポイントです。公式ドキュメントによると、2025年後半に公開されたRerank 4.0では、品質重視のproと低レイテンシ・高スループット重視のfastの2種類が用意され、英語・非英語の多言語やJSONなど半構造化データに対応し、32kトークンのコンテキスト長をうたっています。自前でモデルを運用せずに導入できる手軽さが利点ですが、外部へテキストを送る点と従量課金は考慮が要ります。

LLMリランク#

汎用のLLMそのものにリランクを任せる方法もあります。候補群を提示し、「質問に最も関連する順に並べ替えて」あるいは「各候補の関連度を採点して」とプロンプトで指示するやり方です。専用モデルを用意せずに始められ、関連度の理由まで出させられる柔軟さがありますが、候補ごとにトークンを消費するためコストとレイテンシは重くなりがちで、出力の安定性(順序の再現性やフォーマット崩れ)にも注意が必要です。

どれくらい候補を拾い、どこまで絞るか#

二段構成では「第一段で何件拾い(retrieve)、第二段で何件に絞る(rerank後のtop_n)」かを設計します。ここに唯一の正解はありませんが、考え方の軸はあります。

第一段の取得件数は、再現率とリランクコストのトレードオフです。多く拾うほど正解を候補に含められる確率は上がりますが、そのぶんCross-Encoderが処理するペアが増え、レイテンシと費用が線形に近く膨らみます。一般的な解説では、数十件から百件程度を第一段で拾い、リランク後に数件へ絞る、といったレンジがよく例示されます。Pineconeの記事では、取得25件をリランクして上位3件に絞る例が示されています。ただしこれらは説明用の一例であり、最適値はデータ・埋め込みモデル・質問の傾向で動きます。

第二段でLLMへ渡す件数は、回答に必要な文脈量と、ノイズ・トークンコストの兼ね合いで決めます。絞りすぎると根拠が欠け、渡しすぎると前段でリランクした意味が薄れます。

ハイブリッド検索・チャンク分割との関係#

リランキングは単独の技ではなく、検索パイプラインの他の要素と組み合わせて効きます。

第一段の再現率を上げる定番がハイブリッド検索です。ベクトル検索(意味の近さ)とBM25などのキーワード検索(語の一致)を併用し、型番・固有名詞・略語のように埋め込みが取りこぼしやすい語も拾えるようにします。第一段で網を広げておくほど、リランカーが選り分けられる正解の母数が増えるため、ハイブリッド検索とリランキングは相性が良い組み合わせです。

チャンク分割も土台として効きます。一つのチャンクに複数の話題が混ざっていると、リランカーでもスコアが割れて評価しづらくなります。意味のまとまりで適切に区切れているほど、リランカーは関連する断片を素直に高く評価できます。逆に言えば、分割が雑なままリランカーだけ足しても、伸びしろは限られます。検索側の改善は積み重ねで効くと考えるのが現実的です。

コストとレイテンシのトレードオフ#

リランキングの導入判断で最も重要なのが、精度の向上と引き換えに払うコストとレイテンシです。

Cross-Encoderは質問が来てから候補ごとに推論を走らせるため、第一段のベクトル検索に比べて明確に遅く、重い処理です。追加される遅延は、候補数・モデルサイズ・実行環境(自前GPUか外部APIか)で変わります。候補を増やすほど、また大きいモデルを使うほど、レイテンシと費用は増えます。商用APIならリクエスト課金が、自前ホストならGPUの確保・運用コストが乗ります。LLMリランクはさらにトークン課金の影響を受けます。

だからこそ、効果を測らずに常時入れっぱなしにするのは得策ではありません。リランキングで得られる精度向上が、増えたレイテンシ・コストに見合うかは用途しだいです。ミリ秒単位の応答が求められるオートコンプリートのような場面と、多少待っても正確さを優先したいナレッジ検索とでは、答えは変わります。

効果をどう測るか(評価指標)#

リランキングは「並べ替え」の質を上げる処理なので、順位を評価できる指標で測るのが筋です。実務でよく使われるのは次の3つです。

• Hit Rate(命中率): 上位k件の中に正解が1件でも入っているかを見る、最も直感的な指標。まず正解を候補に拾えているかを確認する用途に向きます。
• MRR(Mean Reciprocal Rank): 最初の正解が何位に出たかを、順位の逆数で評価します。正解を上位に押し上げられているかを測るのに向き、正解が主に1件のケースで見やすい指標です。
• nDCG(normalized Discounted Cumulative Gain): 複数の正解や関連度の段階(強く関連・やや関連など)を扱え、上位ほど重く配点します。関連度に濃淡がある検索の質を総合的に測るのに向きます。

やり方はシンプルです。想定質問と正解箇所の対応表(評価セット)を用意し、リランキングあり・なしで同じ指標を並べて比較します。第一段だけの順位と、リランク後の順位で指標がどれだけ動いたかを見れば、リランカーの寄与を切り分けられます。

導入の進め方#

リランカーの対応言語・コンテキスト長・料金・モデル名は各社の更新で変わります。Cohereなどの商用APIやbge-rerankerなどのオープンモデルは、実装前に公式ドキュメント・モデルカードで現行の仕様を確認してください。この記事の数値例は説明用の目安で、最適値は構成依存です。

向かない・効きにくい場面#

リランキングは強力ですが万能ではありません。次のような場面では、入れても効きにくい、あるいは割に合わないことがあります。

低レイテンシが最優先の用途では、Cross-Encoderの追加遅延が許容できないことがあります。リアルタイム性の高い入力補完や、応答速度が体験を左右する対話では、精度向上より速さを取る判断もあり得ます。

候補がもともと少ない場合も効果は限定的です。第一段が数件しか返さない、あるいは対象文書が小規模で並べ替える余地が乏しいなら、リランクの伸びしろは小さくなります。

第一段の検索が的外れなときは、リランカーでは立て直せません。前述のとおり、正解が候補に入っていなければ並べ替えても意味がありません。この場合は埋め込みモデルの見直し、ハイブリッド検索の導入、チャンク分割の改善など、第一段の再現率を上げる施策が先です。

文書全体を集計・網羅するタイプの質問(該当する規程をすべて列挙する、条件に合う件数を数える等)も、上位数件を精密に並べ替えるリランキングの守備範囲外です。これは検索の精度問題ではなく、別の仕組みで補う領域です。

よくある質問#

まとめ#

リランキングは、既存のRAGに一段足すだけで検索の質を底上げしやすい、費用対効果の見えやすい改善策です。ただしCross-Encoderは重く、効果は構成に依存して変動します。だからこそ「入れて満足」ではなく、Hit Rate・MRR・nDCGで測り、レイテンシとコストと並べて判断する姿勢が欠かせません。RAG全体の設計や、第一段を支える埋め込み・チャンク分割とあわせて押さえると、どこを直せば効くのかの見通しが良くなります。