ベクトル検索の限界は完全一致の取りこぼしにある
ベクトル検索単体では、エンタープライズの業務に耐えられないケースが多々あります。
意味的な近さを捉えることには長けていますが、特定の品番、社内固有の略語、あるいは人名といった「完全一致が求められる」クエリには構造的に弱いからです。
たとえば「A-1234」という特定の型番を検索する際、ベクトル空間上では「B-1234」や「A-1235」と距離が近くなり、意図しないドキュメントが上位にランクインしてしまいます。
そこで、意味の関連性を捉えるベクトル検索（Dense Retrieval）と、単語の完全一致を見るキーワード検索（Sparse Retrieval / BM25など）を組み合わせるハイブリッド検索が不可欠になります。
現場でPoCの精度評価を支援していると、「社内用語が全くヒットしない」というユーザーからの指摘で、プロジェクトの空気が一気にトーンダウンする光景を何度も見てきました。まずはこの弱点を直視し、適切な検索手法を組み合わせる設計が必要です。
検索結果の統合にはRRF（Reciprocal Rank Fusion）を使う
2つの異なる検索結果を統合し、最終的なランキングを作成するには、スコアの単純加算ではなく順位に基づくRRFが有効です。
ベクトル検索のスコア（例：コサイン類似度）とキーワード検索のスコア（例：BM25のスコア）は、全く異なる尺度で計算されています。そのため、正規化せずにそのまま足し合わせても、正しい評価や順位付けができません。
RRFは score = 1 / (rank + k) （通常 k=60）という非常にシンプルな計算式を用います。各検索手法での順位（rank）を元にスコアを再計算し、合算します。
これにより、スコアスケールの違いを吸収し、両方の検索で上位にきているドキュメントを確実に取り上げることができます。
実装自体は単純な計算式ですが、システムに組み込む際、検索マネージドサービス（Azure AI Searchなど）の標準機能に頼るか、アプリケーション層で独自実装するか、インフラ制約との板挟みになるのはよくあることです。
ハイブリッド検索とRRFの実装例
ハイブリッド検索をアプリケーション層で実装する場合の流れをまとめます。以下は、ベクトル検索とBM25の検索結果リストを受け取り、RRFで統合するシンプルなPythonのコード例です。
def calculate_rrf(vector_results, bm25_results, k=60):
rrf_scores = {}
# ベクトル検索の順位に基づくスコア加算
for rank, doc_id in enumerate(vector_results, start=1):
if doc_id not in rrf_scores:
rrf_scores[doc_id] = 0.0
rrf_scores[doc_id] += 1.0 / (rank + k)
# BM25検索の順位に基づくスコア加算
for rank, doc_id in enumerate(bm25_results, start=1):
if doc_id not in rrf_scores:
rrf_scores[doc_id] = 0.0
rrf_scores[doc_id] += 1.0 / (rank + k)
# スコアの降順でソートして返す
sorted_results = sorted(rrf_scores.items(), key=lambda x: x[1], reverse=True)
return [doc_id for doc_id, score in sorted_results]
# 実行例
vector_hits = ["docA", "docB", "docC"]
bm25_hits = ["docB", "docD", "docA"]
final_ranking = calculate_rrf(vector_hits, bm25_hits)
現場の要件定義において、ベクトルとBM25の重み付けをどう設定するかがよく議論になりますが、過度なパラメータチューニングに走る前に、まずは標準的なRRFでベースラインの精度を測るよう助言しています。
評価は実業務のクエリセットで行う
RAGの検索精度は、公開されているオープンなデータセットではなく、実業務のクエリセットで評価しなければ意味がありません。
事業部門ごとの特有の語彙や、エンドユーザーの入力揺れは、一般的なベンチマークテストでは測れないからです。
実際に業務で使われる想定のクエリ（例：過去のヘルプデスク問い合わせ履歴）を50件ほど抽出し、期待する正解ドキュメントがTop5に入る割合（Hit Rate@5）などを測定します。
ハイブリッド検索を導入する前後でこのHit Rateを比較し、業務要件を満たす水準に達しているかを定量的に判断します。
統計的な精度指標が数パーセント上がったかどうかよりも、現場のユーザーが「これなら業務で使える」と実感できる閾値を見極めることが、アーキテクトとしての重要な役割だと考えています。
まとめ
ベクトル検索とキーワード検索を組み合わせたハイブリッド検索は、RAGの精度課題に対する確実な一手となります。
一方で、インデックスサイズの肥大化や、2回の検索を発行することによるレイテンシの増加というトレードオフも伴います。