ハイブリッド検索とは｜キーワード検索(BM25)とベクトル検索を組み合わせてRAGの取りこぼしを減らす

RAGの検索が「意味は近いのに、肝心の型番や製品コードで指定した文書を拾えない」とつまずくことがあります。原因の多くは、ベクトル検索とキーワード検索の得手不得手のミスマッチです。ハイブリッド検索(hybrid search)は、この2つを同時に走らせて候補を集め、ひとつのランキングに統合することで取りこぼしを減らす仕組みです。この記事では、なぜ単独の検索では抜けが出るのか、スコアの異なる2つの結果をどう統合するのか(RRFがなぜ扱いやすいのか)、そしてretrieve->fuse->rerankの流れと運用コストまでを、実務で判断できる粒度で整理します。

なぜ単独の検索だと取りこぼすのか#

RAGの検索でよく使われるのがベクトル検索(デンス検索)です。文書と質問をそれぞれ埋め込みベクトルに変換し、意味的に近いものを引きます。「解約したい」と「退会の手続き」のように語が違っても意味が近ければ拾える、言い換えや同義に強いのが最大の利点です。

一方で、ベクトル検索には弱点があります。文書を意味の空間に圧縮するため、「型番XR-200」「エラーコードE04」「略語のSLA」といった、字面そのものが重要な完全一致の検索が苦手です。似た型番や関連する概念に引っ張られ、狙った一件を確実に上位へ持ってこられないことがあります。

ここで力を発揮するのが、BM25に代表されるキーワード検索(スパース検索)です。BM25は語の出現頻度をもとにスコアを付ける古典的な手法で、指定した語が実際に含まれる文書を素直に高く評価します。型番・固有名詞・IDのような完全一致にはめっぽう強い反面、「解約」と「退会」を別物として扱うため、言い換えや同義語には弱いという、ベクトル検索とちょうど裏返しの性質を持ちます。

ハイブリッド検索の基本的な流れ#

ハイブリッド検索は、この2つを二者択一にせず両方走らせます。Weaviateのドキュメントでは、ベクトル検索とキーワード(BM25)検索を並行して実行し、両方の結果セットを融合(fusion)アルゴリズムでひとつのリストにまとめる、と説明されています。おおまかな流れは次の三段です。

要は、取得の段でネットを二重に張り、拾える母数を増やしてから絞り込む、という発想です。ベクトル検索の意味理解とキーワード検索の正確な語一致、その両方を活かせるのがハイブリッド検索の核心です。

スコアの統合はなぜ難しいのか#

2本の候補リストを1本にまとめるとき、最初にぶつかる問題がスコアの互換性です。BM25のスコアには上限がなく、ベクトル検索の類似度は使う距離指標によって決まった範囲に収まります。例えばMicrosoftのAzure AI Searchのドキュメントでは、full-text検索(BM25)は上限なし、ベクトル検索(コサイン)は0.333〜1.00といった具合に、算出アルゴリズムごとにスコアの範囲と桁が異なると説明されています。

範囲も桁も違う2つのスコアをそのまま足し引きすると、片方の大きな値に全体が引きずられます。Qdrantのドキュメントも、生スコアに固定の重み(alpha)をかける方式は、生の値が大きいほうの検索器に支配されがちだと指摘しています。だからこそ、なんらかの形で土俵をそろえる必要があります。統合方式は大きく2系統に分かれます。

RRF(順位ベースでスケール非依存)#

RRF(Reciprocal Rank Fusion)は、スコアの値そのものを捨て、順位だけを使う方法です。各リストで文書の順位rを見て、1/(rank+k)という逆数スコアを与え、複数リストにまたがって出てくる文書のスコアを合算します。kは下位の影響を抑える定数で、Azureのドキュメントでは60のような小さな値でよく機能する、と紹介されています(この定数は近傍数のkとは別物です)。

RRFの強みは、スコアの分布を知らなくてよいことです。BM25とコサイン類似度の桁が違っても、順位という共通の物差しに変換してから統合するため、面倒な正規化なしにスケールの不一致を回避できます。複数の検索で上位に共通して現れる文書ほど高く評価される、直感にも合った挙動です。

スコア正規化・重み付き結合#

