キーワード検索とセマンティック検索の違いは何ですか？

BM25のようなキーワード（レキシカル）検索は、完全一致する単語を照合し、希少な単語に重みを付ける——精確だが同義語には盲点がある。セマンティック（ベクトル）検索は意味を埋め込みにエンコードして類似度で照合するため、言い換えや関連概念を捉えるが、IDやエラーコードのような正確なトークンを取りこぼすことがある。両者は正反対の状況で強みを発揮する。

ハイブリッド検索とは何ですか？

ハイブリッド検索は、キーワード（BM25）とベクトル取得の両方を並列で実行し、フュージョンアルゴリズムでランク付き結果を1つのリストにマージする。2つの手法が異なる形で失敗するからこそ存在する——ベクトルは同義語と概念を扱い、BM25は正確な単語・識別子・希少な専門用語を確実に捉える——そのため両者を組み合わせるとリコールとプレシジョンの両方が向上する。

Reciprocal Rank Fusion (RRF)とは何ですか？

RRFは、生のスコアではなくランク位置だけを使って2つのランク付きリストをマージする。各ドキュメントのフュージョンスコアは、リトリーバーにわたって1を（kとそのランクの和）で割った値の合計であり、kは小さな定数（一般的には60）だ。BM25とベクトル検索の互換性のないスコアスケールを無視するため、正規化が不要でそのまま使える。

ハイブリッド検索が純粋なベクトル検索より優れるのはどんな場合ですか？

クエリが自然言語と正確な識別子を組み合わせる場合、希少またはドメイン固有の専門用語を使う場合、ドメイン外のコンテンツに対して実行する場合、あるいは多言語の場合だ。十分に埋め込まれたドメイン内データに対する純粋に概念的な質問なら、純粋なベクトル検索で十分なこともある。コードや製品名が多い技術的なナレッジベースでは、ハイブリッドが明らかに優れている。

ベクトル検索が正確な単語やIDを取りこぼすのはなぜですか？

埋め込みはテキストを固定サイズのベクトルに圧縮して意味を捉えるが、正確なスペルは捉えない。そのため、エラーコード、SKU、頭字語などの希少なトークンは平滑化されて消えてしまう——この特性は「構造的盲点」と呼ばれることもある。モデルはあるパッセージが何について書かれているかは知っているが、検索した文字列そのものが含まれているかどうかは知らない。これがまさにBM25の得意とするところだ。

RRFと重み付きフュージョン、どちらを使うべきですか？

まずはRRFから始めよう：堅牢でパラメータが少なく、コーパスごとのチューニングが不要だ。一方のリトリーバーに偏らせる明確な理由がある場合に、重み付き（alpha）フュージョンへ切り替えよう——識別子の多いコンテンツで完全一致を優先するならalphaを低く、自然言語の質問でセマンティクスを優先するならalphaを高くする。

ハイブリッド検索はレイテンシやコストを増やしますか？それでも価値はありますか？

2回の取得とフュージョンステップを実行するためオーバーヘッドがあり、リランキングを加えるとさらに増える。ほとんどのRAGシステムでは、特に技術的または混合コンテンツのコーパスにおいて、リコールとプレシジョンの向上がそれを正当化する。十分に埋め込まれた純粋に概念的なデータを扱い、レイテンシが重要な場合は、純粋なベクトル検索で十分かもしれない——自分のクエリで計測してみよう。

← Resources

By Sora Kashiwagi — Senior Engineer, Vector Search · 2026-05-16 · TUTORIAL

ハイブリッド検索：RAGのためのBM25とベクトル検索の組み合わせ

キーワード（BM25）検索とベクトル検索は正反対の失敗パターンを持つ。だからこそ本番環境のRAGは両者を組み合わせる。本ガイドでは、両手法の仕組み、フュージョン（RRF）が結果をマージする方法、リランキングの役割、そしてハイブリッドが純粋なベクトル検索を明確に上回る場面を解説する。

異なる形で失敗する2種類の検索

