本地搜索做小了，找到的东西会变差吗？

想找的东西，未必有合适的文件名#

假设你在做一款本地资料助手。用户记得一段视频里有人展示过产品，却不知道文件名，也记不清当时说了什么。他想直接输入“有人拿起蓝色包装盒”，找到对应片段。

如果系统只能搜文件名，这句话几乎没有用。如果先把所有视频转成文字，又可能漏掉没有被说出来的画面。

Google DeepMind 在 2026 年 10 月 6 日发布的 EmbeddingGemma 2，提供了另一种选择：把文字、图片、视频和音频转换成可以相互比较的表示。这里的“嵌入”可以理解为给内容做一份用于查找的数字索引。它负责找相近内容，不直接替用户回答问题。官方发布

我的判断是：这种模型值得进入本地搜索的候选名单，但验收不能停在“手机装得下”。还要看压缩之后漏掉了什么，以及找到的结果是否真的可用。

先问清楚，省的是哪一部分#

官方给出的完整模型规模是 7.4 亿参数，也允许只加载需要的输入模块。发布文章列举了 Pixel 11 Pro 上量化后的内存数据：纯文字权重约 191 MB，完整多模态模型约 567 MB。这是特定设备和配置下的数字，不能当成整款应用的内存上限。发布说明

产品还要保存原文件、索引和界面状态。如果后面接一个生成回答的模型，也有额外开销。模型能载入，与资料库能长期稳定运行，是两次不同的检查。

另一笔容易混淆的账是索引空间。模型卡说明，模型默认用 768 个数描述一份内容，也支持缩短到 512、256 或 128 个数。同样的数据类型下，从 768 缩到 128，向量本身只剩六分之一；原视频、文件信息和其他索引结构不会随之一起缩小。不能把这个比例写成“应用体积减少六倍”。

少存一些数字，结果会怎样？#

官方模型卡给出了同一模型、不同向量长度的评测。以下数据使用完整精度检查点，并非上面手机量化配置的实测。

向量长度	多语言文字 MTEB v2	多模态 MMEB v2 综合
768	61.36	59.01
256	60.41	56.24
128	57.89	45.65

这两列是各自评测的汇总分数，不是业务搜索准确率，也不应该横向比较哪类任务“更强”。值得注意的是：缩到 128 时，多模态综合分数下降明显。官方也提醒，128 维更适合纯文字用途，多模态场景需要单独验证。

模型卡还比较了前后两代：在 MTEB code v1 的代码任务上，EmbeddingGemma 2 为 78.68，上一代为 68.76，指标为任务平均的 NDCG@10。通俗地说，它关注前十个结果里，相关内容是否排得更靠前。这个提升不能推导出所有文档、图片和录音搜索都更好；公开表格也不足以核对每个对照的全部运行配置。

这些证据对选型的意义很具体：不要把最短的向量当成默认最划算的选项。 如果用户主要找图片和视频，省下的空间可能换来更多漏检。先保留完整长度作为对照，再尝试缩短，才知道交换是否值得。

用同一批问题，比较用户能否找到#

下面是我的产品验证建议，不是已经完成的实验。

我会先从明确获准使用的资料里，整理一组用户真实会问的问题，并由人标出相关文件或片段。既要有容易找到的内容，也要有外观相近、表述含糊、根本不存在答案的情况。

然后固定资料、问题和结果数量，只改向量长度。分开看文字找文字、文字找图片、文字找视频片段等任务，避免一个平均分掩盖某类内容失效。

除了看前几个结果里有没有目标，还应记录用户需要翻找多久、是否点开了错误文件，以及系统无结果时有没有说清楚。若最常用任务稳定，可以考虑缩短；若漏检集中在视频细节，先保留更完整的表示，或限制功能适用范围。

离线可用，还要补上三件小事#

首先，区分首次整理资料和之后的搜索。Google 的工程文章介绍了本地媒体索引和相似度检索流程，也展示了视频片段查找。搜索框反应快，不代表首次处理大量文件同样快。产品应让用户知道哪些文件已经处理完成，别把“还没整理到”显示成“没有相关内容”。工程说明

其次，结果要能回到原始证据。搜索视频时，最好直接跳到相应片段；搜索文档时，显示匹配的位置。相似度高只能说明值得查看，不能替代事实核查。权限检查和删除后的索引清理也不能省掉。

最后，测试不能只看程序有没有报错。模型卡提醒，某些精度设置或向量处理方式错误时，可能得到看似正常、实际质量下降的结果。产品验收应留一组固定问题做回归：每次升级模型、改变压缩方式或更换设备，都重新检查能否找到，而不是只确认服务能启动。

对前面的资料助手，我更愿意先把一个明确任务做好，例如在获准访问的视频库里找到目标片段，再扩大输入种类。少占一些空间很有价值，但用户最终在意的是：我记得的那样东西，今天还能不能找到。

来源与边界#

• 发布来源： Google DeepMind 的 Sahil Dua、Henrique Schechter Vera，《EmbeddingGemma 2: an open, lightweight multimodal embedding model》，2026 年 10 月 6 日。用于核对机构、版本、发布日期和特定手机上的量化内存口径。
• 评测与限制： Google DeepMind《EmbeddingGemma 2 model card》，页面更新于 2026 年 10 月 6 日 UTC，文档采用 CC BY 4.0。本文原创概括其完整精度评测表、前代代码检索对照和向量截短限制；未独立复现。表格不是量化手机测试，也不是不同模型在统一成本预算下的综合排名。
• 工程来源： Google AI Edge Team、Android ML Team，《Bring multimodal semantic search to the edge with EmbeddingGemma 2》，2026 年 10 月 6 日。提供本地索引与媒体检索案例；本文没有试用这些演示。该文提到最高八倍向量压缩，与模型卡 768→128 的六倍口径不一致，本文采用可核对的模型卡维度，不外推到整个数据库。
• 尚不能说明： 上述来源没有提供本文假设资料库的检索成功率、完整应用峰值内存、首次建索引耗时、耗电量或端到端成本。公开成绩也不能代替中文业务资料和目标设备测试。
• 本文判断： 资料助手场景、验收流程、权限与删除检查均为产品建议，不是个人已交付项目或 Google 已验证的业务收益。