RAGは、LLMに外部ドキュメントを参照させることで、精度と信頼性を高める代表的なアーキテクチャです。その中核にあるのが「Embeddingモデルを使ったベクトル検索」です。
しかし、Embedding検索は構造的にできない領域があります。

この記事では、OpenAIの最新Embeddingを前提に、RAGにおけるEmbedding検索のできることとできないことを整理します。この記事を読み終えると、Embeddingでどこまで頑張れるのかがイメージできるようになるはずです。

※OpenAI の最新 Embedding(embedding-3 系)は詳細なアーキテクチャ非公開ですが、代表的な研究として、MSMARCOで23.4%改善したcpt-textというモデルがあります。

Embedding検索で「できること」

最新のEmbeddingは、word2vec時代の課題を乗り越え、強力な意味検索が可能になりました。

1. 意味的に近い文書を検索できる

Embedding検索の強みは、キーワード検索では拾えない「意味的に近い文書」を取ってこられる点です。Embeddingは意味の近さをベクトルで表現するため、自然言語で書かれた質問に対して、意味的に近い文書を探すことが得意です。

例えば、ユーザーのクエリが「営業のオンボーディング手順を知りたい」だった場合、
・新任営業向け研修マニュアル
・営業職の立ち上がり支援ガイド
といったタイトルのドキュメントをきちんと候補に挙げてくれます。

キーワード検索の場合、
・「オンボーディング」という単語がない
・「研修」「立ち上がり」など別表現になっている
といった理由で取りこぼしが発生しますが、Embeddingは「意味的な近さ」を学習しているため、こうした表現の揺れを吸収できます。

2. 表記ゆれや言い換えに強い

最新のEmbeddingモデルは、単語を細かい文字列に分解する“サブワード”という仕組みや、文脈依存の表現により、表記ゆれや言い換えにかなり強くなっています。

例:
・「りんご」「リンゴ」「林檎」
・「マネージャ」「マネージャー」
・「問題」「課題」「イシュー」

これらは完全に同一のベクトルになるわけではありませんが、ほぼ同じ意味空間に属するものとして扱われるため、検索結果としては十分に実用的です。

一部の固有名詞でまだ問題もあったりしますが、word2vec時代に大きかった「表記ゆれ問題」は、現代のEmbeddingではかなり軽減され、実務上は大きなボトルネックにはなりにくくなりました。

関連記事:自然言語処理の分散表現(Word2Vec,fastText)の課題

3. 多義語を文脈で区別できる

TransformerベースのEmbeddingは文脈依存であるため、多義語の問題をかなり解決してくれています。

例えば「ドライブ」という単語は、
・「車でドライブに行く」
・「DVDドライブが壊れた」
といった文脈で、それぞれまったく違う意味になります。

文脈依存Embeddingの場合、
・前者は「旅行・移動・車」の意味空間
・後者は「コンピュータ・ストレージデバイス」の意味空間

とベクトル空間の中で互いに離れた位置に配置されるため、RAGでの検索精度も大きく向上します。

4. 未知語・低頻度語にも比較的強い

word2vecなど過去のEmbeddingでは、コーパス中に1〜2回しか出てこない単語はほぼノイズ扱いでした。近年のEmbeddingモデルは、サブワードの分解や周辺文脈からの意味推定により、こうした低頻度語でもある程度まともなベクトルを生成できます。

そのため、製品名や新しい技術用語が混ざったドキュメントでも、一定の検索性能が出せるようになっています。

5. 高速で安定した検索が可能

Embeddingで生成したベクトルを、ANNインデックス(近傍探索アルゴリズム)などにより大規模でも高速な検索が可能です。

Supabaseのpgvectorベンチマークでは、OpenAI 埋め込み(1536 次元)・100 万ベクトル・HNSWインデックス・高スペック構成という条件で、平均応答時間 0.015 秒という結果が報告されています。

そのためEmbedding検索は、100万件、1000万件クラスのドキュメントから「だいたいこの辺が関係ありそう」という候補を高速に絞り込むのに最適です。

Embedding検索で「できないこと」

Embedding検索はとても有力な手法ですが、構造的にできないことが存在します。
これらはEmbeddingモデルの性能が悪いというわけではなく、テキストを数値に変換して類似度計算するという、Embedding検索の構造に起因します。

<課題の大枠の整理>
・テキスト同士の近さしか見ていない ⇒課題1,2,3,4
・論理的な条件処理が扱えない ⇒課題5
・文書レイアウトや図表などの見た目の構造を持てない ⇒課題6

