谷歌开放新嵌入模型：图片音频文字同一个空间
Google 10 月 6 日发布开放权重的 EmbeddingGemma 2：基于 Gemma 4，共 740M 参数，文字、图片、音频、视频与代码嵌入同一个空间，视觉与音频编码器可选，只处理文字时只需 270M。上下文 8K，是上一代的 4 倍。代码检索 MTEB 从 68.76 升到 78.68，多语言文本几乎持平。
编辑标为信号级，适合持续跟踪。
本页目录12 节
记录
信号正文
#发生了什么
10 月 6 日 Google 发布 EmbeddingGemma 2，一个开放权重的轻量级多模态嵌入模型，基于 Gemma 4。本条的数字来自 Google 的发布文章与 Hugging Face 上的模型卡。
模块化的 740M
- 总参数 740M，按需组合：
- 只处理文字：270M（130M 主干加 140M 嵌入层）
- 可选视觉编码器 170M
- 可选音频编码器 300M
- 文字、图片、音频、视频和代码进入同一个向量空间，支持图文混合输入
- 上下文 8K token，是 EmbeddingGemma 1 的 4 倍，约能放 5.5 分钟音频、29 张图或 58 帧视频
- 向量 768 维，可以截断到 512、256 或 128 维，存储最多省 6 倍
基准：代码大涨，文字持平
与 EmbeddingGemma 1 对比：
- MTEB 代码 v1：78.68，上一代 68.76
- MTEB 多语言 v2：61.36，上一代 61.15，基本没变
新增的多模态成绩：MMEB v2 总分 59.01（图片 57.28、文档图像 67.84、视频 50.67），音频的 MAEB 49.39。
截断有代价：截到 128 维时，代码检索从 78.68 降到 71.41，MMEB 总分从 59.01 降到 45.65。Google 称它「胜过两倍大小的专用模型」，但没有给出对比数字。
端侧
在 Pixel 11 Pro 上量化运行，只用文字时约占 191 MB 内存，多模态约 567 MB，没有给出延迟。Hugging Face、Kaggle、Ollama、llama.cpp、transformers.js、MLX、vLLM 都已可用。
许可标为 Apache 2.0，但许可链接指向的是 Gemma 4 许可，商用前值得核对。
对读者意味着什么
- 做代码检索的团队，值得在自己的代码库上换上它测一次，提升幅度最大的是这一块。
- 想做图文、音视频统一检索又受限于端侧资源的应用，有了一个几百 MB 的选项。
- 用截断维度省存储之前，先在自己的数据上量一下召回损失：128 维的损失并不小。
为什么是现在
为什么重要
#一个几百 MB、能在手机上跑的开放模型，把文字、图片、音频和代码放进同一个向量空间。代码检索提升明显，但纯文本几乎没变；截断维度能省存储，也会掉召回。
背景
技术背景
#嵌入模型把内容转成向量，相近的内容向量也相近，检索时比较向量距离。共享向量空间意味着可以用文字查图片或音频。Matryoshka 式训练让向量可以截短使用，用精度换存储。
关注人群
谁该关注
#下一步
学习路径
#- 读《检索增强生成基础》，了解嵌入模型在检索链路里的位置
- 读《检索流水线调优》，准备一份自己的检索评测集
- 用 768 维与 256 维各跑一次，对比召回与存储
- 读《端侧模型部署与硬件适配》，评估 191 MB 与 567 MB 两种配置
关系网络
在技术网络中的位置
#当前技术与相邻技术、技能和背景知识的连接，点击节点可继续探索。
延伸思考
后续问题
#- 你的检索里代码、文字、图片各占多少？哪一块会受益最大？
- 截到 256 维时，你的召回掉了多少？省下的存储值不值？
- 许可链接指向 Gemma 4 许可，你的使用场景是否受其中条款限制？
发布记录
收录于
#收录这条信号的技术简报，新的在前；最后一行是它那一周的周回顾。标签是它在那一期所在的栏目。
来源参考