ハイブリッド検索とは｜BM25とベクトル検索をRRFで統合する方法

ハイブリッド検索とは｜2つの検索方式を1つのランキングに束ねる

結論として、ハイブリッド検索は「性質の違う2つの検索器を並べて走らせ、結果を混ぜる」だけの仕組みです。新しい検索アルゴリズムではありません。条件は、両者のスコアを直接比較しないこと。例外的に、同一スケールに正規化できる場合は値ベースの統合も選べます。

BM25（キーワード検索）が得意なこと・苦手なこと

BM25は、クエリ語の出現頻度と文書長から関連度を算出する古典的なランキング関数です。語が一致していれば強く、一致していなければスコアが付きません。ただしこれはBM25という関数単体の話で、検索システム全体としてはアナライザの切り方・同義語展開・クエリ拡張の設計次第で挙動が変わります。

得意なのは、型番・エラーコード・関数名・社内の固有名詞。「ORA-01555」や「NullPointerException」のような文字列は、ベクトル化すると意味が潰れて近傍に埋もれます。BM25ならピンポイントで拾えます。

苦手なのは言い換えです。「退職金」で検索したとき、本文が「勤続慰労金」としか書いていなければヒットしません。

ベクトル検索（密ベクトル）が得意なこと・苦手なこと

ベクトル検索は、文章を埋め込みモデルで数百〜数千次元のベクトルに変換し、距離が近いものを返します。語が一致していなくても意味が近ければ拾えます。

ただし、意味に寄せる性質が裏目に出るケースがある。固有名詞や数字は、埋め込み空間では「似たような何か」として丸め込まれやすく、「v2.3.1」と「v2.3.4」の区別が消えることもあります。社内用語や造語のように、学習データに存在しない語はさらに不利です。

なぜ併用すると取りこぼしが減るのか

両者の失敗パターンが重ならないからです。BM25が落とすのは言い換え、ベクトルが落とすのは固有名詞。片方が0点でも、もう片方が上位に入れていれば、融合後のランキングに残ります。

このあたりの前提となるRAGの全体像は『RAGとは？仕組み・活用事例・導入メリットをわかりやすく解説』で押さえられます。

スコア統合の2方式｜順位ベースと値ベース

結論から言うと、順位ベース（RRF）が初手の推奨です。条件は「ラベル付きの評価データがまだ無いこと」。例外として、両リトリーバのスコア分布を把握できていて、重み調整で伸ばしたい段階に来ているなら値ベースを選びます。

理由は尺度の非互換です。MicrosoftのHybrid Search Scoring (RRF) - Azure AI Searchでも、全文検索のBM25スコアは「上限なし」、ベクトル検索（HNSW・コサイン）は「0.333〜1.00」と明記されています。レンジが違う数字をそのまま足せば、BM25側が常に支配します。

RRFの計算式とk定数

RRFは、スコアを捨てて順位だけを見ます。各リトリーバの結果リストで文書dが何位だったかを取り、1/(k + rank)を全リスト分足し合わせるだけです。

Elastic公式のReciprocal rank fusionでは、ランク定数のデフォルトは60、1以上の値を取ると定義されています。Azure AI Searchも「実験上、kを60程度の小さい値にすると最も性能が良い」としています。

kの役割は平滑化です。kを小さくすると上位の重みが極端に効き、1位の文書がほぼ決定的になります。kを大きくすると順位差がならされ、どちらのリストにも顔を出す文書が有利になります。

注意したいのは、プラットフォームによって既定値が違うこと。Hybrid Queries - QdrantのRRFは定数k=2を採用しており、Elasticの60とは挙動が大きく変わります。移植するときは数式ごと確認してください。

スコア正規化方式（min-max・相対スコア融合）

値ベースは、各リトリーバのスコアを0〜1に正規化してから重み付きで足す方式です。順位では潰れてしまう「どれくらい強く一致したか」を残せます。

Hybrid search | OpenSearch Documentationは、正規化と結合をパイプラインのプロセッサとして分離し、算術平均・幾何平均・調和平均などの結合手法を選べる設計になっています。WeaviateはHybrid search | Weaviate Documentationのとおり、v1.24以降のデフォルトがRelative Score Fusionで、alphaパラメータ（1でベクトルのみ、0でキーワードのみ）で比重を振ります。

どちらを選ぶかの判断基準

ミニFAQ：kを60から動かすべきタイミングは？ 評価セットでRecall@10は十分なのにnDCGが伸びない、つまり「正解は拾えているが順位が低い」ときです。kを20〜30程度まで下げると上位が締まるケースがあります。

ミニFAQ：RRFだとスコアの絶対値が小さくなるが問題ないか？ 融合後のスコアは相対順位のための値で、関連度の強さを表しません。しきい値カットに使うなら、RRFスコアではなく融合前のスコアで足切りします。

