RRF(Reciprocal Rank Fusion)とは？ハイブリッド検索とRAGで使う順位統合を初心者向けに解説

RRF(Reciprocal Rank Fusion)とは？ハイブリッド検索とRAGで使う順位統合を初心者向けに解説

RRFは、AI検索やRAGを学び始めた人にとって少し地味に見える用語です。生成AIの回答文そのものを作るモデルでも、文章をベクトルへ変換する埋め込みモデルでもないため、最初は重要性が分かりにくいかもしれません。しかし実際の検索システムでは、ユーザーの質問に対して「どの文書を上位候補として渡すか」が回答品質を大きく左右します。どれほど高性能なLLMを使っていても、参照させる情報がずれていれば、回答もずれます。

そこで役立つのが、複数の検索手段を組み合わせる考え方です。たとえば全文検索は、ユーザーが入力した語句と同じ単語が文書に出てくる場合に強い一方、言い換えや抽象的な質問には弱いことがあります。ベクトル検索は、意味が近い文書を探しやすい一方で、固有名詞、型番、エラーコード、短い専門語の完全一致では期待どおりに上位へ出ないことがあります。RRFは、このような異なる得意分野を持つ検索結果を、スコアの大きさではなく順位を使って統合するための実用的な方法です。

RRFが必要になる背景

検索システムの目的は、単に大量の文書から何かを見つけることではありません。ユーザーが求めている情報を、できるだけ少ない手間で、できるだけ上位に出すことです。社内FAQ、ECサイトの商品検索、論文検索、カスタマーサポートのナレッジ検索、RAGの文書検索など、目的は違っても「上位に何を並べるか」は共通した課題です。

従来のキーワード検索では、BM25のような手法がよく使われます。BM25は、検索語が文書内にどれくらい現れるか、文書全体の長さはどうか、その語が珍しいかどうかといった要素を使って関連度を計算します。検索語と文書中の語がはっきり対応している場面では非常に強く、特に商品番号、法律名、エラーコード、機能名、固有名詞の検索では頼りになります。

一方で、近年のAI検索ではベクトル検索もよく使われます。文章を埋め込みモデルで数値ベクトルに変換し、意味的に近い文書を探す方法です。「パスワードを忘れた」と「ログインできない」は文字列としてはかなり違いますが、意味としては近い場合があります。ベクトル検索はこのような言い換えを拾いやすく、自然文の質問や曖昧な問い合わせに向いています。

ただし、どちらか一方だけで常に十分とは限りません。キーワード検索は言い換えを見落とすことがあり、ベクトル検索は細かな語句の一致や数値の違いを軽く扱いすぎることがあります。そこで、キーワード検索とベクトル検索を両方実行し、それぞれの上位結果を統合するハイブリッド検索が使われます。問題は、統合するときに何を基準にするかです。

検索器Aのスコアが0.92、検索器Bのスコアが13.7だったとして、そのまま足してよいとは限りません。スコアの意味、範囲、分布、計算方法が違うからです。ベクトル検索の類似度とBM25の関連度スコアは、同じ「点数」に見えても同じ物差しではありません。RRFはこの問題に対して、各検索器の中で何位だったかを共通の物差しとして使います。

RRFの基本的な考え方

RRFの名前に含まれるReciprocal Rankは「順位の逆数」という意味です。ある文書が検索結果の1位に出たなら大きく評価し、10位ならそれより小さく評価し、100位ならさらに小さく評価します。Fusionは複数の結果を融合することです。つまりRRFは、複数のランキングにおける順位の逆数を足し合わせて、文書ごとの統合スコアを作る方法だと考えられます。

よく使われる形は、文書ごとに次のような値を足す考え方です。

たとえば、文書Aがキーワード検索で2位、ベクトル検索で5位だったとします。文書Bはキーワード検索では30位ですが、ベクトル検索では1位だったとします。RRFでは、それぞれの順位から加点を計算し、複数の検索リストにまたがって合計します。複数の検索器で安定して上位に出る文書は高く評価されやすく、一方の検索器で非常に上位に出た文書も一定の評価を得ます。

