Embedding Model

ひとことで言うと：Embedding Modelは、テキストや画像などの入力を、用途に関連する類似性や特徴が距離として扱えるような数値ベクトルへ変換するモデルです。^[1][2][3]

Embedding Modelとは

Embedding Model（埋め込みモデル）は、テキスト、画像、音声などの入力を、固定長または所定形式の数値ベクトルへ変換するモデルです。生成AIでは、Semantic Search、Vector Search、RAG、推薦、クラスタリング、重複判定などの基盤として使われます。

「文章を数字に変えるモデル」と説明されることがありますが、大切なのは単に数値化することではありません。学習された埋め込み空間では、用途に関連する類似性を持つ入力が近いベクトルになるよう設計・学習されます。そのため、ベクトル間の距離や角度を使って「どの入力が近いか」を計算できます。

埋め込みは何を表しているのか

Embeddingは、元の文章を可逆圧縮したものではありません。ベクトルから元の文章をそのまま復元できることを目的にした表現でもありません。入力の特徴を、多次元空間内の位置として表したものです。

テキスト埋め込みでは、ある検索用途で意味が似た文章が近づくよう学習されていることがあります。たとえば「犬の飼い方」と「家庭で犬を世話する方法」が近くなり、「企業決算の読み方」は離れる、といった配置が期待されます。

ただし、何が「似ている」と見なされるかはモデルの学習データ、学習目的、タスク指定、言語対応、ドメインに依存します。Embedding Modelは普遍的な意味の座標系を提供するわけではありません。

Dense EmbeddingとSparse Embedding

生成AIのRAGで「Embedding Model」と言うと、dense embeddingを生成するモデルを指すことが多くあります。Dense Embeddingは、数百〜数千次元程度のベクトルの多くの要素が非ゼロ値を持つ表現です。深層学習モデルによって意味的な類似性を捉える用途に使われます。

一方、Sparse Embeddingでは非常に高次元のベクトルの大部分がゼロになります。語彙に対応する次元を持ち、語の重要度や学習された語展開を表す方式もあります。BM25のような古典的スパース表現と、SPLADEのような学習型Sparse Retrievalを区別する必要があります。

したがって、「Embedding Model＝dense vector model」と固定して理解すると、近年のsparse embeddingやmulti-vector表現を見落とす場合があります。

どのように検索へ使うのか

Vector Searchでは、文書とクエリをEmbedding Modelでベクトル化し、その距離や類似度を計算します。Cosine Similarity、Dot Product、Euclidean Distanceなどが使われます。

重要なのは、検索側と文書側が互換性のある埋め込み空間にいることです。同じ次元数だから互換というわけではありません。別々のEmbedding Modelが作ったベクトルを、意味も確認せず直接比較してはいけません。

モデルによっては、query用とdocument用で異なるタスク指定やプレフィックスを要求します。これを無視すると、同じモデルを使っていても検索性能が落ちることがあります。

LLMとの違い

Embedding ModelとLarge Language Model（LLM）は、同じTransformer系技術を使うことがあっても役割が違います。LLMは次トークン予測を中心に文章生成や推論を行うモデルです。Embedding Modelは入力をベクトル表現へ写像し、比較や検索に使える表現を返すことを主目的にします。

RAGでは、Embedding Modelが検索候補を探すための表現を作り、LLMが検索されたテキストを読んで回答を生成する、という役割分担が一般的です。

このため、「LLMを最新版に変えたから検索も自動的に良くなる」とは限りません。Embedding Modelが別なら検索層はそのままです。逆にEmbedding Modelだけ変更すると、既存文書の再埋め込みが必要になる場合があります。

Worked example

FAQに次の二つの文章があるとします。

A: 「退職時には会社貸与PCを最終出勤日までに返却してください」 B: 「離職する社員は、支給されたノートPCを勤務終了日までに返す必要があります」

ユーザーが「辞めるとき会社のパソコンはいつ返す？」と質問した場合、語彙は完全一致しません。検索向けEmbedding Modelが「退職／辞める」「会社貸与PC／会社のパソコン」「最終出勤日／勤務終了日」の関係を近く表現できれば、AとBを近い候補として取得できます。

しかし、「PC」がpolitical correctnessの略として使われる文脈や、特定製品名の略称だった場合、埋め込みが想定と違う近さを作る可能性があります。意味は入力文脈と学習された表現に依存します。

次元数は性能の高さではない

製品説明では「3072次元」「1536次元」といった数字が示されます。次元数はベクトルの長さを表しますが、数字が大きければ必ず高性能という意味ではありません。

高次元は表現容量を増やせる一方、保存容量、ネットワーク転送、索引サイズ、検索計算量にも影響します。モデルによっては出力次元を短くする機能があります。品質とコストのトレードオフを評価する必要があります。

また、異なるモデル間で「次元数だけ」を比較して性能順位を決めることはできません。ベンチマーク、対象言語、ドメイン、検索タスク、長文処理、レイテンシなどを合わせて見る必要があります。

Embedding Modelの限界

Embedding Modelが作る類似性は、事実の正しさや論理的含意と同じではありません。「薬Aは薬Bより安全ではない」と「薬Aは薬Bより安全だ」は語彙的・意味的に近く埋め込まれる可能性がありますが、主張は逆です。

数値、日付、否定、細かな契約条件、コードの識別子なども注意が必要です。意味的に近い文書を探すことと、ユーザーの問いに必要な条件が一致することは別問題です。

