微信如何训练多模态 Embedding 模型

简介: 多模态 Embedding 模型训练的两个阶段……

Embedding 模型从文本扩展到图片、视频和视觉文档之后,训练需要处理的数据类型和任务也变得更加复杂。如何把不同模态、不同任务的数据组织进同一套训练体系,并学习统一的多模态表示,正成为训练中的一个核心问题。

上周,微信团队发布了 WeMM-Embedding 技术报告,并开源了 2B、4B 和 9B 三个版本。模型支持文本、图片、视频、视觉文档以及交错多模态输入,并应用于微信内部的搜索和推荐场景。

WeMM-Embedding: WeChat Multi-Modal Embedding Technical Report」论文采用两阶段训练方案:第一阶段用数亿级异构数据完成大规模多模态对齐第二阶段再通过数据重采样、质量清洗、难负样本、Reranker 和模型蒸馏进一步提升表示能力

在这篇文章里,我们将从训练数据、Batch 构造和两阶段训练策略入手,看看微信是如何训练一个多模态 Embedding 模型的。

多模态训练数据的统一组织

WeMM-Embedding 面对的第一个问题,是训练数据之间存在很大差异。论文中显示的训练数据主要包括六类:

  • 图文、视频文本等弱监督配对数据;

  • 描述实体、属性、关系、动作、空间和时间信息的图像/视频描述数据;

  • 实例、文档、时刻定位、组合查询、推理、工具和 GUI 等检索数据;

  • 商品、视频、文章等带多级相关性的配对数据;

  • 物体、场景、动作等分类数据;

  • OCR、文档、图表、知识、空间关系和推理等问答数据。

这些数据覆盖文本、图片、视频以及交错多模态输入,来源包括公开数据集、Web 级弱监督数据、面向任务生成的合成数据,以及微信内部数据。第一阶段使用的数据规模达到数亿对。

图 1:多模态训练数据概述图

面对这些差异很大的任务,微信团队没有为每种任务建立独立的数据结构,而是把训练样本统一表示成一个 Pair:

