EmbeddingGemma 2 多模態搜尋將 AI 檢索帶到裝置端，為雲端優先流程帶來壓力

Google 於 10 月 6 日推出 EmbeddingGemma 2 多模態搜尋，將五種內容類型整合至一個為消費級裝置而設的模型之中。這個擁有 7.4 億參數的模型，可在同一共享空間內嵌入文字、程式碼、圖像、影片及音訊。這改變了一項常見的取捨：開發者不再需要假設，廣泛的媒體搜尋必須依賴雲端優先流程或多個獨立模型。

重要的競爭不只是 Google 與另一家模型供應商之間的較量，而是一個統一的本機模型，對上許多現有搜尋產品背後由轉錄、字幕生成、嵌入、儲存及檢索服務組成的集合。Google 表示，EmbeddingGemma 2 可取代其中多個步驟，同時讓私密內容留在手機、手提電腦或邊緣裝置上。

這項承諾仍需在 Google 的基準測試及展示應用程式以外接受驗證。小型模型必須在檢索品質、電池用量、建立索引時間及硬件相容性之間取得平衡。EmbeddingGemma 2 令本機多模態檢索更具可信性，但並沒有令這些工程限制消失。

EmbeddingGemma 2 多模態搜尋整合五種內容類型

這次推出讓 EmbeddingGemma 由文字檢索模型，轉變為個人媒體、程式碼、文件及錄音的通用搜尋層。

嵌入模型會將項目轉換為其語義的數值表示。搜尋系統會比較這些向量，以找出相關資料，即使查詢與內容未必使用相同詞彙。

EmbeddingGemma 2 將輸入映射至統一的 768 維向量空間。因此，文字查詢與相關圖像可在數學上彼此接近。同一原理亦適用於程式碼、影片影格、語音音訊及混合輸入。

這個共同空間支援一些在純文字系統中較難處理的搜尋方式。使用者可以描述一張相片，而毋須知道檔案名稱。語音備忘錄可成為尋找相符影片片段的查詢。開發者亦可利用自然語言，在本機程式碼庫中尋找相關函式。

Google 的 EmbeddingGemma 2 發布公告將這種跨模態檢索列為核心改變。首代 EmbeddingGemma 專注於超過 100 種語言的文字；新一代在保留多語言文字支援的同時，加入專門的視覺及音訊元件。

完整配置包含 7.4 億個參數，由 2.7 億參數的文字及程式碼基礎模型、1.7 億參數的視覺編碼器，以及 3 億參數的音訊編碼器組成。開發者可略去應用程式不需要的元件。

僅文字部署會載入 2.7 億參數的基礎模型。加入視覺功能後，啟用的配置會增至 4.4 億參數。文字加音訊需要 5.7 億參數，而使用所有支援模態則需完整的 7.4 億參數。

這種模組化設計相當重要，因為「裝置端」涵蓋的硬件範圍很廣。旗艦手機、較舊的手提電腦及嵌入式電腦，記憶體限制各不相同。只載入相關編碼器，讓開發者能按產品需要調整模型規模。

模型可接受最多 8,192 個文字及原始碼 token。Google 表示，相同的輸入預算最多可表示 29 張圖像、58 個影片影格或 5.5 分鐘音訊。混合輸入共用這個總預算。

這些上限提供了實用可能性，但不會把模型變成無限容量的媒體檔案庫。長影片仍需取樣或分段。大型文件庫仍需建立索引。模型令個別項目可被搜尋，而周邊應用程式仍須管理資料匯入及檢索。

輸出向量可儲存為 768、512、256 或 128 維。這採用 Matryoshka Representation Learning，一種可在向量逐步縮短的前綴中保留有用資訊的訓練方法。

Google 表示，將向量由 768 維縮短至 128 維，最多可將向量儲存需求減少六倍。其開發者文件指出，較小的表示仍可保留完整模型的大部分品質，但結果取決於模態及工作負載。

這不只是雲端搜尋的縮小版本。模型權重以 Apache 2.0 授權提供，容許商業部署及修改。應用程式可在不把原始資料傳送至 Google 的情況下生成嵌入向量。

開發者打包好所需軟件及權重後，模型亦可離線運作。這令它適用於私密相片庫、野外設備、本機程式碼搜尋，以及網絡連線不穩定的媒體檔案庫。

