RAGリランキングは、初期検索（ベクトル検索やBM25）で取得した候補チャンクを、Cross-EncoderやColBERT等のより精密なモデルで再スコアリングし、上位に並べ替えることで検索精度を大幅に向上させる手法である。
リランキング（Re-ranking）は、RAGパイプラインのRetrieval段階において、初期検索で取得した候補チャンク群を、より高精度なモデルで再評価し、関連性の高い順に並べ替える処理である。検索の2段階パイプライン（Bi-Encoder → Cross-Encoder）として知られるこのアプローチは、検索精度とレイテンシのトレードオフを最適化するために設計されている。
初期検索（First-stage Retrieval）では、ベクトル検索やBM25などの高速な手法でTop-K（通常20〜100件）の候補を広く取得する。この段階では速度を優先するため、精度には限界がある。リランキング（Second-stage Retrieval）では、取得した候補を1件ずつ精密に評価し、最終的にTop-N（通常3〜10件）に絞り込む。この2段階アプローチにより、大規模コーパスからの検索でも高い精度を維持できる。
初期検索の手法にはそれぞれ固有の限界がある。
| 初期検索手法 | 限界 |
|---|---|
| ベクトル検索（Bi-Encoder） | クエリとドキュメントを独立にエンコードするため、細かい相互作用を捉えられない |
| BM25（キーワード検索） | 語彙の一致に依存し、同義語や言い換えに弱い |
| ハイブリッド検索 | 2つのスコアのマージ比率が固定で、クエリの種類に適応しない |
リランカーはクエリとドキュメントのペアを同時に処理するため、単語間の細かい相互作用や文脈的な関連性を正確に捉えることができる。実験的に、リランキングの追加によりMRR（Mean Reciprocal Rank）が15〜30%向上することが報告されている。
Cross-Encoderは、クエリとドキュメントを連結して1つの入力としてTransformerモデルに通し、関連性スコアを直接出力するモデルである。代表的なモデルとして以下がある。
| モデル | パラメータ数 | 特徴 |
|---|---|---|
| ms-marco-MiniLM-L-12-v2 | 33M | 軽量・高速、入門用に最適 |
| bge-reranker-v2-m3 | 568M |
| 多言語対応、日本語性能が高い |
| bge-reranker-v2.5-gemma2-lightweight | 2.6B | 最新世代、高精度 |
| Cohere Rerank 3.5 | 非公開 | API提供、多言語・マルチモーダル対応 |
| Jina Reranker v2 | 137M | コスト効率が高い、8K トークン対応 |
Cross-Encoderの処理はクエリ×ドキュメント数の計算量を要するため、初期検索のTop-K全件（数千〜数万件）に適用することは現実的でない。そのため、初期検索でTop-20〜100に絞った後にCross-Encoderを適用するのが標準的な運用である。
ColBERT（Contextualized Late Interaction over BERT）は、クエリとドキュメントを独立にエンコードしつつ、トークンレベルの細粒度マッチングを行う「Late Interaction」アーキテクチャを採用したモデルである。
従来のBi-Encoderは文全体を1つのベクトルに圧縮するため情報損失が生じるが、ColBERTは各トークンのベクトルを保持し、検索時にMaxSim演算（各クエリトークンに対して最も類似度の高いドキュメントトークンを見つけ、その最大値を合計する）で関連性スコアを計算する。
ColBERT v2では、ベクトルの量子化と圧縮により、ストレージコストをCross-Encoderの約1/100に削減しながら同等の精度を達成している。RAGatouille（ColBERT v2のPythonラッパー）を使用すれば、数行のコードでColBERTリランキングを導入できる。
GPT-4oやClaude 3.5 SonnetなどのLLM自体をリランカーとして使用するアプローチも注目されている。LLMにクエリとドキュメントのペアを入力し、「このドキュメントはクエリに対してどの程度関連性がありますか？」と質問して関連性スコアを生成させる。
| 項目 | Cross-Encoder | ColBERT | LLM-as-Judge |
|---|---|---|---|
| 精度 | 高い | 高い | 最も高い |
| 速度 | 中程度 | 速い | 非常に遅い |
| コスト | 低い（ローカル実行可） | 低い | 高い（API課金） |
| カスタマイズ性 | ファインチューニング可 | ファインチューニング可 | プロンプト調整のみ |
| マルチモーダル | テキストのみ | テキストのみ | 画像・テーブル対応 |
LLM-as-Judgeはレイテンシとコストが最大の課題であり、候補数が多い場合にはリストワイズ評価（複数のドキュメントを一度に比較してランク付け）やスライディングウィンドウ手法で呼び出し回数を削減する工夫が必要である。
リランキングをRAGパイプラインに統合する代表的なパターンは以下の通りである。
パターン1: シンプルリランク: 初期検索Top-K → リランカーでスコアリング → Top-N を LLM に渡す。最も基本的なパターンである。
パターン2: カスケードリランク: 初期検索Top-100 → 軽量リランカー（MiniLM）でTop-20 → 高精度リランカー（bge-reranker-v2.5）でTop-5。精度とレイテンシの最適なバランスを実現する。
パターン3: ハイブリッドスコア融合: 初期検索スコア（ベクトル類似度）とリランカースコアの加重平均で最終ランキングを決定する。Reciprocal Rank Fusion（RRF）が広く使われる。
Q: リランキングはどの程度のレイテンシを追加しますか？ A: Cross-Encoder（MiniLM-L-12）でTop-20をリランクする場合、GPU上で約50〜100ms、CPU上で約200〜500msの追加レイテンシが生じる。ColBERTは事前計算済みトークンベクトルを使用するため、20〜50ms程度に抑えられる。LLM-as-Judgeは1ペアあたり500ms〜2sと最も遅い。
Q: リランカーのファインチューニングは必要ですか？ A: ドメイン固有の用語や文書構造がある場合、ファインチューニングにより大幅な精度向上が見込める。MS MARCOなどの汎用データセットで学習済みのモデルは、医療・法律・金融などの専門分野では性能が低下することがある。ファインチューニング用データは、ユーザーのクリックログや人手アノテーションから構築する。
Q: リランキングを使わずに検索精度を改善する方法はありますか？ A: クエリ拡張（Query Expansion）、HyDE（仮説ドキュメント埋め込み）、ハイブリッド検索（ベクトル + BM25）の組み合わせで一定の改善が可能である。ただし、リランキングとは相補的な手法であり、併用することで最大の効果を得られる。