8月26日、Towards Data Scienceが「How Does a RAG Reranker Really Work?」と題した記事を公開した。RAGパイプラインにおけるリランカーの実際の動作原理と、エンタープライズ用途での限界を掘り下げた内容だ。
RAGシステムの検索精度が低いとき、エンジニアが真っ先に聞くアドバイスは「リランカーを追加しろ」だ。しかし「なぜリランカーが効くのか」を問うと、答えはアーキテクチャの説明で止まる——「クロスエンコーダだから」「クエリとパッセージを一緒にアテンションしているから」「関連度ラベルでファインチューニングされているから」。どれも正しいが、モデルが実際に何を学習したかは説明されていない。
この記事はその一段下まで掘り下げ、「ビジネスパートナーに説明できるレベルの答え」を提示する。
リランカーは何を学習しているのか
クロスエンコーダとバイエンコーダの違い
バイエンコーダ（埋め込みモデル）はクエリを単独で読んでベクトルを生成し、パッセージも単独で読んでベクトルを生成する。2つのベクトルをコサイン類似度で比較するだけで、モデルは両者を「一緒に見る」ことはない。
クロスエンコーダ（リランカー）はクエリとパッセージを[CLS] query [SEP] passage [SEP]という形で連結し、全トークンが相互にアテンションできる状態で1回のフォワードパスを実行し、関連度スコアを1つ出力する。この「一緒に読む」という点がアーキテクチャ上の本質的な差異だ。そしてこれが、リランカーがバイエンコーダより30〜100倍遅い理由でもある。
学習データ：MS MARCOとその仲間たち
リランカーの学習には(クエリ, パッセージ, 関連度ラベル)という三つ組のデータが使われる。代表的なのが**MS MARCO**——Bingの実際の検索クエリ約100万件に対して人手で関連度を付与したデータセットで、2016年の初公開以降、パッセージランキング版・QA版など複数のバージョンが整備されてきた（Bajaj et al.）。他にNatural Questions、BEIR、TRECなどが広く使われる。
モデルはこの三つ組を何百万件も見て、「関連ありと判定されたペアに共通するパターン」を学習する。重要なのは、モデルは答えを「生成」するように訓練されていない点だ。ペアを見て、スコアが関連ペアと非関連ペアを分離するよう最適化される。
正直な答え：リランカーが学んだのはトークン間の対応関係
では、学習データ上で関連ペアと非関連ペアを分けている支配的なパターンは何か。
クエリトークンとパッセージトークンの共起関係だ。
MS MARCOにおいて「how to cancel my subscription」というクエリは、cancel、subscription、unsubscribe、terminate、end your membershipを含むパッセージと関連ありとラベルされている。何百万件もの例を通じて、モデルは「cancelを含むクエリにはterminateやunsubscribeを含むパッセージが関連する」という対応関係を重みに吸収する。
つまりリランカーは、クエリのトークン群とパッセージのトークン群の間の学習済み対応機構であり、ニューラルネットワークのスコアとして表現されているにすぎない。バイエンコーダも同じ機構だが、各テキストを独立して処理する。リランカーはペアを条件として処理する。同じ機構、異なる条件付け。
リランカーが勝つケース、詰まるケース
勝つケース：質問の言葉を繰り返さない正解
「What is the maximum coverage amount?」に対して3つのパッセージを用意する。
- 正解：「Cover is capped at 50,000 euros per year」（質問の言葉を使わず答えている）
- エコー：「The maximum coverage amount can be found in the benefits schedule」（質問の言葉を繰り返しているが答えていない）
- 無関係なパッセージ
すべてのバイエンコーダはエコーを1位にする。 エコーがmaximum、coverage、amountを共有しているため、ベクトル空間上で近い位置に来る。正解はほぼ語彙を共有しないので2位か3位に落ちる。
バイエンコーダはすべてエコーを1位に。bgeリランカーは正解を1位に引き上げる。（画像：元記事より）
一方、bge-baseおよびbge-large（BAAI/bge-rerankerシリーズ）のリランカーはこれを逆転させ、正解を1位に持ってくる。「capped at X per year」というパッセージが「maximum coverage amount」という質問に答えていると認識できるのだ。これがリランカーの本来の仕事——質問の言葉と答えの言葉の橋渡し——だ。
ただし、正直な注釈も付く。ms-marco-MiniLMはエコーを1位のままにする（バイエンコーダと同じ語彙バイアスを持っている）。また、text-embedding-3-largeのような強力なバイエンコーダがすでに正解を1位にしている場合、リランカーを追加しても何も改善しない。なお、元記事の比較実験で使用されたバイエンコーダモデルの詳細については元記事を直接参照されたい。
詰まるケース：プライベートな語彙
「what's the rule on contractor overtime?」に対して、正解パッセージが「non-employee labor compensated beyond 40h/week」という社内固有の表現を使っており、contractorという単語が一切含まれていないケース。
正解は「contractor」を使わず「non-employee labor」と書いている。バイエンコーダもリランカーも全モデルが正解を最下位にする。（画像：元記事より）
すべてのモデル——バイエンコーダもリランカーも——が正解を最下位にする。 MS MARCOにcontractor→non-employee laborという対応関係の学習データが存在しないため、リランカーの対応機構にそのエントリがない。クロスアテンションは動いているが、学習していない対応関係には反応できない。
ファインチューニングは「答えを知っている」前提
この問題への標準的な解決策はファインチューニングだ——自社ドメインの(クエリ, パッセージ, 関連)三つ組でリランカーを追加学習する。
しかしここに本質的な矛盾がある。そのラベルを付けるには、「non-employee labor beyond 40h/weekが正解だ」と知っている人間が必要だ。その知識を持っているなら、同義語辞書や用語マッピング（contractor = non-employee laborの1行）を検索前処理として挟む方が直接的な解になりうる。
リランカーのファインチューニングは、統計的な一般化のために何百ものラベル付きペアを要求し、再学習コストがかかり、スコア0.83というブラックボックスとして動く。用語マッピングは1行で書け、決定論的に動き、監査でどのキーワードがマッチしたか明示できる。マッピングが広すぎて列挙できない場合（一般的なウェブ検索規模）にのみ、リランカーの統計的学習は辞書より価値を発揮する。
※編集部の考察：この「辞書 vs. 統計モデル」のトレードオフは、エンタープライズ検索の設計では古典的な論点でもある。ドメイン語彙が限定的・安定的な場合は、クエリ拡張やシノニム辞書との組み合わせがリランカー導入より先に検討に値する。
エンタープライズにおける3つの判断基準
1. 監査証跡が不透明：スコア0.83は「なぜこのパッセージが返ったか」を説明しない。コンプライアンスや法的な文脈では、これは小さなトレードオフではなく失格要因になりうる。キーワードフィルタなら「パッセージにforce majeureとpandemicが含まれていた」と説明できる。
2. コストは現実的：クロスエンコーダはバイエンコーダより30〜100倍遅い。top-20〜50にリランクを絞っても15〜100msの追加レイテンシが生じる。低クエリ量では問題ないが、毎秒100クエリの本番環境ではGPUコストと尾引きレイテンシが現実のコスト項目になる。
3. 語彙ギャップはエンタープライズで必ず顕在化：force majeureとact of Godは保険契約では等価だが、リランカーの学習済み対応機構では異なる近傍に落ちる。rescissionはMS MARCOに少なく、社内製品名は存在しない。バイエンコーダの語彙外問題はリランカーにもそのまま引き継がれる。
リランカーを「チュートリアルがそうしていたから」追加するのか、「この特定のトレードオフが価値を持つから」追加するのか——その判断を支えるのがこの記事の核心だ。
詳細はHow Does a RAG Reranker Really Work?を参照していただきたい。
