現代の RAG システムでは、次のような複数の Retriever を同時に使うことがよくあります。

• Dense ベクトル検索：意味的な一致を担当する
• BM25 または Sparse 検索：キーワードや厳密な用語の一致を担当する
• タイトル、コード、メタデータなどを対象とする専用検索

各 Retriever は、それぞれ独立した順位付き結果リストを返します。問題は、通常、それぞれのスコア体系が異なることです。

Dense 類似度：0.84
BM25 スコア：13.7

この二つのスコアは直接比較できません。RRF（Reciprocal Rank Fusion、逆順位融合） は、複数の検索順位を一つの結果リストへ統合する手法です。

RRF は 2009 年に Cormack、Clarke、Büttcher によって提案されました。各検索器の生スコアを比較するのではなく、各リスト内での文書順位に基づいて融合することが中核的な考え方です。(ACM Digital Library)

1. RRF が解決する問題

典型的な Hybrid Search の流れは次のとおりです。

ユーザークエリ
   │
   ├── Dense Search → 順位リスト A
   │
   └── Sparse Search → 順位リスト B
                        │
                        ▼
                       RRF
                        │
                 統合候補文書リスト
                        │
                     Reranker
                        │
                       LLM

Dense と Sparse の関連度スコアは、異なるアルゴリズムから得られます。

• Dense 検索では、コサイン類似度や内積が使われることがあります。
• BM25 は、単語頻度、逆文書頻度、文書長などの要素を使います。
• Neural Sparse、フィールド検索、その他の Retriever にも、それぞれ固有のスコア範囲があります。

スコアを直接加算するには正規化が必要であり、正規化方法そのものが最終結果に影響する可能性があります。RRF はこの問題を回避し、各リストにおける文書の 相対順位 だけを使います。そのため、スコア尺度に互換性がない Hybrid Retrieval に特に適しています。(Elastic)

2. RRF の計算方法

一般的な式は次のとおりです。

[ \operatorname{RRF}(d)

\sum_{i=1}^{m} \frac{1}{k+\operatorname{rank}_i(d)} ]

ここで、各記号は次を表します。

• \(d\)：ある文書
• \(m\)：融合に参加する検索結果リストの数
• \(\operatorname{rank}_i(d)\)：第 \(i\) リストにおける文書の順位
• \(k\)：上位順位間のスコア差を制御する平滑化定数

文書の順位が高いほど寄与は大きくなります。同じ文書が複数のリストで上位に入っていれば、通常、その合計スコアも高くなります。

結果が次のようになったとします。

Dense：
1. 文書 A
2. 文書 B
3. 文書 C

Sparse：
1. 文書 C
2. 文書 A
3. 文書 D

簡略化した例として k = 60 とすると、次のようになります。

A = 1/(60+1) + 1/(60+2)
C = 1/(60+3) + 1/(60+1)
B = 1/(60+2)
D = 1/(60+3)

A と C は二つのリストの上位にともに現れるため、最終的に最上位になりやすくなります。

3. RRF が RAG でよく使われる理由

3.1 相互補完的な Retriever を融合できる

Dense Search が得意とするものは次のとおりです。

自然言語の言い換え
同義表現
意味的類似性
言語横断クエリ

Sparse Search が得意とするものは次のとおりです。

エラーコード
製品型番
固有名詞
API 名
法令条文
厳密な数値

RRF はこの二つのシグナルを統合し、RAG に意味的な再現能力とキーワードの厳密性を同時に与えられます。

Elastic、Azure AI Search、Qdrant は、現在いずれも RRF を Hybrid Search のネイティブな融合方式として提供しています。Elastic は、Hybrid Retrieval の一般的な出発点として RRF を明示的に推奨しています。(Qdrant)

3.2 生スコアを共通尺度へそろえる必要がない

Dense と BM25 のスコアを直接融合する場合、通常は次のような処理が必要です。

Min-Max 正規化
Z-score
Softmax
手動設定した重み
データから学習した重み

これらの方法が有効な場合もありますが、より多くの調整と検証が必要です。

RRF は順位だけに依存するため、次の特徴があります。

• 実装が簡単
• パラメータが少ない
• 学習データが不要
• Retriever 間のスコア尺度の違いに影響されにくい

3.3 低コストのベースラインに適している

高品質なラベル付きデータがない場合、RRF は多くの場合、妥当な初期案になります。

Dense Top K
+
Sparse Top K
↓
RRF

その後、評価結果に基づいて、重み付き融合、線形スコア結合、Learning to Rank のどれを使うか判断できます。

4. RAG アーキテクチャにおける RRF の正確な位置

RRF は通常、次の位置に置かれます。

複数経路の検索後、精密な再ランキング前。

