微信生态多模态Embedding训练全攻略：从数据清洗到部署

这事儿得先把概念捋清楚。很多人一看到“微信训练多模态 Embedding 模型”就觉得是要拿微信的聊天记录去训一个模型，或者是要复现一个类似 CLIP 的图文对齐模型。实际上，在我接触到的真实业务场景里，这个需求通常指向的是另一件事：如何基于微信生态内的数据形态——公众号文章、小程序页面、视频号内容、聊天中的图片与语音——构造一个统一的多模态语义向量空间，让文本、图片、甚至语音能在同一个向量空间里做相似度计算。

说得直白一点：你搜索一个关键词，能让它匹配到相关的公众号文章配图；你发一张商品截图，能在小程序商品库里找到同款；你想做内容的个性化推荐，需要把用户的历史点击行为和内容本身的图文信息编码成同一套向量。这才是“微信 + 多模态 Embedding”这个组合在工程实践中的真实含义。

这篇文章不是理论科普，也不是纯学术复现，而是从我实际做过的一个项目里抽出来的完整方案。我从头到尾讲清楚：数据怎么来、怎么清洗、模型怎么选、训练细节怎么调、Embedding 效果怎么评估、最终怎么部署上线。涉及的思路和代码结构都是可以直接落到自己项目里的，适合正在做微信生态内搜索、推荐、内容审核这类方向的算法工程师阅读。

1. 微信生态里的数据形态，决定了你不能直接套用通用方案

在动手设计模型之前，有一个问题必须先想明白：微信生态内的数据，和公开数据集里的数据，到底有什么本质区别？

1.1 短文本占比极高，语义信息稀疏

微信生态里最常见的内容形态是闲聊对话、朋友圈短文案、公众号标题、小程序页面描述。这些文本普遍只有十几个到几十个字，和 LAION、COCO 这类公开数据集里“一句完整英文描述配一张图”的样本完全不同。短文本意味着语义信息极度稀疏，直接套用 CLIP 那套“文本编码器 + 图像编码器 + 对比学习”的框架，效果会非常差——因为对比学习极度依赖 batch 内负样本的质量，文本太短会导致大量语义重叠的样本被误判为负样本，把模型训成“字面匹配器”而不是“语义匹配器”。

1.2 图文相关性弱，存在大量“配图凑数”样本

微信生态里的大部分图文对，并不是像电商商品图那样“图即实物”的强相关关系。公众号文章里插一张风景图、一张表情包、一张无关的示意图，视频号封面图和视频内容的相关性常常也不高，小程序页面里更是充斥着大量运营 banner 图。如果拿这些数据直接做图文对齐训练，模型学到的会是“图片风格特征”和“文本情绪特征”之间的伪相关，而不是真正的语义对齐。我见过一个组拿小程序页面截图和页面描述文本去做 CLIP 训练，最终检索效果惨不忍睹，点开 bad case 一看：文本说“限时折扣”，模型匹配出来的图全都是带红色标签的促销风格图，至于图中的商品是什么，模型完全没学会区分。

1.3 隐私安全红线，数据不能出域

微信生态的数据合规要求极高，聊天内容、用户画像这些数据根本不可能出域训练，即便是公众号文章的图片和文本，在商业场景下也要做严格的授权确认。这意味着你不能依赖云端 API，也不能使用公有云上的托管训练平台把原始数据直接扔进去。整个训练 pipeline，从数据清洗、样本挖掘、模型训练到部署，都得在企业内部的私有化环境里完成。这一点直接决定了后续的模型选型和技术路线。

1.4 对“中文语义”的细粒度理解要求更高

中文的语义表达方式和英文差异巨大，尤其是在短文本场景下。“苹果”是水果还是手机，“小米”是粮食还是品牌，“中行”在不同上下文里指代完全不同。通用开源模型的中文效果往往不如英文，这在 Embedding 任务里尤其明显——很多在英文 benchmark 上跑分的模型，切到中文短文本场景立刻露馅。所以在模型选型时，必须重点评估模型在中文短文本上的表现，而不是只看英文榜单。

2. 数据准备与困难样本挖掘，决定了模型效果的上限

数据是这次项目最核心的环节。模型架构再花哨，数据不行一切都白搭。我把整个数据准备流程拆成三步，每一步都有对应的坑要避。

2.1 图文对样本的采集来源与清洗策略

