ハイブリッド検索とは — ベクトル検索＋BM25でRAGの精度を上げる設計

「A社の実績を出して」と検索したのに、トップに並んだのは競合のB社・C社の資料だった——ベクトル検索を入れた現場で、この取り違えは驚くほどよく起きます。型番で聞いているのに似た製品が返る、というのも同じ症状です。ベクトル検索はいまのRAGの定番なのに、なぜ肝心なところで外すのか。

答えは、検索を一本に頼っているからです。この記事では、ベクトル検索の弱点をキーワード検索とリランキングで補うハイブリッド検索の設計と、その底に流れる「ルールで解ける所はルールで解く」という考え方を、実装者の視点で書きます。検索は、私たちの経験では本番で最も大きく精度を落とし、かつ直したときの効果が一番大きい層です。全体像はRAG精度の診断ガイドにあり、この記事はその第2層「検索設計」を深掘りするものです。

ハイブリッド検索とは

ハイブリッド検索とは、性質の異なる複数の検索方式——実務ではほぼ「意味の近さで探すベクトル検索」と「語の一致で探すキーワード検索（BM25）」——を並走させ、結果を統合して一つの順位にまとめる検索構成のことです。単体では埋められない互いの弱点を補い合うのが狙いで、RAG（検索拡張生成）の検索部に限らず、社内文書検索やサイト内検索でも同じ構図が使われます。

「両方回すぶん遅くなりそう」と感じるかもしれませんが、2つの検索は並列に走らせられるため、体感の遅さにはつながりにくい構成です。効き方は文書と質問の性質によりますが、固有名詞・型番・条文番号が主役になる業務文書では、私たちの経験ではほぼ例外なく採用する価値がありました。以下、なぜ要るのか・どう組むのかを順に見ていきます。

なぜベクトル検索だけでは固有名詞を取りこぼすのか

ベクトル検索の強みは、言い換えへの強さです。「解約したいときの手続きは」と日常語で聞いても、「中途解約」「契約の解除」と書かれた条項までたどり着く。ここはベクトル検索の独壇場で、キーワード一致では拾えない曖昧な質問に効きます。

問題は、この「意味で寄せる」力が、区別してほしい場面でも働いてしまうことです。会社名・型番・条文番号のように一文字違えば別物になる情報ほど、ベクトルは「近い仲間」としてまとめてしまう。だから「A社の実績は？」に、そっくりなB社・C社の資料が平気で上位に並ぶ。正直に言うと、私も最初はベクトル1本で十分だと思っていました。固有名詞で何度も取り違えて、ようやく限界に気づいたのです。意味が近いことと、指しているモノが同じことは、別だ——これが検索設計の出発点です。

この限界は経験則だけの話ではありません。2025年に、埋め込みの次元が「上位に返せる文書の組み合わせ」の数を理論上縛ることが示されました。同じ論文の単純な検索課題（5万文書）では、Geminiの埋め込みが上位100件に正解を含められたのは10.0%だったのに対し、BM25は93.6%でした。ただし、文書側の語を同義語に置き換えた小規模版では、BM25が9割近く落ち、多くのベクトル検索のモデルより悪くなっています（Weller et al., ICLR 2026）。字面の一致に強いBM25と、言い換えに強いベクトル検索は、どちらか一方では足りない。だから並走させます。

ハイブリッド検索の設計 — 3つを組み合わせる

解決策は、検索を一本に頼らないことです。意味の近さはベクトル検索に任せ、固有名詞や型番のような厳密な一致はキーワード検索（BM25）で押さえ、最後にリランキングで「この質問に本当に答えているのはどれか」という観点で並べ直す。

ベクトルとキーワードという2つの検索結果を束ねる方法としては、RRF（Reciprocal Rank Fusion）が古典的で安定します。順位だけを使ってスコアを気にせず統合できるので、実装が単純で壊れにくい（Cormack et al., SIGIR 2009）。商社の案件では、このハイブリッド化が、正答率を38.8%から93.6%へ引き上げた改善の中で最も大きく効いた部分でした。

RRFか、スコアの重み付けか

統合にはRRFのほかに、それぞれの検索スコアを正規化して重み付きで足し合わせる方法（線形結合）もあります。重み付けは調整の自由度が高い一方、ベクトルとBM25ではスコアの分布がまるで違うため、正規化の設計と重みの調整が新たな保守ポイントになります。順位だけを使うRRFは、その調整自体を不要にする割り切りです。私たちは、まずRRFで土台を作り、評価セットで測って明確な理由が出たときだけ重み付けを検討する、という順番にしています。調整項目は、少ないほど壊れません。

