技术知识库 · 工具评测 · 2026-09-11 · 国科智飞 Gavin

微信开源 WeMM：多模态检索底座的能力与边界

一套向量空间同时编码文本、图片、视频和图文文档，2B 版本在公开基准上超过 8B 基线。它强在哪，坑又在哪？

检索系统的老问题是模态分裂：文本走一套向量库，图片走一套 CLIP，视频再单独建一套索引，图文混排的 PDF 干脆没法处理。2026 年 8 月，腾讯微信视觉团队开源 WeMM-Embedding（仓库 Tencent/WeMM-Embedding，Apache-2.0），尝试用一个统一的向量空间解决这个问题，代码和权重全部开源，可商用。

它是什么

WeMM-Embedding 是一个通用多模态 Embedding 模型家族，提供 2B、4B、9B 三个尺寸，底座基于 Qwen3.5 系列。它的输入覆盖文本、图片、视频、视觉文档以及交错多模态输入——一段文字加几张图再加一段视频，可以放在同一次编码里。向量通过 last-layer hidden state 在专用 <embedding> token 位置取出，再做 L2 归一化。

输出维度采用 Matryoshka（套娃）设计：2B 最高 2048 维，4B 最高 2560 维，9B 最高 4096 维，都支持从 64 维起的多档截断。这个设计的实际意义是：向量存储成本可以按需拉伸，小团队不必为用不到的全维度买单。

训练分两阶段：先做大规模多模态对齐，把不同模态映射到统一向量空间；再用精选业务数据做细粒度相关性监督，并做跨规模知识迁移。

能力与亮点

视频检索是最值得关注的部分。 视频片段可以直接变成向量，用于搜索、聚类，或者作为 RAG 的检索源。这在此前的开源方案里是最难啃的模态。

按官方技术报告公布的 MMEB-v2 基准（图像与视频用 Hit@1，视觉文档用 NDCG@5），WeMM-Embedding 2B 平均分 77.9，超过 Qwen3-VL-Embedding 8B 的 77.8；其中视频分项 70.8，而 VLM2Vec-2B 只有 29.0。参数少四倍、分数反超，这是它性价比最直观的证据。4B 平均 79.2，9B 平均 80.6。需要说明的是，这些数字来自项目方技术报告，并非独立第三方复测。

Matryoshka 维度压缩是实用亮点。 官方称 2B 模型在 256 维下能保留全维约 98.7% 的图像与视频性能，存储压到约八分之一。对个人库和小团队来说，这让"图文视混合检索"从做不起变成跑得起。

图文混排文档的编码方式值得单独说。 传统做法是先 OCR 提取文字、再单独描述图片，最后拼成纯文本向量；WeMM 把图文混排文档当作一个整体编码，版面和图片的相对位置信息不会在预处理阶段丢失。对产品手册、研究报告这类图文混排资料，这能减少一道信息损耗。

工程支持完整。 transformers、sentence-transformers、vLLM、SGLang 四条推理路径都支持，vLLM 0.27.0 与 SGLang 0.5.9 官方给了部署命令，一行命令即可起服务。

线上验证过。 模型已在微信内部的视频号、公众号、电商等业务中用于跨模态搜索与内容推荐。据官方技术报告，模型经过多轮线上 A/B 与内部任务验证，服务亿级流量。这不是实验室玩具，但外部团队仍应拿自己的数据验证。

局限与坑

不支持音频。 这是最容易踩的坑。在 MMEB-v3 基准里，WeMM 的音频项记 0.0。视频内容如果包含口播、环境声，只用画面向量会漏掉声音里的信息。真要商用，通常要配 ASR 做双通道混合检索：视频帧向量加口播转写文本向量。

视频计算成本高。 视频按 64 帧采样，编码耗时和算力开销都远超图片。它适合做"值得建索引"的视频，不适合全量流水线无脑跑。

部署有硬件门槛。 按社区经验估算，2B 的 bf16 权重约 4–5GB，推理显存约 6–8GB；4B 和 9B 分别需要 12–14GB 和 22–26GB 级别。vLLM 与 SGLang 都不支持 Apple Silicon，生产环境基本要用英伟达 CUDA 卡。在 16GB 内存的 Apple 笔记本上，用 MPS 跑 2B 只能做小规模验证，单图要几秒，视频基本别想。

基准自报。 MMEB 成绩全部来自项目方报告，不同业务的数据分布差异很大，上线前必须用自己的样本重测召回率。

生态还很新。 模型 2026 年 8 月才发布，第三方工具链、社区微调、踩坑记录都还少。遇到问题主要靠自己读技术报告和源码，这一点和成熟 Embedding 模型的处境不同，团队要做好自担排查成本的准备。

适用场景

• 相册与知识库的图文混检：文搜图、文搜视频，见效最快，2B 加 256 维即可起步。
• Agent 的视觉长记忆：截图、图表、报错日志向量化后按需召回，成本最低。
• RAG 的多模态预处理：图片、截图、PDF 图文文档统一向量化，替代多套模型拼接的方案。
• 内容去重与聚类：海量素材的相似度计算、视频查重、图片去重，以前要按模态分别做，现在一套向量解决。
• 视频与电商内容打标、推荐：价值最大，但最吃部署资源。

选型建议

不要一上来就上 9B。2B 版本在公开基准上已经超过 8B 基线，配合 256 维截断是个人和小团队的甜点配置；等业务真正上量、召回质量成为瓶颈时，再换 4B 或 9B。生产部署建议一张英伟达卡加 vLLM 起 2B 服务，先在一个真实场景验证端到端效果。

如果团队暂时没有英伟达卡，也可以按小时租云 GPU 做验证：起一个 vLLM 实例，把业务里最难的几百条图文查询灌进去，人工看 Top-5 召回里有多少是想要的。这种自定义评测比看榜单有效得多，也最能暴露"这个模型不适合我的数据"。

如果现有系统已经有成熟的文本 Embedding，不要把 WeMM 当成"全盘替换"的选项，更稳的做法是灰度迁移：新模态走 WeMM，文本检索先保持原样，对比一段时间后再决定。还要提前考虑版本管理——Embedding 模型一旦更换，已有向量库需要重建，迁移期建议双写两套向量或者按业务分库，避免一次性重构。

音频场景记得提前设计 ASR 双通道，别等上线后才发现声音信息全丢了。