Google EmbeddingGemma 2

テキスト、ソースコード、画像、動画フレーム、音声が同じ 768 次元空間に入る。書いた一文で音声アーカイブを検索できるし、映っていた内容の説明からスクリーンショットを探せる。異なるメディアを比べられるのは、ベクトルが同じ座標系を共有しているからで、複数のモデルを後から継ぎ合わせているからではない。マルチモーダル埋め込みモデルの多くは形式ごとに別の空間を持ち、その間を翻訳する。境界で情報が落ちる。

フルモデルは 7 億 4000 万パラメータで、テキストとコードの 2 億 7000 万、視覚の 1 億 7000 万、音声の 3 億に分かれる。テキスト経路だけ配布すれば、ダウンロード量もメモリも大きく下がる。後から視覚や音声を足しても、空間は変わらないので計算済みのテキストベクトルはそのまま使える。

Matryoshka 表現学習は、有用な情報を各ベクトルの前半に寄せる。768 次元をそのまま使ってもいいし、512、256、128 に切り詰めてもいい。端末の保存量は最大 6 分の 1 になる。次元を落とすと検索精度は下がり、その影響はテキストより画像と音声で早く出る。決める前に自分のクエリで試すべきだ。

コンテキスト窓は初代の 4 倍になった。1 回の入力でおよそ 5.5 分の音声、29 枚の画像、58 フレームの動画を扱える。組み合わせて入れ子にすることもできる。ナレーション付きのスライド資料を、細切れの塊ではなく 1 つの項目としてエンコードできる。

量子化すると、テキスト専用の重みは Pixel 11 Pro で約 191 MB の使用メモリに収まる。フルマルチモーダルでは約 567 MB だ。この差は、アプリを出荷できるかメモリ消費で弾かれるかを分ける。ミッドレンジの Android では特に効いてくる。

MTEB Code のスコアは 68.76 から 78.68 に上がった。前版から 9.92 ポイントの伸びだ。ローカルのコードベース索引や、コーディングエージェントの検索に向く。問い合わせが記号名ではなく意図を述べる場面で強い。Google は、画像、動画、文書、音声のタスクで 2 倍以上大きい専用モデルを上回るとも報告している。

公式とコミュニティの統合は sentence-transformers、transformers、vLLM、SGLang、llama.cpp、Ollama、LM Studio、MLX、transformers.js、WebGPU に及ぶ。Qdrant はベクトル保存の手順を公開し、Unsloth はファインチューニングの文書を出している。推論スタックもデプロイ経路も 1 つに縛られない。

EmbeddingGemma 2 はテキストのトークナイザと音声エンコーダを Gemma 4 と共有する。2 つを同じパイプラインで動かせば同じ部品を二重に読み込まずに済み、合計のメモリ使用量も下がる。検索と生成が同じノート PC やスマートフォンで完結し、ネットワーク呼び出しは要らない。