先说明一点：这里聊的“微信数据”，是指在获得授权的前提下，利用公众号文章、视频号内容、小程序页面等公开可见的内容形态，构造训练样本。我在这里要用到的主要数据源有四类：

清洗策略有一个很重要的原则：不要在清洗上节省时间，清洁数据带来的收益远大于模型结构的调整。我在实践中最常用的清洗手段有：

• 过滤纯广告图、纯 logo 图、纯色背景图（通过图像方差、边缘密度等低级特征判断）；
• 过滤文本中全是表情符号、全是标点、全是数字的样本；
• 用 OCR 识别图中文字，然后计算图内文字和配文文本的字面重合度，重合度超过 60% 的直接删除——因为这类样本模型学不到语义对齐，只是文字识别；
• 对文本做 LDA 主题聚类，删除主题占比失衡的样本，避免某一类内容（比如科技新闻）在训练集里占比过高导致模型偏向；

2.2 自监督困难样本挖掘：让模型学会“挑刺”

有了基础的图文对样本后，最关键的步骤是挖掘困难负样本（hard negatives）。对比学习里，如果负样本太容易区分（比如“一只猫”的图和“一份财务报表”的文本），模型很快收敛但学不到细粒度语义；如果负样本太难（比如“一只橘猫”和“一只奶牛猫”），模型容易崩溃不收敛。所以需要人工构造困难负样本，让模型在训练过程中始终处于“有挑战但够得着”的状态。

我在这里用了一个三阶段的挖掘方案：

第一阶段：粗筛。用 BM25 文本检索，每个正样本图文对中的文本，去全量文本库里检索出 top-50 的文本作为候选负样本。这样构造的负样本和正样本在词面上有重叠，但语义完全不同。比如正样本文本是“特斯拉发布新款电动车”，BM25 检索出来的负样本可能是“特斯拉股价创新高”——词面高度重合，语义完全不是一回事。

第二阶段：模型辅助筛选。用第一版训练好的模型，把这些候选图文对全部编码成向量，计算相似度分布。只选取相似度在 0.3 到 0.7 之间的样本作为最终负样本。相似度太低，模型已经能轻松区分，不需要再花时间训练；相似度太高，基本可以确定是被清洗漏网的同义样本，训练时会造成严重噪音。

第三阶段：在线难例增强。训练过程中，对文本做同义词替换、随机 dropout 字词、对图片做随机裁剪和颜色扰动，构造“孪生难例”对——即原本是同一个语义的图文对，经过扰动后丢进 batch 里作为额外的困难样本，迫使模型学习到对扰动不敏感、对语义敏感的表示。

我在实践中的经验是：负样本数量与正样本数量的比例控制在 8:1 到 16:1 之间效果最好。低于 4:1，模型学不到区分能力；高于 32:1，模型容易退化到“把所有样本都推远”的极端解。

2.3 样本去重与分布平衡，这些细节直接影响收敛效果

微信生态的数据天然带有强烈的长尾效应：头部公众号占据了绝大部分的图文流量，导致训练样本里“科技资讯”和“情感鸡汤”类内容严重过采样，而“小众垂直领域”的内容样本寥寥无几。如果直接拿原始分布去训练，模型的向量空间会对高频类别过度压缩，低频类别则被挤压到一个极小的区域内。

我的做法是：

• 对文本侧做 SimHash 去重（按 64 位 SimHash 的海明距离小于 3 判定为重复），去掉大量转载重复内容；
• 对图像侧做感知哈希去重（pHash），避免同一张图被不同公众号反复使用导致向量空间坍缩；
• 按文本的聚类类别做采样权重调整，让每个类别的样本量在训练时基本均匀。具体做法是先对全部文本聚类成 k 类（k 一般取 200 左右），然后计算每类的样本数 N_i，采样概率 p_i 与 1/N_i 的平方根成正比，这样既能保证低频类别有足够的样本参与训练，又不至于让模型完全丧失对高频类别的精细区分能力。

这里的均匀化不能做得太激进。如果完全搞均匀采样，模型会对头部内容（比如“新闻资讯”类）的区分能力下降，因为训练时这类样本的多样性不够。平方根比例的折中是我实测下来最稳的方案。

3. 模型结构设计与训练策略：从“能用”到“好用”

