检索增强生成的检索端，能不能整个塞进手机或浏览器？Google DeepMind 2026 年 10 月发布的 EmbeddingGemma 2 给出了肯定答案：740M 参数、Apache 2.0、文本代码图像视频音频五种模态全部投影到同一个 768 维向量空间，全程零网络请求。本文拆它的架构设计、截断取舍和落地时的工程细节。
架构：模块化编码器加共享空间
不用多模型拼接，而是每种模态配专门编码器，统一投进共享向量空间：文本与代码核心 270M（Gemma 4 架构适配解码器，8192 token 上下文），视觉编码器加 170M（图像、文档截图、视频帧），音频编码器加 300M（直接吃原始音频，不做转录）。
模块按需加载，部署四档：纯文本 270M、文本加视觉 440M、文本加音频 570M、全模态 740M。关键设计是四档输出落在同一向量空间——用纯文本版生成的查询向量，可以检索全模态版索引的文档，扩功能不用重建向量库。
它和 Gemma 4 共享分词器与音频编码器，同一条端侧管线里检索和生成可以复用组件，总内存低于两套独立栈。
截断省存储的三个前提
输出默认 768 维，训练时用了套娃表示学习（MRL），推理时可直接截到 512、256 或 128 维，无需重训。官方口径：256 维时文本与代码基本无损，图像视频语音检索约保留 95%；128 维只适合纯文本。
工程上有三条铁律，踩了就静默失准：
- 截断后必须重新做 L2 归一化。截断破坏了单位长度，直接算余弦相似度结果是错的。
- 查询向量和文档向量必须同维度。一边 768 一边 256，相似度毫无意义。
- 省的只是向量本体。索引结构和元数据的存储开销另算，别指望存储线性下降四分之三。
验证方法：固定一批查询和标准答案，768 维跑一遍基线，逐档下探记录召回率变化，找到精度与存储的平衡点再定生产配置。
精度选择与 token 预算
官方明确警告：不要用 FP16，动态范围会导致数值溢出或质量静默下降，用 BF16 或 FP32。这个坑的表现很隐蔽——不报错，只是检索质量悄悄变差，排查时先查精度配置。
量化后 Pixel 11 Pro 上纯文本权重约 191MB 活跃内存，全模态约 567MB。注意这只是模型权重，不含运行时、激活值、向量索引和输入数据，实际占用更高。
8K token 上下文是上一代的四倍。换算参考：每张图像约 280 token、每帧视频约 140 token、每秒音频约 25 token，单次输入上限约 29 张图或 5.5 分钟音频。文本和媒体共享这 8K 预算，混合输入时留量要重新算。
代码上手
from sentence_transformers import SentenceTransformer
# 纯文本档：关掉不用的编码器，权重根本不加载
model = SentenceTransformer(
"google/embeddinggemma-2",
config_kwargs={"vision_config": None, "audio_config": None},
)
q = model.encode(query, prompt_name="SearchQuery", normalize_embeddings=True)
d = model.encode(docs, prompt_name="Document", normalize_embeddings=True)
prompt_name 背后是训练时约定的任务前缀——查询和文档必须用不同提示，用混了召回明显下降。浏览器侧走 transformers.js 加 WebGPU，模型首次加载后缓存进 IndexedDB，之后离线可用；公开数据显示单次查询约 20 到 70 毫秒。
最小可用管线：入库时文档图片音频分块编码存向量，查询时编码问题取 Top-k，生成时把原片段连同问题交给本地 Gemma 4。保留原始文件的可寻址引用——向量邻近只是检索候选，需要精确措辞或截图里的小数字时必须回取原文。
用不用它：边界清单
适合：隐私敏感场景（数据不出设备）、离线或弱网环境、跨模态混合资料库、本地代码检索、纯静态站点的零后端检索。
不适合照搬：追求极致检索质量且数据可上云时，云端模型仍可能更优；纯文本且已有成熟嵌入模型时，迁移前先用真实查询对比；官方基准分数未经独立复现，"小模型最优"的结论只当方向参考。
上线前该验证的三件事：代码检索的提升在自己的仓库上是否成立、256 维截断后召回掉了多少、目标硬件上非 FP16 精度配置是否稳定。用自己的数据跑通，再决定迁不迁。
评论0