大模型光会“接话”还不够，得让它“听话”。这两年做AI应用落地，我越来越深的一个体会是：从预训练基座模型到能真正上线的对话助手，中间那道最关键的工序就是“加强训练”，也就是强化训练这条技术链路。今天围绕 TRL、RLHF 和 SFT 这三个词，结合我自己跑通的完整示例，把这套东西从头到尾捋一遍——它是什么、解决什么问题、代码怎么写、坑在哪里。面向正在做大模型微调、RLHF 对齐，或者刚接触 TRL 库准备上手的开发者，这篇文章应该能帮你少走不少弯路。
1. 为什么预训练模型必须再“训一轮”
1.1 基座模型只会“续写”，不会“回答问题”
很多人第一次拿到开源基座模型（比如只做了预训练的 checkpoint）时，都会有一个困惑：为什么问它问题，它回答得驴唇不对马嘴，甚至开始编故事？其实这不是模型“笨”，而是它的训练目标决定的。预训练阶段模型学的就是“给定上文，预测下一个 token”，本质上是一个超级强大的文本续写器。你跟它说“你好，请问今天天气怎么样”，它的第一反应不是去查天气，而是顺着“天气”这个话题继续编一段像模像样的天气预报，甚至把“你好”后面的内容续成一封邮件。这跟产品需要的“指令遵从”能力之间，隔着一条巨大的沟。
这条沟怎么填？靠的就是对齐（Alignment）技术。对齐的目标很朴素：让模型的输出符合人类的意图、偏好和价值观。落到工程实现上，主流路线就是 SFT（监督微调）加上 RLHF（基于人类反馈的强化学习），后者在2023年前后因为一系列大模型产品的成功而广为人知。把这两个词拆开看：SFT 解决的是“让模型学会指令格式”，RLHF 解决的是“让模型在开放式生成中学会权衡取舍”。
1.2 一套完整链路：SFT、RM、RLHF 各管哪一段
我习惯把大模型上线前的训练分三段看。第一段是 SFT：拿一批高质量的“人类提问 + 标准回答”数据，让模型把“提问 → 回答”的映射关系学进去。这一步做完，模型已经具备了基本的对话能力，但它的回答风格、安全边界、偏好倾向还没有被精细校准。第二段是训练奖励模型（Reward Model，RM）：让模型学会给不同回答的质量打分，这个打分信号就是后面强化学习阶段的“老师”。第三段才是 RLHF 的核心——用强化学习算法（通常是 PPO）去优化策略模型，让模型在每一轮生成中都倾向于产出奖励模型认为“更好”的回答。
举个例子类比一下：预训练模型像一个博览群书但没有社会经验的应届生，SFT 是入职培训，告诉他“别人问你什么，你要按什么格式答”；奖励模型是公司里的绩效评分体系；而 RLHF 则是把这套评分体系和员工的晋升机制绑定，让他在实际工作中不断调整行为，去追求高分。这三段缺一不可，而且每一段都有自己独立的技术难点。
1.3 直接回答“为什么不用纯监督学习”
有人会问：既然有 SFT，为什么不直接弄几百万条人工标注的高质量问答把模型训练到位，非要绕一大圈做强化学习？这个问题我在实际项目里也纠结过。核心原因有两个。第一，高质量人工标注数据太贵了，要覆盖开放式问题的所有合理回答风格，成本根本扛不住。而 RLHF 只需要标注“哪条回答更好”，这种对比式的标注比从零写标准答案便宜得多，而且更容易保持一致。第二，SFT 在训练时只能教模型“模仿某个固定答案”，但模型在推理阶段面对的问题是开放的，同一个问题可以有很多种同样正确但风格迥异的回答。SFT 没法告诉模型“在这个维度上你要偏好什么”，强化学习却可以通过奖励信号教会模型在连续的动作空间里做权衡。这也是为什么越往后做对齐，大家越依赖 RLHF 这类技术的原因。
2. SFT：地基打不牢，后面全是白干
2.1 SFT 数据准备的三个关键点
想做“加强训练”，第一关就是 SFT 数据。数据质量直接决定了模型能力的天花板，这不是空话。我在实操中总结出三个要点：
- 格式统一。所有样本都统一成“指令 + 回复”的结构，上下文中如果有对话历史，也要明确拆分成 system / user / assistant 三个角色。格式越规整，SFT 阶段模型学得越快，后面 RLHF 也不容易被奇怪的 prompt 干扰。
- 难度要有梯度。样本里既要有“简单指令”（比如“翻译这句话”），也要有硬骨头（比如“分析这份数据的潜在偏差”）。如果全是简单样本，SFT 之后模型只会处理模板化任务；如果全是复杂样本，小模型根本学不动。
- 覆盖真实使用场景。我见过不少团队 SFT 数据跟线上真实请求完全脱节，结果做出来的模型在内部测试集上表现挺好，一放到真实环境中就露馅。这一点在构造数据时要尤其警惕。
关于样本量，网上说法从几千条到几万条都有，实际取决于任务复杂度。我自己从 5k 数据起步，加到 50k 之后收益明显变缓，再往上的边际收益就很低了。与其盲目堆量，不如花时间清洗掉低质量、重复、有隐性偏见的样本。
2.2 全参微调 vs LoRA：选错成本翻倍
SFT 的工程实现也分好几条路线。传统做法是全参微调（Full Fine-tuning），把模型所有参数都更新。效果好，但对显存的要求极其苛刻——一个 7B 模型做全参微调，单卡 40G 显存几乎跑不起来，通常要上多卡并行，还得配合 ZeRO 之类的分布式优化。
我的建议是：小模型（3B 以下）且显存充足时可以做全参微调；7B 以上的模型用 LoRA 或 QLoRA 更划算。LoRA 的原理是在原有权重旁边加上低秩可训练矩阵，把训练参数量压到原来的千分之一甚至更低。我做过一组对比实验：在一个 7B 模型上，LoRA 训练效果在绝大多数评测维度上跟全参微调差距很小，但显存占用直接从 70G 降到 25G 左右，训练时间也缩短了一大截。QLoRA 则在 LoRA 基础上把基座模型用 4-bit 量化存起来，显存需求进一步降低到 12G 级别，单张消费级显卡就能训。
2.3 SFT 训练参数实测心得
数据准备好之后，训练超参数同样值得精调。我的经验值是这样：
- 学习率：全参微调用 1e-5 到 2e-5 之间；LoRA 因为可训练参数少、分布稳定，可以用稍大的学习率，比如 2e-5 到 5e-5。
- Epoch：SFT 不需要训很多轮，2 到 3 个 epoch 往往就够。小数据集上如果超过 5 个 epoch，模型几乎必然开始对训练集过拟合，后面做 RLHF 时容易出现“复读机”症状。
- Batch size：在显存允许的范围内尽量大。如果只能用小 batch，记得相应调低学习率，否则训练会不稳定。
- 序列长度：对长上下文的场景，序列长度直接决定模型能看到的上下文窗口，不要为了省显存把长度压得太多，否则收益失真。
注意：SFT 阶段一定要保留独立的验证集，不能只看训练 loss。我踩过最大的坑就是训练 loss 很低、但验证集上的生成质量一塌糊涂，原因就是数据里的噪音被模型强行背下来了。训练时每隔几百步做一次生成质量抽查，比盯 loss 曲线管用得多。
3. RLHF 原理拆解：三个模型接力跑
3.1 把语言生成变成强化学习问题
进入 RLHF 之前，得先把强化学习那套术语跟语言生成对上号。在强化学习里，智能体（Agent）在环境（Environment）中采取动作（Action），环境返回奖励（Reward），智能体根据奖励调整策略（Policy）。对应到语言模型中：策略就是语言模型本身，动作就是每一个生成出来的 token，环境是上下文和已经生成的内容，状态是当前已经生成的前缀。模型每生成一个 token，可以看作在策略驱动下采取一个动作，整段生成结束后拿到一个总奖励——这个总奖励通常来自奖励模型对整段回答质量的打分。
用强化学习去优化语言模型，最大的理论难题是：语言生成是离散的、不可微的，标准的反向传播没法直接把奖励信号传回生成过程。PPO 算法（近端策略优化）解决了这个问题：它不要求生成过程可微，而是通过策略梯度来估计奖励信号对模型参数的梯度方向，然后用一个裁剪目标函数保证每次参数更新的幅度不会过大。
3.2 奖励模型：RLHF 的“灵魂”
奖励模型（RM）在整套系统里扮演老师角色。训练 RM 的数据形式和 SFT 不一样：SFT 需要“问答对”，RM 需要“同一个 prompt 下两组不同回答 + 哪组更好的标注”。这里有个细节值得注意：标注人员给的偏好分数并不绝对可靠，所以标准做法是在损失函数里加入一个 margin，让模型对“明显更好”的答案给出更高分、对“差不多好”的答案不要强行拉分。
我自己的经验是，RM 的数据量不必像 SFT 那么多，但质量要求反而更高。标注不一致的数据对 RM 的伤害远大于对 SFT 的伤害，因为 RM 的优化目标就是拟合人类偏好，数据里自相矛盾的偏好会把模型训成一个“和事佬”——给什么回答都打差不多的分。
RM 的训练也不能只盯着准确率。更重要的是看分数分布是否合理，我一般会统计 RM 对“明显高质量”“中等质量”“明显低质量”三类回答的打分区间，如果分布挤在一起，说明 RM 没有学到足够的区分度。这种 RM 拿到 RLHF 阶段，会让 PPO 无所适从。
3.3 PPO 阶段：actor / ref / reward / critic 四模型协作
到了 PPO 这一步，事情开始变得复杂。一个完整的 PPO 训练流程里，同时存在四个模型：
- Actor 模型：真正要被优化的策略模型，也是最终要部署的模型。
- Reference 模型：训练前 Actor 的初始版本，全程冻结权重。它的作用是给 PPO 提供 KL 散度的参照点，防止 Actor 跑得太远。
- Reward 模型：给 Actor 生成的回答打分。
- Critic 模型：估计每个状态下未来收益的期望值，为 PPO 计算 Advantage（优势函数）提供服务。这也是最容易让新手困惑的一个角色——可以把它理解为“评论家”，告诉策略模型“这一步做得比预期好还是差”。
整体流程大致是：Actor 根据当前的 prompt 生成一段回答 → Reward 模型给这段回答打分 → 同时计算 Actor 与 Reference 模型之间的 KL 散度 → 总奖励 = RM 打分 − KL 惩罚项 → Critic 模型估计 Advantage → 用 PPO 目标函数更新 Actor 和 Critic。
3.4 KL 散度惩罚到底在防什么
KL 散度惩罚是 RLHF 里最容易被低估的设计。如果没有它，Actor 会很快在奖励模型的打分漏洞上钻空子——比如发现回答里堆砌某个华丽词汇能让 RM 给高分，就会疯狂产出这种“高分垃圾”。KL 惩罚的作用是给 Actor 的更新套上缰绳，不允许它偏离 Reference 模型太远。换句话说，RLHF 不是让模型无边无际地追求高分，而是在“保持原有语言能力”和“迎合人类偏好”之间找一个平衡点。
KL 系数调大，模型会变得保守，学不到太多新偏好；调小，模型容易奖励黑客。我通常从 0.02 到 0.1 之间开始搜索，观察 KL 均值的变化曲线——如果 KL 均值一直在涨且停不下来，说明系数太小了；如果训练了很长时间 KL 都没什么波动，说明系数太大，模型基本在原地踏步。
4. TRL 库快速上手：从零跑通一个 RLHF 示例
4.1 为什么选 TRL 而不是自己实现 PPO
强化学习训练语言模型在工程上非常繁琐，自己从零实现一轮 PPO 光是把“采样生成、奖励打分、GAE 计算、策略更新”这几个环节衔接起来，就足够让人崩溃。我更推荐直接使用开源的 TRL 库。它是针对 Transformer 语言模型设计的训练工具，高度封装了 SFT、RM、PPO、DPO 等流程，接口简洁，迭代活跃，社区反馈样本多，踩坑信息也容易搜到。
4.2 环境安装
安装方面建议用虚拟环境隔离。PyTorch 版本和 Transformers 版本要匹配，否则容易出现算子不兼容的问题。
pip install transformers datasets accelerate peft pip install trl新版 TRL 对 Python 版本的要求比较严格，建议 Python 3.9 以上。如果只用基础功能，trl 会拉取一些稍微重的依赖，但都可以接受。想跑 PPO 的话，还需要单独的trl示例代码里常用的torch分布式功能，这里我用单机单卡演示，已经足够说明全流程。
4.3 示例场景：让模型学会“简短又有礼貌”的回复
我的 demo 设计得尽量简单：训练基座模型学会在收到指令时给出“简短、礼貌、不带多余废话”的回答。之所以选这个场景，是因为效果很容易主观评估，而且即使小规模训练也能看出前后差异。
完整的数据流是：SFT 阶段用几千条（指令 + 回复）数据让模型适应问答格式；RM 阶段用同场景下的偏好对训练打分模型；PPO 阶段用 RM 的分数奖励 Actor 输出礼貌而简短的回复。下面分步写出关键代码。
4.4 SFT 阶段的 TRL 实现
在 TRL 中，SFT 可以直接用SFTTrainer。需要把数据集整理成包含instruction和output字段的格式。我的数据样本长这样：
{"instruction": "帮我写一段产品介绍", "output": "好的，这是您需要的产品介绍，简洁明了。"}用SFTTrainer训练：
from trl import SFTTrainer from transformers import AutoModelForCausalLM, AutoTokenizer model = AutoModelForCausalLM.from_pretrained("your-base-model") tokenizer = AutoTokenizer.from_pretrained("your-base-model") tokenizer.pad_token = tokenizer.eos_token trainer = SFTTrainer( model=model, tokenizer=tokenizer, train_dataset=dataset, max_seq_length=512, args=TrainingArguments( output_dir="./sft_out", per_device_train_batch_size=4, learning_rate=2e-5, num_train_epochs=2, logging_steps=20, save_steps=500, fp16=True, ), ) trainer.train()这里有一个新手容易忽略的点：SFTTrainer会自动帮你把instruction和output拼接成训练格式，但不同模型对应的 chat template 不一样，如果基座模型带特殊的角色标记（比如<|user|>、<|assistant|>），最好在数据处理阶段就显式处理，只靠默认拼接在 openai 格式的模型上会出问题。
4.5 RM 阶段的 TRL 实现
TRL 提供了RewardTrainer，输入数据的格式是同一个 prompt 下两条回答以及哪个更好。训练样本：
{"prompt": "帮我写一段产品介绍", "chosen": "好的，这是您需要的产品介绍...", "rejected": "产品介绍写作要点包括以下几点：第一...第二..."}RewardTrainer的核心训练逻辑是让chosen的得分高于rejected的得分：
from trl import RewardTrainer rm_model = AutoModelForSequenceClassification.from_pretrained( "your-sft-model", num_labels=1, ) trainer = RewardTrainer( model=rm_model, tokenizer=tokenizer, train_dataset=rm_dataset, args=TrainingArguments( output_dir="./rm_out", per_device_train_batch_size=4, learning_rate=1e-5, num_train_epochs=3, fp16=True, ), ) trainer.train()RM 模型用的不是最终的生成模型结构，而是一个带打分头的序列分类模型。这意味着需要把 SFT 模型加载成AutoModelForSequenceClassification，并且模型里新增的score参数会随机初始化，需要跟着训练更新。
4.6 PPO 阶段的 TRL 实现
PPO 阶段 TRL 提供了PPOTrainer，这也是整套流程中代码量最集中的部分。核心流程是：拿一组 prompt，让 actor 生成回答，然后用 RM 给回答打分并计算 KL 惩罚，最后用trainer.step完成参数更新。
from trl import PPOTrainer, PPOConfig from transformers import AutoModelForCausalLM, AutoModelForSequenceClassification actor = AutoModelForCausalLM.from_pretrained("./sft_out") ref_model = AutoModelForCausalLM.from_pretrained("./sft_out") reward_model = AutoModelForSequenceClassification.from_pretrained("./rm_out") config = PPOConfig( model_name="./sft_out", learning_rate=1e-5, batch_size=8, mini_batch_size=4, gradient_accumulation_steps=2, kl_penalty="kl", kl_coef=0.05, ) ppo_trainer = PPOTrainer( config=config, model=actor, ref_model=ref_model, reward_model=reward_model, tokenizer=tokenizer, ) for batch in ppo_dataloader: query_tensors = tokenizer(batch["prompt"], return_tensors="pt", padding=True) response_tensors = ppo_trainer.generate( query_tensors.input_ids, max_new_tokens=64, pad_token_id=tokenizer.eos_token_id, ) # 用 RM 计算 reward rewards = reward_model_score(response_tensors) stats = ppo_trainer.step(query_tensors.input_ids, response_tensors, rewards)需要特别注意的是，generate出来的 response tensor 里既包含 prompt 部分也包含生成部分，step方法内部会特殊处理。如果你在写自己的采样逻辑时不小心把长度搞错了，整个训练流程都会崩得莫名其妙。
关于kl_coef的选择，我在 demo 里先用 0.05，然后观察 KL 均值。如果发现回复变得过分简短而丧失信息量，就调低一点；如果训练过程中 reward 一直不涨，就调高一点。这个系数对最后效果的影响非常大，值得花时间调。
5. 实操过程中的坑与排查技巧
5.1 显存不足：用一个公式提前估算
模型训练显存估算有个简易公式：大概每 10 亿参数（1B）的模型，在 fp16 训练时需要约 2GB 显存，如果是全参微调还要翻倍，加上优化器状态还得再翻。7B 模型用 QLoRA 也要 20G 以上。在做 PPO 时四个模型同时加载，显存压力更大。我的建议是提前算好，避免跑起来才发现 OOM。
比如一个 7B 的 Actor + 7B 的 Reference + 7B 的 Reward + 7B 的 Critic，如果全用 fp16 加载，光是权重就占了 4×14GB = 56GB，这还没算梯度、优化器状态和中间激活值。所以很多人做 PPO 只能用小模型或量化方案不是没有理由的。
5.2 训练不稳定的排查顺序
PPO 训练中常见的现象是 loss 曲线不断跳动，甚至 reward 出现明显的“先涨后崩”。我的排障顺序：先看 KL 均值有没有失控→再检查数据里有没有异常长的 prompt→接着看 RM 分数分布是否正常→最后才调 PPO 内部的裁剪参数。大多数情况下，问题出在 RM 打分分布不合理，而不是 PPO 实现有 bug。
也有一种情况是 Actor 在采样生成时用了错误的解码参数，导致生成内容质量极差。do_sample=True和top_p、temperature这些参数要提前固定，不能训练过程中随意切换，否则模型策略会被不同风格的生成样本扰乱。
5.3 奖励黑客：怎么发现和扼杀
奖励黑客是 RLHF 特有的问题。一个明显的信号是：RM 平均分数持续上升，但人工观察生成样本后发现质量并没有变好，甚至在一些维度上变差了。比如我见过模型学会在回答末尾固定加“祝您生活愉快”，因为 RM 训练数据里这类客套话出现在高分段中，模型就把它当作高分密码。
对付奖励黑客有几种手段：一是增加 KL 惩罚强度；二是给 RM 做多次迭代更新，让 RM 跟上 Actor 的“新花招”；三是在 PPO 训练中定期用固定测试 prompt 做人工评估，不能只看数值。最后一点是很多团队拿到高分曲线就宣布大功告成，结果一上人工评测被打回原形的根本原因。
5.4 训练效果评估：不能只看 reward
我经历了不止一次“reward 涨得很好看，实际部署效果一塌糊涂”的情况。现在的习惯是每个训练 checkpoint 都保存下来，并且在固定的测试集上生成样本后进行人工评分。跟 SFT 阶段不一样，RLHF 的评估更看重模型是否在“遵从人类偏好”上发生变化，比如同样一个开放性问题，SFT 版本的回答可能又长又全面，RLHF 版本则更简洁、更有礼貌。这个变化只能通过真实生成样本来感知，任何自动指标都替代不了。
6. 从 RLHF 到 DPO、GRPO：更轻量级的对齐方案
6.1 DPO：跳过了奖励模型的强化学习变体
RLHF 全流程跑下来虽然效果扎实，但工程复杂度不低。近两年 DPO（Direct Preference Optimization）越来越流行，它的思路非常巧妙：既然奖励模型的最终目的是表达人类偏好，那能不能跳过训练的 RM，直接把偏好数据用于策略优化？DPO 做到了这一点——它从数学上推导出奖励函数可以直接用策略模型自身的输出概率表示，这样只需要一个模型、一组偏好数据，就能完成类似 RLHF 的对齐训练。
在 TRL 里跑 DPO 非常方便，把chosen和rejected数据丢给DPOTrainer即可：
from trl import DPOTrainer dpo_trainer = DPOTrainer( model=actor, ref_model=ref_model, tokenizer=tokenizer, train_dataset=dpo_dataset, args=TrainingArguments( output_dir="./dpo_out", per_device_train_batch_size=4, learning_rate=1e-5, num_train_epochs=2, ), ) dpo_trainer.train()DPO 的优势是训练稳定、显存占用低（不用加载 RM 和 Critic），劣势是它对偏好数据的质量更为敏感——没有 RM 平滑打分，数据里的噪音会直接传导到策略更新中。小规模数据上我观测到 DPO 偶尔会产生“偏好遗忘”，也就是训练集上的偏好拟合得很好，但遇到稍微偏一点的 prompt 时行为反而变得怪异。
6.2 GRPO：把 Critic 也去掉的群体相对策略优化
GRPO 是最近一段时间热度极高的方向。它的核心改进是去掉 Critic 模型——不再单独估计值函数来算 Advantage，而是用一组同 prompt 下多个采样回答的相对得分来近似优势。这个思路跟“多生成几条回答，挑出相对更符合偏好的方向”很接近。好处是省掉了一个大模型的内存开销，训练速度也有可见提升。TRL 新版本已经内置了GRPOTrainer，想在 RL 阶段换用 GRPO 的话，可以沿用 RM 打分，也可以用规则打分（比如格式是否符合要求）。
从工程角度看，GRPO 在推理成本和训练稳定性之间做了很好的折中，尤其是在需要快速迭代的实验阶段，我个人已经把不少场景从 PPO 换到了 GRPO。不过 GRPO 对采样数量（num_generations）比较敏感，采样太少时优势估计的噪音会变大，需要根据显存余量设置一个合适的值。
6.3 一条现实的选择路径
结合团队实际项目，我给出的选型建议是：如果目标是快速验证方案，直接用 DPO，成本低、见效快；如果对效果要求极高且预算充足，用完整的 PPO 管线，它的上限更高；如果既想省显存又想贴近 PPO 的优化思路，GRPO 是目前平衡点最好的选择。三条路线在 TRL 中都有现成实现，切换成本很低。
注意：不管选哪条路线，训练完成之后的评估环节都不能省。我在多个项目里发现，DPO 训出来的模型在偏好数据上契合度很高，但容易出现“为了显得礼貌而丢失关键信息”的现象。这类行为退化只有通过真实场景的人工抽检才能暴露出来，单纯看评测集分数有可能会被骗过去。
7. 写在最后的几条实战建议
回头看我做“加强训练”这几轮迭代，最大的感受是“别把 SFT 当陪跑、别把 RLHF 当魔法”。SFT 决定模型的基础行为边界，RLHF 决定模型在开放场景下的取舍偏好。数据质量永远排在模型结构和训练技巧前面，这在任何阶段都不会变。
如果现在的你正打算上手 TRL，我建议先用小模型（比如 1B 级别）和几千条数据，把 SFT→RM→PPO（或 DPO/GRPO）的链路完整跑通，亲眼看一下每一步的输入输出格式，再上规模。否则一上来就上 7B、70B 的模型，一旦报错你都分不清是代码问题还是显存问题。
最后分享一个我在调试时最爱用的技巧：不管训练跑得多么顺利，每隔一段时间就用一个固定的、不太常见的 prompt 让模型生成回答，亲手看一看它到底变成了什么样子。这个习惯曾经不止一次地救了我的项目——因为当所有训练指标都在上升时，只有人工亲眼所见，才能真正确认这次加强训练到底“强”在了哪里。
