MULTIMODAL / ON-DEVICE SEARCH
文書、写真、録音、動画を別々の検索システムに分けず、同じ意味空間で照合する。小型のオープンモデルがローカル検索の選択肢を広げた。
埋め込みは、文章や画像などを意味の近さを比べられる数値の列に変換する技術だ。たとえば「夕日の海」という検索文と海辺の写真が近いベクトルになれば、ファイル名が分からなくても探し出せる。検索拡張生成（RAG）では、まず関連資料を埋め込みで探し、その資料を生成モデルに渡す。埋め込みモデル自身が回答文を生成するわけではない。
昨年のEmbeddingGemmaは主にテキスト向けだった。今回の第2世代は、異なる媒体を1つのベクトル空間で比較できる点が大きな変更だ。[1][2]
Gemma 4を基盤に、テキスト部分が270M、画像用が170M、音声用が300Mパラメーター。画像用エンコーダーは動画フレームも処理する。テキストだけなら270M、テキスト＋画像・動画なら440M、テキスト＋音声なら570M、全部なら740Mを読み込む構成を選べる。[2][3]
GoogleはPixel 11 Proで量子化した場合、テキスト専用のアクティブRAMは約191MB、フル構成は約567MBからと説明する。これはモデルの特定の量子化・端末条件での値であり、アプリ全体の常時メモリー使用量ではない。[1]
Google公開のモデルカードでは、フル精度・768次元でのMTEB Codeスコアが旧モデルの68.76から78.68へ上がった。一方、多言語テキストのMTEBスコアは61.15から61.36で、用途によって改善幅は異なる。コード検索の値は評価セット上の平均であり、個別の社内リポジトリで同じ差が出る保証はない。[1][2]
| 評価 | 旧モデル | EmbeddingGemma 2 |
|---|---|---|
| MTEB Code／NDCG@10 | 68.76 | 78.68 |
| MTEB 多言語／Mean(Task) | 61.15 | 61.36 |
「最大6分の1の保存量」は768次元を128次元に切り詰めた場合のベクトル本体のサイズ比。モデルカード上では128次元のMMEB総合値が768次元の59.01から45.65へ下がるため、画像・動画混在の検索で無条件に128次元を選ぶべきではない。256次元では56.24だ。[1][2]
ローカルに置いた議事録、写真、研修動画、ソースコードを横断的に探す用途が考えられる。端末内処理なら素材を毎回外部APIへ送らずに済む構成を作れるが、モデル配布や端末のログ、検索インデックスの扱いは別途設計が必要だ。以下は公式開発ガイドのテキスト専用構成を使った最小例。動画・音声を使う場合は対応するエンコーダーを有効にする。[3]
pip install -U "sentence-transformers[image,audio,video]" transformersfrom sentence_transformers import SentenceTransformer
model = SentenceTransformer(
"google/embeddinggemma-2",
config_kwargs={"vision_config": None, "audio_config": None},
)
query = model.encode("障害対応の手順", prompt_name="SearchQuery",
truncate_dim=256, normalize_embeddings=True)
doc = model.encode("title: 運用手順 | text: 障害時はログを確認する",
prompt_name="Document", truncate_dim=256,
normalize_embeddings=True)
print(model.similarity(query, doc))検索文と文書には異なるタスク用プロンプトを付ける。短縮したベクトルは再正規化し、検索文と保存側の次元を必ず揃える。モデルカードもこの2点を明記している。[2][3]
埋め込みの近さは事実の正しさを保証しない。写真や音声の誤検索、機密資料の検索結果への露出、著作権・個人情報への配慮はアプリ側で対処する必要がある。Google公表の評価値は提供元の測定であり、量子化後、短縮後、日本語の固有名詞を多く含む社内データでの品質は別問題だ。
今後は端末別の量子化モデル、索引更新の運用、256次元などの圧縮率と実検索品質のバランスを見たい。生成モデルと組み合わせる場合は、検索の根拠表示と回答の検証も重要になる。
最終確認日：2026年10月7日（日本時間）