BM25（レキシカル検索またはキーワード検索）は、完全一致する単語の重なりでドキュメントをスコアリングし、希少な単語により高い重みを与え、文書の長さにペナルティを課す。決定論的であり、転置インデックス上で動作する。ベクトル（セマンティック）検索は、クエリとドキュメントを密な埋め込みにエンコードし、最近傍類似度で取得することで、言語をまたいでも意味・同義語・言い換えを捉える。

それぞれの弱点は互いに鏡像の関係にある。BM25は同義語と概念を取りこぼす：「database memory issues」というクエリは、単語が異なれば「cache eviction policies」というタイトルのページを見つけられない。一方ベクトル検索は、正確なトークン——頭字語、SKU、エラーコード、ID、型番——を取りこぼし、セマンティックドリフトに悩まされる。「Nike running shoes」のクエリに対し、埋め込み上は近いが誤った「Adidas running shoes」を返すのが典型例だ。失敗パターンが互いに補完的であるため、どちらか一方だけでは不十分である。

ハイブリッド検索の仕組み

ハイブリッド検索は、レキシカル（BM25）と密（ベクトル）の取得を並列で実行し、2つのランク付き結果リストを1つにマージする。このマージ処理こそが肝心な部分だ。なぜなら、BM25スコアとベクトル類似度スコアはまったく異なるスケール上に存在し、単純に足し合わせることができないからだ。

そのため、主流のフュージョン手法であるReciprocal Rank Fusion (RRF)は、生のスコアではなくランク位置だけを使用する。各ドキュメントのフュージョンスコアは、両方のリトリーバーにわたって、1を（kとそのランクの和）で割った値の合計であり、kは小さな定数（一般的には60、20を用いる研究もある）だ。スコア分布を完全に無視するため、RRFは正規化が不要で「そのまま使える」——これが多くのベクトルデータベースでデフォルトになっている理由だ。

RRF vs 重み付きフュージョン

RRFが唯一の選択肢ではない。重み付き（alpha）フュージョンは、2つのスコアセットを正規化したうえで、調整可能な重みでブレンドする：alphaが0なら純粋なキーワード、1なら純粋なベクトル、0.5なら均等で、デフォルトはセマンティック寄りの0.75前後に設定されることが多い。相対スコアや分布ベースのフュージョンを提供するエンジンもある。

トレードオフはこうだ：RRFは堅牢でパラメータが少なく、コーパスごとのチューニングを避けたい場合に理想的だ。重み付きフュージョンは、識別子の多い技術コンテンツで完全一致を優先したい（alphaを低く）、あるいは自然言語の質問でセマンティクスを優先したい（alphaを高く）という明確な理由があるときに調整ダイヤルを提供してくれる。まずはRRFから始め、一方のリトリーバーに偏らせる明確な理由が出てきたら重み付きフュージョンに切り替えよう。

リランキングの位置づけ

ハイブリッド取得は第1ステージ、リランキングは第2ステージだ。高速なリトリーバー（BM25、ベクトル、またはハイブリッド）が候補セットを取得し、続いてクロスエンコーダーが、クエリとドキュメントを完全なクロスアテンションで単一パスで同時にエンコードしながら、各候補を再スコアリングする。クロスエンコーダーは第1ステージのリトリーバーよりはるかに高精度だが、コーパス全体に対して実行するにはコストが高すぎるため、上位k件の候補だけを再スコアリングする。

そのため、標準的な本番パイプラインは次のようになる：ハイブリッド取得（BM25 + ベクトル、RRFでフュージョン） → クロスエンコーダーまたはLLMリランカー → 上位結果をモデルのコンテキストへ。各ステージは最も得意なことを担う——まずリコール、最後にプレシジョンだ。

本当に効果があるのか？そしてosFoundryでの構築

効果は確かに存在するが、データに依存する。ElasticのBEIR研究では、RRFハイブリッドがBM25単独と比べて平均NDCG@10を約18%向上させ、強力な学習済みエンコーダーに対してもわずかな差で上回り、テストされたすべてのデータセットでBM25と同等以上の結果を示した。密なモデルの改善に伴い、ハイブリッドの限界的な上乗せ効果は縮小しており——ドメイン内データでは数パーセント程度のことも多い——それでもドメイン外コーパス、希少な用語、自然言語と正確な識別子が混在するクエリでは依然として最大の効果を発揮する。ハイブリッドは本番環境のデフォルトであり続けている。

