EmbeddingGemma 2 多模态搜索将 AI 检索带到端侧，对云优先管线形成压力

Google 于 10 月 6 日发布了 EmbeddingGemma 2 多模态搜索，将五类内容纳入一款面向消费级设备运行而设计的模型。这款拥有 7.4 亿参数的模型，可在同一共享空间内嵌入文本、代码、图像、视频和音频。这改变了一项常见的权衡：开发者不再需要默认认为，广泛的媒体搜索必须依赖云优先管线或多个独立模型。

真正重要的竞争，并不只是 Google 与另一家模型提供商之间的较量。它是统一的本地模型与众多现有搜索产品背后转录、字幕生成、嵌入、存储和检索服务集合之间的竞争。Google 表示，EmbeddingGemma 2 可替代其中多个环节，同时让私密内容留在手机、笔记本电脑或边缘设备上。

这一承诺仍需在 Google 的基准测试和展示应用之外接受检验。紧凑型模型必须在检索质量、电池消耗、索引时间和硬件兼容性之间取得平衡。EmbeddingGemma 2 让本地多模态检索更具可信度，但并未让这些工程约束消失。

EmbeddingGemma 2 多模态搜索统一五类内容

此次发布将 EmbeddingGemma 从文本检索模型扩展为个人媒体、代码、文档和录音的通用搜索层。

嵌入模型会将内容项目转化为其语义的数值表示。搜索系统会比较这些向量来定位相关资料，即使查询和目标内容并不包含相同词语。

EmbeddingGemma 2 将输入映射到统一的 768 维向量空间。因此，文本查询与相关图像可以在数学意义上彼此接近。同样的原理也适用于代码、视频帧、语音音频和混合输入。

这个公共空间支持一些在纯文本系统中较为别扭的搜索方式。用户可以描述一张照片，而无需知道其文件名。语音备忘录可以成为搜索匹配视频片段的查询。开发者也可以使用自然语言，在本地代码库中寻找相关函数。

Google 的 EmbeddingGemma 2 发布公告将这种跨模态检索作为核心变化。第一代 EmbeddingGemma 专注于 100 多种语言的文本；其继任者在保留多语言文本支持的同时，加入了专用的视觉和音频组件。

完整配置包含 7.4 亿参数，由 2.7 亿参数的文本和代码基础模型、1.7 亿参数的视觉编码器，以及 3 亿参数的音频编码器组成。开发者可以省略应用不需要的组件。

纯文本部署只加载 2.7 亿参数的基础模型。加入视觉后，活跃配置增至 4.4 亿参数。文本与音频需要 5.7 亿参数，而所有受支持模态则使用完整的 7.4 亿参数配置。

这种模块化很重要，因为“端侧运行”涵盖的硬件范围非常广。旗舰手机、较旧的笔记本电脑和嵌入式计算机拥有截然不同的内存限制。仅加载相关编码器，让开发者能够使模型适配自身产品。

该模型最多可接收 8,192 个文本和源代码 token。Google 表示，相同的输入预算最多可表示 29 张图像、58 帧视频或 5.5 分钟音频。混合输入共享这一总预算。

这些上限带来了实用的可能性，但并不会把模型变成无限容量的媒体档案库。长视频仍需采样或分段；大型文档库仍需建立索引。该模型让单个项目可被搜索，而周边应用仍必须管理内容导入与检索。

输出向量可存储为 768、512、256 或 128 维。这采用了 Matryoshka Representation Learning，一种能够在向量逐步缩短的前缀中保留有效信息的训练方法。

Google 表示，将向量从 768 维缩短至 128 维，最多可将向量存储需求降低六倍。其开发者文档称，较小的表示形式可保留完整模型的大部分质量，尽管结果取决于模态和工作负载。

这不仅是云端搜索的缩小版。模型权重采用 Apache 2.0 许可证提供，允许商业部署和修改。应用可在不将源材料发送给 Google 的情况下生成嵌入向量。

在开发者打包必要软件和权重后，该模型也能离线运行。这使其适用于私密照片库、现场设备、本地代码搜索，以及连接不稳定的媒体档案。

