導入
「最新のベクトルデータベースを導入したのに、なぜかユーザーからの評判が芳しくない」
もしあなたがRAG（検索拡張生成）システムの構築・運用を担当しているなら、このようなジレンマに直面したことはないでしょうか。PoC（概念実証）段階では魔法のように思えたセマンティック検索（意味検索）が、いざ本番環境で多種多様なクエリに晒されると、意外な脆さを露呈することがあります。
特に、製造業の品番検索、社内規定の条項番号、あるいは特定のプロジェクトコードといった「一文字も間違えられない」クエリに対して、ベクトル検索は時として自信満々に誤ったドキュメントを提示してしまいます。「意味的には似ている」からです。
私たちはAIの可能性に魅了されるあまり、時として「最新技術こそが最善である」というバイアスに陥りがちです。しかし、システム開発の現場における一般的な傾向として、真の解決策は往々にして「新旧技術の融合」にあります。技術の本質を見抜き、ビジネスへの最短距離を描くことが重要です。
今回は、あえて時計の針を少し戻しましょう。1990年代から検索エンジンの裏側を支え続けてきた枯れた技術「BM25」を再評価し、それを最先端のベクトル検索と組み合わせる「ハイブリッド検索」について掘り下げます。そして、その二つを驚くほど簡単に、かつ効果的に統合する手法「Reciprocal Rank Fusion (RRF)」を用いた実装戦略を共有します。
これは、AIの魔法を否定するものではなく、AIをより実務で信頼されるパートナーへと進化させるための、泥臭くも確実なエンジニアリングの話です。
なぜ「ベクトル検索」だけでは実務で失敗するのか
ベクトル検索（Dense Retrieval）は、テキストを多次元の数値ベクトルに変換し、意味の近さを計算することでドキュメントを探し出します。これは「類義語」や「言い換え」に対応できる画期的な技術であり、従来のキーワード検索では拾えなかった情報を救い上げる力を持っています。
しかし、この「曖昧さを許容する」という最大の強みが、特定のビジネスコンテキストでは致命的な弱点となります。多くのプロジェクトで「導入初期は感動するが、実運用で失望する」というパターンが繰り返されるのは、この特性を過信しているためです。
「意味は合っている」が「答えは間違っている」現象
例えば、社内ドキュメント検索システムにおいて、ユーザーが「製品Aのv2.1の仕様書」を探しているとします。ベクトル空間において、「製品A」というコンテキストは強力に作用しますが、「v2.1」と「v2.2」というバージョンの違いは、ベクトル同士の距離（コサイン類似度など）で見ると極めて近接しています。
その結果、ベクトル検索エンジンは「v2.2」の仕様書を「意味的に非常に近い（ほぼ同じトピックを扱っている）」と判断し、上位にランク付けしてしまうことが頻繁に起こります。AIにとっては「誤差」レベルの違いでも、実務を担当するエンジニアにとって、バージョンの違いは「誤情報」以外の何物でもありません。
また、論理的な否定の扱いも苦手とする場合があります。「クラウドを利用しないケース」というクエリに対し、「クラウドを利用するケース」のドキュメントが高い類似度を示してしまうことも珍しくありません。最新の埋め込みモデル（Embedding Models）であっても、肯定文と否定文は多くの単語を共有しているため、ベクトル空間上で近傍に配置されやすいという課題は完全には解決されていません。
ベクトル空間における「固有名詞」の埋没問題
さらに深刻なのが、固有名詞や専門用語の扱いです。汎用的なモデルは、インターネット上の膨大なテキストで学習されていますが、特定の組織独自の「プロジェクト・フェニックス」や「コード3849」といった専門用語の意味を知りません。
未知の単語（Out-of-Vocabulary）や学習データに少ない単語は、一般的な単語の組み合わせとしてベクトル化されるか、あるいは特徴のないベクトルとして表現されがちです。その結果、ユーザーが特定の固有名詞でピンポイントに検索しても、そのキーワードが持つ「唯一無二性」がベクトル空間の中で希釈され、一般的なドキュメントの中に埋没してしまいます。
ユーザーが求めているのは「類似性」ではなく「正解」
検索システムを使うユーザーの心理を考えてみましょう。彼らがWeb検索のように「なんとなく知りたい」状態で使う場合、ベクトル検索がもたらすセレンディピティ（偶発的な発見）は歓迎されます。しかし、業務の中でRAG（検索拡張生成）を使う場合、その多くは「特定の問題を解決するための具体的な事実」を求めています。
最新の評価フレームワーク（Ragas等）を用いた検証でも、単純なベクトル検索のみの構成では、正確な情報を引き出す指標（Context RecallやPrecision）が伸び悩む傾向が報告されています。「類似性（Similarity）」と「適合性（Relevance）」は似て非なるものです。
ベクトル検索は前者を計算するのは得意ですが、後者、特にキーワードの完全一致が求められる厳密な適合性の判定においては、単独では限界があります。ここで、私たちが一度は通り過ぎてきた「あの技術」——つまり、キーワードベースの検索技術の再評価が必要となるわけです。
原点回帰：枯れた技術「BM25」がAI時代に輝く理由
BM25（Best Matching 25）は、1994年に発表されたランキング関数です。「今さら90年代の技術？」と思われるかもしれませんが、ElasticsearchやSolrといった従来の検索エンジンだけでなく、MilvusやAzure AI Searchといった最新のAI検索プラットフォームにおいても、ハイブリッド検索の中核技術として採用され続けています。
重要なのは、BM25というアルゴリズム自体が「枯れた技術」でありながら、その実装環境はAI時代に合わせて進化しているという点です。例えば、Milvusの最新バージョンではBM25統計情報のプリロードによる高速化が行われ、Azure AI Searchの最新APIではハイブリッド検索におけるBM25のランク付け制御が強化されています。これらは、BM25が単なる過去の遺産ではなく、現代のRAG（Retrieval-Augmented Generation）システムに不可欠な構成要素であることを証明しています。
TF-IDFの進化系、BM25のロバスト性
BM25は、基本的にはTF-IDF（Term Frequency - Inverse Document Frequency）の概念を拡張したものです。TF-IDFの核心は、「ある文書に頻繁に出てくる単語（TF）」は重要だが、「あらゆる文書に出てくるありふれた単語（DF）」は重要ではない、という考え方にあります。
例えば、「の」「です」「ます」といった単語は無視され、「RAG」「ハイブリッド」「RRF」といった希少な単語が含まれている文書が高く評価されます。
BM25がTF-IDFより優れている点は、単語の出現頻度（TF）によるスコア上昇に上限（飽和点）を設けていることと、文書の長さによる正規化を行っていることです。これにより、特定の単語を大量に詰め込んだだけのスパム的な文書が過剰に評価されるのを防ぎ、短い文書でも適切なキーワードが含まれていれば正当に評価されるようになっています。
「レアな単語」を重視するアルゴリズムの妙
この「希少な単語を高く評価する」という特性こそが、ベクトル検索の弱点を補完する完璧なピースとなります。
先ほどの「製品A v2.1」の例で考えてみましょう。「v2.1」という文字列は、ドキュメント全体の中では出現頻度が低い（レアな）キーワードである可能性が高いです。BM25は、この「v2.1」という記号がピタリと一致する文書に対して、極めて高いスコアを与えます。
ベクトル検索が「文脈全体」をぼんやりと捉えるのに対し、BM25は「ピンポイントなキーワード」を鋭く捉えます。人間が検索クエリを入力するとき、無意識のうちに最も重要だと思う単語（型番や固有名詞）を含める傾向があるため、BM25のアプローチは人間の検索意図（の表層的な部分）と非常に相性が良いのです。
キーワードマッチングが担保する「安心感」
実務において、キーワードマッチング（字句検索）は一種の「安心感」を提供します。「検索した単語が必ず含まれている」という事実は、結果の解釈を容易にします。ベクトル検索の場合、「なぜこれが検索されたのか？」を説明するのは困難ですが（ブラックボックス）、BM25なら「この単語が含まれていたからです」と明確に説明（Explainability）できます。
さらに、最新の検索パイプラインでは、BM25による初期検索結果を、Cohereの最新Rerankモデルのような高性能なクロスエンコーダーで再ランク付けする手法が一般的になっています。AIシステムの信頼性を高めるためには、魔法のような推論だけでなく、こうした予測可能で堅牢なアルゴリズムを土台に据えることが戦略的に重要です。
ハイブリッド検索の実装戦略：Reciprocal Rank Fusion (RRF) の活用
では、ベクトル検索（Dense）とBM25（Sparse）をどのように組み合わせればよいのでしょうか。これを「ハイブリッド検索」と呼びますが、実装には一つの大きな壁があります。それは「スコアの尺度が全く異なる」という点です。
ベクトル検索のスコアは通常、コサイン類似度（0.0〜1.0）などで表されます。一方、BM25のスコアは理論的な上限がなく、文書群の統計量によって大きく変動します（例えば 0.0〜50.0 など）。これらを単純に足し合わせたり、重み付け平均をとったりしようとすると、どちらかのスコアが支配的になり、調整（キャリブレーション）の泥沼にはまります。
そこで推奨したいのが、「Reciprocal Rank Fusion (RRF)」という手法です。
スコアの尺度が違う2つをどう混ぜるか
RRFは、スコアそのものではなく、「検索順位（ランク）」を使って統合を行います。具体的なアルゴリズムは非常にシンプルです。
$$ RRFscore(d) = \sum_{r \in R} \frac{1}{k + r(d)} $$
ここで、$d$はドキュメント、$r(d)$はその検索手法における順位、$k$は定数（通常は60程度）です。
簡単に言えば、「それぞれの検索手法で上位に来ているドキュメントほど、高いスコアを与えて合算する」という仕組みです。1位のドキュメントには大きなスコアを、10位のドキュメントには小さなスコアを与えます。
RRF（逆順位融合）による「調整不要」の統合
この手法の最大の利点は、スコアの正規化や複雑なパラメータチューニングが不要であることです。
ベクトル検索が「類似度0.85」、BM25が「スコア12.5」を出したとしても、RRFはそれらを気にしません。「ベクトル検索では3位」「BM25では1位」という順位情報だけを使います。これにより、全く異なる性質を持つ検索アルゴリズムを、対等かつ公平に混ぜ合わせることができます。
例えば、ベクトル検索で上位には入らなかったが、BM25で1位（キーワードが完全一致）だったドキュメントは、RRFによって総合順位の上位に浮上します。逆に、両方の検索でそこそこの順位だったドキュメントも、安定して上位にランクインします。
パラメータチューニングの泥沼を避ける
開発現場では、納期やリソースの制約が常にあります。「ベクトル検索の重みを0.7、BM25を0.3にしてみよう」「いや、クエリによっては逆の方がいい」といった重み付けの調整（Linear Combination）は、終わりのない作業になりがちです。経営者視点とエンジニア視点の両方から見ても、こうした調整コストは最小限に抑えるべきです。
RRFは、この調整コストを劇的に削減します。定数$k$（通常60）は、経験的に多くのデータセットで良好な結果を出すことがわかっており、ここを細かく調整する必要はほとんどありません。まずは動くプロトタイプを素早く作り、仮説を即座に形にして検証するアジャイルな開発において、RRFは非常に強力な武器となります。
さらに、最新の検索インフラストラクチャはこのハイブリッド検索の実装を強力にサポートし始めています。
- Milvusの最新バージョン: BM25の統計情報処理やパフォーマンスが最適化され、ハイブリッド検索の基盤としてより堅牢になっています。
- Azure AI Search: ハイブリッド検索におけるランク付け結果の量制御や、ベクトルクエリの重み付け機能が強化されており、より柔軟な統合が可能です。
- Cohere Rerank: RRFで統合された結果に対し、さらにクロスエンコーダーを用いた高精度なリランク（再順位付け）を行うことで、検索精度を極限まで高めるアプローチも一般的になっています。
このように、ElasticsearchやOpenSearchに加え、MilvusやAzure AI Searchといった主要なプラットフォームがハイブリッド検索機能を標準化・高度化させています。エンジニアはアルゴリズムの複雑な調整ではなく、これらのツールを適切に選定し、コンテンツの質やUIの改善に時間を割くべきです。実装のハードルは、皆さんが思っているよりもずっと低くなっています。
反対意見への応答：LLMのコンテキストウィンドウが広がれば検索は不要か？
ここで、技術トレンドに敏感な方なら一つの疑問を持つかもしれません。「ClaudeやGeminiの最新モデルのように、数百万トークン規模のコンテキストを扱えるLLMが登場しています。全ドキュメントをプロンプトに入力して読ませれば、RAGも検索も不要になるのではないか？」
確かに、ロングコンテキストLLMの進化は目覚ましいものがあります。しかし、実務的な観点から見ると、検索（Retrieval）の重要性は当面失われないと断言できます。
「全部読ませればいい」派への反論
まず、「Needle in a Haystack（干し草の中の針）」の問題があります。LLMは大量のコンテキストを与えられた際、その中ほどにある情報を見落とす傾向があることが複数の研究で示されています。数千ページのマニュアルを全て読ませて、その中からたった一行の「注意書き」を正確に抽出させるのは、依然としてリスクが高い処理です。
検索システムを使って、最初から関連性の高い数ページ（チャンク）だけに絞り込んでLLMに渡す方が、LLMの注意機構（Attention Mechanism）が分散せず、回答精度（特に幻覚の抑制）において有利に働きます。
コストとレイテンシの現実的な壁
次に、経済合理性です。毎回数百万トークンをLLMに入力すれば、APIコストは莫大なものになります。また、トークン数に比例して処理時間（レイテンシ）も増大します。ユーザーが質問してから回答が返ってくるまでに数十秒も待たされるチャットボットは、実用的とは言えません。
適切な検索システムでコンテキストを数千トークンに絞り込むことは、コストを大幅に圧縮し、数秒でのレスポンスを実現するために不可欠なエンジニアリングです。
情報の鮮度と更新性
最後に、情報の更新性です。ドキュメントは日々更新されます。LLMのコンテキストに毎回全データをロードするのは非効率ですし、ファインチューニングで知識を埋め込むのは更新頻度的に現実的ではありません。データベースのインデックスを更新するだけで最新情報に対応できるRAGアーキテクチャは、情報の鮮度が命であるビジネス環境において最も理にかなった選択肢です。
結論：AI検索は「意味（Vector）」と「単語（Keyword）」の両輪で走る
これまでの議論をまとめましょう。ベクトル検索は革新的ですが、万能ではありません。特に実務で求められる「正確性」や「固有名詞への対応」において、従来のキーワード検索（BM25）が持つ特性は、今なお強力な補完要素となります。最新のAI検索プラットフォームにおいても、BM25は過去の遺産ではなく、進化し続ける重要なコンポーネントとして位置づけられています。
銀の弾丸はない、適材適所のハイブリッド戦略
私たちはしばしば「古い技術を捨てて新しい技術に乗り換える」ことを進化だと捉えがちです。しかし、真の進化とは「使える道具を全て使いこなし、最適な組み合わせを見つけること」です。
ベクトル検索が捉える「文脈・意味」と、BM25が捉える「正確な語句」。この両輪が揃って初めて、AI検索システムはユーザーの意図を深く、かつ正確に理解することができます。実際、Milvusの最新バージョンではBM25統計情報のプリロードや最適化が行われ、Azure AI Searchでもハイブリッド検索におけるBM25のランク付け制御機能が強化されるなど、主要なプラットフォームは「ベクトル＋キーワード」の統合を加速させています。
そして、その二つを繋ぐRRF（Reciprocal Rank Fusion）や、Cohereなどが提供する最新のリランキングモデルは、エンジニアを複雑なパラメータ調整から解放し、精度の高い検索結果を導き出すための強力な接着剤となります。
明日から始める既存システムへのBM25追加
もし今、RAGの精度に悩んでいるなら、プロンプトエンジニアリングやモデルの再学習に走る前に、検索パイプラインを見直す価値があります。既存のベクトル検索システムを捨てる必要はありません。そこにサイドカーのようにBM25を追加し、結果をマージする処理を挟むことが、現代的かつスピーディーな解決策です。
多くのベクトルデータベースやクラウド検索サービスがハイブリッド検索を標準機能としてサポートし始めており、実装のハードルは以前よりも格段に下がっています。このアプローチは、低リスクで導入でき、それでいてユーザー体験を劇的に改善する可能性を秘めています。まずは手を動かし、実際にどう動くかを検証してみてください。
信頼されるAIエージェント構築のために
技術は手段であり、目的はユーザーの課題解決です。「AIなのに品番も分からないのか」と失望されるのではなく、「曖昧な聞き方でも、正確な型番でも、ちゃんと答えを見つけてくれる」と信頼されるシステムへ。
ハイブリッド検索は、そのための堅実な第一歩です。ぜひ、最新のツールチェーンを活用しながら「枯れた技術」の底力を引き出し、ビジネス価値を最大化するAIエージェントの開発に挑戦してみてください。
【実践ガイド】実務で使えるRRF実装とハイブリッド検索構成
本記事で解説したRRFの実装パターンや、主要な検索エンジンでの具体的な設定、さらにはハイブリッド検索のパフォーマンス比較データについては、技術的なリファレンスとして活用可能です。「理論はわかったけど、実際にどうコードを書けばいいの？」という疑問に応えるスニペットや構成例は、AI開発の現場における実装コストを大きく下げる助けとなるでしょう。
コメント