埋め込み(embeddings)の選定と運用

この記事の目的

RAG外部の知識ソースを検索し、結果を LLM の入力に加えて回答の根拠にする手法。検索の判断を Agent に任せる構成は Agentic RAG と呼ばれる。・長期記憶・分類の土台である埋め込み(embeddings)モデルを、根拠を持って選定・評価・運用できるようになります。RAG 実装パターンが検索パイプライン全体を扱うのに対し、本記事はその一段下 — 「何が『近い』のか」「どのモデルを選ぶか」「更新でどう壊れるか」— に踏み込みます。

対象読者

• RAG や意味検索を実装し、埋め込みモデルの選定・乗り換え・評価を担当するエンジニア
• 「検索の精度が上がらない」原因を、埋め込みの層から切り分けたいエンジニア

前提知識

• RAG 実装パターン — 検索パイプライン全体(本記事はその埋め込み層の詳解)
• ライブラリ外の前提: ベクトル(数値の並び)と類似度のごく基本的な考え方

本文

概要: RAG 実装パターンとの分担

具体的な埋め込みモデルの製品名・価格はカタログ化しません(変化が速く、選定軸があれば公式情報で判断できるため)。本記事は選び方・評価・運用の安定した部分を扱います。

埋め込みとは: 何が「近い」のか

埋め込みとは、テキスト(や画像)を意味的な近さが距離に対応する数値ベクトルに変換したものです。似た意味の文が近いベクトルになるため、クエリと文書のベクトル距離で「意味の近い文書」を検索できます。

要点は、「近い」の中身はモデルの学習データとタスクで決まることです。あるモデルにとっての「近さ」は、別のモデルでは違います。だからこそ、埋め込みは「どれでも同じ」ではなく、自社のデータと質問で評価して選ぶ対象になります。類似度の指標(コサイン類似度など)自体より、モデルがその指標で何を「近い」と見なすかが本質です。

選定軸

埋め込みモデルは次の軸で選びます。製品名ではなく、この軸で候補を絞ります。

選定は勘ではなく評価で決めます(後述)。とくに日本語は、英語ベンチマークで上位でも日本語で振るわないモデルがあるため、自社データでの確認が要ります。

次元のトレードオフ

次元数(ベクトルの長さ)は、精度と保存・検索コストのトレードオフです。

• 高次元: 表現力が高く精度が上がりやすいが、保存容量・検索計算・メモリAgent が「覚えている」ように見えるデータの総称。短期記憶(コンテキスト)・作業状態・長期記憶(外部ストレージ)の 3 層に分けて設計する。が増える。数百万チャンク規模では次元数がそのままインフラコストに響きます
• 低次元: 安く速いが、細かい意味差を捉えにくい
• 次元削減という選択肢: 一部のモデルは、生成したベクトルの先頭 N 次元だけを使っても品質が保たれる設計になっています(切り詰めて次元を下げられる)。精度の劣化を評価で確かめたうえで、コストとのバランスで次元を選べます

「とにかく高次元」ではなく、評価セットで精度がほぼ変わらない最小次元を探すのが実務です。

非対称検索: クエリと文書は非対称

検索では、短い質問(クエリ)と長い文書(チャンク)を突き合わせます。この 2 つは性質が違うため、同じ扱いをしないほうが精度が上がることがあります。

• クエリと文書で埋め込みを変える: モデルによっては、クエリ用と文書用で異なる前処理(プレフィックスや指示文の付与)を推奨します。「これは検索クエリです」「これは検索対象の文書です」と役割を伝えると、非対称性を活かせます
• 指示付き埋め込み: 一部のモデルは、埋め込み時に「何のための埋め込みか」を指示として渡せます(タスク条件付き)。同じ文でも用途で近さを変えられます
• 公式の推奨に従う: この前処理はモデルごとに作法が異なるため、利用するモデルの公式ドキュメントの指示に従います(自己流のプレフィックスは逆効果になりえます)

チャンクサイズとの相互作用

埋め込みの品質は、渡すチャンクの大きさと切り離せません(チャンキング設計は RAG 実装パターン が正本)。