リランキングを入れるかどうかでも答えが変わります。スコアを使う重み付けには、順位しか見ないRRFに無い調整の余地があり（Elastic, 2025）、リランキングが無い間は試す価値があります。効くかどうかは評価セットで確かめます。一方、強いリランカーを入れた後では、統合の工夫を足しても上積みが確かめられなかったという報告があります（Singh et al., 2026・査読前）。リランキングを入れているなら統合はRRFのまま据え置き、手間は後述の足切りとクエリ拡張に回します。

Difyのように、ハイブリッド検索の重みを画面で振れるツールもあります。Difyで固有名詞を外しているときにどの設定から触るかは、DifyでRAGの精度が出ないときに症状別の表で書きました。

ルールで解ける所は、ルールで解く

ここで、この記事でいちばん伝えたい考え方に触れます。ハイブリッド検索が効くのは、単に手法を足したからではありません。「意味の曖昧さ」と「厳密な一致」という性質の違う問題を、それぞれ向いた道具に振り分けているからです。

固有名詞の厳密一致は、答えが一意に決まる問題です。ここにLLMや凝った仕組みを持ち出す必要はありません。キーワード検索（BM25）は、統計に基づく確立された手法で、意味を推論しないぶん、ブレず・安く・速く・なぜその順位になったかを説明できる（Robertson & Zaragoza, 2009）。同じ発想で、記号や略称の正規化、通称から正式名称へのクエリ拡張も、まず辞書やルールで解けないかを先に考える。LLMで言い換えを作る場合は、言い換えた文をベクトル検索に渡し、キーワード検索には元の語も残します。ベクトル側は言い換えで拾う範囲を広げ、キーワード側は元の語の一致で順位を支える、という分担です。この分担で、言い換えない場合に比べ、BEIRの7種の評価で順位の指標（nDCG@10）が3.82%上がったと報告されています（Zhang, 2026）。

決定的に解ける処理をルールで固めることには、はっきりした利点があります。測定しやすく、出力がブレず、コストが低く、保守しやすい。LLMの出番は、それでも残る意味の曖昧さを吸収する所——曖昧な言い換えや、自由文の解釈——に絞る。検索の土台をルールで固めるほど、本番は安定します。「AIらしさ」で全部を解こうとせず、ルールで固められる所は固めて、LLMは曖昧さの担当に回す。これが、私たちが本番の検索で繰り返し確かめてきた線引きです。

リランキングで、上位を底上げする

ベクトルとキーワードで候補を広く集めたら、最後にリランキングで並べ直します。集める段階は「取りこぼさない」ことが仕事なので広めに拾い、並べる段階で「質問への適合度」で上位を締める。この役割分担があると、拾いすぎたノイズが上位を汚さずに済みます。

仕組みも補足しておきます。候補集めのベクトル検索は、質問と文書を別々にベクトル化して距離を測る（だから速く、大量の文書から引ける）のに対し、リランカーは質問と文書をペアで突き合わせて適合度を採点します。突き合わせるぶん判定は正確で、そのぶん遅く、コストもかかる。だから全文書には掛けず、検索で絞った上位数十件だけに掛ける——「広く速く集めて、狭く丁寧に並べ直す」という二段構えが、リランキングを入れるときの基本形です。

導入自体は重くありません。各社のリランキングAPIやオープンなリランカーモデルを、検索と生成の間に1段挟むだけで、既存の検索構成を作り替える必要はない。効き目を評価セットで測れる、着脱しやすい部品です。

改善の順番も決めておきます。私たちは検索の改善を、リランキングの導入→リランキングのスコアでの足切り→クエリ拡張→埋め込みモデルの見直し→取得件数（k）の調整、の順に進めます。先に挙げたSinghらの報告では、強いリランカーの後で確実に効いた追加策は、クエリ拡張と、出典ごとにスコアを較正する補正の2つだけでした（Singh et al., 2026）。根拠は査読前の報告1本なので、この順番も自社の評価セットで効き目を確かめながら進めます。

リランカーの候補は、日本語に特化した小型のもの（ruri-v3-rerankerなど）、多言語のもの（Qwen3-Reranker、bge-rerankerなど）、各社のAPIの3種類から取ります。公開ベンチマークのスコアは、条件がそろっていないことがあります。たとえば日本語の評価セットJQaRAは、評価用（test）とは別に学習に使える分割（dev・unused）を用意しており（JQaRA）、ruri-v3-rerankerはその分割を学習データに含めています（学習データのカード）。同じ形式の問題で学習したモデルと、学習していない多言語モデルとのスコアの差は、同じ条件での比較ではありません。学習データのカードで評価データとの重なりを確かめ、候補を2〜3本に絞ったら、自社の評価セットで比べて決めます。

