セマンティック検索を補うハイブリッド検索：BM25・RRFの実装と再現率評価

ドキュメントの確認日：2026年10月24日。 以下の実装ガイドは、確認時点のElasticsearch、Weaviate、Pineconeのドキュメントに基づいています。評価の設定値は、検証を始めるための提案です。実測した改善幅やベンダーのベンチマークではありません。

セマンティック検索を補うハイブリッド検索とは？

ハイブリッド検索は、文字どおりの表現と意味の両方を検索結果に反映します。この記事で扱う構成では、キーワード検索とベクトル検索がそれぞれ順位付きのリストを返し、融合手法で両者を統合します。Weaviateの解説でも、この2つの検索経路と統合の仕組みが説明されています。

同じ問い合わせを2人の調査担当者に調べてもらう場面を考えてみてください。一方は索引を使い、名称やエラー文字列がそのまま一致する情報を探します。もう一方は内容を読み、別の言い方で書かれた回答も含めて、関連する情報を探します。どちらか1人に両方を任せるのではなく、それぞれが見つけた候補をまとめるわけです。

BM25は、クエリに含まれる語が文書にどのように出現するかに基づいてスコアを付ける、語彙ベースのランキング関数です。スコアには語の出現頻度と文書の長さが影響するため、一致した単語を単純に数えるよりも有用です。Elasticsearchは、テキスト類似度の既定方式にBM25を使っています。これらの要素はElasticの類似度リファレンスで確認できます。

ベクトル検索は、内容を数値で表した埋め込みを比較し、意味の近い情報を見つけます。たとえば「何度もログアウトされる」という質問から、表現が異なる「セッションの有効期限切れ」の文書を見つけられます。この検索経路は、セマンティック検索のガイドで解説しています。

例として、ERR_SESSION_EXPIRED after loginというクエリを考えます。キーワード検索の経路は、このエラー文字列そのものを含む情報を結果に届けます。意味に基づく検索の経路は、認証セッションやその更新に関する説明を候補に加えられます。最後に融合処理が順位を決めます。これは目指す動作の例であり、未設定のストアが特定の順位を返すと保証するものではありません。

ハイブリッド検索でも、識別子の完全一致には明確なルールが必要です

キーワード検索の経路を加えても、識別子の完全一致が保証されるわけではありません。文字列を検索可能なトークンに変換するテキスト解析によって、インデックスに登録される形が変わることがあります。たとえばElasticの標準アナライザーは、公式の例でハイフン付きの語句を分割しています。設定したアナライザーが、自分たちのSKUやエラーコードをどう処理するか確認してください。標準アナライザーのドキュメント。

識別子の表記によって対象が一意に決まる場合は、完全一致用の専用フィールドに保存します。Elasticは、こうした構造化された値のためにkeywordフィールドを用意しています。架空のSKUであるAX-BLUEを検索したときに、説明文が似ているからといって、いつの間にかAX-GREENのおすすめに変わってはいけません。keywordフィールドのリファレンス。

判断の基準： 一意の識別子を認識したら対応する項目を返す、という製品仕様であれば、完全一致の検索に振り分けます。その商品のトラブルシューティング情報を探す場合など、識別子とより広い目的が組み合わさった質問には、ハイブリッド検索のランキングを使います。

RRFと重み付きスコア：検索結果をどう統合するか

異なるスコア尺度を調整せずに比較の基準を作りたいなら、まずはReciprocal Rank Fusionを使います。バランス調整に使える正解ラベルがあり、スコア同士の差を残したい理由もあるなら、重み付きスコアを検討します。

RRFはスコアの値ではなく順位を使います

**Reciprocal Rank Fusion（RRF）**は、ある文書が現れる各リストからの寄与を合計します。

RRF（文書）= 各検索結果リストにおける1 / (c + 順位)の合計。

順位は1位から数えます。あるリストに文書がなければ、そのリストからの寄与はありません。Gordon V. Cormack、Charles L. A. Clarke、Stefan Büttcherは、SIGIR 2009の論文でRRFを発表しました。実験では定数を60に固定しています。論文ではこの定数をkと呼んでいますが、この記事ではrecall@kの結果件数と混同しないよう、cと表記します。