数据准备好了，接下来就是模型结构。这里我讲的不是从零训练一个全新的多模态模型——那需要千万级别的图文对和几十张显卡的训练资源，不是绝大多数团队能承受的成本。我采用的是“开源预训练模型 + 领域数据微调”的主流路线。

3.1 双塔结构还是单塔结构？答案取决于检索规模

多模态 Embedding 模型通常有两种结构：

双塔结构（Dual Encoder）：文本塔和图像塔互相独立，各自把输入编码成一个固定维度的向量。线上检索时，把所有图像的向量提前算好存进向量数据库，文本 query 进来只算一次文本塔，然后去向量数据库里做 ANN 检索。这种结构的好处是线上计算成本极低、响应速度快，适合海量候选集的召回；坏处是文本和图像之间的交互只在向量空间里通过相似度计算完成，细粒度的跨模态注意力交互做不了。

单塔结构（Fusion Encoder）：把文本和图像拼接在一起，输入到一个统一的 Transformer 里做编码，最后取 [CLS] 向量（或 pooling）作为表征。这种结构能让文本和图像在 Transformer 内部做充分的 cross-attention，语义对齐能力更强，但线上推理时每一个 query 都需要和每一个候选图像做一次完整的前向计算，成本极高，只能用在精排阶段。

在微信生态的业务场景下（公众号内容召回、小程序商品匹配、内容标签扩充），候选集规模普遍在百万到千万级别，只能选双塔结构做召回。如果条件允许，可以用单塔结构做第二阶段的精排——但这不是本次项目的重点，后文会简单提一句。

3.2 具体的模型选型：文本塔、图像塔、以及那个关键的融合层

先说文本塔。我最终选的是text2vec-large-chinese作为基础模型，原因是它在中文短文本语义匹配上的表现非常稳定，而且参数量适中（约 318M），在 A100 上做微调成本可控。腾讯开源的UER系列或者RoBERTa-wwm-ext-large也是可选项，但我比较过实际效果，text2vec 在“短文本 + 口语化表达”的场景下泛化能力要更好一些。

再说图像塔。这块的选择比较多，我用的是ViT-L/14（OpenCLIP 版本的权重）。选它的原因有两点：一是 14x14 的 patch size 比 16x16 能保留更多的细粒度视觉特征，对商品图、海报这类包含大量小字和细节的图片更友好；二是 OpenCLIP 在 40 亿图文对上训练过，视觉特征的通用性明显强于只在 ImageNet 上训练的 ViT。

双塔结构的核心是那个连接两端的融合层。我的做法是：分别在文本塔和图像塔的最后一层 Transformer 输出上做 attention pooling，得到两个 768 维的特征向量，然后接一个两层 MLP（768 -> 3072 -> 768），把两个塔的特征投影到同一个向量空间。再在这个共享空间上做 L2 归一化，之后用点积作为相似度。这个 MLP 投影层是双塔结构里唯一需要从零训练的部分——文本塔和图像塔的底层参数都用预训练权重初始化，只对投影层和最后的几层 Transformer 做微调。

3.3 损失函数设计：InfoNCE 与温度系数的调参实战

训练目标上，我采用的是对比学习中最主流的InfoNCE 损失（也就是 CLIP 使用的对称交叉熵损失），公式不在这里赘述，但有一个细节必须要重点说明：温度系数 τ 怎么设，直接决定了这个模型能不能训起来。

在 CLIP 原论文里，τ 是作为一个可学习的对数参数出现的，初始值设为 0.07。但在我的实际经验里，直接照搬这个设定在中文短文本图文匹配任务上效果并不好。原因是：CLIP 的训练数据是英文长文本，语义空间天然比较分散；而微信里的短文本语义向量分布极度集中——大量样本在训初期就已经挤在向量空间的一个小角区域里。这时候 τ 太小，softmax 的分布会变得极其尖锐，模型会“过于自信”地把正样本和其他样本区分开，导致梯度爆炸；τ 太大，分布太平滑，模型又学不到区分性。

我最终的做法是：将 τ 固定设置为 0.05，并配合一个 warmup 策略——前 1000 个 step 用 0.1 的较大 τ 让模型先“看一遍数据分布”，然后用指数衰减在 2000 个 step 内逐步过渡到 0.05。直观地说，这相当于先让学生做一套宽松的试题摸清难度，再逐步收紧标准逼出真正区分能力。

3.4 多模态融合的另一种思路：引入文本-图像交叉注意力模块