Google 表示，第一代 EmbeddingGemma 发布后下载量已超过 2,000 万。现有开发者基础为第二版提供了更顺畅的分发路径。已经使用本地文本嵌入的团队，无需采用无关的模型家族，即可评估新的媒体类型。

不过，升级并不只是替换模型。现有向量必须保持兼容或重新生成，检索阈值可能需要调整，媒体预处理也会带来新的存储需求。此次发布打开了更广阔的搜索范围，但开发者仍需围绕它构建索引工程。

为什么端侧检索会给云优先管线带来压力

EmbeddingGemma 2 所针对的不只是一次模型请求的成本，更是多模态搜索中大量活动部件的数量。

传统媒体搜索管线通常会先将每类输入转换为文本。语音会经过自动转录；图像会生成说明文字或进行光学字符识别；视频会被采样、添加说明并划分场景。随后，文本嵌入模型会为这些衍生描述建立索引。

这种方法确实有效，但每次转换都可能丢失语义。转录可能遗漏语气、环境音或不熟悉的人名；图像说明可能忽略后来变得重要的小物件；视频采样可能错过用户想找的时刻。

每一次转换也会增加一项运营依赖。团队必须选择模型、定义中间格式、处理故障，并监控多种延迟特征。私密媒体在变得可搜索之前，可能已跨越多个服务边界。

EmbeddingGemma 2 使用专用编码器，但这些编码器会进入同一兼容的表示空间。模型可以将原始音频查询与文本比较，或将文本描述与视觉内容比较，而无需先把每项输入都转化为说明文字。

这一设计从三个方面对云优先系统构成压力。第一是隐私。本地推理可让敏感材料留在用户或组织控制的硬件上。

第二是响应速度。本地索引无需等待网络传输和远程服务，即可响应搜索。当人们每天反复搜索个人文件时，这一优势尤其明显。

第三是架构。单一嵌入模型家族可减少不同模态之间适配器的数量，也能为多种内容类型提供统一的向量格式。

这并不意味着云基础设施会消失。许多产品仍会同步索引、集中处理大型集合，或在检索后使用远程生成式模型。本地嵌入改变的是第一阶段可以在哪里发生。

设想一个包含幻灯片、笔记、屏幕录制和音频的会议档案。传统系统可能会转录录音、提取幻灯片文字，并将结果发送给不同服务。EmbeddingGemma 2 则提供了一条可在用户电脑上为这些来源建立索引的路径。

例如，“客户留存率在入职引导后下降的那张图表”这样的查询，可以同时搜索视觉帧和文本。模型返回相关项目，而另一个应用则负责展示或总结它们。

同样的模式也适用于个人知识软件。当检索能覆盖截图、录音、文档和笔记，而不必先将所有内容压扁为文本时，个人知识库会变得更有用。

本地处理也改变了重复检索的经济性。云 API 会直接或间接地对处理、存储和流量收费。端侧系统则将这些成本转向下载体积、工程工作、本地计算和电池消耗。

两种方式都不必然更便宜。云服务可将基础设施管理分摊给众多客户；本地应用则必须支持多种处理器、操作系统和内存配置。

不过，EmbeddingGemma 2 为团队提供了另一种可信选择。处理私密或高频搜索内容的产品，可以让索引留在用户身边。云服务则必须通过更高质量、更易运营或更广泛的可扩展性来证明远程处理的价值。

Google 正通过其部署栈强化这一选项。该公司已向 Google AI Edge Gallery 添加 Instant Media Search 和 Video Moments Finder。这些应用展示的是本地检索，而不只是发布模型权重。

Google 还表示，EmbeddingGemma 2 将支持 ML Kit。计划中的集成会将该模型作为 Android 服务提供，并在兼容设备上利用神经处理单元加速。

MediaPipe 正在添加 Universal Embedder Task，用于处理图像缩放、归一化和多模态 token 化。其 Semantic Retriever Task 则加入了嵌入式向量搜索引擎，用于本地近似最近邻查询。

根据 Google 的边缘集成计划，该检索器可在个位数毫秒内返回排序后的匹配结果。这仍是公司报告的性能说法，而非对每一台设备或每个集合的保证。

配套软件的重要性或许不亚于基准分数。许多开放模型未能进入普通应用，是因为集成仍然困难。标准化的 Android 和跨平台接口可降低这一门槛。

