Embedding on KnightLi的博客

Gemini Embedding 2：把文字、圖像、影片和音訊放進同一個向量空間

Mon, 04 May 2026 06:01:10 +0800

Google Developers Blog 介紹了 Gemini Embedding 2 的開發用法。這個模型已經透過 Gemini API 和 Gemini Enterprise Agent Platform 進入 GA，重點不只是「新的 embedding 模型」，而是把文字、圖像、影片、音訊和文件映射到同一個語義空間。

這會讓檢索系統的邊界變寬。過去很多 RAG 流程需要先把圖片、影片、音訊拆成文字或中繼資料，再分別建立索引；Gemini Embedding 2 則可以直接處理多模態輸入，讓代理、搜尋和分類系統更容易圍繞真實業務材料工作。

原文連結：Building with Gemini Embedding 2: Agentic multimodal RAG and beyond

模型能力

Gemini Embedding 2 支援 100 多種語言。單次請求可以處理：

最多 8,192 個文字 token
最多 6 張圖片
最多 120 秒影片
最多 180 秒音訊
最多 6 頁 PDF

它的關鍵點是「統一語義空間」。開發者可以把不同模態的內容放在同一套向量表示裡，用同一種檢索、聚類或重排序邏輯處理。

例如，文字描述和圖片可以放在同一次 embedding 請求裡：

from google import genai
from google.genai import types

client = genai.Client()

with open('dog.png', 'rb') as f:
    image_bytes = f.read()
result = client.models.embed_content(
    model='gemini-embedding-2',
    contents=[
        "An image of a dog",
        types.Part.from_bytes(
            data=image_bytes,
            mime_type='image/png',
        ),
    ]
)

print(result.embeddings)

如果你希望每個輸入分別得到 embedding，而不是聚合成一個向量，可以使用 Batch API。原文也提到，Agent Platform 對這類批次支援還在跟進中。

對 RAG 的意義

多模態 embedding 對代理式 RAG 很有用。一個 AI agent 可能需要同時檢查程式碼倉庫、PDF、截圖、圖表、音訊會議紀錄和產品圖片。如果所有資料都能進入同一個語義空間，檢索鏈路就不必為每種材料單獨設計一套入口。

Google 建議根據任務使用 task prefix，讓 embedding 更貼近檢索目標。例如問答、事實核查、程式碼檢索和搜尋結果，可以使用不同前綴：

# Generate embedding for your task's query:
def prepare_query(query):
    return f"task: question answering | query: {content}"
    # return f"task: fact checking | query: {content}"
    # return f"task: code retrieval | query: {content}"
    # return f"task: search result | query: {content}"
# Generate embedding for document of an asymmetric retrieval task:
def prepare_document(content, title=None):
    if title is None:
        title = "none"
    return f"title: {title} | text: {content}"

這種前綴適合非對稱檢索：使用者查詢往往很短，文件內容往往很長。把 query 和 document 分別按任務格式整理，可以改善短查詢到長文件之間的匹配。

原文給了兩個落地回饋：

Harvey 在法律檢索基準上，Recall@20 precision 相比上一代 embedding 提升 3%。
Supermemory 在 Recall@1 搜尋準確率上提升 40%，並把它用於記憶、索引、搜尋和問答管線。

這些數字不代表所有場景都會同幅度提升，但說明多模態 embedding 已經不只是展示能力，而是在真實檢索產品中產生效果。

視覺搜尋

Gemini Embedding 2 也適合做以圖搜圖、圖文混合搜尋和商品識別。原文提到服裝租賃公司 Nuuly 用它匹配倉庫中未打標籤的服裝照片，使 Match@20 從 60% 提升到接近 87%，整體成功識別率從 74% 提升到 90% 以上。

這類場景的關鍵不是生成內容，而是理解「這張圖片和哪個庫存、文件或商品紀錄最接近」。如果你的業務裡有大量圖片、影片片段或掃描件，多模態 embedding 會比純文字索引更自然。

檢索重排序

Embedding 還可以用於 rerank。常見做法是先用基礎檢索拿到一批候選結果，再計算候選結果和使用者查詢之間的相似度，把更相關的內容排到前面：

# 1. Define a function to calculate the dot product (cosine similarity)
def dot_product(a: np.ndarray, b: np.ndarray):
  return (np.array(a) @ np.array(b).T)
# 2. Retrieve your embeddings
# (Assuming 'summaries' is your list of search results)
search_res = get_embeddings(summaries)
embedded_query = get_embeddings([query])

# 3. Calculate similarity scores
sim_value = dot_product(search_res, embedded_query)

# 4. Select the most relevant result
best_match_index = np.argmax(sim_value)

原文還提到一種思路：先讓模型根據內部知識生成一個假設答案，再把這個假設答案做 embedding，與候選內容比較相似度，用來挑出語義更貼近的結果。這對問答型 RAG 尤其有用。

聚類、分類和異常檢測

除了檢索，embedding 也適合聚類、分類和異常檢測。和前面的問答檢索不同，這些屬於對稱任務，query 和 document 可以使用同一種任務前綴：

