1. 微信场景下的多模态 Embedding到底在解决什么问题先说个我在实际落地中反复被问到的点多模态 Embedding 不是把一张图和一段文字丢进同一个模型然后拼个向量就完事。微信这种体量的产品每天产生的是视频号里的短视频、公众号图文、朋友圈状态、小程序商品、聊天中随手发的图片和语音这些内容之间天然存在跨模态的语义关联。用户可能搜一张靴子的图片实际想找的是公众号里那篇穿搭攻略用户可能在视频号刷到一个做菜片段转头就想搜同款食材的图文教程。这种“用 A 模态表达、要 B 模态结果”的需求在微信里太常见了。所以多模态 Embedding 的核心目标是把不同模态的内容统一映射到同一个向量空间里让图片、文本、视频帧、音频片段之间的相似度可以计算、可以比较、可以检索。模型输出的向量质量直接决定了搜索排序、推荐召回、内容去重、素材库管理的效果上限。如果向量空间没对齐后面做什么都白搭。再说说适用人群。这篇文章不是写给只看理论的人看的而是给那些真正要动手训练模型的人。我假设你有一定的 PyTorch 使用基础跑过一些简单的 CV 或 NLP 模型但还没有完整做过一个多模态对比学习的训练管线。文章里我会聊聊在 16G 显存这种常见的单卡环境下怎么把模型训起来、怎么构造训练数据、怎么处理 batch 内负样本、怎么评估向量质量以及我在实际项目中踩过的那些文档里不会写的坑。训练多模态 Embedding 本质上是个工程问题不完全是算法问题。你需要的不是一篇顶会论文复现而是一套能落地、能迭代、能上线的方案。2. 方案选型为什么我不推荐一上来就上多模态大模型训练这块最常见的误区就是“哪个模型强用哪个”。网上热词里总看得到“16g显存多模态模型推荐”“多模态大模型”这类搜索词很多人上来就想微调一个 Qwen2-VL 或者 LLaVA 这类大模型来产出向量。我的看法很直接除非你的业务场景极其复杂否则这是个性价比很低的做法。2.1 Embedding 模型和生成式多模态模型的本质差异生成式多模态大模型的目标是理解并生成内容它的输出是 token 序列内部表示虽然包含语义但它的设计目标不是为了产生一个紧凑、可比较的向量。你要用它做检索还得专门抽取倒数第二层的隐状态然后在上面再接 pooling 层再做 normalization效果还不一定好。因为大模型在训练时并没有被显式地约束“相似的输入要映射到相近的向量”它学到的表示是任务驱动的不是度量驱动的。而 Embedding 模型则不同它的核心是度量学习。训练目标就是让正样本对比如一张靴子图和它的标题文本在向量空间里距离近让负样本对距离远。整个网络结构的设计、损失函数的选择、样本构造的方式全部围绕向量空间的对齐展开。2.2 在 16G 显存下我推荐的结构组合我的建议是采用双塔结构Two-Tower而不是单塔融合。图像塔用 CLIP/ViT 系列的视觉编码器文本塔用 BERT 或者更轻量的 Sentence-BERT 结构两个塔的输出投影到同一个 512 维或 768 维的向量空间然后通过对比学习拉近正样本。这套方案在显存占用上非常友好。以我的实测经验在 16G 显存的单卡上图像塔用 ViT-B/16大约 86M 参数文本塔用 6 层 BERT约 66M 参数投影层用两层 MLP输入图片分辨率 224x224文本长度截断到 64 tokenbatch size 可以开到 256配合混合精度训练显存占用大概在 11G 到 13G 之间还有余量做梯度累积。如果换成 ViT-L/14batch size 就要降到 64 左右否则会直接 OOM。这里有一个很关键的设计两个塔的输出向量必须经过 L2 归一化再做相似度计算。原因不复杂归一化之后向量内积就等于余弦相似度值域固定在 [-1, 1]配合温度系数缩放训练会稳定很多。很多人训练的时候不归一化向量模长分布不一致损失值波动很大那个坑我踩过。2.3 什么时候才需要考虑更大的模型有一个常见的热搜词是“多模态融合算法”这个方向确实是前沿但在训练 Embedding 模型的场景下我建议你先问自己三个问题业务是否需要细粒度的跨模态对齐比如像素级别的图文对应现有双塔召回的指标是否已经到达瓶颈你有多少标注数据如果数据量不足十万对双塔结构已经足够如果检索精度不够优先排查的应该是负样本挖掘和难例挖掘而不是换更大的模型。我在项目里见过太多人花两周去微调一个大模型最后 recall 只提升了 0.5%而调整损失函数里的温度系数和难负样本策略一夜之间涨了 3 个点。当然如果是离线分析场景或者想做多模态内容生成那大模型有它的价值。但做检索召回Embedding 模型是更精准的武器。3. 数据构造微信场景下的图文对、难负样本与滑动窗口策略数据是整个训练管线里最耗时间、也最决定上限的部分。一个多模态 Embedding 模型的效果不是看网络结构有多花哨而是看喂进去的图文对质量有多高。这点在微信的业务场景里尤其明显因为用户产生的数据噪音非常大。3.1 图文对的来源与清洗对于微信生态常见的数据来源有三类。第一类是公众号文章的配图和标题、段落文本。一篇文章里的多张配图和周围文本天然构成弱相关的图文对这里需要做位置窗口过滤一般来说取图片前后各 200 字以内的文本超出窗口的文本大概率跟图没什么关系。第二类是视频号的视频帧和封面标题抽帧频率建议每 2 秒一帧然后和该片段的字幕对齐。第三类是朋友圈的图片和文案这类数据噪音最大因为用户发文案很随意经常是“今天天气真好”配一张自拍这种图文对信号非常弱我一般会先过滤掉所有短文案字数小于 15 的。数据清洗里面有一个容易被忽略的问题重复图片。用户在不同时间发的同一张图比如一张表情包反复用在数据集中会形成大量近乎重复的样本。如果不做去重模型会把这些图片的向量聚集在一起导致检索结果被表情包霸屏。我处理的方法是从数据里随机抽样一部分图片用预训练的 CLIP 模型离线提取特征然后做局部敏感哈希LSH粗筛再对候选集计算精确相似度把相似度大于 0.95 的合并成一组只保留最早出现的样本。这一步能去掉大约 20% 到 30% 的重复数据。3.2 难负样本的挖掘机制对比学习训练中负样本的选择决定了模型能学到多精细的区分能力。如果负样本都是些“靴子和汽车”这种明显不相关的模型学到的只是粗粒度的语义差异它分不清“靴子和高跟鞋”的差别。这就是难负样本挖掘要解决的问题。我的做法是三阶段挖掘。第一轮先用一个预训练的 CLIP 模型作为初始化跑一遍全量数据的向量检索对每个正样本图文对找出“文本描述相近但配图完全不同”的图文对以及“图片相近但文本描述完全不同”的图文对作为困难负样本。第二轮在训练进行到一半时冻结模型权重重新对训练集做一次向量检索用“当前模型认为难分但实际上是负样本”的样本替换掉一部分上一轮的难负样本。第三轮是动态难负样本挖掘每个 batch 内除了常规的 in-batch 负样本外还会从一个小规模的难负样本池里在线采样把它们也拉进这个 batch 参与计算。这个机制说起来不复杂但工程实现上有几个细节值得注意。难负样本池不能太大我习惯控制在训练集总量的 2% 左右太大了每次采样会有 IO 压力太小了覆盖度不够。每训练 500 步左右就重新挖掘一次不要每个 epoch 都挖那会训练到过拟合困难的样本上。3.3 滑动窗口滤波在训练数据预处理中的角色热词里出现了“滑动窗口滤波模型”这本来是一个信号处理的术语但我觉得它用在图文序列对齐上非常贴切。在视频场景里一段视频的不同帧和语音文本存在时序对应关系如果用全局匹配容易把文字和毫无关系的画面配对。我的做法是设定一个 3 秒到 5 秒的滑动窗口在窗口内计算视频帧特征和文本特征的相似度保留相似度最高的那对作为正样本窗口滑动步长设置为 1 秒允许相邻窗口之间存在重叠。这样做的好处是即使视频画面切换很快文本和画面的对齐关系也能保持稳定。对于图文对来说同样可以用滑动窗口的思路来处理长文本和长图片序列。当一篇公众号文章包含多张配图时我会在文章中按照位置滑动一个 300 字左右的窗口每个窗口只和距离最近的配图建立潜在匹配关系然后再通过 CLIP 模型初筛把分数达到阈值的窗口-配图对纳入训练集。这个策略简单有效能大幅减少弱相关图文对的引入。4. 训练细节与完整流程数据准备好之后就到了最核心的环节——模型训练。这一节我会按照实际操作的顺序从损失函数的选择、batch 配置、训练脚本到 16G 显存的优化把完整流程过一遍。4.1 损失函数与温度系数多模态 Embedding 训练最常用的损失函数是 InfoNCE或者叫 NT-Xent 损失。这个损失函数的直觉理解是这样的你有一批图文对比如一个 batch 里有 256 张图和对应的 256 段文本对每一张图来说正确的文本是它在 batch 里的匹配项其他 255 条文本都是负样本对每一段文本来说同理。然后模型要最大化正样本对之间的相似度同时最小化负样本对之间的相似度。公式我不展开推导了但有个参数你必须重点调温度系数temperature。它控制模型对负样本的“狠心程度”。温度越低模型越关注那些相似度高的难负样本区分粒度越细但容易训练不稳定温度越高模型对负样本的惩罚越宽松训练稳定但区分能力弱。常见设置是 0.07 或 0.1我在微信场景的数据上实测0.05 到 0.08 这个区间效果最好。代码实现上PyTorch 里可以直接基于 cosine similarity 计算我不建议手动写循环用矩阵运算一次性算完。下面是我常用的一个简化版 InfoNCE 实现batch size 为 N特征维度为 dimport torch import torch.nn.functional as F def info_nce_loss(image_embeds, text_embeds, temperature0.07): # image_embeds: [N, d], text_embeds: [N, d] # 两个嵌入都已经是 L2 归一化后的 # 计算图文相似度矩阵 [N, N] logits image_embeds text_embeds.T / temperature # 对角线是正样本构造标签 labels torch.arange(logits.shape[0], devicelogits.device) # 计算双向损失图片到文本、文本到图片 loss_img F.cross_entropy(logits, labels) loss_txt F.cross_entropy(logits.T, labels) return (loss_img loss_txt) / 2这个实现里有几个细节注意。logits 矩阵的 shape 是 [N, N]在 batch 为 256 时这是一个 256x256 的矩阵显存开销很小但计算量不小所以 batch 大小受限的主要是双塔的前向计算而不是对比损失本身。我习惯把梯度的计算放在两个方向上也就是对称损失。为什么因为一个 batch 里图片到文本的匹配和文本到图片的匹配难度往往不对称对称损失能让模型双向对齐都学到。4.2 完整的训练脚本结构下面是我实际用来跑训练的一个骨架脚本。它不完整但包含了最核心的训练循环、混合精度、梯度累积和日志输出你可以直接在这个基础上改造。import os import argparse import torch from torch import nn from torch.cuda.amp import autocast, GradScaler from torch.utils.data import DataLoader from torch.optim import AdamW from torch.optim.lr_scheduler import CosineAnnealingLR from transformers import CLIPVisionModel, BertModel from dataset import WeChatMultimodalDataset from losses import info_nce_loss def parse_args(): parser argparse.ArgumentParser() parser.add_argument(--batch_size, typeint, default256) parser.add_argument(--lr, typefloat, default2e-5) parser.add_argument(--epochs, typeint, default10) parser.add_argument(--temperature, typefloat, default0.07) parser.add_argument(--accum_steps, typeint, default1) parser.add_argument(--output_dir, typestr, default./checkpoints) parser.add_argument(--grad_clip, typefloat, default1.0) return parser.parse_args() def main(): args parse_args() # 双塔模型 image_encoder CLIPVisionModel.from_pretrained(openai/clip-vit-base-patch16) text_encoder BertModel.from_pretrained(bert-base-chinese) # 投影层把各自维度映射到 512 维 img_proj nn.Sequential( nn.Linear(image_encoder.config.hidden_size, 1024), nn.GELU(), nn.Linear(1024, 512) ) txt_proj nn.Sequential( nn.Linear(text_encoder.config.hidden_size, 1024), nn.GELU(), nn.Linear(1024, 512) ) model nn.ModuleDict({ image_encoder: image_encoder, text_encoder: text_encoder, img_proj: img_proj, txt_proj: txt_proj }) model.cuda() train_dataset WeChatMultimodalDataset(...) train_loader DataLoader( train_dataset, batch_sizeargs.batch_size, shuffleTrue, num_workers8, drop_lastTrue, pin_memoryTrue ) optimizer AdamW(model.parameters(), lrargs.lr, weight_decay0.02) scheduler CosineAnnealingLR(optimizer, T_maxargs.epochs * len(train_loader)) scaler GradScaler() global_step 0 for epoch in range(args.epochs): for batch in train_loader: images batch[image].cuda() texts batch[text].cuda() attention_mask batch[attention_mask].cuda() with autocast(): img_feats image_encoder(pixel_valuesimages).pooler_output txt_feats text_encoder(input_idstexts, attention_maskattention_mask).pooler_output img_embeds F.normalize(img_proj(img_feats), dim-1) txt_embeds F.normalize(txt_proj(txt_feats), dim-1) loss info_nce_loss(img_embeds, txt_embeds, args.temperature) loss loss / args.accum_steps scaler.scale(loss).backward() if (global_step 1) % args.accum_steps 0: scaler.unscale_(optimizer) torch.nn.utils.clip_grad_norm_(model.parameters(), args.grad_clip) scaler.step(optimizer) scaler.update() optimizer.zero_grad() scheduler.step() if global_step % 100 0: print(fEpoch {epoch} | Step {global_step} | Loss: {loss.item():.4f}) global_step 1这个脚本看起来不复杂但每个部件背后都有讲究。比如为什么用 CLIPVisionModel 而不是直接用 torchvision 的 ResNet因为 CLIP 的视觉编码器本身经过大规模图文对比学习预训练做初始化起点比 ImageNet 分类预训练的 ResNet 好得多收敛速度快最终效果也明显更好。文本塔为什么用 BERT因为在中文场景下BERT 类模型的语义理解能力比轻量模型稳定如果你还要同时支持英文内容可以直接换成 XLM-RoBERTa不需要改结构。4.3 16G 显存的优化策略与实测配置很多朋友一看到 batch size 256第一反应是“我显卡不够”。别急16G 显存完全够用关键是做好三件事混合精度、梯度累积、梯度检查点gradient checkpointing。混合精度我用的是 torch.cuda.amp 自带的自动混合精度脚本里已经写了。这套机制的原理一句话总结前向和反向计算中对显存占用大的部分用 FP16对数值敏感的部分比如 loss 缩放保持在 FP32。实测下来训练速度能提升大约 40%显存占用能降低 30% 到 40%。梯度累积解决的是“batch 小了负样本不够”的问题。如果你的卡只能跑 batch size 32那就在 8 步中累积梯度等价于一个 256 的 batch。这里有个关键细节累积梯度时loss 需要除以累积步数。脚本里已经写了 loss loss / args.accum_steps这一步很多人会忘忘掉之后的学习率等效于放大了 accum_steps 倍模型容易训飞。梯度检查点适合在显卡实在不够、还想上 ViT-L 的情况。它的原理是不保存中间激活值反向传播时重新计算。代价是训练速度会慢 20% 左右。我的建议是如果你用的是 ViT-B不需要梯度检查点浪费速度不划算如果上 ViT-L那就开。我实测过几组配置整理成表格你可以对照自己的卡来选模型组合batch size梯度累积显存占用备注ViT-B/16 6层BERT1282约 9G推荐速度质量均衡ViT-B/16 6层BERT2561约 13G显存刚好不建议再加序列长度ViT-L/14 6层BERT644约 14G开启梯度检查点ViT-L/14 12层BERT328约 15.5G极限配置不推荐这里面有个容易忽略的额外显存消耗来自对比学习的 logits 矩阵。当 batch size 为 256 时logits 是 256x256占用不大但当 batch size 达到 1024 时logits 矩阵就占了 8MB 显存前向计算时梯度图还会翻几倍所以在超大 batch 下对比损失本身也会成为显存瓶颈。5. 推理、向量检索与模型部署的落地细节训练不是终点模型训完要上线跑检索才有价值。微信场景下的多模态 Embedding 应用主要是在向量数据库里做相似度检索。这里面的工程坑不少。5.1 推理时的向量处理流程模型训练完之后推理时有一个容易被忽视的约束训练时输入是“一批图 一批文本”推理时往往是“一张图 一段文本”或者“一段文本 一个候选图片集”。由于训练时用了 batch 内的对比学习模型对 batch 统计有一定依赖性推理时 batch 变小会导致向量分布轻微偏移。解决方法是推理时对向量做标准化L2 normalize并且尽量保持和训练一致的输入预处理流程。另外推理输入的图片分辨率要和训练一致。我见过有人训练时用 224x224推理时为了省时间改成 112x112结果向量质量和检索效果跳水。这不是模型的问题是输入分布不一致的问题。推理阶段还有一个细节文本截断长度。训练时我截断到 64 token推理时必须保持同样的截断策略。如果推理时允许长文本输入模型会看到训练时从未见过的 token 位置pooler_output 的质量会退化。5.2 向量降维与量化Embedding 做完之后是 512 维的 float 向量一个向量占 2KB。如果线上有 1 亿条内容那就是 200GB 的原始向量存储压力很大。所以实际工程中我一般会做降维和量化。降维用 PCA。先在验证集上计算所有向量的 PCA 主成分保留前 128 维或 256 维一般能保留 95% 以上的检索性能但存储省一半以上。这里要注意PCA 的变换矩阵必须在训练集或独立的验证集上拟合不能在整个数据库上拟合否则会泄漏信息影响后续增量数据的处理。量化用 Product QuantizationPQ。把 512 维向量切成 16 个子空间每个子空间 32 维用 KMeans 聚类成 256 个中心点这样每个子空间只需要 1 个字节存储中心点索引最终一个向量只需要 16 字节。配合倒排索引IVF检索速度会快很多。但 PQ 是有损压缩如果你们的业务对精度要求很高我建议用 OPQ 做旋转优化可以在同样码率下提升不少召回率。5.3 与向量数据库的对接现在市面上有 Milvus、Faiss、Qdrant、Weaviate 等主流向量检索库。对于微信这种规模我倾向于用 Milvus 或者基于 Faiss 自建检索服务。Faiss 的优势是底层库性能稳定支持 GPU 加速适合技术团队自己封装Milvus 的优势是运维省心自带数据管理、索引构建、监控告警。不管用哪个有几件事必须做。一是建立独立的评估集每个版本上线前都跑一遍召回率对比防止模型迭代后某个指标回退。二是设置相似度阈值多模态检索里跨模态的相似度天然低于单模态检索阈值低了会返回一堆噪音阈值高了会漏召回这个阈值需要用线上日志去统计分布来定不能拍脑袋。另外如果业务里还需要关联 RAG 流程那 Embedding 向量不仅仅是做多模态召回它还要和文本 Chunk 的向量做混合检索。热词里出现“deepseek embedding ragflow”说明不少人会使用 RAGFlow 这类系统。RAGFlow 默认用他们自己的 Embedding但可以替换成你训练好的模型。接入方式是按照 RAGFlow 的 Embedding 接口实现一个自定义类把模型部署成一个 HTTP 服务然后配置指向这个服务。实测下来替换自己训练的多模态 Embedding 之后在包含图片描述的文档检索场景下召回质量明显好于通用 Embedding 模型因为通用模型没见过你的业务数据分布。6. 评估指标与调优心得模型训完怎么判断它好不好只看 loss 下降是不够的loss 降低只代表模型拟合了训练数据不代表检索效果好。我从实际项目中总结出一套评估方案如果只能看三个指标那就看 RecallK、MRR 和向量分布的可视化。6.1 三个必须看的指标RecallK 衡量的是对每个查询模型返回的前 K 个结果中有多少比例覆盖了人工标注的正确结果。K 一般取 10 或 50。这个指标对召回场景最直观。MRRMean Reciprocal Rank衡量的是正确结果排在返回列表第几位。第一位得 1 分第二位得 0.5第三位得 0.33等等。MRR 对排序质量更敏感搜索场景尤其关注它。向量分布可视化是调优的辅助手段。用 t-SNE 或者 UMAP 把验证集的向量降到二维然后按内容类别着色。一个训练良好的模型同类内容的向量应该自然聚成团不同类之间有清晰的分界。如果看到类别之间乱成一锅粥说明模型没学到区分特征这时候调损失函数和难负样本比调网络结构有用。6.2 调优过程中的几个关键判断在微信业务数据上我遇到过一个很典型的现象模型训练到第 3 个 epoch 之后训练 loss 还在下降但验证集 Recall10 不再上升了。这是明显的过拟合信号。我的做法是从第 3 个 epoch 开始每个 epoch 都保存一次 checkpoint最后根据验证集指标选择最优的那一版而不是训练到最后一个 epoch。另外把温度系数在训练中后期从 0.07 慢慢提高到 0.1也可以缓解过拟合因为更高的温度会让模型对负样本的关注度降低减少对训练集噪音的拟合。调优难负样本池的比例也值得记录。负样本池占比从 0% 增加到 2% 时Recall10 能提升 3 到 5 个点但继续增加到 5%收益反而下降因为太难的负样本会让模型训练不稳定loss 震荡明显。我最后固定在了 1.5% 到 2% 之间。一个高效的技巧是多模态模型蒸馏。如果你有条件使用一个更强的多模态大模型作为教师模型可以拿它来给图文对生成更精细的相似度分数然后用这个分数作为软标签蒸馏到小 Embedding 模型上。这个方向有专门的算法不是简单的把大模型的输出向量拿过来对齐而是要去蒸馏大模型对样本对的相对关系。具体操作上把教师模型对每个 batch 内所有图文对的相似度矩阵算出来用温度 T2 做 softmax 得到分布让小模型的相似度分布去拟合这个软标签分布。训练速度会慢一些但效果提升很值得。6.3 和通用模型的对比训练完成之后对比是必须做的。我通常会拿我们训练好的模型和我们之前的通用多模态模型做一个同测试集对比。评价维度包括单模态内的图文检索、跨模态检索、跨语言检索、视频帧检索。这里有个很实用的结论通用模型在通用领域的图文匹配上可能更好但在业务专属场景比如垂直领域的专业名词、用户的特定表达习惯下微调后的模型明显占优。通用模型的优势是泛化能力好冷启动能力强适合上线初期没有业务数据的情况一旦积累了十万级以上高质量的图文对训练自己的模型就能显著拉开差距。7. 常见问题与排查技巧实录最后这部分我把自己训练多模态 Embedding 模型过程中踩过的坑整理成一个排查手册。你可能不会一次全遇到但遇到的时候至少知道从哪个方向排查。7.1 显存 OOM 的排查顺序显存不够是最常见的问题但很多人一看到 OOM 就盲目减小 batch size这是不对的。正确的排查顺序是先看是不是输入分辨率太大把 224 改成 160显存能省一大半再看序列长度如果你把文本截断在 128 token 而实际大部分文本只有 20 个 token那就在数据加载时动态截断到实际长度的 90% 分位然后看混合精度是否开了梯度检查点是否开了最后才考虑减小 batch size。我用一个实际案例说明一个朋友复现我的配置在 16G 卡上跑不起来报 OOM。远程一看batch size 设的是 256图片预处理时 resize 到 384x384文本序列长度是 512。三个因素叠加显存爆了很正常。把分辨率改回 224、序列长度改为 64 之后显存从 14G 降到了 8G问题直接解决。7.2 loss 剧烈震荡或变 NaNloss 震荡的原因很多最常见的是学习率太大、温度系数太低、难负样本太多。排查思路是按顺序排除把学习率降一个数量级比如从 2e-5 降到 2e-6看 loss 是否稳定如果稳定了说明是学习率问题然后把温度系数提高到 0.1看是否稳定再检查难负样本池占比如果超过 3%降低到 1%。NaN 的问题一般出在混合精度上。fp16 的表示范围有限遇到极端值容易溢出。解决方法是检查数据预处理文本 token 里不能有 NaN 的 attention mask图片像素值必须在 [0,1] 或 [0,255] 且类型正确确认投影层输出之后做了 L2 归一化归一化会把数值压缩到 [-1,1]可以防止后续矩阵乘法溢出最后看 GradScaler 是否正常工作如果 loss_scale 在训练中不断下降说明有梯度溢出需要检查模型里是否有数值不稳定的层。7.3 模型效果一直上不去怎么排查这是最让人头疼的情况。模型训练没报错loss 也下降了但检索效果就是不行。我的排查路线是先检查训练数据的质量随机抽 200 条图文对人工看一遍如果发现很多图文根本不相关那就先去修数据。这一步能解决 60% 的“效果不行”问题数据没问题再去查负样本构造是不是负样本太简单了模型没有压力去学区分能力如果是做一轮难负样本挖掘负样本也没问题就看双塔之间是否对齐把训练集里图文对相似度的分布画出来如果分布峰值接近 1说明模型把所有东西都映射到了同一个区域这是模型退化的典型特征需要调整投影层结构或者加深投影 MLP。这里有一个我常用的“体检”脚本用 100 对标注图文对看模型在同 batch 内的相似度排序如果正样本对的平均排序低于前 10%说明模型有严重问题需要回退到模型结构层面的检查。7.4 模型推理速度太慢多模态 Embedding 在线上推理时图像塔是计算瓶颈。一张图过 ViT-B 的前向大约需要 15ms 到 30ms取决于 GPU 型号文本塔只需要 2ms 到 5ms。优化思路有几个图像塔用 TensorRT 或者 ONNX Runtime 做加速实测能把单张推理时间压到 8ms 以内对图片做缓存同一个 URL 的图片特征只算一次命中缓存直接返回如果对延迟要求极高可以考虑把视觉塔替换成更轻量的结构比如 MobileViT。微信场景里还有个特殊情况图片可能被压缩过EXIF 旋转可能没被正确处理导致推理时图片是横着的。这个在数据预处理时就要处理好统一按 EXIF 信息旋转再 resize。我见过一个 case线上有 3% 的图片带着旋转信息没处理那 3% 的检索结果全乱了。8. 后续可以扩展的方向多模态 Embedding 训练到能上线只是第一步。按照我的经验后面有几个值得继续投入的方向。一个方向是在线难负样本挖掘。我用的是离线定期挖掘更激进的方案是在每轮迭代中实时挖掘困难负样本并缓存这样模型训练时看到的负样本永远比当前模型能力略难一点收敛快上限高。缺点是工程复杂度高且需要注意不要把标签错误的样本引入训练集。另一个方向是加入音频模态。微信场景里视频号包含大量语音信息如果把音频也映射到同一向量空间可以实现“听到某段音频就搜到相关画面”的体验。做法是再加一个音频塔用预训练的 Wav2Vec 或者 CLAP 做编码器训练策略和图文对比基本一样。还有多模态模型蒸馏这条路。热词里出现“模型蒸馏”这个是当前业界常用的见效方法。如果你有一个更强的大模型比如 Qwen2-VL 这类多模态大模型可以在离线批量推理时让它产出高质量的伪标签再蒸馏到小模型上。这个方向对资源的要求高一些但效果往往比只靠自己标注数据训练要好值得投入。最后向量索引的更新策略也很关键。微信这种每天产生大量新内容的场景增量索引的时效性很重要。我现在的方案是新内容入库时先抽取向量写入一个临时的“新鲜索引”每隔半小时和主索引做一次合并。这样既能保证新内容的实时召回又不会因为频繁合并索引导致检索性能下降。实际线上这个方案能让新内容的可搜时间从小时级降到分钟级这个体验差异用户能明显感知到。多模态 Embedding 这个方向没有一个放之四海而皆准的答案。模型结构、数据配比、负样本策略、温度系数、评估指标每个环节都需要针对自己的数据分布反复调。我自己训第一版的时候光在温度系数和难负样本池配比上就实验了将近一周。但门槛不高只要有清晰的数据思路和一套可迭代的训练管线结果一定会比直接用通用模型好。希望这篇实践记录能让你少走一些弯路。