EmbeddingGemma 2をローカル導入する際の移行リスクガイド

EmbeddingGemma 2をローカルで動かすからといって、既存の埋め込みサービスをそのまま置き換えられるとは限りません。アプリケーション側の変更を抑えたままランタイムを移行できるケースはありますが、ベクトルの表現仕様が変わるなら、通常はベクトルの再生成が必要です。安全に進めるには、モデルをどう実行するか、既存ベクトルとの互換性が本当にあるか、そして手元のデータでマルチモーダル検索が十分な品質になるかを分けて判断しましょう。

移行の判断を一枚で整理する

テキスト、コード、画像、動画、音声を同じモデルファミリーでローカル埋め込みにしたい場合は、EmbeddingGemma 2が有力です。ただし、計画的なバックフィルを実施できることが前提になります。ドキュメント側の更新を後回しにして、本番のクエリエンコーダーだけを先に切り替えるのは避けてください。埋め込みモデルは、ベクトル次元が同じに見えてもインデックスのスキーマの一部です。

Googleのモデルカードでは、768次元時の指標として、MTEB multilingual v2が61.36、MTEB code v1が78.68、ビジュアルドキュメント検索のNDCG@5が67.84、動画検索のHit@1が50.67、音声検索のMRR@10が69.54と報告されています。いずれも参考値であり、実際のクエリに対する検証の代わりにはなりません。

EmbeddingGemma 2への移行で変わるもの、変わらないもの

EmbeddingGemma 2は、テキスト、コード、画像、動画、音声を共通の768次元空間にマッピングします。チェックポイントはモジュール構成になっており、公式開発者ガイドでは、テキスト専用の270M構成、テキスト＋視覚の440M構成、テキスト＋音声の570M構成、すべてを含む740M構成が説明されています。エンコーダーを無効にすればロードされる重みとピークメモリは減りますが、それだけで別の意味空間が生成されるわけではありません。

この違いは移行時に重要です。Googleはこれらの構成が互換性のあるベクトル空間を共有すると説明しているため、270M構成で生成したテキストクエリと、フル構成で生成したEmbeddingGemma 2のドキュメントベクトルは比較できます。ただし、以前のEmbeddingGemma 1、Qwen、Nomic、あるいはAPIプロバイダーのベクトルを、768個の座標を持つという理由だけでEmbeddingGemma 2のクエリと安全に比較できるわけではありません。

タスク用のフォーマットも表現仕様の一部です。非対称検索では、EmbeddingGemma 2はtask: search result | query: ...のような検索クエリ用の指示と、title: ... | text: ...のようなドキュメント形式を想定しています。コード検索には専用のタスク指示があります。以前のパイプラインで異なるプレフィックス、チャンク分割、正規化、入力フィールドを使っていたなら、それらの変更を新しい表現バージョンとして記録し、移行の一部として検証してください。

ランタイムは、まず最小限のローカル構成から選ぶ

正しさを優先するならSentence Transformersから始める

公式モデルカードでは、google/embeddinggemma-2をSentence TransformersおよびTransformersで利用する方法が説明されています。メディア入力を扱う場合は、マルチモーダル用の追加パッケージもインストールします。

pip install -U "sentence-transformers[image,audio,video]" transformers

移行の基準実装としては、これが最も扱いやすい選択肢です。プロンプト名、切り詰め、正規化、マルチモーダル入力の挙動が公式例に沿っているからです。必ずしも最小レイテンシーの配信構成ではありませんが、最適化の前に信頼できる基準値を作れます。

テキスト専用の最小スモークテストは次のようになります。

from sentence_transformers import SentenceTransformer

model = SentenceTransformer(
    "google/embeddinggemma-2",
    config_kwargs={"vision_config": None, "audio_config": None},
)
query = model.encode(
    "embedding model migration",
    prompt_name="SearchQuery",
    truncate_dim=256,
    normalize_embeddings=True,
)
document = model.encode(
    "Rebuild vectors when the embedding representation changes.",
    prompt_name="Document",
    truncate_dim=256,
    normalize_embeddings=True,
)
print(model.similarity(query, document).item())

サーバー化、量子化、ベクトルデータベースの導入に進む前に、まずこれを実行してください。チェックポイント、タスク用プロンプト、次元数、正規化の経路が正しく組み合わさっているかを確認できます。

エコシステムのランタイムは機能差を確認してから使う

Googleの開発者ガイドでは、vLLM、Hugging Face Transformers、Sentence Transformers、SGLang、MLX、Ollama、LM Studio、LiteRTが開発またはデプロイ用の対応ツールとして挙げられています。ただし、この一覧は利用可能性の目安です。テキスト、画像、動画、音声、入力のインターリーブ、タスク用プレフィックス、切り詰め、バッチ処理を、すべてのランタイムが同じ組み合わせで提供することを意味しません。

