AI-LECTURER 速報課｜2026-10-07｜約 25 分鐘

一個 740M 的小模型，怎麼把影片、聲音、程式碼都塞進同一張地圖？EmbeddingGemma 2 拆解

取材：EmbeddingGemma 2: An open, lightweight multimodal embedding model（Hacker News（AI 高人氣））
📍 真實場景
阿翔，台北的獨立紀錄片剪輯師，硬碟裡有三年份的訪談素材

客戶臨時要他找出「導演在咖啡廳提到預算超支」的那一小段，素材包含語音備忘錄、手機影片和現場照片

😖 卡住的地方：檔名全是 IMG_4821、錄音 0033 這種編號，只能一支一支點開聽，花了兩小時還沒找到。素材又涉及客戶機密，不能上傳雲端搜尋服務
💡 這課讓你看懂：為什麼一個能在手機上跑的小模型，就能用一句話同時搜尋聲音、影片和圖片，以及它用了哪些工程取捨才做到

🧭 這到底是什麼（白話版）

EmbeddingGemma 2 是 Google 釋出的開放模型。它的工作不是聊天，而是把東西變成 嵌入向量（embedding）一長串數字，用來代表一段內容的「意思」，意思越接近的內容，數字排列就越相似。去年的第一代只處理文字，累積超過 2000 萬次下載，大家拿它做手機上的本機搜尋，以及不把資料外傳的 RAG檢索增強生成：先從資料庫找出相關資料，再交給 AI 參考後回答，讓 AI 不用靠記憶亂答 系統。

第二代最大的改變是 多模態同一個模型能處理多種資料型態，例如文字、圖片、影片、聲音。它把程式碼、圖片、影片和聲音，全部放進同一個「共享嵌入空間」。你可以把它想成一張大地圖：「導演說預算超支」的錄音、寫著預算的投影片截圖、討論預算的文字，會被放在地圖上很近的位置，所以用文字就能搜到聲音。

它基於 Gemma 4 架構，總共有 740 million（7.4 億）個 參數模型裡可以調整的數字旋鈕，數量越多通常越強，但也越吃記憶體和算力，採用 Apache 2.0 授權一種寬鬆的開源授權，商業產品也可以免費使用、修改，所以個人和公司都能直接拿來用。

🎯 為什麼值得你花時間

一個模型搜遍所有媒體以前搜聲音要一套模型、搜圖片要另一套，還得想辦法把結果合併。現在同一個模型把文字、程式碼、圖片、影片、聲音放進同一空間。一句文字查詢可以直接找出一段錄音或一個影片片段，系統少了很多拼接的麻煩。
小到能在手機上跑官方數據：經過 量化把模型數字用更省空間的精度儲存，犧牲一點點精度換取大幅降低記憶體用量 後，在 Google Pixel 11 Pro 上，純文字版本只需約 191MB 的運作記憶體，完整多模態版約 567MB。資料不用離開手機，隱私和速度都有保障。
程式碼搜尋明顯進步在 MTEB Code（程式碼嵌入評測）上，分數從第一代的 68.76 升到 78.68，提升 9.92 分。官方指出這讓它更適合本機程式碼庫索引、語意程式碼搜尋，以及寫程式 AI 助手的檢索。

⚙️ 它是怎麼運作的

1
各種媒體先過各自的「翻譯官」文字、圖片、聲音的結構完全不同。模型採模組化設計：文字核心約 270M 參數，另有可選的視覺編碼器 170M 和音訊編碼器 300M。三者加起來正好 740M。
▼
2
全部映射到同一張地圖不管輸入是什麼，輸出都是同一種格式：768 個數字組成的向量。意思相近的內容，向量在空間中的位置就靠近，這是跨媒體搜尋能成立的原因。
▼
3
用 MRL 彈性縮短向量MRL（Matryoshka Representation Learning）套娃式表示學習：訓練時就讓向量「前面幾個數字」已經包含最重要的資訊，所以可以直接截短使用，像俄羅斯套娃一層一層縮小 讓你把 768 維截成 512、256 或 128 維，最多省下約 6 倍儲存空間（768 除以 128 剛好是 6）。
▼
4
8K 上下文吃進更長的內容上下文視窗（context window）模型一次能「看」的內容長度上限 擴大到 8K token，是第一代的 4 倍。官方說明這相當於最多 5.5 分鐘音訊、29 張圖片、58 個影片影格，或它們交錯組合。
▼
5
查詢時比相似度把你的問題也變成向量，和資料庫裡每筆向量比較「有多靠近」，最靠近的就是搜尋結果。這些向量通常存在 向量資料庫專門儲存並快速比對向量的資料庫，越短的向量，佔用空間越小。
EmbeddingGemma 2 的模組化組合（依官方數據整理）
組合參數量官方標示的用途
只用文字約 270M純文字工作負載，運作記憶體約 191MB（量化、Pixel 11 Pro）
文字＋視覺270M + 170M加入圖片、影片、文件理解
文字＋視覺＋音訊（完整版）約 740M完整多模態，運作記憶體約 567MB（量化、Pixel 11 Pro）