実装パイプラインの標準形

結論として、実装は「並列取得 → 融合 → 絞り込み」の3段です。条件は、各段の件数を別々に管理すること。例外として、ドキュメント数が数千件規模なら融合だけで十分な場合もあります。

1. クエリを受け取り、BM25検索とベクトル検索を並列に実行する

2. 各リトリーバから候補を50〜200件取得する

3. RRFまたは正規化で1本のランキングに融合する

4. （任意）クロスエンコーダ（クエリと文書をペアで入力し関連度を再計算するモデル）のリランカーで上位を並べ替える

5. 最終的に5〜12チャンクをLLMのコンテキストへ渡す

各リトリーバの取得件数（top-k）の決め方

ここが最も事故りやすい箇所です。最終的に10件使うからといって、各リトリーバで10件しか取らないと、融合する意味がほとんど無くなります。

目安は最終件数の10〜20倍。最終10件なら各100〜200件です。Elasticのrank_window_sizeは既定でsizeパラメータと同じ値になるため、明示的に広げないと融合の効果が出ません。Azure AI Searchはテキスト側の既定上限が1,000件（maxTextRecallSize）です。

候補数を増やすとレイテンシとメモリが増えます。50件から始めて、評価セットのRecallが頭打ちになる点を探すのが堅実です。

重み付けを入れるべきケース

デフォルトは等重みで構いません。重みをいじるのは、ドメインが明確に片方へ偏っているときだけにします。

• 社内ドキュメント検索で型番・品番の照会が大半を占める → BM25側を重く

• FAQ検索で利用者が自由な言い回しで聞いてくる → ベクトル側を重く

• 両方が混在する一般的な社内RAG → 等重みのまま

Azure AI Searchは、ベクトルクエリ側にweight（既定1.0）を掛けてからRRFに渡す設計です。Weaviateはalpha、Qdrantはv1.17.0以降のRRF重み付けで同等のことができます。

リランキングとの役割分担

融合は「候補を広く集める」ための処理、リランキングは「集めた候補の順番を精密に直す」ための処理です。役割が違うため、一方をもう一方で置き換えても同じ効果は得にくくなります。

ハイブリッド検索で取りこぼしを減らし、リランカーで上位の精度を上げる。この二段構えが現在よく採られる構成です。リランカーのモデル選択や候補件数の決め方は『リランキング（Rerank）とは｜RAGの検索精度を上げる仕組みと実装』に委ねます。

主要プラットフォーム別の対応状況

以下は2026年10月時点で各公式ドキュメントから確認した内容です。既定値や対応状況はバージョンで変わるため、採用前に利用中のバージョンのドキュメントで確認してください。

pgvectorで組む場合は融合処理が自前になるため、設計の前提を『pgvectorとは｜PostgreSQLでベクトル検索を実装する仕組みと導入手順』で確認しておくと手戻りが減ります。BM25側をElasticsearchに寄せる構成なら『Elasticsearchとは？全文検索エンジンの仕組み・ELKスタック・案件単価をフリーランス視点で解説』が参考になります。

ミニFAQ：既存のベクトル検索にBM25を足すのと、全文検索基盤にベクトルを足すのでは、どちらが早い？ 既存の検索基盤がElasticsearchやOpenSearchなら後者が速いです。アナライザとインデックスがすでにあり、追加するのはベクトルフィールドと融合設定だけで済みます。

日本語でハイブリッド検索を組むときの注意点

日本語は分かち書きをしないため、BM25側の設定が精度を左右します。ここを放置したままハイブリッド化しても、キーワード側がほとんど機能しません。

形態素解析とN-gramの使い分け

形態素解析（kuromoji等）は意味の単位で切るため、検索結果のノイズが少なくなります。一方で、辞書に無い新語や社内用語は不自然に分割されます。

N-gram（2〜3文字単位）は辞書に依存せず、未知語に強い代わりにノイズが増えます。実務では両方のフィールドを持ち、どちらもBM25で引いて融合対象に加える構成も採られます。

表記揺れ・同義語辞書

「サーバ」と「サーバー」、「ユーザ」と「ユーザー」のような長音の揺れは、BM25では別語になります。ベクトル検索側が吸収してくれる事もありますが、頼り切るのは危険です。同義語辞書を整備して正規化しておきます。

全角・半角、英数字の大文字小文字も同様に正規化対象です。

スパースベクトルという選択肢

BM25の代わりに、SPLADEやBM42のような学習済みスパースベクトルを使う手もあります。語の重みをモデルが学習するため、BM25より言い換えに強くなります。

ただし推論コストが増え、モデルの日本語対応状況も確認が必要です。BM25で足りているなら、まずはそちらで始めるほうが運用は軽くなります。

効果を測る｜導入前後で何を比較するか

