Semantic Searchとは

Semantic Searchは、検索queryと文書に同じ単語が含まれるかだけでなく、意味的にどれくらい近いかを使って関連情報を探す検索方式です。現在のAIシステムでは、文章をEmbeddingと呼ばれるベクトルへ変換し、queryと文書ベクトルの近さを比較する方法が広く使われています。

たとえば「会社を辞めたときの保険手続き」と検索した人に、「退職後の健康保険資格変更」という文書を返せれば、語が完全一致しなくても意図に近い検索ができます。これがSemantic Searchの典型的な価値です。

Keyword Searchとの違い

Keyword Searchは、queryに含まれる単語が文書にどれくらい現れるかを重視します。BM25などは、単語頻度や希少性を使って関連度を計算します。

Semantic Searchは、文章全体を意味表現へ変換し、言い換えや類似概念を捉えようとします。「自動車」と「車」、「有給の持ち越し」と「年次休暇の繰越」のように表現が違っても近い候補を見つけやすいのが利点です。

しかしKeyword Searchが古くて不要という意味ではありません。製品型番、法律条文番号、エラーコード、人名、固有名詞など、文字列一致が非常に重要な検索があります。

Embeddingがどう使われるか

Embedding Modelは、文章やqueryを固定長の数値ベクトルへ変換します。意味的に似たテキストが近いベクトルになるよう訓練されたモデルなら、cosine similarityやdot productなどで近さを計算できます。

文書側のEmbeddingを事前に計算してindexへ保存しておけば、queryが来たときにquery embeddingだけを計算し、近い文書ベクトルを探せます。Sentence-BERTなどの研究は、このようなsentence embeddingを高速なsemantic similarity searchへ利用できることを示しました。

Vector Searchと同じなのか

実務ではSemantic SearchとVector Searchがほぼ同じ意味で使われることがありますが、厳密には分けたほうが安全です。

Semantic Searchは「意味的に関連する情報を探す」という目的・検索概念です。Vector Searchは「ベクトル空間で近い点を探す」という計算方法です。

テキストEmbeddingを使うVector SearchはSemantic Searchの代表的実装です。しかしVector Searchは画像特徴、音声特徴、推薦用ユーザーベクトルなどにも使えます。逆にSemantic Searchは、知識グラフや別の学習ランキング手法を組み合わせることも可能です。

近いベクトル＝正しい答えではない

Embeddingで近い文書は、queryと意味的に関連している可能性が高いというだけです。文書の内容が正しい、最新、質問への答えを含むことまで保証しません。

たとえば「薬Aの副作用」を検索したとき、「薬Bの副作用」文書が非常に近い意味空間にある可能性があります。薬名の違いは意味全体に比べ小さく表現され、誤検索につながるかもしれません。

数値、否定、条件、固有名詞などの細かな差をEmbeddingが十分に保てない場合もあります。

Worked example：FAQ検索

ユーザーが「パスワードを忘れてログインできない」と入力したとします。

Keyword SearchではFAQ側に「パスワード」「ログイン」が含まれていれば見つけやすいです。Semantic SearchならFAQが「認証情報を失った場合の再設定」と書かれていても、意味的な近さで候補に上げられる可能性があります。

しかし「二要素認証端末を紛失した」FAQも認証トラブルとして近いかもしれません。Semantic Searchは候補集合を賢く広げますが、最終的な順位や分類には追加のRe-rankingが役立つことがあります。

多言語検索

多言語Embedding Modelでは、異なる言語の文章を同じ意味空間へ配置することを目指します。日本語queryから英語文書を探すcross-lingual retrievalも可能です。

ただし言語ごとの性能は均一ではありません。訓練データ量、専門用語、文字体系、ドメインによって差が出ます。「multilingual対応」というラベルだけで、すべての言語が同品質と考えないことが重要です。

Similarity metric

ベクトルの近さにはcosine similarity、dot product、Euclidean distanceなどが使われます。どれが適切かはEmbedding Modelの訓練方式に依存します。

モデル提供者が推奨するmetricと違うものを使うと性能が落ちる場合があります。また、embeddingを正規化するかどうかも影響します。

Semantic Searchの説明で「ベクトルDBに入れれば動く」とだけ書かれている場合、Embedding Modelとsimilarity metricの組合せを確認してください。

Approximate Nearest Neighbor

大規模な文書集合で全ベクトルを毎回比較すると遅いため、Approximate Nearest Neighbor（ANN）indexを使うことがあります。厳密な最近傍ではなく、非常に近い候補を高速に見つける方法です。

HNSWなどのindex方式では、検索速度、メモリ、recallのtrade-offがあります。Semantic Searchの精度はEmbedding Modelだけでなく、index設定にも影響されます。

Hybrid Search

実務では、Semantic SearchとKeyword Searchを組み合わせるHybrid Searchがよく使われます。意味の言い換えと、固有名詞の厳密一致を両方拾うためです。

たとえば「ERR-5042 接続タイムアウト」の検索では、エラーコードはkeywordで強く一致させつつ、「接続が切れる」という言い換えはsemantic側で拾えます。

