Google 推 Gemini Embedding 2，把多模態檢索戰從聊天介面拉回資料底層

Google 這次發的不是新的聊天介面，也不是再替 Gemini 補一個比較容易上新聞的 consumer 功能，而是一個更偏底層、但長期影響可能更大的能力更新。Gemini Embedding 2 是 Google 首個原生多模態 embedding model，官方直接把文字、圖片、影片、音訊與文件放進同一個 embedding space，並同步在 Gemini API 與 Vertex AI 公開預覽。這件事最重要的地方，在於它把 AI 應用競爭從表面的回答品質，再往下拉回「資料到底怎麼被表示、檢索與路由」這一層。

如果你之前已經看過 Google 把 Canvas 放進 AI 搜尋與工作流場景，會更容易理解這步的意義。前台的聊天介面之所以能看起來愈來愈像會做事的助手，後面其實都需要更好的 RAG、更好的檢索品質，以及更穩定的上下文工程。Embedding model 雖然不如聊天模型顯眼，但它決定的是系統能不能把你真正需要的內容，在正確時機找出來。

這次的硬規格，比「多模態」三個字更值得看

Google 官方給的細節相當具體。Gemini Embedding 2 支援最多 8192 個文字 token，單次可處理 6 張圖片，原生支援 MP4 與 MOV 的 120 秒影片輸入，也能直接吃音訊而不必先轉文字，另外還能直接嵌入最多 6 頁的 PDF 文件。更重要的是，這些內容不是各自分開跑不同模型，而是被放進統一的語意空間裡。這代表開發者之後可以用文字找影片片段、用圖片找相應文件、甚至把不同模態內容放進同一個語義檢索流程。

Google 這次還把輸出維度做成可彈性縮放，預設維度是 3072，也建議在 1536 或 768 維度下平衡品質與儲存成本。官方提到這建立在 Matryoshka Representation Learning 上，簡單講就是讓同一個模型輸出的資訊可以在較高維與較低維之間更自然切換。這對要自己養向量資料庫或做大規模語義搜尋的團隊很重要，因為 embedding 不是只看效果，還直接牽動索引大小、查詢延遲與整體成本。

Google 想搶的，不只是模型排名，而是多模態資料入口

官方把這個模型定位成能支撐 Retrieval-Augmented Generation、semantic search、sentiment analysis 與 clustering，但更值得注意的是它公開的 partner 訊號。Google 提到 Paramount Skydance 已把它用在影音搜尋場景，甚至宣稱文字找影片的 Recall@1 可以做到 85.3%。這種案例的價值，不在於單一數字是否能被所有人複製，而在於 Google 正在告訴開發者: 多模態檢索不該再是研究題，而是可以直接進入產品層的能力。

這也讓 Gemini Embedding 2 跟很多「模型更新」不太一樣。大多數人討論 AI 競爭時，焦點會放在聊天回答、代理能力或前台 UI，但真正決定企業系統品質的，常常是最底下那層資料對齊做得好不好。尤其當內容來源不只是一堆文字，而是客服錄音、PDF 合約、行銷影片、螢幕截圖與知識庫圖片時，光靠純文字 embedding 會很快撞牆。Google 現在等於是在說，它想提供的不是一個會回答問題的 Gemini，而是能幫你把複雜內容先轉成可計算語意基礎的 Gemini。

這條線也能和 Google Maps 把 Gemini 帶進地圖決策入口放在一起看。Maps 那篇看的是 consumer 端入口如何被對話化，Embedding 2 則是更典型的 developer 基建層。兩者共同點很明確: Google 不只是想在聊天框裡贏，而是想把 Gemini 植進資料、搜尋、地圖、工作流與 API 的多個層次，讓它變成一整組能力棧，而不是單一產品名稱。

值得補一句的是，官方雖然強調它在文字、圖像、影片任務上優於領先模型，也能支援超過 100 種語言，但目前公開資料仍主要停留在官方 benchmark 與合作案例。對真正要上線的團隊來說，後續更值得驗證的是跨語種穩定度、不同模態混合輸入的品質，以及在自家資料集上的 long-tail 表現。Embedding 的落差，往往不是在 demo 資料上，而是在企業自己的髒資料和異質內容上。

所以 Gemini Embedding 2 這則新聞不該被當成「Google 又上新模型」就略過。更準確地說，它是在把 AI 競爭從聊天介面的顯眼位置，往資料表示與多模態檢索的深水區再推一步。對開發者而言，這會直接影響下一代多模態應用怎麼做；對 Google 而言，這則消息的真正野心，是讓 Gemini 變成更多資料系統的底層語意引擎，而不只是會回話的聊天機器人。