第3章 アプリケーション開発 / 想定学習時間:30〜40分 / 最終確認:2026年8月

3-2. 埋め込みモデルの選定と設定

🎯 この節の学習目標

1. 埋め込みとは:テキストを「意味の座標」に変換する

埋め込み(Embedding)とは、テキストを固定長の数値ベクトルに変換することです。このベクトルは「意味の座標」として働き、意味が近いテキストほどベクトル空間上で近い位置に配置されます。たとえば「返品したい」と「商品を返送する方法」は字面こそ違いますが、埋め込みベクトルは近くなります。

RAG における検索(2章で準備したチャンクの類似検索)は、この性質を利用しています。

  1. インデックス作成時:全チャンクを埋め込みモデルでベクトル化し、Databricks AI Search(旧 Vector Search) インデックスに格納する
  2. クエリ時:ユーザーの質問を同じモデルでベクトル化し、インデックス内の近いベクトル(=意味の近いチャンク)を検索する

つまり埋め込みモデルは類似検索の品質を根本から決める部品です。ここでの選定を誤ると、後段でどれだけプロンプトを工夫しても「関係ないチャンクしか取れてこない」状態になります。

2. 選定基準:5つの観点

観点確認すること誤ると起きる問題
対応言語多言語対応か、英語のみか。扱う文書とクエリの言語をカバーしているか日本語文書に英語専用モデルを使うと検索精度が大きく低下する
ドメイン適合性法務・医療・コードなど、専門ドメインの語彙・意味関係を捉えられるか専門用語同士の類似性を捉えられず、的外れなチャンクがヒットする
次元数ベクトルの長さ。高次元ほど表現力が高い傾向だが、ストレージ容量と検索速度のコストが増える過剰な次元はコスト増、不足は精度低下(トレードオフ)
最大入力トークン1回に埋め込めるテキスト長の上限。チャンクサイズはこの上限以内に収める必要がある(2章のチャンキングと連動)上限を超えたチャンクは切り捨てられ、後半の内容が検索対象から消える
コスト・速度埋め込み対象の文書量とクエリ頻度に対して、料金とレイテンシが許容範囲か大規模文書群の再埋め込みが高コストになり、モデル変更の柔軟性を失う

💡 具体例:要件からモデル要件を導く

3. Databricks で使える埋め込みモデル

Databricks では Foundation Model API を通じて埋め込みモデルがサービングエンドポイントとして提供されており、例として databricks-gte-large-endatabricks-bge-large-en といった英語向け埋め込みモデルがあります(名前末尾の en は英語向けであることを示します)。エンドポイント名を指定するだけで、独自にモデルをデプロイせずに埋め込みを計算できます。

📝 試験のポイント

「日本語(または多言語)の文書を検索対象にする」というシナリオで、英語専用の埋め込みモデル(名前に en が付くもの)を選ぶ選択肢は誤りです。文書とクエリの言語をカバーする多言語対応モデルを選ぶ、という判断が問われます。

4. 最重要原則:インデックスとクエリで同じモデルを使う

埋め込みモデルに関する試験特に問われやすいの原則がこれです。

インデックス作成時(チャンクの埋め込み)とクエリ時(質問の埋め込み)には、必ず同一の埋め込みモデルを使う。

理由は2つあります。

  1. 次元の一致:ベクトル検索は同じ次元数のベクトル同士でしか距離を計算できません。モデルが違えば次元数が異なることが多く、そもそも検索が成立しません。
  2. 意味空間の一致:仮に次元数が同じでも、モデルごとにベクトル空間の「意味の配置」はまったく別物です。モデルAで埋め込んだチャンクをモデルBのクエリベクトルで検索しても、距離に意味がなく、無関係な結果が返ります。

この原則から、次の運用ルールが導かれます。

💼 ケース:検索結果が突然おかしくなった

あるチームが検索精度向上を狙って、クエリの埋め込みだけを新しいモデルに切り替えたところ、検索結果がほぼ無関係なチャンクばかりになりました。原因はインデックス側が旧モデルのベクトルのままだったことです。正しい手順は「新モデルで全チャンクを再埋め込み → インデックス再構築 → クエリも新モデルに切り替え」を一体で行うことです。

📝 試験のポイント

「埋め込みモデルを新しいものに変更した。次に必要な作業は?」→ ソース文書(全チャンク)を新モデルで再埋め込みし、インデックスを再構築するが正解の型です。「クエリ側だけ変える」「インデックスはそのままでよい」は典型的な誤答選択肢です。

5. チャンキング戦略との整合(2章の復習と接続)

