ハイブリッド検索とは、ベクトル検索（Dense Model）と全文検索（BM25などのSparse Model）を組み合わせ、それぞれの弱点を補完する検索アーキテクチャです。

RAG（Retrieval-Augmented Generation）システムの精度は、検索フェーズの品質に直結します。ベクトル検索は意味的な類似度に強い一方、型番・固有名詞・コードスニペットといったキーワード完全一致が求められる場面では取りこぼしが発生しやすい傾向があります。

本記事では、ハイブリッド検索の仕組みからRRF（Reciprocal Rank Fusion）によるスコア統合、Weaviate・Qdrant・Elasticsearch・PostgreSQLでの実装例、精度評価の方法まで、実務で即活用できる知識を体系的に解説します。RAGシステムの検索精度改善を検討しているエンジニアや、本番環境への導入を控えているチームに向けた内容です。

ハイブリッド検索とは、**ベクトル検索（Dense Model）と全文検索（BM25などのSparse Model）**を組み合わせた検索手法です。ベクトル検索は意味的な類似性に、BM25はキーワードの一致にそれぞれ強みを持ちますが、単独ではカバーしきれないクエリがあります。2つを併用することで、意味的な類似性とキーワードの一致を同時に捉えられるようになります。RAGシステムの検索精度を高める上で、現在最も実用的なアプローチの一つです。

ベクトル検索（Dense Model）は意味的な近さをエンベディングで表現し、類義語や言い換えに対応できる。一方で、型番・固有名詞・コードなど語彙的に一致しなければ意味をなさないクエリには弱い。たとえば「PS-3200A」を検索しても、ベクトル空間では似た意味の文書が優先され、正確な型番を含む文書が埋もれることがある。

ベクトル検索の主な限界

• 語彙の完全一致が必要なクエリ（型番・法令番号・コード）に対して再現率が落ちやすい
• 学習データに含まれない専門用語は意味空間で正しく表現されない
• 近似最近傍探索（ANN）のパラメータ次第で真の最近傍が取りこぼされる

全文検索（BM25）は単語の出現頻度と逆文書頻度でスコアを算出し、キーワードが文書に含まれるかどうかを直接評価するため、型番や固有名詞の検索に強い。しかし、「購入する」と「買う」のように意味が同じでも語形が異なると関連文書をまったく拾えない。

全文検索（BM25）の主な限界

• シノニム・言い換え・略語への対応が辞書整備に依存する
• 文脈を考慮しないため長文クエリの意図を捉えにくい
• 日本語・タイ語などでは製品ごとに適切なanalyzer/tokenizerを設定しなければ検索品質が大きく低下する

2つを組み合わせることで、意味的類似性とキーワード一致を同時に捉えられるようになる。RRFでスコアを統合すれば、片方だけでは上位に来なかった関連文書が浮上しやすくなり、ゼロヒット率も低下する。

RAGの精度は検索フェーズの品質に大きく左右される。どれほど優れたLLMを使っても、関連文書を取り逃せば回答の質は下がる。セマンティック検索だけに頼ると、型番や固有名詞など「意味ではなく文字列として一致すべき」クエリで取りこぼしが起きやすい。

セマンティック検索が苦手とする領域は明確だ。「ABC-1234-X」のような型番はエンベディング空間で類似コードと区別しにくく、人名・地名などの固有名詞は出現頻度が低いため意味ベクトルが不安定になりやすい。git rebase --ontoとgit rebaseは意味的に近いが動作は大きく異なる。

たとえば社内ナレッジベースで「部品番号 XR-990 の仕様」を問い合わせた場合、ベクトル検索はXR-991やXR-880の仕様書を上位に返す可能性がある。型番が1文字違うだけで仕様が全く異なる製造業・医療機器分野では致命的だ。

BM25はトークンの出現頻度とIDF（逆文書頻度）でスコアを計算する。型番や固有名詞はコーパス全体で出現頻度が低く、IDF値が高くなるためBM25スコアが大きく上昇する。ハイブリッド検索を導入すれば「型番はBM25で拾い、文脈はベクトル検索で補う」役割分担が実現できる。特に製品マニュアル検索・法令データベース・APIドキュメントなど、正確な文字列マッチが品質を左右するシステムでは、全文検索の組み込みを優先的に検討すべきだ。