候補となる各ランタイムについて、実際のリクエストを使って5点を確認しましょう。正確なチェックポイントのリビジョン、利用するモダリティの入力、出力次元、切り詰め後の正規化、クエリとドキュメントのプレフィックス処理です。テキストを高速に配信できても、ビジュアルドキュメントの経路を扱えないなら、フルモデルと同等とはいえません。

軽量なネイティブサーバーは、移行計画ではなく最適化として使う

公開されているembeddinggemma.cリポジトリは、EmbeddingGemma 300M向けに特化したC11/Metalスタイルのサーバーを提供しており、CPU、Metal、CUDA、ROCm、Intel XPUの各バリアントに対応しています。READMEでは、OpenAI互換の/v1/embeddingsエンドポイント、768/512/256/128次元、278 MBのQ4_0モデルダウンロードが案内されています。プロジェクトはApple M5 Max上で、llama.cpp build b8981との54セルにわたる比較を実施し、幾何平均で1.25倍の優位性を報告しています。ただし、これはプロジェクト固有のスループット結果であり、品質比較でも740Mチェックポイントとのマルチモーダル互換性を証明するものでもありません。

移行時に役立つのは、APIの形を合わせられる点です。アプリケーションがすでにOpenAI形式の埋め込みAPIを使っているなら、エンドポイント互換のローカルサーバーによってアダプターの実装量を減らせます。それでも、サーバーのモダリティ対応とプレフィックス処理が本番パイプラインと一致するまでは、Sentence Transformersの結果を正しさの基準として残してください。

インデックス再構築のリスク：次元数だけでは判断できない

入力からベクトルへの変換関数が変わるなら再埋め込みする

モデルファミリー、モデルバージョン、タスク用プレフィックス、正規化、チャンク分割、切り詰め方針、入力フィールド、類似度の定義のいずれかを変更する場合は、全面的な再構築を前提にしてください。Qdrantの移行ガイドとNalarのモデル移行分析が示す運用上の要点は同じです。ドキュメントベクトルとクエリベクトルは、同じ表現バージョンに属していなければなりません。次元数が一致していても、意味的な互換性の根拠にはなりません。

古い768次元ベクトルを切り出して、256次元のEmbeddingGemma 2ベクトルとして扱うのはやめましょう。EmbeddingGemma 2のMatryoshka出力は、対応する切り詰めサイズ向けに学習されており、切り詰め後には再度正規化する必要があります。モデルカードに記載された公式の参考スコアは次のとおりです。

公式モデルカードでは、768次元時のビジュアルドキュメント検索についてNDCG@5が67.84、動画検索についてHit@1が50.67とも報告されています。これらはフル次元の基準値として使い、縮小次元の値を推測で作らないでください。判断の方向性としては、256dは128dよりフル品質に近く、マルチモーダルのスコアは128dでより大きく低下します。別モデルのベクトルを切り詰めるのではなく、選択した次元数で公式チェックポイントからすべてのベクトルを再生成するのが確実です。

EmbeddingGemma 2内で共通空間を使えるなら、不要な作業を減らせる

重要な例外が1つあります。既存のコーパスがすでにEmbeddingGemma 2で埋め込まれており、単にロードするエンコーダーの構成だけを変える場合です。Googleの開発者ガイドによれば、各構成は1つのベクトル空間を共有しています。そのため、テキスト専用のクエリでフルモデルのドキュメントベクトルを検索できます。サービングプロセスが視覚や音声のサポートをロードするようになったというだけで、既存のテキストベクトルを再生成する必要はない場合があります。

ただし、メディアを含む新しいレコードについては、新たなベクトルが必要です。テキスト専用のインデックスでは、埋め込み処理を一度もしていない画像、動画、音声のアイテムを検索できません。モデルのチェックポイントが変わらなくても、マルチモーダル検索の追加はコーパスを段階的に移行する作業になります。

ブルーグリーン方式またはnamed vectorで切り替える

稼働中のシステムでは、Qdrantの移行パターンが分かりやすいテンプレートになります。新しいコレクションを作成し、新規レコードをデュアルライトし、信頼できる元データからバックフィルを行い、Recall@10/MRR/nDCG@10を比較してから、エイリアスを切り替えます。ロールバックに備えて旧コレクションも残しておきます。Qdrantのガイドでは、version 1.19.0、512次元、100ポイント単位のバッチが使われていますが、これらは例であり、EmbeddingGemma 2に必須の値ではありません。

