740M 先被排進了模型卡：EmbeddingGemma 2 的規格，是一頁等著被誤讀的介面

2026 年 10 月 6 日，APPI News 刊出一篇談嵌入模型選型的長文，主角是 Google 新推出的 EmbeddingGemma 2。熱點過後值得回頭看的，反而是這份模型卡本身：一組參數量、幾個分數、一段多模態能力清單，如何被排成一頁看似可以 直接拿來做決策的介面。

先從最小的數字看起。模型卡上，740M 是包含文字、視覺與音訊組件的完整多模態規模；純文字配置其實是 270M，視覺編碼器 170M、音訊編碼器 300M，可依用途選擇載入。同一個模型，在頁面上有兩種「大小」，取決於讀者有沒有把組件拆解讀完。這個設計誠實，但也容易在轉述過程中被壓縮成單一數字。對只做文字檢索的團隊來說，270M 才是真正需要拿去估算記憶體與延遲的那一格；至於推論套件能否略過不需要的模組，模型卡沒有替你保證，得實測。

分數的排版也是同一種閱讀陷阱。Google 列出 MTEB multilingual v2 平均 61.36，前代 61.15，差距不到一分；MTEB code 的 NDCG@10 則從 68.76 升到 78.68，幅度明顯。兩組數字放在同一張卡上，視覺重量卻相同，讀起來的說服力完全不同。哪一個才是「這模型變強了」的證據，取決於你的任務長得像哪個基準資料集。APPI News 的作者張饒輝在文中反覆提醒：排行榜回答的是模型在指定資料集上的相對表現，不能推算企業內部文件的命中率。

模型卡裡最誠實的一句話，反而藏在限制段落：「模型可能無法在所有語言中展現相同的效能。」這是 Google DeepMind 自己寫下的但書。支援一百多種語言的清單，在頁面上是一個很大的數字；繁體中文在其中的實際位置，頁面沒有給出答案。來源文中舉的例子很具體：員工查「育嬰留停期間保險怎麼算」，相關規定可能分散在法規頁、人資說明與表單指引，若文件切得太碎、查詢帶有臺灣慣用詞，檢索失敗的原因未必在模型。字面相似的「健保自付額」與「商業保險理賠」，則是測試集裡最能分辨「找到相關內容」與「找到表面相似句子」的那一關。

把這份規格頁當成介面來讀，會發現它與其他被排好版的規格敘事有共通的結構。我們先前看過 一張跑分截圖如何替尚未發表的手機排好期待，也看過 21:9 這類電影規格如何被寫進影片模型的更新清單。差別在於手機規格洩漏是被動的，而模型卡是官方主動排版的一份說服文件：Google 將 EmbeddingGemma 2 定位為「適合裝置端多模態嵌入的開放模型」，以低延遲和較少資源需求作為賣點。The Decoder 的報導轉述了這些主張，但註明來源是 Google 本身，性質上屬於發布方的產品定位，而非獨立評測。

換模型的成本也沒有出現在這張卡上。來源文給出的比較方法很樸素：用相同的文件、查詢、切塊策略與硬體，同時記錄命中品質、延遲、記憶體與索引空間。768 維的輸出向量乘上知識庫的文件量，就是儲存帳單；參數少減輕的是推論負擔，整套服務的成本仍由使用方式決定。這些欄位官方頁面一概不會替你算，因為它們屬於每個知識庫自己的介面。

所以 EmbeddingGemma 2 適不適合 RAG？這個問題的正確答案不在模型卡上。卡上的數字篩選得出候選名單，選擇本身要靠一份代表自家業務的繁中查詢集、熟悉業務的人標註的正確段落，以及同條件下的對照測試。規格頁設計得再完整，它回答的始終是「模型在哪些基準上得幾分」；使用者真正想問的那一題，得自己排版。