Google 表示，原版 EmbeddingGemma 推出後下載量已突破 2,000 萬次。這個既有開發者基礎，為第二版提供較容易的分發途徑。已使用本機文字嵌入的團隊，可在毋須採用無關模型家族的情況下評估新媒體類型。

不過，升級不只是更換模型。現有向量必須保持相容或重新生成，檢索門檻可能需要調整，而媒體預處理亦會帶來新的儲存需求。這次發布開啟了更廣闊的搜尋範圍，但開發者仍須圍繞它設計索引。

為何裝置端檢索為雲端優先流程帶來壓力

EmbeddingGemma 2 所針對的不只是模型請求成本，還有多模態搜尋中各個環節的數量。

傳統媒體搜尋流程通常會將每項輸入轉換成文字。語音會先經過自動轉錄。圖像會生成說明文字或進行光學字元辨識。影片則會被取樣、加上說明文字並劃分場景。文字嵌入模型其後會為這些衍生描述建立索引。

這種方法可行，但每次轉換都可能遺失語義。轉錄可能錯過語氣、環境聲音或不常見的名稱。圖像說明文字可能忽略日後變得重要的小物件。經取樣的影片亦可能遺漏使用者想找的時刻。

每一次轉換亦會帶來新的營運依賴。團隊必須選擇模型、定義中間格式、處理故障，並監察多種延遲表現。私密媒體在變得可搜尋之前，可能已跨越多個服務邊界。

EmbeddingGemma 2 採用專門編碼器，但這些編碼器會輸入同一個相容的表示空間。模型可將原始音訊查詢與文字比較，或將文字描述與視覺內容比較，而毋須先把每項輸入都轉為說明文字。

這種設計在三方面為雲端優先系統帶來壓力。第一是私隱。本機推論讓敏感資料可留在使用者或機構控制的硬件上。

第二是回應速度。本機索引可毋須等待網絡傳輸及遠端服務便回覆搜尋。當用戶每天反覆搜尋個人檔案時，這項優勢尤其明顯。

第三是架構。單一嵌入模型家族可減少模態之間所需的轉接層，也為多種內容類型提供統一的向量格式。

這並不代表雲端基建不再需要。許多產品仍會同步索引、集中處理大型資料集，或在檢索後使用遠端生成式模型。本機嵌入改變的是第一階段可在哪裏進行。

以一個包含投影片、筆記、螢幕錄影及音訊的會議檔案庫為例。傳統系統可能會轉錄錄影、擷取投影片文字，並將結果傳送至不同服務。EmbeddingGemma 2 提供了一條可在使用者電腦上為這些來源建立索引的途徑。

例如「客戶完成初始設定後留存率下跌的圖表」這類查詢，可同時搜尋視覺影格及文字。模型會傳回相關項目，而另一個應用程式則負責呈現或摘要內容。

同一模式亦適用於個人知識軟件。當檢索可涵蓋截圖、錄影、文件及筆記，而毋須先把所有內容壓平成文字時，個人知識庫便會更有用。

本機處理亦改變了重複檢索的經濟效益。雲端 API 會直接或間接就處理、儲存及流量收費。裝置端系統則把成本轉向下載大小、工程投入、本機運算及電池消耗。

沒有任何一種方法必然較便宜。雲端服務可將基建管理分攤至眾多客戶；本機應用程式則必須支援多種處理器、作業系統及記憶體配置。

不過，EmbeddingGemma 2 為團隊提供了另一個可信選項。處理私密或經常被搜尋內容的產品，可將索引保留在靠近使用者的位置。雲端服務必須透過更佳品質、更容易的營運或更廣泛的擴展能力，證明遠端處理的價值。

Google 正透過其部署堆疊強化這項選擇。公司已在 Google AI Edge Gallery 加入 Instant Media Search 及 Video Moments Finder。這些應用程式展示本機檢索，而不只是發布模型權重。

Google 亦表示，EmbeddingGemma 2 支援即將加入 ML Kit。計劃中的整合會將模型作為 Android 服務提供，並在相容裝置上使用神經處理單元加速。

MediaPipe 正加入 Universal Embedder Task，處理圖像調整大小、正規化及多模態 tokenization。其 Semantic Retriever Task 則加入內嵌向量搜尋引擎，以進行本機近似最近鄰查詢。

根據 Google 的邊緣整合計劃，該檢索器可在個位數毫秒內傳回排序後的相符結果。這仍是公司所報告的效能聲稱，並非對每部裝置或每個資料集的保證。