ここで重要なのは、RRFが元の検索スコアを直接比較しないことです。BM25で20点だった文書と、ベクトル検索で0.82だった文書を「どちらが強いか」と直接比べる必要がありません。それぞれの検索器が自分の基準で並べた順位だけを使い、順位から統合スコアを作ります。この性質により、スコア正規化の設計が難しい場面でも導入しやすくなります。

順位を使うとなぜ安定しやすいのか

スコアを使った統合は一見すると自然です。高い点数の文書を上に置けばよい、という考え方は分かりやすいからです。しかし、複数の検索器を使うと、点数の意味が変わります。ある検索器では0.9が非常に高い値かもしれませんが、別の検索器では0.9付近の文書が大量に出るかもしれません。BM25のようなスコアはクエリや文書集合によって値の範囲が変わりやすく、単純な足し算では一方の検索器に偏ることがあります。

順位は、各検索器の中での相対的な強さを表します。1位はその検索器が最も関連すると見なした文書であり、2位は次に関連すると見なした文書です。もちろん順位も完全ではありませんが、異なるスコア尺度を無理に合わせるより扱いやすい場合があります。RRFはこの相対順位を使うことで、検索器ごとのスコア設計の違いをある程度吸収します。

また、RRFは上位の差を重視します。1位と2位の差は、50位と51位の差より検索品質に与える影響が大きいことが多いからです。ユーザーが実際に見るのは上位数件であり、RAGでLLMに渡す文書数も限られます。RRFの加点は順位が下がるほど小さくなるため、上位に現れた文書を自然に優先できます。

一方で、RRFは下位に現れた文書を完全に無視するわけではありません。候補数を広めに取り、複数の検索器でそこそこ上位に出ている文書を拾うことができます。これは、検索語が少し曖昧な場合や、複数の観点から関連文書を集めたい場合に役立ちます。ただし、あまり深い順位まで入れすぎるとノイズも増えるため、取得件数の設計が重要になります。

RRFの簡単な例

具体例で考えてみましょう。社内ナレッジベースで、ユーザーが「ログインできない」と検索したとします。キーワード検索では「ログイン」「できない」という語を含む文書が上位に来ます。ベクトル検索では、「パスワードを忘れた」「アカウントに入れない」「認証エラーが出る」といった意味的に近い文書が上位に来るかもしれません。

この例では、文書の良し悪しは単純な語句一致だけでは決まりません。「ログイン」という語が出ていても、デザイン変更履歴はユーザーの困りごとに合わない可能性があります。一方で「パスワード再設定」は、検索語と完全には一致しなくても、ユーザーの意図に合うかもしれません。RRFは、キーワード検索とベクトル検索の両方の視点を統合し、候補の偏りを抑えるために使われます。

ただし、RRF自体が文書の意味を深く理解しているわけではありません。RRFが見ているのは、あくまで各検索器が出した順位です。元の検索器がまったく不適切な候補しか返していなければ、RRFで統合しても良いランキングにはなりません。この点は初心者が誤解しやすいところです。RRFは検索品質を魔法のように改善する装置ではなく、複数の有効な検索結果をより扱いやすく混ぜる方法です。

ハイブリッド検索での使いどころ

ハイブリッド検索とは、複数の検索方法を組み合わせる検索設計です。代表的なのは、キーワード検索とベクトル検索の組み合わせです。キーワード検索は厳密な語句一致に強く、ベクトル検索は意味的な近さに強いため、両方を使うことで検索漏れを減らしやすくなります。

RRFは、このハイブリッド検索の統合部分でよく使われます。流れとしては、まず同じクエリをキーワード検索器とベクトル検索器へ投げます。次に、それぞれから上位N件の候補を取得します。そして、候補文書のIDをそろえ、文書ごとにRRFスコアを計算します。最後に、RRFスコアの高い順に並べ直します。

この方法の利点は、システムを段階的に改善しやすいことです。すでに全文検索があるシステムにベクトル検索を追加する場合、既存の検索器を完全に捨てる必要はありません。両方の検索結果を取り出し、RRFで統合することで、既存の強みを残しながら意味検索の強みを足せます。新しい検索器を追加したときにも、まずは順位統合として試しやすいのが特徴です。

