RAG 06：ハイブリッド検索 ― キーワードと意味を合わせる

キーワード検索は「巻末の索引」

キーワード検索は、質問に含まれる言葉が文字どおり載っている文書を探す方法です。Web 検索やサイト内検索で、昔から使われてきました。

でも、質問のたびに全部の文書を頭から読んで、言葉を探すわけではありません。前もって、本の巻末の索引のようなものを作っておきます。

これを転置索引（インバーテッドインデックス）と呼びます。普通は「文書 → そこに載っている言葉」ですが、それを逆（転置）にして「言葉 → それが載っている文書」にしたものです。

質問が「E-4012 の申請」なら、索引で「E-4012」と「申請」を引けば、候補の文書がすぐにそろいます。全文書を読む必要はありません。何百万件の文書でも、一瞬で候補が出せます。

ちなみに、第5章の IVF の「I」も Inverted（転置）です。「区画 → そこに入っている点」の一覧を持つ、という同じ発想から名前が来ています。

BM25：どの文書をより上に並べるか

索引で候補の文書がそろったら、次は並べる順番です。キーワード検索で最もよく使われる並べ方が BM25 です。名前は「Best Matching（いちばんよく合う）」の略に、試した計算式の通し番号 25 が付いたものです。文書ごとに「質問とどれだけ合っているか」の点数（スコア）を出し、点数の高い順に並べます。

BM25 は 1990年代に、ロンドン市立大学の Okapi という検索システムの研究から生まれました。数式は少し込み入っていますが、考え方は次の3つです。

1つ目の「珍しさ」の考え方は、昔から IDF（逆文書頻度）と呼ばれるものです。「その言葉が載っている文書が少ないほど大きくなる数」と思えば十分です。

BM25 の良いところは、学習が要らないことです。どんな分野の文書にも、そのまま使えます。速く、結果の理由も説明しやすい（「この言葉が一致したから」）。多くの検索エンジンで、いまも標準の並べ方になっています。

「古い技術」と思われがちですが、RAG の研究でも、BM25 は今でも強い比較相手として必ず登場します。特定の分野の専門用語が多い資料では、意味の検索に勝つことも珍しくありません。

意味の検索が苦手なもの：番号・名前・ぴったりの言い回し

改めて、意味の検索（ベクトル検索）が苦手なものを整理します。

図は、ベクトル検索の結果です。1位は「E-4013 の対処」、2位にやっと「E-4012 の対処」、3位は「障害時の連絡先」。どれも「エラーと対処」の話としては近いのですが、欲しい資料が1位ではありません。

今回はまだ2位に入っているので救いがあります。でも、似た番号のエラーが何十個もあれば、欲しい資料は圏外に落ちてしまいます。

「似ている」は「同じ」ではありません。意味の検索は、同じ話題の別物を上に持ってきやすいのです。

キーワード検索が苦手なもの：言い換え・表記ゆれ

では、キーワード検索だけで良いかというと、そうでもありません。キーワード検索にも、はっきりした弱点があります。文字が一致しなければ、見つからないのです。

第4章の最初の例、「休みはいつ取れる？」と「有給休暇の取得手続き」は、キーワード検索の弱点そのものです。

利用者は、資料に書かれている言葉を知りません。自分の言葉で質問してきます。キーワード検索だけだと、「言葉が合っている人だけが答えにたどり着ける」検索になってしまいます。

表記ゆれは、索引を作るときに正規化（全角・半角をそろえる、長音をそろえるなど）や同義語の辞書を使えば、ある程度は減らせます。でも、言い換えを全部辞書に書き出すのは現実的ではありません。

日本語の壁：単語の間に空白がない

キーワード検索を日本語で使うときには、もう1つ大きな壁があります。単語の間に空白がないことです。

英語なら、空白で区切れば単語になります。日本語の「東京都庁の休暇規程」は、どこで区切ればいいのでしょうか。索引を作るには、まず文章を言葉の単位（ここではこれをトークンと呼びます。索引の「言葉」の欄に載る1つ1つです）に区切らなければいけません。方法は大きく2つです。

図の n-gram を見てください。「東京都庁」を2文字ずつ区切ると、「京都」という区切りが出てきます。「京都」で検索すると、東京都庁の資料が当たってしまいます。

形態素解析の道具には MeCab、Sudachi、kuromoji などがあり、検索エンジンにはそれを組み込むための部品が用意されています。PostgreSQL の標準の全文検索は日本語の区切りに対応していないので、pg_bigm（2文字ずつの索引）や PGroonga といった拡張を使うのが一般的です。

実務では、「形態素解析を基本にして、社内用語を辞書に足す」「両方の索引を作って合わせる」など、資料に合わせて選びます。使う道具が日本語にどう対応しているかは、必ず最初に確かめてください。

ハイブリッド検索＝両方で探して、結果を合わせる

キーワード検索と意味の検索は、ちょうど弱点が逆です。

それなら、両方で探して、結果を合わせればいい。これがハイブリッド検索です。図のように、1つの質問で2つの検索を同時に走らせます。片方が外しても、もう片方が拾ってくれます。

仕組みは単純ですが、効果は大きく、いまの RAG では定番の構成になっています。多くの検索エンジンやベクトルデータベースが、ハイブリッド検索を組み込みの機能として持っています。

2つの検索は並行して走らせられるので、待ち時間はほぼ遅いほうの検索の時間だけです。

残る問題は1つです。2つの検索は、それぞれ別々の順位表を返してきます。キーワード検索では「E-4012 の対処」が1位、意味の検索では「E-4013 の対処」が1位。これをどうやって1つの順位表にまとめるか。次のページから見ていきます。

