微信开源 WeMM-Embedding：把文本、图片和视频放进同一个向量空间

9月4日，微信 AI 官方宣布开源通用多模态嵌入模型 WeMM-Embedding。它不是一个用来聊天或生成内容的模型，而是负责把文本、图像、视频、视觉文档等内容编码成可比较的向量，服务于搜索、推荐、分类和跨模态匹配。

**WeMM-Embedding 是一组能够将文本、图像、视频、视觉文档以及交错多模态输入映射到统一向量空间的 Embedding 模型。**此次开源包含 2B、4B、9B 三个参数规模，微信方面称，这套模型已经大规模部署在视频号、直播、公众号、电商和朋友圈等业务中，每日调用量达到 10 亿量级。

从产品热度看，Embedding 模型通常没有聊天模型那么容易被用户感知；但从 AI 系统的底层架构看，它往往更接近搜索和推荐的“地基”。用户输入一句话，系统能否召回相关视频；用户上传一张图片，系统能否找到语义相近的文章；一个账号的历史行为能否与内容理解结果对齐，背后都离不开高质量的向量表示。

9B 登顶 MMEB-v2，2B 击败此前 8B 开源模型

WeMM-Embedding 的公开成绩，是这次发布中最值得关注的部分。官方信息显示，WeMM-Embedding-9B 在多模态嵌入评测 MMEB-v2 上取得 80.6 分，位列榜单第一；2B 版本得分 77.9，超过此前领先的 8B 开源模型；4B 版本得分 79.2。

**MMEB-v2 是用于评估多模态嵌入模型在图像、视频、视觉文档和跨模态检索等任务上表现的公开基准。**与只测试文本相似度的传统 Embedding 评测相比，MMEB-v2 更接近真实内容平台的工作负载：查询可能是文字，候选内容可能是图片、视频或文档，模型需要判断两者是否语义相关。

| 模型 | 参数规模 | MMEB-v2 总分 | 主要特点 | |---|---:|---:|---| | WeMM-Embedding-2B | 2B | 77.9 | 计算成本较低，超过此前领先的 8B 开源模型 | | WeMM-Embedding-4B | 4B | 79.2 | 在性能和部署成本之间取得平衡 | | WeMM-Embedding-9B | 9B | 80.6 | MMEB-v2 榜单第一，适合对效果要求更高的场景 |

补充评测结果显示，在 MMEB-v3 上，WeMM-Embedding-9B 得分 59.5，同样位列第一；2B 和 4B 分别为 56.0 和 58.2。不过，MMEB-v3 当前包含音频相关任务，而 WeMM-Embedding 暂不支持音频输入，相关任务按 0 分计入。因此，v3 的成绩需要结合任务覆盖范围理解，不能简单与支持音频的模型横向比较。

这组成绩有两个实际意义。第一，2B 版本的效果并不是传统意义上“大模型缩水版”：在嵌入任务上，更重要的是训练数据、任务设计、负样本构造和对齐方式，而不只是参数量。第二，9B 版本虽然部署成本更高，但它在图像、视频和跨模态检索上的综合能力，已经具备作为大规模内容平台基础模型的竞争力。

原生多模态骨干，而不是多个编码器拼接

WeMM-Embedding 选择基于 Qwen3.5 多模态架构构建统一骨干。原生多模态架构是指文本和视觉内容从输入阶段起就由同一个多模态模型共同建模，而不是先由不同编码器分别处理，再在后端强行拼接向量。

这一区别看起来像工程实现，实际会直接影响跨模态理解效果。

传统的多模态检索系统经常采用“双塔”或多塔方案：文本由一个文本编码器处理，图像由视觉编码器处理，视频再单独抽帧并编码。优点是结构清晰、检索速度快，但不同模态之间的语义对齐通常依赖额外训练。遇到“带字幕的视频”“图文混排文章”“图片中的表格与正文共同表达一个意思”等场景，多个独立编码器容易丢失上下文关系。

WeMM-Embedding 的输入可以由任务指令和多个有序的多模态片段组成，文本、图片、视频以及视觉文档按照原始顺序进入同一条序列。这样一来，模型看到的不只是“这张图像是什么”，还可以理解“这张图像出现在这段文字之后意味着什么”。