如果这些接口能在多样化硬件上发挥作用，EmbeddingGemma 2 将不只是一个可下载的 checkpoint。它会成为面向私密搜索、路由和检索的应用平台的一部分。

共享空间是该模型的核心优势

该模型的主要机制是跨模态的语义兼容性，从而减少将每个查询和文档都转换为文本的需求。

EmbeddingGemma 2 建立在 Gemma 4 解码器架构之上。其文本组件充当双向编码器，这意味着它会在表示输入的每个部分时评估周围上下文。

视觉和音频塔会先处理各自的媒体，再通过共享模型投射信息。最终结果是一个归一化向量，可与其他受支持模态的向量进行比较。

这一机制之所以重要，是因为跨媒体匹配需要的不只是识别孤立的物体或词语。实用的向量空间必须将相关语义放在彼此相近的位置，即使它们的格式不同。

例如，对海浪的语音描述应能检索到相关音频和视频。对某项软件行为的自然语言描述应能检索到实现它的代码。包含图表的截图应能匹配关于该图表含义的问题。

CLIP 等传统多模态模型奠定了强大的图文检索能力。其他系统则将这一理念扩展至音频、视频或文档。EmbeddingGemma 2 试图以一个紧凑、开放权重的模型覆盖所有这些类别。

Google 还推出了一款面向云端的大型模型 Gemini Embedding 2。该模型覆盖文本、图像、视频、音频和混合输入，但其定位与 EmbeddingGemma 2 不同。

Gemini Embedding 2 面向高端托管式检索。EmbeddingGemma 2 则面向本地运行与模型所有权。它们展示的是同一家公司提供的两条路径，而非彼此的直接替代品。

这款云模型在多项基准测试中报告了更高的绝对成绩。其多模态嵌入论文显示，MTEB Code 得分为 84.0，多语言 MTEB 评测得分为 69.9。这些数字不应被视为直接的产品性能保证。

EmbeddingGemma 2 则更强调每个参数所带来的质量。Google 表示，其代码得分从第一代 EmbeddingGemma 的 68.76 上升至 78.68，在该公司的 MTEB Code 对比中提高了 9.92 分。

Google 还表示，这款新模型在选定的代码、视觉和音频基准测试中，领先于参数量不足十亿的多模态嵌入模型。当内存和网络访问限制较少时，更大的托管模型仍可能提供更高质量。

这一差异明确了核心竞争所在。EmbeddingGemma 2 无需在每项基准测试中击败所有云模型。它需要做到的是，让本地检索的表现足够好，使隐私、延迟和控制权的优势超过潜在的质量差距。

共享向量空间也简化了检索增强生成，即 RAG。在 RAG 中，系统会先找到相关源材料，再由生成模型组织答案。

本地 RAG 应用可以使用 EmbeddingGemma 2 检索截图、代码文件或录音片段。随后，它可以将选中的材料交给另一款设备端模型，例如 Gemma 4，来完成生成。

Google 表示，EmbeddingGemma 2 和 Gemma 4 共享文本分词器及音频编码器架构。复用这些组件可以降低设备端流水线的总体内存占用。

由此形成了明确的分工。EmbeddingGemma 2 负责寻找相关内容。生成模型则基于这些内容进行推理或生成回应。较小的检索模型可以高频运行，而无需为归档中的每一项都调用更大的模型。

该模型还支持零样本分类。应用无需训练单独的分类器，只需嵌入一个新输入，并将其与“账单问题”或“技术支持”等书面标签进行比较。

这使语音、图像和文本的本地意图路由成为可能。Google 在演示中描述了毫秒级路由，但生产环境中的性能会因硬件和标签数量而异。

可灵活调整的向量维度提供了另一项工程杠杆。128 维索引占用的空间更少，搜索速度也可能快于 768 维索引。更大的表示形式则可能保留小向量丢失的区分能力。

开发者可以根据工作负载选择这一权衡。个人照片库或许可以接受紧凑索引。专业技术档案则可能需要完整表示，以区分相似记录。

Google 的技术指南称，256 维向量可保留大部分文本和代码性能，并保留图像、视频和语音检索完整质量约 95% 的水平。这些汇总结果仍需在每个应用的数据上进行验证。