セマンティック検索のみに依存したRAGでは、特定のパターンでハルシネーションが発生しやすくなる。原因は「意味的に近い文書を取得できても、必要な情報を正確に含んでいない」という構造的な問題にある。

• 類似文書の混入: 「製品Aの仕様」を問い合わせた際に「製品Bの仕様」が上位に来て、LLMが誤った型番・スペックを出力する
• バージョンの取り違え: v2.1とv2.0のリリースノートがエンベディング空間で近接し、古い情報が参照されても検索スコアに差が出にくい
• 否定・例外条件の見落とし: 「〜できない」「〜を除く」は意味ベクトルに反映されにくく、肯定的な文書が優先されやすい

BM25は語彙的一致を直接スコアリングするため、型番・バージョン番号・固有名詞ではベクトル検索より高い精度を示す。セマンティック検索単独では「関連はしているが正確ではない」文書をもとにLLMがもっともらしい誤情報を生成するリスクがあり、ハイブリッド検索はこのリスクを構造的に低減する手段として有効だ。

ベクトルデータベースとBM25インデックスをどう共存させるか、チャンクサイズとエンベディングモデルをどう設計するか。この2点を事前に固めておかないと、統合時に大規模なリファクタリングが発生しやすい。以降で各ポイントを詳しく解説する。

最初の判断ポイントはインフラ選定だ。ベクトル検索とキーワード検索を同一システムで動かすには、両機能をネイティブに持つプラットフォームを選ぶか、専用ツールを組み合わせる。

• Weaviate: keyword search（BM25F）とベクトルインデックスを単一コレクションで共存。ハイブリッドクエリをファーストクラスでサポートし、追加の外部サービスが不要で運用コストを抑えやすい
• Qdrant: Dense vectorsとsparse named vectorsを1コレクションに格納。sparse側はclassic BM25ベースの検索からSPLADE等のlearned sparse retrievalまで表現でき、Query APIでサーバーサイドのハイブリッド融合が可能
• Elasticsearch: BM25は成熟。現行版ではベクトル検索もネイティブにサポートし、RRFおよび線形結合によるハイブリッド検索が標準機能として提供されている
• PostgreSQL（pgvector + tsvector）: 既存インフラ上でハイブリッド検索を実現。Supabaseが公式に案内しており、専用のベクトルDBを追加せずに済む

共存設計で押さえるべきポイント

• ベクトルインデックスとキーワードインデックスは同一ドキュメントに対して別々に構築されるため、インデックス更新のタイミングを揃える仕組みが必要
• キーワード検索用テキストフィールドのanalyzer/tokenizer設定は検索品質に直結する（特に日本語環境）
• グリーンフィールドの新規構築ならWeaviateやQdrantが設計をシンプルにしやすく、既存Elasticsearchがあればネイティブのハイブリッド機能を活用する形が移行コストを抑えやすい

チャンクサイズとエンベディングモデルの選択を後から変えると再インデックスのコストが大きいため、事前に方針を固めることが重要だ。

チャンクサイズの設計指針

• 短いチャンク（128〜256トークン）: ピンポイントな事実抽出に向く。BM25との相性がよく、キーワードヒット率が上がりやすい
• 長いチャンク（512〜1024トークン）: 文脈の連続性が必要な説明文や手順書に向く。ベクトル検索の意味的な類似度が安定しやすい
• スライディングウィンドウ方式: チャンク間に50〜100トークンのオーバーラップを持たせると、境界をまたぐ情報の欠落を減らせる

技術マニュアルや規約文書では256〜512トークン前後が多く採用されている。ただし最適値はドキュメントの性質やユースケースで異なるため、候補を2〜3パターン用意してRecall@Kで比較検証するのが現実的だ。

エンベディングモデルの選定ポイント

• 多言語対応: 日本語やタイ語を含む場合、多言語対応モデル（multilingual-e5、Gemini Embedding 2など）を選ぶ。英語専用モデルは非英語テキストの表現精度が落ちやすい
• 次元数とコスト: 次元数はモデルにより大きく異なる（Gemini Embedding 2はデフォルト3072次元で縮小可能）。ストレージ・レイテンシ・精度のバランスを要件に応じて選定する
• ドメイン適合性: 専門用語が多い領域ではドメイン特化モデルのほうが検索精度が改善する傾向がある

チャンクサイズとエンベディングモデルは相互に影響するため、セットで評価することが欠かせない。

