今回の論文
今回取り上げるのは、Gordon V. Cormack、Charles L. A. Clarke、Stefan Büttcherによる「Reciprocal rank fusion outperforms condorcet and individual rank learning methods」です。2009年のSIGIRで発表された情報検索・ランキング統合の論文で、公開元はACM、掲載ページは758〜759です。論文の書誌・DOIと著者公開の本文を参照できます。
選んだ理由は、検索モデルを新しく学習しなくても「性質の異なる検索をどう組み合わせるか」を改善できるためです。AIモデルの構造を提案する論文ではありませんが、AI検索やRAGの候補選択に応用できる具体的なアルゴリズムを扱っています。以下では、原論文の検証と、現在のRAGへ応用する際の考察を分けて説明します。
どんな技術か
RRF（Reciprocal Rank Fusion）は、複数の検索器が返した文書ランキングを、一つのランキングへまとめる技術です。使うのは各検索器の生のスコアではなく、文書が何位に現れたかという情報です。
例えば、製品のエラーコードを正確に拾うキーワード検索と、「接続できない」と「認証失敗」のような意味の近さを拾うベクトル検索を併用するとします。両方に上位で現れる文書には加点し、一方だけで見つかる文書にも順位に応じた点を与えます。
これにより、異なる尺度のスコアを無理に足し合わせずに、検索経路を増やせます。RRF自体は文章を読まず、埋め込みも作りません。検索器の後ろに置く、小さな集計処理です。
課題
検索器が違うと、スコアの意味も違います。BM25のスコアとベクトルのコサイン類似度は、そのまま比較できません。単純に足すと、数値の範囲が大きい検索器に結果が偏ることがあります。
スコアを正規化して重み付きで足す方法もありますが、質問ごとの分布や検索モデルの更新によって、適切な調整が変わり得ます。学習型の統合器を作る場合には、正解文書のラベルや学習・検証の仕組みが必要です。
一方、一つの検索器だけに絞ると、その検索器の苦手分野を引き継ぎます。語句一致は型番や識別子に強く、意味検索は言い換えを拾いやすいというように、失敗の仕方が異なります。DPRのデュアルエンコーダによる意味検索は、このうち意味側の検索器を理解する手掛かりになります。
RAGでは、検索の失敗がそのまま回答の根拠不足につながります。そこで、候補を複数経路で集めつつ、生成モデルへ渡す件数は抑えるための統合方法が必要になります。
用語解説
- ランキング融合
- 複数の順位表から、共通の候補集合と最終順位を作る処理です。RRFは検索モデルの内部を変更せず、出力された順位を組み合わせます。
- 疎検索と密検索
- 疎検索は主に語彙ごとの重み、密検索は学習済みの連続値ベクトルで質問と文書を照合します。両者のスコアの尺度が異なるため、順位だけで融合する動機になります。
- 順位の逆数
- 順位の数値が小さいほど大きくなる重みです。RRFでは単純な1/順位ではなく、定数kを加えた1/(k＋順位)を使い、1位だけが極端に強くなるのを抑えます。
- 候補集合と取得深度
- 候補集合は各検索結果の和集合、取得深度は各検索器から何件取り出すかです。実装では有限のリストを融合するため、取得深度によって文書が加点される回数も変わります。
- MAP
- 関連文書が現れた各順位での適合率を平均したAPを、質問全体で平均する指標です。複数の関連文書を上位へ並べられるかを評価し、原論文の主要な比較に使われます。
技術の仕組み
順位を点数に変えて足す
原論文では、文書dに対し、各ランキングrでの順位r(d)を使って次のスコアを計算します。
RRFscore(d) = Σ_r 1 / (k + r(d))
順位は1から数え、合計スコアが大きい文書を上へ並べます。論文では予備実験でkを60に決め、その後の検証でも固定しました。kは返す文書数ではなく、順位の差が点数へ及ぼす強さを調整する定数です。原論文の式と設定
以下は仕組みを理解するための独自の計算例です。kを60とすると、1位の寄与は約0.01639、5位は約0.01538、10位は約0.01429です。一つの検索器の1位だけに現れる文書Aより、二つの検索器の5位に現れる文書Bの合計約0.03077の方が高くなります。
ただし、これは「複数で見つかる文書が必ず勝つ」という規則ではありません。順位、リスト数、リストに現れるかどうかで決まります。kを小さくすると最上位の差が強くなり、大きくすると取得範囲内での順位差が縮まり、出現する検索経路の数が相対的に効きやすくなります。
上位リストへ適用するときの処理
原論文の式は共通の文書集合に対する順位で定義されています。実際のRAGで各検索器の上位だけを受け取る場合は、取得されたリストに現れた文書だけに加点し、現れないリストからの寄与をゼロとする形で実装できます。これは有限候補へ適用する際の規約なので、取得件数と一緒に記録します。
処理は、検索、IDの統一、スコアの集計、並べ替えの順です。概念的には次のようになります。
from collections import defaultdict
def rrf(rankings, k=60, output_count=20):
scores = defaultdict(float)
for ranking in rankings:
# rankingは同一粒度の一意な文書IDの順位表です。
for rank, document_id in enumerate(ranking, start=1):
scores[document_id] += 1.0 / (k + rank)
# 同点時の順序も固定し、比較を再現しやすくします。
return sorted(scores, key=lambda d: (-scores[d], d))[:output_count]この例では各リスト内のIDは一意で、ID同士を比較可能としています。同じ文書の別URLや別版が混ざる場合は、集計前に何を同一とみなすか決めます。チャンク単位の検索ならチャンクIDを使い、文書単位とチャンク単位の順位をそのまま混ぜない設計が必要です。
学習と推論で何が増えるか
基本のRRFには、追加のニューラルネットワークや学習工程がありません。各検索器の順位表を順次処理でき、すべての順位表を同時に保持する必要もありません。原論文のDiscussion
実装上の計算量を考えると、検索器がm個、各取得件数がLなら集計はおおむねO(mL)、候補の異なるIDがU個なら全件の並べ替えはO(U log U)です。これは上の実装から分かる計算量で、原論文の実測速度ではありません。全体の遅延には、複数の検索を実行する時間も含まれます。
実験と結果
原論文は、検索方式の異なる結果を統合したときのMAPを比較しています。BM25と現在の埋め込みモデルを組み合わせるRAGの実験ではありません。
TRECで単独検索と融合方式を比較する
表2ではTREC参加システムの提出結果を融合しています。値はMAPで、高いほど良好です。
| 評価集合 | RRF | 最良の単独結果 | Condorcet | CombMNZ |
|---|---|---|---|---|
| TREC Robust | 0.3686 | 0.3586 | 0.3652 | 0.3575 |
| TREC 3 | 0.4350 | 0.4226 | 0.4256 | 0.4381 |
| TREC 5 | 0.3394 | 0.3165 | 0.3213 | 0.3237 |
| TREC 9 | 0.2830 | 0.3519 | 0.2750 | 0.2671 |
Condorcetは文書ペアの順位を多数決で決める方式、CombMNZは検索スコアと出現数を使う融合方式です。RRFは表2の全集合でCondorcetを上回りますが、TREC 3ではCombMNZが上回っています。TREC 9の最良単独結果は人間の関与がある方式で、自動方式の最良値0.2801はRRFが上回りました。原論文の表2と説明
学習済みランキングの統合にも使える
LETOR 3の583,850文書・質問ペアを使った表3では、RRFのMAPは0.6051、単独方式で最良のListNetは0.5846でした。差は0.0205で、相対的には約3.5%の改善です。一方、CombMNZは0.6107で、RRFより数値上は高く、この二方式の差はp＝0.2でした。原論文の表3
結果が示すのは、順位だけを使う簡単な統合でも、単独の学習済みランキングを改善できる場合があることです。どんな検索器の組でも改善する保証や、RAGの回答精度が同じ割合で上がる証拠ではありません。
何に使える？
以下は、RRFの性質を踏まえた開発上の応用案です。原論文が直接検証した用途ではありません。
社内文書RAGの候補を集める
規程名や申請番号を拾う語句検索と、社員の口語的な質問を拾う意味検索を組み合わせます。スコアの調整を先に作り込まず、双方の順位を使って候補を統合できる点が役立ちます。
RRFの後に、質問と本文を精密に照合する処理を置くこともできます。RankRAGの再順位付けと回答生成は、その後段を考える例です。RRFは候補を広くまとめ、本文を読むモデルは適用条件などを詳しく判断する、という役割分担になります。
コード・障害調査の検索
エラーメッセージや関数名をキーワードで検索し、症状の説明をベクトル検索します。正確な識別子と、説明の言い換えを別の経路で拾う構成です。ソースコード、Issue、仕様書をまたぐなら、統一IDと対象バージョンを持たせることで、融合後の根拠を追跡しやすくなります。
検索クエリを変えた結果の統合
エージェントが元の質問と補助クエリで検索した結果を、RRFでまとめる使い方も考えられます。ただし、似た補助クエリを大量に作ると、同じ種類の結果だけが繰り返し加点されます。検索回数を増やす前に、各経路で新しい正解根拠を拾えているかを確認する必要があります。
開発や事業へのヒント
検索器の追加価値を測る
小規模なRAGでも、既存の語句検索と埋め込み検索を接続し、RRFを比較の出発点にできます。まず、各検索単独、候補の和集合、融合後の上位候補を分けて評価します。
和集合に正解根拠が入らないなら、検索器やチャンクの問題です。和集合にはあるのに融合後に落ちるなら、順位統合や取得深度を見直す余地があります。回答だけを採点するより、改善箇所を特定しやすくなります。
三つの数を別々に調整する
各検索器の取得件数L、RRFの定数k、後段へ渡す件数Nは別の設定です。例えば「各100件取得、k＝60、融合後20件」は検証用の一案であり、論文がRAG用に推奨した設定ではありません。
Lを変えると候補範囲と重複の数が変わり、kを変えると順位の重みが変わり、Nを変えると後段の計算量が変わります。自社質問の評価セットで、根拠到達率、上位の適合率、回答品質、遅延を一緒に比較します。
順位の内訳をログへ残す
最終スコアだけでなく、検索経路、元順位、文書ID、取得件数を保存します。「二経路で共通して高い」「一経路だけだが上位」という違いが分かれば、品質低下の原因を調べやすくなります。RRFは足し算なので、各経路の寄与を説明できる点も実装上の利点です。
限界
RRFはスコアの尺度に依存しない代わりに、スコア差の情報を捨てます。1位と2位に大きな確信度の差があっても、同じ順位なら同じ寄与になります。信頼できるスコアを校正できる環境では、別の融合方式が有利な可能性があります。
また、検索器の質を自動で判定しません。弱い検索器やほぼ同じ検索器を追加すると、不要な候補や偏りを強めることがあります。原論文の改善結果だけから、検索経路を増やすほどよいとは言えません。
有限の上位リストでは、圏外の文書は加点されません。取得深度の差やフィルタの適用順、重複IDの扱いで結果が変わります。アクセス権や製品版の条件は検索時点でそろえ、同じ粒度の候補を融合する必要があります。
集計処理は軽量でも、検索器を追加するコストは残ります。並列実行なら遅い経路の応答待ち、逐次実行なら時間の積み上がりが問題になります。期限までに返らない経路を除く場合も、使われた経路を記録しないと再現性が落ちます。
そしてRRFには、文書の事実性、更新日の妥当性、回答への論理的な適合を読む機能がありません。原論文は短い情報検索研究であり、日本語社内文書や現代のRAGにおける有効性は、対象データで別途検証する必要があります。
よくある質問
Q. RRFを使えば埋め込みモデルの学習は不要ですか？
A. RRF自体の追加学習は不要ですが、意味検索には学習済みの埋め込みモデルなどが必要です。RRFは検索器を作る技術ではなく、既にある順位表をまとめる技術です。
Q. k＝60なら上位60件を返すのですか？
A. いいえ。kは1/(k＋順位)の定数です。各検索器が何件返すか、融合後に何件残すかは別に決めます。60は原論文で固定した値であり、あらゆる対象への最適値ではありません。
Q. RRFの後にリランキングは必要ですか？
A. 必須ではありません。RRFは本文を読まないため、似た候補の適用条件まで区別したい場合は、融合後の少数候補をリランカーで精査する構成が考えられます。追加遅延に見合う改善があるかを測って判断します。
Q. 一方の検索だけで見つかった文書は消えますか？
A. 消えません。その順位に対応する寄与が残ります。ただし複数経路で加点された文書が上へ来ると、最終的な件数制限で落ちる場合があります。和集合の評価と融合後の評価を分けると、この取りこぼしを確認できます。
Q. RRFの点数を回答の信頼度として表示できますか？
A. そのまま確率として表示するのは適切ではありません。点数は検索経路の数、順位、k、取得深度に依存する相対値です。例えば経路を増やすだけでも合計値が変わるため、正答確率や根拠の事実性を表しません。
今日の学び
この論文は、尺度の異なる複数の検索結果を、追加学習なしで統合する課題を扱いました。RRFは順位に定数を加えた逆数を足し合わせ、単独検索では得にくい組み合わせの効果を狙います。
開発へのヒントは、検索モデルの高性能化に加えて、既存の検索経路をどう集め、どう絞るかも設計対象にすることです。RAGでは候補の和集合と最終順位を分けて測ることで、検索不足と統合時の取りこぼしを切り分けられます。