# Generate embedding for query & document of your task.
def prepare_query_and_document(content):
    # return f'task: clustering | query: {content}'
    # return f'task: sentence similarity | query: {content}'
    # return f'task: classification | query: {content}'

這類任務可以用於輿情分類、內容審核、相似資產歸類、異常樣本發現，也可以幫助 agent 對大量上下文材料先做整理，再進入後續推理。

儲存和成本

Gemini Embedding 2 預設輸出 3,072 維向量。它使用 Matryoshka Representation Learning，因此可以透過 output_dimensionality 把向量截斷到更小維度。Google 推薦在效率優先時使用 1,536 或 768 維：

result = client.models.embed_content(
    model="gemini-embedding-2",
    contents="What is the meaning of life?",
    config={"output_dimensionality": 768}
)

向量可以存到 Agent Platform Vector Search、Pinecone、Weaviate、Qdrant、ChromaDB 等系統裡。成本方面，原文提到 Batch API 可提供更高吞吐，並達到預設 embedding 價格的 50%。

開發者該怎麼用

如果你已有文字 RAG，可以先從兩類增量改造開始：

把 PDF、截圖、圖片說明和文字文件放入同一個索引，測試查詢召回是否更穩定。
給不同任務加 task prefix，例如問答、事實核查、程式碼檢索、商品搜尋，不要把所有內容都按同一種 embedding 方式處理。

如果你在做新產品，可以優先考慮這些方向：

企業知識庫：同時檢索文件、圖表、簡報截圖和會議材料。
視覺搜尋：用圖片、文字或混合輸入查找商品、資產、設計稿和檔案。
Agent 工具鏈：讓 coding agent、研究 agent 或客服 agent 檢索多種格式的業務材料。
內容治理：對文字、圖片、影片片段做統一分類、聚類和異常檢測。

Gemini Embedding 2 的價值在於把多模態材料變成同一套可檢索資產。對開發者來說，這會減少「先轉文字再檢索」的中間層，也讓 RAG 系統更接近真實世界的資料形態。

常見向量模型怎麼選：OpenAI、BGE、E5、GTE、Jina 對比

Thu, 23 Apr 2026 15:23:47 +0800

做 RAG、語義搜尋、知識庫召回時，很多人一開始都會糾結同一個問題：向量模型這麼多，到底該選哪一個。

常見模型大致可以分成兩組。一組是通用文字向量，覆蓋中英文和多語言任務；另一組更適合中文場景，重點看中文檢索、中文問答和中文知識庫效果。

如果先給一個很短的結論，可以這樣看：

想省事、直接用 API：text-embedding-3-small 或 text-embedding-3-large
想做中文檢索，且希望開源可自部署：bge-base-zh-v1.5、bge-m3、gte-large-zh
想兼顧多語言：multilingual-e5-base、multilingual-e5-large、jina-embeddings-v3
想在中文場景裡壓低成本：bge-small-zh-v1.5、gte-base-zh

一、先按類型看這些模型

1. OpenAI 系列

text-embedding-3-small
text-embedding-3-large

這類模型的特點是調用簡單、穩定，適合直接接 API 做檢索、RAG、分類和相似度匹配。它們的優勢不在於「某一個中文榜單分數特別高」，而在整體體驗完整：接入門檻低、效果穩定、工程成本也低。

如果團隊不想自己託管模型、不想維護推理服務，OpenAI 這類方案通常最省時間。

2. BGE 系列

BAAI/bge-small-zh-v1.5
BAAI/bge-base-zh-v1.5
bge-m3

BGE 是中文檢索裡很常見的一條線。bge-small-zh-v1.5 和 bge-base-zh-v1.5 更偏中文單語任務，適合中文語義搜尋、知識庫召回、FAQ 匹配。bge-m3 則更通用，能覆蓋多語言、多粒度和更複雜的檢索場景。

如果你的資料主要是中文文本，BGE 往往是最容易進入候選名單的一組。

3. E5 系列

intfloat/multilingual-e5-base
multilingual-e5-large

E5 系列的特點是多語言能力比較均衡，適合中英混合、跨語種檢索、國際化內容庫。它不是只盯中文，而是更強調「不同語言都能放到一個統一檢索體系裡」。

如果你的語料不是純中文，而是中文、英文、日文甚至更多語言混在一起，E5 通常比中文專用模型更穩。

4. GTE 系列

Alibaba-NLP/gte-base-zh
gte-large-zh

GTE 在中文任務裡也很常見，定位和 BGE 有點接近，都是中文檢索的實用型選手。它的特點通常是比較平衡，沒有特別複雜的使用門檻，適合做中文知識庫、站內搜尋和企業內部文件召回。

如果你想在中文開源模型裡多做一組對照，GTE 很值得一起評測。

5. Jina Embeddings

jina-embeddings-v3

Jina 這一類更偏通用和現代工程場景，常見於多語言檢索、長文字、網頁內容處理等任務。它經常出現在「一個模型覆蓋更多任務形態」的討論裡，適合希望統一 embedding 層的團隊。

如果你的內容來源比較雜，既有網頁、文件，也有多語言文本，Jina 往往是一個值得測試的備選。

