资料明明存过却找不到，Google给了新办法

摘要：EmbeddingGemma 2把文字、图片、录音和视频放进同一套检索空间，让人有机会凭内容找资料。它可以在本地运行，但要成为好用的知识库，还需要切片、索引和结果定位。理解这些环节，才能判断这次更新对自己有什么用。

电脑里最难找的资料，常常是你确信自己保存过的那份。记得某次会议讨论了退款规则，却忘了是哪天；记得一张截图里有深色侧栏，却想不起文件名。搜索框需要一个明确的词，人脑留下的却可能只有一个场景、一段意思，或者模糊的画面。

2026年10月6日，Google发布了EmbeddingGemma 2。这次更新值得关注，是因为它把几种原本分散的资料放到了一起：文字、代码、图片、音频和视频，都能转换为可以相互比较的向量。于是，文字描述有机会找到图片，问题有机会匹配录音片段，搜索不必总从文件名开始。

这件事离日常需求很近。我们已经有太多工具帮助保存内容，网页可以收藏，会议可以录音，视频可以下载，聊天记录也能导出。积累越来越容易，重新找到其中有用的部分却没有同步变容易。EmbeddingGemma 2提供的是一块检索组件，开发者还需要把它接进具体应用；普通用户也可以据此看懂，下一代本地搜索可能改在哪里。

搜索开始理解意思，但它还不会替你写答案

Embedding，也就是嵌入，可以理解为把一份内容转换成一串数字。这串数字用于表示内容的某些特征，检索系统再比较数字之间的距离，找出可能相关的材料。这里的向量不是文件的压缩包：拿到它，不能完整还原原来的文章、照片或录音。

假设你的笔记里写着“乘客取消订单后，款项会按原支付渠道退回”，而你搜索“钱怎么退到银行卡”。两句话没有多少相同的字，关键词搜索可能漏掉它们；语义检索则尝试根据含义，把它们放在较近的位置。这是一个说明机制的例子，具体能否匹配，还取决于模型、资料和检索设置。

EmbeddingGemma 2更进一步，让不同形式的输入也能进入同一个空间。图片可以有图片向量，录音可以有音频向量，文字问题也有自己的向量。系统因此可以尝试跨形式匹配，而不必先要求所有资料都变成文字。统一空间解决了“能否比较”的问题，并不保证任何一句描述都能准确找到目标。

也要分清它与聊天模型的工作。嵌入模型返回向量，检索程序返回相关资料；如果你还希望得到一段有组织的回答，需要再接入能够生成文本的模型。常说的RAG，即检索增强生成，就是先找材料，再让生成模型依据材料回答。找得准与答得好，是两道分别需要检查的关口。

这层分工对用户也有意义。一个知识库能写出流畅的总结，不代表它找到了正确文件。比起先欣赏答案的语气，更值得检查的是它引用了哪份资料、哪一页、哪一段录音。检索结果能回到原文，才便于核实，也便于继续工作。

把四种资料放在一起，会改变哪些使用方式

对图片，最直接的需求是凭描述找图。比如从设计参考中找“左侧是导航、右侧是大图的深色页面”，或者从产品照片中找某类外观。文件名未必含有这些信息，图像内容却可能提供线索。把图片和文字放进同一套检索空间，能够为这类搜索提供技术基础。

扫描件则需要更细的处理。寻找“讲交付流程的那一页”，可以同时利用页面图像和识别出的文字；查找某个精确发票号码，仍应保留OCR文字和精确匹配。语义相近并不能代替号码一致。对于表格、密集小字或细节差异，实际资料上的表现比一句“支持图片”更有参考价值。

对录音，难点通常是定位。一个小时的会议里，真正需要的也许是两分钟的决定。如果应用把音频拆成片段，保留会议名称、参与者和起止时间，文字查询就有机会返回对应片段。听完那一段，再决定是否引用，比只得到一个会议文件名有用得多。识别专业术语、嘈杂环境和多人重叠说话的能力，仍需要用自己的录音验证。

视频也有类似需求：找到某个演示步骤、某段操作过程，或者出现某类画面的时刻。不过视频涉及画面抽样与时间定位；一闪而过的细节，可能没有被抽到。检索应用需要明确处理帧、音轨和切片，不能看到模型支持视频，就认为长片里的每个瞬间都已经被理解。

对于代码，使用者往往知道想完成什么，却不知道函数叫什么。自然语言查询可以辅助寻找实现位置，再结合文件路径、符号名和项目版本缩小范围。它适合帮助发现入口；是否真的实现了某项逻辑，仍要阅读代码。一个含义相近的函数，可能恰好用了不同的权限条件或边界处理。

这些场景有一个共同要求：找到之后，要能打开。图片应返回原文件，笔记应返回页面，录音和视频应返回时间点，代码应返回文件位置。只有相似度分数，没有来源和定位信息，使用者仍然要再找一遍。