named vectorを使えば、古い表現と新しい表現を1つのコレクションに共存させることもできます。ただし、利用するベクトルデータベースが対応しており、更新経路から両方へ一貫して書き込めることが条件です。Weaviateのベクトライザー移行ガイドは、本番環境ではコレクションエイリアスを推奨しています。検証中も旧コレクションを保持でき、即時ロールバックに使えるためです。既存コレクションにベクトルを追加する方法は、ストレージを恒久的に増やす可能性があり、最終構成というより比較検証に向いています。

マルチモーダル品質：モデル変更の影響が出るデータを分けて検証する

EmbeddingGemma 2の共通空間が役立つかどうかは、実データで期待どおりに検索できるかで決まります。テキスト専用ベンチマークだけでは、テキスト検索が壊れていないことは確認できても、PDFページ、チャート、画像キャプション、動画フレーム、音声クリップ、インターリーブされたレコードで起きる問題を見逃します。

まずは、ラベル付きのスライスを分けて用意します。

1. テキストクエリ → テキストチャンク
2. コードクエリ → コードチャンク
3. テキストクエリ → 画像またはビジュアルドキュメント
4. テキストクエリ → 動画フレームまたは音声セグメント
5. テキスト＋メディアの混在クエリ → 混在ドキュメント
6. クロスリンガルクエリ → サービス対象言語のドキュメント

マルチモーダルの最初の基準値には、768dまたは512dを使いましょう。公式モデルカードでは、共通の8,192トークンコンテキスト内で、画像1枚に280トークン、動画の1フレームに140トークン、音声1秒に25トークンを割り当てています。入力が混在する場合も同じ予算を共有するため、テキスト、画像、動画を含むレコードでは、単一モダリティの入力より各要素に使える余地が小さくなります。

モデルカードでは、128dにするとテキスト専用タスクよりもマルチモーダルタスクで品質が大きく低下することも報告されています。したがって128dは、大規模なテキストインデックスで候補を絞る最初の選択肢にはなりますが、混在メディアのアーカイブでのデフォルトには向きません。ストレージ削減の効果を受け入れる前に、実際のビジュアルドキュメント検索とクロスモーダル検索で256dを評価してください。

EmbeddingGemma 2の統合パイプラインと、現在使っている分離型のテキスト／画像パイプラインを、同じクエリで比較しましょう。モデルが共通空間を採用しているという設計だけから、マルチモーダル品質を推測してはいけません。

既存のRAGシステムを段階的に移行する手順

1. 現在の表現仕様を棚卸しする。 モデルID、チェックポイントのリビジョン、プレフィックス、チャンク分割、次元数、距離指標、正規化、入力フィールド、すでにインデックス化しているすべてのモダリティを記録します。
2. 代表性のある評価セットを作る。 Recall@k、MRR、nDCGの目標に加え、テキスト、コード、ビジュアルドキュメント、音声、動画、言語、長いクエリのスライスを分けて用意します。
3. ローカルの基準値を作る。 まず同じコーパスをSentence Transformersで処理します。埋め込みレイテンシー、検索レイテンシー、メモリ、インデックスサイズ、エラー、スコア分布を記録します。
4. バージョン管理した候補インデックスを構築する。 安定したドキュメントIDと、信頼できる元のテキスト／メディアをベクトルストアの外で管理し、再現可能なバックフィルにします。
5. バックフィル中の書き込みを整合させる。 元データのスナップショットと変更のリプレイを使うか、新旧両方の表現バージョンへ新規・更新レコードをデュアルライトします。
6. 本番クエリをシャドー実行する。 ユーザーに見える回答を変えずに、ランキング結果、空結果率、レイテンシー、ラベル付きの関連性を比較します。
7. アトミックに切り替える。 EmbeddingGemma 2のクエリエンコーダーと、それに対応するインデックスを1つのバージョンまたはエイリアスにまとめて紐付けます。新しいクエリエンコーダーを古いインデックスに接続する中間状態は、決して作らないでください。
8. ロールバック手段を残す。 代表的なトラフィックが受け入れ基準を満たすまで旧インデックスと旧クエリ経路を保持します。その後、デュアルライトを停止してストレージを解放します。

FAQ

EmbeddingGemma 2はCPUだけで動かせますか？

CPUに対応したランタイムを使えば可能です。モデルカードでは、bfloat16を利用できない場合はfloat32を推奨しており、テキスト専用構成は270Mパラメーターです。CPUのスループットは、ランタイム、精度、バッチサイズ、ハードウェアによって変わるため、GPUの数値を流用せず、自分のコーパスで測定してください。

ランタイム選びでは、基準実装としての正しさ、機能の網羅性、配信効率、新しい検索バージョンを検証するコストのバランスを取る必要があります。