支援軟件的重要性可能不下於基準分數。許多開放模型未能進入一般應用程式，原因是整合仍然困難。標準 Android 及跨平台介面可降低這個門檻。

若這些介面能在各類硬件上運作，EmbeddingGemma 2 便不只是可下載的 checkpoint，而會成為私密搜尋、路由及檢索應用平台的一部分。

單一共享空間是模型的核心優勢

模型的主要機制，是讓各模態在語義上相容，從而減少把每個查詢及文件都翻譯成文字的需要。

EmbeddingGemma 2 建基於 Gemma 4 解碼器架構。其文字元件充當雙向編碼器，即是在表示輸入的每個部分時評估周圍語境。

視覺及音訊塔會先處理各自的媒體，然後透過共享模型投射資訊。最終結果是一個經正規化的向量，可與其他受支援模態的向量比較。

這個機制相當重要，因為跨媒體配對不只是辨識個別物件或詞語。實用的向量空間必須能將相關語義放在彼此接近的位置，即使其格式不同。

例如，對海浪的口述描述應可檢索相關音訊及影片。以自然語言描述某項軟件行為，應可檢索實作該行為的程式碼。包含圖表的截圖，應可配對有關該圖表含義的問題。

傳統多模態模型如 CLIP 奠定了強大的圖像至文字檢索能力。其他系統則把這個概念延伸至音訊、影片或文件。EmbeddingGemma 2 嘗試以一個精簡、開放權重模型涵蓋所有這些類別。

Google 亦營運一個面向雲端、規模更大的模型，名為 Gemini Embedding 2。該模型涵蓋文字、圖像、影片、音訊及混合輸入，但其定位與 EmbeddingGemma 2 不同。

Gemini Embedding 2 面向高端託管式檢索。EmbeddingGemma 2 則面向本機執行及模型自主擁有。兩者展示了同一家公司採取的兩條路線，而非彼此的直接替代品。

雲端模型在多項基準測試中報告了較高的絕對成績。其多模態嵌入論文顯示，在 MTEB Code 取得 84.0 分，在多語言 MTEB 評估取得 69.9 分。這些數字不應被視為直接的產品保證。

EmbeddingGemma 2 反而着重每個參數所帶來的品質。Google 表示，其程式碼分數由首代 EmbeddingGemma 的 68.76 升至 78.68。在該公司的 MTEB Code 比較中，這代表提升了 9.92 分。

Google 亦表示，新模型在指定的程式碼、視覺及音訊基準測試中，領先參數量不足十億的多模態嵌入模型。當記憶體和網絡存取限制較少時，規模更大的託管模型仍可能提供更高品質。

這個分別釐清了主要競爭所在。EmbeddingGemma 2 不必在每一項基準測試上擊敗所有雲端模型。它需要做到的是，讓本機檢索的品質足以令私隱、延遲及控制權的優勢，勝過可能存在的品質差距。

共享向量空間亦簡化了檢索增強生成，即 RAG。在 RAG 中，系統會先找出相關的來源資料，然後才由生成模型組織答案。

本機 RAG 應用程式可以利用 EmbeddingGemma 2 檢索截圖、程式碼檔案或錄音片段，然後把選取的資料交給另一個裝置端模型，例如 Gemma 4，進行生成。

Google 表示，EmbeddingGemma 2 與 Gemma 4 共用文字 tokenizer 及音訊編碼器架構。重用這些元件可降低裝置端流程的整體記憶體佔用。

結果是形成一種分工。EmbeddingGemma 2 找出相關內容；生成模型則就該內容推理或產生回應。較小型的檢索器可以頻繁運作，而毋須為檔案庫中的每一項內容都啟用較大型模型。

該模型亦支援零樣本分類。應用程式可嵌入新輸入，並將其與書面標籤比較，例如「帳單問題」或「技術支援」，而毋須訓練獨立分類器。

這讓語音、圖像及文字可在本機進行意圖路由。Google 在示範中描述了毫秒級路由，但實際生產環境效能會因硬件及標籤數量而異。

可靈活調整的向量維度提供了另一個工程槓桿。128 維索引所佔空間較少，搜尋速度亦可快於 768 維索引。較大的表示形式或能保留較小向量所失去的差異。

開發者可按工作負載選擇這項取捨。個人相片庫或可接受精簡索引；專門的技術檔案庫則可能需要完整表示，以區分相近紀錄。