RRFの利点は、BM25の高スコアとベクトル検索の高スコアが、同じ意味を持つ必要がないことです。見るのは順位だけです。PineconeのRRF実装では、順位を1から数えることと、リストにない文書の扱いが明示されています。

ただし、この方式には確認しておきたい性質があります。説明用の例として、文書Aはキーワード検索で1位ですが、ベクトル検索のリストにはないとします。文書Bは両方のリストで2位です。c = 60なら、Aは1/61、Bは2/62となり、Bが上位に来ます。 これは式から計算した例であり、検索ベンチマークの結果ではありません。

重み付きスコアはスコアの差を残します

重み付きスコア融合では、各検索の関連度スコアを比較可能な尺度にそろえてから組み合わせます。よく使われる形は次のとおりです。

スコア = alpha × 正規化したベクトルスコア + (1 − alpha) × 正規化したキーワードスコア。

重みalphaでバランスを調整します。初期値を0.5にすれば係数は等しくなりますが、有用性まで等しくなるわけでも、最適な設定になるわけでもありません。正規化と重み付けは、どちらを変えても順位に影響するため、両方を記録してください。

Elasticsearchのlinear retrieverは、minmaxなどの正規化方式を使った加重和に対応しています。Weaviateの相対スコア融合は、各結果集合の中にある相対的なスコア差を保持します。一方、順位に基づく融合では、その差は使われません。

まずRRFを比較の基準にし、重み付き融合は評価用に取り置いたクエリで有効性を確認できた場合に採用します。 生のBM25スコアとベクトル類似度を足して、その合計に意味があると考えてはいけません。また、候補を何件まで取得したかも記録してください。正規化の対象リストに含める結果が変わると、スコアの範囲も変わり得ます。

ベクトル検索だけの場合より、ハイブリッド検索が有効なのはいつか

キーワード検索が、ベクトル検索では見つからなかった関連情報を取得し、統合後もその情報が役立つ順位に残るなら、ハイブリッド検索は有効です。これは実際に確認できる条件であり、あらゆる場面で精度が高くなるという主張ではありません。

特に試す価値があるのは、次のような用途です。

• サポート情報の検索： エラー文字列、関数名、アカウントに関する用語と、症状を説明する文章が混在します。
• カタログ検索： 正確な製品名やSKUに、互換性の確認や交換部品の探索といった目的が組み合わさります。
• 社内ナレッジ検索： プロジェクト名や略語と、自然文の質問が混在します。

Pineconeのハイブリッド検索の概要でも、意味を捉える密ベクトル検索と組み合わせるキーワード側の手掛かりとして、製品コード、エラー文字列、名称が挙げられています。

識別子だけで対象を引く用途では、まず確実に動く完全一致検索を用意します。既存の文書集合とクエリにベクトル検索が十分対応できているなら、検索の問題が確認できてから経路を追加してください。

実際の限界を決めるのは、候補に必要な情報が含まれているかです。融合処理が並べ替えられるのは、各経路で取得した文書の和集合だけです。どちらの経路も必要な文章を見つけていなければ、統合方式を変えても取り戻せません。融合前にはあった文章が最終結果から消えるなら、ランキングと件数による切り捨てを調べます。

既存のストアにハイブリッド検索を追加する

必要な検索機能がそろっているなら、今使っているストアを維持します。データベースと検索戦略を同時に変えると、何が改善につながったのか切り分けにくくなります。

次の表は、どこで検索結果を組み合わせるかを整理したものです。ベンダーの優劣を示すものではありません。

Elasticsearchでハイブリッド検索を実装する

テキスト検索とベクトル検索に対応するElasticsearchでは、テキスト用のstandardリトリーバーとベクトル用のknnリトリーバーを、rrfリトリーバーの下に配置できます。この構成と候補ウィンドウは、公式のRRFリトリーバーのリファレンスで説明されています。

