768 维装下文本、代码、图像、视频和音频：谷歌 EmbeddingGemma 2 拆了检索的墙

做检索系统的人都有一个共同的痛：文本有一套向量库，图片有一套，视频又有一套，跨模态搜索往往要在几个互不兼容的空间里来回搬运。谷歌这次想做的，是把这些墙直接拆掉。

一分钟速览

• EmbeddingGemma 2 是谷歌发布的开放权重多模态嵌入模型，基于 Gemma 4，采用 Apache 2.0 许可证。
• 文本、代码、图像、视频、音频被映射进同一个 768 维语义空间，可以直接比较相似度。
• 支持按需加载子编码器，参数规模从 2.7 亿到 7.4 亿，面向手机、笔记本等设备端低延迟场景。
• 在代码搜索和技术内容检索上明显强于上一代，适合本地代码库索引和智能体代码搜索。
• 支持套娃表示学习（MRL），768 维截断到 128 维后，100 万条向量的存储从约 1.5GB 降到 250MB。

为什么“同一个空间”很重要

多模态检索过去的主流做法，是为每种媒体训练一个编码器，再在应用层做对齐。问题是，不同编码器产出的向量维度不同、分布不同，跨模态比较要么依赖额外的映射层，要么干脆做不到。EmbeddingGemma 2 的思路更直接：不管输入是文字、代码、截图、视频还是录音，最后都落在同一个 768 维空间里，距离近就代表语义近。

这带来的直接变化是，开发者可以用一句自然语言去搜代码、搜屏幕截图、搜录音，也可以用文字描述去检索视频内容，而不需要为每种媒体维护一套独立的嵌入空间。对 RAG 系统来说，这意味着知识库的边界被拓宽了：以前只能检索文档，现在可以把会议录音、产品截图、演示视频一起放进去。

小模型，设备端优先

EmbeddingGemma 2 的定位很明确：不是云端最大的嵌入模型，而是能在消费级硬件上跑得动的那个。它允许开发者只加载应用需要的编码器，参数规模从 2.7 亿起步，覆盖文本和代码；要完整多模态能力时，再扩展到 7.4 亿。这种“按需拼装”的设计，对移动端和边缘设备尤其友好——搜索、分类、聚类这些任务，不必每次都把请求发到云端。

存储优化是另一个实用点。模型支持套娃表示学习，可以把 768 维向量截断成更短的单位向量。按 bfloat16 精度计算，100 万条 768 维向量大约占 1.5GB 内存，截断到 128 维后只需 250MB，降到原来的六分之一。代价是质量折损：在 128 维下，文本任务大约能保留 90% 的质量，但图像、视频和语音检索会降到约 75%。谷歌的建议也很直接：只有在存储或速度确实吃紧时才截断。

社区提醒的两个坑

模型发布后，开发者讨论最热烈的不是榜单，而是使用细节。有用户提醒，任务前缀不是可选项：索引文档时如果误用了查询前缀，而不是规定的“title: none | text:”格式，召回率会明显下降。另一个更容易被忽略的问题是归一化顺序——如果要做 MRL 截断，应该先切片，再对较短的向量做 L2 归一化；如果先在 768 维上归一化再截断，得到的向量范数就是错的。

也有开发者给出了相对冷静的评价：真正令人印象深刻的是图像和音频能进入同一个共享语义空间；如果只看纯文本任务，这一代的提升并不算巨大。这个判断值得参考——它说明 EmbeddingGemma 2 的价值主要在“跨模态”，而不是“刷新文本检索纪录”。

趋势洞察

嵌入模型正在从“检索组件”变成“端侧基础设施”。当文本、代码、图像、视频、音频被压进同一个空间，搜索的形态会先发生变化：不再是输入关键词返回链接，而是用任意一种媒介描述，去召回任意一种媒介的内容。对开发者来说，接下来要补的课不是模型选型，而是数据治理——前缀、归一化、截断策略这些看似琐碎的细节，往往决定召回率是 90% 还是 60%。