这一要求很容易被低估。搜索质量并不是一个单一数字。模型可能在广泛基准中表现良好，却错过定义某一特定产品的精确术语、视觉模式或口音。

共享空间降低了流水线复杂性，却将依赖集中于单一模型。如果模型误解了某个领域，所有模态都可能继承这一问题。因此，团队需要能反映其用户情况的评测集，而不应只依赖公开排行榜。

“口袋级”说法存在真实限制

能装入内存的模型，并不意味着它在每台设备上都会高效、准确，或已具备生产就绪条件。

Google 报告称，在 Pixel 11 Pro 上，量化后的 EmbeddingGemma 2 权重在纯文本检索时使用约 191MB 的活动内存。完整多模态配置则需要约 567MB。

这些数字使手机端部署成为可能，但它们描述的是特定设备和经过优化的配置。较旧的手机可能拥有更慢的处理器、更严格的散热限制，或是在操作系统和应用负载后剩余可用内存更少。

模型内存也只是整体占用的一部分。应用还需要为媒体预处理、向量索引、元数据和缓存结果预留空间。大型本地资料库可能使索引本身比模型更重要。

建立索引是另一项隐藏成本。内容被嵌入后，搜索结果可能很快出现，但创建这些嵌入需要计算资源。应用必须决定何时为新文件建立索引，以及如何避免耗尽电池电量。

视频带来了尤为困难的权衡。Google 的默认工具会以每秒一帧的频率采样视频，并将每个输入限制为 58 帧。这使计算量保持可控，但帧间的短暂事件可能会消失。

音频也有类似限制。5.5 分钟的最大长度不足以将长会议或播客作为单个项目处理。开发者必须将录音拆分为多个片段，并保留时间信息，使结果能指向有用的时刻。

分段决策会影响检索质量。过短的片段会丢失上下文。过长的片段则会混合无关主题，并可能模糊最终生成的向量。

统一模型在狭窄领域中也可能不如专用模型。医学影像、法律证据开示、工业声学和源代码安全都使用通用训练可能无法充分表示的模式。

对 EmbeddingGemma 2 进行微调的选项有所帮助，但微调会增加数据、评估和维护需求。组织还需要证据证明，适配能够改善其目标任务，同时不会损害更广泛的检索能力。

基准解读也带来另一项风险。Google 的领先结果比较的是规模相近的模型，并采用了选定的评测套件。“同等规模中最佳”并不意味着整体最佳，也不保证在私有数据上取得最佳结果。

模型卡和文档提供了比发布宣传更详细的信息，但已发布的性能证据大部分仍来自 Google。由于模型较新，跨手机、笔记本电脑和真实用户资料集的独立复现仍然有限。

早期社区测试已经说明了为什么本地评估至关重要。一名开发者报告称，在一个小型私有检索集上，与现有文本嵌入模型相比没有明显差异。该结果只是轶事，且范围有限，但它表明更高的公开基准分数并不保证带来可见的产品改进。

跨模态搜索还会引入难以解释的误报风险。系统可能通过宽泛的共享概念关联一段音频和一张图像，却错过用户真正意图中的具体关系。

应用需要置信度阈值、回退行为和清晰的结果预览。本地模型可以保护数据，却仍可能返回具有误导性的匹配结果。

隐私声明同样需要谨慎措辞。本地推理可防止内容被发送至嵌入 API，但周边应用仍可能同步文件、遥测数据或向量。

嵌入本身也可能泄露源材料的信息。开发者应将本地向量索引视为敏感数据，并通过适当的访问控制和加密加以保护。

许可证消除了另一项障碍，但并未消除所有治理问题。Apache 2.0 允许广泛的商业使用，但组织仍需对其应用、训练数据选择及个人媒体处理方式负责。

硬件碎片化可能成为最大的采用限制。Android 设备使用不同的神经加速器、驱动程序和内存配置。桌面端则涵盖 Apple silicon、x86 处理器、独立 GPU 和浏览器运行时。

MediaPipe 和 ML Kit 可以掩盖部分差异，但无法让每台设备都同样快速。团队将需要制定最低硬件要求，并为能力较弱的系统提供精简配置。