模型也允许将文字和媒体组合成一个输入。例如，一份产品资料可以同时包含说明和照片，用共同的向量表示这份材料。这适合搜索“防水的户外鞋”之类既涉及文字属性、也涉及外观的对象。不过，把许多主题不同的图片和说明全部混成一条记录，会让结果难以解释。资料在业务上属于同一个对象，才有理由组合；组合并不意味着不再需要细分。

跨模态还需要关心查询方向。用文字找图片，与用图片找相似图片，检索目的可能不同；从一段录音找相关笔记，也不等于查出了逐字相同的句子。建立应用时，可以先锁定一个最常见的方向，例如文字找会议片段，明确什么样的结果算成功，再扩展到其他方向。范围越清楚，越容易知道改进来自哪里。

7.4亿参数，实际要加载多少取决于资料类型

根据官方模型卡，EmbeddingGemma 2基于Gemma 4架构，完整模型约7.4亿参数，默认输出768维向量，并以Apache 2.0许可开放。它的一个实用设计，是可以按需要省去视觉或音频编码器。

这使部署选择更贴近实际需求。一个只搜索Markdown笔记的项目，不必为了未来可能处理视频，先把所有编码器加载进内存。日后加入图片或录音，再调整配置、建立相应索引，通常更容易控制资源消耗。

“轻量”仍然是相对的。参数数量不能直接等同于应用的总内存；推理框架、数据预处理、批量大小以及索引都会占用空间。同一模型在不同精度、硬件和运行工具下，也可能有不同的速度与内存表现。判断一台电脑是否合适，应看实际工作量，而不是只看模型文件能否下载。

模型还支持128、256、512和768维的输出选择。这来自MRL，也就是套娃表示学习：向量前面的部分经过专门训练，也能用于检索。降低维度可以减少向量存储，但需要按照模型要求处理并重新归一化，不能随手删掉任意一段数字。

只计算向量本身，假设有10万条记录，都用32位浮点数保存，768维大约需要307.2MB，128维大约51.2MB，前者是后者的六倍。这是维度乘以记录数的结果，不包含索引结构、元数据和原文件；它也不表示整个知识库会缩小六倍。较低维度是否值得，要看节省的空间能否抵得上具体任务里的检索损失。

查询向量和资料向量必须使用一致的模型与维度。今天用768维建库，明天把查询换成128维，并不是一次可以直接兼容的小改动。升级模型版本也应重新检查索引，不能把旧模型生成的向量与新模型向量混在一起比较。

维度也不是唯一的速度开关。资料规模很小时，直接计算相似度就能完成演示；记录增多后，还需要选择索引方法、调整批量和检索候选数量。原始媒体的解码可能占用时间，首次加载模型也与后续查询不同。评估时，应分别记录建库耗时、查询耗时与内存峰值，避免把一次冷启动的等待当成每次搜索都要付出的成本。

本地知识库真正需要的是一条完整的检索链

模型下载到电脑之后，知识库不会自动出现。首先要确定资料从哪里来，如何解析，如何切成能够检索的小块。接着为这些块生成向量，保存向量与原始位置的对应关系。用户提问时，再生成查询向量，检索相关内容，并把结果交给界面或生成模型。

切片方式会影响结果。一整本手册只生成一个向量，多个主题可能混在一起；每句话各生成一个向量，又可能丢失上下文。更合理的起点，是沿章节、段落或业务规则切分，同时保留标题和必要的相邻信息。合同里的例外条件、操作手册中的前置步骤，不适合为了让片段短一点而被拆开。

每块资料还应保存文件路径、文档标题、页码或时间戳、更新时间等信息。检索到“退款规则”时，使用者需要知道这是当前规则，还是一年前留下的版本。向量表达内容关系，版本和权限需要应用额外管理。在多人知识库中，结果展示之前也应按用户可见范围过滤，不能让相似度决定谁有资格看资料。

长媒体尤其需要规划。EmbeddingGemma 2的文字、图片、音频和视频共享8192 token的输入预算。按默认音频开销计算，只输入音频时大约可容纳327秒；加入文字或其他媒体后，可用空间会减少。因此，一场长会议需要拆分，不能把整段音频无限塞进一次调用。视频同样受预算和抽帧设置限制。

切片可以保留一点重叠，减少关键内容恰好落在边界两侧的情况；结果也可以带回附近上下文，让人听懂完整意思。这里没有适合所有资料的固定秒数。讲课、访谈、产品演示的节奏不同，片段长度应服务于要找什么，以及找出来后准备怎样使用。

向量检索与关键词检索也可以配合。搜索某个报错代码、订单号或文件名时，精确匹配很重要；记得含义却不记得用词时，语义检索更有帮助。先检索候选，再依据日期、项目或资料类型筛选，比要求一个相似度分数独自处理所有问题更稳妥。

知识库还会变化。新增文档应进入索引，修改过的片段应重新编码，删除资料后也应清理相应记录，否则搜索结果可能仍指向不存在或过时的内容。可以把内容哈希与更新时间保存下来，只更新发生变化的部分。全量重建并非每次都必要，但换模型、改切片规则或改变向量维度时，要明确哪些旧记录需要迁移。

