项目进度走到 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_size=2, gradient_accumulation_steps=16, learning_rate=5e-6, max_length=1024, max_prompt_length=512, beta=0.1, logging_steps=10, save_steps=200, num_train_epochs=2, fp16=True, ) dpo_trainer = DPOTrainer( model=model, ref_model=None, # 不指定时默认使用 model 创建参考模型 args=training_args, train_dataset=train_dataset, tokenizer=tokenizer, ) 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_map="auto", torch_dtype=torch.float16) eval_file = "./data/eval_set.jsonl" results = [] with open(eval_file, "r", encoding="utf-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_prompt=True, return_tensors="pt" ).to(model.device) output_ids = model.generate( input_ids, max_new_tokens=512, do_sample=False, temperature=None, top_p=None, ) response = tokenizer.decode(output_ids[0][input_ids.shape[1]:], skip_special_tokens=True) results.append({ "instruction": prompt, "gold": sample.get("output", ""), "prediction": response, }) with open("./eval_results.json", "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2) print("Evaluation finished.")这个脚本输出的 eval_results.json 就是后续人工抽评和错误分析的输入。要注意的是，自动评测脚本本身需要保证可重复性，生成时关闭采样（do_sample=False），否则同一道题两次评测结果不一致，无法做回归对比。
6.3 回流机制
评估结果不能只是“看完写个报告”，它必须回流到数据侧和训练侧。每轮评测的错误样本，应经过分析后分门别类：数据质量问题进入数据清洗流程；模型能力短板进入下一轮训练数据构造清单；评测标注错误则修正评测集。
回流机制的闭环程度，直接影响多轮训练的效率。
7. 多轮训练常见问题与排查方法
多轮训练有一个其他机器学习项目不常见的特点：每一轮训练都可能让模型“变笨”。这在当前的大模型训练中并不少见，下面几个问题是项目后半程最容易遇到的。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 第二轮训练后，领域准确率下降 | 偏好数据中混入错误知识；DPO 训练过度改变了模型输出分布 | 对比第二轮训练前后的领域评测分数；检查偏好数据的 chosen 是否在事实上正确 | 清洗偏好数据；在偏好数据中加入明确的事实约束 |
| 多轮训练后回复变得千篇一律 | 多轮偏好数据引导模型走向“安全但无聊” | 观察模型在开放性问题上的输出多样性；检查重复率 | 减少偏好训练轮次；调整 beta；在偏好数据中加入多样性样本 |
| 新数据训练后旧能力明显遗忘 | 数据配比失衡；学习率过高 | 用回归集做全量测试，找到衰减最严重的任务类型 | 加入旧任务数据的回放（replay）；降低学习率；使用混合数据训练 |
| 自动评测分数在涨，人工体验反而变差 | 自动评测规则过于简单；模型机械套用评测偏好 | 重新审查评测指标和标注标准；增加人工盲评 | 优化评测 prompt；增加人工评估权重；设计更细粒度的评分维度 |
| 训练 loss 正常下降，但评测输出全是空内容 | 生成参数与训练参数不匹配；tokenizer 的 pad 设置有问题 | 检查生成阶段的特殊 token 处理 | 在生成时设置 pad_token_id=eos_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% 时，恰恰是精修阶段最关键的窗口期——所有前面的训练成果，都要在这里接受最终考验。
