3. ベクトル検索とBM25の比較
密ベクトル検索（Dense Retrieval）の特徴
密ベクトル検索は、テキストを埋め込みモデル（Embedding Model: OpenAI の text-embedding-3 や BGE など）に入力し、数百から数千次元の高密度な数値配列に変換して類似度を測る手法です。
▸ 密ベクトル検索の強み
文章全体の文脈やニュアンス、同義語を理解できる点に最大の強みがあります。 たとえば、「お腹が痛い」という質問に対して、「胃の不調」「腹痛の治療法」といった異なる表現が使われた文書であっても、意味が近ければ上位に検索できます。 ユーザーが専門用語を知らずに自然言語で質問した際にも柔軟に対応できます。
▸ 密ベクトル検索の弱み
固有名詞、製品型番、エラーコード、人名などの完全一致を捉えることが苦手です。 たとえば、「Error-404-X9」と「Error-404-X8」は、ベクトル空間上ではほぼ同一の数値配列に変換されてしまい、微妙な英数字の差異を区別できません。 また、埋め込みモデルの計算コストやインデックス作成のメモリ消費量が大きい点も注意が必要です。
疎検索（Sparse Retrieval: BM25）の特徴
疎検索は、文書に含まれる具体的な単語の一致を手がかりに検索を行う手法であり、BM25 がその筆頭です。
▸ BM25の強み
入力されたキーワードそのものを厳密に検索するため、製品名、品番、プログラムの関数名、エラーコード、法令番号などの検索で抜群の正確性を誇ります。 また、事前の重いベクトル計算（GPU や Embedding API の呼び出し）が不要であり、CPU のみで超高速にインデックス作成と検索処理を実行できます。
▸ BM25の弱み
単語の「意味」や「言い換え」を理解できません。 「スマートフォンの電池持ち」で検索した場合、「スマホのバッテリー持続時間」と書かれた文書は単語が一致しないため、上位に表示されにくくなります。 また、スペルミスや表記揺れにも弱く、ユーザーが適切なキーワードを入力できないと見当違いの結果になることがあります。
ベクトル検索とBM25の比較対照表
両者の特徴を整理すると、下表のようになります。
| 比較項目 | 密ベクトル検索（Dense） | 疎検索（BM25 / Sparse） |
|---|---|---|
| 主なマッチング方式 | 意味的類似度（コサイン類似度・内積） | 単語の出現頻度と希少性（語彙一致） |
| 言い換え・同義語 | 非常に得意（自動的に吸収） | 苦手（同義語辞書等がないと不一致） |
| 固有名詞・型番・コード | 苦手（わずかな文字列差異を無視しがち） | 非常に得意（完全一致を確実に検出） |
| 計算リソース | 高い（Embeddingモデル計算・GPU推奨） | 非常に低い（CPUのみで軽量動作） |
| 初期構築コスト | Embedding API代やモデル準備が必要 | オープンソースやローカルCPUで即時利用可能 |
| 言語依存性 | 多言語対応モデルなら言語横断も容易 | 言語ごとの形態素解析やトークナイザーが必須 |
なぜハイブリッド検索が必要なのか
表からも明らかなように、密ベクトル検索と BM25 は、互いの弱点を完全に補い合う関係にあります。
実際の業務データでは、「概念的な質問（例：有給休暇の申請方法について）」と「具体的な質問（例：申請様式No.12-Bの提出先）」の両方が頻繁に行われます。 ベクトル検索だけに頼ると型番や固有名詞で誤検索が起き、BM25 だけに頼ると表現の揺らぎや口語表現に追従できません。
そのため、両方の手法で同時に検索を行い、スコアを合成して上位の文書を抽出する「ハイブリッド検索」が、実用的な RAG におけるデファクトスタンダードとなっています。 次章では、これらを実現するためのデータストアについて詳しく解説します。