リランカーとは？

リランカーは、一次段階の検索（embeddings、BM25 など）で取得した上位候補をクエリに対して再評価し、関連性に基づいて並べ替える第2段階です。
その中核技術はクロスエンコーダーであり、クエリとドキュメントを1つの結合入力として transformer に通し、正確な関連性スコアを算出します。
bi-encoder（embeddings）は高速ですが、各ドキュメントを単一のベクトルに圧縮して情報を失う一方、cross-encoder は低速ですがはるかに高精度です。
cross-encoder は候補ごとに transformer 推論を実行する必要があるため、コーパス全体に直接適用するのはコストが高すぎ、非常に遅くなります。
そのため、標準的なパターンは2段階検索です。まず高速検索で広く候補を集め（recall）、その後、reranker で絞り込みながら精密に順位付けします（precision）。

リランカーとは何か？

検索または RAG（retrieval-augmented generation）パイプラインにおいて、reranker は第2段階の精緻化ステップであり、一次段階の検索で返された候補ドキュメントをクエリに対して再評価し、最も関連性の高いものから順に並べ替えます。一次段階の検索では通常、embedding ベースのベクトル検索や BM25 のようなキーワード検索を使って、数百件の候補を素早く取得します。reranker はその候補のうち上位の一部だけを取り上げ、それぞれがクエリにどれほど関連しているかを慎重に再スコアリングし、そのスコアに基づいて再ランキングします。

reranker の中核をなす技術はcross-encoderです。Pinecone によれば、reranker は「クエリとドキュメントのペアに対して類似度スコアを出力」し、クエリとドキュメントを別々に処理する embedding モデルとは異なり、両者を一緒に解析します。Elastic のドキュメントでも、cross-encoder は「クエリとドキュメントのテキストを1つの連結された入力として受け取る」ことで、クエリを意識したドキュメント表現を生成すると説明されています。

Bi-encoder（Embeddings）とCross-encoder（Reranker）の違い

reranker を理解するには、一次段階の検索で使われるbi-encoderとの違いを把握する必要があります。両者の根本的な違いは、クエリとドキュメントを別々にエンコードするのか、それとも一緒にエンコードするのかという点にあります。

Aspect	Bi-encoder (embeddings)	Cross-encoder (reranker)
Input method	クエリとドキュメントを別々にエンコードする	クエリとドキュメントを1つの入力にまとめて、一緒にエンコードする
Output	再利用可能な埋め込みベクトル	クエリとドキュメントのペアに対する関連性スコア（0–1）
クエリ認識	ドキュメント埋め込みはクエリ非依存です（事前計算済み）	クエリの文脈でドキュメントを評価します
速度	高速（コサイン類似度の比較のみ）	低速（候補ごとにtransformerの推論が必要）
精度	比較的低い	高い
スケーラビリティ	最大で数十億件のドキュメントを事前インデックス化可能	少数の上位候補に対してのみリアルタイムで適用
役割	第1段階の検索（広範囲、再現率重視）	第2段階の再ランキング（狭範囲、精度重視）

bi-encoderの限界は情報損失です。Pineconeは、bi-encoderは「ドキュメントが持ちうるあらゆる意味を単一のベクトルに圧縮しなければならない」と指摘しており、そのため情報が失われます。加えて、クエリが分かるのは実行時のみなので、事前に作成されたドキュメント埋め込みはクエリの文脈を反映できません。これに対してcross-encoderは、「元の情報を大規模なtransformer計算に通す」ことで情報損失をほとんど伴わず、ドキュメントを「ユーザーのクエリに特化した」方法で分析します。

Cross-encoderが埋め込みを生成しない理由

Sentence Transformers（SBERT）のドキュメントには、「cross-encoderは文埋め込みを生成しない」と明記されており、個別の文を単独でcross-encoderに入力することもできないと説明されています。これは、2つの文を同時にtransformerへ通し、0から1の間の類似度値だけを出力するためです。言い換えると、cross-encoderは「このクエリはこのドキュメントにどの程度関連しているか？」に答える精度は非常に高い一方で、大規模検索インデックスを構築するために再利用可能なベクトルを生成する用途には使えません。

なぜ2段階に分けるのか：速度と精度のバランス

cross-encoderのほうが高精度であれば、最初からすべてのドキュメントに適用するのが理にかなっているように見えるかもしれませんが、コストとレイテンシーのためそれは不可能です。Pineconeはこれを、「rerankers are slow, and retrievers are fast」と要約し、具体的な数値も示しています。V100 GPU上で小型のBERTモデルを用いて4000万件のレコードを再ランキングするには50時間以上かかります一方、ベクトル検索は100ミリ秒未満で完了します。

SBERT のドキュメントにも、同様の例が掲載されています。10,000文をクロスエンコーダーでクラスタリングするには、およそ5,000万通りの組み合わせについて類似度を計算する必要があり、約65時間かかります。一方、バイエンコーダーで各文の埋め込みを取得するだけなら、わずか5秒で済みます。

このため、標準的なパターンは2段階検索であり、2つのアプローチを連携させます。SBERT が推奨するフローは次のとおりです。まず、効率的なバイエンコーダーを使って、クエリに対する上位100件の候補を素早く取得します。次に、クロスエンコーダーで各（クエリ、候補）ペアをスコアリングし、その100件を再ランキングします。バイエンコーダーは再現率を確保するために広く候補を拾い、クロスエンコーダーは精度を高めます。Elastic も同じ点を指摘しており、セマンティック再ランキングは「比較的大きく複雑な機械学習モデルをリアルタイムで使用する」ため、小さな上位k件の結果セットに対する最終段階として適用するのが理にかなっていると述べています。

実際の影響と事例

再ランカーは、一次検索で取りこぼした関連文書を上位に引き上げます。Pinecone の例では、RLHF に関するクエリに対して、最も関連性の高い情報は一次検索結果の23位にありましたが、再ランキング後には1位まで上昇しました。その結果、LLM に「はるかに関連性の高い情報」が渡され、ノイズが減少しました。Pinecone は再ランキングを、「RAG や検索ベースのパイプラインにおける再現率を劇的に改善する最も簡単な方法の1つ」と呼び、通常は「数行のコードとわずかなレイテンシ」と引き換えに、はるかに関連性の高い結果を提供するとしています。

商用の再ランカーも広く利用されています。Cohere の Rerank モデルは、「テキスト入力をクエリに対する意味的関連性で並べ替える」もので、既存の検索ソリューションが返した結果を再ソートする用途で頻繁に使われます。Cohere Rerank は、リクエストごとにクエリのトークンと文書のトークンを組み合わせ、たとえばrerank-v3.5のようなモデルでは、文書ごとのコンテキスト上限は4,096トークンです。クエリと文書を合わせたトークン数が上限を超えると、文書は自動的にチャンクに分割され、複数回の推論にまたがって処理されます。

実装チェックリスト

一次検索（ベクトル検索または BM25）で十分に多くの候補を取得します。たとえば上位50〜100件です。その後、再ランカーを適用します。
再ランキングは、レイテンシーとコストを抑えるため、コーパス全体ではなく上位-kの候補セットにのみ適用します。
RAGでは、ノイズを減らして精度を向上させるため、再ランキング後の上位数件だけをLLMのコンテキストに入れます。
多言語ドキュメントの場合は、多言語対応のreranker（たとえば、Cohere multilingual や rerank-v3.5）を選びます。
長文ドキュメントでは、モデルの1文書あたりのトークン上限（たとえば4,096）を考慮してチャンク分割戦略を設計します。