1. 質問者の「意図」を理解した検索ができない

Embeddingは、クエリに書かれている内容(意味)をベクトル空間に写像する技術です。しかしそれは、質問の背後にある目的、重視する軸といった利用者側の目的性(意図)を直接反映したものではありません。

例えば、「この手順で一番注意すべきポイントは?」というクエリで検索すると、Embeddingが返す候補は、
・その手順の説明
・その作業の概要
・注意事項っぽい見出しを含む文

あたりでしょう。しかし、"注意すべきポイント"を本当に理解して拾ってくるわけではありません。なぜならそれは「意図」の領域です。"注意すべきポイント"が何を指すのかは、クエリには書かれていないからです。

※Embeddingは、推論や意図理解のプロセスを持ちませんが、LLM(GPT等)はこの「意図」を推論的に解釈しています。

2. 比較・評価・因果関係を理解した検索ができない

次のようなクエリも、Embedding検索では対応できません。
・「AとBのメリット・デメリットを比較したい」
・「このエラーの一番多い原因は何ですか?」
・「どのプランがコストパフォーマンスが良いですか?」

Embeddingは、似ている文書を取ってくることしかできず、関係性を処理できないため、どちらが優れているか、どの要因が原因として重要か、何がリスクとして大きいかといった判断は行えません。

3. 抽象的・概念的な質問に対して「適切な文書」を選択できない

例えば、
・「この機能の本質的な価値は何ですか?」
・「このサービスがユーザーにもたらす変化は?」
・「エンジニアの生産性とは何か?」

といった抽象的な問いは、どのような観点で説明するか、どのレベルの抽象度で答えるかといった判断が必要です。

Embeddingはテキストとの距離しか見ていないため、概念的に近い文書が集まるだけで、今のユーザーにとって一番役立つ説明が選べるわけではありません。

4. 検索後に「どの文書を最終的に使うか」判断できない

Embedding検索は、意味的な距離が近いベクトルを上位k件返すところまでしかやってくれません。
・本当に信頼できるのはどの文書か
・どの文書を優先してコンテキストに含めるべきか
・どの文書はノイズなので捨てるべきか

といった役立つ文書かどうかの判断は、Embeddingではできません。

5. 条件や制約を制御できない

Embeddingはクエリ全体を1つのベクトルに圧縮するため、複数条件を個別にコントロールしたり、A 条件を満たすが B 条件を満たさない候補を落とすといった厳密な制御ができません。

・「Windowsかつ Python 3.10 かつ GPUなし環境で動くインストール手順」
・「フルリモート可 かつ 年収600万以上 かつ 関東在住者向けの求人」

これらのクエリは、複数条件のAND/ORが含まれています。
ベクトル空間に論理は存在しておらず、「条件Aを何%満たす」「条件Bは満たしていない」という概念がないため、メタデータによるフィルタリングや、GPTの再判断が必要です。

6. 文書構造(章・節・項・図表)を理解できない

技術マニュアルや仕様書の理解では、章、節、項の構造や、図表などの文書構造の情報が重要になります。例えば「図3の説明文を探したい」「この手順の前提条件が書かれている箇所は?」といった問いには、ページ内のレイアウトや見出し構造の情報が重要です。

しかし、Embedding は単にテキスト列をベクトル化するだけなので、PDF のレイアウトやページ上の空間的な位置関係といった構造情報そのものは持てません。
図表やレイアウトを扱うには、Document Intelligenceなどのレイアウト解析などの工夫が必要です。

参考記事:Azure AI Document IntelligenceとLangChainを活用したRAGの実装


RAG設計のポイント:Embedding検索は一次フィルタと割り切る

ここまで見てきたように、Embedding検索は、Word2Vec時代の多義語・表記ゆれ・類義語の単語レベルの問題を大きく改善し、意味的な近さに基づく検索には強い一方、以下のような判断は苦手です。
・意図の理解
・比較・評価・因果推論
・最終的な文書選択
・条件の制御
・文書構造の理解

つまりEmbedding検索は、意味の近い文書を大量のドキュメント群から高速に拾ってくることは得意ですが、どの文書をどう使うべきかを判断することはできません。

RAGで高精度を目指す場合、Embedding検索で集めた候補に対して、LLM等での再ランキングや最終判断の処理を追加することが必要不可欠と感じます。

参考文献:

OpenAI “Text and Code Embeddings by Contrastive Pre-Training” — A. Neelakantan
OpenAI API ドキュメント “Embeddings” ガイド