Query
  │
  ├── Dense Retriever ── Top 30
  ├── BM25 Retriever  ── Top 30
  └── その他の Retriever ── Top 30
              │
              ▼
             RRF
              │
        融合候補 Top 20～50
              │
      Cross-Encoder Reranker
              │
         最終 Top 5～10
              │
       Context Builder
              │
             LLM

RRF が主に担うのは 候補の融合 であり、最終的な関連性の判定ではありません。

Elastic の現行ドキュメントでも、Hybrid Retrieval、RRF による融合、その後の Semantic Reranking は別々の段階として区別されています。(Elastic)

5. RRF と Reranker の違い

この二つはよく混同されます。

RRF

入力：

複数の順位付き文書リスト

利用する情報：

文書の順位

出力：

融合後の一つの順位リスト

特徴：

• 高速
• モデル推論が不要
• Query と Document の全文内容を読まない
• 検索結果の融合に適している

Reranker

入力：

Query + 候補文書のテキスト

利用する情報：

クエリと文書の結合意味情報

出力：

より精密な関連度順位

特徴：

• 通常はより正確
• レイテンシーとコストが高い
• より小さな候補集合の処理に適している

したがって、一般的な組み合わせは次のとおりです。

Hybrid Retrieval
→ RRF
→ Cross-Encoder / Rerank API

簡単に言えば、次のように理解できます。

RRF：複数経路の結果を適切に統合する
Reranker：その後、どれが最も関連するかを詳しく判断する

6. RRF の主な利点

シンプル

アルゴリズムを実装しやすく、追加の学習済みモデルも必要ありません。

スコア尺度に影響されにくい

Dense、BM25、その他の検索器のスコアを共通の方法で正規化する必要がありません。

複数経路の検索へ拡張しやすい

Dense と Sparse だけでなく、次のような検索も融合できます。

タイトル検索
本文検索
コード検索
多言語検索
異なる Embedding モデル
複数のベクトルフィールド

Azure AI Search は、Hybrid Query と複数の並列ベクトルクエリで RRF を使い、統一された結果を生成します。(Microsoft Learn)

工学的な実装が成熟している

Qdrant、Elasticsearch、Azure AI Search はいずれもサーバー側 RRF を提供しているため、アプリケーション層で二経路の結果を取得してから自力で融合する必要がありません。(Qdrant)

7. RRF の限界

7.1 生スコアの差を無視する

Dense Search が次の結果を返したとします。

文書 A：1 位、0.99
文書 B：2 位、0.60

RRF が把握するのは一位と二位という情報だけであり、実際の類似度に大きな差があることは分かりません。

反対に、一位と二位のスコアがほぼ同じでも、RRF は順位に基づいて異なるスコアを与えます。

7.2 デフォルトでは各 Retriever の影響力がほぼ等しい

従来の RRF は通常、各経路の結果を同等に扱います。

しかし、実際の業務では次のような動作が望まれる場合があります。

エラーコードのクエリ：Sparse の方が重要
自然言語クエリ：Dense の方が重要
タイトル一致：本文一致より高い重み

この場合、次の方法が必要になる可能性があります。

• Weighted RRF
• Query Routing
• スコア正規化と線形重み付け
• Learning to Rank
• 後段の Reranker

重み付き融合や別の融合手法に対応している製品もあります。たとえば Elastic は RRF と線形融合をともに提供し、Qdrant は重み付き形式とスコア分布に基づく融合方式をサポートしています。(Qdrant)

7.3 パラメータ調整が完全に不要なわけではない

RRF はほとんど調整が不要だと言われることがありますが、これはパラメータがまったく重要でないという意味ではありません。

主なパラメータは次のとおりです。

rank_constant / k
各経路の候補ウィンドウサイズ
最終的な返却件数
各 Retriever の重み

Hybrid Retrieval の融合関数を分析した研究では、RRF はパラメータに敏感な場合があり、学習済みの線形スコア結合が一部のデータセットで RRF を上回る可能性が示されています。(arXiv)

したがって、RRF は堅牢なベースラインには適していますが、すべてのデータセットで最適だと仮定することはできません。

7.4 弱い Retriever もノイズを持ち込む可能性がある

ある検索経路の品質が低い場合でも、その順位によって無関係な文書のスコアが加算される可能性があります。

したがって、次の関係は成り立ちません。

Retriever が多い
≠ 必ず品質が高い

各 Retriever を個別に評価し、単にノイズを増やすのではなく、補完的なシグナルを提供していることを確認する必要があります。

8. RRF、重み付き融合、線形融合の選び方

RRF を優先する場合

ラベル付きデータがない
Dense と Sparse のスコア尺度が大きく異なる
Hybrid Search のベースラインを迅速に作りたい
大量のパラメータ調整を避けたい
複数の異なる Retriever を融合する必要がある