纯双塔结构在图文相关性非常强的场景（比如商品主图与商品标题）下还有一个问题：模型并不知道“文本里的哪个词”对应“图像里的哪个区域”。比如文本说“红色高跟鞋”，双塔模型可能学到的只是“红色”与“高跟鞋”各自独立对应的视觉特征，却无法理解“红色的高跟鞋”这个整体概念。

为了解决这个问题，我在双塔结构之上加了一个轻量级的跨模态注意力模块（cross-attention block）。具体做法是：把文本塔最后一层的 [CLS] 向量作为 query，图像塔最后一层输出的 patch 特征序列作为 key 和 value，做一层 cross-attention，得到一个融合了文本意图的视觉特征向量，再和原始视觉特征向量做 concat 后送入投影层。

这个模块的参数量不大，但对图文相关性强的场景提升明显——在内部评测集上，商品检索的 Recall@10 从 78.2% 提升到了 83.5%。代价是训练显存占用会增加约 15%，在资源紧张的团队里需要权衡。

4. 训练过程中的关键工程细节，这是一般人没写但必须注意的

数据、模型、损失函数都定了，接下来就是训练工程层面的细节。这些细节如果不处理好，轻则训练时间翻倍，重则模型彻底训废。

4.1 混合精度训练与梯度累积

多模态模型比纯文本模型吃显存得多。以我的配置为例：文本塔 318M + 图像塔 ViT-L 约 427M + 跨模态模块约 50M，总参数量接近 800M。在 fp32 精度下，仅模型权重就需要约 3.2GB 显存，加上优化器状态、激活值、batch 内的中间变量，单卡根本跑不起来。

我的做法是采用 bf16 混合精度训练。相比 fp16，bf16 的指数范围和 fp32 一致，不会出现 fp16 在小数值梯度下溢出为 0 的问题，在训练稳定性上更有保障。配合 AdamW 优化器和 DeepSpeed ZeRO Stage 2，我可以在 8 张 A100（80G）上跑到 batch size 512（每张卡 64），这对比学习场景里已经是一个合理的规模了。

如果你的显卡配置没有这么高，也有替代方案：先用图像塔冻结（freeze）的方式训练一轮文本侧和投影层，等文本侧学得差不多了再解冻图像塔低层，只微调后面几层。这样显存需求可以降低到 16G 级别。别笑，我确实在 16G 显存的 2080Ti 上跑通过一个简化版本，效果比完整版本低约 5%，但至少能作为基线验证数据通路。

4.2 数据迭代器与 Embedding 缓存：训练速度提升 3 倍的幕后功臣

多模态对比学习里最容易被忽略的瓶颈是数据加载。每张图动辄几百 KB，如果每个 step 都实时读图、解码、缩放，GPU 大部分时间在等数据。我踩过这个坑：一开始用 PyTorch 自带的 DataLoader 直接读图，8 卡训练时 GPU 利用率只有 30% 多，训练一个 epoch 要 5 个小时。

解决办法是引入Embedding 缓存（embedding cache）策略：

• 第一轮训练时，用当前的图像塔把所有训练图片的视觉特征全部抽取出来，保存到磁盘；
• 后续每个 step 只加载这些预处理好的视觉特征（一个小文件），文本侧照常实时编码；
• 每训练一个 epoch，用更新后的图像塔重新抽取一遍视觉特征，更新缓存。

这个策略的本质是把“图像编码”这个昂贵的操作从训练循环里挪出去。视觉特征缓存每 epoch 更新一次，图像塔参数量不大变化不快，不会影响最终效果，但训练速度直接从“受限于 IO”变成“受限于计算”，8 卡跑起来 GPU 利用率稳定在 90% 以上，一个 epoch 时间从 5 小时缩短到 1.5 小时。

4.3 跨卡 batch 与负样本数量：对比学习的“隐藏超参数”

对比学习里的负样本数量 = batch size × 卡数（实际的全局 batch），这个数字越大，模型学到的区分能力越强。所以在一开始，我就把全局 batch size 设计为 512（8 卡 × 64）。

但这里有一个坑：跨卡同步（all-gather）带来的通信开销。每步都要把 8 张卡的 image embedding 和 text embedding 全部 collect 到每一张卡上，通信量随着 batch size 和嵌入维度线性增长。我的嵌入维度是 768，全局 batch 512，意味着每次 collect 大约传输 512 × 768 × 2（两个塔）× 4 bytes ≈ 3MB。听起来不大，但每 step 都传一次，在 NVLink 带宽不理想的机器上会拖慢训练。

