在垂类模型的数据工程里前面几个阶段我们基本都在跟数据和标注较劲真正把“语义”这个事落地还是得到 Embedding 训练这一步。这一阶段讨论的是怎么把一套领域相关的文本表示从通用模型手里接过来让它能区分专业场景里那些微妙差异我的选择是用双编码器架构配合 InfoNCE 损失函数来做整套训练闭环。这篇文章记录的就是这一个阶段从架构选型、数据构造到实际训练和踩坑的完整流程主要面向正在做垂类检索、召回或者语义匹配的工程同学也适合准备把对比学习用在自己领域数据上的研究者参考。我会把原理和实操放在一起讲有些结论看起来反直觉但跑完一轮实验基本都能对上。1. 为什么垂类模型不能直接吃通用Embedding1.1 通用向量的“领域失明”问题先说我遇到的一个真实场景。早期为了快速出效果我直接拿来一个在大规模通用语料上预训练好的文本向量模型用来做某个细分行业的单据检索。日常运营人员的提问都是“这个单子能不能在台账里查到”标准单据名称是像“某类设备维修记录单”这种规范文本听起来好像没什么但实际跑出来的 top10 检索结果非常失败。失败不在于模型本身能力差而在于通用模型训练语料里这种垂直场景的数据占比太低。模型对“维修”、“单”这些词的理解偏向日常生活对领域内的同义改写、简写和编号规则几乎无感。同一个意思用户输入和库里的正式名称字面完全不像但语义上应该匹配。通用向量的语义空间是按开放域问题训练出来的它不知道“质保期”在这个行业里等同于“三包有效期”这种专有映射。这种问题在开放域搜索里可能不明显因为通用语料本身覆盖了各种问法。但一到垂类场景领域词表是封闭的、句式是固定的、标准答案是明确的通用模型分配在“常见语义”上的容量就对不上了。所以做垂类模型数据工程到最后真正拉开差距的不是模型结构多新而是 Embedding 有没有被领域数据重新校准过。1.2 用“语义空间偏移”理解垂类训练的目标如果从训练目标看垂类 Embedding 要做的事只有一件在这个封闭领域里重新度量“相似”。通用模型给每个文本一个向量这个向量在通用语义空间里是合理的但在垂类语义空间里不是。比如“卡”这个词用在支付行业和用在机械行业代表完全不同的实体。想让模型理解这一点只能让它看足量的领域内正负样本通过损失函数把向量空间里的距离关系掰过来。我把这个阶段看作数据工程链条中“从量到质”的转换前几个阶段解决的是数据有没有、干不干净Embedding 训练解决的是用这些数据能不能形成有效的度量。你需要先接受一个前提通用 Embedding 可以作为初始权重但绝不应该作为终态。如果一开始就抱着“通用模型反正能跑凑合用吧”的心态后续所有召回优化都是在有瑕疵的地基上打补丁。1.3 先做一轮低成本语义体检在进入训练之前建议先花半天时间做一次便宜的体检也是我每个垂类项目都会重复的动作准备大概 50 条领域内的真实 query以及一个对应的候选文档池用通用 Embedding 做 recall10再把结果人工瞄一遍。不用做完整评估只要看 top10 里有多少是“类型对得上但内容不对”或者“字面相关但语义不相关”。我见过的绝大多数垂类项目这一步之后都会得到同一个结论通用向量在领域内会把字面相似性和语义相关性严重混淆。典型的例子是搜索“设备故障”和标准文档里“机器运转异常处理规范”字面完全不重叠但语义应该相关而通用模型往往排序很低。体检的价值在于给你一个量化的基线。后面训练完再测同一个体检集提升多少一目了然。这一阶段的所有工作本质上都是在跟这个基线作对比。2. 双编码器架构拆解从结构选择到部署约束2.1 为什么是“两个塔”而不是一个交叉编码器垂类语义匹配的技术栈里有两个常用套路交叉编码器和双编码器。交叉编码器把 query 和文档拼成一个序列用一个模型做完整交互效果好但慢得离谱因为它需要为每个候选对跑一次前向。双编码器把 query 和文档分别编码成两个向量之后只需要算向量相似度可以用近似最近邻检索做大规模召回。我选双编码器核心原因是生产环境约束。线上一个 query 打到几百上千万的候选库如果每条都过交叉编码器响应时间直接爆炸。双塔结构等于把重计算放在离线阶段文档塔可以提前把库里所有文档变成向量存进索引线上只需要编码一次 query然后做一个向量检索。这种“离线重、在线轻”的结构才是支撑高性能召回的唯一现实选择。很多刚接触的人会觉得双塔丢失了交互信息不如交叉编码器。这个批评没有错但要看场景。垂类搜索里的候选集往往很大需要的是先快速召回一个高质量的子集语义精排再交给交叉编码器这类重模型。双塔负责“大海捞针”交叉编码器负责“针尖对麦芒”两者是配合关系不是替代关系。2.2 双塔内部的三个关键设计点第一个设计点是两个塔是否共享参数。共享参数的好处是参数少、训练稳定适合 query 和文档文本分布比较接近的场景比如检索式问答。不共享参数的好处是每个塔可以适应不同文本风格适合 query 普遍短小、文档普遍长且结构化的垂类场景。我在大多数垂类项目里选择两个塔结构相同但权重独立因为 query 侧的用词和文档侧的规范术语分布差异太大了。第二个设计点是序列编码的池化方式。文本经过编码器后得到一串 token 向量通常有几种做法把它压成一个句子向量。最粗糙的是用 [CLS] 位好一点的是对所有 token 做均值池化更好一点的是按 token 的权重加权求和。垂类文档往往很长存在大量与核心语义无关的章节比如模板里的“注意事项”“参考文件”这种噪声对均值池化伤害很大。我会在文档塔上尝试加权池化权重来自一个简单训练的领域词表映射效果往往比默认池化高出不少。第三个设计点是向量归一化。双塔输出的向量在算点积之前一定要做 L2 归一化让所有向量都落在单位球面上这样点积等价于余弦相似度语义可比性才稳定。如果不做归一化向量模长会参与相似度计算导致长文档天然占便宜排序结果会失真。这个细节看似小但对后续难负样本挖掘和阈值设定影响巨大我见过好几个项目因为漏掉这一步调了很久温度参数都调不对。2.3 底层模型怎么选不要盲目追求大垂类场景的文本通常有个特点领域内专用词占比高、句式重复性强、单条文本长度波动大。底层预训练模型的选择上我的建议是先用中等规模的通用模型初始化再把领域语料继续做少量预训练。这个操作成本不高但收益稳定尤其是那些领域术语跟通用词义冲突大的场景比如法律、医疗、工业制造。大模型不一定更优。模型越大训练和线上推理成本越高而且垂类数据量通常有限大模型容易过拟合到少部分高频 pattern 上。双塔训练的核心是让两个 encoder 学到“好匹配”的判别边界而不是让它们变得更加博学。领域知识由预训练阶段负责匹配能力由双塔训练负责这个分工想清楚之后模型选型就不会被参数规模带跑。3. InfoNCE 损失函数一个公式怎么让两个塔“学会对齐”3.1 从实例到公式InfoNCE 到底在算什么双塔架构定下来后核心问题就是怎么定义“拉近正样本、推开负样本”。我最早用的是三元组损失但很快就换成了 InfoNCE因为 InfoNCE 在训练稳定性、负样本利用率和最终效果上都明显更好。它本质上在做一件很简单的事给定一个 batch 里的 query把当前 batch 里唯一的正样本从所有样本中识别出来。如果用一句话说清楚 InfoNCE 的思路那就是把匹配问题变成分类问题每个 query 有一个正确答案其余 batch 内的文档都是错误答案让模型学会从一堆候选中挑出那个正确的。写成公式就是这个样子[ L_{InfoNCE} -\log \frac{\exp(\text{sim}(q,p^)/\tau)}{\exp(\text{sim}(q,p^)/\tau) \sum_{i1}^{N-1} \exp(\text{sim}(q,p_i^-)/\tau)} ]其中 sim 是余弦相似度τ 是温度系数p^ 是正样本p_i^- 是负样本。这个公式里面有一个关键设计分母中的负样本数量越多模型需要区分的类别就越多学到的语义边界就越细。这一特点正好匹配垂类检索的诉求——因为真实召回面对候选集是百万级的训练时区分几十个负样本只是最小成本的模拟。建议训练中用大 batch 来增加负样本数量这也是 InfoNCE 的核心收益之一。batch 里每个 query 对应的正文档对其他 query 来说恰好就是负样本这一机制下产生的“batch 内负样本”数量等于 batch size 减一完全不需要额外构造和存储训练效率非常高。后续讲数据构造时会再展开。3.2 温度系数 τ 的直觉理解与调参影响InfoNCE 公式里的温度系数 τ 是最容易被忽略、但影响最大的超参数。它的作用相当于给相似度打分做缩放分数除以一个更小的 τ会让相似度分布的对比度变大相当于把模型的注意力集中到那些最难区分的高相似度负样本上τ 太大则会让所有分数的差异被抹平模型学不动τ 太小又会让模型对噪声极度敏感一点扰动就会被放大。我的经验是τ 一般初始设在 0.05 左右再根据训练集难度微调。判断标准很简单如果训练一开始 loss 掉不下去检查 τ如果 loss 掉得飞快但评估指标没有同步提升很可能 τ 太小模型在死记硬背区分训练样本而不是泛化出了语义边界。比如之前在一个保险场景里我把 τ 从 0.05 调小到 0.02训练 loss 降得明显更快但 recall5 反而掉了调回 0.04 效果最好。这里有个实操细节值得注意如果向量没有做 L2 归一化τ 的实际效果会失控。因为余弦相似度本身的取值范围被限制在 [-1, 1]除以一个很小的 τ 前还说得过去如果向量没有归一化点积的范围可能是 [-10, 10] 甚至更大同一个 τ 就会产生截然不同的梯度尺度。所以“先归一化再调温度”是双塔训练里绝对不能打破的顺序。3.3 InfoNCE 与三元组损失的对比我看到很多项目还在用三元组损失也不是完全不行但有几个坑很难绕开。首先三元组损失需要显式构造 anchor、positive、negative 三元组负样本的难度全部依赖人工挖掘策略而 InfoNCE 天然利用了 batch 内全部负样本不需要额外设计。其次三元组损失只有一个固定 margin遇到简单负样本和困难负样本距离相差很大时梯度容易被简单样本主导。InfoNCE 的另一个优势是它与 softmax 分类天然同构。从公式里可以看出它就是带温度的 softmax 交叉熵损失每个 query 被要求预测自己对应的正样本。这让整个训练过程非常稳定因为梯度有明确的“分类不确定性”作为校准信号不会像 margin loss 那样经常出现负样本离得太远或太近导致的波动。我之前做过一个对比实验同样数据一份用三元组损失一份用 InfoNCE训练同样的步数后者的 recall10 高出 6 个百分点左右。而且三元组损失需要更多小 trick 才能训起来比如动态难样本挖掘、margin 自适应InfoNCE 则只需要关注数据和温度省心太多。除非你有特殊的场景需求否则 InfoNCE 是我在这个阶段的首选。4. 垂类训练数据构建正样本、负样本与难负样本的分寸4.1 正样本从哪里来日志、规则与人工标注的配合Embedding 训练需要成对的 query 和正样本文档。在垂类项目里正样本来源通常有三种一是用户检索点击日志用户搜完之后点开了哪条文档这是一个弱标注的正样本二是基于规则和领域知识构造的规范匹配对比如“报销凭证”和“费用结算证明”就是人工规则认定的同义对三是人工标注数量少但质量最高用来做种子集。我的做法是把这三种来源结合先用日志数据跑一个召回模型从日志里取高置信度的点击对作为自动正样本再用规则构造一批同义改写对补充长尾表达最后请领域同学标几百条最难的语义对重点关注那些通用模型容易混淆的边界情况。日志数据噪声很大用户点开文档不一定代表内容匹配需要用停留时长和后续行为做置信度过滤否则模型会被噪声带偏。关于正样本数量很多人会问是不是越多越好。我的经验是垂类模型对正样本的质量敏感度远高于数量敏感度。几百条高质量种子对配合几千条相对可信的日志对就能训练出一个明显优于通用 Embedding 的模型。如果日志数据本身有系统性偏向比如只覆盖热门类型冷门类型完全没有点击那再多数据也救不了冷门类的召回。4.2 负样本的层次化设计随机负样本与难负样本负样本的重要性经常被低估。随机负样本简单粗暴从候选库里随机取一段文本跟 query 大概率不相关这保证了模型能区分基础的正负语义。但如果只用随机负样本模型会变成“字面匹配器”只要字面重叠高就认为相关这对垂类搜索是致命的。大部分垂类场景里真正难的是区分那些看起来很像但语义不同的样本。比如“设备安装”和“设备调试”在同一个项目流程里可能都出现但用户搜“安装”时“调试规范”就不应该排前面。这类难负样本需要主动挖掘用当前模型跑一遍训练集把每个 query 召回排名靠前但不相关的文档捞出来作为难负样本混入训练数据下一轮模型就会对这类样本更敏感。难负样本的加入量需要控制分寸。我在实践中一般把负样本池设计成三部分随机负样本占 60%难负样本占 30%领域内规则构造的“相似但不同”样本占 10%。难负样本比例如果太高训练初期模型还没有区分能力会把大量难负样本当成正样本的近邻导致损失波动剧烈。先训几轮让模型把基础语义学扎实再逐步提高难负样本比例效果会更稳定。4.3 数据清洗与去重防止数据泄漏和“病态捷径”训练数据构造中还有一个很容易翻车的点数据泄漏。如果同一条文档既出现在训练集里又出现在测试集/验证集里召回指标会被严重高估。垂类数据总量小这个问题尤其容易出现。我在每个项目里都会做严格去重不只是整段去重还要做改写后去重因为很多文档只是换了标题正文基本一致。另一个容易被忽略的问题是“病态捷径”。模型很聪明会去找数据里最省力的判别信号。如果所有正样本文档都集中在某种格式比如都带“规范”两个字模型可能学会只看“规范”这个 token 就判相关而不是理解真正的语义关系。这种模型在测试集上表现尚可一上线遇到格式不同的真实文档就崩。避免病态捷径的办法有两个一是让正负样本在格式特征上尽量同分布保证表面特征不是有效区分信号二是在训练数据里加入大量对抗性噪声样本专门把那些“表面很像、语义不同”的例子做成负样本逼模型放弃表面匹配策略。这两个操作听起来简单但实战中需要反复看 bad case 才能找到模型的“偷懒点”。4.4 数据规模与冷启动确实没有数据时怎么办垂类项目最尴尬的情况是冷启动连日志都没有人工标注也没预算。这种情况下我的建议是先做两件事一是用通用模型对领域文档做一次聚类把同一簇内但字面差异大的文本对自动挖掘成弱正样本二是利用领域词表做同义替换生成合成数据。这两招不完美但能在一天内构造出初始训练集让模型先跑起来。等模型跑出第一版就能用模型自身的召回结果做第二轮数据迭代这就是所谓的“自举”。先用弱数据训一个粗模型再让粗模型去挖掘难负样本和高置信度正样本扩大训练集。每一轮迭代之后模型对领域语义的理解都会加深也会在下一轮数据挖掘中找到更难、更有价值的样本。数据工程的这四个阶段最后都会收敛到这个“模型辅助数据生产”的模式上。5. 训练实操模型配置、批量大小与调参策略5.1 训练流程的整体设计与关键参数整个训练流程我会分成三个阶段领域预训练、双塔对比训练、可选精调。领域预训练是在通用模型基础上继续用垂类语料做掩码语言建模这一步不是必须但对领域术语多的场景收益明显。双塔对比训练是主力用前文的数据构造方案喂给 InfoNCE。可选精调则是在少量人工标注数据上用更小的学习率再走一轮专门修正边界案例。我用一段伪代码概括 InfoNCE 训练的核心逻辑方便不熟悉实现细节的读者理解整个过程# 伪代码InfoNCE 双塔训练前向 def info_nce_loss(query_emb, doc_emb, tau0.05): # query_emb 和 doc_emb 均已做 L2 归一化 # 假设 batch 内第 i 个 query 的正确答案是第 i 个 doc logits query_emb doc_emb.T / tau # [batch, batch] labels torch.arange(len(query_emb)) # 对角线为正确匹配 return cross_entropy(logits, labels)这里唯一容易被忽视的是 labels 的构造对角线样本对是正样本同一行其他列都是负样本。如果你的数据 pipeline 把正样本对排列打乱了必须维护一个索引映射否则 batch 内“负样本”里混进正确答案训练损失就直接崩了。关键超参我整理了一张表这是我在垂类项目里比较通用的一组起点配置参数推荐范围说明学习率1e-5 ~ 3e-5基于预训练模型微调不建议太大batch size64 ~ 256越大隐式负样本越多但受显存限制温度 τ0.03 ~ 0.1先小后大视训练难度微调难负样本比例20% ~ 40%逐步加入不要一开始就给满训练轮数3 ~ 8垂类数据通常不需要训很多轮warmup前 10% step避免学习率突变打乱预训练权重5.2 大规模 batch 的实现技巧与显存优化InfoNCE 非常吃 batch size。batch 越大隐式负样本越多训练出的语义边界越细。但双塔结构有一个实现优势query 塔和文档塔可以分开前向不需要同时把两侧的长文本都存进显存显存峰值比交叉编码器低得多。我一般用梯度累积来模拟更大的 batch先把文档塔的向量存下来再编码 query这样即使单卡也能跑到 128 以上。垂类文档通常很长如果原样截断会损失关键信息。我的做法是先把文档按语义分段对每段分别编码再把所有段的向量做加权合并。这样做的原因是文档里真正跟 query 匹配的核心信息往往只出现在某一段全局均值反而把信号稀释了。合并权重可以通过一个可学习的注意力层来获得训练时和双塔一起更新。如果资源允许多卡训练值得投入。双塔的并行策略很简单每张卡处理一个子 batch前向完成后把所有 doc 向量汇总到一块做全量 logits 计算。注意这里的同步通信是必要的因为 InfoNCE 的负样本是跨卡共享的如果只在单卡内做负样本batch 效应会被打折效果明显不如全量共享。5.3 评估与早停不能用 loss 判断模型好坏训练过程中最容易犯的错误是盯着 loss 看。InfoNCE loss 下降不代表检索效果好因为它只反映模型区分训练集 batch 内样本的能力而检索效果取决于模型在真实候选集上的语义排序能力。所以我在训练过程中每个 epoch 结束都会跑一次固定的验证评估集算 recallk 和 nDCG。垂类场景的离线评估集设计要贴近线上真实分布query 来自真实的用户日志正样本来自人工确认负样本从全量候选库里随机抽取。我用 recall5 和 recall20 作为主要指标因为线上召回阶段只要把正确文档带回精排就算完成目标。如果 recall5 提升不明显但 recall20 提升明显说明模型把语义带到了更前面的位置同样值得发布。早停的标准应该围绕评估集指标而不是 loss 变化。我通常设置 patience 为 3 个 epoch如果评估 recall20 连续三轮没有上升就停止。垂类数据量不大训练通常不会太长关键是把握好“继续训练会不会过拟合到难负样本”这个临界点。一旦评估指标下降立刻回滚到最佳 checkpoint不要恋战。6. 实战中踩过的坑与完整排查链路6.1 坑一难负样本加太猛训练直接发散第一次做难负样本挖掘时我犯过一个典型错误把模型自身召回 top20 的不相关文档全部塞进负样本池比例一度拉到 50% 以上。结果训练 loss 上下乱跳评估指标不升反降。原因现在看很简单训练初期模型根本没有区分难负样本的能力把大量高相似度负样本丢给一个没准备好的模型等于让它在黑暗中猜拳梯度信号互相打架。排查过程花了很长时间因为我先怀疑是学习率问题调了几轮没有改善又怀疑是数据量不够加了数据还是不行最后把我把负样本比例按轮次动态调整前两轮只保留随机负样本第三轮开始才逐渐加入难负样本一切才恢复正常。这个经验后来固化成我的训练策略难负样本是给“已经学会基础语义的模型”加量的不是给冷启动模型补课的。6.2 坑二向量没有归一化调参怎么调都不对还有一个项目A 同学搭建了一套双塔训练代码照着网上的配置跑但无论怎么调学习率和温度评估指标都很差。我帮忙排查时第一眼看的就是向量是否做了归一化发现训练代码把 raw encoder 输出的向量直接做了点积没有 L2 归一化。这里引发的问题非常隐蔽向量模长参差不齐长文档总是占优模型学会了“长度匹配”而不是“语义匹配”。排查链路是给几个样本打出来看相似度矩阵发现所有相似度都集中在某个区间分布完全不像余弦相似度的样子。把归一化加上之后同样的训练配置和超参效果立刻恢复正常。这个坑我很确定地写下来是想提醒所有做双塔训练的读者归一化必须在 loss 计算之前一个都不能漏。它可以放在 encoder 输出之后作为一个独立的 normalize 层。6.3 坑三数据泄漏导致评估虚高差点带病上线训练数据里有一条很隐蔽的数据泄漏路径评估集中某些 query 的正样本文档在训练集中也以较高相似度的变体出现过。导致评估指标看起来非常好但如果把评估集换成线上真实 query效果就崩了。当时我们甚至差点把那个模型发布上线还好在最后的 bad case 分析中发现模型对某些文档标题异常偏爱词表之外几乎不看。排查手段是评估集和训练集做双向相似度检索把训练集每条文档去评估集里找最相似的样本如果相似度超过阈值就检查是否属于同一份文档的变体。这个操作看起来耗时但对垂类这种小数据量环境非常值得做。从这之后我把“训练-评估隔离检查”写进了每一个数据工程的验收清单每次发版前都必须过一遍。6.4 坑四温度 τ 成为“全局开关”一调就全局生效最后一个想记录的坑是 τ 的定位偏差。一开始我把它当作一个“能涨点就调”的参数每次模型效果不理想就先把 τ 从小到大扫一遍结果发现它虽然能带来短期提升但无法弥补数据层面的问题。后来我把 τ 当成一个“和作用域绑定的开关”它主要影响难样本区分的锐度只有在数据质量、负样本比例、归一化都正确的前提下调 τ 才有意义。这个认知改变了我整个调参流程的顺序。现在遇到效果不好的情况我会先排查数据问题再检查归一化和训练代码最后才动温度系数。垂类模型数据工程走到 Embedding 训练阶段时数据就是天花板模型和参数只是负责逼近这个天花板。把顺序搞反的人往往在参数调节上花掉大量时间却始终突破不了那个数据决定的性能边界。这一阶段的实战做下来我的一个整体感觉是双编码器加 InfoNCE 这个组合在垂类场景里足够稳它能帮你从前几个阶段积累的数据里榨出一套真正属于领域语义的向量表示。回看整个训练过程最有价值的建议还是那几句老话先体检再动手先归一化再调参先保数据隔离再谈指标。项目推进中总会有各种突发问题但只要每一步的选择都能说清楚为什么遇到问题时排查链路就会清晰很多。技术上双塔结构本身并不复杂真正的复杂度永远在数据和细节里这也是为什么我把这一阶段的笔记重点都放在了踩坑和排错上。