ベクトル検索とBM25のスコアは単位が異なるため、そのまま足し合わせても意味のある結果は得られない。この問題を解決するのがRRF（Reciprocal Rank Fusion）だ。RRFはスコアの絶対値ではなく「順位」を使って統合するため、異なる検索方式の結果を安定してマージできる。

RRFは各ドキュメントのスコアを Σ 1/(k + rank_i) で算出する。rank_iは検索方式iにおける順位、kは平滑化定数だ。kの既定値は製品ごとに異なり、Elasticsearchでは60、Qdrantでは2、Supabaseの公式サンプルでは50が使われている。

たとえばk=60で、あるドキュメントがベクトル検索1位・BM25で3位なら 1/61 + 1/63 ≈ 0.0323。別のドキュメントがベクトル5位・BM25で2位なら 1/65 + 1/62 ≈ 0.0315。前者が上位に表示される。

kの調整指針

• kを小さくすると上位ランクへの集中度が高まり、大きくすると順位差の影響が緩和される
• 使用プラットフォームの既定値を確認し、Recall@KやMRRを見ながら調整するのが一般的

重み付きRRFへの拡張

検索方式ごとに重みを乗算する拡張も可能だ。α × 1/(k + rank_ベクトル) + β × 1/(k + rank_BM25) とすれば、型番が多い技術文書ではβを大きく、概念的なFAQではαを大きくできる。αとβの合計を1に正規化しておくと閾値設定が安定する。具体的な値はゴールデンセットを用いたオフライン評価で決定することを推奨する。

主要プラットフォームはそれぞれ異なるアプローチでハイブリッド検索をサポートしている。

Weaviate — hybridクエリでkeyword search（BM25F）とベクトル検索を単一APIから実行。alpha（0〜1、0=pure keyword、1=pure vector）で比重を調整する。融合方式はRelative Score Fusion（v1.24以降の既定）とRanked Fusion（1/(rank+60)の順位ベース融合）の2種類が選択可能。日本語にはgseやkagome_jaなどCJK向けtokenizationを設定する必要がある。

Qdrant — prefetch+fusionでdense vectorsとsparse vectorsのハイブリッド検索を実装。sparse側はclassic BM25ベースの検索からSPLADE等のlearned sparse retrievalまで対応し、RRFとDistribution-Based Score Fusionがサーバーサイドで選択可能。RRFの定数kの既定値は2（Elasticsearchの60とは異なる）。

Elasticsearch — ネイティブのハイブリッド検索をサポート。retrieverAPIでRRFと線形結合の両方が標準機能として提供されている（8.14で追加、8.16でGA）。既存インフラのBM25チューニング知見をそのまま活かせる点が強み。日本語にはkuromoji analyzer、タイ語にはthai analyzerやICU tokenizerが利用可能。

PostgreSQL / Supabase — pgvector+tsvector/tsqueryで実装可能。Supabaseが公式にハイブリッド検索を案内しており、GINインデックス（全文検索）とHNSW（ベクトル検索）を併用するサンプルを提供している。RRFはSQL関数で実装する形になる。

いずれも仕様変更が頻繁なため、実装前に最新ドキュメントを確認すること。

RRFは「順位の融合」であり、クエリと文書の意味的一致度を直接測るものではない。そこでリランキングモデルを後段に追加する構成が広く採用されている。

典型的なパイプライン構成

• 第1段階（Retrieve）: ハイブリッド検索でTop-50〜100件を取得
• 第2段階（Rerank）: Cross-Encoderでクエリと各文書のペアをスコアリング
• 第3段階（Generate）: 上位3〜10件をコンテキストとしてLLMへ渡す

Cross-Encoderはクエリと文書を同時にエンコードして関連度スコアを出力する。Bi-Encoderベースのベクトル検索より計算コストは高いが精度面で優れ、候補を絞った後段で使えばレイテンシを許容範囲に抑えられる。

代表的な選択肢はCohere Rerank API（多言語対応・クラウド）、bge-reranker-v2-m3（多言語対応・OSS）、cross-encoder/ms-marco-MiniLM（英語・軽量）など。多言語RAGでは対象言語での精度をゴールデンセットで事前評価することを推奨する。リランキング追加時はレイテンシ増加に注意し、非同期処理やキャッシュでスループットを確保する。