Google 的技術指南指出，256 維向量保留了大部分文字及程式碼效能，並可保留圖像、影片及語音檢索完整品質約 95%。這些整體結果仍須以各個應用程式的數據驗證。

這項要求很容易被低估。搜尋品質並非單一數字。一個模型可以在廣泛基準測試中表現良好，卻錯過定義特定產品的精確術語、視覺模式或口音。

共享空間降低了流程複雜度，但亦把依賴集中在一個模型上。若模型誤解某個領域，每種模態都可能承受同一問題。因此，團隊需要能反映用戶情況的評估集，而不應只依賴公開排行榜。

「口袋大小」的說法有實際限制

能放入記憶體的模型，並不代表在所有裝置上都自動具有效率、準確或已準備好投入生產環境。

Google 表示，量化後的 EmbeddingGemma 2 權重，在 Pixel 11 Pro 上進行純文字檢索時，使用約 191MB 的活躍記憶體。完整多模態設定則需要約 567MB。

這些數字令手機部署變得可行，但它們描述的是特定裝置及經最佳化的設定。較舊手機的處理器可能較慢、散熱限制更嚴，或在作業系統及應用程式負載後可用記憶體更少。

模型記憶體亦只是整體佔用的一部分。應用程式還需要為媒體預處理、向量索引、中繼資料及快取結果預留空間。大型本機資料庫可令索引的重要性高於模型本身。

建立索引是另一項隱藏成本。內容完成嵌入後，搜尋結果可以很快出現，但建立這些嵌入需要運算。應用程式必須決定何時為新檔案建立索引，以及如何避免耗盡電池。

影片帶來尤其困難的取捨。Google 的預設工具每秒從影片擷取一格，並將單一輸入限制為 58 格。這能令運算維持在可管理範圍內，但幀與幀之間的短暫事件可能會消失。

音訊亦有類似限制。5.5 分鐘的上限無法把長會議或 podcast 作為單一項目處理。開發者必須把錄音分割成片段，並保留時間資訊，讓結果可指向有用的時刻。

分段決策會影響檢索品質。過短的區塊會失去上下文；過長的區塊則會混合無關主題，並可能令生成的向量變得模糊。

統一模型在狹窄領域中亦可能不及專用模型。醫學影像、法律證據開示、工業聲學及原始碼安全，均涉及通用訓練未必能充分表達的模式。

微調 EmbeddingGemma 2 的選項有助應對這點，但微調會增加數據、評估及維護需求。機構亦需要證明適應過程能改善目標任務，同時不會損害更廣泛的檢索能力。

基準測試的解讀帶來另一項風險。Google 的領先結果比較了大小相若的模型，並採用了特定評估套件。「同等大小中最佳」並不代表整體最佳，亦不保證在私有數據上取得最佳結果。

模型卡及文件比發布標題提供更多細節，但大部分已公開的效能證據仍來自 Google。由於模型剛推出，針對手機、手提電腦及真實用戶收藏的獨立重現測試仍然有限。

早期社群測試已說明本機評估為何重要。一名開發者表示，在一個小型私有檢索集上，與現有文字嵌入器相比沒有實質差異。這個結果屬軼事性質且範圍狹窄，但它顯示較高的公開基準分數不保證會帶來可見的產品改善。

跨模態搜尋亦引入難以解釋的誤判風險。系統可能透過廣泛的共享概念，把音訊片段與圖像聯繫起來，卻錯過用戶原本想要的特定關係。

應用程式需要信心閾值、後備行為及清晰的結果預覽。本機模型可保護數據，同時仍可能返回具誤導性的匹配結果。

私隱聲稱同樣需要審慎措辭。本機推論可避免把內容傳送至嵌入 API，但周邊應用程式仍可能同步檔案、遙測資料或向量。

嵌入本身可能洩露來源資料的資訊。開發者應把本機向量索引視為敏感數據，並以適當的存取控制及加密保護。

授權消除了另一道障礙，但並非所有管治問題。Apache 2.0 允許廣泛的商業使用，而機構仍須為其應用程式、訓練數據選擇及個人媒體的處理方式負責。

硬件碎片化可能成為最大的採用限制。Android 裝置使用不同的神經加速器、驅動程式及記憶體配置。桌面部署則涵蓋 Apple silicon、x86 處理器、獨立 GPU 及瀏覽器運行環境。

MediaPipe 及 ML Kit 可以隱藏部分差異，但無法令每部裝置都同樣快速。團隊將需要為能力較低的系統制定最低硬件要求及精簡設定。

