写在前面

如果你正在构建 RAG 系统，或者你的业务涉及图文、视频、音频等多种内容形态，那这篇文章值得你花 10 分钟读完。

3 月 10 日，Google 发布了 Gemini Embedding 2。这不是又一个 " 更大更强 " 的大模型——它是一个嵌入模型（Embedding Model），解决的是 AI 系统里一个看似基础、实则最关键的问题：

怎么让机器理解 " 这段文字 " 和 " 那张图片 " 说的是不是同一件事？

以前，文本要用文本模型处理，图片要用图片模型处理，音频还得先转成文字。如果你想让系统同时理解文字、图片和视频，就得搭一整条复杂的管线，把不同模型的输出想办法对齐到一起。

Gemini Embedding 2 的做法是：把文本、图片、视频、音频、PDF 五种模态，全部塞进同一个向量空间。一次 API 调用搞定。

这听起来像一个技术细节。但对于正在做 AI 应用的团队来说，它可能是今年投入产出比最高的一次基础设施升级。

嵌入模型为什么重要？先说 30 秒背景

如果你用过 ChatGPT、文心一言或者其他大模型，你可能遇到过一个问题：大模型的知识是有截止日期的，而且它不认识你公司内部的文档。

RAG（检索增强生成）就是为了解决这个问题——先从你的知识库里检索最相关的内容，再把这些内容喎给大模型，让它基于真实信息来回答。

而检索的质量，几乎完全取决于嵌入模型。

嵌入模型做的事情很简单：把一段内容（文字、图片、视频……）变成一组数字（向量）。两段内容的向量越接近，它们的含义就越相似。

所以，嵌入模型的质量，直接决定了你的 AI 系统能不能找到正确的信息、给出靠谱的答案。

五种模态，一个向量空间

Gemini Embedding 2 原生支持五种输入类型，以下是具体规格：

真正的杀手锧：交错输入

更关键的能力是 " 交错输入 "（interleaved input）。你可以在一次请求里同时传入一张图片和一段文字描述，模型会把它们理解为一个整体，输出一个融合了图文语义的向量。

举个实际场景：一段产品介绍视频 + 一段口播音频 + 一张产品图 + 一段文字说明。以前需要四个模型分别处理再拼接，现在直接丢进一个 API，出来就是一个统一的向量。

从 " 各自为战 " 到 " 从头到尾一起理解 "

以前做多模态嵌入的业界标杆是 CLIP。它的做法是：一个视觉编码器处理图片，一个文本编码器处理文字，然后用对比学习把两边对齐。

问题在于，两个编码器各自独立工作，只在最后一步才 " 碰面 "。模态之间的细微关联，在最后对齐时已经丢了。

Gemini Embedding 2 完全不同。它直接构建在 Gemini 基础模型之上，所有模态共享同一个 Transformer 架构。文本、图片、视频、音频在网络的中间层就开始交互，形成深层的跨模态连接。

CLIP：各自处理，最后才碰面 → Gemini Embedding 2：从第一层就一起理解

" 俄罗斯套娃 " 技术：精度和成本，你全都要

做过向量检索的人都知道一个痛点：维度越高，效果越好，但存储和计算成本也越高。

Gemini Embedding 2 默认输出 3,072 维向量。如果你有几百万条数据全用 3,072 维存储，成本会很可观。

为此 Google 使用了一种叫做 Matryoshka Representation Learning（MRL）的技术。Matryoshka 就是俄罗斯套娃——大娃娃里面套小娃娃，每一层都是完整的。

普通模型 vs " 套娃 " 模型

普通的嵌入模型会把语义信息均匀分布在所有维度上。强行把 3,072 维截断到 768 维，精度会大幅下降——你丢掉了 75% 的信息。

但 Gemini Embedding 2 被训练成：把最重要的语义信息塞进最前面的维度。前 768 维已经包含了最核心的含义，后面的维度逐步增加细节。

两阶段检索：又快又准

实际使用中，你可以设计一个两阶段检索架构：

• 第一轮粗筛：用 768 维在百万级索引里快速找到 Top-K 候选

• 第二轮精排：对候选结果用完整的 3,072 维重新排序

这样你既拿到了大模型的精度，又只付出了小模型的延迟和成本。

result = client.models.embed_content (

model="gemini-embedding-2-preview",

contents=" 你的输入内容 ",

config=types.EmbedContentConfig ( output_dimensionality=768 )

)