🔍 程式碼漫遊（點有 ● 的行看白話講解）

這是我們自己寫的小範例，用來說明 MRL 截短的概念，不是官方 API。重點是：截短後要重新把長度「正規化」，比較相似度時才公平。

●import numpy as np
💬 NumPy 是 Python 做數字陣列運算的常用工具。
●vec = np.random.randn(768)
💬 假裝這是模型輸出的 768 維向量。真實情況由 EmbeddingGemma 2 產生。
●short = vec[:128]
💬 重點行：只取前 128 個數字。MRL 訓練時就讓最重要的資訊排在前面，所以這樣截不會像隨便砍一半那樣壞掉。
●short = short / np.linalg.norm(short)
💬 重點行：把向量長度調回 1。截短會改變長度，不調整的話，比較相似度時長度會干擾結果。
●print(vec.nbytes, short.nbytes)
💬 印出兩者佔用的位元組數。768 對 128，剛好是 6 倍的差距，對應官方說的「最多 6 倍儲存縮減」。

🛠️ 動手做：拖動滑桿：把向量截短，搜尋排名會怎麼變？

  1. 下方有一個查詢「找會議錄音裡講預算的那段」，以及 4 筆素材。每筆素材都用 8 維的玩具向量代表（真實模型是 768 維，這裡縮小方便觀察）。
  2. 先把滑桿放在 8（使用全部維度），記下排名第一的素材。
  3. 再把滑桿往左拖到 2，觀察排名變化。留意「旅遊照片」這類素材是否冒到前面。
  4. 思考：省下儲存空間的代價是什麼？為什麼實務上不會一口氣截到最短？
👇 下面是活的，直接操作

🧠 工程思維透鏡（資深工程師看到的是什麼）

🔭 為什麼要做成「可拆的模組」，而不是一個 740M 的整包？
裝置資源是硬限制。如果你的應用只搜文字，載入視覺和音訊編碼器純屬浪費。官方數據：純文字只要約 191MB，完整版約 567MB，差了接近 3 倍。工程取捨是：多一層「按需載入」的複雜度，換來在低階裝置也能用。這是把成本交給使用者自己選擇的設計。
🔭 MRL 讓向量能截短，那為什麼不永遠用 128 維？
維度越少，能區分細微差異的空間就越小，排名可能變粗糙。你可以在手作練習中看到：截得太短時，原本不相關的素材可能被擠到前面。實務做法是依場景調整。素材量小、精度重要就用 768；素材量巨大、儲存是瓶頸就降維，並用自己的資料實測品質掉多少。官方只保證「最多省 6 倍儲存」，沒有說品質完全不變，所以要自己驗證。
🔭 把所有媒體塞進同一個空間，會有什麼隱藏代價？
好處是系統簡單、跨媒體搜尋自然成立。代價是：模型要用有限的 740M 參數同時學會多種任務，需要在不同媒體之間分配容量。官方宣稱它在 sub-1B（10 億參數以下）多模態嵌入模型中領先，也勝過一些兩倍大的專用模型。不過這是官方在特定基準測試上的結果，換成你自己的領域資料（例如台灣口音的訪談錄音），表現可能不同，上線前必須用自己的資料評估。

📝 隨堂考（點選答案，立即回饋）

Q1. EmbeddingGemma 2 相比第一代，最核心的新增能力是什麼？
✅ 第一代只處理文字，第二代擴展到程式碼、圖片、影片與音訊，且放在同一個共享嵌入空間，所以能用文字搜聲音或影片。它是嵌入模型，不是聊天或生成模型。
Q2. 官方說用 MRL 可以把 768 維向量截短到 128 維，最多能省多少儲存？
✅ 768 除以 128 剛好是 6，所以最多約 6 倍儲存縮減。
Q3. 阿翔想在手機上只搜尋文字筆記，最適合的組合是？
✅ 模型是模組化設計，純文字只需約 270M 參數，官方數據運作記憶體約 191MB（量化後、Pixel 11 Pro）。不需要的視覺和音訊模組不必載入。
Q4. 8K token 的上下文視窗，官方說明最多可處理多長的音訊？
✅ 官方數據是最多 5.5 分鐘音訊，或 29 張圖片、58 個影片影格，或它們的交錯組合。更長的素材需要先切段處理。

🃏 翻牌記憶卡（先想答案，再點開對答）

EmbeddingGemma 2 的總參數量與授權？點我翻面
740 million 參數，Apache 2.0 授權，基於 Gemma 4 架構。
模組化拆分的參數量？點我翻面
文字約 270M，視覺編碼器 170M，音訊編碼器 300M，合計 740M。
MRL 的作用？點我翻面
讓 768 維向量可以截短成 512、256、128 維，最多省約 6 倍儲存，因為訓練時就把重要資訊放在前面。
上下文視窗大小與可處理量？點我翻面
8K token，是第一代的 4 倍；最多 5.5 分鐘音訊、29 張圖、58 個影片影格。
程式碼檢索進步多少？點我翻面
MTEB Code 從 68.76 升到 78.68，提升 9.92 分。

✅ 離開前自測（全勾＝這課真的學會了）

0%