7月29日、Jeff Millsが「Top Reranking Models to Boost RAG Accuracy in 2026」と題した記事を公開した。RAGパイプラインにおけるリランキングモデルの種類・選定基準・本番運用コスト管理について詳しく論じている。
「ランキング23位の正解」が答えを壊す
RAGを本番で動かしていると、こんな障害が起きる。レトリーバーは50チャンクを取得し、正しいドキュメントはその中に含まれている。しかし位置23番に埋もれており、LLMは先頭付近の「惜しい外れ」を拾って誤答を生成する。
これはcontext rotと呼ばれるLLMの既知の弱点に起因する（学術的には"Lost in the Middle"問題として知られており、関連情報がコンテキストの中間に位置するほど参照されにくくなる現象を指す）。関連情報がコンテキストの先頭や末尾にあれば精度は高いが、中間に埋まると性能が落ちる。リランキングはこの問題に直接対処する層だ。第一段階検索（リコール重視の広い網）でプールした候補を、より精度の高いモデルで並び替え、最良のチャンクをプロンプトの先頭に移動させる。
第一段階（BM25やベクトル検索）は速度優先で設計されており、ドキュメントを1ベクトルや単語袋に圧縮する段階で詳細が失われる。リランキングはその損失を補う「精度レイヤー」として機能する。
リランキングモデルの3つの方式
クロスエンコーダー（最も主流）
クエリとドキュメントを同一のTransformerに入力し、ペアの関連スコアを出力する。すべてのクエリトークンがドキュメントトークンを「見る」ため精度が高い。Cohere、Voyage AIのRerankモデル、BAAI/bge-rerankerファミリー、Mixedbread/mxbai-rerankファミリーなど、現在の主流リランカーの多くがこの設計を採用している。
コストはペア数に比例するため、候補プールが小さい場合に限って使う設計になっている。10,000文を全ペアで評価すると約5,000万ペアとなり、クロスエンコーダーでは約65時間かかる計算だ。同じ文をバイエンコーダーで埋め込み生成すれば約5秒で済む。
小型モデルはコストを和らげる。cross-encoder/ms-marco-MiniLM-L6-v2はTREC DL19でnDCG@10 74.30を記録しつつ、毎秒1,800ドキュメントを処理できる。
LLMベースのリランカー
生成モデルにドキュメントを渡してランク順を出力させる方式（RankGPTスタイル）。大規模LLMの知識を使えるが、速度とコストの代償が大きい。ゼロショットのLLMリランカーはドメイン外データでファインチューニング済みリランカーに精度で劣ることも多く、「大きなLLMを使えば勝てる」という単純な話にはならない。
Qwen3 Rerankerファミリー（0.6B / 4B / 8B）は各ペアに対して「yes」と「no」を生成する確率からスコアを算出するアプローチで、比較的小型にLLM的な判断を取り込んでいる。
レイトインタラクション・マルチベクトル（ColBERT系）
ColBERTはクエリとドキュメントをトークンごとのベクトル集合として独立にエンコードし、クエリ時に最大類似度演算でスコアを算出する。ドキュメントのベクトルを事前計算できるため、従来のBERTベースランカーに比べて2桁（100倍程度）高速との報告がある。弱点はストレージ：コレクション内の全トークン分のベクトルを保持する必要があるが、後期バージョンの残差圧縮でフットプリントを大幅に削減できる。
モデル選定の実践的な判断軸
レイテンシ予算との照合
ミッドサイズのクロスエンコーダーは1クエリあたり数十〜数百ミリ秒、LLMリランカーは数秒かかることもある。ただし、シャープなチャンクをLLMに渡すことで生成時間が短縮されるため、リランキングのレイテンシを単体で評価するのではなく、エンドツーエンドの合計で計測する必要がある。
ハードウェア、バッチサイズ、量子化の条件によって数字は変動するため、公開ベンチマークは出発点にすぎない。自分のワークロードで実測することが前提だ。
コンテキスト長と多言語対応
チャンクが512トークン前後であればほとんどの主流リランカーで問題ない。ページ全体や長い書き起こしをリランキングする場合は、モデルカードの「最大コンテキスト長」だけでなく「推奨動作コンテキスト長」も確認すること（推奨値はハードリミットよりかなり低いことが多い）。
多言語対応もモデルカードの記載だけで判断せず、実際のクエリ分布でテストする必要がある。
スコアのキャリブレーション
リランカースコアは相対順位を示すものであり、絶対的な関連度ではない。あるモデルの0.7と別モデルの0.7は意味が違う。リランカーを交換するたびに閾値の再調整が必要になる。ドメイン外データでは関連・非関連の差が小さくなり、固定カットオフが機能しなくなることもある。クエリごとに「上位N件を常に渡す」ではなく、スコアのフロア値と組み合わせて評価するのが実践的なアプローチだ。
第一段階検索の質がリランカーの上限を決める
リランカーは候補プールにないドキュメントを復元できない。第一段階のリコールがリランカーの性能上限を決める。
候補数を増やせば増やすほど良いわけでもない。余分なドキュメントが混入すると回答精度が下がる場合があり、候補数が多すぎると単独の検索より再現率が下がるケースもある。
第一段階の品質を上げる現実的な手段はハイブリッド検索（キーワード検索＋ベクトル検索の組み合わせ）だ。Redisの場合、Redis 8.4で追加されたFT.HYBRIDがRRF（Reciprocal Rank Fusion）または線形結合で全文検索とベクトル検索の結果を統合する。10億ベクトルのベンチマークでは、50並列クエリで上位100件を取得した際に**中央値レイテンシ約200ms・精度90%**という結果が報告されている。
本番コストを抑える4つのパターン
1. オーバーフェッチ→トランケート
リランキング後に上位チャンクのみLLMに渡す。広く候補を取得してから絞り込むことで、リコールと精度を両立させる基本パターンだ。
2. モデルの階層化
低リスクなクエリは安価な高速ティアにルーティングし、複雑なクエリにのみ高精度モデルを使う。トラフィック全体に重いリランカーを適用するのではなく、クエリの性質に応じて使い分けることでコストを抑える。
3. 自前ホスティング
小型オープンウェイトモデルは継続的な高トラフィックがあれば自己ホストが現実的な選択肢になる。APIコールのレイテンシも排除できる。
4. セマンティックキャッシング
意味的に近い過去クエリの回答を返すことで、検索・リランキング・生成をまるごとスキップする。RedisのLangCacheはこのパターンのマネージドサービスで、LLM推論コスト最大73%削減を報告している。
RedisVL（Redis公式のPythonクライアントライブラリ）はローカルのHugging Faceクロスエンコーダー、CohereとVoyage AIのホステッドリランカーをRedisパイプラインに直接接続できる。
リランカーは精度レイヤーとして有効だが、第一段階検索が弱ければ意味がない。まず高リコールのハイブリッド検索を整備し、自分のデータでキャリブレーションし、繰り返しクエリはキャッシュで逃がす——この順番が本番導入の基本だ。
詳細はTop Reranking Models to Boost RAG Accuracy in 2026を参照していただきたい。
