1. 为什么2025年的Post-Training值得单独立卷先抛一个可能被喷的结论现在大模型项目的分水岭已经从“能不能把基座模型训出来”变成了“后训练做得好不好”。我身边不止一个团队基座模型走的是公开数据加通用配方跑出来的分数大差不差。真正拉开体验差距的反而是后面那一段看似“没有技术含量”的流程指令微调用什么数据、偏好对齐选哪个算法、评测集怎么搭、迭代几轮才敢上线上。2025年6月这份《LLM Post-Training Handbook》之所以值得单独拿出来聊就是因为它把这段最容易靠感觉走的路整理成了可以照着检查的清单。我最早接触后训练这个概念还是在某个开源社区的讨论帖里。当时大家把SFT监督微调之后的步骤统称为“对齐”具体怎么对齐、对齐到什么程度算好没人说得清。后来RLHF基于人类反馈的强化学习那一套被反复验证大家才意识到基座模型的能力天花板有多高很大程度上取决于Post-Training阶段能把地板抬多高。这份Handook面向的读者也很明确手里已经有一个基座模型准备做指令微调、偏好优化、评估迭代的算法工程师和技术负责人。它不讲怎么从零预训练也不讲推理部署专门拆解基座模型到可用产品的最后一公里。如果你现在的项目正卡在“模型看起来什么都会但一用起来就胡说八道”那这篇文章很大程度上就是为你准备的。有意思的是标题里带上了“2025.06”这个时间标记。说明后训练不是一套静态流程它和基座模型一样在快速迭代。这个版本的手册把重点放在了过去半年被验证过的实践上而不是那些只出现在论文里的方法论。这个取舍本身就是经验之谈我后面会详细展开。2. 数据基建后训练七十步数据第一步2.1 指令数据的构成比例别把SFT做成数据堆砌手册第一部分用了很大篇幅讲数据这一点我非常认可。基座模型训练时数据是几百上千亿token硬撑起来的但后训练阶段的SFT数据量通常只有几十万到几百万条。量少就意味着每一条的质量都被放大一条脏数据在预训练里可能只是噪声在SFT里可能就是模型反复模仿的错误行为。我见过最典型的失败案例某团队为了追求指令覆盖的多样性把网上爬来的问答数据直接做规则清洗后灌进SFT结果模型确实变得“健谈”了但回答里全是编造的细节和错误的逻辑链。后来排查发现数据里有一大批写手风格的虚构文章模型学到的是“生成看起来很流畅但完全不可信的内容”的倾向。制作用指南里值得直接抄走的一版配置数据类别建议占比数据来源清洗重点指令遵循类40%人工编写的指令模板结合模型自生成指令与回答的匹配度推理类数学、逻辑25%竞赛题、过程化标注数据解题步骤的完整性知识问答类20%结构化知识库转写事实性核验多轮对话类10%真实客服与角色扮演场景上下文一致性安全与拒答类5%红队测试沉淀拒答而不生硬这个比例不是拍脑袋背后逻辑是SFT的核心目标是让模型学会“怎么回答”而不是“知道什么”。知识在预训练阶段已经灌得差不多了SFT阶段需要强化的是格式、语气、推理链路和边界感。2.2 多轮对话的mask规则最容易被低估的细节手册里提到的对话掩码mask规则是很多新团队最容易忽略的细节。没有经验的做法是把用户消息和模型回答一起参与loss计算结果就是模型学会了预测用户下一句说什么而不是把精力放在生成优质回答上。正确的做法是只对模型回答部分计算loss用户消息和系统提示词全部mask掉。这个规则看起来简单但实际操作中有两个坑。第一个坑是工具调用场景下的mask边界。现在很多模型要走function calling中间会插入工具返回结果的回合。你mask掉工具返回内容后模型如何把工具输出和最终回答之间的因果关系学明白手册的建议是工具返回过程可以参与attention计算也就是模型能“看到”但不参与loss最终自然语言回答才参与loss。经验是很多团队把工具输出也mask了导致模型对工具结果的依赖明显变弱实际使用中经常忽略上下文里已有的工具返回值。第二个坑是屏蔽系统提示词。系统提示词通常是产品经理精调的产物如果参与loss计算模型会把这些提示词当成一种“需要模仿的输出”导致推理时对系统提示词的敏感度焊死。之前测评过一个模型把系统提示词稍微改几个字回答质量立刻崩盘后来一查SFT代码就是没做系统提示词的mask。2.3 数据清洗的“宁缺毋滥”原则手册里关于数据清洗的描述翻译成人话就是一条半脏的数据比缺失十条干净数据更危险。清洗红线至少包含这几类包含潜在个人信息的文本一律去掉不只是隐私问题还会让模型在推理时倾向于“回忆”而非“推理”包含争议性立场的问答即便比例极低也会被模型放大并缓存成一种隐性偏见重复度超过80%的近似句子需要用embedding去重否则SFT会过度学习某些特定句式长度异常比如超过两千字的回答要专门筛查往往意味着混乱的逻辑和强凑的内容。这些细节在指南里只占了很小的篇幅但实际执行起来工作量最大。建议无论团队规模多大数据清洗都要跑两遍第一遍用规则脚本粗筛第二遍人工抽检加模型辅助精筛。别指望一次脚本就能出干净数据凡是写“一把梭”清洗管道的后面都会在评估阶段还债。3. SFT阶段的核心参数与损失设计3.1 超参与损失设计别只看loss曲线数据准备完成后就进入SFT阶段。手册这部分给出的建议不是具体参数值而是一组配套关系的经验法则。很多人喜欢直接问“你SFT用的学习率是多少”但脱离了数据量和模型规模谈参数都是耍流氓。手册给出的经验区间和配套关系值得抄进笔记参数建议区间配套逻辑学习率1e-6 到 1e-57B级别模型数据量大时偏低防止灾难性遗忘batch size有效批次64到128条与学习率强相关batch大则学习率可适当调高训练轮数1到3轮超过3轮开始过拟合指令模板最大序列长度2048到4096取决于业务场景最大输入输出权重衰减0.01到0.05防止SFT阶段权重偏离预训练太远其中最让我有共鸣的一点是SFT阶段的loss下降到0.5以下之后进一步下降往往意味着灾难性遗忘的开始。换句话说SFT的loss不该追求无限逼近0它和预训练阶段的loss诉求完全不同。预训练是学知识loss越低代表压缩得越好SFT是学行为loss过低反而说明模型已经放弃了预训练阶段的广泛能力去死记硬背指令模板了。手册里给了一个很实用的监控组合除了SFT loss还要每500步跑一次基座评测集上的通用任务准确率。如果通用任务准确率出现连续下降说明正在过拟合需要调低学习率、减少训练轮数或者引入一部分预训练数据做混合。这个“SFT loss和通用评测双监控”的做法我在多个项目里验证过非常管用。3.2 拒绝采样的应用SFT数据可以更聪明2025年这版手册里专门强调了一个技巧SFT阶段的数据不是只能来自人工编写也可以用“拒绝采样”来生成。所谓拒绝采样就是让一个已经表现不错的模型甚至就是当前基座模型对指令生成多个候选回答然后用规则或分数模型筛选出高质量答案混合进SFT数据集。这个技巧之所以有效是因为它解决了人工编写数据的一个核心问题人工编写的回答往往过于规范、过于书面化缺乏真实推理过程中可能出现的迂回和修正。模型见过多样化但质量可控的回答后在推理时遇到分布外输入会表现得更稳健。拒绝采样的实施有一些细节每个指令采样8个候选但只保留排名前2的别贪多选择保留的答案评分模型分数要高且与人工编写的风格差异不能太大将模型自生成的高质量回答与人工数据按1比1混合比例太高会让模型变得自说自话比例太低又起不到泛化作用。这个做法在中文社区里讨论得不算多但它对提升模型在长尾指令上的表现作用非常明显。3.3 冻结层与LoRA不是所有参数都需要动手册对参数高效微调PEFT的态度是能用LoRA解决的就别全量微调除非你有非常充足的数据和算力。尤其在SFT阶段全量微调的风险大于收益因为你其实并不想改变模型的知识储备只想调整它的回答风格和行为模式。LoRA的秩rank选择上手册的建议是64到128足够覆盖大多数SFT场景。秩太大训练变慢且容易过拟合秩太小则表示能力不足模型很难学进足够复杂的行为模式。多数情况下我习惯用秩80起步看效果再决定是否调整。还有一个小技巧SFT阶段冻结embedding层和lm_head层能显著降低“模型学会乱改词汇表”的风险。这两个层的参数量大而且微调它们容易导致模型对输入输出的token表征敏感稍微换个同义词就翻车。不过得给个提醒极少数业务场景下——比如目标是把模型训练成某一个特定领域专家包含大量专业术语——保留embedding层的适配也有道理。这时候你需要观察实际评测结果决定不能一刀切。4. 偏好对齐从DPO到多阶段优化的选型逻辑4.1 DPO和PPO/GRPO怎么选才务实偏好对齐这部分是2025年手册更新的重头戏之一。早两年RLHF几乎是标配但RLHF需要单独训练奖励模型数据标注要求高训练过程不稳定。DPO直接偏好优化这类方法把“奖励模型 RL”压缩成一步直接通过偏好对优化策略模型实现简单、训练稳定迅速成了很多中小团队的首选。但手册并没有无脑吹DPO它给了很务实的决策建议方法适用场景主要痛点DPO数据量中等、偏好对质量高、算力有限对超参比较敏感beta值要仔细调PPO有稳定的奖励模型、数据规模大、能接受工程复杂度训练不稳定调试成本高GRPO需要降低RL训练成本、有可复用采样流程多组采样的方差控制需要经验这个选型对照表值得留在团队文档里。我见过不止一个团队在还没把DPO调明白的情况下直接上PPO结果在reward hacking奖励作弊上折腾了两周没进展。另一个团队反其道数据已经超过百万量级且有着打磨过的规则奖励模型还坚持用DPO最后模型在长文本指令上的表现始终差一口气。从工程角度看DPO适合探索期它的失败成本低能快速验证偏好数据是否合理PPO/GRPO适合项目已经进入冲刺期确认数据没问题、奖励模型打分也不漂移的情况下可以进一步榨取性能上限。4.2 DPO超参里的beta值一个决定稳不稳的关键DPO中最重要的超参是beta它控制着对参考模型的惩罚强度。beta越大训练后的模型越靠近参考模型即SFT阶段产出的模型越不容易偏离原始能力beta越小则是允许模型更大胆地优化偏好但风险是生成内容开始退化出现重复、语无伦次或者过度追求风格而牺牲事实准确性。手册给出的实验结论是7B级别模型上beta在0.1到0.5之间是比较合适的探索区间实际调参过程通常是从0.3起步观察训练集准确率和评测集通用任务分数的变化。如果发现通用任务明显下降上调beta并降低学习率而不是直接砍掉训练轮数。这个点让我想起某位技术前辈的经验DPO阶段一旦出现训练loss反常上升先别急着怀疑实现去检查参考模型是不是被不小心更新了。参考模型和策略模型的权重必须严格隔离任何共享参数都会让DPO的对比逻辑失效。这个bug调试起来极其隐蔽模型表面看起来在正常训练实际学到的全是噪声。4.3 多轮偏好数据与“迭代式对齐”2025年手册另外强调了一个趋势偏好数据不能只在单轮问答上做必须包含多轮交互。原因也简单模型在实际产品中的使用场景多轮对话用户的真实拉扯、话题切换、上下文依赖等等单轮偏好数据完全覆盖不到。如果只用单轮数据做DPO模型在多轮场景下容易出现忘记用户上一轮的需求、重复自己的旧回答、或者把上下文里无关信息当成关键约束。手册给出了一个多轮偏好数据的构造思路用基础模型或已有模型模拟多个不同性格、不同职业背景的用户与当前模型开启多轮对话从中截取两轮到五轮不等的对话片段作为偏好对偏好标注不只是给整体回答打分还要标注“在哪个轮次开始偏离用户意图”方便模型学到纠偏点。实际操作中这个方法最大的价值在于能让模型学会在对话中“纠偏”。之前测试过一个小型客服模型初始版本在用户连续两次表达不满后只会重复道歉加入多轮偏好对齐后模型学会了在第二轮尝试给出补偿方案而不是继续道歉体验提升非常明显。4.4 拒绝采样加DPO迭代式对齐的完整闭环最后的对齐流程建议手册给出的路径非常清晰SFT → 拒绝采样 → 偏好标注 → DPO然后循环。这里关键的理解是“迭代”第一轮DPO不需要追求完美目标是产出一个明显优于SFT版本的模型。用这个模型继续生成候选回答做第二轮拒绝采样和偏好标注再进行一轮DPO。每一轮的偏好数据质量都会因为前一版模型能力的提升而提高。这个闭环本质上是用模型自己的能力提升标注数据的上限。很多团队卡在“标注数据不够好”而迟迟不敢做DPO其实可以先跑一轮看评测结果再决定要不要进一步投入标注资源。等数据质量改善了模型也在迭代中逐渐稳定下来。5. 评估体系不骗自己的评测设计5.1 基准测试之外的三个评估维度评估这一章我觉得是整份手册里最容易被略读但又最值得细读的部分。不少团队做完SFT和DPO后第一件事就是跑开源基准测试分数上去了就开始庆祝。但这个习惯很危险因为公开基准测试只覆盖通用能力和你的业务场景中间隔着一条很大的沟。手册建议的评估体系至少拆成三层通用能力层沿用开源基准测试目的是盯住模型有没有灾难性遗忘尤其是数学、代码、常识推理这些容易退化的能力业务场景层从真实产品中采集指令和对话构造脱敏后的评测集模拟用户在业务内的典型用法安全与边界层红队测试覆盖恶意输入、诱导性提问、隐私探测等确保模型在对抗场景下不会失控。很多团队只做了第一层业务场景层靠“感觉”安全与边界层靠“运气”。手册里反复强调一句话评测设计要逼自己面对真实的问题不能精心挑选一个只会显示自身优势的评测集。这句话我举双手赞成评测如果只挑会的题目那评测本身就是自欺欺人。5.2 自动评估与人工抽评的配合比例2025年手册里推荐了一种很实际的做法先用自动评估模型做初筛淘汰明显不合格的样本然后人工抽评保留的样本。自动评估用强模型当裁判主要看格式、相关性、安全约束这三项人工则重点看逻辑一致性、事实准确性和语气自然度。自动评估的具体方式不少团队用打分制让强模型按几个维度给出1到5分。手册提醒几个要点打分时把评分标准写进评测提示词里减少评委模型的主观漂移每个样本取多次打分取平均因为强模型作为评委也存在随机性打分任务和生成任务要做上下文隔离避免模型“自己答完自己打分”带来的测试泄漏。人工抽评的比例不需要太高大概5%到10%但抽评样本要分层高分样本、低分样本、波动大的样本都要覆盖。低分样本更关键能暴露评测集本身的问题比如题目描述歧义、期望答案与实际标准不符等这些都需要针对性地修正业务评测集。5.3 回归测试与发布决策怎么判断“可以上”手册对发布决策的描述贴近实际工程。发布不是追求所有指标都往上走而是在业务关键指标不降的前提下整体体验有所提升。这里有一个很反直觉的结论通用基准测试的分数小幅下降但业务场景评估大幅上升这种情况通常说明模型在业务侧的适配做得对。那怎么判断“小幅下降”的容忍边界手册给了一个实操口径以发布前三个版本的模型为基线记录各项评估分数新模型在通用能力上的下降不超过两个百分点同时业务场景分数至少提升五个百分点这个版本才进入候选发布名单。另外发布前一定要跑一次“回归演练”。把上一版的已经被用户反馈过的问题整理成回归测试集新版模型必须修复已知问题还不能破坏已经正常的功能。没有回归演练的发布本质上是把用户当测试员。我在实际项目里吃过这个亏新模型提升了长文本能力但是把短指令的拒答阈值调高了导致一批正常请求被误拒一周内收到大量投诉。评测不是项目结束后的收尾动作而应该是研发流程的一部分。手册里有一句话很有同感每一天都在跑评测就能提前很多天发现数据污染、超参漂移和偏好过拟合让问题暴露在项目早期而不是发布后。6. 工程化琐事与几段容易挨骂的实话6.1 训练稳定性分开的坑远比想象中多后训练阶段真正耗时间的往往不是模型设计和数据处理而是那些看似基础的工程琐事。多机多卡训练时的通信问题是最大的时间黑洞。数据并行与张量并行混用卡间的通信延迟稍微波动训练速度就会突然掉一半且表现为周期性的卡顿。排查思路很简单但需要耐心先用单机多卡跑一个小规模任务确认模型代码和数据管道没问题再逐步增加节点观察吞吐量变化是否符合预期。一旦在增加节点的过程中发现吞吐量不是近似线性增长优先检查网络拓扑和通信库配置别先去调模型超参。断点续训也是后训练里一个高频翻车点。SFT阶段做了几个小时后中断恢复训练时如果优化器状态没有正确保存后面会看到loss突然跳动。手册特别提醒保存断点时不只是模型权重优化器的Adam状态、学习率调度器的当前步数、随机数生成器的状态全部都要存档。很多框架默认只存权重这就是隐患。6.2 那些反复会踩的“经典坑”关于偏好数据的标注一致性是一个极大的工程黑洞。同一对回答标注员A认为左边好标注员B认为右边好这类不一致数据比例如果超过15%DPO训练的效果就会明显打折扣。别指望标注员天然保持一致必须提前编写非常详细的标注规范并先用一小批数据做一致性检验一致率低于80%就先不要大规模开展标注。另一个高频坑是“评测集污染”。团队在调优过程中反复使用同一个业务评测集模型会在几次迭代后“记住”这些题目的风格导致评测集无法反馈模型真实水平。手册建议定期更换评测集的题目内容办法是把原始评测集按比例留出30%每个迭代周期轮换使用。这个做法模拟了真实考试中的“题库抽题”能有效防止模型在评测集上过度拟合。6.3 后训练的最终交付物不只是模型权重手册的下半部分让我最受触动的是它把后训练的交付物定义为一整套流程而非一个文件。一个成熟的后训练交付包至少应该包含模型权重与对应配置可复现的数据集版本、清洗脚本、标注规范说明SFT与DPO的训练日志、超参实验记录完整的评测报告包括细分的维度、样本示例以及评测集版本已知问题清单和对应的产品规避建议。这个想法非常贴近实际工程。算法团队的人员流动很常见如果所有的经验都装在代码里没有文档人员一变动模型就变成黑盒后续排查和优化都无从谈起。手册里反复强调可复现性本质上是把项目从“靠某个人”变成“靠一套体系”的关键一步。最后说点可能不太中听的实话。如果你所在团队的后训练指标停在70分上不去80%的可能不是算法不行而是数据标注一致性出了问题剩下20%才是超参和模型结构的问题。后训练这件事投入产出比最高的地方始终是数据基建其次是评估体系建设最后才是各种花哨的训练技巧。今年这份手册的价值恰恰在于它用一整卷的篇幅反复验证了这个顺序。