这一压力测试并不会抹去此次发布的重要性。它定义了 EmbeddingGemma 2 必须达到的实际标准：当本地搜索能够在常规功耗、内存和存储限制内表现得可靠时，该模型才算成功。

开发者如今必须选择搜索部署在哪里

EmbeddingGemma 2 将检索架构转化为关于控制权、质量和位置的产品决策。

计划构建多模态搜索的团队现在至少有三条广泛路径：使用多个专用模型，采用托管式统一嵌入服务，或在本地部署紧凑型统一模型。

专用流水线可让团队控制每个阶段。强大的转录服务可处理音频，专门的视觉模型则处理图像。代价是编排复杂度，以及各阶段之间信息丢失的风险。

托管式统一模型提供强大的通用性能和简洁的 API 访问。它们降低了本地硬件要求，但会将处理交由外部基础设施，并形成持续的服务依赖。

EmbeddingGemma 2 提供本地所有权和兼容的统一表示空间。其代价是较低的质量上限、更多设备测试，以及对整个索引生命周期的责任。

最佳选择取决于产品。具备集中治理机制的企业档案可能倾向于云端处理。私密的个人助手可能优先考虑本地推理。无法可靠联网的现场应用则有更充分的理由留在设备端。

混合设计很可能变得普遍。产品可以为高频搜索构建本地索引，再仅在查询需要更深层推理或更广泛数据时调用云模型。

这种模式可让日常检索保持快速响应，同时将远程计算留给困难场景。它也可以让用户选择特定资料集是否离开自己的设备。

EmbeddingGemma 2 的多模态搜索对已经掌控本地应用的软件开发者尤其相关。笔记工具、媒体管理器、代码编辑器、无障碍产品和移动助手都可以增加语义检索，而无需建立新的服务器端媒体流水线。

此次发布也给操作系统搜索带来压力。用户越来越期待一次查询即可覆盖文档、截图、对话、照片和录音。关键词索引无法可靠地连接所有这些格式。

Apple、Microsoft 和设备制造商已在本地智能领域投入资源。Google 的开放模型让独立开发者也能获得类似的架构构件，尽管平台所有者仍保有集成优势。

云嵌入供应商面临的是另一种压力。他们可以通过更高质量、更低延迟、更清晰的隐私控制或紧凑的可下载模型来回应。关键比较将从基准分数转向整体产品表现。

以下三个信号将显示 Google 的方法是否获得真正采用。

首先，开发者应关注 ML Kit 的发布及其支持的硬件。覆盖广泛、内存使用可预测的加速支持，将增强其用于生产级 Android 部署的理由。延期或设备覆盖范围狭窄则会削弱这一理由。

其次，独立检索评估需要测试私有代码库、照片库、嘈杂音频和长视频。若结果接近 Google 的声明，将证实这款紧凑模型能够顺利迁移到经过精选的基准测试之外。

第三，实际应用必须证明本地索引能够长期运行，同时不会带来不可接受的电池消耗或存储空间增长。展示型演示可以证明可行性，而持续使用才能揭示这一架构是否适合日常生活。

竞争对手的回应同样重要，但不应分散对这些信号的关注。一项新模型发布的意义，远不如其能否在数千台设备和多样化个人内容集合中实现可靠集成。

Google 已经提供了权重、文档、Sentence Transformers 支持以及边缘端演示。下一阶段将属于应用开发者、硬件厂商和独立评估机构。

EmbeddingGemma 2 并不会终结云端搜索。它让远程处理成为产品必须说明理由的选择，而不再是理所当然的默认方案。

对开发者而言，实际的下一步并不是迁移整个系统。应选择一个私密的混合媒体内容集合，并在多种向量尺寸下评估检索质量。在目标设备上测量索引时间、电池使用情况、内存占用和误匹配情况。将这些结果与现有的云端或专业处理流程进行比较。如果本地搜索在真实限制条件下仍能保持准确，就扩大测试范围；如果不能，则保留混合路径。关键问题已不再是多模态检索能否在设备上运行，而是 EmbeddingGemma 2 多模态搜索能否在不牺牲本地推理所具备的隐私性和响应速度的前提下，达到特定产品的质量门槛。