ハイブリッド検索（ベクトル×キーワード）

なぜ単体では足りないのか

HNSW/IVF-PQによるベクトル索引 と 転置インデックス＋BM25 は、それぞれ単独でも動く完結した仕組みです。しかし両者は失敗するクエリの種類が対称的に異なります。

ベクトル検索は埋め込み空間上の距離で「意味の近さ」を捉えるため、言い換えや同義語（「解雇」と「クビ」）に強い一方、学習データで意味を持たない固有名詞・型番・エラーコード・略語（ERR_502、製品型番XJ-4400）はベクトル空間上でうまく分離されず、埋め込みが潰れて無関係な結果を引きやすくなります。逆にBM25はトークン一致に基づくため型番や固有名詞の完全一致には滅法強い一方、クエリと文書が同じ語を共有しない言い換えには原理的にスコアが立ちません。

尺度が違う二つのスコアをどう混ぜるか

素朴には「ベクトル類似度スコアとBM25スコアを重み付き和で足せばよい」と考えたくなりますが、これは危険です。理由は二つのスコアがまったく異なる分布・尺度を持つからです。

• コサイン類似度は基本的に0〜1（あるいは-1〜1）に収まるが、クエリによって上位群のスコア差がごく小さいこともあれば大きく開くこともある。
• BM25スコアは上限がなく、クエリの語数・idf・文書長によって同じ「1位」でもスコアの絶対値が数倍変わる。

このため score = a * cos_sim + b * bm25 のような線形結合は、クエリごとに最適なa, bが変わってしまい、事前に固定した重みでは特定のクエリ分布に過学習します。スコアそのものを毎回min-max正規化して混ぜる手もありますが、母集団（そのクエリでヒットした集合）が変わるたびに正規化の基準が動くため、順位が不安定になりがちです。

RRF（Reciprocal Rank Fusion）：順位だけを使う

この問題を回避する標準的な手法が RRF（Reciprocal Rank Fusion） です。核心のアイデアは「スコアの値を一切見ず、各検索結果内での**順位（rank）**だけを使う」ことにあります。

RRF(d) = Σ_i  1 / (k + rank_i(d))

  d       : 統合対象の文書
  i       : 各検索系列（例: ベクトル検索、BM25検索）
  rank_i(d): 系列 i における文書 d の順位（1位, 2位, ...）。系列 i に出現しなければ加算しない
  k       : 平滑化定数（原論文・実装の既定値は 60）

たとえば文書Aがベクトル検索で1位、BM25検索で圏外（未ヒット）、文書Bがベクトル検索で5位、BM25検索で2位だったとすると、k=60のとき次のように計算されます。

RRF(A) = 1/(60+1)                = 0.01639
RRF(B) = 1/(60+5) + 1/(60+2)     = 0.01538 + 0.01613 = 0.03151

両方の検索でそこそこ上位に来たBが、片方だけで1位のAを上回ります。これがRRFの本質的な性質で、「一つの系列で圧倒的だが他方で無視される文書」より「両系列である程度支持される文書」を優先します。

k（平滑化定数）の役割にも注意が必要です。kを大きくすると1/(k+rank)の分母が支配的になり、上位と下位の差が緩やかになります（上位互恵の効果が弱まり、より多くの文書が横並びに近づく）。逆にkを小さくすると1位と2位の差が急峻になり、上位の系列一致がより強く効きます。k=60という既定値は、TRECのような大規模ベンチマークで経験的に安定した値として広まったもので、理論的な最適値の証明があるわけではありません。

実行経路：並列実行とクエリ側の設計

ハイブリッド検索の実行は典型的に次の流れを取ります。

1. クエリ文字列を受け取る
2. (a) クエリを埋め込みモデルでベクトル化 → ANN索引を検索 → 上位N件（ベクトル候補）
   (b) クエリをトークナイズ → 転置インデックスを検索 → 上位N件（BM25候補）
   ※ (a)と(b)は独立なので並列実行できる
3. 両候補集合の和集合に対しRRFでスコアを再計算
4. 統合スコア順に上位k件を返す

(a)と(b)は互いに独立したクエリなので並列実行でき、統合コストはRRFの単純な計算だけなのでレイテンシへの上乗せは小さく抑えられます。ただし、ベクトル検索側のefSearchやBM25側の候補数Nを絞りすぎると、統合前の時点で本来上位に来るべき文書が候補集合から漏れ、RRFがいくら頑健でも救えません。実務では両系列とも「最終的に返す件数より一桁多い候補」を取ってから統合するのが定石です。

まとめ