Vertex AIのEmbedding TuningはRAGを改善するのか？検索精度・汎用性・運用コストで検証してみた

## はじめに RAG（Retrieval-Augmented Generation）は、LLM に外部知識を与えるための現実的な手法として広く使われるようになりました。弊社でも、社内外の文書検索、業務知識の活用、専門領域の問い合わせ対応などで検証を進めています。 一方で、最近は RAG の汎用的な精度向上がある程度打ち止めになってきた感覚があります。チャンク分割、クエリ書き換え、ハイブリッド検索、reranking などで着実な改善は可能ですが、既に一定水準に達したパイプラインをさらに大きく伸ばすのは簡単ではありません。 特に課題になるのが、顧客固有・業界固有の用語です。 - 社内略語・製品コードネーム - 業界特有の言い回し - 一般語としては近くないが業務上は強く関連する語 - 似ているが区別が必要な概念 ここで重要なのは、**LLM 本体が専門用語を知っていることと、Embedding が適切に検索できることは別問題**だという点です。 最近のフロンティアモデルは、Kubernetes のような IT 系の用語や、ある程度一般化された業界知識をかなり知っています。そのため、最終的な回答だけを見ると、LLM の内蔵知識でそれなりに答えられることがあります。 しかし RAG では、まず Retrieval 段階で正しい文書を引ける必要があります。LLM 本体が知っている用語であっても、Embedding モデルがその用語の言い換え、略称、近い概念との差分をうまく表現できなければ、正しいチャンクに到達できません。 つまり、問題は「LLM が答えを知っているか」だけではなく、**Retrieval 段階で正しい文書に到達できるか**にもあります。 この「検索で取りこぼす」問題を解決するために、Embedding 自体をドメインに合わせて fine-tuning できないか、というのが今回の出発点です。 本記事では、Vertex AI の **Tune text embeddings** を使い、Embedding tuning が RAG の検索性能と最終回答品質に与える影響と、そのコスト面での現実を検証します。 結論から言うと、今回の検証では **Embedding tuning は対象ドメインに対して base 比で改善しました**。また、別データセットでのデグレも小さく、汎用性能が大きく壊れることもありませんでした。 一方で、最新の Gemini Embeddings 2 がチューニングなしで同等以上の性能を示すケースもありました。さらに、チューニング済みモデルの推論には Vertex AI Endpoint での推論リソース管理が必要であり、通常の Embedding API のようにそのまま serverless に呼び出せるものではありませんでした。 今回のまとめは次の通りです。 **Embedding tuning は効く。ただし、軽くはない。 さらに、最新のフロンティア Embedding モデルがチューニングなしで同等以上になるケースもある。 そのため、まずは通常の RAG 改善や最新 Embedding モデルを試し、それでも顧客固有語や業界用語の検索に課題が残る場合に検討するのが現実的です。 ## 背景 ## 基盤モデルの fine-tuning で感じていた難しさ fine-tuning 自体には以前から期待がありました。 ドメイン知識を追加する、顧客ごとの業務に合わせる、専門領域に強くする、といった話をすると、自然とfine-tuning（微調整）という選択肢が出てきます。ビジネス面でも「顧客専用モデル」「業界特化モデル」という響きは分かりやすく、期待されやすい技術です。 ただ、基盤モデル、つまりLLM（大規模言語モデル）本体をfine-tuningする場合には、実務上いくつかの壁があります。 まず、fine-tuningはベースモデルの能力を大きく超える魔法ではありません。ベースモデルの知識量や推論力が十分でない場合、少量のドメインデータを追加しても、最新のフロンティアモデルに追いつくのは簡単ではありません。 次に、ドメイン知識を追加するだけでは、実用的なチャットモデルにはなりません。ユーザーの指示に従う、指定された形式で回答する、余計なことを言わない、といったinstruction following（指示従順）の能力も必要になります。ドメイン知識のfine-tuningとinstruction tuningをどう両立させるかは、思った以上に大きな問題でした。 最後に、運用コストがあります。fine-tuningした基盤モデルを実運用するには、何らかのGPUリソースが必要になります。モデルサイズが大きくなるほど、学習だけでなく推論時のコストも重くなります。精度が多少上がっても、運用コストまで含めると見合わない、という判断になりがちです。 まとめると、基盤モデルのfine-tuningには次のような難しさがあります。 - ベースモデルの能力に強く依存する - ドメイン知識だけでなくinstruction followingも考える必要がある - 学習後の推論コストが重い このため、基盤モデルのfine-tuningは効果があったとしても、実用化まで考えるとかなり重い取り組みになります。 ## なぜEmbeddingのfine-tuningに注目したか そこで発想を変えて、Embedding（埋め込み）だけをfine-tuningすることを考えました。 Embeddingであれば、基盤モデルのfine-tuningで問題になりやすい点をいくらか回避できるかもしれません。 Embeddingモデルは回答文を生成しないため、生成品質やinstruction followingには直接影響しません。学習対象も「このクエリとこの文書は近い」という関係であり、基盤モデル全体に新しい知識や振る舞いを覚えさせるよりも、問題を切り分けやすくなります。 また、RAG（Retrieval-Augmented Generation：検索拡張生成）の性能を分解すると、Retrieval（検索）とGeneration（生成）に分けられます。Embeddingのfine-tuningは、このうちRetrievalだけをピンポイントで改善する手法です。効果測定もしやすく、RAG全体の改善施策として扱いやすいと考えました。 さらに、Vertex AIにはEmbeddingをチューニングできるmanagedサービスが用意されています。もし学習から推論までmanagedかつserverlessに近い形で使えるなら、基盤モデルfine-tuningで問題になった運用コストの壁を越えられるかもしれません。 この期待から、Vertex AIのTune text embeddingsを試すことにしました。 ## Vertex AI「Tune text embeddings」 Vertex AI には、テキスト埋め込み（Embedding）を教師ありでチューニングする **Tune text embeddings** という機能があります。 公式ドキュメントはこちらです。 [https://cloud.google.com/vertex-ai/generative-ai/docs/models/tune-embeddings](https://cloud.google.com/vertex-ai/generative-ai/docs/models/tune-embeddings) 今回使用したベースモデルは text-multilingual-embedding-002 です。日本語クエリで評価したかったため、多言語対応モデルを選びました。 また、比較対象として OpenAI の text-embedding-3-large と、Gemini Embeddings 2 (gemini-embedding-2) も使用しました。 Google Cloud のドキュメントでは、公開ベンチマークにおいて、Embedding tuning（埋め込みの微調整）により最大 41%、平均 12% の品質改善があったと説明されています。 この数字だけを見ると、RAG（Retrieval-Augmented Generation：検索強化生成）の検索精度を向上させる手法としてかなり魅力的に映ります。 ここが今回のデータ作成で一番重要な部分です。 単にチャンク本文をそのまま質問にすると、キーワード一致で解ける簡単な評価セットになってしまいます。それでは Embedding tuning の差が出にくくなります。 そこで今回は、各チャンクの内容から LLM でクエリを生成する際に、次のような特徴を持たせました。 - 本文中の用語を別の自然な表現に言い換える - 具体的な用語を少し抽象化する - 似た概念と混同しやすい聞き方にする - 単語一致だけではなく、文脈理解が必要になるようにする つまり、単なる QA データではなく、Retrieval が少し難しくなる評価データを意図的に作っています。 例えば、本文にある専門用語をそのまま質問に含めるのではなく、実際のユーザーが曖昧に問い合わせそうな表現に寄せます。これにより、単純な lexical overlap ではなく、意味的に正しいチャンクを引けるかを評価しやすくなります。 ## train_labels.tsv クエリと文書の対応関係を表すラベルです。 query_id corpus_id score score は、そのクエリと文書の関連度を表します。 今回は、各チャンクから生成したクエリに対して、そのチャンク自身を正例として扱いました。つまり、「このチャンクの内容から作ったクエリなら、このチャンクに戻ってきてほしい」という教師データです。 本格的には、似ているが正解ではない文書、いわゆる hard negative も丁寧に設計した方がよいです。ただ、今回はまず実験基盤の構築と、Embedding tuning の効果確認を優先しました。 ## 実験 ## 実験設定 今回は、2 つのデータセットで検証しました。 1 つ目は、Kubernetes 公式ドキュメントです。 Kubernetes を選んだ理由は、公式ドキュメントが整備されていて取得しやすく、用語や概念も多いためです。一方で、Kubernetes は LLM や Embedding モデルにとって比較的得意な領域でもあります。そのため、今回の実験は「未知ドメインに対する最終検証」ではなく、「Embedding tuning の効果が出るかを確認する」位置づけです。 2 つ目は、某損害保険会社の約款です。 こちらは、Kubernetes よりも業務ドメイン寄りのデータとして用意しました。約款は表現や条項の構造に独特さがあり、一般的な Web 知識や IT ドキュメントとは異なる性質があります。顧客固有・業界固有の検索課題に近い対象として、Embedding tuning の効果を確認するために使用しました。 なお、某損害保険会社の約款は非公開データを含むため、本文ではデータの詳細は記載せず、概要と評価結果のみを扱います。 対象 評価データ Kubernetes 公式ドキュメント 50 件 某損害保険会社の約款 78 件 比較した Embedding モデルは次の通りです。 表記 モデル Vertex base text-multilingual-embedding-002 Vertex tuned text-multilingual-embedding-002 を対象データでチューニングしたもの OpenAI text-embedding-3-large Gemini Embeddings 2 gemini-embedding-2 RAG としての最終回答品質も確認しました。 項目 内容 回答生成 gpt-5.4 評価方法 LLM as a judge 評価モデル Claude Sonnet 4.5 評価スケール 1〜5点 なお、RAG 最終品質の評価には LLM-as-a-Judge を用いています。LLM による評価にはスコアのばらつきや評価モデルのバイアスが含まれる可能性があるため、ここでのスコアは絶対的な性能値ではなく、同一条件内での相対比較として扱っています。 ## Retrieval 評価の指標 Retrieval 評価では、主に MRR（Mean Reciprocal Rank）を見ました。 MRR は、正解チャンクの順位の逆数を平均した指標です。正解が 1 位なら 1.0、2 位なら 0.5、5 位なら 0.2 になります。RAG では、正解チャンクが単に検索候補に含まれるだけでなく、できるだけ上位に来ることが重要なので、MRR は実用上かなり重要な指標です。 ## 結果 ## Retrieval 性能 まず、Retrieval 性能です。ここでは MRR を比較します。 モデル Kubernetes MRR 損害保険の約款 MRR Vertex base 0.19 0.26 Vertex tuned 0.37 0.31 OpenAI 0.26 0.23 Gemini Embeddings 2 0.42 0.34 Retrieval 性能 Kubernetes では、Vertex tuned の MRR が 0.19 から 0.37 へ改善しました。ほぼ 2 倍です。 某損害保険会社の約款でも、Vertex tuned は 0.26 から 0.31 へ改善しました。改善幅は Kubernetesほど大きくありませんが、base比では改善しています。 この結果から、少なくとも今回の条件では、Embedding tuningによって対象ドメインのRetrieval性能は改善することが分かりました。 一方で、Gemini Embeddings 2にも注目する必要があります。Kubernetes では0.42、某損害保険会社の約款では0.34で、どちらもVertex tunedを上回りました。 つまり、Embedding tuning はベースモデルと比較して効果がありますが、最新のフロンティア Embedding モデルはチューニングなしでも同等以上の性能を示すケースがあります。 ## RAG としての最終品質 次に、検索結果を使って実際に RAG で回答させた場合のスコアを比較します。 | モデル | Kubernetes score | 損害保険の約款 score | | :--- | :---: | :---: | | no RAG | 2.24 | 2.15 | | Vertex base | 2.42 | 2.78 | | Vertex tuned | 3.04 | 3.06 | | OpenAI | 2.68 | 2.83 | | Gemini Embeddings 2 | 3.02 | 3.21 | RAG の品質について、Kubernetes では、Vertex tuned は Vertex base に対して 2.42 から 3.04 へ改善しました。RAG の最終回答品質においても、Embedding tuning（埋め込みモデルの微調整）の効果を確認できました。 某損害保険会社の約款でも、Vertex tuned は 2.78 から 3.06 へ改善しました。こちらも、Retrieval 性能と同様にベースモデルと比較して改善しています。 一方で、Gemini Embeddings 2 は Kubernetes では 3.02 と Vertex tuned にほぼ同等、某損害保険会社の約款では 3.21 と最も高いスコアになりました。 ここで見えてくるのは、次のような傾向です。 - Embedding tuning は対象ドメインでベースモデル比の改善を出す - その改善は RAG の最終品質にも一定反映される - ただし、最新の Gemini Embeddings 2 がチューニングなしで同等以上になる場合がある Retrieval 評価では MRR（平均逆順位）が大きく改善していても、RAG の最終スコアの改善幅はそれより小さくなることがあります。これは自然な結果だと思います。 RAG の最終回答は、検索だけで決まるわけではありません。 - LLM が元々持っている知識 - 検索結果の読み取り能力 - プロンプトの設計 - 評価データの難易度 - top-k（上位 k 件）に入っていれば何位でも回答できるケース などが絡みます。 特に Kubernetes のような一般的な IT 知識では、フロンティアモデルが内蔵知識だけである程度答えられるケースもあります。そのため、検索順位が大きく改善しても、最終回答の改善幅は圧縮されます。 ## 汎用データでのデグレ確認 fine-tuning（微調整）では、対象ドメインに最適化される一方で、汎用性能が壊れる可能性があります。 そこで、チューニングした Embedding モデルが、別の RAG データセットで劣化しないかを確認しました。 デグレ確認には、Allganize RAG Evaluation Dataset JAを使用しました。 [https://huggingface.co/datasets/allganize/RAG-Evaluation-Dataset-JA](https://huggingface.co/datasets/allganize/RAG-Evaluation-Dataset-JA) 結果は次の通りです。 モデル Kubernetes tuned 損害保険の約款 tuned no RAG 1.92 1.88 Vertex base 2.98 2.92 Vertex tuned 2.90 2.84 OpenAI 2.86 2.99 Gemini Embeddings 2 2.95 2.93 デグレ確認 Kubernetesでチューニングしたモデルは、Vertex baseに対して-2.4%でした。某損害保険会社の約款でチューニングしたモデルは、Vertex baseに対して-2.6%でした。 どちらも少し低下していますが、大きなデグレとは言いにくい結果です。少なくとも今回の範囲では、Embedding tuning（埋め込み調整）しても、汎用的な日本語RAG評価セットで大きく性能が壊れることはありませんでした。 これは重要な結果です。 Embedding tuningが対象ドメインで効いたとしても、他ドメインで大きく壊れるなら、実用上はかなり扱いづらくなります。しかし今回の結果では、対象ドメインで改善しつつ、汎用データでは大きな劣化は見られませんでした。 ## 考察 ## ここまでの結果は良好でした ここまでの結果だけを見ると、Embedding tuning（埋め込み調整）はかなり有望に見えます。 - KubernetesドメインではRetrieval性能が大きく改善 - 某損害保険会社の約款でもRetrieval性能が改善 - RAGの最終回答品質も改善 - 汎用データでの大きなデグレは見られない 基盤モデルのfine-tuning（微調整）と比べると、Embedding tuningはかなり扱いやすい印象でした。 基盤モデルのfine-tuningでは、モデルの回答品質、instruction following（指示従順性）、ハルシネーション（幻覚現象）、運用コストなど、考えることが多くなります。一方でEmbedding tuningは、検索対象との距離関係を改善する話なので、評価対象をRetrieval（情報検索）に切り分けやすいです。 RAGの改善手法としては、かなり素直です。 また、今回の追加検証で分かった重要な点として、某損害保険会社の約款のような業務ドメイン寄りのデータでも、base 比では改善が見られました。これは、Embedding tuning が Kubernetes のような IT ドキュメントだけに効くわけではない、という意味で前向きな結果です。 一方で、今回の結果では Gemini Embeddings 2 が非常に強い結果を示しました。 Kubernetes では、Gemini Embeddings 2 が Retrieval 性能で最も高く、RAG 最終品質でも Vertex tuned とほぼ同等でした。 某損害保険会社の約款でも、Gemini Embeddings 2 が Retrieval 性能と RAG 最終品質の両方で最も高いスコアになりました。 この結果から、Embedding tuning を考えるときには、単に「base モデルから改善するか」だけでは不十分だと分かります。 実務上は、次の比較が必要です。 - Vertex base と比べて改善するか - 最新の Embedding モデルと比べて優位があるか - 改善幅が運用コストに見合うか 今回の検証では、Vertex tuned は base 比では改善しました。しかし、Gemini Embeddings 2 と比較すると、同等または下回る結果でした。 つまり、チューニング済みモデルを作って運用する前に、まず最新のフロンティア Embedding モデルを試す価値はかなり大きいと感じました。 実際に進めてみると、もう 1 つ大きな問題がありました。 Tune text embeddings は、学習自体は Vertex AI の managed な仕組みで実行できます。しかし、チューニング済み Embedding モデルは、通常の Embedding API のようにそのまま呼び出せるわけではありません。 チューニング済みモデルを使うには、Vertex AI Endpoint にデプロイし、推論に使う machine type や accelerator などのリソースを管理する必要があります。 当初は、managed service という言葉から、学習後の推論も通常の Embedding API のように serverless に近い形で使えることを期待していました。 しかし実際には、チューニング済み Embedding モデルを運用するには、推論リソースをどこかで確保する必要があります。 これはかなり大きな違いです。 RAG の Embedding は、通常の検索クエリごとに呼ばれます。社内向け RAG や顧客向け RAG で常時 GPU endpoint を立てるとなると、利用頻度が十分に高くない限り、コストが見合わない可能性があります。 Embedding tuning による RAG 最終品質の改善に対して、GPU を含む推論リソースの運用コストを払うか、という判断になります。 ここはかなり悩ましいです。 今回の実験から分かったことを整理します。 まず、Embedding tuning そのものには効果があります。 Kubernetes でも某損害保険会社の約款でも、Vertex base と比較して Retrieval 性能は改善しました。特に Kubernetes では MRR がほぼ 2 倍になりました。正解チャンクがより上位に来るようになるため、RAG の検索品質改善としては素直に効いています。 また、RAG の最終回答品質も改善しました。 ただし、Retrieval の改善幅に比べると、最終回答の改善幅は小さくなります。これは、フロンティアモデルが元々ある程度の知識を持っていることや、検索結果の順位差を回答生成側がある程度吸収できることが理由だと思います。 次に、汎用性能のデグレは大きくありませんでした。 Kubernetes でチューニングしたモデルも、某損害保険会社の約款でチューニングしたモデルも、Allganize RAG Dataset で評価した範囲では、Vertex base に対して -2.5% 前後の低下に収まりました。この点は良い結果です。 一方で、最新の Gemini Embeddings 2 は非常に強い結果でした。今回の範囲では、Vertex tuned と同等またはそれ以上の性能を、チューニングなしで示しました。 さらに、最大の課題は運用コストです。 学習が managed で安価にできても、推論が通常の Embedding API のように使えないなら、実運用のハードルはかなり上がります。特に RAG の検索用途では、Embedding 生成は高頻度に呼ばれる可能性があるため、GPU endpoint のコストは無視できません。 つまり、今回の結論は次のようになります。 Embedding tuning は Retrieval を改善する。 RAG の最終回答品質にも一定の効果がある。 汎用性能も大きくは壊れない。 ただし、最新のフロンティア Embedding モデルがチューニングなしで同等以上になるケースがある。 さらに、推論時の GPU 運用コストを考えると、適用できるケースは限られる。 ## おわりに 本記事では、Vertex AI の Tune text embeddings を使い、Embedding tuning が RAG を改善するのかを検証しました。 結果として、Kubernetes ドキュメントと某損害保険会社の約款を対象にした評価では、Retrieval 性能が改善し、RAG の最終回答品質も向上しました。また、Allganize RAG Dataset を使ったデグレ確認では、大きな汎用性能の劣化は見られませんでした。 一方で、Gemini Embeddings 2 はチューニングなしでも Vertex tuned と同等以上の性能を示しました。また、チューニング済み Embedding モデルの推論には Vertex AI Endpoint での推論リソース管理が必要であり、当初期待していた serverless managed service とは違いました。 今回のまとめは、次の一文に尽きます。 Embedding tuning は効く。ただし、軽くはない。 RAG の精度向上が頭打ちになってきたとき、Embedding tuning は有力な選択肢になり得ます。ただし、まずは通常の RAG 改善や reranking、query rewriting、最新 Embedding モデルの利用などの軽量な手法を試した上で、それでも顧客固有用語や業界用語の検索に課題が残る場合に検討するのが現実的だと思います。 今後は、Vertex AI以外のオープンなEmbeddingモデルやオンプレGPU、クラウドGPUインスタンスを使った運用も含めて、実用的な構成を模索していきたいと思います。 翻訳全文

Vertex AIのEmbedding TuningはRAGを改善するのか？検索精度・汎用性・運用コストで検証してみた

背景や根拠まで確認しますか？

調べる

選ぶ

サイト