EmbeddingGemma 2 多模態搜尋：權重留在手上，離線檢索還要驗什麼？（2026）

2026 年 10 月 6 日，Google DeepMind 的 Sahil Dua 與 Henrique Schechter Vera 在 Google 官方部落格發布了〈EmbeddingGemma 2: an open, lightweight multimodal embedding model〉。EmbeddingGemma 2 把文字、圖片、音訊與影片放進同一個語意搜尋空間，並讓開發者把模型權重留在自己手上。它值得關注的地方，是私有資料能否在裝置上跨媒體搜尋；至於「同級最佳」，還得拆開測試條件來看。

先看原文如何把不同媒體接在一起，再核對架構、跑分與縮維代價，最後判斷：你的搜尋問題，究竟需要一個多模態模型，還是需要更好的資料整理？

EmbeddingGemma 2 改變的是「找資料」，不是直接替你作答

Today, we’re launching EmbeddingGemma 2, expanding beyond text to unify code, images, video, and audio in a shared embedding space.

中文：今天推出的 EmbeddingGemma 2 超越文字，把程式碼、圖片、影片與音訊統一到共享的嵌入空間。

Google DeepMind，官方發布文章

嵌入可以想成一組描述內容位置的座標。查詢與資料被轉成向量後，搜尋系統找出位置相近的內容。統一空間的意義，是一句「找出有人在海邊跑步的片段」，可以和影片畫面、照片或音訊的表示做相似度比較，不必先把所有問題都改成同一種檔案格式。這是用途示意，並非本文自行執行的結果。

這個方向有研究脈絡：CLIP 原始論文已展示用成對圖片與文字學習可對照的表示。這次 Google 把更多媒體帶入一個小型嵌入模型。官方文件把用途列為語意搜尋、RAG、分類與分群；RAG 則還需要後續的生成模型，才能把找到的資料組成回答。搜尋品質與回答品質，是兩個需要各自驗收的環節。

270M 到 740M：只載入需要的編碼器

公開 model card列出 2.7 億參數的文字核心、1.7 億的視覺編碼器與 3 億的音訊編碼器，全開合計 7.4 億。原生輸出是 768 維；文字、圖片、影片與音訊共用 8,192-token 輸入預算。模組化的實際價值，是純文字索引可以省下不需要的媒體編碼器，而不是每個應用都背著全套模型。

媒體上限也有條件。model card 預設每張圖片使用 280 tokens、每個影片影格 140 tokens、音訊每秒 25 tokens；約 29 張圖片、58 個影格或 327 秒音訊，是單一媒體、不另加文字時的預算估算。混合輸入要共同分配，影片預設按每秒一個影格取樣，音訊輸入則為單聲道 16kHz。能收進數十個影格，不等於完整逐格理解一段長影片。

Google 原文另外公布 Pixel 11 Pro 量化配置的數字：文字權重約 191MB active RAM、全多模態模型約 567MB。這是Google 的指定裝置測試，本文沒有重跑；它也不能直接當成整個搜尋 App 的記憶體需求。原始媒體、解碼、向量索引與後續回答模型，都還有自己的資源成本。Google 原文也指出，若搭配 Gemma 4，可因共用文字 tokenizer 與音訊編碼器降低合併負擔；這仍要在實際部署中核算。想估本機系統的總負擔，可接著讀本機模型記憶體指南。

EmbeddingGemma 2 的跑分亮點，和「最佳」之間還有什麼？

Google 的全精度 checkpoint 評估列出：MTEB Code 從前代 68.76 到 78.68，上升 9.92 分；多語文字平均則是 61.15 到 61.36。程式碼檢索的提升較醒目，不能把這個幅度套用到所有文字任務。原圖把小模型的成績和參數量並列，想說明的是品質與體積的取捨，而非每個測試都贏過所有大模型。

圖片與音訊的原圖同樣在強調小模型的效率；但榜單的任務平均、檢索指標與分類指標並不都是同一把尺。以截至 2026 年 10 月 7 日本文核對的材料，這些新品數字的證據仍是 Google 公告與 model card；另有 Qdrant 團隊於 10 月 6 日發布的原創測試：它取得 Google 預先提供的模型，在 SciFact、NFCorpus、ArguAna、SCIDOCS、FiQA 五個純文字檢索資料集，比較縮維、量化與重評分。這能補上窄域的外部證據，但不是四種媒體的廣泛領先驗證；也要考慮作者本身提供向量資料庫。因此，可把它當成值得試的候選，尚不宜把「同級最佳」變成你自己資料集上的結論。

