摘要：企业做RAG时有一个长期存在的偏差：知识库明明是多模态的，检索入口却被强行压成文本。PDF先OCR，PPT提取文字，设备照片生成Caption，视频转字幕，然后所有内容统一送进文本Embedding。这样做简单，也能解决不少问题，但代...
企业做RAG时有一个长期存在的偏差：知识库明明是多模态的，检索入口却被强行压成文本。PDF先OCR，PPT提取文字，设备照片生成Caption，视频转字幕，然后所有内容统一送进文本Embedding。这样做简单，也能解决不少问题，但代价同样明显。一张工艺流程图的空间关系、一张设备故障照片的纹理、一段操作视频的动作过程，在转换成文字时很容易丢失。
腾讯微信视觉团队8月26日前后开源的WeMM-Embedding，尝试解决的就是这一层问题。模型提供2B、4B、9B三个规模，统一支持文本、图像、视频、视觉文档以及交错多模态输入，并把这些内容映射到同一个向量空间。9B版本完整Embedding维度为4096，代码以Apache 2.0许可开放。当前暂不支持音频，这一点官方README写得很清楚。
Embedding模型看起来没有大语言模型那么吸引眼球，却是搜索、推荐和RAG真正的底座。生成模型负责“最后怎么回答”，Embedding负责“先把什么材料找出来”。如果第一步检索漏掉了正确证据，后面再强的LLM也只能在错误上下文上推理。
多模态Embedding究竟统一了什么
传统文本Embedding把一句话编码成一个向量。语义相近的句子在向量空间里距离更近，因此可以用近似最近邻搜索快速找相关文档。多模态Embedding把这个逻辑扩展到不同媒体：一张图片、一段视频、一个PDF页面和一句自然语言查询，都能得到可比较的向量。
这让跨模态检索变得直接。例如用户输入“找出叶轮边缘出现类似气蚀剥落的历史案例”，检索系统不必先把每张维修照片描述成文字，而可以让文本Query直接和图片Embedding比较。反过来，工程师上传一张损伤照片，也可以直接检索相似图片、维修报告和相关视频。
WeMM的统一输入形式还包括“interleaved multimodal inputs”，也就是文字和图片、视频混合在同一输入里。企业知识往往不是纯媒体文件：一页PPT有标题、图表、标注和流程箭头；一份检修报告里夹着现场照片；一条聊天记录里可能包含文字说明和截图。多模态Embedding如果能把这种组合整体编码，RAG就不必先把内容拆得过碎。
WeMM为什么要做2B、4B、9B三档
Embedding模型也存在容量、延迟和成本权衡。2B版本适合高QPS服务或边缘部署，9B版本追求更高检索质量，4B居中。官方MMEB-v2结果中，WeMM-Embedding-2B、4B、9B平均分分别为77.9、79.2和80.6；在MMEB-v3的综合结果里分别为56.0、58.2和59.5。需要注意，这些成绩来自项目技术报告和官方评测流水线，属于团队自报结果，实际业务仍应使用自己的数据集验证。
模型的另一个实用设计是Matryoshka Embedding。9B模型虽然完整维度达到4096，但支持截取成64、128、256、512、1024、2048等更短维度，并重新L2归一化。2B模型官方报告称，在MMEB-v2中使用256维仍能保留完整维度图像和视频性能的98.7%。
这对向量数据库成本很重要。假设有1亿条向量，4096维FP32大约需要1.6TB原始向量存储，256维只有约100GB，差距巨大。生产系统还要考虑索引、备份和内存缓存，维度降低能显著减少成本。Matryoshka训练的目标就是让重要语义尽量集中在前面的维度，使企业能根据召回质量和存储预算选择截断长度。
多模态RAG最适合先从“视觉信息本来就很重要”的行业落地
工业场景是很典型的一类。设备知识不仅存在手册文字里，还存在CAD截图、P&ID、现场照片、显微图、红外图、质检图片和维修视频。如果知识库只做OCR，会把很多视觉模式完全抹掉。
质量检测也适合。工程师上传一张缺陷照片，可以检索过去相似缺陷、对应批次和处理记录。售后场景里，客户发一段设备异响或动作异常视频，系统可以寻找类似维修视频和说明文档。设计领域还可以用产品效果图或草图检索历史方案与零部件资料。
电商、媒体和企业文档同样明显。传统“图片搜图片”和“文字搜图片”通常分别维护两套模型和索引，多模态Embedding有机会统一检索层。这样做的价值不只在少一个模型，而是Query和Corpus能够自由跨模态：文字找视频、图片找文档、视频片段找文字说明，都基于同一个语义空间。
视觉文档比OCR文本更值得关注
WeMM把Visual Document单独列为支持类型，这一点对企业知识库很重要。PDF和PPT中的很多信息依赖布局。表格的行列关系、图注和图片位置、流程箭头、页眉与正文层级，仅做OCR会得到一串文字，却丢掉“谁和谁属于一组”的结构。
视觉文档Embedding可以直接把页面当成图像和文本的联合对象。检索“2025年二季度东区设备故障率对比”时，系统有机会直接命中包含对应图表的页面，而不是只依赖OCR能不能正确读出坐标轴和图例。
当然，这并不意味着OCR没有用了。更合理的企业RAG通常会同时保留结构化文本、页面图像和布局信息。Embedding负责候选召回，后续Reranker或多模态LLM再做细粒度判断。多模态Embedding扩展的是第一阶段召回能力，并不会替代整个文档解析链。
统一向量空间并不代表“所有媒体都同样好搜”
不同模态的信息密度和噪声差异很大。视频尤其麻烦。一段十分钟视频包含大量重复帧，真正相关动作可能只发生三秒。WeMM的官方评测使用固定的视频采样策略，实际生产系统仍要决定是整段编码、分镜切片还是按时间窗口生成多个Embedding。
图片也存在分辨率和裁剪问题。一张大型工程图如果缩到模型输入尺寸，细小文字和局部结构可能消失；如果切成几十块，又需要管理父子关系。多模态Embedding降低了“媒体类型不一致”的门槛，却没有消除数据预处理、Chunking和索引设计。
企业上线时仍应建立专用评测集。比如从真实用户问题里抽500条，标出正确文档、图片或视频片段，再比较文本Embedding、多模态Embedding以及不同维度、不同切片策略的Recall@K。官方Benchmark能帮助选型，不能代替自己的检索验收。
和Reranker、生成模型怎么配合
一个完整多模态RAG系统通常会采用“两阶段甚至三阶段检索”。第一阶段Embedding从百万级或亿级库中快速召回几十个候选；第二阶段用更昂贵的Cross-Encoder或多模态Reranker重新排序；第三阶段才把最相关的几项材料交给LLM/VLM生成答案。
WeMM主要解决第一阶段。它提供vLLM和SGLang部署示例，说明团队已经考虑在线服务。由于Embedding请求通常比生成模型短、QPS更高，企业需要重点测试批处理吞吐和向量生成成本，而不是只看单条延迟。
另外，统一Embedding空间有利于Agent工具化。一个企业智能体可以只有一个“search_knowledge”工具，传入文字、图片或视频，底层自动得到向量并查询同一个索引，不必为每种媒体暴露独立工具。这会让上层Agent的工具选择更简单。
Apache 2.0为什么对企业落地有实际意义
腾讯仓库明确说明其自有代码采用Apache 2.0。相比一些附带复杂商业限制的模型许可证，这种许可更容易进入企业产品。当然，模型权重和依赖组件仍应逐项核对相应许可，不能只看代码仓库根LICENSE就推断所有第三方资产都没有限制。
开源还带来另一个价值：企业可以自己部署Embedding服务，敏感文档、生产图片和内部视频不必上传公共API。对于工业、医疗、政务等数据边界严格的场景，本地向量化往往是基本要求。
WeMM-Embedding值得关注的地方，并不是“又一个Embedding榜单第一”。更深的变化是，RAG的知识入口正在从文本扩展成真正的多模态数据层。企业过去为了适配文本检索，把图片和视频强行翻译成文字；下一阶段，文字只是多种知识形态之一。谁能更完整地保留原始信息，谁的智能体就更有机会在复杂业务里找到正确证据。
参考资料
- Tencent / WeMM-Embedding GitHub
https://github.com/Tencent/WeMM-Embedding - Horizon Summary 2026-08-27
https://thysrael.github.io/Horizon/2026/08/27/summary-zh.html