过去半年我最大的感受是预训练已经不再是大家茶余饭后的唯一话题**中训练Mid-training和后训练Post-training**这两个词出现的频次越来越高。与此同时圈子里最热闹的“AI for AI”——也就是用AI模型去训练、评估、修正另一个AI模型——也在快速从概念走向工程落地。我理解的“中训练”并不是一个学界严格定义的名词而是一个行业约定俗成的说法在通用预训练完成之后、正式做指令微调之前把模型扔进一个领域数据池里再训一程把通用底座“盘”成某个行业或某个能力方向的专用底座。而后训练则是从SFT监督微调到偏好对齐、再到强化学习/强化验证这一整套流程决定模型“好不好用”。有意思的是这两段训练的迭代频率、实验成本和调试难度都远高于单纯的预训练恰好成了检验AI工程化能力的最好战场。这篇文章就围绕“中训练后训练AI for AI最佳试炼场”这个核心命题把我自己实操下来的经验、参数、坑和排查思路完整整理一遍。1. 中训练与后训练模型的能力到底在哪一段炼出来的1.1 中训练到底在训练什么很多人对“继续训练”的理解停留在“喂更多数据、降低loss”这种朴素的认知上。但实际上中训练的目标粒度比预训练细致得多它的重点往往不在“学会语言”而在“学会领域”和“学会格式”。举两个典型场景场景A代码模型的中训练。以通用模型为底座再用大量高质量代码数据、尤其是包含完整代码上下文和结构化注释的数据做继续预训练。这里的关键不是让它多背几段代码而是让它在“给定文件名、依赖关系、上下游调用”时能够更合理地推断出代码生成的方向。这种中训练对学习率、数据配比和重复度都非常敏感。场景B领域法规/文档知识的中训练。比如做法律或医疗垂直模型把判决文书、诊疗指南、药品说明书等数据注入到底座中。很多团队在这里踩过一个坑数据重复次数太多模型会出现局部“背题”现象即在特定格式的输入下能精确复述内容但换个问法就完全失效。这说明中训练并没有真正泛化只是把数据“记住”了。我在实操中会把中训练拆成两个阶段考虑第一个阶段用相对高的学习率比如1e-5到3e-5把模型从通用分布拉到目标分布的“邻域”第二个阶段用极低学习率1e-6左右做精调和稳定性收尾。这么做的好处是既能明显改变模型的行为偏好又不容易把预训练阶段学到的通用能力“洗掉”。另外一个容易忽略的点是数据配比。中训练不能只放领域数据必须保留一部分通用数据甚至需要包含一批“通用能力评测集”否则训练后期会产生严重的灾难性遗忘。我常用的配比是领域数据占60%、通用数据占20%、开源指令数据占20%并且在训练过程中每隔一段步数就跑一次标准评测观察通用能力是否有明显下滑。1.2 后训练对齐、偏好与能力解锁后训练这一段行业里已经形成了一套相对标准化的流水线先做SFT让模型学会“有问有答”的格式再做偏好对齐比如DPO、KTO、SimPO这一类离线或在线的方法让模型知道“什么回答更讨人喜欢”最后如果资源充足还可以上RLVR基于可验证奖励的强化学习或RLHF让模型在数学推理、代码执行这类能用规则判断对错的场景里继续搜刮能力。我在实际复盘中得出的一个结论是SFT决定模型的能力上限对齐决定模型的下限。SFT阶段如果数据太脏模型会把坏习惯学进参数里后期偏好对齐很难完全纠正过来。所以SFT数据的质量控制优先级要高过数据量本身。此外后训练阶段有一个很容易被忽视的“试炼”属性评测回归。每一轮后训练改动都可能让模型在某些能力上提升、在另一些能力上退化。比如我遇到过调大RLVR的奖励系数后数学推理分数涨了3个点但代码生成类任务的格式错误率反而翻倍。这种情况下任何不配合完整评测体系的后训练都是盲人摸象。1.3 为什么说这是AI for AI的最佳试炼场中训练和后训练有一个共性它们都是“面向迭代”的训练方式。预训练阶段一组数据训练一次动辄数千卡GPU做完整次实验的周期以月计普通人很难在短时间内积累大量实验经验。而中训练和后训练的实验周期可以压缩到几天甚至几小时天然适合引入大量自动化工具让AI自己参与用AI模型自动构造SFT指令数据、负样本数据用AI模型给模型回答打分、构造偏好对用AI模型做评测、判断两个版本模型在哪些case上产生了行为分裂用AI Agent自动扫描训练日志、分析loss异常。这些环节叠在一起就是一个标准的“AI for AI”闭环模型在快速迭代中不断产出数据数据又被用来训练下一代模型整个循环中人工干预的点越来越少。可以说中训练和后训练不只是模型的“精修车间”更是AI工程化能力的试炼场。2. AI for AI训练流程里的自动化闭环2.1 合成数据驱动的自我迭代先讲最落地的一环合成数据。做后训练的人都明白高质量人工标注数据是稀缺资源尤其是指令遵循类数据人工一条条地去写既慢又难保证覆盖度。业内常用的做法是让模型参与到数据生产中来用大模型生成一批任务描述覆盖不同领域的指令再让模型根据任务描述生成回答草稿用规则过滤器去掉格式错误、长度异常的内容最后用评分模型对回答质量做排序和筛选。这一套流程中数据生成的模型可以是开源的通用模型也可以是你正在训练的模型本身。前者适合做增量扩充后者适合做“自我对弈”式的迭代。我在一个文本摘要项目中实践过自我迭代先让当前模型对一批文档生成摘要然后用人工评过的历史数据做偏好对用DPO训练出新模型新模型再生成下一轮候选摘要不断滚下去。效果提升虽然每一步只有一两个点的ROUGE-L增益但累计五轮之后摘要的可读性和要点覆盖率都有了质的提升。2.2 模型评测与回归检测自动化中训练和后训练迭代得越快评测就越不能依赖人工。人工当然要看一部分case但这只能作为定性抽查不能作为回归决策依据。我的做法是把评测分成三层第一层规则评测。针对格式敏感任务比如JSON输出、表格提取、代码format用脚本断言结果是否合法这一层跑得最快适合在训练过程中频繁调用。第二层模型评测。用更强大的模型比如当前能拿到的最强API模型作为裁判对生成结果按多个维度打分比如相关性、完整性、有害性。注意裁判模型需要做好提示词约束必要时还要做多模型投票避免单模型偏差。第三层任务指标评测。针对具体业务场景跑真实指标比如检索里的RecallK、分类任务里的F1、代码任务里的编译通过率。这一层最贵但才最有说服力。在这一套体系里模型每次迭代后只需要跑前两层就能快速决定这轮改动是否进入候选集合每周再跑一次第三层确定最终发布版本。评测本身就是AI for AI——用模型/算法去衡量模型的行为变化。2.3 工具链选型解析从Embedding到DeBERTa再到LightGBM做AI for AI闭环时会用到大量辅助模型我自己常打交道的几个方向Embedding模型主要用来给文本聚类、做语义去重。后训练数据准备阶段如果指令数据大量重复模型很容易过拟合到几条相似的句子上。我习惯在清洗数据时把文本转成向量然后做近重复检测相似度超过阈值的只保留一条。选Embedding模型时重点看检索任务上的召回指标而不是看参数量大小。DeBERTa这类encoder-only模型通用能力弱但特别适合做分类打分。在淘汰低质量数据时我会用一个DeBERTa/LoRA微调过的质量分类器给候选样本做初筛。相比直接用大模型打分小分类器速度快、成本低线上批处理可以做到毫秒级。训练一个质量分类器本身就是一个很典型的“用AI训练AI”任务先用大模型标一批弱标签人工review 20%然后用弱标签微调小模型。LightGBM这类传统机器学习模型在训练监控和回归分析上有奇效。比如我想分析“这轮迭代在哪些case上变差了”可以把每个case的特征长度、领域、困惑度、embedding距离等拼成表格用LightGBM训练一个“变差预测器”找出导致模型退化的关键特征维度。这种方法解释性远强于直接暴力对比文本尤其在处理上千条case时非常实用。2.4 数据与评测的闭环组织方式做闭环不是写几个脚本串起来就完事工程上要走通“数据-训练-评测-归因”的循环。我的建议是一开始就把流程拆成独立模块用明确的接口串联数据模块产出统一的JSONL格式里面包括指令、回答、来源、质量分、嵌入向量训练模块只消费标准格式不关心数据是人工还是合成评测模块输出每个case的细粒度得分保留评测结果log归因模块读取新旧模型在每个case上的得分差按领域标签聚合。这样每个模块都可以独立替换比如今天用DeBERTa做质量分类、明天换成更新的Qwen分类模型只改模块内部实现不通影响数据流的其他环节。这个设计看似平淡其实是整个AI for AI体系里最容易翻车也最值得花时间的地方。3. 从0到1跑通一轮快速迭代实操记录这一节我以“做一个垂直领域指令模型”为例完整走一遍中训练后训练的流程。假设底座选用一个开源的中型模型7B-13B级别目标场景是电商客服问答包括商品咨询、售后政策、订单查询三大类任务。3.1 步骤一确定迭代目标和数据构成开始之前先定清楚三个问题要解决什么缺陷比如当前模型在售后政策类问题上总是回答得过于笼统缺少具体的退换货条件和时间限制。怎么衡量成功选10个典型售后问题作为“金标case”要求新模型的回答必须覆盖三个关键实体时间期限、条件限制、操作路径。数据从哪里来中训练阶段准备10万条客服对话原文后训练阶段准备1.2万条指令问答对其中6000条人工写过并审核剩余6000条由模型合成后经规则和分类器筛选。数据构成这块我要多说一句不要只堆“对话轮次”要有意识地制造数据多样性。我常用的做法是按“意图标签”做分层抽样确保每个意图下都有足够数量的长问题、短问题、带数字的、带情绪化的、中英混输的样本。这样训练出来的模型面对真实用户时不容易顾此失彼。3.2 步骤二中训练的关键参数与配置中训练我用的配置大概是这样不同底座会有差异但思路一样数据长度把对话文本按4096 token切段保留完整对话的上下文不强行截断到句子中间训练轮数1到2个epoch不需要多中训练主要目的是“注入领域存在感”学习率第一阶段3e-5第二阶段1e-6配合warmup ratio 3%Batch size单卡可承受范围内尽量大比如8卡A100global batch 64优化器AdamW权重衰减0.1梯度裁剪1.0Loss策略保留语言建模loss但对话文本中“用户侧”token的loss要mask掉只学习模型应该生成的回复部分。训练过程中的监控不只看loss曲线还要看领域困惑度。我会每隔500步在固定评测集上计算困惑度和一些简单的答案抽取成功率。如果领域困惑度下降不明显但通用数据集困惑度快速上升说明学习率太高或领域数据太多了需要立即回调。训练结束后我会对底座做一次“中训练版本快照”在这个快照基础上进行所有后训练实验。不要在主模型上直接反复折腾分支管理是后训练迭代的基本原则。3.3 步骤三后训练SFT与偏好对齐中训练完成之后开始SFT。SFT阶段的数据就是那张1.2万条指令表训练参数上我会用到学习率2e-5比中训练低避免对底座改动过大轮数3轮但每轮结束都跑一次“金标case”评测第2轮如果效果不如第1轮立即停止Mask处理同样只对模型回答部分计算loss指令部分不参与梯度更新系统提示词统一加上“你是电商客服助手回答要简洁准确”这部分token在训练时也参与注意力计算但不计算loss。SFT之后是偏好对齐。这里我会构造偏好对对同一个用户问题给出两个回答一个是“好回答”一个是“坏回答”。坏回答来源很丰富可以是旧版本模型的输出、温度调高后生成的不可用文本也可以是人工刻意篡改的错误版本。用DPO在这些偏好对上做对齐beta参数我一般设0.1到0.3beta越大模型对偏好差异越敏感但容易把模型学“偏”。这里有一个很实在的经验偏好对的质量比对数量重要得多。1000条人工仔细审核过的偏好对效果往往好于1万条自动生成的噪声偏好对。尤其在客服场景下用户的真实诉求是“赶紧解决问题”而不是“回答花哨”所以偏好对齐数据更需要突出“信息充分、逻辑清晰、态度冷静”这几个维度。3.4 步骤四批量评测与效果对比后训练完成之后用前面说的三层评测体系跑一遍。跑的时候有一点要注意不要只对比最终的得分还要看每一条case的得分变化。我会生成一个“对比报告”里面包含新模型相比旧模型得分提升的case列表及提升幅度新模型相比旧模型得分下降的case列表及下降幅度按意图标签聚合的升降趋势随机抽10条变化幅度最大的case人工查看。这个习惯帮我避免过很多“总分涨了但关键场景崩了”的事故。举个例子某次迭代中整体F1涨了1.5%但细看发现“退款金额计算”这个标签下的正确率从82%掉到61%原因是偏好对齐阶段把一些包含具体数字的对齐对权重调得太高模型开始“回避给精确数字”。及时发现后我把这类case单独喂回SFT数据中重训了一版问题才解决。这一整轮中训练加后训练的迭代端到端跑下来大约需要2到3个工作日如果只是后训练微调半天到一天就能完成。这也是我说它是“最佳试炼场”的原因实验周期足够短才能支撑你一遍遍尝试不同的AI for AI方案。4. 常见问题与排查技巧实录4.1 BN崩溃训练中BatchNorm统计量失稳标题里提到的“yolo训练中bn崩溃”这类问题在中大型预训练模型里比较少见但如果你做的是多模态模型、视觉语言模型或者改造过的CNN结构就很容易遇到。BN崩溃的典型表现是训练loss突然剧烈抖动验证指标暴跌甚至出现NaN。我的排查思路是先确认是不是学习率过大导致的把学习率降一个量级观察几步看batch size是否过小BN在小batch下统计量方差极大容易失稳检查是否有“异常样本”混入数据比如全黑图片、空文本等这些样本会让BN的统计量被带偏如果确认是BN本身的锅尝试把BN层替换成LayerNorm或者RMSNorm后者在生成任务中更稳定。顺带提一句这也是“AI for AI”的又一典型场景用自动监控脚本在训练过程中实时计算各层统计量的方差一旦发现某个特定层的统计量偏移超过阈值立即暂停训练并定位到触发样本。人工去盯几千步日志不现实交给程序去盯才是常态。4.2 训练后模型迁移IsaacLab到MuJoCo这类跨环境转换网络热词里还有一个典型的工程诉求“isaaclab训练完成后如何导入到mujoco中”。这虽然更多是机器人仿真领域的操作但背后映射的是模型部署迁移也就是训练环境的产物如何平滑转到推理环境中去。在训练/后训练场景中类似的“迁移”问题我会拆成三类权重格式转换比如把PyTorch权重转成ONNX、TensorRT或GGUF。这里最常踩的坑是动态维度问题转ONNX时未指定动态轴推理时固定batch和seq len导致服务端无法处理变长输入。前后处理不一致训练时用分词器的clean_up_tokenization_space等参数和推理时不统一生成结果会多出莫名其妙的空格。别笑这是生产环境高频事故。环境依赖差异训练机器上的CUDA版本、Flash Attention版本与推理机器不一致虽然模型能加载但输出概率有细微差异严重时会出现采样结果明显变差。我的建议是团队内部最好统一一个“部署矩阵”文档把每种来源模型的转换命令、目标格式、验证样例、允许误差范围都写清楚。每训练出一个新版本先跑“转换→加载→输出比对”的冒烟流程再谈上线。4.3 切换模型后原对话不停跳闪这个现象看起来像是前端问题但根子在服务端。当你做了多版本模型切换比如AB测试或者灰度发布如果切换时没有保持请求上下文的隐状态一致性客户端极有可能出现“模型答复不稳定、前后内容跳闪”的现象。常见原因有三服务端没保持会话状态每次请求都从新的上下文窗口开始导致模型“失忆”切换模型的tokenizer版本有差异同一个问题分出的token id不同生成的回复自然对不上并发切换时热加载版本不一致同一会话的多次请求落到了不同版本的模型上。排查时我通常先抓请求日志确认同一会话最多被打到几个模型实例上再看tokenizer是否一致如果都是正常的才去审查前端渲染逻辑。这类问题其实也和“AI for AI”有关当你用Agent来自动做模型灰度评测时如果测试链路中的会话隔离没做到位评测结果本身也就不可信了。4.4 常见问题速查表问题现象常见原因优先级推荐排查路径训练loss发散/NaN学习率过高、数据含异常样本、梯度爆炸高降低学习率检查数据开梯度裁剪验证指标不升反降过拟合、训练数据与评测分布不一致高减少轮数增强数据多样性加入正则BN统计量崩溃batch过小、异常样本、统计量监控缺失中调大batch替换Norm层加自动监控模型迁移后输出异常格式转换参数错误、前后处理不一致中统一部署矩阵跑转换冒烟测试切换模型后行为漂移上下文失效、tokenizer不一致、负载均衡漂移高抓请求日志固定会话路由偏好对齐后关键场景退化偏好对分布偏斜、beta设置过大高做分层对比报告针对性补数据合成数据质量不高生成器模型弱、过滤规则过宽中升级生成器收紧规则引入评分模型这张表里的每一行我都对应着一个真实的事故。你可以把它当作初版的排查手册后续根据自己的数据情况持续扩充。5. 一些实操中的心得最后分享几个持续影响我工作习惯的判断。第一中训练和后训练的标配就是评测体系没有评测就不要动模型。哪怕只是一个很小的偏好对齐实验也要在改动前后跑同一组评测样本。很多团队翻车不是因为训练方法不对而是因为压根没有快速发现“翻车”的手段。第二AI for AI的实验闭环必须从第一天就设计好。不要先手工做数据、手工跑训练、手工看case做到第二轮再想自动化。你会发现第三轮开始根本忙不过来。我在一个项目里手工迭代了两次就放弃了改成合成数据自动筛选自动回归评测之后同样的时间内多完成了四轮迭代。第三快速迭代要刻意制造“可对比性”。每一轮实验记录里除了模型版本号还要记录数据构成、学习率、batch、训练步数、评测命令。没有这些元信息的实验过两周就变成一笔糊涂账。我现在甚至会对关键实验生成一份MD格式的manifest里面写着“这轮改了什么、为什么改、结果如何、下一步怎么做”。第四多借助模型来筛数据而不是直接让模型写答案。让模型从候选集合里挑高质量样本比让它凭空生成要可靠得多。实际效果上同一批问题生成式的回答可能有20%不合格但用模型打分挑出来的Top 50%合格率可以到90%以上。这个领域每天都在出新技术今天的中训练技巧可能三个月后就过时了但“用工程方法加速模型迭代”这件事本身是会一直沉淀下来的。希望这篇文章里那些或轻或重的经验能在你下一次跑模型迭代时派上用场。