尤其「支援 100 多種語言」不等於每種語言效果相同。model card 也列出語言能力差異。繁體中文混英文檔名、口語錄音、專有名詞與低畫質掃描，應分開出題；如果你在做驗收，可先用模型 Shadow Eval 的比較方法保留固定題集與版本。

省六倍向量，並不代表品質與帳單都不變

Matryoshka Representation Learning 原始研究讓一個表示在不同維度下仍能使用。EmbeddingGemma 2 支援 768、512、256、128 維；若每個數值的儲存格式相同，768 ÷ 128＝6，向量數值本身可降到原來六分之一。索引結構、metadata 與原檔並不一起消失，所以這不是整個資料庫成本必然省六倍。

最值得讀的是 model card 的縮維表：MMEB v2 Overall 從 768 維的 59.01，降到 256 維的 56.24，再到 128 維的 45.65。Google 因此把 128 維較適合的用途指向純文字工作負載。這張表支持的選擇，是先把 256 或 512 維納入測試，再看你的資料是否值得換取更小體積，而非一開始就追最小數字。

官方使用規則還要求截斷後重新做 L2 正規化，查詢與資料使用相同維度；文字檢索則區分 query 與 document 前綴。官方亦提醒推論使用 bfloat16 或 float32，避免 float16 的數值範圍導致 NaN 或嵌入品質悄悄變差。這些前處理與精度改動會影響排序。模型檔能下載，仍要連同 tokenizer、前綴、切段、媒體取樣與版本一起保存，才能知道日後的變化來自哪裡。

開放權重的價值：搜尋座標可以自己保管

目前官方文件與 Hugging Face 模型頁均標示 Apache 2.0，權重檔也已列在公開 repository。對需要長期維護搜尋的人，這讓下載、固定版本與自行運行有了具體路徑。Google 也把部署接到 AI Edge、LiteRT 與多種常見推論工具；有程式環境的讀者可從官方 Developer Guide追當前整合方式。原文還提供 AI Edge Gallery 的 Instant Media Search 與 Video Moments Finder 展示，分別用來找媒體內容與影片片段。原文也把 MediaPipe Decision Task API 指向多模態分類、路由與決策的應用。它們讓用途更具體；工具支援清單與展示本身仍不是你的硬體效能報告。

為什麼權重會影響索引的壽命？Qdrant 的技術說明指出，向量是由來源資料轉換而來，模型改動會改變空間幾何。若雲端端點停止提供某個模型，你保留的舊向量還在，卻需要相容的查詢向量才能繼續比較。自己保存同版權重與前處理，可降低對單一託管端點的依賴；換成另一模型仍需要重新評估與重建索引。這是根據向量相容性的工程判讀，不是 Google 對永久相容的保證。

而且離線只解決資料流的一部分。嵌入在本機計算，能讓這一步不必把原始資料送往遠端；如果生成回答、備份或診斷記錄仍連雲端，整套系統便有別的出口。搜尋權限也要沿用原檔的存取規則，不能因為檔案變成向量，就讓所有人看到相近結果。對 RAG 而言，入庫內容品質與執行層的權限邊界仍要各自處理。

我同意什麼、存疑什麼，以及下一步怎麼選

我同意：統一媒體表示、可選編碼器與公開權重，把私有搜尋的選擇權往裝置端推進。它特別適合「內容散在不同媒體、資料不方便離開裝置、需要長期保存查詢能力」的問題。對純文字資料庫，則應先問前代或現有模型已能做到什麼，而非為多模態標籤重新建一遍。

我存疑：小體積、漂亮平均分與示範影片，還不足以推出「個人所有資料都能可靠找到」。相似度高的片段可能只是主題相近；音訊取樣、文件切段和權限篩選也會改變結果。成功標準應是找到正確原檔與位置，並能解釋為何其他候選沒有被採用。

今天可以先挑十個你真的找不到的檔案或片段，寫下正確答案和來源位置；混合文字查圖片、文字查音訊、文字查影片，以及幾題「資料庫根本沒有答案」。對每種媒體記錄前五筆命中、錯誤類型、等待時間與總記憶體，再比較全維度與縮維配置。本文沒有把這套建議當成已完成的實測。若只想先建立評估觀念，可從AI Evals 入門開始。

真正值得追的下一個進展，是不同硬體、語言與私有資料集的可重跑結果：跨媒體召回是否穩定、縮維代價是否可接受、長期索引是否能由固定版本延續。這三件事能被證明多少，才決定 EmbeddingGemma 2 對你有多大價值。