二、中文場景裡，哪些模型更常用

如果把範圍收窄到中文場景，常見候選基本就是這些：

bge-small-zh-v1.5
bge-base-zh-v1.5
bge-m3
gte-base-zh
gte-large-zh
multilingual-e5-base
multilingual-e5-large

這幾類裡，最典型的分法其實不是「誰絕對更強」，而是下面這三個問題：

你的資料是不是以中文為主
你是不是需要多語言
你更在意效果、成本，還是部署方便

三、把這些模型放在一起看

1. 如果只看中文效果

純中文知識庫、中文問答、中文文件召回，一般優先看 BGE 和 GTE。

bge-small-zh-v1.5：更輕，適合成本敏感場景
bge-base-zh-v1.5：通常是中文場景裡更均衡的一檔
gte-base-zh：和輕量 BGE 類似，適合先做基線
gte-large-zh：更適合追求召回品質的場景
bge-m3：適合希望把中文檢索和更複雜能力放到一起考慮的團隊

如果語料幾乎全是中文，E5 雖然也能用，但很多時候不會是第一優先。

2. 如果需要多語言

這時優先級會明顯變化。

multilingual-e5-base 和 multilingual-e5-large 更適合多語言統一檢索
jina-embeddings-v3 也適合多語言和通用文字任務
bge-m3 比傳統中文專用模型更適合擴展到多語言
text-embedding-3-small 和 text-embedding-3-large 適合想直接上 API 的場景

如果你的庫裡同時有中文、英文、產品文件、網頁文案和使用者問題，多語言模型會比中文專用模型省掉很多後續改造成本。

3. 如果要控制推理和儲存成本

輕量模型更有優勢。

bge-small-zh-v1.5
gte-base-zh
multilingual-e5-base
text-embedding-3-small

這類模型通常更適合：

文件量大
更新頻繁
需要批量向量化
對延遲和成本比較敏感

如果資料規模很大，embedding 維度、推理速度、索引占用都會直接影響總成本，所以「先上小模型做基線」通常是更穩的做法。

4. 如果優先追求上限

更大的模型通常更適合複雜檢索或高品質召回，例如：

text-embedding-3-large
multilingual-e5-large
gte-large-zh
bge-base-zh-v1.5
bge-m3

但這裡要注意，模型越大不代表線上體驗一定越好。很多專案最後的瓶頸不是模型本身，而是切分策略、召回條數、重排、資料清洗和評測方式。

四、每個模型更適合什麼任務

模型	更適合的場景	簡單判斷
`text-embedding-3-small`	通用檢索、RAG、快速接入	API 省事，成本友好
`text-embedding-3-large`	更重視品質的通用檢索	效果優先，工程最省心
`bge-small-zh-v1.5`	中文輕量檢索	中文常用入門款
`bge-base-zh-v1.5`	中文知識庫、FAQ、語義搜尋	中文場景很均衡
`bge-m3`	中文為主但希望兼顧更複雜檢索	擴展性更強
`multilingual-e5-base`	多語言基礎檢索	國際化專案常用
`multilingual-e5-large`	多語言高品質召回	更偏效果導向
`gte-base-zh`	中文輕量召回	適合先做基線
`gte-large-zh`	中文品質優先場景	可作為 BGE 對照組
`jina-embeddings-v3`	多語言、網頁、通用文字任務	統一 embedding 層時值得測

五、實際選型時可以怎麼決策

如果你只是要落地，而不是寫論文，選型順序可以簡單一點：

場景一：中文知識庫

優先測試這幾組：

bge-base-zh-v1.5
gte-large-zh
bge-small-zh-v1.5

如果預算緊，先從小模型開始；如果更重視召回品質，再往更大的模型試。

場景二：中英混合知識庫

優先測試：

multilingual-e5-base
multilingual-e5-large
text-embedding-3-small
text-embedding-3-large

如果不想自部署，OpenAI 會更直接；如果要自己託管，E5 更常見。

場景三：中文為主，但未來可能擴到多語言

優先測試：

bge-m3
multilingual-e5-base
jina-embeddings-v3

這類場景最怕的是一開始只看中文，後面又要重做整個向量庫。

六、最後怎麼選，關鍵不是「榜單第一」

向量模型選型裡，最容易踩的坑就是只看公開分數，然後直接上線。

更可靠的方式通常是：

先挑 2 到 4 個候選模型
用自己的真實資料做 embedding
跑一輪召回評測
再結合成本、延遲、部署方式做決定

因為真正決定結果的，往往不是模型名本身，而是模型和你的語料、分塊策略、查詢形式到底合不合。

總結

如果只想記住一版實用結論，可以這樣：

中文優先：先看 bge-base-zh-v1.5、gte-large-zh
成本優先：先看 bge-small-zh-v1.5、gte-base-zh、text-embedding-3-small
多語言優先：先看 multilingual-e5-base、multilingual-e5-large、jina-embeddings-v3
直接上 API：先看 text-embedding-3-small、text-embedding-3-large
想兼顧中文和後續擴展：先看 bge-m3

沒有一個模型適合所有專案，但大多數專案都可以先從這幾組裡很快篩出第一批候選。