足切りの値は、モデルと組で持つ

検索にはもう一つ、見落とされやすい設定があります。「このスコアより低い文書は候補にしない（候補が残らなければ答えない）」という足切りの値です。

足切りの値は、埋め込みモデルと文書の切り方の組み合わせごとに決まる値です。類似度スコアの出方は、モデルごとに違います。たとえばmultilingual-e5は学習の設定上、類似度がおおむね0.7〜1.0に集まり、モデルカード自身が「スコアの絶対値より順位が大事」と書いています（multilingual-e5-large）。埋め込みモデルを替えて足切りの値を旧モデルのまま据え置くと、関係のない質問まで足切りを通り抜け、答えや案内が出るようになります。

そこで3つを決めておきます。

• 断りの判定は、類似度でなくリランキングのスコアで行う。 リランカーは質問と文書を突き合わせて採点するので、「答えていない文書」を落としやすくなります。
• 値は評価セットから引く。 Cohereは、自社の領域の代表的な問い30〜50件について「関連するかどうかの境目にある文書」を用意し、そのスコアの平均を足切りの目安にする手順を示しています（Cohere）。正解の文書と無関係な文書のスコアの分布を並べて、境目を選びます。
• モデル・版・切り方と組で管理する。 どれかを替えたら値を引き直し、質問の種類ごとの前後差を確かめてから本番に出します。

日本語の全文検索で詰まるところ

日本語でキーワード検索を組むとき、つまずく所が2つあります。

1つは分かち書きです。日本語は単語の区切りが書かれていないので、BM25の前に文を語に分ける必要があります。形態素解析器のSudachiは、短い単位から固有表現の単位まで3段で分けられ、検索用に長い単位と短い単位を併せて出す設定があります（「関西国際空港」を「関西国際空港・関西・国際・空港」としてインデックスに入れる。elasticsearch-sudachi）。インデックス側とクエリ側で同じ辞書・同じ版を使い、社内の型番や略語は辞書に登録します。

もう1つは、PostgreSQLの全文検索です。「全文検索がある」ことと「BM25で順位を付けている」ことは別です。日本語対応で広く使われるPGroongaのスコア関数は語の出現回数だけを数える方式で、BM25ではありません（PGroonga）。pgbigmは2文字ずつの一致の度合いです。PostgreSQLの中で日本語のBM25を持つなら、ParadeDBのpgsearch（日本語の形態素解析にLinderaを使える・AGPL-3.0）やVectorChord-bm25が選択肢になります。BM25の拡張pg_textsearchは、分かち書きをPostgreSQLの検索設定に頼るため、日本語の設定を別に用意する必要があります。採点方式を確かめ、BM25が無ければアプリ側で計算するのも一つの手です。

どこまでやるか — 過剰設計を避ける

ハイブリッド検索まで来ると、多くの業務RAGは実用域に届きます。それでも、法令や規程のように条文が準用・参照でつながっている文書では、意味的に遠い準用先が抜けるので、参照をたどるGraph拡張を足す価値があります（法令RAGをGraph拡張で解いた事例）。

キーワードとベクトルのほかに、足せる経路が2つあります。1つは学習済みの疎ベクトルで、語の一致を土台にしながら、言い換えもある程度拾います。OpenSearchが2025年に公開した多言語モデルは、日本語の検索評価（MIRACL）の検索適合度でBM25の0.312に対して0.669と報告されています（OpenSearch, 2025）。もう1つは、PDFのページを画像のまま引く検索で、表・図・スキャンの多い資料で効きます。ただし、この方式の代表的な公開ベンチマーク（ViDoRe V3）には日本語が含まれていません（ViDoRe V3）。どちらも、自社の文書と質問で効き目を測ってから足します。

逆に、参照構造の無い文書にGraphを足しても、複雑さが増えるだけです。検索は「足せば足すほど良い」ものではありません。症状と文書の性質を見て、必要な分だけ組む。どの系統まで必要かの見立てはRAG精度の診断ガイドの系統選びにまとめています。

よくある質問

ハイブリッド検索はどんなときに必要ですか。

固有名詞・型番・規程番号のように、一字違うだけで別物になる語が出てくる業務文書なら、最初から並走させます。はじめから2系統で持っておくと、どちらの経路で拾えたかを評価で見比べられ、改善も速くなります。逆に、数十〜数百件で変わらないFAQのように文書が少なく固定なら、検索を組まずに全件をプロンプトに載せるほうが確実な場合もあります。

