Re-ranking

ベクトル検索で上位20件の文書を取得しても、本当に質問に関連するのは数件だけ、ということがよくあります。最初の検索は「広く網を投げる」段階であり、そこから精度を高める仕上げが必要です。リランキング（Re-ranking）とは、検索で取得した文書をより精密なモデルで再評価し、関連度の高い順に並べ替える手法です。

なぜリランキングが必要なのか

最初の検索段階（ファーストステージ）で使われるベクトル検索やBM25は、高速に大量の候補を絞り込むことに最適化されています。しかし、クエリと文書を個別にベクトル化するバイエンコーダー方式では、両者の細かなニュアンスの対応関係を捉えきれません。たとえば「Pythonでのエラーハンドリング」という質問に対して、Pythonの一般的な概要記事が上位に来てしまうことがあります。

クロスエンコーダーの仕組み

リランキングではクロスエンコーダーと呼ばれるモデルが使われます。バイエンコーダーがクエリと文書を別々にベクトル化するのに対し、クロスエンコーダーはクエリと文書を1つのペアとして同時に入力し、関連度スコアを直接出力します。両者の単語レベルの対応関係を細かく分析できるため、精度はバイエンコーダーを大きく上回ります。Cohere Rerank、Jina Reranker、BGE Rerankなどが代表的なモデルです。

パイプラインでの位置づけ

リランキングはRAGパイプラインの中で「セカンドステージ」に位置づけられます。一般的な流れは、まず検索で候補を50〜100件取得し、リランカーで再評価して上位5〜10件に絞り、それをLLMのコンテキストとして渡します。この2段階のアプローチにより、検索の速度と精度を両立できます。

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

クロスエンコーダーは精度が高い反面、各候補をクエリとペアで処理するため、候補数に比例して推論コストとレイテンシが増加します。100件の候補をリランキングすれば100回の推論が必要です。そのため、ファーストステージで候補数をある程度絞っておくことが重要です。また、API型のリランカー（Cohere Rerankなど）は1リクエストあたりの課金となるため、検索頻度が高いシステムではコスト設計も考慮が必要です。リランキングは精度への貢献が大きいため、RAGの品質改善で最初に検討すべき手法の1つです。