中训练+后训练：AI for AI最佳试炼场与实操指南

过去半年，我最大的感受是：预训练已经不再是大家茶余饭后的唯一话题，**中训练（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 合成数据驱动的自我迭代

先讲最落地的一环：合成数据。做后训练的人都明白，高质量人工标注数据是稀缺资源，尤其是指令遵循类数据，人工一条条地去写既慢又难保证覆盖度。业内常用的做法是让模型参与到数据生产中来：

1. 用大模型生成一批任务描述，覆盖不同领域的指令；
2. 再让模型根据任务描述生成回答草稿；
3. 用规则过滤器去掉格式错误、长度异常的内容；
4. 最后用评分模型对回答质量做排序和筛选。

这一套流程中，数据生成的模型可以是开源的通用模型，也可以是你正在训练的模型本身。前者适合做增量扩充，后者适合做“自我对弈”式的迭代。我在一个文本摘要项目中实践过自我迭代：先让当前模型对一批文档生成摘要，然后用人工评过的历史数据做偏好对，用DPO训练出新模型；新模型再生成下一轮候选摘要，不断滚下去。效果提升虽然每一步只有一两个点的ROUGE-L增益，但累计五轮之后，摘要的可读性和要点覆盖率都有了质的提升。

2.2 模型评测与回归检测自动化

中训练和后训练迭代得越快，评测就越不能依赖人工。人工当然要看一部分case，但这只能作为定性抽查，不能作为回归决策依据。我的做法是把评测分成三层：

• 第一层：规则评测。针对格式敏感任务，比如JSON输出、表格提取、代码format，用脚本断言结果是否合法，这一层跑得最快，适合在训练过程中频繁调用。
• 第二层：模型评测。用更强大的模型（比如当前能拿到的最强API模型）作为裁判，对生成结果按多个维度打分，比如相关性、完整性、有害性。注意，裁判模型需要做好提示词约束，必要时还要做多模型投票，避免单模型偏差。
• 第三层：任务指标评测。针对具体业务场景跑真实指标，比如检索里的Recall@K、分类任务里的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 步骤一：确定迭代目标和数据构成

开始之前，先定清楚三个问题：

1. 要解决什么缺陷？比如当前模型在售后政策类问题上总是回答得过于笼统，缺少具体的退换货条件和时间限制。
2. 怎么衡量成功？选10个典型售后问题作为“金标case”，要求新模型的回答必须覆盖三个关键实体：时间期限、条件限制、操作路径。
3. 数据从哪里来？中训练阶段准备10万条客服对话原文，后训练阶段准备1.2万条指令问答对，其中6000条人工写过并审核，剩余6000条由模型合成后经规则和分类器筛选。

数据构成这块我要多说一句：不要只堆“对话轮次”，要有意识地制造数据多样性。我常用的做法是按“意图标签”做分层抽样，确保每个意图下都有足够数量的长问题、短问题、带数字的、带情绪化的、中英混输的样本。这样训练出来的模型面对真实用户时不容易顾此失彼。

3.2 步骤二：中训练的关键参数与配置

中训练我用的配置大概是这样（不同底座会有差异，但思路一样）：

• 数据长度：把对话文本按4096 token切段，保留完整对话的上下文，不强行截断到句子中间；
• 训练轮数：1到2个epoch，不需要多，中训练主要目的是“注入领域存在感”；
• 学习率：第一阶段3e-5，第二阶段1e-6，配合warmup ratio 3%；
• Batch size：单卡可承受范围内尽量大，比如8卡A100，global batch 64；
• 优化器：AdamW，权重衰减0.1，梯度裁剪1.0；
• Loss策略：保留语言建模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.3，beta越大，模型对偏好差异越敏感，但容易把模型学“偏”。

这里有一个很实在的经验：偏好对的质量比对数量重要得多。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。

我的排查思路是：

1. 先确认是不是学习率过大导致的，把学习率降一个量级观察几步；
2. 看batch size是否过小，BN在小batch下统计量方差极大，容易失稳；
3. 检查是否有“异常样本”混入数据，比如全黑图片、空文本等，这些样本会让BN的统计量被带偏；
4. 如果确认是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测试或者灰度发布），如果切换时没有保持请求上下文的隐状态一致性，客户端极有可能出现“模型答复不稳定、前后内容跳闪”的现象。

常见原因有三：

1. 服务端没保持会话状态，每次请求都从新的上下文窗口开始，导致模型“失忆”；
2. 切换模型的tokenizer版本有差异，同一个问题分出的token id不同，生成的回复自然对不上；
3. 并发切换时热加载版本不一致，同一会话的多次请求落到了不同版本的模型上。

排查时我通常先抓请求日志，确认同一会话最多被打到几个模型实例上；再看tokenizer是否一致；如果都是正常的，才去审查前端渲染逻辑。这类问题其实也和“AI for AI”有关：当你用Agent来自动做模型灰度评测时，如果测试链路中的会话隔离没做到位，评测结果本身也就不可信了。

4.4 常见问题速查表

这张表里的每一行，我都对应着一个真实的事故。你可以把它当作初版的排查手册，后续根据自己的数据情况持续扩充。

5. 一些实操中的心得

最后分享几个持续影响我工作习惯的判断。

第一，中训练和后训练的标配就是评测体系，没有评测就不要动模型。哪怕只是一个很小的偏好对齐实验，也要在改动前后跑同一组评测样本。很多团队翻车不是因为训练方法不对，而是因为压根没有快速发现“翻车”的手段。

第二，AI for AI的实验闭环必须从第一天就设计好。不要先手工做数据、手工跑训练、手工看case，做到第二轮再想自动化。你会发现第三轮开始根本忙不过来。我在一个项目里手工迭代了两次就放弃了，改成合成数据＋自动筛选＋自动回归评测之后，同样的时间内多完成了四轮迭代。

第三，快速迭代要刻意制造“可对比性”。每一轮实验记录里，除了模型版本号，还要记录数据构成、学习率、batch、训练步数、评测命令。没有这些元信息的实验，过两周就变成一笔糊涂账。我现在甚至会对关键实验生成一份MD格式的manifest，里面写着“这轮改了什么、为什么改、结果如何、下一步怎么做”。

第四，多借助模型来筛数据而不是直接让模型写答案。让模型从候选集合里挑高质量样本，比让它凭空生成要可靠得多。实际效果上，同一批问题，生成式的回答可能有20%不合格，但用模型打分挑出来的Top 50%合格率可以到90%以上。

这个领域每天都在出新技术，今天的中训练技巧可能三个月后就过时了，但“用工程方法加速模型迭代”这件事本身，是会一直沉淀下来的。希望这篇文章里那些或轻或重的经验，能在你下一次跑模型迭代时派上用场。