★ FEATURED ARTICLE 开篇手头一个内部项目用的是某开源基座模型通用榜单跑分不算差可一丢进真实业务场景——用户随便问两句业务相关的它就开始一本正经地胡说。这个团队找我的时候很困惑以为是基座模型不够强想换更大的版本。我看了一眼他们的训练记录问题根本不在预训练而在post-training压根没做到位。所谓LLM Post-Training就是基座模型在预训练完成之后通过指令微调、偏好对齐、上下文适配、工具调用等一系列手段把“会说话的模型”改造成“能用、好用、符合业务要求的模型”。这恰恰是2025年多数开源模型落地项目里最决定成败、也最容易被低估的阶段。这篇文章我想按我自己的实操经验把后训练这条链路完整地拆一遍数据怎么做、算法怎么选、训练超参怎么调、评测怎么闭环、以及从训练到上线这最后一公里有什么要注意的。适合手上已经有基座模型、正打算自己调模型的团队也适合想系统理解后训练到底在干什么的人。全文基于我做过的大大小小十余个开源模型后训练项目踩过的坑和沉淀下来的方法都会直接写出来尽量不讲正确的废话。1. 后训练到底在解决什么问题预训练负责“学会”后训练负责“可用”1.1 预训练和后训练的分工逻辑预训练阶段模型在海量文本上做自回归预测本质上是在学“语言本身是什么样”。这就像一个人读了大量书知识储备很丰富但你直接问他问题他并不知道该怎么组织回答——因为读书和对话是两码事。基座模型出厂的“综合能力”、世界知识、推理底子都在预训练里定型了。但“能回答”和“很好地回答问题”之间隔着一整条后训练流水线。后训练覆盖的东西其实很宽不只是很多人理解的“喂点问答对”。指令跟随、拒答策略、对话格式、角色一致性、工具调用、JSON输出约束、安全合规对齐甚至对某个垂直领域术语的偏好表达都是后训练阶段做的事。如果预训练决定了一个模型的天花板那后训练决定的是这个天花板能被兑现多少。我见过不少团队模型换成更大的基座效果没怎么涨问题就出在这里——预训练能力在那但后训练没把能力引导出来。一个直观的类比预训练是在铸造一把刀的坯子后训练是开刃、配柄、做热处理。坯子不够好怎么磨都有限坯子够好却不磨那就是个铁疙瘩看着能用实际没法用。2025年的开源基座模型普遍很强真正的差距往往就在“磨刀”的技术上。1.2 为什么2025年过后训练的位置变了前几年大家一说微调模型第一反应就是“拿几千条数据做SFT”。那时候的效果确实立竿见影因为基座模型本身就不怎么会对话简单教一教就有巨大提升。但现在开源基座的对话能力已经普遍不错了基础的SFT早就不是什么门槛。要进一步提升业务场景的真实表现更多要依赖偏好对齐、强化学习、长链路推理这些偏后期的技术。一句话总结这个转折过去后训练是“从0到1”的加持现在是“从1到10”的精细雕琢。这意味着同样的SFT操作效果可能比两年前小得多——不是退步了是基座本身变强了边际收益变了。我在一个项目里把SFT数据从5万条减到1.2万条业务指标不降反升就是因为在基座能力上来的情况下过量的指令微调反而容易损害模型原有的泛化能力。2. 数据工程后训练里最容易被轻视的胜负手2.1 不是数据越多越好SFT数据的选择与配比聊到后训练数据我被问得最多的就是“要准备多少条才够”。这个问题的答案很反直觉以2025年的基座模型水平SFT阶段的高质量数据量通常在5000到20000条之间就足够覆盖大多数垂直场景。某次我做金融客服场景初始数据8万条清洗去重之后剩不到9000条训练出来的模型效果反而好得多。原因不复杂大量重复、低质量、标注不一致的数据会让模型学到的是“平均水平的错误”而不是特定任务的正确模式。选什么数据才是真正的功夫。我总结出三条原则多样性优先于数量、难度梯度优先于均匀分布、真实用户语料优先于凭空造数据。多样性要覆盖用户表达习惯、任务类型、边角情况模型没见过某类问法后训练再多的相同问法也补不上。难度梯度则是刻意保留一些长上下文、多轮纠错、模糊意图的样本让模型在训练里见过“难缠的用户”。至于真实语料这个优先级强调再多也不为过——我自己在几个项目里做过对比用真实脱敏用户语料构造的指令数据在业务评测上的表现普遍好于用模板批量生成的合成数据。2.2 被忽略的对话格式与模板一致性这个坑我连续踩过两次非常值得单独说。后训练数据的对话格式必须和推理时用的chat template严格一致否则模型会学到怪异的行为。比如训练数据里系统提示词用的是A模板推理时框架默认用的是B模板模型就会把B模板当成正常输入的一部分来处理表现出来的症状是“前言不搭后语”或者“拒绝回答”。实操时有个更隐蔽的细节数据里角色的命名和顺序要一致。一个批次里如果既有“system→user→assistant”三段式又有“user→assistant”两段式又没有控制比例模型会在长对话里逐渐迷失该输出的内容会在第二个turn就结束。我现在的做法是数据管线入口就强制校验消息角色序列跑训练前还会抽样渲染出完整的模板对比结果人工过一遍。这个步骤只多花半个小时能少走好几天的弯路。2.3 数据质量审查的几个实操信号很多人会问“怎么快速判断一批数据行不行”我给出三个可以量化的信号。第一个是交叉内容重复率不只是全句重复还要做语义向量层面的近似去重。同一个问题换个说法出现几十次模型会被带偏只学会复读机式的回答。第二个是答案长度分布正常指令数据应该长短都有如果你发现绝大多样本都是几十个字以内的短答案说明数据集里缺少复杂的推理样本模型会越训越“懒”。第三个是意图覆盖度拿一个预先准备好的意图清单大概几十类就行对数据做分类统计凡是覆盖度低于八成的高频业务意图都得补数据。还要提一句合成数据的用法。大模型生成合成指令作为辅助是高效的但别让它成为主力尤其不能让它淹没真实语料。某项目里我试过70%真实加30%合成效果尚可反过来30%真实加70%合成业务指标立刻往下掉。合成数据的问题在于风格太规整、太“模型腔”真实用户根本不会那么说话。3. 从SFT到偏好对齐算法选型的真实演进逻辑3.1 SFT的边界模仿不等于对齐SFT的本质是监督模仿它教会模型的是“看到某个输入应该输出什么”。这在对话风格、格式化输出、基础指令跟随这类任务上非常有效训练成本低、稳定性好、迭代快。但它的天花板在于SFT无法让模型区分“好答案”和“更好的答案”。模型学会的是训练集里的平均输出水平而不是判断能力本身。简单场景比如让模型把一段文本改写成三句话摘要SFT完全够用。复杂场景比如开放域问答、创意写作、需要价值判断的客服回复SFT训练出来的模型会显得“应付”答案不算错但不够好。这个问题的根源不是数据不够而是监督信号本身的局限。到了这一步就得考虑偏好对齐。3.2 RLHF效果上限的高成本路线经典RLHF流程分四步SFT基座、训练奖励模型、用强化学习优化策略、迭代评估。我最早尝试RLHF是在一个垂直问答项目上效果确实比SFT有可感知的提升尤其是回答的信息密度和“言之有物”程度上。但代价非常实在需要至少几十万条带偏好排序的数据来训练奖励模型而且要准备多个奖励模型候选做对比强化学习阶段的训练极其不稳定我见过同一条奖励模型情况下连续跑了三次一次收敛一次发散一次波动到底。PPO算法对超参极其敏感连随机种子都可能影响最终结果。在小规模场景里我通常建议把RLHF放后面考虑。它适合那种“答案质量的上限决定产品竞争力”的场景比如通用对话助手、代码生成、复杂推理类任务。如果你做的是垂直业务问答评分标准相对固定用轻量级的偏好对齐方法往往性价比更高。3.3 DPO与它的近亲轻量偏好对齐的取舍DPODirect Preference Optimization的出现几乎可以说是把偏好对齐从大厂特权变成了小团队也能用的常规武器。它不训奖励模型、不做强化学习采样直接拿“好答案 vs 差答案”的偏好对去更新策略本身。我在某代码助手项目里用DPO只用了四万多条偏好对效果接近此前一套完整RLHF流程的八成以上训练开销却只有前者的零头。DPO也有它的麻烦。最典型的是偏好过拟合训练轮数稍微多一点点模型就开始疯狂压低被选为chosen的答案的损失导致输出极端化甚至出现重复、啰嗦、表达过度自信的毛病。控制训练步数、适当降低学习率、或者在偏好数据里加入一些复杂样本都可以缓解这个问题。我见过有些团队跑完DPO后模型变笨了其实不是DPO不对而是条件没控好训练过头了。除了DPOKTO这类不需要成对偏好数据的算法也有价值。实际业务里“绝对打分”往往比“两两对比”更容易获取KTO在这种场景下比DPO更好落地。我给团队的建议是别迷信某一个算法手头什么数据形式方便就选择对应的算法路线。3.4 不同场景下的算法选型对照场景类型数据条件推荐路线参考规模固定格式输出、风格迁移几千条问答对即可SFT3000-10000条开放域回复质量提升有几万条偏好对DPO30000-60000对代码/推理等长链路任务有奖励模型标注能力或偏好数据RLHF / 多阶段DPO偏好对越多越好绝对话术价值判断场景有绝对评分但难成对KTO20000-50000条选型不是选最“高级”的而是选最匹配你数据和迭代速度的。后训练讲究的是闭环迭代快——你今天的模型上线明天收集badcase后天就该增量训练。要是每一步都卡在“算法太复杂、数据要求太高”上面迭代速度就拖死了效果。4. 训练过程的火候把控超参、监控与调参经验4.1 学习率和epoch最常见的翻车点后训练超参里最容易被低估的两个是学习率和训练轮数。很多团队拿着平时跑预训练或从头训练的经验来调上来就是epoch10、learning_rate1e-4结果模型训完变得“油嘴滑舌”原来的世界知识都开始遗忘。问题的本质是后训练是在一个已经充分收敛的模型上做“手术”幅度必须小、火候必须轻。以7B到14B参数规模的模型为例SFT阶段我常用的初始配置是学习率1e-5到2e-5之间训练轮数1到2轮全参数训练或2到3轮LoRA训练。DPO阶段学习率通常要压低到5e-6到1e-5训练步数按偏好对数量一般是几百到两千步。这只是个起点关键判断依据是验证集损失曲线。SFT阶段如果第二个epoch的验证损失不降反升说明该停了DPO阶段如果chosen侧损失掉太快、rejected侧损失也同步掉说明边界条件还行但如果rejected侧涨得离谱那就已经过拟合了。我的习惯是训练过程中间隔固定步数跑一次小规模评测集比如每500步跑一次。只用最终损失做决策太滞后中间接入评测信号才能尽早发现问题。4.2 全参数还是LoRA按场景选别跟风LoRA在2025年依然是大部分垂直场景的后训练主力训练快、显存省、可以快速切换多版本。但“轻量”不等于“完全够用”。某次在一个领域术语极其密集的项目里全参数SFT比LoRA的最终评测高了接近五个点差异主要在术语引用准确率和长文结构稳定性上。原因不复杂LoRA的低秩约束本身就是在限制模型参数更新的表达能力当任务需要大量调整内部知识粒度的关联时低秩更新可能不够用。反过来在另一个人机对话风格调整的项目里LoRA和全参数的结果几乎没差别。这类任务改的是表达习惯不涉及深层知识重排LoRA的轻量化优势就非常明显。我的一般建议是第一个版本用LoRA快速跑通数据流程、验证评测口径等数据稳定了再考虑要不要全参数精调一版。对于小参数量模型或者任务涉及领域知识密度很高时就直接上全参数。4.3 损失曲线之外还有什么值得盯损失曲线只能反映训练本身的状态不能反映模型真实表现。两套后训练配置可能在训练损失上近似最终业务效果天差地别。我现在的做法是盯三个额外指标第一个是输出长度分布。SFT后如果平均输出长度大幅增长或收缩通常是格式控制出了问题比如模板把“继续输出”带偏了。第二个是拒绝率。做安全对齐或拒答训练后要盯“过度拒绝”的比例模型可能学会了把所有不确定的请求都拒掉这在业务上近乎灾难。第三个是知识遗忘信号。可以准备一组通用知识题在训练前、中、后分别跑一遍如果某个通用题从对变错说明后训练已经损害了基座原有能力需要调整数据配比或者降低学习率。5. 评测闭环没有标尺的调优就是盲调5.1 三层评测体系是怎么搭的我有一次帮某团队做复盘发现他们调了整整两周模型但唯一的变化依据是“感觉回答变好了”。这完全没法评估。后来我给他们搭了一套三层评测底层是通用基准集用来检测模型的通用能力有没有明显退化中间是业务能力集对应垂直场景的高频任务和典型难题顶层是开放式对抗集专门准备一些模糊、长尾、对抗性的问题。三层各有各的作用。通用基准集是“体检”业务能力集是“面试”对抗集是“压力测试”。业务能力集的建设尤其重要它不是一次性工程而是要和你的数据管线一样持续迭代。每次线上收集到的新badcase经过筛选去重后都应该趁早进到评测集里。评测集的平均分可以作为门槛条件但更重要的是里面的分类型分析——哪个题型下降了、哪个领域退步了这些细分信号直接指导下一轮的数据补充方向。我需要提醒一点公开榜单分数只能作为一个粗糙的参考别作为决策依据。某开源模型在某榜单上表现不佳但在我们垂直评测里全面领先另一个高分模型原因就是榜单题目分布和业务分布差异太大。5.2 评测集建设的具体方法评测集要能真正反映业务就不能只从网上找“现成的标准题”。最靠谱的办法是从真实用户对话里采数据挑出那些标注过好坏、或者经过人工修正过的样本然后再加一部分构造的边界case。方法上我建议至少保持评测集里有三成是真实用户原始提问而且提问的原始形态不要做过多改写——用户口语化的、不完整的表达本身就是评测中宝贵的一部分。规模上业务能力评测集我一般控制在300到800道题之间太少不稳定太多迭代成本高。同时要保留一个固定版本的评测集用于回归每次训练结束都在同一份评测集上跑分否则不同版本之间没法对比。再准备一个持续扩充的“候选池”候选池验证过的题就可以定期消化进稳定评测集。这样既能避免评测集的缓慢漂移又能保证新问题被覆盖到。5.3 模型漂移与回归测试模型训练的决策在整个生命周期里都会持续发生因此变量管理格外重要。没有变量管理你根本不知道某个改动是模型变好了还是数据换炮了。我见过不止一次团队开发完一个版本后业务分明明涨了但通用题掉了一堆这就是没有做好回归测试。模型漂移不是一次性发生的它是每一次增量训练后的慢性损耗跑分不会立刻崩但是积累个几个版本就会突然暴露在线上。我的习惯是每个候选版本上线前都跑一遍固定回归集对比上一版本。一旦发现通用能力上的明显掉点就在当前迭代里分析原因而不是留到以后再查。线上A/B的时间至少要预留几天到一周并且要提前定义清楚核心观测指标避免看一百个指标最后被噪声左右。6. 从训练到上线后训练是迭代工程不是一次性项目6.1 数据回流闭环才是后训练真正的发动机回到开头那个项目我帮团队把模型调出了一个能用的版本但真正的改变发生在后续的一个月——线上持续收集badcase每周做一次筛选聚类选出一批高质量的补充数据做增量训练周五发布来周一观察数据。跑完三轮这样的循环后业务核心指标才真正稳定下来。数据回流闭环的流程很固定线上日志抽取、脱敏和隐私过滤、badcase分类与标注、对比上一版模型确认确实是回归或未覆盖的新case、把新case筛进训练集和评测集、重新训练与评测、发布与观察。每一步都要有明确的负责人和工具链支撑这在团队协作里很重要。很多后训练项目死在的不是算法阶段而是这一步没做好导致模型一直停留在“第一个版本完善后的样子”。6.2 版本迭代与灰度观察的最小必要配置后训练版本的发布最好搭配一套“小流量观察回滚预案”。我不建议直接全量替换线上模型因为你离线评测做得再充分也覆盖不了线上用户的全部真实情况。小流量观察期间可以重点看三件事线上badcase的比例变化、核心任务的成功率、以及有没有出现“新错误类型”——比如原本很正常的短答案突然变成长篇大论。与此同时要把模型版本、数据版本、训练配置全部记录下来最好是每次训练自动生成带变更列表的报告。后训练是一个高度工程化的迭代型过程阶段复盘时需要能回答三个问题这版本根据什么数据催生的训练中里改了什么参数上线后核心指标变了多少三个问题缺一个复盘就沦为猜测。6.3 小技巧拿“差分模型”当诊断工具我去年在一个模型调试项目里试了一个特别有用的思路对同一份训练前的基座和训练后的模型跑同一批测试题把所有输出两两对齐人工只检查输出差得最大的那些样本。这个方法能非常高效地暴露模型被“改坏了”的地方。不需要看全部输出只需要看二三百个差分显著的case就能判断这次改动的主要影响面是什么。另一个类似思路是用“对比测试集”做定向诊断。比如你想知道模型是变笨了还是变钝了就构造几组同义改写、换数字、换人名的问题看模型对变异输入的行为是否稳定。这类零成本小技巧在训练迭代里的作用被很多人低估了实际上比盯着损失曲线来得直观得多。写到最后的一些实在话做后训练这一年多以来我自己最大的体会是别急着问“用什么算法”先问“数据和评测稳不稳”。绝大多数项目翻车不是算法选错而是两侧的底座没搭好。好的后训练工程师先把数据流程和评测闭环建设好再谈怎么调超参、怎么上偏好对齐每一步都能验证每一步都能回退。先找个具体、边界清晰的业务场景跑通整条链路在闭环里慢慢进化要比一开始就追求大而全的解决方案稳妥得多。
阅读完成 · 觉得有帮助？