点数をそのまま足せない：物差しが違う

いちばん素直な案は、「それぞれの点数を足して、大きい順に並べる」です。でも、これはうまくいきません。点数の物差しが違うからです。

この2つをそのまま足すと、どうなるでしょうか。BM25 の点数の差（12.3 と 5.0 で 7 以上）に比べて、コサインの差（0.82 と 0.79 で 0.03）はごくわずかです。結果は、ほぼキーワード検索の順番そのままになります。意味の検索は、実質的に効いていません。

では、点数を 0〜1 に揃え直してから足せばいいのでは、と考えるかもしれません（正規化）。これも使われる方法ですが、「何を最大・最小として揃えるか」で結果が変わり、質問によって振る舞いが不安定になりがちです。

そこで広く使われているのが、点数を捨てて、順位だけを使う方法です。

RRF：点数を捨てて「順位」だけを使う

RRF（Reciprocal Rank Fusion、逆順位融合）は、2009年の論文で提案された、とても単純な合わせ方です。名前は「順位（Rank）の逆数（Reciprocal、1÷その数）を合わせる（Fusion）」という意味です。

やることは1つだけです。各検索の結果で、資料が何位だったかを見て、次の点数を足します。

点数 ＝ 1 ÷ (60 ＋ 順位)   を、出てきた検索の数だけ足す

読み下すと、「1位なら 1÷61、2位なら 1÷62……と、順位が下がるほど少しずつ小さくなる点をもらい、両方の検索に出てくれば2回分もらえる」です。表の「—」は、その検索の結果に出てこなかった（点をもらえない）という意味です。

図の例で計算してみます。

「E-4012 の対処」は、どちらの検索でも1位ではありません。でも、両方で上位だったので、合わせた点数はダントツです。

「60」という数は、上位どうしの差をなだらかにするための値です。60 だと1位と2位の差が小さく、「片方で1位」より「両方で上位」が強くなります。元の論文で良かった値で、いまもほぼそのまま使われています。

RRF の良さは、点数の物差しを気にしなくていいことです。BM25 が 12.3 でも 120 でも、コサインが 0.8 でも 0.3 でも、使うのは順位だけです。検索を3本、4本に増やしても、同じように足せます。

合わせた結果：両方で上位の資料が1位に

RRF で合わせた順位表が、図の右の列です。

欲しかった「E-4012 の対処」が1位になりました。キーワード検索の「ぴったり」と、意味の検索の「話題の近さ」の両方で支持されたからです。

同じ仕組みは、逆の場面でも働きます。「休みはいつ取れる？」のような質問では、キーワード検索はほとんど外しますが、意味の検索が「有給休暇の取得手続き」を上位に出します。RRF で合わせても、それは上位に残ります。どちらか一方が外す質問でも、もう一方が支えてくれるのです。

一方で、2位に「E-4013 の対処」が残っていることにも注目してください。ハイブリッド検索は「拾う」のは上手になりますが、細かい正しさの判断まではしてくれません。上位の候補を、質問と照らし合わせてもっと丁寧に並べ直すのが、次の第7章のリランキングです。

どちらを重く見るか：資料と質問の性質で決める

RRF では、それぞれの検索に重みを付けることもできます。1 ÷ (60 ＋ 順位) に、検索ごとの重みを掛けるだけです。たとえばキーワード検索の重みを 2、意味の検索を 1 にすると、キーワード検索でもらう点だけが2倍になり、キーワード検索で上位の資料が勝ちやすくなります。

どちらを重くするかは、資料と質問の性質で決めます。

質問の中身を見て、その場で重みを変える方法もあります。たとえば、質問にエラーコードや型番らしい文字列（英数字とハイフンの並びなど）が入っていたら、キーワードを重くする、といった具合です。第9章で見る「質問を直す」工夫と組み合わせることもできます。

どの場合も、勘で決めないことが大事です。実際に来る質問を集め、重みを変えながら「答えの載った資料が上位に入ったか」を数えて決めます（第12章）。

コードで見る：RRF は十数行

RRF は、図のように十数行で書けます。TypeScript の例です。

紛らわしいのですが、ここの k（＝60）は第5章の top-k の k（取り出す件数）とは別物です。RRF の式の「60」を入れる変数に、慣習で同じ文字が使われています。

ポイントは、それぞれの検索から多めに取ることです。コードではキーワード・意味の両方から50件ずつ取り、合わせた上位20件を次に渡しています。片方で51位の資料は、そもそも合流に参加できません。

検索エンジンやデータベースによっては、RRF が組み込みの機能として用意されています。その場合は、自分で書かずにそれを使えば十分です。ただ、中身がこれだけ単純だと知っておくと、結果がおかしいときに原因を追いやすくなります。

もう1つ、権限の絞り込み（第5章・第13章）は、両方の検索に必ず掛けてください。

よくある落とし穴と、かかる手間

ハイブリッド検索は効果が大きい一方で、手間も増えます。よくある失敗と合わせて整理します。

かかる手間は、主に「索引が2つになる」ことです。文書を足す・変える・消すたびに、両方を更新します。キーワード検索とベクトル検索が同じデータベースでできるなら（PostgreSQL＋日本語の全文検索の拡張＋pgvector など）、この手間はかなり減ります。

それでも、多くの場合、ハイブリッド検索の効果は手間に見合います。特に、型番・コード・固有名詞が多い業務の資料では、ほぼ必須と考えてよいでしょう。