「Semantic Search導入でkeyword検索を廃止」と単純化せず、データ特性に応じて使い分けます。

RAGでの役割

RAGではSemantic SearchがRetrieval手段として使われることが多いです。文書をchunkに分け、それぞれをEmbeddingし、query embeddingに近いchunkを上位取得してLLMへ渡します。

ただしRAG=Semantic Searchではありません。RAGはRetrievalとGenerationを組み合わせる構成で、RetrievalにBM25やWeb検索を使うこともあります。

元の文脈へ戻るチェック

Semantic Searchという語を見たら、①どのEmbedding Modelか、②対象言語・ドメイン、③similarity metric、④Vector DB/index方式、⑤top-k、⑥Re-ranking、⑦Keyword Searchとの併用、⑧評価データを確認します。

「意味検索で精度向上」という主張も、何をbaselineにして、どのqueryセットで、Recall@kやnDCGなど何を測ったかを見る必要があります。

次に起こりやすい誤解

Semantic Searchを知ると、「AIが文書の意味を人間のように理解して検索する」と表現したくなります。しかし実際には、学習された表現空間での近さを利用しています。文脈、否定、細かな条件、最新性、真実性を完全に理解するわけではありません。

Semantic Searchの強みは、言葉が違っても近い意味を候補として拾えることです。弱みは、その「近さ」が目的に合うかどうかをEmbedding Modelと評価データに依存することです。ここを押さえると、ベクトル検索の宣伝文句を現実的に読めます。

Embedding Modelの選択が核心

Semantic Searchでは、Vector DBよりもEmbedding Modelの質が意味表現を大きく左右します。一般文に強いモデル、コード検索に強いモデル、多言語に強いモデル、長文向けモデルなど、訓練目的が異なります。

社内文書の検索で、製品番号や略語が多いのに一般会話向けEmbedding Modelを使うと、期待ほど良くないことがあります。モデルのbenchmarkだけでなく、自分のqueryと文書で評価する必要があります。

Queryとdocumentの非対称性

検索ではqueryが短く、documentが長いことが多いため、両者を同じ方法で埋め込むだけでなく、「これは検索query」「これは候補文書」と役割を明示してEmbeddingするモデルがあります。

モデルによっては query: や passage: のようなprefixを推奨します。これを無視すると性能が落ちる場合があります。Embedding APIの利用例は単なる飾りではなく、訓練時の形式と一致させる意味があります。

Chunkingとの関係

長文を1本のembeddingにすると、複数トピックが平均化され、細かな検索意図を拾いにくくなることがあります。そのためRAGでは文書をchunkへ分けてembeddingします。

ただしchunkを短くしすぎると前後条件が失われます。Semantic Searchの精度問題に見えて、実はchunking設計が原因ということもあります。

Re-rankingで補う

Vector Searchで上位候補を高速に取り、Cross-EncoderやLLMでqueryと候補を一対一に詳しく比較してRe-rankingする構成があります。Embedding検索は大量候補の絞り込みに強く、Cross-Encoderは精密比較に強いという役割分担です。

このため「Semantic Searchの性能」を評価するとき、embedding-onlyなのか、re-ranking込みなのかを区別する必要があります。

Semantic similarityとrelevanceは同じではない

二つの文章が意味的に似ていても、検索目的に対してrelevantとは限りません。「iPhone 15の価格」と「iPhone 15のカメラ性能」は同じ製品について語るためEmbedding上は近いかもしれませんが、価格質問への直接回答ではありません。

良いSemantic Searchは、単なる一般的な意味類似だけでなく、検索タスクに適した関連性を学習している必要があります。Embedding benchmarkでも、STSのようなsimilarity評価とretrieval評価は別に見るべきです。

最新性・権限はベクトル距離に入らない

Vector similarityが高くても、古い文書を上位に出したくない場合があります。このとき日付filterやversion metadataを組み合わせます。同様にアクセス権もmetadata filterで制御します。

Semantic Searchは関連性スコアの一部であり、最終ランキングにはfreshness、authority、business ruleなどを組み合わせることがあります。

関連するAI用語

• Retrieval
• Keyword Search
• Hybrid Search
• Vector Search
• Embedding Model
• Re-Ranking

注・出典

1. Reimers & Gurevych 2019, Sentence-BERT：https://arxiv.org/abs/1908.10084
2. Yang et al. 2019, Multilingual Universal Sentence Encoder for Semantic Retrieval：https://arxiv.org/abs/1907.04307
3. Muennighoff 2022, SGPT: GPT Sentence Embeddings for Semantic Search：https://arxiv.org/abs/2202.08904

AI協働制作について

本記事は、著者が独自に設計した指示、参照資料、出典確認規則、著作権確認および監査工程を組み込んだChatGPT等の生成AIを、情報収集の補助、資料整理、構成検討、草稿作成、文章校正および監査補助に使用して制作しました。記事の対象範囲、情報源の採否、構成、解釈および最終表現は著者が判断し、最終稿を承認しています。著者は、本記事の正確性、独自性、引用、著作権処理および公開内容について責任を負います。制作工程の詳細は「AI協働制作方針」をご覧ください。 AI協働制作方針