実装を急ぐと意外な落とし穴にはまりやすい。スコアの統合方法や言語処理の設定を誤ると、単体の検索方式より精度が低下するケースもある。設計段階でこれらを把握しておくことで手戻りを大幅に減らせる。

最も多い実装ミスが、スコアのスケールを揃えずに統合することだ。

ベクトル検索側のスコアはcosine similarity / cosine distance / 内部変換スコアなど、エンジンや距離関数で意味が異なる（数学的なcosine similarityは-1〜1）。BM25のスコアもドキュメント集合の規模やテキスト長で値域が大きく変動し、数十〜数百に達することもある。この状態のまま単純加算すると、BM25側が結果を支配し、セマンティック検索の恩恵がほぼゼロになる。

症状として現れやすいパターン：

• キーワードを含む短いチャンクが上位を独占し、文脈的に関連性の高い長文チャンクが圏外になる
• クエリの表現を少し変えただけで上位結果が大幅に入れ替わる
• RRFを使わず加重和（Weighted Sum）で統合している実装で特に顕著

RRFを採用すれば正規化の手間を省けるが、スコアの大小を活かしたい場合は明示的な正規化付き線形結合が現実的だ。開発段階で両方のスコア分布をログ出力して可視化する習慣をつけると、ズレを早期に発見できる。

キーワード検索側のanalyzer/tokenizerが原因で検索精度が大きく落ちるケースがある。英語前提のBM25実装は空白区切りでトークン分割するため、日本語やタイ語のように単語間にスペースがない言語では正しく分割されない。

よく起きる問題

• 日本語で「自然言語処理」を検索すると、適切なtokenizationなしでは1トークンとして扱われ部分一致が機能しない
• タイ語は単語境界の検出に専用の処理が必要だが、デフォルト設定では無視される
• 英語・日本語・タイ語が混在するドキュメントでは言語ごとにトークン粒度が異なり、スコア比較が不公平になる

プラットフォーム別の対処

• Elasticsearch / OpenSearch: 日本語にkuromoji analyzer、タイ語にthai analyzerやICU tokenizerが標準提供。言語ごとにフィールドマッピングを分ける設計を推奨
• Weaviate: CJK言語向けにgseやkagome_jaなどのtokenizationオプションを提供。デフォルトでは日本語の分割精度が落ちるため設定変更が必要
• PostgreSQL / Supabase: PGroongaが日本語・中国語などCJK言語に対応。pg_bigmによるbigramインデックスも選択肢

多言語ドキュメントが混在する場合は言語検出ステップを挟み、言語ごとに異なるanalyzerを適用する。ベクトル検索側は多言語対応エンベディングモデルで言語差を吸収できるが、キーワード検索側はanalyzer/tokenizerの設定を製品ごとに確認・設計しなければ精度が担保されない。

ハイブリッド検索を導入しても、精度が本当に改善しているかを定量的に確認しなければ改善サイクルは回らない。主観的な「なんとなく良くなった」では本番運用の判断材料にならない。Recall@K・MRR・NDCGとゴールデンセットによる回帰テストが基本となる。

Recall@K — 上位K件に正解ドキュメントが何件含まれるかを測る。RAGでは「取りこぼしていないか」の確認に使い、K=5やK=10が実務で一般的だ。

MRR（Mean Reciprocal Rank） — 正解が初めて登場する順位の逆数を平均した値。1位なら1.0、3位なら0.33。最初に目にする結果の質を評価したい場合に有効で、チャットボット型RAGとの相性がよい。

NDCG — 関連度に段階的スコア（完全一致/部分一致/無関係）を付けられる指標。上位に関連度の高い文書が来るほどスコアが高くなる。ラベリングコストが高いため、まずRecall@KとMRRで素早く評価し、精度が拮抗したときにNDCGで深掘りする。

実務では、ベクトル検索のみ・BM25のみ・ハイブリッドの3条件を同一テストセットで比較し、改善幅を数値で確認する。Recall@Kは「取りこぼし」の検出、MRRは「上位精度」の確認と、指標ごとに役割を分けて解釈するのがポイントだ。

ゴールデンセットとは「クエリ」と「期待される正解ドキュメント」のペアを人手で定義したテスト用データセットだ。最低50〜100件程度が出発点となる。

作成のポイント

