EmbeddingGemma 2はテキスト、画像、音声、動画を端末内の768次元に統合する

Googleは、7億4,000万パラメータの公開embeddingモデルEmbeddingGemma 2をApache 2.0でリリースした。テキスト、コード、画像、音声、動画を共通の768次元空間へ写像する。重みはHugging FaceとKaggleで入手できる。

5種類の入力をクラウド経由なしで1つのモデルが扱う

構成はモジュール式だ。テキストとコードには2億7,000万パラメータの基盤を使い、画像encoderが1億7,000万、音声encoderが3億を加える。Googleによれば、量子化したテキスト重みはPixel 11 Proで約191 MBのアクティブRAMを使い、完全なmultimodalモデルは約567 MBを使う。

コンテキストは8,192 tokenで、最大5.5分の音声、29枚の画像、58フレームの動画を処理できるという。Matryoshka Representation Learningにより、出力を768次元から512、256、128次元へ短縮でき、ベクトルDBの容量を最大6分の1にできる。

端末内retrievalが全メディア共通のindexを持てる

実用上の変化は、写真、音声メモ、文書、動画ごとに別々のembedding pipelineを用意しなくてよい点にある。1つのindexで、テキストや音声から動画内の場面を探し、個人データをクラウドへ送らずに処理できる。

モバイル検索、offline RAG、ローカルcodebaseの索引に向く。transformers、llama.cpp、Ollama、MLX、LiteRTへの対応も導入を容易にする。ただし、量子化とベクトル短縮の後でも品質が保たれなければ、利点は薄れる。

開発元のbenchmarkだけでは手元のデータを予測できない

GoogleはMTEB Codeが68.76から78.68へ改善し、10億パラメータ未満のmultimodalモデルで上位だと報告している。ただし、これは開発元による測定だ。導入判断には、自社のデータ、言語、メディア形式、実機のスマートフォンやPCでの検証が要る。

共通ベクトル空間があっても、騒音の多い録音からテキスト検索で正しい1秒を必ず見つけられるわけではない。multimodal retrievalはpipelineを簡素化する一方、関連性が崩れる場所を増やす。

小さなindexと一般的な端末での実測が勝負を決める

128次元へ短縮した実データでのrecall、消費電力、Pixel 11 Pro以外での遅延を追う必要がある。100を超える対応言語で、異なるメディアをまたぐ検索品質が保たれるかも重要だ。

2億7,000万パラメータの基盤と小さなローカルindexで十分な結果が出れば、クラウドembeddingサービスはアプリの必須部品ではなくなる。失敗すれば、EmbeddingGemma 2は選び抜いたデータ上の印象的なデモにとどまる。

Lilithの判定

EmbeddingGemma 2は写真、音声メモ、動画を1つのindexに収め、アーカイブを端末へ戻す。通信が切れた瞬間にも正しい場面へ着地できるかが本当の試験になる。