また、RRFは検索器の種類が2つに限定されません。キーワード検索、ベクトル検索、タイトルだけを対象にした検索、タグやカテゴリを重視する検索、更新日時や人気度を考慮した検索など、複数のランキングを統合できます。もちろん検索器を増やせばよいというものではありませんが、複数の観点をランキングとして表現できるなら、RRFは統合の候補になります。

実務では、各検索器から何件ずつ取るかも重要です。キーワード検索から10件、ベクトル検索から10件だけ取るのか、それぞれ50件ずつ取るのかで、RRFに渡される候補の幅が変わります。候補が少なすぎると、片方の検索器で少し下にいた有用文書を拾えません。候補が多すぎると、ノイズが増え、処理コストも上がります。RRFは統合手法ですが、その前段の候補生成設計とセットで考える必要があります。

RAGでRRFが注目される理由

RAGは、LLMに外部知識を参照させながら回答させる構成です。一般的には、ユーザーの質問を受け取り、関連文書を検索し、その文書をプロンプトに含めてLLMへ渡します。このとき、検索で選ばれた文書が回答の材料になります。つまり、検索段階で重要な文書を取り逃すと、LLMは正しい根拠を持てません。

RAGでは、ユーザーの質問が自然文で入力されることが多く、単語一致だけでは十分でない場面が多くあります。「退職時に返却するものは？」という質問に対して、社内文書では「貸与物の返却」と書かれているかもしれません。このような言い換えにはベクトル検索が有効です。一方で、「Form 1099」「ERR-4031」「SAML」などの固有の記号や専門語は、キーワード検索の方が堅実に拾えることがあります。

RRFは、この両方を活かしたいRAGで便利です。キーワード検索だけでは自然文の揺れに弱く、ベクトル検索だけでは厳密な語句の一致を逃す可能性があります。RRFで統合すると、両方の検索器が上位に置いた候補を強く評価しつつ、一方の検索器だけが見つけた重要候補も残しやすくなります。

ただし、RAGでRRFを使えば必ず回答が正しくなるわけではありません。LLMに渡す文書数には上限があり、チャンクの長さ、重複、文書の鮮度、権限管理、プロンプト設計も影響します。RRFは、検索候補の並びを改善するための部品です。RAG全体の品質は、検索、統合、リランキング、コンテキスト構成、回答生成、評価の組み合わせで決まります。

スコア統合との違い

RRFとよく比較されるのが、スコアを正規化して足し合わせる方法です。たとえば、キーワード検索のスコアとベクトル検索のスコアを0から1の範囲に変換し、重みを付けて合計する方法です。この方法は、スコアの意味をきちんと調整できるなら有効です。特定のデータセットで検証し、どの重みがよいかを継続的に評価できる場合、スコア統合の方が細かく制御できることもあります。

しかし、スコア正規化は意外に難しい作業です。検索クエリごとにスコア分布が違ったり、検索器のバージョン変更でスコアの出方が変わったり、文書集合の更新で分布が変わったりします。スコアの最大値と最小値で正規化しても、外れ値に引っ張られることがあります。平均や標準偏差を使っても、クエリごとのばらつきは残ります。

RRFは、こうした調整の複雑さを避けやすい手法です。順位だけを使うため、元スコアの尺度をそろえる必要がありません。特に、まずハイブリッド検索を試したい段階や、複数の検索器のスコア設計が大きく異なる段階では、RRFの単純さが強みになります。

一方で、RRFはスコアに含まれる細かな情報を捨てます。1位と2位のスコア差が非常に大きい場合でも、順位としては1位と2位です。逆に、1位と2位のスコアがほぼ同じでも、順位差として扱われます。検索器のスコアが十分に信頼でき、その差分に意味があるなら、スコア統合や学習ベースのランキングの方がよい場合もあります。

単純な順位平均との違い

順位を使うなら、単純に平均順位を取ればよいのではないか、と思うかもしれません。たとえば、文書Aが1位と9位なら平均5位、文書Bが4位と4位なら平均4位、というように並べる方法です。これは直感的ですが、検索結果に現れなかった文書や、非常に下位に出た文書の扱いが難しくなります。