ベクトル検索とキーワード検索、どちらを主にすべきですか。

どちらかを主にするのではなく、並走させて統合するのがハイブリッド検索です。あえて言えば、業務文書では固有名詞の比重が大きいぶん、BM25の貢献が想像より大きくなります。

リランキングは必須ですか。

文書をチャンクに切って検索する作りなら、最初から入れておく部品です。検索の改善で最初に効くのもここで、リランキングのスコアは「答えていない文書」を落とす足切りにも使えます。リランキングが無いまま統合の重みや取得件数を細かく調整しても、入れた後には調整し直しになります。導入は検索と生成の間に1段挟むだけで、効き目は評価セットで測れます。

ハイブリッド検索のデメリットは何ですか。

検索を2系統持つぶん、インデックスの管理対象と統合部分の保守が増えることです。速度は2つの検索を並列に走らせられるため大きな問題になりにくく、実務で効いてくるのは運用の手間のほうです。統合をRRFで単純に保つのは、この保守コストを抑えるためでもあります。

主要な検索基盤でハイブリッド検索は組めますか。

組めます。Elasticsearch / OpenSearch はキーワード検索（BM25）とベクトル検索の両方を備えていますし、Azure AI Search はハイブリッド検索を標準機能として提供しています。PostgreSQL でも pgvector と全文検索の併用で同じ構成が組めますが、日本語の全文検索の拡張には採点がBM25でないものがあります（PGroongaのスコアは語の出現回数だけ）。採点方式を確かめてから選びます。基盤選びで詰まるより、統合と評価の設計に時間を使うほうが効きます。

埋め込みモデルを替えるとき、何を確かめればよいですか。

3つです。足切りの値を新しいモデルで引き直すこと（旧モデルの値を据え置くと、関係のない質問まで通り抜けます）。評価セットを全部流し、質問の種類ごとに前後差を見ること。アプリと推論サーバーの両方が同じモデル名・版を指しているかを、起動時に照合すること。モデル名を2か所で持っていると、片方だけ替わるずれが起きます。

検索設計の点検リスト

• ベクトル検索だけになっていないか。固有名詞をキーワード検索（BM25）で押さえているか。
• ベクトルとキーワードの結果をRRFなどで安定して統合できているか。
• リランキングで上位の適合度を底上げしているか。
• 足切りをリランキングのスコアで行い、その値を埋め込みモデル・切り方と組で管理しているか。
• 日本語の分かち書きと、全文検索の採点方式（BM25か）を確かめたか。
• 一意に決まる処理（厳密一致・正規化・略称展開）を、まずルールで解こうとしているか。
• 文書の性質に対して、検索が過剰・過少になっていないか。

検索の穴を、一緒に塞ぎませんか

「固有名詞で外す」「準用先が抜ける」という症状が出ているなら、検索を見直す余地があります。いまの構成と、どの種類の質問で外しているのかを聞かせていただければ、ハイブリッド化・クエリ拡張・参照辿りのどこに伸びしろがありそうか、当たりをつけてお伝えします。検索を含む全体像はRAG精度の診断ガイド、この検索設計が現場で効いた記録は商社の文書検索事例にあります。

参考文献

• Cormack, Clarke & Büttcher (2009) Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods, SIGIR — PDF
• Robertson & Zaragoza (2009) The Probabilistic Relevance Framework: BM25 and Beyond, Foundations and Trends in Information Retrieval — link
• Gao et al. (2023) Retrieval-Augmented Generation for Large Language Models: A Survey — arXiv:2312.10997
• Weller et al. (2025) On the Theoretical Limitations of Embedding-Based Retrieval, ICLR 2026 — arXiv:2508.21038
• Singh et al. (2026) Beyond the Reranker: Do RAG Retrieval Enhancements Help Once a Strong Reranker Is Present?（査読前） — arXiv:2606.28367
• Zhang (2026) Query Expansion Should Be Coordinated: Dense Expands, Sparse Anchors（査読前） — arXiv:2608.15851
• Elastic (2025) Hybrid search revisited: introducing the linear retriever in Elasticsearch — elastic.co
• Cohere, Best Practices for using Rerank — docs.cohere.com
• intfloat, multilingual-e5-large モデルカード（FAQ） — huggingface.co
• hotchpotch, JQaRA データセットカード — huggingface.co
• cl-nagoya, ruri-v3-dataset-reranker データセットカード — huggingface.co
• PGroonga, pgroonga_score function — pgroonga.github.io
• Works Applications, elasticsearch-sudachi — github.com
• OpenSearch (2025) Advancing search with OpenSearch v3 neural sparse models and a multilingual retrieval model — opensearch.org