既存のインデックスでは、検索対象のテキストとその埋め込みを、同じ文書IDに紐付けて保持します。両方の経路で同じ検索対象にクエリを実行し、その後に融合処理を行います。テナント、アクセス権限、製品バージョンの制限も、経路間でそろえてください。

以下は、ES_URLとES_API_KEYを設定した後に実行できるリクエストです。既存のインデックス名がdocs、テキストフィールドがtext、密ベクトルフィールドがembeddingであり、query-vector.jsonにはクエリの実際の埋め込み配列が入っていることを前提とします。この配列は、インデックス内の文書に使ったモデルで生成してください。コマンドの実行にはjqとcurlが必要です。

jq -n --slurpfile v query-vector.json \
  --arg q 'ERR_SESSION_EXPIRED after login' \
  '{
    size: 10,
    retriever: {
      rrf: {
        retrievers: [
          {standard: {query: {match: {text: $q}}}},
          {knn: {
            field: "embedding",
            query_vector: $v[0],
            k: 50,
            num_candidates: 100
          }}
        ],
        rank_window_size: 50,
        rank_constant: 60
      }
    }
  }' > hybrid-request.json

curl --fail-with-body "$ES_URL/docs/_search" \
  -H "Authorization: ApiKey $ES_API_KEY" \
  -H 'Content-Type: application/json' \
  --data-binary @hybrid-request.json

ここに示した値は、評価のための設定例です。sizeは最終的な結果件数、rank_window_sizeは各子リトリーバーから融合処理に参加できる結果件数を制御します。この例にはフィルターがないため、アクセス権限のあるアプリケーションで使う場合は、検索対象の制約を必ず追加してください。Elasticのドキュメントには、子リトリーバーそれぞれの仕様に従って適用される、親側のfilterが記載されています。

つまずきやすい点： 子リトリーバーの候補ウィンドウが狭いと、ハイブリッド検索で拾いたかった結果そのものを捨ててしまいます。統合方式を調整する前に、各経路の候補と最終結果を比べてください。linear retrieverへ切り替える場合は、重みとともに正規化も設定します。

Weaviateでハイブリッド検索を実装する

テキスト検索とベクトル検索に対応するデータベースWeaviateでは、collection.query.hybridからハイブリッド検索を利用できます。キーワード側の検索には、複数フィールドに対応したBM25の派生であるBM25Fを使います。ハイブリッドクエリのドキュメントでは、検索対象プロパティ、融合方式の選択、スコアの説明が扱われています。

query_propertiesには、タイトル、エラー文、製品名など、語句の一致が有効な手掛かりになるフィールドを指定します。アプリケーション側で埋め込みを生成する場合はクエリベクトルを渡し、そうでなければコレクションに設定したベクトル化の経路を使います。融合方式を比較するときはfusion_typeを明示し、結果の順位が動いた理由を調べるときはexplain_scoreを取得してください。

alphaも明示的に設定します。0はキーワード検索、1はベクトル検索を選びます。確認時点のドキュメントでは、省略時に適用される重みはクライアントに依存すると注意されています。既定の融合方式はrelativeScoreFusionで、rankedFusionも利用できます。Weaviateの融合方式リファレンス。

つまずきやすい点： 重みを変えても、検索対象フィールドの不足や、識別子のトークン化による崩れは直せません。埋め込みモデルを置き換えるべきだと結論付ける前に、キーワード側が何を検索できているか確認してください。重みの両端にあたるベクトル検索のみ、キーワード検索のみの設定を診断用の基準にしてから、組み合わせた設定を評価します。

Pineconeでハイブリッド検索を実装する

検索用データベースのPineconeは、異なるハイブリッド検索のパターンを公開しています。サンプルをコピーする前に、どの方式を使うか決めてください。サーバー側での密・疎ベクトルの統合と、クライアント側でのRRFは、別の実装です。Pineconeのハイブリッド検索の概要。

