セマンティック検索（Semantic Search）

キーワード検索との根本的な違い

従来のキーワード検索（BM25 に代表される Sparse Model）は、クエリに含まれる単語が文書中に出現するかどうかを直接評価する。「自動車」で検索すれば「自動車」を含む文書がヒットするが、「車」や「クルマ」は拾えない。

セマンティック検索は、この制約を超える。テキストをエンベディングモデルで数百〜数千次元のベクトルに変換し、ベクトルデータベース上で近傍探索を行う。「自動車の燃費を改善したい」と「車のガソリン消費を減らす方法」は、語彙はほぼ重複しないが、意味空間では近い位置に写像されるためヒットする。

どこで強く、どこで弱いか

セマンティック検索が得意なのは、言い換え・同義語・概念レベルの問い合わせだ。「退職手続きの流れ」と「会社を辞めるときにやること」のように、表現が異なるが意図が同じクエリに対して高い再現率を発揮する。社内ナレッジベースや FAQ 検索との相性がよい。

一方、型番（XR-990）・法令番号・プログラムコードのように語彙の完全一致が必要なクエリには弱い。エンベディング空間では「XR-990」と「XR-991」がほぼ同じ位置にマッピングされ、区別がつかないことがある。この弱点を補うために、BM25 と組み合わせるハイブリッド検索が実務で広く採用されている。

RAG における役割

RAG（Retrieval-Augmented Generation）では、セマンティック検索が検索フェーズの中核を担う。ユーザーの質問をベクトル化し、外部ナレッジベースから意味的に関連するチャンクを取得して LLM に渡す。このとき検索精度が低いと、LLM は関連のない文書をもとに回答を生成し、ハルシネーションにつながる。

検索品質を高めるための実務上の勘所は、エンベディングモデルの選定（多言語対応が必要か、ドメイン特化が効くか）と、チャンクサイズの設計だ。筆者の経験では、同じモデルでもチャンクを 256 トークンから 512 トークンに変えただけで Recall@10 が 10 ポイント以上動いたことがある。モデルとチャンクはセットで評価するのが鉄則になっている。