埋め込みモデルの選定は、2章で学んだチャンキング戦略と相互に制約し合います。

組み合わせ考慮点
チャンクサイズ × 最大入力トークンチャンクはモデルの最大入力トークン以内に収める。超過分は暗黙に切り捨てられ、検索から漏れる
チャンクの粒度 × 埋め込みの表現力1チャンクに複数トピックが混在すると、埋め込みが「平均的な意味」になりどの質問にもヒットしにくくなる(2章:1チャンク1トピックの原則)
文書量 × 次元数・コスト文書量が多いほど、埋め込み計算コストとインデックス容量が次元数に比例して効いてくる

この節で埋め込みモデルが決まれば、次の 3-3 でそれを AI Search のインデックスに接続し、検索パイプラインを実際に組み立てます。

✅ この節のまとめ

練習問題

問1. RAG アプリケーションで、ドキュメントのインデックス作成に使った埋め込みモデルと異なるモデルでユーザーのクエリを埋め込んで検索した。最も起こりうる結果はどれか。

  1. 検索速度が向上する
  2. 意味空間(および多くの場合は次元数)が一致しないため、検索結果が無関係または検索自体が失敗する
  3. 結果は変わらない。埋め込みモデルは互換性がある
  4. クエリ側のモデルの精度が自動的に適用され、検索精度が向上する
解答と解説を見る

正解:B

ベクトル検索が意味を持つのは、インデックスとクエリが同一モデルの同一意味空間にあるときだけです。モデルが異なれば次元数が合わず検索が失敗するか、仮に次元が同じでも距離に意味がなくなり無関係な結果が返ります。埋め込みモデル間に互換性はなく(C)、速度や精度が向上すること(A・D)もありません。

問2. 日本語の社内文書を対象とした RAG システムを構築する。埋め込みモデルの選定として最も適切なのはどれか。

  1. 英語向けの databricks-gte-large-en をそのまま使う(埋め込みは言語に依存しないため)
  2. 日本語を含む多言語に対応した埋め込みモデルを選び、文書とクエリの両方に使う
  3. 文書は日本語のまま、クエリだけ英語に翻訳して英語専用モデルで埋め込む
  4. 埋め込みを使わず、キーワード検索のみで構築する
解答と解説を見る

正解:B

埋め込みモデルには学習した言語の範囲があり、英語専用モデル(名前末尾の en が目印)は日本語テキストの意味を適切にベクトル化できません(A)。Cは文書側が日本語のままでは意味空間が揃わず不成立です。Dはキーワード一致しか捉えられず、意味的類似検索という要件を満たしません。対応言語は埋め込みモデル選定の第一の確認項目です。

問3. 運用中の RAG システムで、埋め込みモデルをより高精度な新モデルに変更することにした。必要な作業として正しいものはどれか。

  1. クエリの埋め込みだけを新モデルに切り替える。インデックスは既存のものを使い続ける
  2. 全チャンクを新モデルで再埋め込みし、インデックスを再構築したうえで、クエリ側も新モデルに切り替える
  3. 新旧モデルのベクトルを同じインデックスに混在させ、徐々に移行する
  4. インデックスの次元数設定を新モデルに合わせて変更するだけでよい
解答と解説を見る

正解:B

モデル変更は「全チャンクの再埋め込み+インデックス再構築+クエリ側の切り替え」を一体で行う必要があります。Aはインデックスとクエリのモデルが食い違い検索が壊れます。Cは同一インデックス内で意味空間が混在し、距離計算が意味を失います。Dの設定変更では既存ベクトルの中身は旧モデルのままなので解決になりません。

問4. 埋め込みモデルの「最大入力トークン」がチャンキング戦略に与える影響として正しいものはどれか。

  1. チャンクサイズは最大入力トークンを超えてもよい。モデルが自動的に分割して埋め込むため
  2. チャンクが最大入力トークンを超えると超過分が切り捨てられ、その部分は検索でヒットしなくなるため、チャンクサイズは上限以内に設計する
  3. 最大入力トークンは生成される回答の長さの上限であり、チャンキングとは無関係である
  4. 最大入力トークンが大きいモデルほど、常に検索精度が高い
解答と解説を見る

正解:B

埋め込みモデルは上限を超えた入力を自動で賢く分割してはくれず、超過分は切り捨てられます。切り捨てられた内容はベクトルに反映されないため検索から漏れます。したがってチャンクサイズはモデルの最大入力トークン以内に設計します。Cは生成モデルの max_tokens との混同です。Dのように上限の大きさと検索精度が直結するわけでもありません(精度はモデルの表現力とチャンク設計で決まります)。