RRFでは、順位の逆数に近い形で加点するため、上位順位の影響が大きく、下位順位の影響は小さくなります。平均順位では、片方の検索器で非常に下位だった場合に大きく引き下げられることがありますが、RRFでは「上位に出た事実」を比較的活かしやすい設計です。これは、検索器ごとに得意分野が違う場合に役立ちます。

また、実際の検索統合では、すべての文書がすべての検索器に出てくるとは限りません。キーワード検索の上位100件には出るが、ベクトル検索の上位100件には出ない文書もあります。RRFでは、出現したランキングの分だけ加点し、出現しなかったランキングからは加点しない、という扱いができます。実装上も比較的シンプルです。

リランキングとの違い

RRFとリランキングも混同されやすい用語です。リランキングは、いったん集めた候補文書を、より高精度なモデルや追加ルールで並べ直す処理です。たとえばCross Encoderのようなモデルを使い、クエリと文書をペアで見て関連度を判定する方法があります。リランキングは精度が高い一方で、計算コストが大きくなりやすいのが特徴です。

RRFは、複数の検索結果リストを統合する軽量な方法です。クエリと文書の意味を新たに深く判定するわけではありません。各検索器が出した順位をもとにスコアを作るだけです。そのため、リランキングより安価で高速に使いやすい反面、最終的な意味判断の細かさではリランキングに及ばないことがあります。

実務では、RRFとリランキングを組み合わせることもあります。まずキーワード検索とベクトル検索で広めに候補を集め、RRFで統合して上位候補を作ります。その後、上位50件や100件に対してリランキングをかけ、最終的にLLMへ渡す数件を選びます。この構成では、RRFは候補の偏りを抑える前段の統合役、リランキングは最終的な精査役として働きます。

RRFで調整する主なパラメータ

RRF自体はシンプルですが、運用で考えるべき値はいくつかあります。代表的なのは、式に出てくるk、各検索器から取得する候補数、最終的に残す件数です。これらは検索品質と処理コストに影響します。

kは、順位の影響を調整する定数です。一般的には、上位順位の差を極端にしすぎないために使われます。kが小さいと、1位と2位の差が相対的に大きくなります。kが大きいと、順位差の影響がなだらかになります。初心者は、まずよく使われる値やライブラリのデフォルト値から始め、評価データに対して比較するのが現実的です。

検索器ごとの重みも検討対象になります。たとえば、特定の業務ではキーワード一致をより重視したいかもしれません。法務文書、仕様書、医療・金融のように用語の厳密性が重要な場面では、ベクトル検索だけに寄せると危険なことがあります。一方、問い合わせ文が自然文で長く、言い換えが多い場面では、ベクトル検索の寄与を高めたい場合があります。Weighted RRFのように、検索器ごとの加点に重みを付ける設計もあります。

実装の流れ

RRFの実装は、概念としては難しくありません。必要なのは、各検索器から返ってきたランキング、文書を識別するID、順位をもとにした加点処理です。実装の流れを簡単に整理すると、次のようになります。

注意したいのは、文書IDの扱いです。同じ文書がキーワード検索とベクトル検索の両方に出てきた場合、それを同一文書として統合できなければ、RRFの効果が弱まります。チャンク単位で検索しているRAGでは、同じ元文書の別チャンクが複数出ることもあります。文書単位でまとめるのか、チャンク単位で扱うのか、元文書ごとの重複を抑えるのかを決める必要があります。

また、メタデータによるフィルタリングの順序も重要です。権限、公開範囲、日付、カテゴリ、言語などで絞り込みが必要な場合、RRFの前にフィルタするのか、後にフィルタするのかで結果が変わります。権限のように絶対に守るべき条件は、統合前後に関係なく確実に適用する必要があります。検索品質だけでなく、安全性と運用ルールも設計に含めましょう。

RRFが向いている場面

RRFは、複数の検索器を手早く組み合わせたい場面に向いています。特に、スコアの尺度が違う検索器を使う場合、順位ベースで統合できることが強みです。既存のキーワード検索にベクトル検索を追加したい、RAGの検索候補を広げたい、複数のデータソースや検索条件の結果をまとめたい、といった場面で候補になります。

