EmbeddingGemma 2 怎样跨文字、代码和视频搜索？

想在手机里找一段视频，过去通常要先把画面或声音转换成文字，再交给另一种模型检索。Google 发布的 EmbeddingGemma 2 试着把这条流程缩短：让文字、代码和多种媒体进入同一套搜索表示。在 Google 展示的本地视频搜索中，用户输入“狗接住飞盘”，设备就能从自己的视频里找出相关画面，不必先生成字幕。

原始来源：Introducing EmbeddingGemma 2: An open model for natively multimodal embeddings。中文深度整理，非逐字翻译。本文依据发布方 Google Developers Blog 的详细官方说明整理，没有把不可播放的 YouTube 音频或未核验字幕当作依据。

发布方页面：EmbeddingGemma 2: The Developer Guide；Bring multimodal semantic search to the edge with EmbeddingGemma 2。

搜索视频画面，不一定要先转录声音

EmbeddingGemma 2 属于“嵌入模型”：它把输入变成一组数字，也就是向量，供搜索系统比较内容是否相近。普通文字搜索要靠词语匹配；向量搜索更关注输入和资料表达的意思是否相似。

Google 给出的本地演示是：手机先把视频的关键画面连同音频片段编入索引，之后用户描述想找的内容，系统再把搜索词和已存画面表示作比较。比如，搜“孩子在笑”或“狗接住飞盘”，程序会挑出相近的片段。这个例子不代表模型会替视频写摘要：它要做的是找到可能相关的位置，用户仍需查看结果是否符合自己的意思。

图片搜索也是同一种思路。在 Google AI Edge Gallery 的演示中，用户可以用一句自然语言找本地照片，也可以选一张图片作为查询。随着搜索词补充细节，结果会按相似度重新排序。资料保存在本机，演示中的计算也不需要联网；这适合做本地媒体搜索，但不等于所有使用该模型的应用都天然具备相同的隐私设置。

同一个搜索空间，模型大小可以按任务选择

“多模态”指模型能处理不同种类的资料。EmbeddingGemma 2 把文字、代码、图片、视频和声音映射到同一个 768 维空间；在这个空间里，来自不同种类输入的向量可以拿来比较。Google 的开发指南称，系统采用可拆分的编码器：只处理文字和代码时是 270M 参数，增加图片处理后是 440M，文字加音频是 570M，启用全部模态则是 740M。

这个设计让开发者不必在每台设备上加载完整模型。不过，参数量小并不自动保证任意设备都运行得快，实际占用还取决于所选编码器、硬件和具体工作流程。Google 也提供了 sentence-transformers 用法：开发者可以关掉暂时用不到的视觉或音频模块，并用同一模型处理多种输入。

另一项设计是“嵌套向量”训练：开发者可以把向量从 768 维缩短到 128 维，减少向量数据库需要保存的数据。Google 的评测指出，在 256 维时，文字和代码检索保留了大部分原有表现；图片、视频和语音检索则约保留 95%。这是发布方给出的特定评测结果，不是对所有数据集、设备和搜索任务的保证。

它负责找线索，不负责替人作出解释

EmbeddingGemma 2 是检索模型，不是用来生成完整回答或解释视频内容的聊天模型。它可以把查询和媒体放到一起比较，却不会因此自动知道用户说的“比赛关键一球”具体指哪一次赛事，也无法只靠一个分数判断画面是否真的满足需求。开发者仍要决定怎样切分视频、保存哪些画面、如何展示搜索结果，并让用户核对命中内容。

Google 将这个模型作为开放权重模型发布，并提供面向服务器端的开发指南；Google AI Edge 还展示了在手机和 Mac 上试用的本地搜索体验。官方还说，计划在接下来几周将模型接入 Android 的 ML Kit。这些路径覆盖了实验和集成，但不同平台的可用性及速度仍需要按实际设备核实。

对开发者来说，这次发布最值得检验的问题很具体：少掉字幕和多模型串联后，搜图片、声音和视频的成本能否下降，同时仍让用户快速找到真正想看的内容？这要看实际检索效果，而不是模型能处理几种媒体或向量有多少维。