WeMM-Embedding：2B 参数的多模态嵌入，险胜 8B 对手
为什么文字、图片、视频必须挤进同一个向量空间？
深夜你在视频号刷到一条雪山徒步 vlog。划走之前，系统已经在替你盘算下一件事：在几亿条图文和视频里，找出"你大概也还想看"的内容。难点不在算力，而在一个更基础的问题。一段动态的视频、一篇图文混排的文章、另一段航拍视频，凭什么能比较谁跟谁更像？
先亮一个结果：WeMM-Embedding-2B 在 MMEB-v2 上以 77.9 对 77.8 窄幅超过 Qwen3-VL-Embedding-8B。一个参数只有对手四分之一的小模型，总分竟然超过了 8B 大模型。反常不在"赢"，而在赢得太薄，差距只有 0.1 分。这 0.1 分到底说明什么？要回答它，先回到内容为何必须共用一把尺子。
答案是先把它们变成同一种东西。嵌入（embedding）听着玄，其实就是把一段文字、一张图、一段视频各自压成一串数字坐标，也就是向量，然后放进同一把尺子上量远近：两段内容离得近，就算语义相近。当一切能被检索的内容都落进同一个向量空间，搜索引擎、推荐系统、内容分类，甚至 agent 手里的工具选择，都可以共用这一把尺子。WeMM-Embedding 这篇论文想做的就是这个"通用"二字：一套 2B/4B/9B 的模型家族，任何内容形态都能进，出来的都是同一空间的向量 WeMM-Embedding。
问题在于，真实内容几乎从来不是"一张图配一段文"那么干净。一篇文章图文交错还嵌着视频，一条视频自带字幕转写，朋友圈九宫格每张图配一句话。早期的 CLIP 式双塔编码器只吃"一张图配一段文"的配对，遇到这种任意交错的内容形态就缴械了。你在公众号里读一篇测评，正文图文混排，中间还夹着两段对比视频，评论区再附上用户发的表情包。要让系统真正理解这么一篇内容，输入格式必须能原样吃下这种交错结构。而 WeMM 的训练数据恰恰是按这种"乱"来准备的：六大数据族横跨弱监督配对、图文描述、检索配对、分类、多模态问答、人工分级相关度等任务类型，覆盖从长文档到视频片段的几乎一切组织方式，每一条都是一对 source-target，两侧各自可以是文本、图像、视频或交错组合。
图注：WeMM 训练数据的六大数据族全景。每一族都是一条条 source-target 配对，两侧的模态和任务设置各不相同，这正是"任意交错输入"落进训练集里的形状。图中不标示各族的精确样本量 WeMM-Embedding。
把多模态大模型改造成嵌入模型这条路，倒不是微信首创。所谓多模态大模型（MLLM），就是既能看图又能读文的 Transformer 大模型。VLM2Vec 在 2024 年证明，任何 MLLM 都可以用两个很简单的手段改造成嵌入模型：指令化输入，让同一个模型按任务意图换个姿势取向量；再加上对比学习，也就是训练时把相关的配对往近处拉、不相关的往远处推。VLM2Vec 还顺手立了 MMEB 评测坐标系，最初版本是 4 类元任务、36 个数据集 VLM2Vec。后来的工作把评测一路扩到视频和视觉文档，WeMM 接续的就是这条路线。
为什么这条路线在 2026 年变得紧迫？因为要用向量比远近的不只是搜索引擎：agent 要在几十个工具里挑出对的那一个，推荐系统要在几亿条内容里捞出用户爱看的，都靠同一把尺子。而"听懂指令"这件事，恰恰是纯视觉双塔装不出来的。VLM2Vec 自己拆过这个现象：同一套 backbone，加指令让它涨了 49.4%，却让 CLIP 掉了 29.4%。模型越通用，工程上越省，一套向量到处能用，这就是"通用多模态嵌入"的野心。
所以真正的难点不是某个模态怎么编码，而是让互不相干的内容形态先落进同一个可比较的向量空间，旧方法只能处理"一图一文"的配对。要把方案做对，得在几件事上同时下功夫：输入怎么统一，输出怎么裁剪，训练怎么让六类任务一起变好。下面按这个顺序拆。
一扇门进、一个向量出：统一输入与可裁剪的输出
WeMM-Embedding 一口气放出三档：2B、4B、9B，backbone 用的是 Qwen3.5 系列原生多模态模型（具体子型号论文未点名）。其中 9B 是唯一的七档维度选手，满档 4096；2B 则是 26 任务内部基准里打头阵的那个。三档覆盖从轻量部署到高精度场景，MMEB-v2 总分随规模上升：77.9、79.2、80.6。这个趋势先看图。
图注：WeMM 的性能总览。左栏是 2B/4B/9B 与多个基线模型在 MMEB-v2 上的总分对比，右栏聚合了 MMEB-v2 图像与视频子集、12 任务跨模态检索和 26 任务内部基准四组表现。条形高度只作相对参考，精确数字以论文 Table 1 为准 WeMM-Embedding。
"通用"的一半来自输入格式的统一。WeMM 把任何一条内容都表示成同一个样子：一段可选的任务指令，加一串有序的多模态片段（文本、图像、视频随便怎么交叠），末尾追加一个专用的 <embedding> 标记。除了文本、图像、视频，视觉文档（PDF 页面、扫描截图、长图）也是这条管道里的居民，五种形态加上交错组合，共用同一个输入管道。
那段"可选的任务指令"不是摆设。同样是这段视频，指令写"找出和它最相似的另一条视频"，和写"转述视频里发生了什么"，要求的是两种不同的相似度。模型靠指令在前向时切换姿势。这也是为什么嵌入模型要用会读指令的多模态大模型打底，而不是 CLIP 那种固定双塔。
图注：WeMM 的统一输入链路。任何内容拼成"任务指令 + 交错片段"后追加
<embedding>标记，前向一次，取最后一层该位置的向量做 L2 归一化，就得到嵌入。这条链路对文本、图像、视频一视同仁。
为什么要取"最后一个标记的位置"，而不是把整条序列平均？因为因果注意力下，序列末尾的 token 能看到前面所有内容，相当于把整个输入总结进一个位置。也正因如此，可以在视频段落后面放一个 <embedding>、在序列末尾再放一个，一次前向同时拿到"只看视频"和"视频加转写"两种粒度的表示。这是"一个模型出多种粒度"的另一种形态：不只是维度可长可短，语义覆盖范围也能按需圈定。顺带一提，这一招依赖因果注意力：序列末尾的 token 天然拥有全量视野，换成双向注意力的编码器反而没有这种地位。
输入统一了，输出还要能裁剪。WeMM 采用 Matryoshka 表示学习（MRL）的做法：训练时就强迫模型学会用向量的前 64 维、前 128 维、前 256 维直到满维，分别把任务做好。这就像一个俄罗斯套娃，最外层是完整向量，往里每一层前缀都是一个能独立使用的向量。这套设计的底气来自 2022 年的原始论文：它在 ImageNet-1K 上验证过，配合自适应的候选筛选加重排，检索的浮点运算量能降到约 128 分之一，端到端时间快约 14 倍，精度基本不掉。训练的时候让每个嵌套维度都参与损失计算，模型就知道每一层前缀都得"能打"。这样推理时，同一个前向产出的向量可以按需截出任意支持的维度，截断后重新归一化即可，不重新训练、不换模型 MRL。
图注：WeMM-Embedding-2B 在 MMEB-v2 上随嵌入维度缩放的相对性能。左图是图像、视频、视觉文档三类任务的性能保持率，右图是分类、问答、检索三类任务的保持率，横轴从 64 维到 2048 维，以满维分数为 100% WeMM-Embedding。
这套设计的工程价值直接落在钱上：向量库按维度计存储和计算成本，向量能截短，同样的库就能塞更多内容，检索也更快。官方仓库把三个规模的可用维度写成了白名单：2B 满维 2048，4B 满维 2560，9B 满维 4096，共享 64 到 1024 的前缀档位。也就是说，哪怕只想要一个 128 维的轻量向量，也不用单独训一个小模型。仓库自报 2B 在 256 维仍保留满维图像与视频性能的 98.7%，论文因此把 256 维或 512 维称为"效率敏感场景的实用选择"。向量库里的索引是按固定维度建的，维度越低，索引越小、单次比对越快，原来塞不下的长尾内容也能装进来 WeMM 官方仓库。
门和出口都定好了，可训练数据的形状千奇百怪，怎么把六类任务一起教会？这是下一章的事。
先广撒网对齐，再精修出判别力：两阶段训练的账本
为什么训练不能一步到位？因为"对比学习"式的对齐是粗的：它只管把相关的配对拉近、不相关的推远，但"相关"这件事在真实场景里往往要细看才能判定。两张图都拍到了雪山，一张是徒步路线、一张是高原救援指南，普通对比学习未必分得出这种难例。要分得清，就得加细粒度的监督。
但细粒度监督很贵。先让模型写一段推理再取向量，判别力最强，可推理要生成几百个 token，检索延迟直接爆表，工业场景扛不住。同期发表的抖音 DME 报告画了一张三栏对照图，把这条权衡讲得很清楚：左边是单遍对比编码，快但粗糙；中间是显式推理前置，细但慢；右边是工业路线，把细粒度监督塞进训练期，推理时仍然只做一次前向 DME。
图注：DME 论文对三类嵌入范式的归类：(a) 单遍对比编码，延迟低但表示粗糙；(b) 推理前置，判别细但延迟高；(c) 训练期结构化精修，推理时保留单遍编码的低延迟。这个三分法是 DME 论文自己的划分，WeMM 走的是 (c) 那一档 DME。
WeMM 的两阶段就是这个工业路线的具体实现。第一阶段在数亿条 source-target 配对上学大规模对齐：InfoNCE 对比学习打底，同一 batch 内自动去重，避免把相似样本误当成负样本；带分级标注的样本改用排序损失约束"分数高的排前面"；每个支持的维度都参与加权。InfoNCE 的做法是拿 batch 里其他所有配对当负样本，谁的相似度错得离谱就重罚谁，负样本质量直接决定对齐的上限。这一阶段的目标，是把"谁和谁相关"大致摆对。
Stage 1 里有两个细节容易被忽略，却都值得说清楚。一是 duplicate-aware masking：同一个 batch 里若恰好有两张几乎一样的图，训练会把它们互相当成负样本推远，等于自相矛盾，所以要先按相似度阈值把重复项筛掉。二是 task-consistent batching：同一个 batch 只装同一类任务的数据，免得不同任务的对比目标互相打架。前者保证负样本是真的负，后者保证每个 batch 的训练目标干净。
图注：WeMM 的两阶段训练链路。Stage 1 在数亿条配对上学粗对齐，Stage 2 在约十分之一规模的精筛数据上叠加 reranker 监督与跨尺度蒸馏，把判别力磨细；9B 没有老师可蒸馏，改用多个变体合并。
第二阶段换用约十分之一规模的精筛数据，构造时三件套缺一不可：按语义 ID 重采样，缓解数据的分布偏斜；用 MLLM 筛掉质量不达标的配对；再人为构造 hard negative，也就是那些看似相关、其实不相关的陷阱候选。在这批数据之上叠加两类细粒度监督。一是 reranker 监督：训练一个专门的排序器给候选打分，把分数当监督信号。二是跨尺度知识蒸馏，这是整个 Stage 2 里最值得讲的一笔：2B 和 4B 拿冻结的 9B 当老师，学的不再是"这个对、那个错"的 one-hot 标签，而是老师在一组候选上给出的相似度分布。哪个跟 query 最近、哪个只是接近、哪个差得远，这种相对排序的信息量比正负标签丰富得多。小模型不是在抄大模型的答案，是在学大模型打分的手感。所谓双向，就是 source 到 target 和 target 到 source 两个方向分别算一遍 KL 散度，老师在两个方向上的偏好都得学。hard negative 则是判别力的磨刀石：模型要是连这种陷阱候选都能排对，日常那些普通负样本自然不在话下。
每一笔投入的回报，消融算得很清楚。Stage 1 检查点在 MMEB-v2 上拿到 75.7，之后每加一样涨一点：精筛数据 +0.9，reranker 监督只有 +0.1，双向 KL 蒸馏 +0.9，最后把视觉输入预算（更高分辨率、更密的视频抽帧）加上去再 +0.3，最终 77.9，Stage 2 累计 +2.2。Stage 1 一侧也有一个醒目数字：去掉 task-consistent batching 是最大的单项损失，整整掉了 3.4 分 WeMM-Embedding。有意思的是，reranker 监督只值 0.1 分，论文自己也承认拿它重排多数多模态任务并不持续提升；真正值钱的是蒸馏那一笔。
而 9B 自己没有更大的老师可蒸馏。它的做法是训练多个各有所长的 Stage 2 变体，再用 TIES 模型合并把它们融成一个最终模型。同一套"两阶段"框架，抖音 DME 走的是另一条精修路线，在训练期做隐式推理加跨条件重建；两家几乎同时发表、互不知情，却得出同一个结论：要保住推理时单遍编码的延迟，细粒度监督就得搬进训练期。
DME 在自己的报告里给出过一组工业数字：离线相对上一代在产模型平均提升 2.92%，上线后搜索场景的在线指标涨了 0.1%，而 query 端编码延迟只增加不到 1 毫秒。那是抖音的业务口径，与微信的场景、流量、任务构造都不同，两家的数字不能拿来直接比较。但两篇报告放在一起至少证实了一件事：把细粒度监督搬进训练期这条路线，在两家不同的工业系统里都走通了。
花这么大力气磨出来的模型，在公开榜单上拿到的 80.6 分，到底该怎么读才不算被骗？下一章拆这个分数。
80.6 分该怎么读：宏平均、0.1 分与 audio=0
先讲口径，再讲数字。MMEB-v2 是当前多模态嵌入事实上的坐标系：9 类元任务、78 个数据集。图像和视频任务用 Hit@1，也就是第一个候选就命中算对；视觉文档任务用 NDCG@5，衡量前五个候选的排序质量；总分是 78 个任务的宏平均。宏平均的意思是，一个单项的反向完全可能被别的项盖过去，1 分涨落也可能来自毫无关系的任务。举个直观例子：如果 24 个视觉文档任务整体偏弱、36 个图像任务整体很强，总分照样好看，但"文档理解不行"这个事实就被平均掉了 VLM2Vec-V2。
图注：MMEB-v2 的 9 类元任务、78 个数据集结构。蓝色边框的是从 MMEB v1 继承的图像类任务，红色边框的是 V2 新增的视频与视觉文档任务 VLM2Vec-V2。
有了坐标系，把 WeMM 的分数拆成三种读法。先看核心三家，数字出自论文 Table 1，仓库 README 表可作为核对。口径不同的分数不能横比：MMEB v1 是 36 个任务的旧尺子，v3 又加了文本、agent 和音频，把三个版本的分数排在一起没有意义：
| 模型（MMEB-v2） | AVG | Image | Video | VisDoc |
|---|---|---|---|---|
| WeMM-Embedding-2B | 77.9 | 79.6 | 70.8 | 80.7 |
| Qwen3-VL-Embedding-8B | 77.8 | 80.1 | 67.1 | 82.4 |
| WeMM-Embedding-9B | 80.6 | 81.9 | 74.3 | 83.3 |
第一种读法是宏平均。9B 的 80.6 是作者声明的官方 leaderboard 第一，状态截止到 2026 年 8 月 24 日。但榜首里还混着 Seed-1.6（76.9）、QQMM（78.3）、Octen（80.1）、DME-Large（80.2）这些闭源条目，它们的分数来自提交、没有公开权重，无法与开源模型公平比较。严格说，这张榜上同时开着两场比赛：一场有源码可跑，一场只有分数可看。所以 80.6 的准确含义是：开源阵营里能自己跑出来的最高分，这是它的真实分量。
第二种读法是拆子项。标题里的"险胜"在这里兑现成事实：2B 的 77.9 只比 8B 的 77.8 高 0.1 分，而且 VisDoc 子项里 2B（80.7）反而低于 8B（82.4）。"2B 超 8B"是真的，但幅度小到接近噪声，且不是处处成立。9B 的领先则有实打实的分量，每一列都比 8B 高出一截。如果只看总分，2B 和 9B 只差 2.7 分；拆开看，视频子项差了 3.5 分，规模红利主要落在视频这类更难的任务上。
第三种读法是跨口径。MMEB-v3 把坐标系扩到 190 个任务，新增 53 个复杂文本、47 个 agent 任务和 11 个音频任务，不支持的模态按 0 分计。WeMM 全系不支持音频，V3-All 的 56.0、58.2、59.5 是带着 11 个音频零分拿下的。九个评测维度里 audio 一整栏都是 0.0，在表格里非常扎眼：WeMM 的选择是先做透视觉语言这条线，音频留给未来。更能说明问题的是 MCMR 子项：2B 拿 42.5，4B 反而掉到 41.9，9B 才跳到 49.3。规模效应在这里不单调，"越大越好"并非处处成立。
把三种读法叠起来，结论很朴素：9B 是真领先，2B 的"险胜"是窄幅领先，而整个家族都在音频上缺席。分数能信，但领先要放在子项和口径里看。那公开榜单好看，落到微信真实业务里是什么样？这些数字又能照单复现吗？
从榜单到全量上线：三层证据与复现的边界
论文的自我证明分三层，可信度各不相同。第一层是公开基准，也就是前面的 Table 1/2，任何人有 GPU 都能复跑，最硬。第二层是微信内部 26 任务基准：WeMM-2B 平均 72.0，把同规模的 Qwen3-VL-Embedding-2B 的 60.9 甩开 11 分，五类子项（分类、检索、跨域、文章相关性、视频相关性）全部更高，但子任务的具体内容没有公开，只能信作者报数。第三层是 14 项在线 A/B 测试，论文只说"一致提升并已全量上线"，没有逐项百分比、没有置信区间，这是声明，不是证据。
| 证据层 | 内容 | 能核实到什么程度 |
|---|---|---|
| 公开基准 | 论文 Table 1/2，仓库 README 表可逐格核对 | 可独立复现 |
| 内部 26 任务 | Table 4：WeMM-2B 72.0 vs 60.9，子项明细未公开 | 只有汇总数，无明细 |
| 在线 14 项 A/B | "一致提升，已全量"，覆盖四个业务线 | 作者声明，无逐项幅度与显著性 |
这套模型已经上线到视频号、公众号、朋友圈和电商的候选召回与排序特征里，还用于用户序列建模和跨域内容理解，跑实际业务相当一段时间。整条部署链路长这样：
图注：WeMM 的部署链路。输入经过 chat template 自动追加
<embedding>标记，取对应位置的最后一层向量，L2 归一化后按需截断到白名单维度，再归一化一次，写进向量库做 ANN 检索。运行时可在 transformers、vLLM 或 SGLang 三种后端里选。
复现的边界在哪里，仓库交代得很清楚。推理、serving 和 MMEB-v3 评测代码都开源了，SGLang 跑视频要打补丁，transformers 官方只推荐 5.2.0 版本，因为新版预处理行为可能不同，这些是真实的工程摩擦。但训练代码完全没有：两阶段训练、reranker 监督、跨尺度蒸馏，全都不可以从公开材料复现。也就是说，SOTA 目前是作者的话，不是任何人能验证的事实。音频不支持这件事，被仓库里四处独立确认（README 模型卡、评测表全 0、eval 注释），是明示的边界而不是遗漏。许可证上 README 称 Apache-2.0，但 LICENSE 文件把范围限定在仓库内代码，模型权重的条款要另查模型卡 WeMM 官方仓库。
评测这一侧倒是有完整的复现路径。仓库里的 MMEB-v3 评测代码是从 VLM2Vec 官方评测管线原样移植的，连上游提交号都钉死；长文本和图形界面任务要开单条 batch、最大长度 262144，视频抽帧从默认 8 帧加深到 64 帧，<embedding> 标记由模板自动追加、不允许手动插入。想复现的人照着这份设置跑即可：能跑的和跑不了的，分界很清楚。
一个工业模型能开源到这种程度已经难得，但它也意味着：这篇报告的价值，一半在能核对的数字里，一半在核对不了的空白里。天花板在哪，是最后一章的事。
音频缺口与下一个赛点
评测的边界正在被拉大。MMEB-v3 把坐标系从 78 个任务扩到 190 个，新增的音频、复杂文本和 agent 任务，直接照出视觉语言系嵌入模型的共同短板 MMEB-V3。
图注：MMEB-v3 的 190 任务结构。基底是 v2 的图像、视频、视觉文档任务，上方新增长文本检索、agent 任务、音频任务，以及一组语义等价的跨模态诊断元组 OmniSET。这是评测覆盖图，不是性能对比图 MMEB-V3。
这类诊断靠的是一套叫 OmniSET 的新考题：把同一条语义分别做成文本、图像、视频、音频四个版本，配上同一组人工核验的难例，然后让模型做 12 个方向的跨模态检索，方向找对才算真正"按指令找模态"。
把 v3 的任务按 query 和 target 的模态配对拆开，还会看到另一个结构性现象：绝大多数配对都落在同一模态里（文本对文本、图对图、视频对视频），跨模态的音频配对少得可怜。连评测本身都还没给出足够多的跨模态考卷，"跨模态"这门课自然也没被充分考到。
MMEB-v3 的诊断还揭开了整个领域欠着的一笔账。跨模态检索存在明显的方向不对称：图像到视频的方向命中率接近满分，反过来却只有个位数，差异悬殊到这个程度已经不是"能力"能解释的，更像评测数据生成方式留下的痕迹；模型返回的"相关"结果往往模态跟着查询走，而不是跟着指令指定的目标模态走；给查询加上一句"我想要视频"的指令，向量确实动了，但常常不是朝目标模态靠近，而是被推离。这些诊断结论适用于所有候选模型，WeMM 的 audio=0 只是这组共同欠账当中的一个实例。它的领先，是在自己整类模态缺席的前提下取得的。
补课的方向也不止"加一个音频塔"这一条。同期工作 UMER 展示了另一条叫 embed-then-rerank 的路线：在同一个模型里既训练嵌入头又训练排序头，先用向量召回 top-K 候选，再对候选两两配对做排序，两条路互相蒸馏 UMER。UMER 为此配了三档开关：纯嵌入召回、pair-aware 排序、两者混合，场景要快就用第一档，要准就上第三档。它提醒我们，精度和效率的账除了"把向量截短"还有另一种算法：把最贵的判别留给最少的候选。
回到开头那个问题：2B 险胜 8B，这 0.1 分意味着什么？把它放回 78 个任务的宏平均里，它只是小数点后的一个呼吸；把它放回"开源阵营里最小的模型能逼平上代最大模型"这个事实里，它是训练方法进步的证据。WeMM-Embedding 的价值不在"登顶"这个词，而在它同时把两样东西摆上了台面：一套把工程最佳实践做到极致的配方，和一份把边界讲得清清楚楚的诚实。音频、跨模态方向、可复现性，这三笔账谁先补齐，谁就是下一轮赛点。
想深入可以读原文：WeMM-Embedding: WeChat Multi-Modal Embedding Technical Report，arXiv:2608.24053。
参考文献
- WeMM-Embedding 技术报告（references/ref-001-wemm.md）：https://arxiv.org/abs/2608.24053
- Tencent/WeMM-Embedding 官方仓库（references/ref-002-wemmrepo.md）：https://github.com/Tencent/WeMM-Embedding
- MMEB-V3: Measuring the Performance Gaps of Omni-Modality Embedding Models（references/ref-003-mmebv3.md）：https://arxiv.org/abs/2604.23321
- VLM2Vec-V2: Advancing Multimodal Embedding for Videos, Images, and Visual Documents（references/ref-004-vlmvecv2.md）：https://arxiv.org/abs/2507.04590
- VLM2Vec: Training Vision-Language Models for Massive Multimodal Embedding Tasks（references/ref-005-vlmvec.md）：https://arxiv.org/abs/2410.05160
- Douyin Multimodal Embedding Model Technical Report（references/ref-006-dme.md）：https://arxiv.org/abs/2608.02148
- Matryoshka Representation Learning（references/ref-007-mrlumer.md）：https://arxiv.org/abs/2205.13147
- UMER: Unifying Embedding and Ranking via Pair-Aware Discriminative Reasoning（references/ref-007-mrlumer.md）：https://arxiv.org/abs/2608.18504