注意：维度低于 3,072 时，输出向量默认不做归一化。如果你用余弦相似度计算，记得手动归一化。

基准测试：不只更好，而是换了赛道

根据 Google 的评测，Gemini Embedding 2 在 MTEB（Massive Text Embedding Benchmark）上全面超越上一代，两个方面尤为突出：

1. 检索准确率显著提升

在标准检索任务上，命中率显著提升，尤其在需要跨模态理解的场景下。

2. 告别 " 领域漂移 "

很多嵌入模型在通用数据（维基百科）上表现很好，但切换到专业领域（法律条文、医学文献、代码库）后准确率断崖式下跌——这叫 " 领域漂移 "（domain drift）。

Gemini Embedding 2 通过多阶段训练和多样化数据集，在零样本场景下对专业领域保持了更高的稳定性。

更大的上下文窗口 = 更完整的语义

8,192 token 的上下文窗口（上代仅 2,048）意味着你可以嵌入更大的文本块。在 RAG 场景中，更大的块保留了更完整的上下文，减少 " 检索回来的片段缺关键信息 " 的问题。

一个被低估的参数：task_type

Gemini Embedding 2 支持在请求时指定 task_type 参数，目前支持 8 种任务类型：

• RETRIEVAL_QUERY — 用于查询侧

• RETRIEVAL_DOCUMENT — 用于文档侧

• CLASSIFICATION — 用于分类

• CLUSTERING — 用于聚类

• SEMANTIC_SIMILARITY — 用于语义相似度

这不是一个可有可无的参数。当你建索引时用 RETRIEVAL_DOCUMENT，查询时用 RETRIEVAL_QUERY，模型会针对这种 " 不对称检索 " 模式优化向量的数学属性，直接提升命中率。

很多开发者在接入嵌入模型时会忽略它，但它对最终效果的影响，可能比调向量维度还大。

已有系统想迁移？注意这三件事

1. 必须重新索引

不同模型的向量处于不同坐标空间，不能混在同一个索引里比较。换模型就意味着全量重新嵌入。

2. 相似度阈值会漂移

原来 RAG 管线里用 0.6 作为过滤阈值，换模型后可能需要调到 0.7。必须通过 A/B 测试重新校准，不能直接平移。

3. 渐进式切量

Google Cloud 社区工程师推荐的迁移路径：

• 先建 " 影子索引 "，后台用新模型重新嵌入全部数据

• 按 5% → 20% → 50% → 100% 逐步切流量

• 新索引在全量负载下稳定运行至少一周，再下线旧索引

新项目？不用犹豫，直接用 gemini-embedding-2-preview。先从 768 维开始，按需扩展。

现在就能用

Gemini Embedding 2 目前以 gemini-embedding-2-preview 名称提供公开预览，通过 Gemini API 和 Vertex AI 调用。

生态支持方面，LangChain、LlamaIndex、Haystack、Weaviate、Qdrant、ChromaDB 等主流框架和向量数据库都已接入。Google 还提供了可在 Colab 里直接运行的交互式 Notebook。

为什么这次升级值得关注

嵌入模型是 AI 系统里最 " 不性感 " 但最关键的一层。大模型能不能给出靠谱答案，很大程度取决于检索层能不能找到正确的信息。而检索层的核心，就是嵌入模型。

Gemini Embedding 2 标志着嵌入模型正在从 " 文本专用工具 " 演进为 " 万物统一表示层 "。对开发者来说，有三点值得关注：

第一，存储成本可以大幅降低。MRL 带来的维度灵活性，让 768 维粗筛 + 3,072 维精排的两阶段架构成为现实。如果你在用 Milvus、Zilliz 等向量数据库，这意味着直接省钱。

第二，多模态管线可以大幅简化。电商的图文商品、教育的视频课程、医疗的影像报告——以前需要多套模型的管线，现在可能简化成一个 API 调用。

第三，" 交错输入 " 是真正的差异化能力。市面上多数嵌入模型还停留在单模态阶段。能在一次请求里理解图文视频音频的联合语义，这在实际业务中价值巨大。

嵌入模型的升级，可能是你的 AI 系统里投入产出比最高的一次改进。

参考来源：

• Google AI Blog: Gemini Embedding 2: Our first natively multimodal embedding model

• MarkTechPost: Google AI Introduces Gemini Embedding 2

• Google Cloud Community ( Karl Weinmeister ) : What you need to know about the Gemini Embedding 2 model