• 長すぎるチャンクは、1 つのベクトルに複数の話題が混ざり、「近さ」がぼやけます
• 最大入力長の超過時にどうなるかは API・ライブラリによって異なります。拒否するものも、切り詰め設定を持つものもあり、自動的に末尾だけが落ちるとは限りません。2026-09-10 に確認した OpenAI の embeddings API は、入力がモデルの最大トークン数を超えないことを要求しています
• 採用モデルに対応するトークナイザテキストとトークン列を相互変換する部品。分割のされ方は言語・内容で大きく変わり、モデル(世代)ごとに異なるため、コスト・コンテキストの見積りは公式のカウント手段による実測を正とする。ーで、プレフィックスや指示を含む実際の入力を事前に計数し、上限内に分割します。切り詰めを選ぶ場合も明示的に設定し、削られた区間を記録して必要情報の欠落を検知します
• したがって埋め込みモデルの選定とチャンクサイズの決定はセットで評価します。「モデルを変えたらチャンクサイズも再評価」が原則です

微調整はいつ効くか

汎用の埋め込みモデルで足りないときの手段が微調整(ファインチューニング既存モデルの重みを自分のデータで追加調整すること。形式・文体・ドメイン特化の挙動に加え事実知識も学習し得るが、正確な再現や容易な更新は保証されない。評価・データ準備・再学習の費用を、プロンプト改善・RAG・モデル変更と比較して選ぶ。)です。ただし最後の手段です。

• 効きやすいのは、語彙が特殊なドメイン(社内固有の略語・型番体系・専門用語)で、汎用モデルが「近さ」を誤るケースです
• 微調整には、そのドメインの「近い/近くないペア」の教師データが要ります。作成・維持のコストと、汎用モデルの乗り換え(後述の再インデックス)を天秤にかけます
• まず汎用モデルの選定・非対称検索・チャンクサイズ調整を尽くし、それでも評価で足りないと確認できてから検討します

評価: 自社の検索評価セットで比べる

埋め込みの良し悪しは、自社の質問と正解チャンクの対応表で測ります(公開ベンチマークの読み方の規律は エージェントベンチマークの全体像 と同じ — 参考にはするが最終判断は自社評価)。

• 質問と「その質問に答えるチャンク」の対応表を作り、候補モデルごとに再現率(recall@k)や正解チャンクの順位を比べます(評価データセットの構築と保守、検索評価の位置づけは RAG 実装パターン)
• 公開ベンチマーク(MTEB など)は候補の当たりを付けるのに使えますが、自社ドメイン・自社言語では順位が入れ替わりえます。カタログの順位を鵜呑みにしないこと
• 評価はコスト(次元・API 単価)と同時に見ます。精度がわずかに高いだけで大幅に高い・遅いモデルは、実務では割に合わないことがあります

運用の最重要問題: モデル更新 = 全再インデックス

埋め込み運用で最も高くつくのが、モデルを変えると全チャンクを埋め込み直す(全再インデックス)必要があることです。旧モデルのベクトルと新モデルのベクトルは同じ空間にないため、混ぜて検索できません。

• バージョンを固定・記録する: インデックスに埋め込みモデル名とバージョンを必ず記録します。「いつの間にかモデルが変わって検索が劣化」を防ぎます
• 更新は「デプロイ」として扱う: モデル変更は、新インデックスを別に構築 → 評価で新旧比較 → 切り替え(ロールバック可能に)、という手順を踏みます(バージョニングとモデル更新追従 と同じ考え方)
• API モデルの暗黙変更に注意: 提供側がモデルを更新・退役すると、意図せず全再インデックスが必要になります。バージョン固定できる提供形態を選ぶか、退役告知を監視します
• 移行コストが乗り換えの障壁になる: 数百万チャンクの再埋め込みは時間もコストもかかります。だからこそ最初の選定を評価で固める価値があります

実務での注意点

アンチパターン

チェックリスト

関連トピック

• RAG 実装パターン — 検索パイプライン全体(本記事の上位・正本)
• ベクトルデータベースの選定と運用 — 埋め込みを格納・検索する基盤
• LLM 向けデータ前処理パイプライン — 埋め込む前のチャンク・メタデータの準備
• 長期記憶の実装 — 記憶の想起にベクトル検索を使う側
• モデル選定ガイド — 埋め込みを含むモデル選定の一般論
• 評価データセットの構築と保守 — 検索評価セットの作り方
• バージョニングとモデル更新追従 — 再インデックスを含む更新運用

参考資料

• OpenAI: Create embeddings  — 入力上限を超えないことを求める API 契約の例(アクセス日: 2026-09-10)
• MTEB: Massive Text Embedding Benchmark  — 埋め込みモデルを多タスクで比較する公開ベンチマークの枠組み(当たり付けに使い、最終判断は自社評価)(アクセス日: 2026-07-08)

TODO・未確認事項