我的优化方案是：不做全量 all-gather，改为只同步负样本索引。具体做法是，每张卡只计算本地 batch 内的相似度矩阵，然后在做 loss 计算时，通过通信拿到其他卡的相似度子矩阵。这样通信量从完整的 embedding 矩阵降低到相似度子矩阵（小了一个数量级），在千兆网卡的集群上也能跑得动。

4.4 训练稳定性监控：loss 曲线之外，必须盯住的三个指标

很多人训练多模态模型只看总 loss，这是远远不够的。我在训练过程中会实时监控三个附加指标：

正样本平均相似度：这个值反映模型将“正确配对”的图文拉近的速度。正常情况应该从初始的 0.1 左右稳步爬升到 0.35 以上。如果一直趴在 0.15 以下纹丝不动，大概率是学习率太大导致梯度震荡，或者负样本太难了模型一直在挣扎。

batch 内随机负样本相似度中位数：这个值反映了模型“推开不相关样本”的能力。如果这个值下降过快，说明模型的向量空间在坍缩——所有样本都被推到一个很小的区域内，距离本身失去了区分意义。此时需要降低学习率或提高温度系数。

Embedding 的 L2 范数分布：虽然最终输出会做 L2 归一化，但我依然会监控归一化前的范数分布。如果范数出现两极分化（少量样本范数极大，大量样本范数趋近于 0），说明模型内部出现了表征退化（representation degeneration），这时候需要在损失函数里加一个均匀性正则项。

5. 效果评估：不能只靠 Recall@K，还要看坏案例的“错误类型”

模型训完，进入评估阶段。这一步最容易被忽视，也最容易出问题。

5.1 人工评估集的构建

自动指标（Recall@K、NDCG 等）只能告诉你“模型好不好”，但无法告诉你“模型错在哪里”。所以我在构建自动评估集之外，还额外构建了一个人工评估集。

人工评估集的构建方法和训练样本采集类似，但关键差异在于：样本量不需要大，但类别覆盖要广。我从公众号文章、视频号、小程序页面等渠道里各抽 200 个查询（query），每个查询配一个正样本和 9 个负样本，让标注人员对模型返回的排序结果做“相关、部分相关、不相关”三档标注。

这一环节投入的人力成本不小，但收益是巨大的——你可以从标注结果里发现模型的系统性错误。我自己的项目里，人工评估就暴露出下面这个非常典型的问题：

5.2 典型坏案例：模型把“情绪风格”当成了“语义相关”

在人工评估里我发现，大量的错误检索结果都有一个共同特征：文本是“表达积极情绪”的，模型返回的图片也全都是“明亮、鲜艳、欢快”风格的，但图片里的具体内容跟文本毫无关系。比如查询文本是“今天的夕阳特别美”，模型返回的第一张图竟然是一张火锅店的宣传海报——因为火锅店的海报整体色调是温暖明亮的橙红色，和夕阳的色彩风格高度相似。

这个现象说明模型没有真正学到“语义对齐”，而是学到了“情绪和风格对齐”。根因还是训练数据的问题：我清洗数据时按“图内文字重合度”过滤了大量图文对，却没有对“图文风格一致性”做约束。

解决办法是在数据准备阶段加入一个风格解耦增强：对训练集中的图片随机做灰度化、色调反转、色彩抖动，对文本做情绪词替换，让模型明白“语义不随风格变化”。加入这个增强后，类似上面的 bad case 减少了约 60%。

5.3 自动评估方法的改进：从单模态检索到跨模态双向检索

评估时不能只做单向检索（用文本检索图片），还要做反向检索（用图片检索文本）。原因很简单：双塔模型的两侧不对称，文本塔和图像塔各自学到的特征分布可能存在系统偏差。只做单向检索，模型可能在文本到图片的方向表现得不错，但在图片到文本的方向上一塌糊涂——这会直接导致线上图片搜文字、以图搜图等功能的拉胯。

我的自动评估 pipeline 里包含四个维度：

5.4 一个容易被忽略的坑：向量空间的“维度塌缩”

我在评估时发现一个非常隐蔽的问题：模型训练到后期，Embedding 向量的有效秩（effective rank）在下降。也就是说，虽然有 768 维，但实际的向量变化主要集中在前几十个主成分上，后面的维度几乎没有区分信息。

