本地 RAG 也能搜图片和音频：EmbeddingGemma 2 给 AI Agent 一套多模态索引
很多 RAG 系统的问题不在生成模型，而在检索入口：文本、截图、录音和视频各自存放，Agent 想回答“那次会议里提到的架构图在哪里”，往往只能先把所有资料转成文字。Google DeepMind 发布的 EmbeddingGemma 2，试图用一个本地优先的多模态嵌入模型，把文字、代码、图片、音频和视频映射到统一的向量空间。
这不是一个聊天模型，也不会直接生成答案。它负责把查询和资料转换成向量，供向量数据库或 Agent 的检索层计算相似度。对于希望把私有代码库、设计稿、会议录音和屏幕录像接入工作流的开发者，这个定位比“又一个大模型”更实用。
它解决的是检索层的割裂
EmbeddingGemma 2 的公开资料给出了几个值得关注的设计点：
- 完整多模态版本为 740M 参数，文本场景可以只使用约 270M 参数的组件；视觉和音频编码器是可选模块。
- 文本、图片、视频和音频可以进入共享的 embedding 空间，因此可以用文字查询媒体，也可以用音频片段寻找相关视频内容。
- 模型使用 Matryoshka Representation Learning，向量维度可以从 768 截断到 512、256 或 128，再重新归一化。维度越低，向量存储和相似度计算的成本越小。
- 上下文窗口为 8K token。官方给出的示例包括最长约 5.5 分钟音频、29 张图片或 58 帧视频，也可以处理交错的多模态输入。
这些数字是模型卡和 Google 官方发布材料中的能力描述，不等于任何设备上的固定吞吐量。真实延迟仍取决于量化方式、运行时、输入类型和硬件。
更关键的是，它面向端侧运行。官方测试材料提到，在 Pixel 11 Pro 上量化后的文本模式约需 191MB 活跃内存，完整多模态模式约需 567MB。对企业知识库或个人工作站而言，这意味着敏感资料可以留在本地，检索请求不必先上传到第三方 API。
给代码 Agent 的实际价值
第一种场景是本地代码检索。代码 Agent 不只需要按文件名寻找源码，还需要理解“处理 OAuth 回调的中间件”“把错误转换成重试信号的函数”这类语义查询。Google 公布的 MTEB Code 结果中，EmbeddingGemma 2 从上一代的 68.76 提升到 78.68；这使它适合做代码库索引、语义代码搜索和 Agent 的上下文召回。
第二种场景是跨媒体知识库。例如一次线上会议留下了录音、白板截图和演示视频。用户可以用自然语言检索“讨论缓存失效的那五分钟”，再由生成模型读取召回片段，生成带来源的摘要。这里 EmbeddingGemma 2 只负责找资料，事实回答仍应由上层 RAG 流程完成。
第三种场景是离线桌面助手：先用本地 embedding 对文件、截图和音频建索引，再让 Gemma 或其他生成模型根据召回结果回答问题。官方列出的集成方向包括 MediaPipe、LiteRT、transformers.js、WebGPU、llama.cpp、Ollama、LM Studio、vLLM 和 Qdrant。开发者可以按部署环境选择运行时，而不是把整个检索链锁定在单一云服务上。
从最小文本检索开始
先不要一上来处理视频。使用 Sentence Transformers，可以从文本查询和文档检索验证索引流程：
from sentence_transformers import SentenceTransformer
model = SentenceTransformer("google/embeddinggemma-2")
query = "如何处理 OAuth 回调失败？"
document = "回调中间件负责验证 state，并把上游错误转换为可重试事件。"
query_vector = model.encode(query, prompt_name="SearchQuery")
document_vector = model.encode(document, prompt_name="Document")
print(model.similarity(query_vector, document_vector))
上面的模型 ID 和 prompt_name="SearchQuery"、prompt_name="Document" 调用来自公开模型卡；示例中的文档内容只是演示数据。接入真实项目时，应该把返回向量写入 Qdrant 等向量数据库，并保存文件路径、提交哈希、时间戳等元数据。这样 Agent 不仅能召回片段，还能把答案链接回原始证据。
需要注意模型卡对输入类型有明确约定：检索查询可使用 task: search result | query: ...，文档则可使用 title: ... | text: ...。不要把所有字符串无差别地编码，否则查询向量和文档向量的训练意图不一致，检索质量可能下降。
上线前的三个检查点
第一，确认许可和访问条件。Google 的公告称 EmbeddingGemma 2 采用 Apache 2.0；但具体模型仓库仍应按模型卡和下载页面的条款执行，不要仅凭名称判断许可。
第二，区分“维度更小”和“质量完全不变”。128 维向量能明显减少存储，但模型卡的 MTEB 表格显示，不同维度的得分并不相同。应在自己的代码库和语言分布上测试召回率，再决定是否从 768 降维。
第三，分离检索与生成的责任。EmbeddingGemma 2 找到相似资料，不代表资料本身正确，也不代表生成模型会引用正确片段。生产环境应保留来源 ID、相似度分数和召回文本，并对高风险操作设置人工确认。
EmbeddingGemma 2 的价值不只是“参数更小”：它把多模态检索、端侧隐私和代码搜索放进同一个接口方向。对于正在构建本地 Agent、离线知识库或跨媒体 RAG 的团队，先用文本和代码做小规模评测，再逐步加入图片、音频和视频，可能比直接迁移一套昂贵的云端多模态检索服务更稳妥。