Embedding Modelには入力長制限もあります。長文をそのまま入れると切り捨てられたり、複数話題が一つのベクトルに混ざったりするため、Chunking設計が重要になります。

モデル選定で見るべきもの

Embedding Modelを選ぶときは、一般的なベンチマーク順位だけでなく、自分の検索対象で評価することが重要です。

• 日本語や対象言語に対応しているか。
• 法務、医療、コード、商品検索など対象ドメインに合うか。
• query/document非対称検索を想定しているか。
• 最大入力長と実際のChunking方針が合うか。
• 次元数とストレージ・Latencyの条件が合うか。
• モデル更新時に既存ベクトルを再生成する必要があるか。
• どのSimilarity Metricを推奨しているか。
• 実データでRecall、nDCG、MRRなどを評価したか。

次に起こりやすい誤解

Embedding Modelを「文章の意味を完全に理解して、意味を座標にするモデル」と考えるのは過剰です。実際には、学習目的に沿って有用な類似性を表現するモデルであり、人間の意味判断を完全に再現するわけではありません。

また、「高性能Embedding Modelを使えばRAGの正答率も高い」という直接推論もできません。検索された候補の質は改善しても、Chunking、Hybrid Search、Re-Ranking、LLM、プロンプト、データ鮮度など別工程が最終結果を左右します。

元文脈へ戻るためのチェックリスト

Embedding Modelという語を見たら、次を確認します。

• 何を埋め込むモデルか。text、image、multimodalなど。
• dense、sparse、multi-vectorのどれか。
• どんなタスク向けに学習・最適化されているか。
• 出力次元と入力長の制約は何か。
• 検索時にquery/document用の指定が必要か。
• どの類似度指標を使うか。
• 対象言語・ドメインで評価されているか。
• モデル変更時の再indexing／再embedding要件は何か。

Embedding Modelというラベルから推論できるのは「入力を比較可能なベクトル表現へ変換する役割」までです。そのベクトルがどんな意味の近さを表し、どの用途で信頼できるかは、モデルの仕様と評価を別途確認する必要があります。

Query用とDocument用のEmbedding

検索向けEmbedding Modelの中には、クエリと文書を同じ書式で入力するのではなく、役割を明示してエンコードする設計があります。質問側は短く、文書側は長いという非対称な検索を想定し、学習時にもquery-documentペアを使います。

この場合、文書を埋め込むときと質問を埋め込むときに異なるtask typeやprefixを指定することがあります。設定を取り違えると、ベクトルの次元数は合っていても検索品質が下がります。

製品のサンプルコードでRETRIEVAL_QUERYやRETRIEVAL_DOCUMENTのような指定がある場合、それは単なるラベルではなく、モデルが用途に合わせた表現を作るための入力条件である可能性があります。

Fine-tuningとドメイン適合

汎用Embedding Modelは幅広いテキストを扱えますが、専門領域では用語関係が一般言語と異なる場合があります。法律、医療、バイオ、コード、特許、社内略語などでは、汎用モデルが重要な違いを十分に表現できないことがあります。

このため、ドメイン固有のペアデータでEmbedding Modelをfine-tuneしたり、専用モデルを選んだりする方法があります。ただしfine-tuningで一部ドメインの性能が上がっても、別ドメインの一般化性能が落ちる可能性があります。

モデル選定では、公開ベンチマークだけでなく、自分のデータから「このqueryにはこのdocumentが正解」という評価セットを作ることが重要です。

MultilingualとCross-lingual

多言語Embedding Modelでは、日本語クエリと英語文書のように言語が異なっても近い位置へ写像できることがあります。これはCross-lingual Searchに便利です。

ただし「多言語対応」と書かれていても、すべての言語で同じ品質とは限りません。日本語の専門用語、固有名詞、長文、混在言語での評価が必要です。

また、翻訳してから検索する方式と、直接多言語Embeddingで検索する方式では、誤差の入り方が違います。どちらが良いかはタスク次第です。

モデル更新の影響

Embedding Modelのversionを変えると、同じ文章でも別のベクトルになります。そのため、文書側を旧version、query側を新versionで作ると、検索品質が大きく崩れる可能性があります。

移行時には、新しいEmbeddingで文書を再計算し、別indexを構築して評価し、切り替える方法が安全です。大量文書では再Embeddingに時間とコストがかかるため、モデルversionは運用上の重要な依存関係です。

「APIのモデル名を一行変更すればアップグレード完了」と考えると、検索indexとの整合性を見落とします。

ベンチマークの読み方

Embedding Modelのランキングでは、MTEBなど複数タスクをまとめたベンチマークが使われます。便利な比較材料ですが、自社RAGの性能と一対一には対応しません。

検索対象が日本語の規程、クエリが短い型番中心、文書が数千token、Latency制約が厳しい、といった条件では、総合順位より個別条件への適合が重要です。

評価では、Recall@k、nDCG、MRRなどのRetrieval指標に加え、Embedding生成Latency、次元数、料金、最大入力長、再indexingコストも見ると実運用の比較になります。

関連するAI用語

• 埋め込み（Embedding）
• Vector Search
• ベクトルデータベース
• Dense Retrieval

注・出典

1. Google Cloud, Get text embeddings — text embeddingがdense vectorを生成し、意味に沿った検索へ利用されること ↩
2. Google for Developers, Measuring similarity from embeddings — cosine、dot product、Euclidean distanceと埋め込みの類似度 ↩
3. Milvus Documentation, Embedding Overview — dense/sparse embeddingと検索用途 ↩

AI協働制作について