2.1 RLHF 强化学习人类反馈

2.1 RLHF 强化学习人类反馈

本节摘要：RLHF（Reinforcement Learning from Human Feedback，基于人类反馈的强化学习）是让大模型"听话"的经典方法，也是 ChatGPT 走红背后的关键技术。它的核心思路是：先让人类标注"哪个回答更好"，用这些偏好数据训练一个奖励模型，再用这个奖励模型当裁判，通过强化学习不断优化模型的回答策略。本节拆解 RLHF 的 SFT、奖励模型、PPO 三阶段流程，分析它为什么有效，也讲清它标注成本高、扩展性差、标注者不一致的三大局限。

学习目标

阅读完本节，你应当能够：

1. 说出 RLHF 三个阶段各自的角色和数据流向
2. 解释奖励模型是怎么从成对偏好数据里学到"好坏"的
3. 理解 PPO 在 RLHF 里为什么需要一个参考模型做 KL 约束
4. 复述 RLHF 的三个主要局限及其成因
5. 判断一个项目是否值得上 RLHF，还是该用更轻量的方案

问题与直觉

预训练完的大模型其实"什么都会一点"，但问题是它不知道你想要什么。你问它"怎么写一封请假邮件"，它可能给你一段技术文档风格的说明，因为它在预训练语料里见过太多这种文本。它缺的不是知识，而是"按人类期望的方式组织和表达"的能力。

最早的解法是有监督微调（SFT）：直接拿人类写好的高质量对话去微调模型。这招有效，但有个天花板——人类很难穷举出"什么是好回答"。同一个问题，回答 A 简洁准确，回答 B 详细有温度，哪个更好？这取决于场景，而场景是无限的。靠人去一条条写"标准答案"既贵又覆盖不全。

RLHF 的突破性想法是：别让人类写答案，让人类做选择。给人类看同一个问题的两个回答，让他标"哪个更好"，这比从零写答案容易得多，而且能表达更微妙的偏好。把这些偏好收集起来训练一个"奖励模型"（它会自动给任意回答打分），然后用这个奖励模型当自动裁判，用强化学习让模型不断生成"得分更高"的回答。人类只需要做相对简单的"比较"工作，费力的"生成和优化"交给强化学习算法。

核心原理

2.1 三阶段流程

RLHF 的标准流程分三步，每步的输入输出和目标都不一样。

阶段一：有监督微调（SFT）。 拿一批人类编写的高质量指令-回答对，用普通的有监督学习微调预训练模型。目标是让模型先学会"听指令、按对话格式回答"，作为一个合格的起点。没有这一步直接上强化学习，模型可能连基本的对话格式都搞不定。

from transformers import AutoModelForCausalLM, TrainingArguments

model = AutoModelForCausalLM.from_pretrained("基础模型路径")
training_args = TrainingArguments(
    output_dir="./sft_model",
    num_train_epochs=3,
    per_device_train_batch_size=4,
    learning_rate=2e-5,
)
​

阶段二：奖励模型（RM）训练。 这是 RLHF 的关键创新。收集大量"同一个 prompt 下，人类标注 A 比 B 好"的成对数据，训练一个序列分类模型，让它学会给回答打分。训练目标是让"好回答"的得分比"差回答"高。

from transformers import AutoModelForSequenceClassification

# 奖励模型本质是个打分器:输入 prompt+回答,输出一个标量分数
reward_model = AutoModelForSequenceClassification.from_pretrained(
    "roberta-large", num_labels=1)

# 训练目标:chosen 的分数要高于 rejected
def reward_loss(reward_chosen, reward_rejected):
    # 经典的偏好损失:让好答案得分减差答案得分的差越大越好
    import torch.nn.functional as F
    return -F.logsigmoid(reward_chosen - reward_rejected).mean()
​

阶段三：PPO 强化学习。 用奖励模型当裁判，让策略模型（就是 SFT 后的模型）不断生成回答、被打分、再优化。这里有个细节：必须保留一份"冻结的参考模型"，用 KL 散度约束策略模型别偏离参考模型太远——否则模型会找到奖励模型的漏洞，生成一堆"得分高但人类看不懂"的废话（这叫 reward hacking）。

from trl import PPOTrainer, PPOConfig

ppo_config = PPOConfig(learning_rate=1e-5, kl_penalty="kl")
ppo_trainer = PPOTrainer(
    config=ppo_config,
    model=policy_model,       # 要优化的策略
    ref_model=ref_model,      # 冻结的参考模型,防止跑偏
    reward_model=reward_model,
)
​

2.2 为什么需要 KL 约束

PPO 阶段最容易踩的坑就是 reward hacking：模型发现某种特殊格式的回答能让奖励模型给高分，就会拼命生成这种格式，哪怕它对用户毫无意义。KL 约束的作用是"别离起点太远"——你可以优化，但不能演化成一个完全不同的东西。这就像给赛车手规定"必须在赛道上"，否则他会为了刷圈速抄近路穿过草地。

工程实践要点

3.1 偏好数据怎么收集

RLHF 的质量天花板是偏好数据。收集时要注意几个原则：第一，给标注者明确的比较维度（准确性、有用性、安全性），别让每个人自己理解"好"；第二，每个 prompt 至少让多个标注者独立标，算一致性，一致性低的样本要剔除或重标；第三，prompt 要覆盖多样化的场景和难度，别全是简单问答。

