企业知识库 AI 多模态检索落地：统一向量空间之后的存储账与召回边界

把这样一个场景放进任何一家有售后体系的制造企业都成立：知识库里躺着十几万张维修工单截图、几千小时客服通话录音，外加一批培训演示视频。团队把它们统统 OCR 成文本再塞进向量库，结果工程师搜「这个报警灯的闪烁频率」，返回的却是一段毫无关联的操作手册文字。

问题通常不在模型，而在入库方式。2026 年 10 月 6 日，Google DeepMind 发布 EmbeddingGemma 2，以 Apache 2.0 许可开源，基于 Gemma 4 架构，把文本、代码、图像、视频帧与音频映射到同一个向量空间。多模态检索第一次有了可私有化落地的开源选项。但从「能跑通」到「能上线」，中间隔着三笔必须自己算的账。

一、为什么企业知识库 AI 现在绕不开图像、视频帧和音频

检索需求从来不是纯文本的。下面三类场景在近两年的项目里出现得越来越密集：

• 产品手册与工单截图——设备型号、接线图、报警码往往只存在于扫描件和照片里，纯文字描述会丢掉图形结构。
• 会议与培训录像——白板推演、系统演示的关键信息在画面里，语音转录只能覆盖口头那部分。
• 客服通话录音——客户的语气、停顿与反复追问本身就是信号，转写成文字后这层信息被抹平。

统一向量空间的价值在于：同一个 query 向量可以同时命中一段文字、一张截图和一帧画面，不必先做一次有损的模态转换。这也是「先 OCR 再入库」在图表类文档上持续掉分的根本原因，第四条会展开。

二、统一向量空间的三笔账

按官方发布信息，全模态档参数量 740M，另有一档 270M 面向文本与代码，两档按需加载；统一空间为 768 维并支持维度裁剪。落到工程上，真正要算的是下面三笔账。

账目	单模态 RAG 的做法	统一空间后的变化	上线前要实测的量
索引存储	只存文本向量，条数与文档数同阶	图片与帧的向量条数由采样策略决定，容易失控	单文档平均产生多少条向量、索引体积增长倍数
冷启动延迟	常驻一个文本编码器	两档按需加载，首次请求要等权重换入内存	P95 首响应时间、模型驻留内存峰值
召回是否均匀	只比较文本对文本	三种模态在同一空间竞争，弱模态易被淹没	各模态 recall@10 及相互之间的落差

第一笔账最容易被低估。768 维听起来不大，但一段 30 分钟的视频按每秒一帧抽就是 1800 条向量，而同等信息量的文字稿可能只有 20 个 chunk。索引成本从文档级跳到帧级，维度裁剪必须和采样率一起定。体积涨上来之后，下一步才是压缩：站内什么规模才该换量化索引给过一个判断门槛，可以直接对照。

第二笔账是延迟。按需加载省内存，代价是冷启动。生产验收不要看平均延迟，要看 P95 首响应——用户第一次提问的那一刻，才是模型换入内存的那一刻。

第三笔账最隐蔽：模态之间是否被公平召回。文本向量在余弦相似度上容易占优，图片与音频常常排在后面。如果评测集只测文本 query，这个偏斜根本暴露不出来。

三、从单模态 RAG 迁移的四个工程决策

下面四条是「已经是 RAG、要不要上多模态」这一步特有的问题；如果你连基础检索链路都还没定，先看RAG 落地的 6 个工程决策，那一层是前置条件。

1. 分库还是混库。混库省一次跨库合并，但不同模态的向量在同一个图索引里互相竞争，弱模态会被挤掉；分库则要在应用层做结果融合与去重。多数团队的现实答案是「文本与图混库、音频单开一路」。
2. 重排器是否要跨模态。如果一级召回已经混合了三种模态，一个纯文本重排器会把图片结果判成噪声。要么换多模态重排，要么先按模态分组、再组内重排。
3. 帧抽取与采样率策略。固定间隔抽帧最省事也最浪费。更省的做法是先做镜头切换检测，只在画面变化处抽帧，并把关键帧时间戳回链到原视频位置。
4. 评测集怎么造。最容易糊弄也最致命。评测集必须按模态分层：文本找图、图找图、语音找文本都要有样本，否则测不出召回偏斜。

四、反面教训：先把图片 OCR 成文本再入库

这是最常见的省事做法，也是长期代价最大的一种。OCR 只保留字符，丢掉版面。一张采购审批流程图 OCR 之后变成一堆没有连线的方框文字，「谁审批谁」的层级关系全部消失。检索时你或许能找到那张图，却回答不了基于它的问题。

第二层损失在表格。合并单元格、跨页表头、单位符号在 OCR 里极易错位，金额或温度数字只要错一格，答案就整体失真。解析层本身的性能与成本取舍另有专篇，可参考解析层提速后的三笔账。

原生多模态嵌入恰好绕开这一步：图像直接编码成语义向量，版面结构以特征形式保留，再与文字段落在同一空间比对。但要强调，这不是「什么都别 OCR」。文字密集、结构规整的合同与通知，OCR 加文本检索依然更便宜；图像块占比高、以图表和示意图为主的手册与工单，才值得走原生多模态路径。

五、落到私有化交付：哪些环节必须留在本地

企业侧的约束通常不是技术，而是数据边界。按「必须本地」和「可以走托管」切一刀：

• 必须本地：嵌入模型推理、向量库、原始截图与录音文件。原始素材一旦离开内网，合规审查就过不去。
• 可以托管：重排与答案生成这类只接触已检索片段的环节，前提是片段本身不含敏感字段或已完成脱敏。
• 建议本地：评测流水线。评测集往往是真实工单与真实通话的采样，外发相当于把最敏感的样本送出去。

按这个切分，一套典型部署是：内网一台带 GPU 的服务器承担 740M 档嵌入与向量检索，重排与生成走托管接口，评测集留在本地只输出汇总指标。这条路径管的是模型权重与推理位置，跟「数据是否需要跨域搬运」是两套验收口径——后者可参考「数据不出域」怎么被证明，两者互补而不重叠。

常见问题

统一向量空间和「每个模态各自建索引」哪个更划算？

取决于跨模态检索在业务里的占比。如果八成查询仍是文本找文本，各自建索引更省资源；一旦出现「用一段描述找图」「用一句话找某段录音」这类需求，统一空间的收益会迅速超过维护成本。

768 维会不会不够用，需要更高维度吗？

维度不是越高越好。它主要影响索引体积与召回上限，而多模态场景的瓶颈通常先出现在采样率和评测集上。先解决帧级存储与召回偏斜，再考虑维度。

多模态嵌入模型能完全私有化部署吗？

开源权重意味着可以，但要区分「权重可下载」与「效果可复现」。私有化部署后需要自建评测集验证，否则你在内网拿到的分数无法与厂商公布的基准对齐。

从单模态 RAG 迁移，最容易翻车的是哪一步？

评测集。多数团队把旧的文本评测集直接复用，结果测不出模态间的召回落差，上线后才发现图片结果长期排在末位。

如果你正在评估把现有检索系统升级到多模态，可以先看我们的私有化交付案例，或把素材形态与检索目标发给我们，我们按你的模态分布给一份存储与延迟预算。

参考

• AIHOT · 2026-10-07 精选：Google DeepMind 发布开源轻量多模态嵌入模型 EmbeddingGemma 2