大模型多轮训练：从SFT到RLHF的迭代精修指南

项目进度走到 90% 的时候往往是最容易产生“马上就能上线”错觉的阶段。尤其是大模型算法项目模型能跑了、loss 在降、示例对话看着也挺像样很多人就会觉得剩下的只是部署和接口联调。但如果你真的做过大模型训练就会知道训练层面的 90%距离能力层面的 90% 还有很长一段路。这篇文章想聊的是“多轮训练”这件事。它不是简单地把同一批数据多跑几个 epoch也不是把训练脚本重复执行几次。多轮训练的本质是围绕“训练-评测-分析-迭代”这个循环分阶段、有目标地提升模型能力。当项目进度推进到 90% 时多轮训练真正要解决的问题已经从“能不能学会”变成了“学得对不对、稳不稳定、敢不敢上线”。如果你正在做大模型 SFT、RLHF 或对齐相关的项目或者在组织一条大模型训练流水线这篇文章会从训练轮次设计、数据组织、评估回流、常见坑和工程最佳实践几个角度讲清楚多轮训练为什么是项目后期质量的关键抓手。1. 为什么单轮训练很难把模型能力拉满很多团队做垂直领域大模型第一次训练都会选择 SFT监督微调。这个阶段的目标很纯粹让模型学会你给它的指令格式、领域表达方式和基础任务逻辑。比如你做了一个法律问答模型第一轮 SFT 就是让模型从“通用助手”变成“懂法条、能按专业格式输出”的助手。但单轮 SFT 的问题在于它假设“数据覆盖了什么模型就掌握了什么”。这在数据量充足、任务边界清晰、测试集和训练集分布一致的情况下勉强成立。真实业务场景远没这么理想同一种问题可能有十种问法同样的法条在不同上下文里有不同的解释用户不会按你预设的指令模板说话。所以你会看到单轮训练后的模型经常出现三个典型问题过拟合到训练模板换一种句式问同样的问题模型就答不出来了。知识记忆和推理能力脱节模型能复述训练数据里的结论但无法处理需要多步推理的新问题。行为和评测指标不一致自动评测分数不错人工体验却觉得回答生硬、模板化。多轮训练的价值恰恰是在第一轮训练跑完之后通过评测发现问题、补充针对性数据、调整训练目标再做第二轮甚至第三轮训练。它更像“精修”而不是“搬运”。换句话说单轮训练决定一个模型能力的上限起点多轮训练决定这个模型是否真的可用。2. 多轮训练不是重复训练核心概念与设计逻辑先明确一个容易混淆的点。多轮训练iterative training / multi-round training和“多轮对话训练”是两个概念。多轮对话是指模型在对话历史中理解上下文而多轮训练指的是模型训练流程本身分多轮迭代。本文讨论的是后者。一个典型的多轮训练过程包含以下组成部分轮次训练方式核心目标常见任务第一轮SFT / 继续预训练建立领域基础能力和指令理解指令微调、领域知识注入第二轮RLHF / DPO / RLAIF对齐人类偏好提升回答质量和稳定性偏好学习、有害内容拒答第三轮定向 SFT / 增量预训练解决评测暴露的特定短板格式错误修复、推理能力增强、长文本处理每一轮训练之间穿插着评测、错误分析、数据构造和超参调整。这个“训练-评估-分析-再训练”的循环才是多轮训练的核心。从算法角度理解多轮训练的优势在于分阶段优化目标。SFT 阶段模型学的是“什么样的输出是正确答案”RLHF 阶段模型学的是“什么样的输出是更受偏好的答案”。两者的优化目标不同混在一起训练会互相干扰。先后分层模型能力更容易收敛。从工程角度理解多轮训练让项目管理更可控。每一轮都有明确的验收指标第一轮看指令遵循和领域准确率第二轮看人类偏好胜率和安全指标第三轮定向修复后看回归测试。一旦某轮训练失败你可以单独回滚到上一轮 checkpoint而不是推翻整个训练流程。3. 第一轮训练建立基础能力的 SFT 阶段第一轮 SFT 决定模型的“地基”。这个阶段最常见的误区是数据越多越好、任务越全越好。实际上第一轮训练更讲究数据质量和配比。3.1 数据组织以 jsonl 格式为例一条标准的 SFT 训练数据长这样{ instruction: 请解释合同中的违约责任条款应当包含哪些要素, input: , output: 违约责任条款通常应包含以下要素违约行为的具体定义、违约责任的承担方式继续履行、采取补救措施或赔偿损失等、违约金数额或计算方式、免责事由以及争议解决机制。在起草该条款时还应当考虑合同双方的实际履约能力和法律规定的强制性要求。, task_type: domain_qa }字段含义不复杂instruction 是用户指令output 是期望模型输出的答案input 可用于补充上下文。task_type 是任务类型标签它会参与后续的数据配比和评测分组非常重要。3.2 第一轮训练的关键配置训练超参因基础模型、数据量和硬件而异。下面是一份基于 DeepSpeed ZeRO-2 的 SFT 配置示例适用于单机多卡训练场景# 文件路径configs/sft_stage1.yaml model_name_or_path: /path/to/base_model train_file: ./data/stage1_train.jsonl validation_file: ./data/stage1_eval.jsonl per_device_train_batch_size: 4 per_device_eval_batch_size: 4 gradient_accumulation_steps: 8 learning_rate: 2e-5 num_train_epochs: 3 lr_scheduler_type: cosine warmup_ratio: 0.03 logging_steps: 10 save_steps: 500 eval_steps: 500 evaluation_strategy: steps save_total_limit: 3 fp16: true deepspeed: ./ds_config/zero2.json这里有两个细节值得注意。第一学习率不宜过高SFT 阶段通常建议在 1e-5 到 3e-5 区间过高会让模型遗忘预训练阶段学到的通用能力。第二训练轮数不能盲目增加常用做法是 2 到 4 个 epoch更多轮数容易过拟合到训练数据。3.3 判断第一轮训练是否成功第一轮训练之后先用验证集跑一次评估。重要指标包括指令遵循率模型是否按要求的格式输出。领域问答准确率专业知识是否正确。通用能力保持度用通用评测集检查模型是否出现严重的“灾难性遗忘”。如果指令遵循率没问题但领域准确率偏低通常说明领域数据覆盖不足需要补充训练数据而不是加大训练轮次。如果通用能力明显下降说明学习率过高或数据配比失衡需要调整数据中领域数据和通用数据的比例。4. 第二轮训练用偏好对齐解决“能答但答不好”第一轮 SFT 之后模型已经具备了基本的领域能力。但你会开始发现另一个问题模型虽然不犯错但回答啰嗦、没有重点、语气不对、安全边界模糊。这就是“能力有了行为不对”。第二轮训练的核心是对齐人类偏好。当前主流方案有两种RLHF基于人类反馈的强化学习和 DPO直接偏好优化。RLHF 需要训练奖励模型工程链路过长DPO 不需要显式奖励模型直接基于偏好数据优化策略对中小团队更友好。4.1 偏好数据怎么准备偏好数据的核心是“同一道题两个回答一个更好”。示例{ instruction: 用户因产品质量问题要求退换货但已超过商家承诺的退换货期限如何处理, chosen: 首先需要核实产品是否存在质量问题以及退换货期限的约定。如果质量问题属于产品固有缺陷即使超过期限消费者仍可根据法律规定主张权利……, rejected: 已经超过期限了没办法处理。建议用户自行联系商家协商。 }构造偏好数据时要注意一个原则chosen 和 rejected 应该是“都好但一个更好”而不是“一个对一个错”。如果 rejected 是明显错误回答模型学到的只是“不要输出错误答案”而不是“输出更优质的答案”。这会导致模型在边界场景下仍然表现平庸。4.2 DPO 训练的代码示例# 文件路径train_dpo.py from datasets import load_dataset from trl import DPOTrainer, DPOConfig from transformers import AutoModelForCausalLM, AutoTokenizer model AutoModelForCausalLM.from_pretrained(/path/to/sft_stage1_checkpoint) tokenizer AutoTokenizer.from_pretrained(/path/to/sft_stage1_checkpoint) tokenizer.pad_token tokenizer.eos_token dataset load_dataset(json, data_files./data/stage2_preference.jsonl) train_dataset dataset[train] training_args DPOConfig( output_dir./outputs/stage2_dpo, per_device_train_batch_size2, gradient_accumulation_steps16, learning_rate5e-6, max_length1024, max_prompt_length512, beta0.1, logging_steps10, save_steps200, num_train_epochs2, fp16True, ) dpo_trainer DPOTrainer( modelmodel, ref_modelNone, # 不指定时默认使用 model 创建参考模型 argstraining_args, train_datasettrain_dataset, tokenizertokenizer, ) dpo_trainer.train() dpo_trainer.save_model(./outputs/stage2_dpo_final)这里的 beta 是 DPO 算法中的温度参数控制对偏好差异的敏感度。beta 越大模型越倾向于严格遵循偏好数据但可能牺牲多样性beta 越小模型输出更自由但偏好对齐效果可能不够明显。实际项目中可以从 0.1 开始尝试根据评测结果微调。4.3 第二轮训练容易忽略的问题第二轮训练后需要特别警惕“奖励黑客”现象。模型可能会找到一种在偏好评估中拿高分、但实际并不更好的输出策略比如刻意使用冗长句式、堆砌专业术语。这也是为什么第二轮训练之后必须做人工抽样评估不能只信自动指标。5. 第三轮训练定向修复评测暴露的短板如果前两轮训练进展顺利项目这时候才真正接近标题里说的“90%”。但剩下的 10%往往是决定项目能否落地的关键。第三轮训练的驱动力不再是通用能力而是评测命中率。把第一轮和第二轮的模型放在评测集上跑一遍你会得到一份错误分析报告。常见的问题类型包括格式类模型回答没有按指定 Markdown 或 JSON 格式输出。逻辑类多步推理过程中出现中间错误。知识类特定领域的知识回答错误或过时。安全类对敏感问题没有拒绝回答。第三轮训练就是针对这些问题构造定向训练数据。例如评测发现模型在做复杂数学应用题时经常跳过中间步骤直接写答案那么第三轮训练可以专门构造一批“带完整的思考链”的训练数据。这类数据的构造方式可以借助强模型生成初稿再人工校验{ instruction: 一家公司去年的销售额为500万元今年比去年增长了20%但成本增加了30%。已知去年成本为300万元求今年的利润是多少, output: 先计算今年销售额500万 × 1.2 600万。再计算今年成本300万 × 1.3 390万。最后计算利润600万 - 390万 210万。因此今年的利润是210万元。 }第三轮训练的重点是小批量、高针对性。数据量通常只有第一轮的十分之一甚至更少但每一批数据都要精准打击评测中发现的错误类型。训练完这轮之后再跑同一份评测集观察修复率和回归率。6. 质量评估与回流机制多轮训练的心脏如果没有一套可靠的评估机制多轮训练就退化成“盲目调参”。项目进度能否从 90% 走到 100%评估体系的设计比训练本身更重要。6.1 评估集怎么设计建议将评估集分为三块评估集来源用途Holdout 集训练前隔离不参与任何训练或数据筛选判断模型是否过拟合回归集历轮评测中暴露问题的汇总确保旧问题不复发新能力集本轮训练目标对应的评测用例判断本轮目标是否达成Holdout 集是很多团队的盲区。因为多轮训练中往往会把上一轮评测发现的错误数据直接加进训练集这时如果没有 Holdout 集就无法判断模型是真正学到了泛化能力还是只是记住了错误数据的正确答案。所以训练之前就应该隔离一部分数据全程不碰。6.2 自动化评测脚本一个尽量简单的评测脚本如下# 文件路径evaluate.py import json from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_path ./outputs/stage3_final tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModelForCausalLM.from_pretrained(model_path, device_mapauto, torch_dtypetorch.float16) eval_file ./data/eval_set.jsonl results [] with open(eval_file, r, encodingutf-8) as f: for line in f: sample json.loads(line) prompt sample[instruction] messages [{role: user, content: prompt}] input_ids tokenizer.apply_chat_template( messages, add_generation_promptTrue, return_tensorspt ).to(model.device) output_ids model.generate( input_ids, max_new_tokens512, do_sampleFalse, temperatureNone, top_pNone, ) response tokenizer.decode(output_ids[0][input_ids.shape[1]:], skip_special_tokensTrue) results.append({ instruction: prompt, gold: sample.get(output, ), prediction: response, }) with open(./eval_results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) print(Evaluation finished.)这个脚本输出的 eval_results.json 就是后续人工抽评和错误分析的输入。要注意的是自动评测脚本本身需要保证可重复性生成时关闭采样do_sampleFalse否则同一道题两次评测结果不一致无法做回归对比。6.3 回流机制评估结果不能只是“看完写个报告”它必须回流到数据侧和训练侧。每轮评测的错误样本应经过分析后分门别类数据质量问题进入数据清洗流程模型能力短板进入下一轮训练数据构造清单评测标注错误则修正评测集。回流机制的闭环程度直接影响多轮训练的效率。7. 多轮训练常见问题与排查方法多轮训练有一个其他机器学习项目不常见的特点每一轮训练都可能让模型“变笨”。这在当前的大模型训练中并不少见下面几个问题是项目后半程最容易遇到的。问题现象可能原因排查方式解决方案第二轮训练后领域准确率下降偏好数据中混入错误知识DPO 训练过度改变了模型输出分布对比第二轮训练前后的领域评测分数检查偏好数据的 chosen 是否在事实上正确清洗偏好数据在偏好数据中加入明确的事实约束多轮训练后回复变得千篇一律多轮偏好数据引导模型走向“安全但无聊”观察模型在开放性问题上的输出多样性检查重复率减少偏好训练轮次调整 beta在偏好数据中加入多样性样本新数据训练后旧能力明显遗忘数据配比失衡学习率过高用回归集做全量测试找到衰减最严重的任务类型加入旧任务数据的回放replay降低学习率使用混合数据训练自动评测分数在涨人工体验反而变差自动评测规则过于简单模型机械套用评测偏好重新审查评测指标和标注标准增加人工盲评优化评测 prompt增加人工评估权重设计更细粒度的评分维度训练 loss 正常下降但评测输出全是空内容生成参数与训练参数不匹配tokenizer 的 pad 设置有问题检查生成阶段的特殊 token 处理在生成时设置 pad_token_ideos_token_id并检查 apply_chat_template要特别提醒的是遇到问题时先不要急着调超参。先看数据再看代码最后才调参数。大模型训练中绝大多数异常现象根因都出在数据侧而不是模型结构或优化器。8. 多轮训练的工程最佳实践把多轮训练的算法逻辑落地到流水线里还需要一些工程层面的保障。这里列几条在项目后期价值较高的实践建议。8.1 训练数据留白多轮训练中每一轮都会加入新的训练数据。如果训练集采用“完全累积”的方式数据规模会越来越大训练成本不可控而且容易过拟合到历史错误修正数据。建议给每一轮数据设置保留策略上一轮修错数据的核心部分保留但允许剔除已被模型稳定掌握的部分。留白才能让模型有空间泛化。8.2 双池评估机制除了常规的 Holdout 集建议再准备一个“真实用户问题池”。这个池子里的数据可以来自线上日志、用户反馈、客服系统而不是人工构造的评测用例。双池评估的好处是人工评测集评估的是“模型有没有达到我们的预期”真实用户池评估的是“模型能不能回答用户真正关心的问题”。两者的分数落差往往就是多轮训练下一轮的数据方向。8.3 使用增量训练模式多轮训练不是每次都从头训练。如果第一轮训练耗时数天第二轮完全从零开始会造成大量算力浪费。更推荐的做法是从上一轮 checkpoint 继续训练并显著降低学习率。这要求训练流水线从一开始就做好 checkpoint 保存策略建议每个轮次保存至少 2 到 3 个中间 checkpoint方便回溯。8.4 日志与可复现多轮训练持续数周甚至数月如果中间换人接手项目很容易“断档”。训练日志应记录的不只是 loss 曲线还应该包括本轮训练数据统计样本量、任务分布、训练超参、评测报告、错误分析结论、下一轮计划。每轮训练独立建立目录确保任何人拿到目录就能复现本轮训练结果。8.5 安全与合规底线这里强调一个容易在项目后期被忽略的问题多轮训练涉及的数据和模型权重必须纳入统一的权限管理和版本控制。训练数据中如果包含用户个人信息数据脱敏和访问控制必须在前置阶段完成。模型本身如果具备生成代码、操作数据库、执行系统命令的能力上线前要做完善的权限隔离和内容安全测试。大模型项目在推进度时安全边界宁可收紧不能放水。9. 下一步怎么走回到文章开头的“90%”这个数字。一个大模型算法项目走到 90% 意味着什么从多轮训练的角度看它意味着模型的基础能力已经建立偏好对齐已经完成定向修复也基本到位。剩下的 10%其实是更考验耐心和工程能力的工作回归测试、边界条件遍历、极端输入验证、上线后的监控与反馈循环。如果你刚准备开始一个多轮训练项目我的建议是先不要追求三轮以上。先跑通第一轮建立评估基线再决定第二轮要不要做、怎么做。很多团队在第一轮之后发现模型表现已经能满足 80% 的业务需求那么第二轮的优先级就不是“提升能力”而是“建立安全的拒绝回答机制”和“统一输出格式”。多轮训练的每一步都应当由评测结果和业务需求驱动而不是为了“多轮”而多轮。模型的训练就像打磨一把刀第一轮锻造成型第二轮开刃第三轮精修。锻造成型是基础开刃是让它好用精修则决定它能不能成为一件称手的工具。大模型项目进度走到 90% 时恰恰是精修阶段最关键的窗口期——所有前面的训练成果都要在这里接受最终考验。