這項壓力測試不會抹殺此發布的重要性。它界定了 EmbeddingGemma 2 必須達到的實際標準。當本機搜尋能在一般電力、記憶體及儲存限制內讓人感到可靠時，該模型便算成功。

開發者現在必須選擇搜尋放在哪裏

EmbeddingGemma 2 讓檢索架構成為關乎控制權、品質及位置的產品決策。

計劃多模態搜尋的團隊，現在至少有三條廣泛路線可選：使用多個專用模型、採用託管式統一嵌入服務，或在本機部署精簡的統一模型。

專用流程讓每個階段都可獨立控制。強大的轉錄服務可處理音訊，而專用視覺模型則處理圖像。代價是協調工作，以及各階段之間可能出現資訊流失的風險。

託管式統一模型提供強大的通用效能及簡單的 API 存取方式。它們降低本機硬件要求，卻會將處理交由外部基礎設施，並建立持續的服務依賴。

EmbeddingGemma 2 提供本機自主擁有及一個兼容的表示空間。它的取捨是較低的品質上限、更多裝置測試，以及對整個索引生命週期的責任。

最佳選擇取決於產品。具備集中管治的企業檔案庫可能偏好雲端處理；私人的個人助理可能優先考慮本機推論；缺乏可靠連線的外勤應用程式，則更有理由留在裝置端。

混合式設計很可能會變得普遍。產品可以為高頻搜尋建立本機索引，然後只在查詢需要更深入推理或更廣泛數據時才呼叫雲端模型。

這種模式令日常檢索保持迅速，同時把遠端運算保留給困難個案。它亦可讓用戶選擇特定收藏是否離開其裝置。

EmbeddingGemma 2 的多模態搜尋，對已掌控本機應用程式的軟件製作者尤其相關。筆記工具、媒體管理器、程式碼編輯器、無障礙產品及流動助理，都可以加入語意檢索，而毋須建立新的伺服器端媒體流程。

這次發布亦為作業系統搜尋帶來壓力。用戶愈來愈期望一次查詢便可涵蓋文件、截圖、對話、相片及錄音。關鍵字索引無法可靠地連結所有這些格式。

Apple、Microsoft 及裝置製造商已投資於本機智能。Google 的開放模型讓獨立開發者可取得相似的架構基礎元件，儘管平台擁有者仍保有整合優勢。

雲端嵌入供應商面對的是另一種壓力。他們可透過更佳品質、更低延遲、更清晰的私隱控制，或精簡的可下載模型作出回應。關鍵比較將由基準分數轉向整體產品效能。

三個訊號將顯示 Google 的做法能否取得真正採用。

首先，開發者應留意 ML Kit 的發布及其支援的硬件。廣泛加速及可預測的記憶體使用量，將強化其用於生產級 Android 部署的理據。延遲或狹窄的裝置覆蓋範圍則會削弱這個理據。

其次，獨立檢索評估需要測試私有程式碼庫、相片庫、嘈雜音訊及長影片。若結果接近 Google 的說法，將確認這個精簡模型能在經精選基準測試以外維持良好表現。

第三，實際應用必須證明能持續進行本機索引，同時不會帶來難以接受的耗電或儲存空間增長。展示型示範可證明可行性，但重複使用才會揭示該架構是否適合日常生活。

競爭對手的回應同樣重要，但不應分散對這些訊號的注意力。相較於可靠地整合至數千部裝置及各式各樣的個人收藏，新模型發布的意義較小。

Google 已提供權重、文件、Sentence Transformers 支援，以及邊緣運算示範。下一階段將由應用程式開發者、硬件供應商及獨立評估者主導。

EmbeddingGemma 2 並非要終結雲端搜尋。它令遙距處理成為產品必須加以理據說明的選項，而不再是理所當然的預設做法。

對開發者而言，務實的下一步並非遷移整個系統。請選擇一個私密、混合媒體的收藏，並在多種向量大小下評估檢索品質。在目標裝置上量度索引時間、耗電量、記憶體使用量及錯誤匹配情況，再將結果與現有的雲端或專用流程比較。若本機搜尋在真實限制下仍能保持準確，便擴大測試；否則，保留混合方案。重要的問題已不再是多模態檢索能否在裝置上運行，而是 EmbeddingGemma 2 多模態搜尋能否在不犧牲令本機推論吸引人的私隱保障及回應速度下，達到特定產品的品質門檻。