可以先用几条文字跑通，再决定要不要扩展

Google提供了Sentence Transformers使用指南，模型文件位于Hugging Face项目页。准备尝试时，可以先做一个仅处理文字的小例子，确认输入、向量和结果之间的关系，再接入大量文件。

不想先写代码，也有体验入口。Google在AI Edge的介绍中公布了Gallery里的即时媒体搜索和视频时刻查找演示；社区还有WebGPU浏览器演示。可以先用演示了解交互，再判断是否需要自己部署。演示的支持设备、资料导入方式和模型下载要求应以页面为准，它们不等于已经接管了电脑里全部文件的通用搜索软件。

先安装指南使用的两个依赖：

pipinstall-Usentence-transformers transformers

下面这个例子用CPU和float32，只加载文字部分；资料内容是为说明检索步骤准备的三条示例。首次运行需要下载模型，后续本地运行所需的文件与依赖应提前准备完整。

importtorchfromsentence_transformersimportSentenceTransformer model=SentenceTransformer("google/embeddinggemma-2",device="cpu",model_kwargs={"torch_dtype":torch.float32},config_kwargs={"vision_config":None,"audio_config":None},)

模型加载完成后，再准备待检索资料和搜索问题。以下代码与前一段在同一程序中顺序运行：

docs=["取消订单后，退款按原支付渠道退回。","修改头像后，需要刷新页面查看。","发票可以在订单详情页下载。",]vectors=model.encode(docs,prompt_name="Retrieval-document",normalize_embeddings=True,)query=model.encode(["取消购买以后钱退到哪里"],prompt_name="Retrieval-query",normalize_embeddings=True,)scores=query @ vectors.Tforiinscores[0].argsort()[::-1]:print(round(float(scores[0,i]),3),docs[i])

这里的两个任务提示分别告诉模型：哪些是待检索资料，哪个是搜索问题。归一化后用向量点积进行排序，能把最相关的候选放到前面。加入真实文档时，可以按官方格式提供文档标题；标题往往包含章节主题，省略它可能损失有用线索。

还有一个容易忽略的精度要求：官方明确要求使用bfloat16或float32，避免float16。这个模型的激活范围可能超出float16能表达的范围，导致NaN或质量下降。bfloat16与float16虽然名称接近，并不能在这里随意互换。先让结果稳定，再考虑量化、批量和速度优化，会少走很多弯路。

三条资料的例子只解释步骤，无法证明复杂知识库的质量。真正评估时，可以从自己的资料中准备几十个问题，标注希望找到的文件或片段，看看正确结果是否进入前几名。还应加入“资料里没有答案”的问题。如果系统对每个问题都硬找一份内容，后续生成模型就容易拿无关材料继续编出答案。

一个实用的评估办法，是保留同一组问题，对比现有关键词搜索、完整维度检索和较低维度检索。不要只挑“退钱”与“退款”这类容易成功的问题，也要加入专业简称、相似版本、否定条件和模糊画面描述。记录前三条或前五条结果中有没有目标材料，再检查定位是否准确。这样能看出模型改善了哪些需求，哪些问题仍要靠资料整理解决。

相似度也不能直接读成正确率。分数为0.8，不代表答案有80%的概率正确；不同资料、任务提示和模型会形成不同的分数分布。拒绝低质量结果的阈值，应依据真实问题和无答案样本调整，而不是从教程里抄一个数字。必要时可以增加重排步骤，对已经找出的少量候选再做更细的相关性判断；这会增加计算，也应确认收益是否足够。

新模型最有价值的地方，是让保存过的内容重新可用

我更看重EmbeddingGemma 2带来的使用空间，而不是单独某个参数或榜单位置。对拥有大量图片参考、录音和视频素材的人，把几种资料放进一套检索流程，可能减少反复切换工具的麻烦。对只有少量文字笔记的人，现有搜索也许已经够用，换模型的收益未必能覆盖重新建库与维护的工作。

本地运行则提供了另一种选择。资料可以在设备上编码和检索，网络不好时也有机会继续使用，开发者也能控制何时更新索引。但“本地嵌入”不等于整条链都在本地：如果最后仍把找到的段落发送给云端聊天模型，那部分资料依然会离开设备。选择应用时，要看完整的数据流。

也别把相似度当成事实保证。关于某种药物的旧笔记，可能比新指南更贴近问题的措辞；“允许退款”和“不允许退款”都在谈退款。一个好用的搜索结果，需要内容相关，也需要版本正确、条件完整、来源明确。模型改善了候选发现，核实仍要回到材料本身。

这次更新给人的期待很具体：当你只记得资料讲了什么、长什么样、出现过什么声音时，也能有一个寻找入口。它离完整产品还有索引、界面和质量评估等工作，但方向值得关注。毕竟，保存一千份资料之后，最让人安心的能力，是需要时能把其中那一份找回来。

#多模态AI# #本地AI# #知识库#