EmbeddingGemma 2：把文本、图片、音频和视频放进同一检索空间
做知识检索时，常见的麻烦不是“没有数据”，而是资料散落在文档、截图、录音和视频里：文字搜索找不到某段会议录音，图片也难以与文字查询直接关联。Google DeepMind 于 2026 年 10 月发布的 EmbeddingGemma 2，试图用一个多模态嵌入模型解决这个断层：将文本（包括代码）、图像、音频、视频及其组合映射到共享向量空间，供语义搜索、聚类和 RAG 使用。
它适合解决什么问题
EmbeddingGemma 2 有 740M 参数，模型卡描述其输出为 768 维向量，并支持 8K token 上下文。开发者可以在本地或边缘设备上构建跨模态索引，例如用文字查询定位视频片段，或按文本查找录音内容。它并不是完整的搜索引擎：向量生成之后，仍需自行选择向量数据库、索引策略、过滤条件和结果排序方式。
模型采用模块化设计。模型卡将文本部分标为 270M 参数，并提供可选择加载的视觉和音频编码器；若任务只涉及文本，就不必把所有模态组件都纳入部署。其 Matryoshka Representation Learning（MRL）支持 128、256、512、768 维等截断输出，减少向量存储空间，但降维后检索质量是否可接受，应该用自己的数据集评测，而不是把“最多节省 6 倍”当作对每种业务都成立的保证。
先从文本检索原型开始
下面用模型卡展示的 Sentence Transformers 接口生成文本向量，并计算一个小批次的相似度：
from sentence_transformers import SentenceTransformer
model = SentenceTransformer("google/embeddinggemma-2")
texts = [
"如何在本地设备上构建隐私优先的检索系统？",
"Local retrieval can keep private documents on-device.",
"周末的天气很晴朗。",
]
embeddings = model.encode(texts)
similarities = model.similarity(embeddings, embeddings)
print(similarities.shape)
这是一个文本工作负载示例，输出矩阵的行列对应输入句子；它不是完整的生产检索流程。落地时通常要把文档切块、保存向量与原文位置、为查询生成向量，再从向量库取回候选并做权限过滤。切块策略会影响语义边界：过短可能丢失上下文，过长则增加索引成本。上线前可用一组固定查询建立离线评测集，记录 Recall@K、延迟和峰值内存，并与现有模型作同条件对比。不要只比较向量相似度的几个例子；应覆盖常见查询、跨语言查询及容易混淆的负例。官方模型卡还提供 Transformers 的 AutoProcessor/AutoModel 用法以及多模态输入说明；在接入图片、音频或视频前，应按模型卡的输入格式与上下文限制实现，不能把文本 encode() 示例误当作通用多模态调用。
部署前要验证的三件事
第一，测量真实硬件上的延迟和内存。Google 的发布说明给出了 Pixel 11 Pro 上量化后的内存估算，但这不等于其他手机、笔记本或推理框架也有相同表现。第二，评估召回质量：用业务查询与标注相关文档比较不同向量维度，并观察截断、量化和语言分布的影响。第三，确认数据流边界。模型可以在本机运行，但索引服务、日志、备份和后续生成模型仍可能把内容带出设备；“本地嵌入”不自动等于整条 RAG 链路私有。
许可方面，Google 官方公告和 Hugging Face 模型卡均标注 Apache 2.0。模型卡列出文本、图像、视频、音频输入能力，也提示开发者查看其使用限制和安全说明。上线前应同时阅读许可与模型卡，而不是仅凭“开放模型”推断所有数据和用途都没有约束。
小结
EmbeddingGemma 2 的价值在于把跨模态向量检索变成可在消费级设备探索的方案，同时允许按任务选择模态组件、调整向量维度。它尤其适合原型验证：先用文本资料建立基线，再逐步加入真正需要的图片或音视频数据，并针对目标设备、隐私边界和召回指标做实测。别把模型发布时的硬件估算、维度压缩比例直接当作生产承诺；最终是否值得部署，应由自己的数据和设备测试决定。