もうひとつの系統は、スコアを0〜1などに正規化してから足し合わせる方法です。Weaviateは融合アルゴリズムとして、順位ベースのranked fusionと、スコアを正規化して足すrelative score fusion(新しめのバージョンでは既定)の2つを提供しています。正規化方式では、ベクトルとキーワードのどちらをどれだけ重視するかを重み(Weaviateではalphaパラメータ)で調整できます。生スコアの情報を活かせる反面、分布の前提に結果が左右されやすい面もあります。

ハイブリッド検索とリランキングの違い#

混同されやすいのが、ハイブリッド検索とリランキング(reranking)の関係です。この2つは動く段が違います。

ハイブリッド検索は取得段(retrieve)の工夫です。複数の検索方式で候補を集め、その結果を統合して1本のランキングにします。目的は、単独の検索では抜ける候補を取りこぼさず母数に含めることです。

リランキングは取得後の工夫です。取得段が返した候補集合を、Cross-Encoderのような重いモデルで関連度を測り直し、上位を並べ替えます。目的は、拾えている候補の中で本当に関連する少数を精密に上へ押し上げることです。

つまり両者は競合ではなく補完関係です。ハイブリッド検索で取得段の再現率を上げて正解を候補に含め、リランキングでその候補を精密に並べ替える、という二段構成が現実的な組み合わせになります。取得段で拾えていない文書はリランカーでは救えないので、まず取り逃さないハイブリッド検索が土台として効きます。リランキング側の詳細は別記事で扱っています。

向く場面・過剰な場面#

ハイブリッド検索は強力ですが、常に入れるべきものではありません。判断の軸を整理します。

向いているのは、質問に固有名詞・型番・製品コード・エラーコード・略語などが混じり、かつ言い換えや自然文の質問も来る用途です。製品サポート、社内ナレッジ、技術文書、法令・規程の検索などは、完全一致と意味理解の両方が必要になりやすく、ハイブリッドの恩恵を受けやすい領域です。

一方、対象が小規模だったり、決まった言い回しのFAQ的な用途では、ベクトル検索単独やキーワード検索単独で十分なことも多く、ハイブリッド化が過剰になり得ます。まず単独で評価し、取りこぼしのパターンを確認してから、補うために足すという順序が健全です。

運用コストの見積もり#

導入前に見ておきたいのが運用コストです。ハイブリッド検索は2系統の検索を維持するため、単独構成より手間が増えます。

• インデックスの二重保守: ベクトルインデックスとキーワード(転置)インデックスの両方を持ち、文書更新時に両方を同期させる必要があります。片方だけ更新が漏れると結果がずれます。
• レイテンシ: 2つの検索を走らせて統合するぶん、単独よりも応答は重くなりがちです。並列実行で緩和できますが、統合やリランクを重ねるほど遅延は積み上がります。
• チューニングの手間: 統合方式(RRFか正規化か)、重み、各系統で拾う件数といったパラメータが増えます。増えたぶんは評価セットで測って決める必要があります。

土台として効くのがチャンク分割です。ひとつのチャンクに複数の話題が混ざっていると、ベクトルもBM25もスコアが割れて統合の質が下がります。意味のまとまりで適切に区切れているほど、両系統が素直にスコアを付けられます。検索側の改善は積み重ねで効くと考えるのが現実的です。

各ベクトルDBが提供する融合アルゴリズムの種類・既定値・パラメータ名(alphaやk、既定のfusion方式など)は、製品やバージョンによって異なり、更新もされます。実装前に利用するベクトルDBの公式ドキュメントで現行の仕様を確認してください。この記事の数値例(RRFのk=60など)は各ドキュメントの説明値で、最適値は構成依存です。

よくある質問#

まとめ#

ハイブリッド検索は、ベクトル検索とキーワード検索という得手不得手が裏返しの2つを取得段で統合し、単独では抜ける候補を拾い直す仕組みです。統合ではスコアのスケール差が壁になりますが、順位だけを使うRRFなら正規化なしで扱え、まず試す一手として現実的です。ただし2系統の保守やレイテンシというコストは確実に増えるため、単独での評価を出発点に、取りこぼしを補う目的で足すのが筋です。取得段のハイブリッドと取得後のリランキング、そして土台のチャンク分割を切り分けて押さえると、RAGのどこを直せば効くのかの見通しが良くなります。