BM25と密ベクトル検索を組み合わせる場合、Documents APIを使う経路では、全文検索と密ベクトル検索を実行し、順位付きの文書IDをアプリケーション側でRRFにより統合します。PineconeのRRFガイドに、このクライアント側の実装が掲載されています。

密ベクトルと疎ベクトルをネイティブに統合する場合、Vectors APIでは各レコードに両方の表現を保存し、1回のクエリで組み合わせられます。単一インデックスのガイドでは、vector_type="dense"とmetric="dotproduct"が必須です。相対的な影響度は、クライアント側でクエリベクトルをスケーリングして設定します。

疎ベクトルはデータの表現形式であり、BM25で生成されたことを示すものではありません。設計資料には、使用する語彙ベースのモデルや全文検索のスコア計算方式を明記してください。

つまずきやすい点： キーワードでフィルタリングしてから密ベクトルで順位を付ける処理は、両方のシグナルをランキングに反映する処理とは異なります。フィルターは候補を除外するため、除外済みの同義語の一致を後から拾い直せません。必須条件にはフィルターを使い、どちらの検索経路からも結果を候補に加えたい場合には融合を使います。

RAGでハイブリッド検索はどんな役割を果たすのか

ハイブリッド検索が変えるのは、**検索拡張生成（Retrieval-Augmented Generation、RAG）**の検索段階です。RAGでは、言語モデルが回答する前に、アプリケーションが検索した資料をモデルへ渡します。ハイブリッド検索は生成段階を置き換えるものでも、回答の正しさを保証するものでもありません。

検索の単位はそろえてください。キーワード検索が文書全体を返し、ベクトル検索が文章の一部分を返すなら、統合前にIDの対応付けを決めます。そうしないと、同じ資料から取った複数の文章が候補を占め、ほかの関連資料が押し出されることがあります。保存と検索の基盤については、ベクトルデータベースの解説で扱っています。

Agentic RAGでは、どの検索処理を実行するか、もう一度検索するかといった判断が加わります。ハイブリッド検索は、その選択肢の1つになります。サポートボットがエラーコードそのものを見逃しているなら、処理の制御をさらに複雑にする前に、その検索機構を修正して評価してください。

検索方式の比較中は、回答を生成するモデルとプロンプトを固定します。完全一致の語句を含むクエリ群では改善しても、言い換えを含む検索が弱いままなら、同じ正解ラベル付きクエリで埋め込みモデルを比較します。埋め込み、チャンク分割、融合方式を同時に変えると、結果の原因を特定できなくなります。

導入前後のrecall@kを比較する

小規模な正解ラベル付きクエリセットを使い、同じ正解に対して、キーワード検索のみ、ベクトル検索のみ、ハイブリッド検索を比較します。生成された回答が流暢でも、それは検索性能の指標にはなりません。

Recall@k = 上位k件に含まれる関連IDの数 ÷ そのクエリで関連ありとラベル付けした全IDの数。 クエリごとの値を平均すると、マクロ平均のrecall@kになります。ラベルが網羅的でない場合は、既知の関連性判定に対する再現率と呼んでください。文書集合にあるすべての関連項目に対する再現率が分かったことにはなりません。

ローカルで再現率を計算する

以下をevaluate_recall.pyとして保存します。使うのはPython 3の標準ライブラリだけです。qrels.jsonlにはクエリごとに1つのJSONオブジェクトを記述し、qid、slice、relevantの各フィールドを含めます。各結果ファイルでは、クエリIDを、取得したIDの順位付きリストに対応付けます。

たとえば、ラベルのレコードは{"qid":"q-exact","slice":"exact","relevant":["guide-login"]}、結果ファイルの内容は{"q-exact":["guide-reset","guide-login"]}のようになります。これは形式を示す例であり、検証済みシステムの検索結果ではありません。すべての結果ファイルに、ラベル付けしたすべてのクエリを含めてください。何も取得できなかったクエリには、空のリストを使います。

import json
import sys
from collections import defaultdict
from statistics import mean

qrels_path, bm25_path, vector_path, hybrid_path, cutoff = sys.argv[1:]
k = int(cutoff)
if k < 1:
    raise ValueError("k must be positive")