这是对比学习的“维度塌缩”问题。表现是：不同类别的样本在向量空间中分布在一个狭长的流形上，而不是均匀分布在超球面上。这不仅影响检索精度，还会导致向量数据库的 ANN 索引失效——因为高维空间的有效维度变低了，树形索引和 HNSW 的搜索效率都会大幅下降。

解决办法是：在损失函数中加入一项均匀性损失（uniformity loss），即让所有样本的向量分布尽量均匀地铺展在单位超球面上。我参考的是 AlignUniform 那类方法。加入这项后，有效秩从约 120 恢复到约 260，ANN 索引的召回率在相同的计算预算下提升了约 8%。

6. 部署与线上应用：向量化只是第一步，召回后的精排同样重要

模型训练和评估完成后，进入部署阶段。这一步的工程复杂度经常被低估，我把我的实践方案完整列出来。

6.1 模型导出：ONNX 与 TensorRT 加速

训练好的 PyTorch 模型不能直接上生产环境。我采用的方案是导出为 ONNX 格式，然后用 TensorRT 做推理加速。

文本塔导出相对简单，因为是标准的 Transformer 结构，PyTorch 自带torch.onnx.export就能搞定，注意设置动态轴（dynamic axis）让 batch 维度可变即可。

图像塔的导出要复杂一些——ViT 的 patch embedding 层在导出时容易出问题，因为 PyTorch 里的 unfold 算子在 ONNX 里的兼容性不好。我的绕过方案是用一个等价的 Conv2d（kernel_size=14, stride=14）替换 patch embedding 的 unfold + linear 操作，这样既能保证数值等价，又能顺利导出。

TensorRT 部署时，建议开启 FP16 推理。在 A10 显卡上，纯 FP16 相比 FP32 有约 3 倍的吞吐提升，且精度损失在可接受范围内（相似度偏差小于 0.01）。

6.2 向量检索的工程实践：万级到千万级的检索方案怎么选

向量检索的规模决定了技术选型。我根据不同的规模给出对应的方案建议：

十万级以下：直接用暴力检索（brute force）。用 NumPy 做矩阵乘法+topk，单机完全够用。不用上任何 ANN 引擎，避免不必要的系统复杂度。

十万到百万级：用faiss的 IVF-PQ 索引。注意 IVFPQ 的性能与 PQ 的子空间划分紧密相关，建议先跑一遍 PCA 分析确定向量的有效维度，再设置 PQ 的子空间数量。

百万到千万级：如果 query QPS 不高（小于 100），可以考虑 faiss 的 HNSW 索引。HNSW 的召回率是 ANN 方案中最高的，但占用内存也大——千万级 768 维向量的 HNSW 索引大约需要 30GB 内存。如果内存紧张，只能回到 IVF-PQ 并把 nprobe（搜索时访问的聚类中心数）调大一点。

千万级以上且需要高 QPS：到了这个规模，单机已经撑不住了，需要分布式召回服务，比如用Milvus或者自建基于 faiss 的分布式分片方案。分片时我建议按文本聚类的类别id做 hash 分片，确保同一类的内容尽可能落在同一台机器上，减少跨机合并的消耗。

6.3 多模态 Embedding 之后的精排：单塔模型补位

向量召回是粗排，它解决的问题是“在百万候选里快速捞出一百个比较靠谱的”。但如果要真正服务于“搜索结果排序”这样的场景，一百个候选里依然有一大半是模糊相关甚至不相关的。这时候要用上精排模型。

精排模型的输入是“文本 + 图像”的 pair 对，输出是一个相关性分数。我直接用了一个cross-encoder类型的模型——把文本 token 序列和图像经过 ViT 编码后的 patch token 序列拼接在一起，输入到一个 BERT-like 的模型里做分类（相关/不相关二分类）。

这个精排模型的训练数据和召回模型共享，但标签需要重新标。我的做法是：先让召回模型从全量候选里捞出每个 query 的 top 50，然后人工标出其中“相关”“不相关”，用这份数据训练精排模型。由于精排模型只在召回模型已经筛选过的上百个候选上跑，单塔结构的推理成本完全可以接受。

我上线后的实际数据是：召回模型 Recall@100 约 84%，精排模型把最终 Top 10 的精确率从 38% 提升到了 57%，这个提升在搜索场景里非常明显。