⚠️ 常见坑：标注者之间天然不一致。一个资深工程师和一个普通用户对"什么是有用回答"的判断差很远。如果你的标注团队背景单一，模型会偏向那个群体的偏好。解决办法是明确标注指南、做标注者培训、定期抽检一致性。

3.2 奖励模型的局限

奖励模型本质是在"模仿人类标注者的偏好"，但它学到的可能只是标注者的表面模式，而不是真正的价值判断。它会过拟合——在训练分布内打分很准，遇到分布外的情况就可能乱给分。而且奖励模型本身也可能被对抗攻击（和第一章的对抗样本是一个道理）：精心构造的输入能骗它给高分。

3.3 PPO 的工程复杂度

PPO 是 RLHF 三阶段里最贵、最难调的。它要同时维护四个模型：策略模型、参考模型、奖励模型，外加一个价值模型（critic）。显存占用是 SFT 的好几倍，学习率、KL 系数、clip 范围这些超参都很敏感，调不好就发散或者训不动。很多中小团队就是卡在这一步。

3.4 什么时候该上 RLHF

💡 关键直觉：RLHF 不是"用了就一定更好"。它的效果高度依赖偏好数据质量和工程实现，烂数据加烂实现的 RLHF 可能比纯 SFT 还差。在没准备好之前，先用 SFT 和 DPO 这种轻量方案验证，等数据 pipeline 和团队经验都成熟了再上 RLHF。

3.5 RLHF 的三大局限

最后系统总结一下 RLHF 为什么会被后面的技术改进：

收获清单

• RLHF 把"写答案"变成"做选择"，让人类只标偏好，费力的优化交给强化学习。
• 三阶段是 SFT 预热 → 奖励模型学偏好 → PPO 优化策略，缺一不可。
• KL 约束防止 reward hacking，没有它模型会钻奖励模型的空子生成高分废话。
• 偏好数据是质量天花板，标注者不一致和数据单一会让模型偏向特定群体。
• PPO 工程成本极高，中小团队往往卡在这，这也是后面 DPO 兴起的原因。

下一节看怎么用 AI 反馈和显式原则降低对人类标注的依赖——RLAIF 和宪法 AI。

工程补充：奖励模型的失效模式与日常巡检

奖励模型是 RLHF 流水线里最脆弱的一环，值得专门展开它失效的三种典型形态。第一种是过拟合标注分布：奖励模型学到的是"这批标注员偏好什么"，而不是"什么是好回答"。表现是 RL 训练的线上指标一路上涨，人工抽检质量却在下跌——策略模型找到了奖励模型的盲区而不是真的变好了。第二种是长度偏置：标注员天然偏爱长回答，奖励模型继承这个偏好，策略模型就学会啰嗦注水。第三种是格式偏置：分点、加粗、代码块这类"看起来专业"的排版拿到更高分，内容质量不变分却涨了。

对应的巡检手段有三个。固定一批"金标准" prompt 每隔若干步用人工评分对照奖励模型打分，看相关性是否漂移；对策略模型的输出做长度和格式统计，任何单一维度的单调增长都是警报；定期把新发现的坏案例加入奖励模型的训练集重训。这三件事都不复杂，但要坚持做——奖励模型是会悄悄烂掉的，等指标崩了才发现，通常已经烧掉了几轮训练预算。

另一个实践细节是 KL 系数的调法。太松，模型跑飞，语言能力退化成胡言乱语；太紧，模型只在 SFT 策略附近微动，对齐等于没做。务实做法是从小系数起步，密切盯住线上评测集的困惑度，一旦困惑度异常上升立即回退——把 KL 当作刹车而不是方向盘，方向感来自奖励数据的质量。

再展开一个实战话题：偏好数据的生产管理。收集偏好数据听起来是标注团队的事，实际上它是 RLHF 项目里决定成败的工程系统。要管理的维度包括：任务说明书（每类 prompt 的比较标准）、标注一致性监控（双人背对背标注的吻合率）、争议样本仲裁流程、以及标注员疲劳效应（连续标注数小时后一致性明显下滑，需要控制单人次时长）。一个可参考的量化基准是：高质量偏好对的成本大约是普通指令数据的五到十倍，所以数据量规划要先想清楚——两千条精标偏好对训练出的奖励模型，往往胜过两万条噪声数据训练的结果，这个量级差异在 SFT 阶段是不存在的，很多团队第一次做 RLHF 都会在这里低估预算。

关于多轮对话场景的对齐还有一个补充：奖励模型通常在单轮偏好对上训练，而产品里大量价值体现在多轮交互——是否记得用户偏好、是否会纠缠旧话题、是否在该澄清时澄清。把多轮质量纳入 RLHF 的做法是对话级偏好标注（标注员比较整段对话而非单条回复），数据成本更高但信号更贴近产品体验。资源有限时，可以只在安全相关的多轮场景上做对话级标注，普通体验维度留给线上指标去观测。

最后提一个排错技巧：RL 阶段指标异常时，先查数据再查超参。九成的"跑飞"根源是偏好数据里的矛盾对或奖励模型版本与策略数据分布脱节，超参背锅的时候反而少。把"回放最近一批高奖励样本人工抽查"固定为排障第一步，能少走很多弯路。