モダンRAGのハイブリッド検索（BM25 + Embedding + RRF）の整理¶

作成日: 2026-06-29 出典 / きっかけ: Hatena Base「モダンRAGの常識が変わった｜BM25 + Embedding ハイブリッド検索が標準になった理由」(2026-04-18, https://hatenabase.jp/blog/modern-rag-hybrid-search-guide/) を起点に、RRF・BM25・各検索エンジンの一次資料で裏取りして体系化したもの関連: vectordb_recommendation_整理（同じ「埋め込み＋ANN」の道具立て・2段階ファネル）、context_engineering_ast活用

0. 要点（3行）¶

純ベクトル検索は「言い換え・類義語」には強いが「完全一致」に弱い — 型番 XG-7200A、エラーコード ERR_CONN_REFUSED、人名・固有名詞・引用文を取りこぼす。ここをキーワード検索（BM25）で補うのがハイブリッド検索で、2024〜2026年に主要エンジンの標準機能になった。
2つの検索結果は「絶対スコア」では足し算できない（BM25の点数とコサイン類似度はスケールが違う）。だから RRF（順位で多数決） で統合する。「点数を信じず、順位を信じる」が肝。
効きの順序は ① ハイブリッド（BM25+Embedding）→ ② リランカー追加。Anthropic の実測では検索失敗率が 5.7% → 2.9%（ハイブリッドで49%減）→ 1.9%（リランカー追加で67%減）。ただし万能ではなく、ドメインによっては +数% 程度しか伸びない（インデックス2本ぶんの運用コストと天秤）。

1. なぜ「純ベクトル検索だけ」だと失敗するのか¶

RAG（Retrieval-Augmented Generation）は「LLM に答えさせる前に、社内ドキュメントDBから関連箇所を引いてきて『これを根拠に答えて』と渡す」仕組み。この検索（Retrieval）の質がそのまま回答の質になる。

純ベクトル検索（embedding + 近似最近傍 ANN）の弱点は完全一致。埋め込みは意味の近さ（semantic similarity）を測るので、表記が少し違っても拾える反面、文字列としての厳密一致を保証できない。

クエリ	純ベクトル検索で起きがちな失敗
`ERR_CONN_REFUSED`	エラーコードそのものの記事でなく「ネットワーク一般」の記事が上位に来る
`XG-7200A`（型番）	似た型番 `XG-7100B` と意味的に近いと判断され混線する
人名・社名・引用文	「だいたい似た話題」を返し、その固有名詞ピンポイントを外す

直感: 埋め込みは「意味のご近所さん」を探す道具。だから「字面がまったく同じ一点」を確実に当てる用途には向かない。そこは昔ながらのキーワード検索の領分。

2. BM25（キーワード検索）とは — 何が得意で、なぜ今も現役か¶

BM25（Okapi BM25, BM = Best Matching） は、クエリ語が文書中に何回出るか（語の頻度 TF）と、その語の希少性（IDF）、文書長による正規化を組み合わせて関連度をスコアする確率的ランキング関数。

理論的土台は Robertson & Spärck Jones「Relevance weighting of search terms」(1976) に遡る確率的検索フレームワーク。
「BM25」という具体形が定着したのは Robertson & Walker (SIGIR 1994) と "Okapi at TREC-3" (1994, ロンドン City University の Okapi システム）。
※ 出典ブログは「1990年代に開発」とするが、正確には理論は1970年代、BM25の確立は1990年代前半。
30年経った今も Elasticsearch / Lucene 系のデフォルトスコアラとして現役。理由は単純で、完全一致を確実に拾うという、ベクトル検索が苦手な仕事をローコストでこなすから。

	ベクトル検索（Embedding）	キーワード検索（BM25）
得意	言い換え・類義語・意味的な近さ	固有名詞・型番・エラーコード・引用文の完全一致
苦手	字面の厳密一致	表記ゆれ・同義語・文脈
スコアの性質	コサイン類似度など（0〜1付近）	語頻度ベース（上限なし・文書集合依存）
計算	事前に埋め込み → ANN で近傍探索	転置インデックスで語をマッチ

この2つは弱点が綺麗に裏返しになっている。だから「両方走らせて混ぜる」と良いとこ取りができる、というのがハイブリッド検索の発想。

3. ハイブリッド検索のスコア統合：RRF（Reciprocal Rank Fusion）¶

2つの検索を走らせると、ランキングが2本できる。問題はどう1本に混ぜるか。

ナイーブに「BM25スコア + コサイン類似度」と足すのはダメ。両者はスケールも分布も違う（BM25は上限なし、コサインは0〜1付近）。重み付け加重和（convex combination）はチューニングが要るうえ、ドメインが変わると壊れやすい。

そこで使うのが RRF（Reciprocal Rank Fusion）。絶対スコアを捨て、順位（rank）だけで足し合わせる。

RRF(d) = Σ_m  1 / (k + rank_m(d))

  d        : ある文書
  m        : 各検索手法（BM25, ベクトル, …）
  rank_m(d): 手法 m の結果での d の順位（1位, 2位, …）
  k        : 平滑化定数（既定 60）

       BM25 の結果          ベクトルの結果
       ─────────           ─────────
  1位  docA                 1位  docC
  2位  docB        ──RRF──▶ 2位  docA      ⇒ docA は両方で上位
  3位  docC                 3位  docE         → 合算スコアが高くなり最終上位へ

  docA = 1/(60+1) + 1/(60+2) = 0.01639 + 0.01613 = 0.03252  ← 両リストで上位
  docC = 1/(60+3) + 1/(60+1) = 0.01587 + 0.01639 = 0.03226

両方の検索で上位に出る文書ほど合算スコアが高くなる＝「順位での多数決」。
k（既定 60）は、1位だけが極端に強くなりすぎるのを抑える平滑化項。Cormack, Clarke, Büttcher「Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods」(SIGIR 2009) で k=60 が多くのベンチで頑健と示され、以後の事実上の標準値。
利点: スケール非依存・チューニング不要・実装が1行。だから各社が標準採用しやすかった。

一言で: RRF は「点数を信じず、順位で多数決」。スコアの単位がバラバラでも、順位なら公平に混ぜられる。

4. リランカー（2段階検索） — ハイブリッドの「後段」¶

ハイブリッドで候補を集めたあと、さらに精度を上げる層がリランカー（reranker）。RAGの定石は2段階検索:

 ① 1段目: ハイブリッド検索（BM25+ベクトル+RRF）
      └ 広く浅く。候補を 50〜100 件ざっくり取る（recall 重視・速い）
                │
                ▼
 ② 2段目: リランカー（cross-encoder）
      └ クエリと各候補を「一緒に」モデルへ入れて精密採点 → 上位 10 件に絞る（precision 重視）

bi-encoder（1段目の埋め込み）: 文書とクエリを別々にベクトル化 → 近傍探索。事前計算でき高速だが、クエリと文書の語が直接相互作用しないので「だいたい同じ話題」までしか測れない。
cross-encoder（リランカー）: クエリと文書をペアで同時にモデルへ入れて関連度を1スコア出す。精度は高いが、クエリ時に候補数ぶん推論するので重い（だから候補を絞った後段でだけ使う）。
代表例: Cohere Rerank（cross-encoder を API 提供。任意の1段目の上に載せる）。一般的な運用は「50〜100件取って10件にリランク」、追加レイテンシは標準GPUで概ね +50〜100ms 程度とされる。

5. Anthropic「Contextual Retrieval」— 数字で見る積み上げ効果¶

「ハイブリッド＋リランカーがどれだけ効くか」を最もきれいに数値化した一次資料が Anthropic「Contextual Retrieval in AI Systems」(2024)。各チャンクに文脈情報を付与（Contextual Embeddings / Contextual BM25）したうえで、top-20 チャンクの検索失敗率を測った。

手法	検索失敗率	ベースfrom 5.7%
ベースライン（埋め込みのみ）	5.7%	—
Contextual Embeddings のみ	3.7%	35% 減
＋ Contextual BM25（＝ハイブリッド化）	2.9%	49% 減
＋リランカー	1.9%	67% 減

読み取れること（事実）: - BM25をembeddingに足すだけで 35% → 49% 減と、はっきり上乗せがある（＝ハイブリッドの効果）。 - リランカーを足すとさらに 49% → 67% 減。3つを積むと最大効果。 - ただしこれは Anthropic のデータセットでの値。自分のドメインでの伸びは要実測（次節）。

6. 主要エンジンの対応状況（2024〜2026で標準化）¶

ハイブリッド検索＋RRF は、もはや自前実装する機能ではなく、各プラットフォームの組み込み機能になっている（出典ブログの主張は一次docsで概ね裏取りできる）。

エンジン	ハイブリッド検索	融合アルゴリズム
Azure AI Search	標準	RRF（k=60）（公式docsに明記）
Elasticsearch	標準（`rrf` リトリーバ）	RRF
Weaviate	標準（`hybrid` クエリ）	RRF / relative score
Qdrant	標準（Query API の fusion）	RRF など
Vertex AI Search	標準	内部融合

含意: 「ハイブリッドにするか」はもう実装難易度の問題ではない。設計判断（後述）と、インデックス2本ぶんの運用コストをどう受け入れるかの問題に移った。

7. いつハイブリッドにすべきか — 早見表とコスト¶

全部ハイブリッドにすればいい、ではない。 完全一致が効くデータかどうかで判断する。

状況 / データの性質	推奨	理由
エラーメッセージ・ログ・型番・SKU を検索	ハイブリッド必須	完全一致が命。純ベクトルは外す
法務・コンプラ・契約書（条番号・固有表現）	ハイブリッド推奨	引用・条文の厳密一致が要る
顧客名・社名・人名で引く	ハイブリッド推奨	固有名詞の取りこぼし防止
自然文の「意味で探す」FAQ・ナレッジ	ベクトル中心で可	言い換え耐性が主目的。BM25の上乗せは小さいことも
高精度が要る本番RAG	ハイブリッド＋リランカー	§5の通り積み上げが効く

コスト面の注意（事実 + ブログ主張）: - インデックスを2本（転置 + ベクトル）持つぶん、ストレージと更新・運用コストが増える。 - 出典ブログは「あるECデータセットでは精度向上が +1.7% に留まった例」を挙げる（＝ドメインによっては伸びが小さい）。 - ※ この +1.7% という数値の一次ソースはブログ内に明記されておらず未確認。傾向（ECの商品名検索などでは上乗せが小さいことがある）は妥当だが、数値そのものは鵜呑みにしない。 - 結論: まず自分のデータで A/B 実測（純ベクトル vs ハイブリッド vs ＋リランカー）してから採否を決める。

8. ベンダー / ライブラリ評価の5つの質問¶

RAG基盤や検索SaaSを選ぶとき、出典ブログが挙げる確認観点（実務的に妥当）:

検索方式 — キーワード／ベクトル／ハイブリッドのどれに対応？ハイブリッドは標準か追加か。
融合アルゴリズム — RRF か、加重和か。k やweightを調整できるか。
リランカー — cross-encoder リランクを組み込めるか（自前 or Cohere等の外部API）。
チャンク分割戦略 — 長文をどう区切るか。文脈付与（contextual chunking）に対応するか。
定量評価 — MRR / NDCG / Recall@k など retrieval 指標で測れるか（＝改善を数字で言えるか）。

④⑤が言える基盤かどうかが分かれ目。「検索が良くなった」を指標で示せない基盤は、改善ループが回らない。

N. まとめ — 一言で / いつ使うか¶

モダンRAGの検索層の定石 = ハイブリッド（BM25 + Embedding）を RRF で混ぜ、必要なら cross-encoder でリランク。これが2026年の標準形。
各エンジンに組み込み済みなので実装は容易。判断軸は「完全一致が要るデータか」と「インデックス2本ぶんの運用コストを払う価値があるか」。
効果は積み上げ式（ハイブリッド → ＋リランカー）だがドメイン依存。導入前に MRR/NDCG/Recall@k で自分のデータで実測してから決める。

状況 → 推奨アプローチ早見表

状況	推奨
とりあえず精度を底上げしたい	ハイブリッド（BM25+Embedding+RRF）にする
型番・エラーコード・固有名詞が多い	ハイブリッド必須
まだ精度が足りない / 本番品質が要る	＋ cross-encoder リランカー
上乗せが小さい / コストが気になる	純ベクトルに留め、A/Bで再評価

参考リンク¶

出典ブログ: モダンRAGの常識が変わった｜BM25 + Embedding ハイブリッド検索 — https://hatenabase.jp/blog/modern-rag-hybrid-search-guide/
RRF 原典: Cormack, Clarke, Büttcher, "Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods" (SIGIR 2009) — https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf
Okapi BM25 / TREC-3: Robertson et al., "Okapi at TREC-3" (1994) — https://en.wikipedia.org/wiki/Okapi_BM25
Anthropic, "Contextual Retrieval in AI Systems" (2024) — https://www.anthropic.com/news/contextual-retrieval
Anthropic / Claude Cookbook: Contextual embeddings guide — https://platform.claude.com/cookbook/capabilities-contextual-embeddings-guide
Azure AI Search — Hybrid search scoring (RRF) — https://learn.microsoft.com/en-us/azure/search/hybrid-search-ranking
Azure AI Search — Hybrid search overview — https://learn.microsoft.com/en-us/azure/search/hybrid-search-overview
Pinecone — Rerankers and Two-Stage Retrieval — https://www.pinecone.io/learn/series/rag/rerankers/

作成: 2026-06-29 ／最終更新: 2026-06-29