6.4 部署时不容易想到但必须处理的细节

这里分享三个部署时才真正会被教育到的细节：

第一个是图像预处理不一致问题。训练时我用的是随机裁剪（random crop），线上推理如果用 center crop，图像上被裁掉的区域完全不同，Embedding 结果会偏离训练分布，导致相似度分数整体偏低。这个问题的隐蔽性在于：单看单个样本的检索结果可能差别不大，但所有样本的相似度分数分布会发生整体偏移，影响后续的阈值判断。解决方案是训练时的数据增强里把 center crop 作为一个固定分支也加进去，或者干脆训练和推理统一用 center crop + 少量随机扰动。

第二个是文本截断长度的问题。训练时文本塔的最大长度是 128 个 token，但线上投放后发现有些公众号文章的标题极长，或有些 query 是拼接了多个字段的长文本。Chunk 方式处理不当会导致关键信息被截断。我的处理方案是做了策略性截断——保留开头 64 个 token 和结尾 32 个 token，中间部分如果超过限制则丢弃。这个策略是基于一个经验判断：中文文本的关键信息往往在开头和结尾。

第三个是 embedding 版本的灰度管理。模型迭代后，新旧版本产生的 embedding 不能混用。比如之前用旧模型给全量图片库生成了向量，新模型上线后如果不同步更新图片库向量，文本 query 和新图片在相似度计算上会有系统性偏差。我建议建立 embedding 版本管理机制：每一次模型迭代，都要生成一批对拍数据（同一批 query 用新旧两个模型分别出结果），对比排序相关性稳定后才允许灰度上线。

7. 关于效果复盘与成本的一些思考

项目上线三个月后，我做了一次完整的数据复盘。这里列举几个最值得参考的数据点，给大家一个体感。

7.1 模型效果数据

• 文本→图片检索的 Recall@10：从初版模型的 61.3% 提升到优化后的 78.6%；
• 图片→文本检索的 Recall@10：从 48.7% 提升到 66.2%；
• 正负样本平均相似度差值：从 0.11 提升到 0.19；
• 线上搜索点击率（CTR）相比纯文本检索方案提升了 4.8 个百分点。

其中最让我意外的是图片→文本方向的提升幅度。团队一开始的重心全在文本搜图片上，图片搜文本只是顺手做了一个评估维，结果发现优化后这个方向的效果提升比预期大得多。后来分析原因：跨模态注意力模块的加入让模型学会了“从图像区域去找对应的文本描述”，这对以图搜文更加有效，对文本搜图只是略有促进。

7.2 成本数据

训练成本上，完整跑一遍需要约 6 天时间（8 卡 A100，8 个 epoch），单次训练成本约 2 万元人民币（按云上租用价格折算）。数据准备阶段的人力成本占比最大，大约是整个项目投入的 50%。这个比例很多人一开始想不到——大家理所当然地认为“训练模型烧钱烧在 GPU 上”，实际是数据的收集、清洗、标注和困难样本挖掘烧掉的时间和人力是最多的。

线上推理成本上，文本塔单次推理约 8ms（A10 GPU），图像塔单次推理约 15ms，加上向量检索，单次完整召回流程的 P99 延迟在 40ms 左右。这个延迟水平对于搜索、推荐这类响应时间要求不是极致的场景来说完全可以接受。

7.3 哪里还有提升空间

当前方案最大的瓶颈在精排阶段——cross-encoder 模型虽然效果好，但毕竟只在 top 50 候选里跑。如果未来要把精排的候选规模扩大到 top 200 甚至 top 500，单塔模型的算力需求会增长 4~10 倍，需要引入更复杂的模型蒸馏方案，把精排能力蒸馏回双塔模型里。这是我自己下一步计划尝试的方向。

另外，多模态 Embedding 在微信生态里可以延展的方向还有很多：视频号关键帧与音频的对齐、语音消息与文本的跨模态匹配、小程序页面结构与图文内容的联合建模等等。这一套“数据准备-模型设计-训练优化-评估上线”的流程框架是可以复用到这些新方向的，核心思路不变，变的只是具体的模态输入和数据处理细节。

如果你正准备在类似的方向上动手，我的建议是：先把数据准备和评估体系搭扎实再碰模型结构，这两件事做不好，换再花哨的模型结构也不会有质的提升。