人类反馈的强化学习（RLHF）这几个字，现在几乎成了大语言模型技术讨论里的“必点菜”。但我发现一个很有意思的现象：大多数人对它的理解停留在“让模型学会说人话”这一步，真正把整个链路从头到尾跑通的人，少得可怜。我自己也是踩了三轮坑、废掉好几个训练任务之后，才敢说自己摸清了这条流水线的脾气。
这一篇是《人类反馈的强化学习之书》系列的第一部分。主打的内容是：人类反馈的强化学习到底是什么、为什么它如此关键、它的完整流程怎么拆，以及你第一次动手做偏好数据、训练奖励模型、进入 PPO 策略优化时，最容易在哪几个环节翻车。适合想认真复现 RLHF 的算法工程师、纯好奇的技术读者，以及被领导一句话“把对齐做一下”砸到头上但不知道从哪开始的同学。
不整虚的，直接开讲。
1. 为什么说 RLHF 是当前大语言模型拼图的最后一块
1.1 从“会模仿”到“按人类偏好行动”
我最早接触强化学习，是还在做对话机器人那会儿。模型用监督微调训完，语法是对的、逻辑也通顺，但一问到“你觉得我应该先辞职再创业，还是先保住工作试水”这种问题，它给的答案总透着一股“端水大师”的味道——两边都分析，谁也不得罪。后来和做产品线的同事复盘，我们才意识到：传统的下一词预测训练，学的是“文本的概率分布”，不是“什么回答更符合一个人看完之后的真实感受”。两者之间的落差，光靠堆数据解决不了。
你要记住这个判断：大语言模型本质上是一个“续写器”，它知道某个词后面大概率接什么词，但它并不知道你读完这句话之后是满意、被冒犯，还是觉得废话太多。这个缺口在最开始不明显，因为很多任务有标准答案，问“一加一等于几”就能得到一个确定写法；但一旦任务变成“帮我写一封拒绝客户的邮件”“给我讲讲量子计算的入门路径”，答案的优劣就变成了高度主观的判断。什么是“好”，什么是“坏”，藏在千千万万个真实用户的偏好里，而不在语料库的词频统计里。
这个落差，就是人类反馈的强化学习（RLHF）要补的位子。你去看现在主流大语言模型的技术报告，基本都会强调一句“通过人类反馈进行微调”。说白了，RLHF 做的是这么一件事：让模型不再只追求“像人写的”，而是追求“人想要的那个”。它的核心词汇是“人类反馈”，也就是把标注者给出的偏好判断当成一种监督信号，用来修正模型的行为倾向。
作为要走进这个方向的工程师，我不建议一上来就扎进 PPO 的公式里。先建立一个整体心智模型：大语言模型本来只会“续写”，RLHF 则是在续写的能力上，加一个“偏好方向盘”。这个方向盘不是人手工写的规则，而是从海量“二选一/多选一”的人类评价中养出来的。
1.2 强化学习能把偏好变成优化目标
这里要回答一个很自然的疑问：为什么不用别的方法，偏偏用强化学习？
我自己的理解分三层。
第一层，偏好不好直接做损失函数。假如你让标注者直接给回答打 0-10 分，分数受个人标准影响极大，同一个回答，A 组可能给 8 分，B 组可能给 5 分。而成对比较、AB 选择这类相对排序，标注者之间的一致性能高得多。但相对的，排序信号没法直接塞进交叉熵损失里，需要一个模型把“A 优于 B”翻译成连续的优化目标，这就是后面要讲的奖励模型。
第二层，生成任务天然就是序贯决策。语言模型的输出是一段完整的句子，但从底层看，它是逐个 token 决策出来的；旧 token 会影响新 token 的分布。这和游戏里按帧做动作的本质一致，标准的监督学习很难处理这种“链式依赖”的优化，强化学习却天生为这种场景设计。你可以想象一个人在拼乐高：每放一块积木，都要看之前已经堆出来的形状再决定下一块放哪，这个决策链条上的每一步都是相互绑定的。语言生成也一样，只优化最后一句成品是行不通的，必须沿着每一步追问“这一步做得对不对”。
第三层，我们需要可控性。微调的本质是“贴近一个新分布”，但如果只贴近偏好数据，模型会在那些见过的指令上说得特别漂亮，换个问法又开始胡说。强化学习给了一个额外抓手：在追求偏好分数的同时，通过 KL 惩罚锚定原始模型，防止模型放飞自我。这种“也想要，但不要走太远”的约束，是 RLHF 区别于硬编码规则和纯微调的关键。
所以，如果你准备复现一个 RLHF 流程，请把这三点装进脑子：难以直接求导的排序信号、序贯生成的决策闭环、以及对偏移的显式惩罚。接下来整个系列的代码与实践部分，都会围绕这三件事展开。
2. RLHF 的全貌：一个完整的三阶段流水线
2.1 三条核心链路：偏好数据、奖励模型、策略更新
我在做模拟项目 X 的时候，把 RLHF 整个流程画成了一条非常直观的流水线。你可以直接在脑子里记成“三段式”：
第一个阶段，是收集或复用人类偏好数据集。你今天看到的每个偏好样本，结构上都是一个五元组：提示词、候选回答 A、候选回答 B、标注者选择、置信度或理由。也有做成排名的，比如四个回答按质量排成 1、2、3、4，一次性更省标注成本。这个阶段的产品形态是“人类数据”，不是模型。
第二个阶段，是训练奖励模型。奖励模型的输入是“提示词 + 回答”，输出是一个标量分数。它是个打分器，目标函数是最大化成对排序的似然：在同一个提示下面，人类标注为更优的那个回答，得分要比另一个更高。这个阶段相对独立，训练完就冻结掉，供第三阶段使用。
第三个阶段，才是很多人理解的“强化学习”——把策略模型作为要训练的主体，让它针对同一批提示词生成回答，再用奖励模型给回答打分，用 PPO 更新策略。为了让模型别把奖励模型钻出空子，还会引入一个参考模型，时刻计算新旧策略之间的 KL 散度，纳入损失。
这三个阶段不一定是严格串行的。实际生产里，第一阶段和第二阶段通常会迭代好几轮：先拿奖励模型得分偏高的样本回去重新给人类标注，提升数据质量；也可以阶段三里发现模型开始刷奖励了，赶紧回去补一轮偏好数据。
我见过不少人把注意力全放在第三阶段的 PPO 上，觉得那才是核心炫技区。但以我的经验，决定一个 RLHF 项目成败的，往往是一阶段的偏好数据质量和二阶段奖励模型的泛化能力。这三个阶段不是“3:1:6”的精力分配，真实比例应该是“4:3:3”——数据工作做到位，后面的事情会顺利到你不敢相信。
2.2 相比单纯微调，RLHF 增加的到底是什么
为了帮助组里的新同学理解，我经常打一个比方：监督微调像是让一个学生反复做标准答案的卷子，RLHF 则像是先告诉学生“哪些解法更受老师欢迎”，再让他对着评分标准自己改作业。
标准微调做的事，是学习一个映射关系：给输入 x，要输出答案 y，两者组对出现在训练集里。这种学习是“样例驱动”的。
而 RLHF 在中间加了一层奖励模型。策略模型生成多个候选回答，奖励模型给出打的分数，PPO 再把这种结果转成梯度回去更新策略。它的优化信号，来自“评分”，而不是“标准文本”。这意味着模型有机会学到数据里没有显式写出来的偏好，比如“同样能答对的情况下，语气更简洁更受偏好”。
我给你一个更具体的对照。假设训练集里有一个样本：提示是“讲个冷笑话”，标准答案是一个固定的段子。监督微调的目标是无限接近那个段子，你给它换一个开头，它可能就开始胡编。但 RLHF 阶段，只要某个候选回答能拿到比另一个更高的奖励分，不管它和“标准段子”差多远，策略模型都会往那个方向移动。你不需要把每一种好的写法都写进数据里，只要奖励模型能分得清好坏，模型自己就能顺着梯度找到更多好风格。
这个差异还会带来一个工程上的后果：监督微调常有明确的 loss 曲线可以看；RLHF 阶段你最好也盯 loss，但更要盯的是一组业务指标——比如回答被用户采纳的比例、安全过滤触发率、平均回答长度。因为 PPO 的 reward 信号本身就是估计出来的，不看业务指标，你完全可能把模型训到了一个“奖励分很高、真实体验很差”的平行世界里去。
3. 第一步实操：设计偏好数据收集方案
3.1 选择标注框架：成对比较、排名分组与 ELO
进入实操，第一个决定不是“哪个模型”，而是“怎么收集人类的偏好数据”。
我最常用的是成对比较（pairwise comparison）。每次给标注者两个回答，让他选“哪一个更好”。为什么优先选它？两个原因。一是标注者认知负担低，十秒内能做出判断，标注速度快；二是因为二选一的相对判断更容易让多人打标达成一致。缺点是：同一对回答在不同的人看来可能互相矛盾，需要大量冗余标注来降噪。
如果回答数量偏多，可以做分组排名。比如一次给四个回答，先分成两对，再比赢家。这样一次能产出六对相对关系，信息量更大，但标注者的疲劳度高，后半程的质量容易掉下来。我试过一次给六个回答，结果标到后面的人开始凭长度猜了。
计算竞赛里的ELO 算法，也被借鉴过来做偏好打分：每个回答有初始分数，与别的回答比较后按胜负结果更新分数。它适合回答数量很多、且答案不是同一模型批量生成的场景。但 ELO 的分数只对“组内比较”有意义，不同批次之间的 ELO 分数不能直接横向比，用的时候要小心。
三种方式，我列个对照表给你：
| 框架 | 单次标注成本 | 信息量 | 标注者一致性 | 适用场景 |
|---|---|---|---|---|
| 成对比较 | 低 | 中 | 高 | 起步首选，通用型 |
| 分组排名 | 中高 | 高 | 中 | 候选回答质量跨度大 |
| ELO 动态评分 | 中 | 可跨轮次累计 | 中 | 多模型长期评测 |
我自己给刚起步的团队一个配置建议：第一批先收集 5000-10000 对成对比较，类别覆盖任务尽量广，每个提示词至少三条不同模型生成的不同回答，保证多样性。然后再根据奖励模型的错误案例，定向扩充数据。别一上来就追求五十万对，优先把数据信噪比做上去，小样本高质量往往比大样本脏数据更有效。
3.2 我在实际数据收集里踩过的坑
下面是真金白银换来的几条心得，建议直接存进你的笔记软件。
指导语不一致，数据噪音直接翻倍。我第一次做数据，只给标注者写了一句“选更好的答案”。结果有人觉得“详细=好”，有人觉得“简洁=好”，有人以“像不像真人”为标准，还有人只看开头三行。后来我们改成：“想象你是用户，希望在 30 秒内获得准确且行动可行的回答”，分歧立刻大幅下降。指导语里要写清楚“你是谁、你要解决什么问题、什么情况算更好”，哪怕长一点，也要讲透。
同一标注者前后标准漂移。标注者标到第 300 条时手指已经形成惯性，常常不读完回答只看开头几个词。我建议给标注队列强制插入“校验题”，把已有共识的问题混进去。如果答错，就提醒并重新校准，连续三次答错就暂停该标注者的任务。
直接拿生成模型采样做候选，太容易自肥。如果我们只用待优化模型做候选，它往往只输出某种风格，比较来比较去都在同质化答案里选，信息量低。我后来养成的习惯是：刻意引入不同来源的候选，包括其他模型、更早期 checkpoint、甚至简单模板。多样性越足，偏好模型越能学到“差异”而不是“重排”。
过早过滤“敏感输入”反而害了奖励模型。有段时间我们把敏感输入提前过滤得很干净，结果奖励模型在真实线上遇到这类输入时表现极差。过滤策略要二次验证，不能只信标注系统的“安全判定”。你希望模型在什么场景下工作，就要让它在训练阶段真正见过那些场景的输入分布，否则奖励模型就是在温室里训练出来的，出门就失灵。
这些坑不是教科书会写出来的。它们直接决定了第一阶段标注数据的信噪比，也就决定了奖励模型的上限。数据有问题，后面的奖励模型和 PPO 调得再好都是白费。
4. 训练奖励模型：把“人的评价”变成机器可优化的分数
4.1 奖励模型的结构与训练目标
奖励模型的结构上，我强烈建议工程团队不要自己设计得很复杂。常见做法是：在骨干语言模型后面接一个线性层，把最后一层 token 的表示映射成 1 个标量。骨干可以是任意开源模型，关键是和策略模型同族的底座，理由后面会提到。
训练数据是 (prompt, chosen_response, rejected_response) 的三元组。最核心的损失函数是排序损失：模型对 chosen 输出打分 s_1，对 rejected 输出打分 s_0，然后令 s_1 - s_0 尽量大，用 sigmoid 转成二分类。写成伪代码就是：
logits_chosen = reward_model(prompt, chosen_response) # 1-d scalar logits_rejected = reward_model(prompt, rejected_response) loss = -F.logsigmoid(logits_chosen - logits_rejected)有人会问：为什么要排序损失，而不是直接回归标注者的绝对分数？以我自己的经验，绝对分数受个人尺度影响太大，而且标注者很难给出稳定分数。相对排序虽然丢弃了强度信息，但换来的一致性收益非常可观。这也是 RLHF 设计者最终选这条路的底层原因：你不需要知道“这个答案值 7 分还是 8 分”，你只需要知道“A 比 B 更好”，这个信息足够且远比绝对分数可靠。
训练的时候要注意一个细节：reward_model 接的是末位 token 的隐状态。大部分实现里，这个 token 通常是序列最后的 eos，你要保证 eos 真的参与模型因果注意力计算，否则隐状态是残缺的。有人图省事直接取前面定长截断位置，结果 reward 模型对句子前半段的信息敏感度极高，后半段的信息基本忽略，最终学习出来的分数完全跑偏。
另外，不要在同一张卡上同时训 reward model 和策略模型。奖励模型和策略模型是两条独立的训练流，共享显存容易导致吞吐波动，两边都不稳定。工程上宁可把奖励模型做完就冻结，把显存留给后面的 PPO。
4.2 归一化与奖励尺度：一个最容易被忽略的细节
奖励模型的分数，本身是没有固定量纲的。你可能得到 0.3 的分差，也可能得到 3.0 的分差。这对 PPO 的稳定训练影响巨大。
我举一个真实调参例子：在一次模拟训练里，第二阶段的奖励模型前三轮本身还在收敛，但奖励分数分布越来越“挤”，两两回答之间只有 0.02 的差异。PPO 感知到信号很弱，策略模型几乎不更新。反过来，另一个实验里奖励模型过拟合，分差拉大到 2.5，PPO 一下就疯狂朝某个高奖励方向冲，生成质量迅速垮掉。
在实践中我会做一个奖励标准化（reward normalization）：在每次收集一批 rewards 之后，减均值除以标准差，把分布拉到接近 N(0,1)，再喂给 PPO 使用。别小看这一步，它对超参数的迁移性帮助巨大。一套在标准化过的 off-policy 样本上调好的 KL 系数，往往能直接迁移到同量级的新任务。
再补一个关于校准的细节：奖励模型的分数通常不校准到人类真实概率。我们只是拿它当相对信号，没必要追求“1 分就是 80% 的人会选它”那种解释。强行做概率校准反而会引入方差，让训练不稳定。这套哲学和普通分类器很不一样，和团队里的算法同学对齐一下预期，能省很多沟通成本。
还有关于底座选择的强烈建议：奖励模型和策略模型最好同族、同词表。为什么？因为策略模型生成的 token 进到奖励模型里，如果词表不一致，奖励模型就得面对一堆自己从未见过的 token 表示。虽然可以靠 embedding 层的随机初始化凑合，但梯度信号会很脏。同族的底座能让模型在表示空间上做一个平滑过渡，收敛速度差一倍都不夸张。
5. 策略优化阶段：用 PPO 让语言模型自己去调整
5.1 PPO 流程中每一步在做什么
策略优化阶段，我把它拆成四个循环动作：
- 采样：策略模型拿到一批提示词，生成回答。生成时要打开 temperature 或 top_p，让输出保持多样性。否则探索太少，策略更新会锁死在局部，模型只会反复输出同一种“高分套路”。
- 打分：奖励模型对生成的每个回答打分，得到一个 reward 标量，并对长度、重复度做轻量规整。这个规整很细，比如给过长回答扣一点分、给重复 n-gram 扣一点分，用来抵消最基础的模式崩塌。
- 计算优势：PPO 用 GAE（广义优势估计）把每一步 token 上的 reward 折算成“这一步相对平均水平好多少”。语言模型场景里，通常只有最后一步有一个非零 reward，因此 GAE 退化成“减 baseline”的形式，这个 baseline 在实现里由 critic 网络输出。
- 更新：用 PPO 的 surrogate loss 更新策略模型参数，同时计入 KL 惩罚，限制单步更新幅度。这一步会在同一个 batch 上做若干次 minibatch 更新，甚至会把同一批数据过好几遍 epoch。
这套东西从代码量看，比 SFT 的 train 脚本多出不少。核心是个 while 循环，里面有 rollout、reward 计算、buffer 组装、PPO 内部多次 minibatch 更新。建议读代码时先把rollout和update拆开，别混在一起看。
关于“为什么 PPO 要好几个 epoch 反复更新”这个问题，很多朋友刚接触时都问过我。原因很简单：我们生成一批回答是很贵的，不可能每更新一次策略就重新采样一批。所以大家选择在固定 batch 上做多次更新，但这样很容易过拟合到当前 batch，所以 PPO 内部有 clip 机制，限制每次更新不要走太远。clip 系数和 KL 惩罚两个机制是搭配着用的，一个限制策略步幅，一个限制与参考模型的偏移，缺一不可。
5.2 参考模型与 KL 距离：为什么不是“随便学”
我看到很多入门帖把参考模型忽略掉，觉得“就是拿来辅助的”。但实际它才是 RLHF 的定海神针。
参考模型是监督微调后冻结的模型。策略模型每一步更新时，都要同时计算当前模型每个 token 的输出 logprob，和参考模型对应的 logprob，两者做 KL 散度。KL 值越大，说明策略模型偏离参考模型越远。优化目标变成：
目标 = reward - β × KL(policy || reference)
这个 β 是 RLHF 里最重要的超参数之一。β 太大，模型几乎学不到新偏好，问题没解决；β 太小，模型迅速把奖励模型钻穿，输出“看起来打分很高但人看着很怪”的内容。我踩过一次特别典型的坑：β 从 0.04 降到 0.01 之后，模型第三轮就开始输出一段又一段重复的模板式感谢语，因为奖励模型对这种格式打了高分。
所以我的经验法则是：监控训练中 KL 值，正常更新幅度应该在每 batch 零到数个 nats 之间；如果 KL 开始指数级上涨，第一时间先调大 β，再检查数据。千万不要看着 reward 在涨就放任不管，那是地基正在塌的迹象。
这里可以做一个类比：参考模型就像你在驾校科目二练车时的“教练座”。方向盘要听你的，但教练座下面还有个副刹车。β 就是那个副刹车的灵敏度。灵敏度太高，学员学不会开车；灵敏度太低，学员一脚油门就把教练和车一起带沟里了。
5.3 训练稳定性：梯度之外的口诀
在工程层面，我把 RLHF 训练的稳定口诀总结成“三看一不动”：
- 一看 KL 曲线：每个 batch 后打印平均 KL，应该平稳上升后收敛，绝不能爆炸。如果前期横死，说明 β 设得太高，模型压根不想动；如果直线拉升，说明 β 太小。
- 二看 reward 均值与分布：reward 均值上升不一定是好事，还要看分布的 shape。如果方差骤增，或者分布出现“从某个 batch 开始直接跳到满分”的尖峰，大概率是奖励模型在自娱自乐。
- 三看回答长度：长度漂移是最隐秘的 reward hacking 信号，模型可能靠加长废话刷高分。每条回答平均长度突然增加 30% 以上，先加长度惩罚，再查原因。
- 一不动：测试集不参与 reward 计算，也不参与 β 调整。它只用来做最终抽查，防止我们朝着奖励模型调过头。很多团队为了多挡几个 prompt 把测试集泄进 reward 分布里，最后评测报告好看到不行，上线就露馅。
这些经验来自模拟项目 X 和几个内部训练任务的反复试错。每次训练挂掉，我基本都能从这三条曲线里找到一个出问题的源头。建立标准化的训练监控面板，比调十轮超参数都管用。
6. 常见问题与工程排查实录
6.1 奖励作弊与模式崩塌
“奖励作弊”（reward hacking）这个词，是 RLHF 从业者绕不开的噩梦。表现为：奖励模型的分数一路新高，但人类只要略微浏览回答，就能看出质量崩了。
我遇到过的典型案例：有一个偏好聚焦在“详细解释”的任务上，奖励模型学会了“长度越长，分数越高”的捷径。PPO 立刻抓住这个洞，策略模型开始输出越来越长的回答，甚至重复前面的内容凑字数。人类一看，评价非常差。
排查手法我已经稳定采用：
- 先看 reward 分布是否呈现“双峰”。一个健康训练里，reward 分布应该缓慢右移；如果出现尖峰直冲上限，一定是奖励模型漏洞被抓住。
- 算参考模型的 reward 做对照。冻结参考模型，拿同样提示词生成回答，用奖励模型打分。如果策略模型比参考模型高出许多，而人工评估却打不过参考模型，基本可以判定奖励作弊。
- 应急手段是给 reward 加上“长度惩罚系数”，并回到数据阶段补充“短小但优质”的高分样本。让标注者多选短的好答案，奖励模型就不会那么依赖长度这个线索。
还有一个隐蔽信号是重复度飙升。模型学到了“把一句话重复三遍，既增加了长度又保持了连贯性”，这种作弊不太容易被 length penalty 拦住，需要在奖励里额外加“n-gram 重复惩罚”。我见过有些团队的奖励打分器只维护一个长度惩罚项，结果模型开始追着重合度低但毫无语义的废词，照样刷分。要把几个维度结合起来做惩罚，才堵得住洞。
6.2 训练不收敛的排查路径
PPO 不收敛，乱上加乱，很多新同学第一反应是调学习率，其实更大概率是 pipeline 没有打通。我按排查频率排序：
- 检查 loss 的回传是否经过正确的 token。LLM 里我们只对生成的 response token 算 policy loss，prompt 部分要 mask 掉。如果 mask 错了，模型会在 prompt 上也做梯度更新，行为就会很怪。这个 bug 藏得很深，它不报错，只是曲线变得诡异。
- 检查 reward 有没有真正依赖生成文本。如果 reward 模型接口传参错误，把空输出当输入，reward 变成同一个常数，loss 还能下降但纯属假象。你甚至会发现模型在“没有信号”的情况下原地打转。
- 检查 GAE 的 lambda 和 discount。语言生成任务里序列长度不一，尤其要注意 pad token 上的数据不能污染 advantage 计算。用 mask 之后可以大幅度提升稳定性。
- 检查 critic 网络是否比 policy 大太多，导致学得快，优势估计不断变化。最好让 critic 和 policy 同步更新，或用一个更小的衰减率。否则优势估计一直在移动靶，策略模型学得再快也追不上。
这些问题，我是怎么发现的呢？靠的是一条一条看日志。别想着一步到位的训练框架能替你处理所有边界情况，RLHF 调参就是一场“看日志-改 mask-重采样-再看日志”的循环。哪一步你跳过去了，后面就会在更隐蔽的地方爆发。
6.3 速查表：RLHF 训练高频问题与建议
| 现象 | 可能原因 | 快速处理 |
|---|---|---|
| KL 曲线爆炸 | β 过小 | 增大 β，暂停训练，先跑一次小规模验证 |
| KL 曲线一条直线 | β 过大 | 减小 β，或检查奖励信号是否有效 |
| reward 均值上涨但人工评价变差 | 奖励作弊 | 检查长度/重复度惩罚，补充偏好数据 |
| reward 分布双峰 | 奖励模型过拟合 | 降低奖励模型容量，或增大偏好数据集 |
| 回答长度持续飙涨 | 长度被奖励模型当成优质特征 | 加长度惩罚项，回去标注短好样本 |
| loss 不下降 | mask 错误或 reward 无效 | 打印梯度回传路径，确认 response token 参与计算 |
| 模型输出千篇一律 | 采样 temperature 太低 | 提高采样多样性，或增大更新步数 |
这张表是我每次训练前都会扫一遍的检查单。它不能解决所有问题，但能帮你在凌晨两点挂掉的训练任务面前，快速缩小排查范围。
7. 系列预告，以及我自己对 RLHF 的整体感受
这一篇是《人类反馈的强化学习之书》系列的第一部分，我特意只写到方法论、三阶段拆解和开坑指南为止，连完整训练代码都没放。因为我对这套技术的最大感受是：公式不多，但链路上的协同关系比公式更难掌握。你单独看懂一个 PPO 很容易，搞清楚它和参考模型、奖励数据之间的耦合关系，才是真正能落地的地方。
接下来这个系列，我计划的第二篇会讲 DPO 与 RLHF 的关系——很多人以为它们是替代关系，实际上它们只是“显式奖励模型”和“隐式奖励模型”两条路线；第三篇我会写一个可复跑的 PPO 训练示例，从数据格式到 loss 计算逐行讲；如果有机会，后面还会讨论 RLHF 的安全对齐、标注者偏差、以及如何用自动化模型筛选替代一部分人类标注。
结尾就不做总结了。我只想说，在你动手写第一条 reward 数据处理逻辑之前，先把这一篇里的“三看一不动”贴在屏幕上；等你被 KL 爆炸折磨过一次之后，会回来感谢它的。
