摘要： Google DeepMind 於 2026 年 3 月 10 日讓 Gemini Embedding 2 進入公開預覽，是該公司第一個原生多模態嵌入模型，讓文字、圖片、影片、音訊與 PDF 共用 3072 維向量空間。它支援 Matryoshka 截斷至 1536 或 768 維，但更換模型仍需全面重建索引。
Google DeepMind 選在 2026 年 3 月 10 日讓 Gemini Embedding 2 進入 Public Preview，這是以 Gemini 架構為基礎打造的嵌入模型，也是該公司第一個原生多模態的嵌入模型。從此文字、圖片、影片、音訊和 PDF 共用同一個 3072 維向量空間，語言涵蓋超過 100 種。具名發布這份公告的，是產品經理 Min Choi 與傑出工程師 Tom Duerig。
檢索工程最零碎的環節，因此有了直接的解法。以往做多模態搜尋，得替文字與圖片各挑一個模型，音訊還要先轉成文字；現在單一模型就能取代這整串拼裝，系統複雜度和嵌入費用一起往下走。
單一模型、單一空間，容納五種模態
- 文字最長 8,192 個 token；一次請求可附 6 張圖片，格式限 PNG 與 JPEG。
- 影片以 120 秒為限（MP4、MOV）；PDF 上限 6 頁。
- 音訊直接以原生形式輸入，省去先轉出中繼文字稿的步驟——那正是語音檢索管線裡向來最棘手的一段。
- 允許交錯輸入：圖片與文字可在同一個請求裡混用。
- 官方說法是在文字、影像與影片各項任務上，成績高於目前的領先模型。
從這些數字可以看出定位：它服務的是「檢索單元」，可能是一頁文件、一小段影片或單張圖片，而不是長度無上限的完整多媒體檔。文字側 8,192 token 的天花板，與 Gemini 主模型百萬等級的上下文相比仍相去甚遠——負責嵌入的與負責生成的，各自做好各自的事。
Matryoshka 截斷遇上 3072 維輸出
輸出維度預設為 3072，背後技術是 Matryoshka Representation Learning——資訊以「巢狀」方式分布在各維度裡，向量因此能按需求截短，不必重新訓練。官方給出三個建議檔位：3072、1536 與 768 維。
在向量資料庫裡，儲存與搜尋的開銷幾乎跟著維度呈線性成長：規模上千萬的索引改用 1536 維就能省下一半，降到 768 維再減半一次。有了 Matryoshka，「拿品質換成本」不再是動工前就得定案的一次性決定，而是寫成一行參數的選項——先在完整維度下離線評測，實際上線時再依延遲預算決定截到多短。
生態系與 API 首日即整合完成
這個模型的 ID 是 gemini-embedding-2-preview，Gemini API 與 Vertex AI 兩邊同時可用；第一波整合的名單涵蓋 LangChain、LlamaIndex、Haystack、Weaviate、Qdrant、ChromaDB 與 Vertex AI Vector Search，Google 還另外準備了 Colab 筆記本。
真正該算清楚的，是切換成本的結構：更換嵌入模型，麻煩從來不在呼叫 API 那一步，而在索引得整個重建——嵌入空間一換，全部資料都要重算。第一天就有的框架整合，壓低的是「先試試看」的門檻：只要把 embedding 函式改指向新的 model ID，跑完一輪評測，再判斷值不值得重建索引。
RAG 與 Agent 管線受到的實際改變
影響有三層。其一，跨模態檢索成了原生能力：拿一句話找出影片片段，或憑一張截圖追溯原始文件，都不用再替各個模態分頭建索引、寫對齊邏輯。其二，Google 開發者部落格展示的 agentic multimodal RAG 是最貼身的應用場景——Agent 能同時消化螢幕截圖、文件與語音備忘，記憶全部收進同一套向量。其三，別忽略鎖定效應：一旦統一空間的品質站得住，把資料和索引留在 Google 生態系裡的引力就會增強；各家的嵌入空間無法互相混用，改換模型等於全面重建索引，評估時務必把這筆帳列進去。
同一個日子裡，Google 也讓 Gemini 更深入 Workspace——個人檔案起草、試算表自動填與 Drive 問答。基礎元件跟終端應用同一週接連出貨，連 Embedding 這類底層零件都被排進例行發布行程，可見多模態檢索已經是 Gemini 平台的標準配備。