はじめに
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と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
今回使用したベースモデルは text-multilingual-embedding-002 です。日本語クエリで評価したかったため、多言語モデルを選びました。
また、比較対象としてOpenAIのtext-embedding-3-largeと、Gemini Embeddings 2 (gemini-embedding-2)も使用しました。
Google Cloudのドキュメントでは、公開ベンチマークにおいて、Embedding tuningにより最大41%、平均12%の品質改善があったと説明されています。
この数字だけを見ると、RAGの検索精度改善手法としてかなり魅力的です。
学習コスト
Tune text embeddingsの学習はVertex AI Pipelines上で実行され、GPUインスタンスの利用時間に応じた従量課金になります。
今回の検証では、学習時間はおよそ2時間で、コストは数ドル程度でした。少なくとも小規模な検証であれば、学習コスト自体はかなり軽い印象です。
この時点では、学習がこれだけ軽いなら、推論も通常のEmbedding APIのようにserverlessで使えて、トークン課金ではないかと期待していました。
この期待は、後半で少し裏切られます。
Embedding fine-tuningの学習データ
tripletの考え方
Embeddingのfine-tuningでは、クエリと文書の関係を学習します。
概念的にはtripletで考えると分かりやすいです。
- anchor: 検索クエリ
- positive: 正解文書
- negative: 不正解文書
例えば、Kubernetesのドキュメントで考えると、次のようなイメージです。
- anchor: 「コンテナが何度も落ちて再起動する原因を調べたい」
- positive: anchorに関係するCrashLoopBackOffに関する説明チャンク
- negative: anchorに関係しないDeploymentのreplica数に関する説明チャンク
このとき、Embedding空間上ではanchorとpositiveを近づけ、anchorとnegativeを遠ざけたいわけです。
ただし、Vertex AIのTune text embeddingsでは、明示的なtriplet形式そのものではなく、以下の3つのファイルを用意します。
corpus.jsonl
検索対象となる文書群です。
1行1JSONのJSONL形式で、各行に文書IDと本文を入れます。
{"_id": "doc_001", "text": "..."}
今回の実験では、対象文書をチャンク分割し、各チャンクを1つのcorpus itemとして扱いました。
queries.jsonl
検索クエリの一覧です。
{"_id": "query_001", "text": "..."}
ここが今回のデータ作成で一番重要な部分です。
単にチャンク本文をそのまま質問にすると、キーワード一致で解ける簡単な評価セットになってしまいます。それでは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では、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はbase比では効くものの、最新のフロンティアEmbeddingモデルがチューニングなしで同等以上の性能を示すケースがあります。
RAGとしての最終品質
次に、検索結果を使って実際にRAGで回答させた場合のスコアを比較します。
Kubernetesでは、Vertex tunedはVertex baseに対して2.42から3.04へ改善しました。RAGの最終回答品質でも、Embedding tuningの効果が確認できました。
某損害保険会社の約款でも、Vertex tunedは2.78から3.06へ改善しました。こちらも、Retrieval性能と同じくbase比で改善しています。
一方で、Gemini Embeddings 2はKubernetesでは3.02とVertex tunedにほぼ同等、某損害保険会社の約款では3.21と最も高いスコアになりました。
ここで見えてくるのは、次のような傾向です。
- Embedding tuningは対象ドメインでbase比の改善を出す
- その改善はRAG最終品質にも一定反映される
- ただし、最新のGemini Embeddings 2がチューニングなしで同等以上になる場合がある
Retrieval評価ではMRRが大きく改善していても、RAGの最終スコアの改善幅はそれより小さくなることがあります。これは自然な結果だと思います。
RAGの最終回答は、検索だけで決まるわけではありません。
- LLMが元々持っている知識
- 検索結果の読み取り能力
- プロンプトの設計
- 評価データの難易度
- top-kに入っていれば何位でも回答できるケース
などが絡みます。
特にKubernetesのような一般的なIT知識では、フロンティアモデルが内蔵知識だけである程度答えられるケースもあります。そのため、検索順位が大きく改善しても、最終回答の改善幅は圧縮されます。
汎用データでのデグレ確認
fine-tuningでは、対象ドメインに最適化される一方で、汎用性能が壊れる可能性があります。
そこで、チューニングしたEmbeddingモデルが、別のRAGデータセットで劣化しないかを確認しました。
デグレ確認には、Allganize RAG Evaluation Dataset JAを使用しました。
https://huggingface.co/datasets/allganize/RAG-Evaluation-Dataset-JA
結果は次の通りです。
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ドキュメントだけに効くわけではない、という意味で前向きな結果です。
ただし、最新のフロンティアEmbeddingモデルは強い
一方で、今回の結果では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モデルを試す価値はかなり大きいと感じました。
さらに、推論時にGPU endpointが必要だった
実際に進めてみると、もう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は「効くが軽くはない」
今回の実験から分かったことを整理します。
まず、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インスタンスを使った運用も含めて、実用的な構成を模索していきたいと思います。