また、検索器ごとの調整に多くの時間をかけられない初期段階でも使いやすい方法です。スコア正規化を細かく設計する前に、RRFでベースラインを作ると、ハイブリッド検索の効果を確認しやすくなります。評価データが十分でない段階でも、完全な重み学習より導入のハードルは低いでしょう。

RRFは、検索結果の上位を安定させたい場合にも役立ちます。複数の検索器で共通して上位に出る文書は、関連性が高い可能性があります。RRFはそのような文書を押し上げやすく、一方の検索器だけの癖に引っ張られにくい設計です。もちろん、検索器が同じような失敗をしている場合には効果が限定されますが、性質の異なる検索器を組み合わせるほど意味が出やすくなります。

RRFが向いていない場面

RRFは万能ではありません。まず、検索器が1つしかない場合には、そもそも統合するランキングがありません。単一の検索器の内部スコアを使って精度を上げたい場合は、検索器のパラメータ調整、インデックス設計、クエリ拡張、リランキングなどを検討する方が自然です。

また、元スコアに非常に意味があり、十分に正規化できる場合には、RRFよりスコア統合の方が細かい制御をしやすいことがあります。たとえば、同一のモデル系列で計算されたスコアを統合する場合や、十分な教師データを使ってランキングモデルを学習できる場合です。RRFは単純で頑健な一方、スコア差の細かな情報は利用しません。

さらに、最終的な関連性判断を高精度に行いたい場面では、RRFだけでは足りないことがあります。RAGで数件だけをLLMへ渡す場合、上位候補の微妙な順序が回答の質に影響します。そのような場面では、RRFで候補をまとめた後に、Cross EncoderやLLMベースの評価、ルールベースのフィルタを組み合わせることがあります。

導入時の注意点

RRFを導入するときは、検索結果の見た目だけで判断しないことが大切です。いくつかのクエリで良さそうに見えても、全体として改善しているとは限りません。代表的な質問セットを用意し、期待する文書が上位に入るか、不要な文書が増えていないか、既存の検索より悪化したケースはないかを確認します。

評価指標としては、Recall、Precision、MRR、NDCGなどが使われます。初心者にとっては指標名が難しく感じられるかもしれませんが、まずは「正解に近い文書が上位に来ているか」「上位数件に必要な文書が含まれているか」を見ることから始めるとよいでしょう。RAGでは、検索指標だけでなく、最終回答が正しいか、根拠文書が適切かも確認する必要があります。

もう一つの注意点は、チャンク分割です。RAGでは長い文書を小さなチャンクに分けて検索することが多いですが、チャンクが短すぎると文脈が不足し、長すぎると検索の焦点がぼやけます。RRFはランキングを統合するだけなので、チャンク設計の問題までは解決しません。検索器から返ってくる候補の単位が悪ければ、統合後のランキングも使いにくくなります。

重複もよくある問題です。同じ文書の近いチャンクが上位を占めると、LLMへ渡す情報が偏ります。RRFで統合した後に、同じ元文書からのチャンク数を制限したり、近い内容のチャンクをまとめたりする処理が必要になることがあります。単にRRFスコア順に上から取るだけでは、ユーザーにとって多様で有益な文脈にならない場合があります。

初心者が混乱しやすいポイント

初心者が混乱しやすい点の一つは、RRFを「検索モデル」と捉えてしまうことです。RRFは文書をベクトル化するモデルでも、キーワードに重みを付ける検索エンジンでもありません。複数の検索結果がすでにある前提で、それらをどうまとめるかを決める手法です。したがって、RRFを使う前には、検索結果を返す仕組みが必要です。

次に、RRFが意味理解をしているわけではない点も重要です。意味的に近い文書を見つけるのはベクトル検索やリランキングモデルの役割です。RRFは、それらが出した順位を受け取って統合します。RRFの出力が良いかどうかは、入力となるランキングの質に大きく依存します。