举个更接近业务的例子：一条视频可能包含画面、标题、字幕、ASR 转写文本和评论摘要。旧式系统需要分别为这些内容生成表示，再通过规则或额外模型融合；统一多模态模型则可以把视频画面和文字描述作为有顺序的输入，直接得到“视频本身”或“视频加上下文”的联合表示。

一个 embedding 标记，同时提取多种表示

WeMM-Embedding 的核心输出机制相对直接：模型在输入序列末尾加入专用的 <embedding> 标记，取该标记对应的最后一层隐藏状态，再进行 L2 归一化，得到最终向量。

**L2 归一化是将向量长度统一为 1 的处理方式，能够让后续相似度计算更关注方向而不是绝对长度。**在向量数据库中，这通常有利于使用余弦相似度进行检索和排序。

它还有一个对工程系统很有价值的设计：一次输入可以放置多个 <embedding> 标记。比如在视频片段之后放一个标记，在完整的视频加文本序列末尾再放一个标记，模型一次前向计算就能同时产出两种表示：一种只代表视频内容，另一种代表视频与文字上下文的联合语义。

这比为同一条内容重复运行模型更节省计算。对内容平台而言，视频原始表示、视频标题表示、视频加 ASR 表示可能分别用于召回、排序和用户兴趣建模。如果每种表示都要单独推理，线上成本会快速增加；多标记输出可以在一定程度上减少重复计算。

Matryoshka Embeddings：向量维度可以按场景裁剪

**Matryoshka Embeddings 是一种支持可变输出维度的嵌入方式，模型训练时让完整向量的前缀部分也具备独立的语义表达能力。**这意味着同一个模型不一定只能输出固定长度的向量，开发者可以根据存储和检索成本选择不同维度。

参考资料显示，WeMM-Embedding-2B 支持从 64 维到 2048 维的输出，9B 版本最高支持 4096 维。4B 版本同样提供可变维度配置，具体上限应以模型仓库中的配置和说明为准。

可变维度的意义在于，向量检索系统不必在“效果最好”和“成本最低”之间二选一。以 100 亿条内容为例，4096 维向量带来的存储、内存和索引压力会明显高于 512 维或 1024 维向量。在首轮粗召回阶段，可以使用较低维度快速筛选候选；在更严格的重排或高价值内容场景，再使用更高维度表示。

当然，Matryoshka 并不意味着维度越低效果完全不变。维度裁剪后，细粒度语义区分能力通常会下降，最终需要结合业务数据测试召回率、延迟、索引大小和显存占用。它提供的是部署空间，而不是免费的性能提升。

微信为什么要把这类“隐形模型”开源

微信方面称，WeMM-Embedding 已用于推荐与搜索系统的多个环节，包括候选检索、排序特征构建、用户序列建模和跨域内容理解。

**候选检索是从海量内容中快速找出一批可能相关对象的阶段，通常依赖向量相似度而不是逐条阅读全部内容。**在微信这样的内容和社交平台中，搜索“某个主题”时，候选可能来自公众号文章、视频号视频、直播内容、电商商品和朋友圈内容。统一向量空间能让这些内容具备跨域比较的基础。

官方披露，在微信内部 26 项任务基准上，WeMM-Embedding-2B 相比同规模基线将平均成绩从 60.9 提升至 72.0，提升 11.1 分，覆盖分类、搜索、跨域匹配、文章相关和视频相关五类任务。参考资料还提到，该模型已经通过 14 项线上 A/B 测试并持续带来改进，随后进入生产环境。

这些数据不能直接等同于所有业务指标提升 11.1 分，也不能推导出用户端点击率会按相同比例增长。内部基准衡量的是模型任务能力，线上 A/B 测试则要看召回率、点击率、停留时长、转化率、延迟和资源成本等具体指标。微信没有在公开资料中披露完整的线上绝对增幅，但能够在多个业务域完成大规模部署，本身说明该模型不只是论文里的离线实验。

从开源策略看，微信释放的重点并不是再造一个聊天机器人，而是把内容平台长期积累的多模态检索经验，转化为社区可以复用的基础组件。对开发者来说，搜索、RAG、内容审核、相似内容发现、商品匹配和用户兴趣建模，都可能直接受益。

对开发者意味着什么

WeMM-Embedding 更适合以下几类场景：