$$z_i=(I_i,q_i,c_i,N_i,y_i$$

其中包含五个元素:

  • Iᵢ:可选的任务指令;

  • qᵢ:Source,也就是查询侧输入;

  • cᵢ:与 Source 匹配的 Target;

  • Nᵢ:可选的显式难负样本(Hard Negative,下面简称:难负样本);

  • yᵢ:可选的相关性分数。

Source 和 Target 都可以是文本、图片、视频,也可以由多种模态交错组成。

经过这种转换,大量看起来差异很大的任务,都能够进入同一种训练接口:给定一个 Source,在候选空间中找到与它匹配的 Target。图文检索可以写成图片与文本 Pair,分类任务可以转成输入与类别描述 Pair,视觉问答可以转成问题与答案 Pair,工具检索也可以转成查询与工具描述 Pair。

不同任务依然保留各自的语义,但进入训练管线之后,可以共享同一套 Source-Target 数据结构。

多模态 Embedding 的表示提取

数据结构统一之后,接下来是如何从原生多模态模型中得到 Embedding。

WeMM-Embedding 基于 Qwen3.5 的原生多模态架构构建。文本、图片和视频经过各自的处理流程后,会按照原始输入顺序排列成一串 Token。

微信团队在序列结尾加入一个专门的 <embedding> Token。

文本 / 图片 / 视频 / ...
          ↓
Multimodal Tokens
          ↓
<embedding>
          ↓
Qwen3.5
          ↓
最后一层 <embedding> Hidden State
          ↓
L2 Normalize
          ↓
Embedding

模型完成前向计算后,取 <embedding> 对应的最后一层隐藏状态,再进行 L2 归一化,得到整段多模态内容的向量表示。

这个设计有一个比较灵活的点,就是一段输入中可以放入多个 <embedding> Token。论文举了视频和语音转写的例子。可以在视频 Token 后加入一个 <embedding>,再在视频与 ASR 文本之后加入另一个 <embedding>

一次前向计算便可以得到两种表示:

视频
  ↓
Video Embedding

视频 + ASR 文本
  ↓
Video-Text Embedding

通过这种方式,同一个输入序列可以同时生成面向不同下游需求的向量。

模型训练的第一阶段

WeMM-Embedding 的训练分为两个阶段。

第一阶段使用数亿规模的训练数据,目标是建立一个覆盖范围足够广的通用多模态表示空间。这个阶段会从前面提到的六类数据中采样训练,其中一个关键设计是 Batch 的构造方式:同一个 Batch 中的样本来自同一数据源和同一任务。

对于普通的 Source-Target 配对数据,模型采用 InfoNCE 对比学习。每条样本对应的 Target 是正样本,同一 Batch 中其他样本的 Target 则作为负样本;如果数据本身包含显式难负样本,也会一并加入负样本集合。

这里,Batch 如何构造会直接影响 In-batch Negative 的质量。

如果把分类、视频检索、文档检索和图文匹配等不同任务混在同一个 Batch 中,其他样本虽然也会被当作负样本,但它们可能来自完全不同的候选空间,缺少有意义的比较关系,对模型学习细粒度区分能力的帮助有限。

而论文中的消融实验也证实了这一点。

图 2:第一阶段数据分析

论文用 2B 模型做了一组小规模的第一阶段消融实验。结果显示,任务一致的 Batch 对效果影响最大:去掉这一设计后,MMEB-v2 的平均分从 71.9 降到 68.5,下降了 3.4 分;相比之下,去掉任务指令后下降 0.8 分,去掉重复感知 Mask 后下降 0.5 分。这说明,多任务训练虽然可以共享统一的数据接口,但 Batch 内的样本仍需要来自相同任务,避免把缺乏有效比较关系的候选混在一起

除了任务之间的差异,In-batch Negative 还要处理假负样本。比如在分类任务中,两张图片都可能对应 "dog",如果它们进入同一个 Batch,其中一条样本的 "dog" Target 就可能被另一条样本当作负样本参与训练。针对这类情况,WeMM-Embedding 会同时检查 Source 和 Target 的相似关系,对重复或语义近似的样本进行 Mask,避免它们互相成为负样本。上面的消融结果中,去掉重复感知 Mask 后,MMEB-v2 从 71.9 降到 71.4。对于大量样本可能共享 Target 的任务,这一步可以减少错误的负样本监督。

除了正负样本,部分搜索和推荐数据还包含更加细粒度的相关性。

高度相关
相关
弱相关
不相关

对于这类数据,WeMM-Embedding 使用基于 CoSENT 的排序目标。

训练过程中,模型会比较不同 Source-Target Pair 之间的相关性顺序,并根据两组样本的相关性分数差距调整权重。相关性差距越大,排序错误受到的惩罚也越强。

训练目标由简单的 正样本 > 负样本扩展为 高度相关 > 相关 > 弱相关 > 不相关

由此,第一阶段通过完成大规模多模态对齐、In-batch Negative 和多级相关性学习,先建立一个覆盖范围足够广的表示空间。

模型训练的第二阶段

第一阶段完成后,WeMM-Embedding 会从原有数据中筛出一套规模约为十分之一的精选训练集,用于第二阶段训练。相比第一阶段强调数据规模和任务覆盖,第二阶段更关注语义分布、数据质量和难样本,希望用更少的数据提供更有效的监督。

其中一个关键环节是基于 Semantic ID 的重采样。大规模训练数据很容易呈现长尾分布:部分高频语义模式反复出现,低频语义则覆盖不足。如果继续按照原始分布采样,模型会反复看到相似内容。

WeMM-Embedding 先使用中间 Checkpoint 对训练数据进行编码,再训练一个三层 RQ-KMeans 量化器,将每条样本映射成一个三段式 Semantic ID。随后根据不同 Semantic ID 的密度重新调整采样概率:

高密度 Semantic ID
        ↓
降低采样比例

低密度 Semantic ID
        ↓
提高保留比例

这种重采样会降低高频语义模式的占比,让精选训练集覆盖更多不同的语义区域。

Semantic ID 在论文里还被用于线上系统。在微信的推荐场景中,多模态 Embedding 会进一步转换成 Semantic ID,用作索引和用户序列建模中的离散特征。

完成语义重采样后,训练数据还会进入质量清洗阶段。微信使用多模态大模型判断 Source-Target Pair 是否符合对应任务的语义关系,并过滤匹配错误的数据;对于部分文本字段,模型也会参与修正。

例如,从 Web 获取的图文和视频文本弱监督数据规模很大,但其中可能包含噪声、描述错误或语义偏差。多模态模型会尽量保留原始 Alt Text 的表达风格和信息粒度,同时修正会影响训练质量的内容。

整个第二阶段的数据精炼过程可以概括为:

Stage 1
数亿级训练数据
      ↓
通用多模态表示空间

      ↓

Semantic ID 重采样
      ↓
质量清洗
      ↓

Stage 2
约 1/10 精选训练数据

第二阶段的数据量明显减少,但样本的语义覆盖和监督质量得到进一步整理。

监督信号增强

数据筛选完成后,第二阶段还会进一步增强训练样本提供的监督信号,其中一个重点就是难负样本的构造。

WeMM-Embedding 会根据不同模态采用不同的难负样本生成方式。对于文本 Target,多模态大模型会根据 Source 和正确答案生成语义接近、表面合理但实际错误的候选;对于图片和视频 Target,则使用 WeMM-Embedding 的中间 Checkpoint,从对应任务的真实候选池中检索语义相近的图片或视频。

这样一来,中间阶段训练出的 Embedding 模型又会反过来参与下一阶段的数据构造,形成一个训练闭环:

训练 Embedding
      ↓
得到中间 Checkpoint
      ↓
从真实候选池检索难负样本
      ↓
构建精选训练数据
      ↓
进一步训练 Embedding

对于图片和视频,从真实候选池中挖掘难样本还有一个好处:负样本和模型上线后面对的候选分布更加接近,也减少了额外生成视觉内容的成本。

难负样本构建完成后,微信还训练了多模态 Reranker。针对同一个 Query,Reranker 会分别判断正确 Target 和多个难负样本的相关程度,并输出更细粒度的相关性分数:

Candidate A   0.93
Candidate B   0.71
Candidate C   0.43
Candidate D   0.12

相比简单的正负标签,这些分数保留了不同候选之间更细的相关性差异。不过论文实验显示,Reranker 监督并非对所有任务都能带来稳定收益,因此第二阶段只在经过实验验证有效的任务上使用这类监督。

除了 Reranker,2B 和 4B 模型在第二阶段还会接受来自 9B WeMM-Embedding 的知识蒸馏。9B 模型作为冻结的老师模型,为较小模型提供额外的相似度监督。

这里蒸馏的重点,是老师模型在整个 Batch 中给出的候选相似度结构。例如,同一个 Query 面对多个 Candidate 时,老师模型可能产生这样的相似度分布:

          A      B      C      D
Query    .91    .73    .28    .11

相比 One-hot 正负标签,这种分布保留了不同候选之间更细的语义距离。

训练时,模型会分别计算 Source→Target 和 Target→Source 两个方向的概率分布,再通过 KL 散度约束学生模型接近老师模型,把 9B 模型学到的多模态相似度结构传递给 2B 和 4B 模型。

对于 9B 模型,由于没有更大规模的同系列老师模型,微信采用了另一种方式:训练多个使用不同数据混合和训练配置的 Stage 2 模型,再通过模型合并得到最终版本。

训练策略的消融分析

论文通过一组累积消融实验,观察第二阶段各项策略带来的收益。

图 3:第二阶段分析

整个第二阶段将 MMEB-v2 的分数从 75.7 提升到 77.9。其中,精选数据带来了 0.9 分增益;加入 Embedding 老师模型蒸馏后,分数又从 76.7 提升到 77.6,是这一阶段贡献较明显的策略之一。

Reranker 对整体指标的提升只有 0.1 分,但视觉文档任务从 78.5 提升到 79.1,也印证了前面的实验观察:这类监督对部分任务更有效,因此只用于经过验证的训练任务。最后一步增加视觉输入预算,包括更高分辨率的图片和更密集的视频帧采样,视频相关任务从 70.0 提升到 70.8。

从这组消融实验来看,第一阶段完成大规模表示对齐后,第二阶段的主要增益来自更精细的数据筛选、监督信号增强,以及跨规模知识迁移。

Matryoshka 多维表示训练

Embedding 模型进入搜索和推荐系统后,还需要考虑向量带来的存储和检索开销。Embedding 维度越高,索引空间、向量存储和相似度计算的成本也会随之增加。

为此,WeMM-Embedding 引入了 Matryoshka Representation Learning。训练时,模型会同时在多个 Embedding 维度上计算目标;推理时只需进行一次前向计算,再截取完整向量前面的不同长度并重新归一化,就可以得到多种维度的 Embedding。

图 4:不同 Embedding 维度下的性能表现

论文测试了 64 到 2048 维之间的模型表现。2B 模型压缩到 256 维后,图片和视频任务仍能保留 2048 维版本约 98.7% 的性能;提升到 512 维后,两类任务分别可以保留约 99.2% 和 98.8% 的性能。

不同任务对向量维度的敏感度并不相同。视觉文档在降维后的性能下降更明显,检索任务对向量长度的依赖也高于分类任务。不过当维度达到 256 之后,论文测试的分类、问答和检索任务都能保留完整维度模型超过 97% 的性能。

从部署角度看,如果业务更关注向量存储和检索效率,256 或 512 维是比较有参考价值的选择。

微信业务场景的线上验证

最终,WeMM-Embedding-2B 在 MMEB-v2 上取得 77.9 分,9B 模型则达到 80.6。除了公开 Benchmark,微信团队还构建了一套包含 26 个内部任务的评测集,覆盖分类、搜索、跨域内容匹配、文章相关性和视频相关性等场景。

在这套内部评测中,WeMM-Embedding-2B 的平均得分达到 72.0,高于对照模型 Qwen3-VL-Embedding-2B 的 60.9。

目前,WeMM-Embedding 被用于视频号、公众号和电商等推荐场景,参与候选召回、排序特征构建、用户序列建模和跨域内容理解;在搜索侧,则覆盖视频号视频、公众号文章和朋友圈内容。

论文还披露了 14 项线上 A/B 测试,多项指标取得持续收益,相关方案随后进入生产环境。

把前面的训练过程收束起来,WeMM-Embedding 的整体链路可以概括为:

异构多模态数据
      ↓
统一 Source-Target Pair
      ↓
任务一致 Batch
      ↓
大规模对比学习
多级相关性学习
      ↓
通用多模态表示空间
      ↓
Semantic ID 重采样
数据质量清洗
Hard Negative
      ↓
Reranker 监督
Embedding Teacher 蒸馏
      ↓
Matryoshka 多维表示
      ↓
搜索 / 推荐

第一阶段通过大规模、多任务数据建立统一的多模态表示空间;第二阶段则缩小数据规模,通过重采样、数据清洗、难负样本和知识蒸馏,提高监督质量和相似度区分能力。

进入线上系统后,Matryoshka 多维表示和 Semantic ID 又进一步兼顾了向量存储、检索效率和推荐建模需求。

从工程实践角度看,WeMM-Embedding 的参考价值也在于此:多模态 Embedding 的训练效果除了依赖底座模型,也受到数据组织、Batch 构造、负样本质量和第二阶段训练策略的共同影响。

相关文章
|
5天前
|
存储 Shell API
拆解 dsh 系列:从源码和版本变化看 DeepSeek Harness 的设计取舍
DeepSeek Harness(dsh)发布仅两周,实则历经两个月内部打磨。本文基于Git历史与npm发布数据,梳理其从0.0.1-rc.1到0.1.1-rc.2的演进:命名重构、定位升维(Coding Agent→Agent Harness)、核心与扩展边界持续厘清,展现一个开源智能体运行时如何审慎定义自身能力疆界。
106 1
拆解 dsh 系列:从源码和版本变化看 DeepSeek Harness 的设计取舍
|
12天前
|
存储 JavaScript 安全
dsh 拆解系列 Vol.01:没有特权内核的 Agent 运行时
DeepSeek Harness(dsh)是DeepSeek开源的Agent运行时框架,秉持“一切皆插件”理念,将模型适配器、工具、会话、主循环等全部解耦为可配置、可替换、可卸载的插件,基于Cordis元框架实现时空可组合性。当前v0.1.0-rc.7为开发者预览版,MIT协议,强调工程可扩展性而非仅功能堆砌。
152 2
dsh 拆解系列 Vol.01:没有特权内核的 Agent 运行时
|
30天前
|
人工智能 缓存 安全
DeepSeek V4-Flash 正式版接入 Codex,OpenAI 新模型 Astra 浮出水面,Google DeepMind 明星团队被拆
本期「周一上线」聚焦AI两大演进方向:模型加速迈向多模态与机器人,Agent则从“写代码”升级为长期协作、端到端交付与自我改进。DeepSeek V4-Flash、MiniMax H3、Gemini Robotics 2等密集发布,OpenAI Astra、Lilian Weng的RSI团队、贾扬清Intent Lab齐探AI自主进化;行业层面,AlphaFold团队拆分、字节整合飞书/豆包/火山引擎,技术与组织同步重构。
214 1
DeepSeek V4-Flash 正式版接入 Codex,OpenAI 新模型 Astra 浮出水面,Google DeepMind 明星团队被拆
|
14天前
|
安全 JavaScript Shell
DeepSeek Harness 设计解析:从 Agent Harness 的六个关键决策讲起
DeepSeek Harness 是一款“一切皆插件”的开源Agent执行框架,聚焦长任务可靠运行:通过可替换的Loop机制、按需暴露的工具Schema、动态管理的上下文、事件驱动的持久状态、分层权限控制及多维验证体系,解决任务中断、约束丢失、上下文污染与验收失真等核心痛点。
310 0
|
2月前
|
人工智能 自然语言处理 开发工具
Codex 实践系列 Vol.03:Codex 那些好用的 slash command
本文是Codex系列第三篇,聚焦真实项目协作:以AI志愿填报Demo为案例,详解`/status`、`/goal`、`/plan`等核心slash命令的实战用法——从确认环境、设定目标、规划修改,到聚焦文件、审查diff、复查逻辑、压缩长对话,系统提升AI编程的可控性与工程规范性。
228 2
Codex 实践系列 Vol.03:Codex 那些好用的 slash command
|
2月前
|
数据库 开发工具 知识图谱
从 DeepWiki 到 OpenWiki:Agent Wiki 到底有什么用?
Agent Wiki 是一种新型知识管理范式:将RAG中“查询时实时检索”改为“导入时预编译”,用模型自动生成并持续维护结构化Markdown Wiki。它解决传统RAG重复推导、无法积累的问题,适用于稳定文档集,但需区分“文档知识”与“用户记忆”。
243 0
|
2月前
|
运维 监控 安全
Coding Agent 规则管理:CLAUDE.md、Skills、Hooks、Subagents 到底怎么选?
Claude Code 用分层设计把 Coding Agent 的规则拆成多种机制,让约束在合适的时机生效
257 1
Coding Agent 规则管理:CLAUDE.md、Skills、Hooks、Subagents 到底怎么选?
|
2月前
|
自然语言处理 安全 API
Agent Graph Engineering:从线性 Workflow 到可扩展 Agent 系统
本文介绍Agent图编排(Agent Graph Engineering)的核心思想:摒弃简单串行流程,以数据依赖关系构建节点(Agent/代码)与边(数据流)组成的有向图。强调清晰输入输出约定、并行执行、故障隔离、验证机制与动态循环设计,提升系统可组合性、稳定性与成本效率。
258 0
Agent Graph Engineering:从线性 Workflow 到可扩展 Agent 系统
|
3月前
|
人工智能 机器人 开发工具
工程实践|Warp 的 Loop Engineering:Agent 如何自己改进 Skill?
Warp 团队提出“双循环驱动”AI Agent进化:内循环(Inner Loop)自动分诊GitHub Issue;外循环(Outer Loop)从人类反馈中提炼规则,生成PR更新技能文件(SKILL.md)。技能即SOP,可审查、可回滚、持续迭代,让Agent越用越懂团队。
350 1
工程实践|Warp 的 Loop Engineering:Agent 如何自己改进 Skill?
|
2月前
|
人工智能 缓存 测试技术
Harness 效应:编排设计如何影响企业级 Agent 的 Token 成本
论文《The Harness Effect》指出:企业级Agent成本主要由编排层(Harness)决定,而非模型单价。Harness通过优化上下文组织、历史压缩、工具调用与重试机制,将单任务Token消耗降低38%(14.2k→8.8k),成本下降33%–61%,CPM提升68%。优化本质是将成本问题从“选模型”转向“精设计”。
243 0
Harness 效应:编排设计如何影响企业级 Agent 的 Token 成本