また、「RRFを入れればRAGの幻覚がなくなる」と考えるのも誤解です。RRFによって関連文書を拾いやすくなることはありますが、LLMが文脈をどう使うか、回答時に根拠を守るか、曖昧な質問にどう対応するかは別の問題です。RRFはRAGの検索段階を改善する部品であり、回答生成の安全性や正確性を単独で保証するものではありません。

RRFと関連用語の整理

RRFを理解するには、周辺用語との違いを整理しておくと便利です。特に、ハイブリッド検索、ベクトル検索、BM25、リランキング、クエリ拡張は一緒に出てきやすい用語です。

この表から分かるように、RRFは単独で検索のすべてを担うものではありません。BM25やベクトル検索が候補を作り、RRFがそれらを統合し、必要に応じてリランキングが最終順位を調整します。RAGでは、その後にLLMが回答を生成します。どの部品がどの役割を持つのかを分けて考えると、トラブルシューティングもしやすくなります。

実務での設計例

社内文書検索を例に、RRFを使う構成を考えてみます。まず、文書を段落や見出し単位でチャンク化し、全文検索用のインデックスとベクトル検索用のインデックスを作ります。ユーザーが質問を入力したら、全文検索で上位50件、ベクトル検索で上位50件を取得します。次に、文書IDまたはチャンクIDをキーにして候補を統合し、RRFスコアを計算します。

統合後は、上位20件程度をリランキングに渡すか、メタデータで絞り込みます。たとえば、部署、公開範囲、更新日時、文書種別などの条件を使います。最終的にLLMへ渡すのは、重複を除いた数件のチャンクです。このとき、同じ文書から近いチャンクばかりを渡さないようにする工夫も必要です。

この構成では、RRFは候補生成と最終回答生成の間にある中間処理です。ユーザーからは見えませんが、回答の根拠にどの文書が選ばれるかに影響します。検索精度を改善したいときは、RRFの有無だけでなく、全文検索の設定、埋め込みモデル、チャンク分割、候補件数、リランキング、プロンプトのすべてを分けて評価すると原因を見つけやすくなります。

RRFを学ぶときの実践的な順番

RRFを学ぶときは、最初から数式だけを追うより、検索結果の表を作って手計算してみる方が理解しやすいです。まず、キーワード検索の上位5件とベクトル検索の上位5件を用意します。次に、同じ文書がどちらのリストに出ているかを確認します。そして、順位が上の文書ほど大きく加点されることを見ながら、合計スコアで並べ替えます。

その後、kを変えると順位がどう変わるか、候補件数を増やすとノイズが増えるか、片方の検索器だけに重みを付けるとどうなるかを試します。実際のデータで試すと、RRFが強い場面と弱い場面が見えてきます。特に、用語一致が重要なクエリと、自然文の言い換えが重要なクエリでは、効果の出方が変わります。

学習段階では、RRFを「順位を足し合わせる便利な方法」とだけ覚えるのではなく、「異なる検索器のスコアを直接比べにくいとき、順位を共通の手がかりとして使う方法」と理解すると応用しやすくなります。この理解があると、なぜハイブリッド検索やRAGでRRFが選ばれるのか、どの場面で別の方法を検討すべきかも判断しやすくなります。

まとめ

RRF(Reciprocal Rank Fusion)は、複数の検索結果ランキングを順位にもとづいて統合する手法です。キーワード検索とベクトル検索のように、スコアの尺度が異なる検索器を組み合わせるときに扱いやすく、ハイブリッド検索やRAGの候補文書選定でよく使われます。

RRFの大きな特徴は、元のスコアを直接比較せず、各検索器の中での順位を使うことです。これにより、スコア正規化の難しさを避けながら、複数の検索器の強みを統合できます。複数の検索器で上位に出る文書は高く評価され、一方の検索器だけが見つけた有用候補も残しやすくなります。

一方で、RRFは万能ではありません。元の検索結果が悪ければ、統合しても良い結果にはなりません。RAGで使う場合も、チャンク分割、候補件数、重複除去、メタデータ、リランキング、回答評価とセットで設計する必要があります。RRFは検索品質改善の強力な部品ですが、検索システム全体の中で役割を理解して使うことが大切です。

更新履歴