
ハイブリッド検索とは、ベクトル検索(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」を検索しても、ベクトル空間では似た意味の文書が優先され、正確な型番を含む文書が埋もれることがある。
ベクトル検索の主な限界
全文検索(BM25)は単語の出現頻度と逆文書頻度でスコアを算出し、キーワードが文書に含まれるかどうかを直接評価するため、型番や固有名詞の検索に強い。しかし、「購入する」と「買う」のように意味が同じでも語形が異なると関連文書をまったく拾えない。
全文検索(BM25)の主な限界
2つを組み合わせることで、意味的類似性とキーワード一致を同時に捉えられるようになる。RRFでスコアを統合すれば、片方だけでは上位に来なかった関連文書が浮上しやすくなり、ゼロヒット率も低下する。

セマンティック検索が苦手とする領域は明確だ。「ABC-1234-X」のような型番はエンベディング空間で類似コードと区別しにくく、人名・地名などの固有名詞は出現頻度が低いため意味ベクトルが不安定になりやすい。git rebase --ontoとgit rebaseは意味的に近いが動作は大きく異なる。
たとえば社内ナレッジベースで「部品番号 XR-990 の仕様」を問い合わせた場合、ベクトル検索はXR-991やXR-880の仕様書を上位に返す可能性がある。型番が1文字違うだけで仕様が全く異なる製造業・医療機器分野では致命的だ。
BM25はトークンの出現頻度とIDF(逆文書頻度)でスコアを計算する。型番や固有名詞はコーパス全体で出現頻度が低く、IDF値が高くなるためBM25スコアが大きく上昇する。ハイブリッド検索を導入すれば「型番はBM25で拾い、文脈はベクトル検索で補う」役割分担が実現できる。特に製品マニュアル検索・法令データベース・APIドキュメントなど、正確な文字列マッチが品質を左右するシステムでは、全文検索の組み込みを優先的に検討すべきだ。
セマンティック検索のみに依存したRAGでは、特定のパターンでハルシネーションが発生しやすくなる。原因は「意味的に近い文書を取得できても、必要な情報を正確に含んでいない」という構造的な問題にある。
BM25は語彙的一致を直接スコアリングするため、型番・バージョン番号・固有名詞ではベクトル検索より高い精度を示す。セマンティック検索単独では「関連はしているが正確ではない」文書をもとにLLMがもっともらしい誤情報を生成するリスクがあり、ハイブリッド検索はこのリスクを構造的に低減する手段として有効だ。

ベクトルデータベースとBM25インデックスをどう共存させるか、チャンクサイズとエンベディングモデルをどう設計するか。この2点を事前に固めておかないと、統合時に大規模なリファクタリングが発生しやすい。以降で各ポイントを詳しく解説する。
最初の判断ポイントはインフラ選定だ。ベクトル検索とキーワード検索を同一システムで動かすには、両機能をネイティブに持つプラットフォームを選ぶか、専用ツールを組み合わせる。
共存設計で押さえるべきポイント
チャンクサイズとエンベディングモデルの選択を後から変えると再インデックスのコストが大きいため、事前に方針を固めることが重要だ。
チャンクサイズの設計指針
技術マニュアルや規約文書では256〜512トークン前後が多く採用されている。ただし最適値はドキュメントの性質やユースケースで異なるため、候補を2〜3パターン用意してRecall@Kで比較検証するのが現実的だ。
エンベディングモデルの選定ポイント
チャンクサイズとエンベディングモデルは相互に影響するため、セットで評価することが欠かせない。

ベクトル検索と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の調整指針
重み付き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は「順位の融合」であり、クエリと文書の意味的一致度を直接測るものではない。そこでリランキングモデルを後段に追加する構成が広く採用されている。
典型的なパイプライン構成
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側が結果を支配し、セマンティック検索の恩恵がほぼゼロになる。
症状として現れやすいパターン:
| 手法 | 概要 | 注意点 |
|---|---|---|
| Min-Max 正規化 | 各スコアを 0〜1 に変換 | 外れ値に引っ張られやすい |
| Z スコア正規化 | 平均0・標準偏差1に変換 | 正規分布に近い場合に有効 |
| RRF | 順位ベースで正規化不要 | スコア差の情報は失われる |
RRFを採用すれば正規化の手間を省けるが、スコアの大小を活かしたい場合は明示的な正規化付き線形結合が現実的だ。開発段階で両方のスコア分布をログ出力して可視化する習慣をつけると、ズレを早期に発見できる。
キーワード検索側のanalyzer/tokenizerが原因で検索精度が大きく落ちるケースがある。英語前提のBM25実装は空白区切りでトークン分割するため、日本語やタイ語のように単語間にスペースがない言語では正しく分割されない。
よく起きる問題
プラットフォーム別の対処
多言語ドキュメントが混在する場合は言語検出ステップを挟み、言語ごとに異なる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を組み合わせることで、どちらか一方では取りこぼすクエリをカバーする実践的な手法だ。型番・固有名詞・コードスニペットのようなキーワード一致が必要な場面と、意味的な近さで文書を探したい場面の両方に対応できる。
本記事で押さえたポイントを整理する。
発展的にはGraphRAGやAgentic RAGへの拡張も視野に入るが、まずはシンプルなハイブリッド検索で精度の底上げを確認してから段階的に進めるのが現実的だ。ハルシネーション低減と回答品質の向上は、検索層の改善なしには実現しにくい。ハイブリッド検索の導入を、RAG全体の品質改善サイクルの起点として位置づけてほしい。

Yusuke Ishihara
13歳でMSXに触れプログラミングを開始。武蔵大学卒業後、航空会社の基幹システム開発や日本初のWindowsサーバホスティング・VPS基盤構築など、大規模システム開発に従事。 2008年にサイトエンジン株式会社を共同創業。2010年にユニモン株式会社、2025年にエニソン株式会社を設立し、業務システム・自然言語処理・プラットフォーム開発をリード。 現在は生成AI・大規模言語モデル(LLM)を活用したプロダクト開発およびAI・DX推進を手がける。