with open(qrels_path, encoding="utf-8") as f:
    labels = [json.loads(line) for line in f if line.strip()]
if not labels or len({r["qid"] for r in labels}) != len(labels):
    raise ValueError("Labels must be nonempty with unique query IDs")

runs = {}
for name, path in (("bm25", bm25_path), ("vector", vector_path),
                   ("hybrid", hybrid_path)):
    with open(path, encoding="utf-8") as f:
        runs[name] = json.load(f)
    missing = {r["qid"] for r in labels} - runs[name].keys()
    if missing:
        raise ValueError(f"{name} is missing query IDs: {sorted(missing)}")

groups = defaultdict(list)
skipped = 0
for row in labels:
    relevant = set(row["relevant"])
    if not relevant:
        skipped += 1
        continue
    scores = {}
    for name, run in runs.items():
        unique_ids = list(dict.fromkeys(run[row["qid"]]))
        scores[name] = len(relevant & set(unique_ids[:k])) / len(relevant)
    groups["overall"].append(scores)
    groups["slice:" + row["slice"]].append(scores)

if not groups:
    raise ValueError("No answerable queries to score")
for group, rows in sorted(groups.items()):
    values = {name: mean(r[name] for r in rows) for name in runs}
    delta = values["hybrid"] - values["vector"]
    report = " ".join(f"{name}={v:.3f}" for name, v in values.items())
    print(f"{group} n={len(rows)} recall@{k} {report} delta={delta:+.3f}")
print(f"Excluded no-answer queries: {skipped}")

取り置いた評価用ラベルと、エクスポートした結果に対して実行します。

python3 evaluate_recall.py qrels.jsonl bm25.json vector.json hybrid.json 10

このスクリプトは、IDの重複を除いてから上位件数で区切ります。アプリケーションでも、同じ重複除去のルールを使ってください。ベクトル検索に対するハイブリッド検索の変化を報告するとともに、キーワード検索の基準値も表示します。これにより、語彙ベースの検索が高い性能を出している場合も、比較から見落とさずに済みます。

重要なクエリ群で改善が見られ、悪化した点も製品要件の範囲で許容できるなら、導入に進みます。 候補は改善したのに最終的な再現率が変わらない場合は、融合方式や返却件数を調整します。最終的な再現率が上がった場合も、結果の並び順、生成回答の正しさ、エンドツーエンドのレイテンシーは別途確認してください。再現率だけでは、そのいずれも測れません。

過大な期待を避け、次に何をするか

「ハイブリッド検索なら両方のいいとこ取りができる」という説明だけでは、設計上の判断が見えなくなります。役立つ情報を拾える範囲は広がり得ますが、同時に、もう1つの検索経路が最終リストに影響することになります。RRFは完全一致の順位を下げることがあります。重み付き融合は、スコア尺度や正規化の挙動の違いによって、一方を優遇することがあります。そして、元になる情報が存在しない問題は、どちらでも解決できません。

開発者がすぐに着手すべきなのは、 正確な語句を含む関連文書がベクトル検索の候補から抜けていると確認できた場合です。キーワード検索の経路を追加し、文書の同一性とアクセス権限をそろえ、正解ラベル付きの比較を実施します。

運用担当者が展開を待つべきなのは、 現在の問題が古いコンテンツ、権限の不足、関連性ラベルの欠如にある場合です。先にその前提条件を整えてから、検索戦略を比較してください。

識別子による検索が安定しているチームは、 より広い情報探索が必要になるまでは、対応を変える必要はありません。信頼できる検索経路を維持し、自然文の質問向けのハイブリッド検索を別途評価します。

次の営業日にまず行うことは、うまくいかない検索を集め、期待する資料にラベルを付け、既存のベクトル検索とキーワード検索の基準実装を並べて動かすことです。各経路が何を取得できるか見えてから融合を加え、取り置いたクエリで有効性を示した設定を採用してください。

よくある質問

実装に役立つガイドをニュースレターで受け取る。