重み付き融合を検討する場合

特定の業務で、ある検索経路の重要性が高いと分かっている
Retriever 間の品質差が明確である
クエリ種別に応じて重みを動的に変える必要がある

線形スコア結合を検討する場合

比較的信頼できる検索ラベルデータがある
各経路のスコアを安定して正規化できる
最適な融合重みを学習したい

Learning to Rank を検討する場合

検索トラフィックが多い
豊富なクリックデータまたは関連度ラベルがある
業務上のランキング目標が複雑である
学習と保守のコストを負担する価値がある

現実的な進め方は次のとおりです。

段階 1：RRF ベースライン
段階 2：評価に基づいて k、ウィンドウ、重みを調整
段階 3：線形融合と比較
段階 4：十分なデータが得られたら LTR を検討

9. プロダクション RAG の推奨プロセス

一般的な出発点は次のとおりです。

Dense Top 30～50
+
Sparse Top 30～50
↓
RRF
↓
融合 Top 20～50
↓
Reranker
↓
Top 5～10
↓
Context Builder
↓
LLM

ただし、これらの値は固定されたベストプラクティスではありません。候補集合を大きくすると、次の変化が起こります。

• Recall が向上する可能性がある
• 検索、融合、Rerank のレイテンシーも増える
• 無関係な候補が増える可能性がある
• Reranker のコストが上昇する

プロダクションシステムでは、少なくとも次の項目を評価する必要があります。

Recall@K
MRR
nDCG@K
Hit Rate
P95 検索レイテンシー
Rerank レイテンシー
クエリ当たりのコスト
最終回答の正解率

少なくとも、次の構成を比較します。

Dense-only
Sparse-only
Dense + Sparse + RRF
Dense + Sparse + 線形融合
Hybrid + RRF + Reranker

さらに、クエリ種別ごとに結果を分けます。

自然言語クエリ
キーワードクエリ
番号とエラーコード
固有名詞
言語横断クエリ
回答不能クエリ

そうしなければ、全体平均が特定のクエリ種別における深刻な劣化を隠す可能性があります。

10. ACL、フィルタリング、マルチテナントとの関係

RRF が担当するのは順位の融合だけであり、アクセス制御ではありません。

企業向け RAG では、通常、次の順序が適切です。

ユーザーの本人確認と権限
        ↓
すべての Retriever に同じ ACL Filter を適用
        ↓
Dense / Sparse Retrieval
        ↓
RRF

すべての文書を先に検索・融合し、最後に権限のない文書を除去してはいけません。そのようにすると、次の問題が起こり得ます。

• データ漏えい
• 権限フィルタ後の候補数不足
• 順位結果の歪み

また、Dense と Sparse の両経路では、次の値を一致させる必要があります。

tenant_id
document_version
ACL
有効期間
データ分類レベル

RRF は、上流のインデックス設計や権限設計の問題を修復できません。

11. 現在の製品サポート状況

現在、主要な検索システムは RRF を正式な機能として提供しています。

• Qdrant：Query API で Dense、Sparse、その他の Prefetch を並列実行し、RRF などの方式で融合します。(Qdrant)
• Elasticsearch：RRF Retriever に加えて、線形融合と後段のセマンティック再ランキング機能を提供しています。(Elastic)
• Azure AI Search：Hybrid Query で全文検索とベクトル検索を並列実行し、RRF で統一順位を生成します。(Microsoft Learn)

これは RRF が Hybrid Search の実装で一般的な選択肢になっていることを示しています。ただし、「一般的」であることは「すべての RAG に最適」であることを意味しません。

まとめ

RRF の位置付けは、次のように要約できます。

生スコアではなく順位を使い、複数の Retriever の結果を一つの候補リストへ統合する融合アルゴリズム。

RAG における典型的な価値は次のとおりです。

Dense が意味的な Recall を提供する
Sparse が語彙上の厳密性を提供する
RRF が二つの順位を統合する
Reranker が精密に並べ替える
LLM が最終的な根拠から回答を生成する

RRF はシンプルで堅牢であり、学習データを必要とせず、既存の検索エンジンへ容易に統合できます。一方で、生スコアの差を無視し、Retriever ごとの業務上の重みを標準のままでは表現しにくく、すべての融合手法より優れるとは限りません。

したがって、現在の工学的な実践により即した中立的な結論は、次のようになります。

RRF を Hybrid Search のデフォルトのベースラインとすることは妥当です。ただし、プロダクションへ導入するか、重み付き融合、線形結合、Reranker が必要かは、具体的な検索データセットとオンライン指標に基づいて判断しなければなりません。