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

没有一个模型适合所有项目，但大多数项目都可以先从这几组里很快筛出第一批候选。