1. 跨模态搜索：用文字搜索图片、视频或视觉文档，也可以用图片寻找相似文章和商品。
2. 多模态 RAG：将 PDF 页面、截图、表格、图片和文本统一建立索引，检索阶段不再被单一文本格式限制。
3. 视频内容理解：同时利用画面、标题、字幕和 ASR 文本生成内容表示，适合视频召回与相似视频发现。
4. 跨域推荐：将公众号文章、视频号内容、电商商品等放进同一个向量空间，辅助构建跨内容形态的用户兴趣画像。
5. 视觉文档检索：处理扫描件、图表、表格和图文混排页面，而不是只读取 OCR 后的纯文本。

但它也不是拿来就能替代完整搜索系统。Embedding 模型负责把内容变成向量，真正上线还需要解决数据切分、向量索引、召回数量、元数据过滤、权限控制、去重、重排和新鲜度等问题。尤其在微信式场景中，内容权限和社交关系过滤不能交给向量相似度处理。

部署成本同样需要现实评估。2B 版本更适合资源有限的团队或大规模离线向量化任务；4B 版本是更均衡的选择；9B 版本适合对复杂跨模态关系和检索质量要求更高的场景。视频输入还涉及抽帧策略、帧数、分辨率和时序信息，显存与延迟不会只由参数规模决定。

官方仓库建议使用与项目匹配的 Transformers 版本，以确保预处理行为一致。实际使用时，应优先按照 GitHub 仓库中的模型配置、输入格式和评测脚本进行验证，而不是把它当成普通文本 Embedding 模型直接接入现有流水线。

还不能忽略的限制

第一，当前版本不支持音频输入。对于直播、播客和视频内容，开发者仍需要将音频转写为文本，或者额外接入音频编码模型。

第二，MMEB-v2 的榜首成绩不等于所有业务都能取得同样结果。公开基准中的数据分布、查询方式和候选内容，与具体行业的商品库、企业知识库或社交内容池可能差异很大。

第三，多模态输入的成本高于纯文本输入。图片分辨率、视频帧数、视觉文档页数都会影响推理速度和显存占用。对于超长视频和大型 PDF，预处理、分段和层级索引仍然是必须解决的工程问题。

第四，统一向量空间带来便利，也可能掩盖模态细节。用户搜索“红色跑鞋”时，视觉相似不一定等同于商品属性匹配；检索“合同中的违约责任”时，表格位置、页码和字段关系也不能只靠一个全局向量解决。成熟系统通常会把向量召回与关键词、结构化过滤和精排模型结合起来。

OpenAI Hub 观察

WeMM-Embedding 的真正价值，不在于它又推出了一个参数规模更大的模型，而在于它把“统一多模态表示”从研究问题推进到了经过十亿级日调用验证的基础设施层。

对于开发者而言，最值得关注的是三点：2B 版本在公开榜单上的高性价比，多个 <embedding> 标记带来的单次前向多表示输出，以及 Matryoshka Embeddings 对向量存储和检索成本的调节能力。对于内容平台而言，9B 版本登顶 MMEB-v2 固然重要，但更重要的是文本、图像、视频和视觉文档能够共享一套表示体系，减少跨业务、跨模态系统之间的重复建设。

它并不会直接替代专用视觉模型、OCR、ASR 或排序模型，也不会自动解决知识库权限和内容新鲜度问题。但如果你的系统正在从“文本搜索”升级为“内容搜索”，或者需要让图文、视频和文档进入同一套 RAG 与推荐架构，WeMM-Embedding 值得优先评测。

截至 2026 年 9 月 4 日，模型权重、代码和评测适配已经公开。下一步真正需要看的，不是榜单分数还能否再涨一两分，而是社区能否在更多真实数据集、不同硬件和更低延迟约束下，把这套微信生产环境验证过的多模态表示能力跑起来。

参考来源

• IT之家：微信开源通用多模态嵌入模型 WeMM-Embedding —— 发布信息、模型规模、微信业务部署情况和公开评测成绩。
• Tencent/WeMM-Embedding GitHub 仓库 —— 官方代码、模型使用说明、评测脚本及配置要求。
• Hugging Face WeMM-Embedding 模型集合 —— 官方模型权重与模型集合页面。
• 知乎：微信开源 WeMM-Embedding：2B/4B/9B 多模态向量模型 —— 对统一向量空间、embedding 标记和 Matryoshka Embeddings 的技术解读。