osFoundryのカスタムRAGパイプラインは、これをブラックボックスではなく構成可能なステージとして公開する：BM25ステージとベクトルステージが並列に動作し、フュージョンステージ（デフォルトはRRF、オプションで重み付きも可）がそれらをマージし、リランキングステージがモデルに渡る前に結果を磨き上げる。コンフィグでナレッジベースごとにレキシカル対セマンティクスのバランスを調整でき、配管コードを書くことなくretrieve-fuse-rerankパターンを実現できる。

Frequently asked questions

キーワード検索とセマンティック検索の違いは何ですか？: BM25のようなキーワード（レキシカル）検索は、完全一致する単語を照合し、希少な単語に重みを付ける——精確だが同義語には盲点がある。セマンティック（ベクトル）検索は意味を埋め込みにエンコードして類似度で照合するため、言い換えや関連概念を捉えるが、IDやエラーコードのような正確なトークンを取りこぼすことがある。両者は正反対の状況で強みを発揮する。
ハイブリッド検索とは何ですか？: ハイブリッド検索は、キーワード（BM25）とベクトル取得の両方を並列で実行し、フュージョンアルゴリズムでランク付き結果を1つのリストにマージする。2つの手法が異なる形で失敗するからこそ存在する——ベクトルは同義語と概念を扱い、BM25は正確な単語・識別子・希少な専門用語を確実に捉える——そのため両者を組み合わせるとリコールとプレシジョンの両方が向上する。
Reciprocal Rank Fusion (RRF)とは何ですか？: RRFは、生のスコアではなくランク位置だけを使って2つのランク付きリストをマージする。各ドキュメントのフュージョンスコアは、リトリーバーにわたって1を（kとそのランクの和）で割った値の合計であり、kは小さな定数（一般的には60）だ。BM25とベクトル検索の互換性のないスコアスケールを無視するため、正規化が不要でそのまま使える。
ハイブリッド検索が純粋なベクトル検索より優れるのはどんな場合ですか？: クエリが自然言語と正確な識別子を組み合わせる場合、希少またはドメイン固有の専門用語を使う場合、ドメイン外のコンテンツに対して実行する場合、あるいは多言語の場合だ。十分に埋め込まれたドメイン内データに対する純粋に概念的な質問なら、純粋なベクトル検索で十分なこともある。コードや製品名が多い技術的なナレッジベースでは、ハイブリッドが明らかに優れている。
ベクトル検索が正確な単語やIDを取りこぼすのはなぜですか？: 埋め込みはテキストを固定サイズのベクトルに圧縮して意味を捉えるが、正確なスペルは捉えない。そのため、エラーコード、SKU、頭字語などの希少なトークンは平滑化されて消えてしまう——この特性は「構造的盲点」と呼ばれることもある。モデルはあるパッセージが何について書かれているかは知っているが、検索した文字列そのものが含まれているかどうかは知らない。これがまさにBM25の得意とするところだ。
RRFと重み付きフュージョン、どちらを使うべきですか？: まずはRRFから始めよう：堅牢でパラメータが少なく、コーパスごとのチューニングが不要だ。一方のリトリーバーに偏らせる明確な理由がある場合に、重み付き（alpha）フュージョンへ切り替えよう——識別子の多いコンテンツで完全一致を優先するならalphaを低く、自然言語の質問でセマンティクスを優先するならalphaを高くする。
ハイブリッド検索はレイテンシやコストを増やしますか？それでも価値はありますか？: 2回の取得とフュージョンステップを実行するためオーバーヘッドがあり、リランキングを加えるとさらに増える。ほとんどのRAGシステムでは、特に技術的または混合コンテンツのコーパスにおいて、リコールとプレシジョンの向上がそれを正当化する。十分に埋め込まれた純粋に概念的なデータを扱い、レイテンシが重要な場合は、純粋なベクトル検索で十分かもしれない——自分のクエリで計測してみよう。