• カバレッジ: キーワード一致クエリとセマンティッククエリを両方含める
• 難易度分布: 同義語・略語・多言語混在など境界ケースを意図的に入れる
• ドメイン代表性: 実際のユーザーログや問い合わせ履歴から抽出すると現実的な難易度になる

CI/CDへの組み込み

ゴールデンセットはコードと同様にバージョン管理し、CI/CDパイプラインのテストステップに組み込む。チャンクサイズ変更やモデル更新のたびにRecall@KやMRRを自動計算して前バージョンと比較し、指標が一定以上低下した場合はマージをブロックする。

ドキュメント更新で正解ラベルが陳腐化するため、本番ログから検索失敗事例を自動収集してゴールデンセットに追加するフィードバックループの構築も推奨する。

ハイブリッド検索は検索層の基盤技術だが、フラットなドキュメント検索だけでは対応しきれない複雑なクエリも存在する。

**GraphRAG**はナレッジグラフと組み合わせるアプローチだ。ハイブリッド検索でヒットしたチャンクから固有名詞を抽出してグラフ上のノードに紐付け、「製品X → 関連規格 → 適用地域」のように複数ホップ先の情報まで横断取得できる。Neo4jやAmazon Neptuneをグラフ層に、QdrantやWeaviateをベクトル層に置き、並列で呼び出す設計が現実的だ。

**Agentic RAG**はマルチステップ推論エージェントにハイブリッド検索を組み込むアプローチだ。エージェントが質問を分解し、固有名詞を含むサブクエリはキーワード検索主体、概念的なサブクエリはベクトル検索主体でalphaを動的に切り替える。LangGraphやLlamaIndex Workflowsでハイブリッド検索ノードを独立したステートとして定義すると、リトライや分岐処理が容易になる。

ただし、複雑化するほど運用コストも増す。多くの場合、まずはシンプルなハイブリッド検索で精度の天井を確認してから段階的に拡張するアプローチが採用されている。

ハイブリッド検索はコストが高くなるか？

設計次第で増分コストは限定的に抑えられる傾向がある。コスト増の主因はインデックスの二重管理（ストレージ増）と2系統の検索の並列実行（計算リソース）だが、BM25は軽量でベクトル検索より計算コストが低く、既存インフラに相乗りできるケースも多い。一方、検索精度が上がるとLLMへ渡すコンテキストの無駄が減り、不要なトークン消費を削減できる場合もある。頻出クエリのキャッシュ活用やチャンクサイズの最適化も有効だ。コスト増が顕在化しやすいのは、数百万ドキュメント以上かつリアルタイム更新が頻繁なケースだ。

クラウドとオンプレミスで実装は変わるか？

変わる。クラウドではAzure AI SearchやAmazon OpenSearch Serviceなど、RRFを含むハイブリッド検索がAPIレベルで提供されており、インフラ管理の負担が小さい。スケールアウトもサービス側が担う。オンプレミスではQdrantやElasticsearchをセルフホストする構成が一般的だが、いずれもサーバーサイドのスコア融合機能を提供しており、すべてをアプリ層で実装する必要はない。データを外部に出せない規制要件（金融・医療・行政など）がある場合はオンプレミスが必須となる。

ハイブリッド検索は、ベクトル検索とBM25を組み合わせることで、どちらか一方では取りこぼすクエリをカバーする実践的な手法だ。型番・固有名詞・コードスニペットのようなキーワード一致が必要な場面と、意味的な近さで文書を探したい場面の両方に対応できる。

本記事で押さえたポイントを整理する。

• 設計段階: ベクトルDB選定、チャンクサイズ、エンベディングモデルを事前に揃えることが精度の土台になる
• スコア統合: RRFは実装がシンプルで効果が出やすい。プラットフォームごとにkの既定値が異なるため確認が必要
• 多言語対応: 日本語・タイ語などではanalyzer/tokenizerの不一致が精度劣化の温床になる
• 評価設計: Recall@K・MRRとゴールデンセットで継続的に品質を監視する

発展的にはGraphRAGやAgentic RAGへの拡張も視野に入るが、まずはシンプルなハイブリッド検索で精度の底上げを確認してから段階的に進めるのが現実的だ。ハルシネーション低減と回答品質の向上は、検索層の改善なしには実現しにくい。ハイブリッド検索の導入を、RAG全体の品質改善サイクルの起点として位置づけてほしい。