2025年提到LLM Post-Training大模型后训练技术圈的热度已经完全不输给预训练本身。我最近和不少做模型的团队聊下来有个特别普遍的困惑手里有算力、有基座模型甚至预训练流程已经跑得滚瓜烂熟但一进后训练阶段就发懵——不知道该先做SFT还是先做偏好对齐不确定数据要整理到什么程度更不知道怎么判断这一轮训练到底成了没有。这篇文章不是教科书式的综述更像是一份我结合2023年以来在多个开源基座模型和内部项目上反复调整后训练流程的手记。会把2025年年中这个时间点上我认为最值得关注的路径、取舍和坑一次性讲透。适合模型已经训到基座阶段、正准备往后训练走的团队也适合那些已经在做后训练、但总感觉效果忽好忽坏的工程师。1. 先搞清楚后训练到底在解决什么问题1.1 预训练和部署之间那段没人管的距离预训练阶段模型学的核心任务只有一个根据前文预测下一个token。这个目标让模型具备了非常强的语言能力和世界知识但它不天然具备好好配合人类的能力。你问一个刚结束预训练的基座模型帮我写个请假邮件它大概率会顺着语言模式续写出一段莫名其妙的内容甚至反问一句请假邮件是什么——因为它学的只是文本的统计规律不是问题-答案的交互方式。后训练要解决的正是预训练目标与部署目标之间的这段距离。部署场景里用户期望模型能理解指令、遵循格式、拒绝有害内容、在长对话中保持一致。这些能力不是再喂点数据就能自然涌现的而是要靠专门设计的训练阶段去塑造。很多人把后训练简单理解成继续训练这个认知会在后续每个决策点带偏你。1.2 2025年的后训练早已不是一个步骤而是一套体系我在2023年刚接触后训练时很多团队的做法就是基座模型 几千条指令数据 微调一晚上完事。到了2024年大家开始意识到SFT只是起点偏好对齐Preference Alignment成了新的分水岭。到了2025年年中成熟的后训练流程已经明确分成了几个互相咬合的环节数据工程指令数据、偏好数据的采集、清洗、配比指令微调SFT让模型学会以指令-响应的方式工作偏好对齐让模型的回答更符合人类偏好常用RLHF、DPO或GRPO评估与迭代不止看指标还要做人评、回归测试和消融这四个环节里任何一个做崩了整体效果都会打折扣。我见过不止一个团队花大价钱做偏好对齐结果发现SFT阶段的数据格式就没统一导致对齐阶段模型反复精神分裂。后训练是一套体系不是几个孤立脚本的拼接。2. 数据工程后训练效果的第一决定因素2.1 指令数据的来源与取舍策略先说一个我反复强调的观点后训练阶段数据质量的重要性远大于数据数量尤其对于SFT来说尤其如此。我做过一个对照实验一份经过仔细筛选的5万条指令数据效果明显好过直接抓取的100万条噪声数据。原因是模型在SFT阶段学的是行为模式而不是知识——它不需要你给它看一万种错误的回答方式来学习。指令数据的来源常用就这么几类公开指令数据集社区里已有不少整理好的数据集但用之前必须自己洗一遍不能直接拿来就训合成数据用更强的模型生成指令与回答然后人工抽检、修正。这是目前最主流的方式成本和效率最平衡人工撰写质量最高但成本也最高一般只用于核心场景或种子数据业务日志如果你做的是真实产品产品里的用户query和优质回答是最宝贵的数据千万别浪费面对一批候选数据我习惯按下面这个优先级过滤过滤维度具体做法说明指令清晰度删除指代不明、无法独立理解的指令模型学到的是含糊问题配含糊回答的坏习惯回答质量至少抽检10%确保回答与指令强相关混入无关回答会让模型学会答非所问格式一致性统一对话模板、标点、换行风格格式混乱会直接干扰偏好对齐阶段难度分布保留一定比例的高难度推理样本全是简单问答会把模型养懒2.2 去重、污染检测与格式统一数据清洗里最容易被低估的是去重。很多人以为重复数据顶多多花点算力事实是重复样本会在SFT中造成严重的过拟合。一个样本出现50次模型就会把它当成标准答案死记下来。我建议至少做两轮去重第一轮是文本层面的MinHash去重把近似重复的样本抓出来第二轮是和预训练语料的交叉去重避免评测数据泄漏进训练集。污染检测这块我要单独提醒。一个非常常见的翻车现场是评测集里的题目出现在训练数据里模型在评测指标上表现好得惊人一到真实场景就露馅。我处理这个问题的方法是在训练前把所有评测集的题目和训练数据做一次embedding级别的相似度比对超过阈值的直接剔除。这一步不能省尤其是从公开数据源拼数据的时候。格式统一说起来简单做起来却特别费人。同一个数据集里可能出现中文全角逗号和英文半角逗号混用、markdown层级混乱、系统提示词和用户消息错位等问题。模型对格式非常敏感SFT阶段格式混乱到了偏好对齐阶段就会表现为改一个beta参数效果剧烈波动——因为模型根本没形成稳定的行为模式。2.3 数据配比与课程学习指令数据的配比我倾向于业务导向 能力平衡两条腿走路。如果产品重点是代码助手代码类数据占比自然要高但也不能完全砍掉通用对话否则模型的泛化能力会退化。一个我常用的起始配比是通用对话40%、代码25%、数学推理20%、结构化任务摘要、改写、抽取15%。这只是起点实际要根据评测结果动态调。关于课程学习我的经验是简单在前、硬核在后的渐进式安排确实有效但不要做得太复杂。简单地把数据按难度排序先训低难度后训高难度比一次性打乱喂进去收敛更稳。2025年还有一个趋势是把多轮对话作为SFT的主训练形态因为真实用户的交互几乎都是多轮的如果只在单轮指令上训练模型在上下文里的记忆-引用能力会明显偏弱。3. SFT教模型像个干活的样子3.1 SFT的本质是行为克隆不是知识注入关于SFT圈子里最大的误解就是多喂高质量问答模型就变聪明了。实际上SFT阶段能注入的新知识极其有限。模型在预训练阶段已经学完了绝大部分知识和语言能力SFT做的是行为对齐——教它如何根据指令组织回答、如何遵循格式、如何呈现推理过程。这个认知直接决定你该怎么做数据你的样本价值不在于这个答案多渊博而在于这个回答方式是不是产品需要的。我筛数据时反复提醒自己和团队不要在SFT阶段塞一堆冷门知识那是预训练和持续预训练该干的事。SFT数据里的每条回答都应该像示范动作让模型看了之后知道遇到这类指令就该这么干。3.2 超参数、上下文长度与轮数控制SFT的超参数我直接给一份从多个项目里沉淀下来的经验值参考参数常用区间说明Epochs1~3超过3轮极易过拟合除非数据量特别小学习率1e-5 ~ 2e-5全参LoRA时可以放宽到1e-4量级批量大小按显存能塞下的最大值尽量大SFT的梯度噪声本来就大最大长度2048~8192取决于业务最长输入别盲目拉长权重衰减0.01左右轻微正则防止极端权重轮数控制是新手最容易翻车的地方。我见过一个团队把SFT跑到5个epoch结果模型回答变得过于机械每个回答都像在背模板多样性明显下降。后来我们把epoch压到2配合early stopping效果立刻改善。判断是否过拟合的办法很简单每个epoch存一个checkpoint用一套固定的评测集横向对比看哪个checkpoint的综合表现最好而不是盲目训满。上下文长度这块我建议按需设置。如果产品场景就是短对话硬把训练长度拉长到8192只会浪费算力如果要做长文档处理那么训练数据里就应该有足够比例的长样本并且要关注模型在长上下文下的注意力衰减问题。3.3 全参微调vs参数高效微调怎么选2025年LoRA这类参数高效微调方法的使用已经非常普遍但我仍然建议分层使用实验探索阶段用LoRA最终上线版本优先全参微调。LoRA的优势是显存友好、实验成本低可以快速试不同的数据配比、不同的超参数组合。我在项目的前期阶段会并行跑好几个LoRA实验用一套固定的评测prompt快速淘汰低质量的数据配置。但LoRA有两个问题一是它的表达能力有上限在复杂推理任务上LoRA微调的最终效果往往比全参微调差一点二是LoRA和多轮偏好对齐的叠加效果有时候会出现两个低秩近似互相抵消的情况。所以我的习惯是LoRA用来探路全参用来收官。确定好最终数据recipe之后用相同的超参数跑一次全参微调通常能再稳定提升几个点。如果你的显存不够全参微调可以考虑加序列并行、激活重计算这些技巧或者干脆租更大显存——后训练阶段这点钱不该省。4. 偏好对齐RLHF、DPO、GRPO到底怎么选4.1 从RLHF说起管线长、效果好、成本高偏好对齐的经典方案是RLHF它的完整管线包括训练一个奖励模型Reward Model来模拟人类偏好分数然后用强化学习算法通常是PPO让语言模型在这个奖励信号下优化策略。这条路线效果最稳定尤其是需要在探索中提升的任务上RLHF的天花板明显更高。但RLHF的代价也摆在那里一是奖励模型本身需要大量人工偏好标注标注质量直接影响上限二是PPO训练过程敏感学习率、KL惩罚系数、优势裁剪这些超参数一旦没调好loss曲线就会上蹿下跳三是显存和训练时间大约是SFT的2~3倍。考虑到这些成本我的建议是如果团队有成熟的强化学习经验且对模型上限要求极高RLHF仍然值得投入否则从DPO或者GRPO这类轻量方案入手更务实。4.2 DPO的兴起与它的边界DPODirect Preference Optimization之所以在2024年之后流行核心原因是它把奖励模型强化学习两步合并成了一步直接优化偏好概率。它不需要单独训练奖励模型也不需要在线采样和PPO更新实现简单、训练稳定可以说是低成本版本的对齐方案。DPO的边界我在实战中体会很深。它对偏好数据的质量极其敏感——如果pair里chosen和rejected的回答差距不大或者被选中的回答实际上并不明显更优DPO会把这种噪声偏好也学进去甚至导致模型变得谄媚、啰嗦。DPO还容易过拟合训练轮数稍微多一点点模型输出就会失去多样性。我的经验是吃DPO的数据质量对比RLHF更苛刻至少要保证每个pair都经过清洗且chosen-response与rejected-response之间确实存在可感知的优劣差异。4.3 GRPO与RLOO2025年真正在用的轻量在线方案2025年的一个明显趋势是大家不再把DPO和RLHF看成二选一而是大量使用GRPOGroup Relative Policy Optimization和RLOOReinforce Leave-One-Out这类中间路线。GRPO的思路是不依赖独立的价值网络Critic而是通过对同一prompt采样一组response用组内相对表现作为baseline来估计优势。这样既保留了在线RL的探索能力又省掉了Critic模型的训练成本。对那些有代码生成、数学推理这类可以自动判分任务场景的团队来说GRPO几乎成了默认选择——你甚至可以直接用单元测试或规则打分作为奖励信号让模型在训练中自己摸索出更好的解题策略。RLOO类似也通过组内留一法来估计收益不需要Critic模型。这类方法在70B以下规模模型上尤其好用训练稳定性比PPO好不少成本却只是略高于DPO。我的建议是如果你的任务可以自动化打分优先考虑GRPO/RLOO如果只能靠人工偏好标注DPO仍然是性价比最高的入门选择。4.4 选型对照表与我的实践结论为了直观我把主流方案的对比整理成一张表方案成本稳定性数据要求天花板推荐场景RLHF (PPO)高低奖励模型标注量大高追求极致效果且有RL经验的团队DPO低高偏好pair质量要求极高中高快速上线、偏好标注质量有保障GRPO中中高可自动打分的任务高代码、数学、多步推理RLOO中中高可自动打分或规则判分高中大模型的在线对齐如果你的预算和时间都有限我建议的路径是先SFT跑一个baseline再上DPO看看收益如果DPO有效但不够稳再切换到GRPO或者RLHF。不要一上来就全链路RLHF那样往往把大量时间耗在调参上而问题可能根本不在算法——在数据。5. 评估与迭代怎么判断这轮训练成了5.1 从基准测试到真实任务评估集要自己攒后训练阶段最忌讳的评估方式是只盯着公开benchmark的分数。公开榜单上的题目大概率出现在预训练数据里即便做了污染检测它仍然无法反映你的真实业务场景。我坚持的做法是自建一套包含200~500条prompt的评测集覆盖产品里的典型用户请求、边界case和反例。这套评测集的设计很讲究。不要只放正常问题一定要包含模糊指令用户没说清楚、长上下文要求对话历史很长、格式约束要求输出JSON或表格、拒绝场景用户问不该答的内容。我通常在SFT开始之前就把这套评测集固定下来之后所有实验都在同一套prompt上对比防止用不同的尺子量身高。5.2 消融实验与回归测试后训练流程中我最常做也最建议做的实验是消融对比同一份SFT数据分别跑只SFT和SFTDPO/GRPO看偏好对齐阶段到底带来了多少真实收益。很多时候你会发现DPO在某些评测项上提升了回答吸引力却在另一些项上让模型变得不敢直接给结论。没有消融对比你根本不知道问题出在哪个阶段。回归测试同样重要。后训练最常见的副作用是灾难性遗忘——对齐阶段提升了某个能力却把SFT阶段学到的另一种行为给覆盖了。我见过一个项目数学推理能力在GRPO之后上了一个台阶但对话的亲和力明显下降回答变得冷冰冰的。这种情况必须通过固定的回归评测集及时发现否则等上线被用户骂回来就晚了。5.3 迭代节奏与checkpoint管理后训练的迭代节奏我总结出的经验是小步快跑、每步可验证。具体来说SFT阶段每次调整数据recipe跑完立刻评测核心指标别攒着一堆实验一起看结果那样根本定位不了问题偏好对齐阶段每几百步存一个checkpoint然后对这些checkpoint做全量评测抽样人评。人评环节我强烈建议保留。自动化指标再丰富也替代不了真实人类对这个回答读起来舒不舒服的判断。我在项目里会固定一组5~8人的评测小组每周抽半天时间用盲评的方式给不同checkpoint的回答打分。这些分数不要追求统计学上的完美它的价值在于给你方向感——告诉你这轮迭代是在变好还是变坏。Checkpoint管理看似小事做不好却会出大事故。我的习惯是每个checkpoint都记录完整的实验元信息数据版本、超参数、loss曲线、评测结果写成一张简单的实验表格。别小看这张表它能帮你在几周后快速复盘为什么那次效果崩了也能在团队协作时避免两个人跑同样的实验浪费算力。6. 我踩过的坑和一些可以抄作业的经验6.1 SFT数据里混入神仙回复的问题早年做SFT数据时我喜欢把那些特别详尽、特别完美的回答选进训练集觉得让模型学最好的总没错。后来发现这个思路有害如果训练数据里全是神仙回复——每一条都写成长篇大论的教科书级答案模型学到的反而是不管用户问什么都长篇输出的习惯。真实用户问现在几点时不需要你写800字的论文。后来我调整了策略SFT数据里的回答要贴近实际部署状态。问答短的就该短能一句话说清的绝不用两句话。模型学的是分配表达长度的能力而不是每条都往长了写。6.2 偏好数据里的标签噪声DPO会如实学进去偏好数据的人工标注质量远比很多人以为的低。我在一个项目里做过抽检发现大约8%~12%的偏好标注是随意标的——标注员根本没有认真对比两个回答的优劣或者对领域内容不熟悉凭感觉选了chosen。这个比例在DPO训练里会被直接放大模型会把错误偏好当成真理学进去最后表现为回答风格偏激忽视安全约束。应对办法没有捷径一是加大对标注员的培训给出清晰的对齐标准二是对pair做交叉验证比如两个人标注同一条pair不一致的拿出来讨论三是定期在训练完成后做偏好一致性的抽检发现模型在某类问题上出现系统性偏差回头查对应的偏好数据。这是一个反复循环的过程没有一劳永逸。6.3 后训练的算力规划与时间预期很多团队在规划后训练算力时只算了SFT一遍的成本严重低估了迭代的消耗。我习惯把后训练总成本按SFT的3~5倍做预算其中1份给SFT1~2份给偏好对齐剩下的都留给评估、消融和返工。这不是浪费——后训练本质上是个实验驱动的工程你不跑足够的实验就找不到最优配置省下的算力会以上线效果不行重新训练的形式加倍还回来。时间预期上也要放平心态。一个70B规模模型的后训练从数据准备到最终定版两周到一个月都是正常的。如果哪个环节快得出奇往往意味着某个质量检查被跳过了。6.4 最后的体会回看这两年做的那么多后训练项目我最大的感受是后训练不是一个跑完脚本就收工的工序而是一套需要反复试错、持续积累的工程体系。数据、算法、评估三者的权重在我心里大约是5:3:2数据永远是最大的杠杆。你在SFT数据、偏好数据上多花的一分心思最后都会在模型表现上拿到回报反过来算法再先进也救不了脏数据。如果你现在正准备启动后训练我的最后建议是先花两周把评估集扎扎实实建好把数据清洗流程跑通再做任何训练实验。磨刀不误砍柴工这个顺序我还没见过反着来能成功的。