結論として、ハイブリッド化は必ず改善するとは限りません。条件は、評価セットを先に作っておくこと。例外として、キーワード一致が明らかに重要なドメイン（法務・医療のコード検索など）では高確率で効きます。

評価データセットの作り方

社内RAGやFAQ検索のような用途であれば、実際のユーザークエリから50〜100件程度を抜き、それぞれに正解ドキュメントを紐づけるところから始められます。必要な件数は対象ドキュメントの多様性で変わるため、クエリの種類が広いドメインではより多く要ります。合成クエリだけで作ると、本番の言い回しと乖離しやすくなります。

ログが無い立ち上げ期なら、想定利用者にクエリを書き出してもらう方法が現実的です。1人あたり10件ほど出してもらえば、5人で50件になります。

見るべき指標

• Recall@k：正解が上位k件に入っているか。ハイブリッド化の効果が最も出やすい指標

• nDCG@k：正解が上位にあるほど高く評価するランキング指標。順位の良し悪しを見る

• レイテンシ：並列実行と候補数増加の代償。p95で見る

評価指標の詳しい見方とボトルネックの切り分けは『RAGの評価方法｜Ragasの評価指標とボトルネック特定・精度改善』で整理しています。

導入チェックリスト

着手前に、この順で潰しておくと手戻りが減ります。

8番は見落とされがちです。チャンクが大きすぎるとBM25もベクトルも精度が出ません。『RAGのチャンク分割｜サイズ・オーバーラップの決め方と検証手順』を先に確認しておくと、融合の調整に入る前に原因を切り分けられます。

よくある失敗と対策

失敗1：2つのスコアをそのまま足す

最頻出の事故です。BM25スコアは上限が無いため、レンジの狭い類似度スコアと素朴に足すとBM25側が支配し、ベクトル検索が実質無効になります。順位ベースにするか、正規化してから足します。

失敗2：候補件数が最終件数と同じ

各リトリーバで10件しか取らずに10件返すと、融合する余地がありません。両者が同じ文書を返していれば何も変わらず、違う文書を返していれば片方が丸ごと落ちます。

失敗3：常にハイブリッドが勝つ前提で入れる

クエリが自然文中心で、固有名詞がほとんど出てこないドメインでは、ベクトル単独と差が付かないケースもあります。レイテンシとインフラコストだけ増えて終わることを避けるため、ベースラインの計測を先にやります。

失敗4：融合のパラメータをプラットフォーム間で使い回す

ElasticのRRFはk=60、Qdrantはk=2。同じ「RRF」でも挙動が違います。移行時は数式と既定値を公式ドキュメントで確認してください。

フリーランス案件でこの知見はどう見られるか

RAG構築の案件では、「ベクトル検索を動かしたことがある」より「精度が出なかったときに切り分けられる」ほうが評価されやすい部分です。ハイブリッド検索は、その切り分けの引き出しの1つとして聞かれる事があります。

面談で踏み込まれやすいのは、次のような論点です。

• 融合方式を選んだ理由を説明できるか（RRFか正規化か、なぜそちらか）

• 候補件数とレイテンシのトレードオフをどう決めたか

• 日本語アナライザの設定経験があるか

• 評価セットを自分で作った経験があるか

RAG構築案件そのものの単価レンジや求められるスキルセットは『RAG構築案件の実情｜単価相場・必要スキル・獲得方法』に整理してあるため、そちらを参照してください。自分の経験がどの程度の市場評価になるか知りたい方は、無料のフリーランスエンジニア単価診断で目安を確認できます。実際の募集内容はAIエンジニアの案件一覧から見られます。

まとめ

ハイブリッド検索は、BM25とベクトル検索を並列に走らせて1本のランキングに束ね、互いの取りこぼしを埋める方式です。迷ったらRRF、k=60から始めれば大きく外しません。

• 統合方式は順位ベース（RRF）と値ベース（正規化）の2択。スコアの素の足し算は成立しない

• RRFのk定数はElasticが60、Qdrantが2。プラットフォーム間で既定値が違う

• 各リトリーバの取得件数は最終件数の10〜20倍を目安に広げる

• 日本語ではアナライザと同義語の整備がBM25側の前提になる

• 評価セット50件以上を先に用意し、ベクトル単独のベースラインと比較する

• ハイブリッドで取りこぼしを減らし、順位はリランカーで詰める二段構えが扱いやすい

次に手を動かすなら、まず評価セットを50件作ってベクトル単独の数字を取ってください。比較対象が無いまま融合を入れると、チューニングの判断ができなくなります。

参照した一次情報：

• Reciprocal rank fusion（Elastic公式）

• Hybrid Search Scoring (RRF) - Azure AI Search（Microsoft Learn）

• Hybrid search | OpenSearch Documentation

• Hybrid search | Weaviate Documentation

• Hybrid Queries - Qdrant