# T01 · 训练方案不是算法排行榜：先把决策分层
> 一句话点题：**训练方案不能按技术名词的新旧排队。真正的判断顺序是：先看能力目标和任务形态，再看数据与学习信号，接着检查候选方法依赖的假设，最后计算它会怎样改变模型组件、训练系统、资源账单和失败模式。**
---
> **🧠 基础模型训练决策专题第 1 章 · 本章只练一件事**
>
> 本专题默认团队已经进入基础模型生产体系，不讨论“普通团队要不要训练大模型”。本章先用一个具体例子讲清 SFT、DPO、PPO、GRPO 及其相关概念，再建立后续章节共用的判断坐标系。读完后，你不必会推导公式，但应该能看懂一个训练方案需要什么数据、增加什么组件、解决什么问题，又把复杂度转移到了哪里。
---
## 阅读地图：这一章处在模型生产的哪一段
在进入例子前，先把这一章放回完整生命周期：
```text
大规模原始数据
↓ 预训练：反复预测下一个 Token
Base Model（基础模型）
↓ 后训练：示范、偏好、奖励、工具与安全训练
候选产品模型
↓ 能力 / 安全 / 回归评测
发布模型
```
- **预训练（Pre-training）**：让模型从大规模数据中学习语言、知识和基础能力，主要目标通常是预测下一个 Token。
- **Base Model（基础模型）**：预训练得到的模型。它已经会续写和解决一些问题，但不一定稳定遵循指令，也未必具有产品要求的行为和安全边界。
- **后训练（Post-training）**：在 Base Model 上继续训练，让它更会遵循指令、表达偏好、推理、使用工具和遵守安全约束。
- **Fine-tuning（微调）**：不是从零训练，而是在已有模型参数的基础上继续训练。SFT、DPO 和强化学习后训练都可能改变已有模型参数。
这里的 **参数（Parameters / Weights）**，可以先理解为模型内部数量巨大的可学习数字。训练不会给模型写入一条条 `if` 规则，而是调整这些数字，使我们希望的 Token、回答或行动以后获得更高概率。
本章重点解释后训练，因为 PPO、GRPO、DPO 和 RLHF 主要出现在这里；但最后会给出一套同样能分析预训练决策的坐标系。
> **最小区别：**监督学习主要让模型模仿已有正确示范；强化学习则让模型实际尝试，根据 Reward 判断结果好坏，再调整 Policy，使高回报行为以后更常出现。
---
## 开场：先看一个最小的后训练现场
假设我们要增强模型的数学能力，给模型一道题：
> 请计算 `17 × 23`，并给出简短步骤。
模型分别尝试了四次：
| 尝试 | 模型回答 | 程序检查结果 |
|---|---|---:|
| A | `17 × 23 = 391` | 1 分 |
| B | `17 × 23 = 381` | 0 分 |
| C | `20 × 23 - 3 × 23 = 391` | 1 分 |
| D | `17 × 23 = 401` | 0 分 |
这张小表已经包含大模型强化学习最重要的几个对象：
```text
Prompt（题目）
↓
Policy / Actor（当前正在训练的模型）
↓ 生成四次
Rollout（让模型实际尝试）
↓
Response / Trajectory（得到的答案或完整行动轨迹）
↓
Verifier（验算程序）
↓
Reward（每次尝试得到 0 分或 1 分）
↓
把“哪些行为应该更常出现”变成参数更新
```
难点出现在最后一步：A 和 C 得了 1 分，我们当然希望模型以后更容易生成它们；B 和 D 得了 0 分，希望它们更少出现。但究竟应该增加或减少多少？如果任务不是一步回答，而是持续两个小时、调用几十次工具的 Coding Agent，最终的成功或失败又该归到哪一步？
PPO、GRPO 等方法主要就在处理这类问题。但在比较它们之前，必须先把图中的角色认全。
---
## 一、先认全训练系统里的基本角色
### 1. Prompt、Response 与 Token
- **Prompt**：交给模型的输入。它可以是一道题，也可以包含系统指令、用户请求、工具说明和此前对话。
- **Response / Completion**：模型针对 Prompt 生成的输出。
- **Token**：模型读写文本时使用的基本单位。一个汉字、英文单词的一部分或标点，都可能占一个或多个 Token。
模型不是一次写出整段回答，而是不断计算“下一个 Token 应该是什么”，逐个生成下去。
### 2. Policy 与 Actor：当前负责做决定的模型
**Policy（策略）**可以先理解成：
> 给定当前输入，模型对“下一步生成什么”所形成的一整套概率规则。
同一个 Prompt 下，模型可能认为 `391` 的概率是 40%，`381` 的概率是 10%，其他答案合计 50%。训练的本质，就是调整这些概率。
在强化学习系统里，当这个模型负责实际生成答案或执行动作时，常把它称为 **Actor（行动者）**。在很多大模型训练系统中，Policy Model 和 Actor 指向同一个模型的不同角色：
- 说 **Policy**，强调它是一套待优化的策略；
- 说 **Actor**，强调它正在 Rollout 系统中执行策略、产生轨迹。
不要误以为 Actor 必然是另一个新模型。
### 3. Rollout 与 Trajectory：尝试过程和留下的轨迹
**Rollout** 是“让当前模型真的尝试一次”的过程。
- 对一道数学题，一次 Rollout 可能就是生成一条完整答案；
- 对 Coding Agent，一次 Rollout 可能包括读代码、搜索、修改文件、运行测试、继续修复，直到成功、失败或达到步数上限。
Rollout 完成后留下的完整记录叫 **Trajectory（轨迹）**，通常包括：
```text
输入 → 模型输出 → 工具调用 → 环境结果 → 下一次输出 → …… → 最终结果
```
实际论文和工程文档有时会混用 Rollout 与 Trajectory。本专题约定：
- Rollout 更强调“生成一次经验”的动作；
- Trajectory 更强调生成后保存下来的训练数据。
### 4. Reward、Verifier 与 Reward Model：谁来打分
**Reward（奖励）**是对一次回答或行动结果给出的分数。
但“分数”必须有人计算。常见的两类评分器是：
| 评分器 | 怎样打分 | 适合什么 | 主要风险 |
|---|---|---|---|
| **Verifier（验证器）** | 用规则、答案、编译器、单元测试或环境状态直接验证 | 数学、代码、格式、工具任务等可验证问题 | 模型可能寻找规则漏洞、偷看测试或走捷径 |
| **Reward Model（奖励模型）** | 从人类或 AI 的偏好数据中学习“哪种回答更好”，再输出分数 | 有帮助性、语气、安全性等难以写成硬规则的问题 | 奖励模型可能有偏差，也可能被策略钻空子 |
必须区分：
- Reward 是最后得到的分数；
- Verifier 或 Reward Model 是产生分数的组件；
- Critic 不是负责判卷的 Reward Model。
### 5. Value 与 Critic：还没结束时，估计未来能得多少分
假设 Coding Agent 已经执行了 20 步，但任务尚未结束。我们想知道：
> 从当前状态继续做下去，预计最终能得多少分？
这个预期叫 **Value（价值）**。负责学习并估计 Value 的模型叫 **Critic（评论者或价值模型）**。
Reward Model 与 Critic 的差别可以这样记：
| 组件 | 核心问题 |
|---|---|
| Reward Model / Verifier | “这次已经产生的结果实际有多好？” |
| Critic | “走到当前状态，接下来预计能有多好？” |
Critic 的好处是可以在任务尚未结束时提供基线，帮助判断某一步是否比预期更好；代价是团队要多训练和运行一个模型，而且 Critic 自己也可能估错。
### 6. Advantage：实际表现比预期好多少
**Advantage（优势）**回答的是：
> 这次行动的结果，相比某个基线，到底好多少或差多少？
只记住这个直觉关系即可：
```text
Advantage ≈ 实际得到的回报 - 原本预期的回报
```
例如，Critic 估计某道题当前平均只有 0.35 的成功机会：
- 最终答对得到 1 分，说明表现高于预期，Advantage 为正；
- 最终答错得到 0 分，说明表现低于预期，Advantage 为负。
训练通常会提高正 Advantage 行为的出现概率，降低负 Advantage 行为的出现概率。这里的“更新模型”，就是通过优化过程调整模型参数。实际算法还会考虑折扣、每个 Token 的归因和稳定更新等问题，但第一章先掌握这个直觉。
### 7. Credit Assignment：结果应该归功或归罪于哪一步
**Credit Assignment（信用分配）**不是在发荣誉证书，而是在回答：
> 最后的 1 分或 0 分，应该怎样分摊给中间每一个 Turn、Action 或 Token？
一步数学题比较简单；长程 Agent 很难：
- 第 3 步选错文件，第 40 步测试才失败；
- 第 10 步得到了关键信息，第 80 步才完成任务；
- 某一步看似失败，却为后续排除了错误路线。
只给整条轨迹一个最终分数，信号便宜但粗；尝试给每一步甚至每个 Token 分配不同 Advantage，信号更细，却需要 Critic、过程验证器或其他估计机制。
### 8. Reference Policy：防止模型一步走得太远
**Reference Policy（参考策略）**通常是训练开始前冻结的一份模型快照。它不负责打分，主要用来回答：
> 新模型的行为已经偏离原模型多远？
DPO 会比较当前 Policy 与 Reference Policy 对偏好答案的相对倾向；很多 PPO 式大模型后训练也会用 Reference Policy 计算 KL 惩罚，防止策略为了追逐奖励而剧烈漂移。
这里的 **KL** 可以先理解成“两个概率分布之间的距离”；不需要在本章推导公式。
### 9. On-policy、Policy Lag 与 Compaction
这三个词会在后面的真实案例中出现：
- **On-policy**：训练数据由当前或非常接近当前版本的 Policy 生成。模型每更新一次，最好用新模型重新采样。
- **Policy Lag**：Rollout 还在使用旧版本生成数据，但 Trainer 已经更新了多个版本。异步系统吞吐更高，却会让数据越来越“过期”。
- **Compaction（上下文压缩）**：长程 Agent 的上下文太长时，把较早的历史压缩成摘要或新的状态表示，再继续任务。用于训练时，一条超长轨迹可能因此被拆成数量和长度不同的多个子轨迹。
这些不是算法旁边无关紧要的工程词。它们会改变训练数据的形状，进而决定某些方法的假设是否成立。
### 10. 在线与离线：训练时还要不要让模型继续尝试
- **离线训练（Offline Training）**：开始训练前，数据已经准备好。训练期间主要反复读取固定数据，例如 SFT 的示范或 DPO 的偏好对。
- **在线 Rollout（Online Rollout）**：训练过程中，当前 Policy 还要不断生成新答案或与环境交互，再把新经验送回 Trainer。
“在线”在这里不是指模型对公众开放，而是指**数据生成与模型更新形成循环**。在线路线能探索当前 Policy 会产生的新行为，但生成数据昂贵，还要处理 Policy Lag、环境故障和训练—推理资源协调。
---
## 二、四条常见路线到底怎样让模型学习
有了上面的角色，现在可以具体看 SFT、DPO、PPO 和 GRPO。为了便于理解，四种路线仍然使用“教模型做数学题”这个例子。
### 1. SFT：直接给模型看好答案
**SFT（Supervised Fine-Tuning，监督微调）**需要的数据最直观：
```text
Prompt：请计算 17 × 23，并给出步骤。
示范答案：20 × 23 - 3 × 23 = 460 - 69 = 391。
```
训练目标是让模型在看到 Prompt 后，更容易生成示范答案中的 Token。
```text
Prompt + 高质量示范
↓
直接训练 Policy 模仿示范
↓
新的 Policy
```
SFT 适合：
- 能写出明确的高质量示范；
- 想教会模型指令格式、回答风格、工具协议或基础任务做法；
- 希望先用最简单、最稳定的路线建立目标行为。
它的限制是：模型主要在模仿已有示范。示范没有覆盖的错误探索、复杂环境互动和“两个都能回答但哪个更好”等问题，不容易只靠 SFT 解决。
> **一句话：SFT 回答“正确示范长什么样”。**
### 2. DPO：不给唯一答案，只告诉模型更喜欢哪一个
有些问题没有唯一标准答案，但人可以判断两个答案哪个更好。此时可以准备偏好对：
```text
Prompt：请解释为什么 17 × 23 = 391。
Chosen（更好）：20 × 23 - 3 × 23 = 460 - 69 = 391。
Rejected（较差）：计算结果是 391，相信我。
```
**DPO（Direct Preference Optimization，直接偏好优化）**直接训练 Policy：相对 Reference Policy，更倾向 Chosen，更不倾向 Rejected。
```text
Prompt + Chosen + Rejected
│
Reference Policy（冻结）
↓
直接更新当前 Policy
```
DPO 的核心训练阶段通常不需要：
- 在线让 Policy 不断生成新 Rollout；
- 单独训练 Reward Model；
- 运行 Critic。
因此系统更像一条离线偏好数据训练管线，通常比在线 RL 简单。但代价是模型主要在既有偏好数据覆盖的范围里学习；如果数据没有包含某种新策略，它也很难通过在线探索发现。[DPO 原论文](https://arxiv.org/abs/2305.18290)
> **一句话：DPO 回答“在已有的两个答案里，更希望模型倾向哪一个”。**
### 3. Critic-based PPO：实际尝试、获得奖励，再做受约束的更新
**PPO（Proximal Policy Optimization，近端策略优化）**是一类策略更新方法。`Proximal` 可以理解成“别一次走得太远”：即使某批 Rollout 得分很高，也限制一次参数更新的幅度，避免 Policy 突然发生过大的变化。[PPO 原论文](https://arxiv.org/abs/1707.06347)
需要严谨地区分：
> PPO 本身主要规定怎样做受约束的策略更新；它不规定 Reward 必须来自人类，也不从定义上强制必须有 Critic。
不过，在大模型在线强化学习中，常见的是 **Critic-based PPO**：用 Actor 生成 Rollout，用 Reward Model 或 Verifier 打分，再用 Critic 估计 Value、计算更细粒度的 Advantage。
```text
当前 Actor / Policy
↓ 在线 Rollout
答案或多轮轨迹
↓
Reward Model / Verifier 给出 Reward
↓
Critic 估计 Value → 计算 Advantage
↓
PPO 限制单次更新幅度
↓
更新 Actor，同时避免偏离 Reference Policy 太远
```
它适合考虑的场景包括：
- 可以让模型与任务环境反复交互；
- 轨迹很长、长度不规则；
- 单条 Rollout 也希望产生训练价值；
- 希望进行 Turn 级或 Token 级的细粒度信用分配；
- 团队能够承担 Critic 的训练和资源成本。
它的系统代价也最直观：
- Actor 要生成数据；
- Critic 要训练和推理；
- Reward Model 或 Verifier 要提供奖励；
- Reference Policy 常用于限制漂移；
- 多个模型要共享或争夺 GPU、显存与网络；
- Rollout 和训练版本要保持足够接近。
> **一句话：Critic-based PPO 回答“模型实际尝试后，哪些动作比预期好，并在不让策略突变的前提下怎样更新”。**
### 4. GRPO：不训练 Critic，用同题多次尝试互相比较
**GRPO（Group Relative Policy Optimization，组相对策略优化）**由 DeepSeekMath 提出，是 PPO 的一种变体。它最关键的变化是：不依赖单独的 Critic，而是让同一个 Prompt 生成一组回答，用组内分数作为相对基线。[DeepSeekMath 论文](https://arxiv.org/abs/2402.03300)
仍然看开头的四次尝试：
| 回答 | Reward | 相对组平均表现 |
|---|---:|---|
| A | 1 | 高于组平均，正 Advantage |
| B | 0 | 低于组平均，负 Advantage |
| C | 1 | 高于组平均，正 Advantage |
| D | 0 | 低于组平均，负 Advantage |
GRPO 的直觉流程是：
```text
同一个 Prompt
↓ 当前 Policy 生成 K 个回答
回答 1、回答 2、……、回答 K
↓
Verifier / Reward Model 分别打分
↓
用组内平均值和分布计算相对 Advantage
↓
使用 PPO 风格的受约束目标更新 Policy
```
它省掉了 Critic，降低了模型数量、显存和价值学习的复杂度；但它增加了新的前提：
- 同一个 Prompt 能够生成多条样本；
- 这些样本具有可比性；
- 组内 Reward 有足够差异；
- 生成 K 条样本的成本可以接受；
- 如果环境故障导致样本缺失，系统能补齐或正确处理不完整的组。
如果一组答案全部得 1 分，或全部得 0 分，大家都和组平均一样，组内相对信号就会退化。对很长、长度悬殊、经过 Compaction 的 Agent 轨迹，“一组样本”本身也可能很难定义。
> **一句话：GRPO 回答“同一道题做了多次，哪些尝试相对同组更好”，用成组采样换掉 Critic。**
### 5. 四条路线放在一起看
| 路线 | 最小训练数据 | 需要在线 Rollout | 独立 Critic | 主要获得 | 主要代价或限制 |
|---|---|---:|---:|---|---|
| **SFT** | Prompt + 示范答案 | 否 | 否 | 学会模仿明确的目标行为 | 高度依赖示范质量和覆盖 |
| **DPO 类** | Prompt + Chosen + Rejected | 核心训练阶段通常不需要 | 否 | 用较简单的离线管线学习偏好 | 受离线数据分布和偏好质量限制 |
| **GRPO 类** | Prompt + 同题多条 Rollout + Reward | 是 | 通常不需要 | 用组内比较学习，并省去 Critic | 要求样本组可构造、可比较且有 Reward 方差 |
| **Critic-based PPO** | 在线 Rollout + Reward + Value 估计 | 是 | 是 | 单轨迹学习与更细粒度信用分配 | Critic、GPU、同步和稳定性成本更高 |
这张表不是先进程度排名。它只是在说明：**输入数据不同、学习问题不同、需要的系统组件也不同。**
---
## 三、RLHF、RLAIF 和可验证奖励为什么不与 PPO 平级
现在再看这组经常被混写的词：
```text
RLHF vs RLAIF vs DPO vs PPO vs GRPO
```
问题在于它们位于不同决策层。
### 1. RLHF：反馈主要来自人
**RLHF（Reinforcement Learning from Human Feedback）**描述的是利用人类反馈塑造模型行为的一类流程。
经典的 InstructGPT 路线是：
```text
人类示范 → SFT
人类比较模型回答 → 训练 Reward Model
Reward Model 打分 → PPO 更新 Policy
```
所以，PPO 可以是 RLHF 流程内部使用的优化方法，二者不是互斥选项。[InstructGPT 论文](https://arxiv.org/abs/2203.02155)
### 2. RLAIF：反馈主要来自 AI
**RLAIF（Reinforcement Learning from AI Feedback）**主要把人类直接评价替换成 AI 评价，以降低标注成本、扩大数据规模。
它仍然没有规定最后必须使用 PPO 还是其他方法。AI 反馈可以用来：
- 产生偏好对，再做 DPO；
- 训练 Reward Model，再进行 PPO；
- 与规则、安全原则或人工抽检共同组成奖励。
### 3. 可验证奖励：反馈来自规则、程序或环境
数学答案、单元测试、编译结果、游戏胜负和工具任务完成状态，都可以形成 **可验证奖励**。它描述的是奖励来源，不是特定优化器。
同一种可验证奖励，可以搭配：
- GRPO：同题采多条结果，做组内相对比较；
- Critic-based PPO：从单条或长程轨迹学习；
- 其他策略优化方法。
因此，正确的分层方式是：
| 决策层 | 它回答什么 | 典型选项 |
|---|---|---|
| **反馈来源** | 谁来定义“更好” | 人类、AI、规则、Verifier、环境 |
| **数据组织** | 训练材料长什么样 | 示范、偏好对、单条 Rollout、成组 Rollout、长程轨迹 |
| **信用分配** | 最终结果怎样归因 | 整条轨迹、过程奖励、Critic、组内相对基线 |
| **策略更新** | 参数怎样稳定变化 | SFT、DPO、PPO、GRPO 等 |
| **系统实现** | 需要哪些组件 | Actor、Critic、Reward Model、Verifier、Reference、Rollout Workers |
> **架构智慧：**遇到“A 还是 B”时，第一问不是谁更强，而是 **A 和 B 是否在回答同一个问题**。如果一个描述反馈从哪里来，另一个描述参数怎样更新，它们就可以同时存在，不能被放进单选题。
---
## 四、再分清三种“架构”
“预训练架构”“后训练架构”容易产生歧义，因为训练讨论中至少存在三种结构。
### 1. 模型架构：一次前向计算怎样发生
它描述模型内部的计算结构，例如：
- Dense：每个 Token 通常经过各层相同的稠密参数；
- MoE：主要在部分前馈网络中，只激活被路由选中的少数专家；
- Attention（决定生成当前 Token 时应该关注哪些上下文信息）；
- 多模态编码器和连接器。
模型架构主要改变参数容量、激活计算、显存、通信和推理特征。其中 **GPU** 是训练模型常用的并行计算设备，**显存**是 GPU 上保存参数、激活值等训练数据的高速内存。本章暂不展开 Dense/MoE，只要知道它们和 PPO/GRPO 不在同一层：前者改变模型怎样计算，后者改变模型怎样学习。
### 2. 训练方法：模型根据什么信号更新
它描述学习目标与更新方式，例如：
- Next-token Prediction；
- SFT；
- DPO；
- PPO、GRPO；
- 蒸馏（用较强的 Teacher Model 产生信号，训练更小或更便宜的 Student Model）。
它会改变训练样本形态、损失或奖励信号、是否需要在线 Rollout，以及参数怎样被更新。
### 3. 训练系统架构：哪些组件一起把方法运行起来
它描述工程系统，例如：
- 数据生产和版本管理；
- Actor、Critic、Reward Model、Verifier；
- Rollout 集群与训练集群；
- 同步或异步流水线；
- Checkpoint（训练快照）、评测门禁与模型注册。
三者最终形成一条约束链：
```text
能力目标
↓
模型架构 + 训练方法
↓
需要怎样的数据、计算图和辅助模型
↓
训练系统拓扑、资源账单和故障边界
↓
评测证据是否证明这次选择值得
```
例如，选择 GRPO 不只是换一个 Loss（损失函数，即系统用来衡量训练目标偏差的计算规则）：系统不再训练 Critic，但必须为同一 Prompt 生成多条可比较 Rollout，并维护完整的样本组。选择 Critic-based PPO 也不只是换算法：系统需要部署和训练 Critic，为它分配显存与 GPU，并处理价值估计偏差。
> **判断边界：一种技术只有在改变数据形态、计算图、系统拓扑、资源账单或失败模式时，才成为本教程重点讨论的架构问题。**
---
## 五、训练决策的八层坐标系
以后遇到任何模型训练方案，都可以沿着下面八层从上往下拆。越靠上越接近“为什么训练”，越靠下越接近“系统怎样承载”。
```text
① 能力目标：到底想让模型变好在哪
↓
② 训练材料：模型实际看到什么
↓
③ 学习信号：系统怎样定义“更好”
↓
④ 信号粒度与信用分配：好坏归到哪一步
↓
⑤ 优化方法：参数怎样更新
↓
⑥ 模型与辅助组件：运行时需要哪些模型
↓
⑦ 训练系统拓扑：这些组件如何生成、训练和同步
↓
⑧ 晋级证据：怎样证明收益大于新代价
```
### ① 能力目标：到底想让模型变好在哪
不要从“我们要上 RL”开始，而要先写清可检验的目标：数学答案正确率、代码测试通过率、多轮工具任务完成率、指令遵循或安全拒答准确率。
可自动验算的代码任务和主观的写作偏好，不应该使用同一套奖励生产方式。
### ② 训练材料：模型实际看到什么
数据可能是原始 Token、Prompt 与示范答案、Chosen/Rejected 偏好对、同题一组候选输出，或包含环境反馈的多轮轨迹。
DPO 需要离线偏好对；组内相对方法需要同题多条可比较样本；长程 Agent RL 必须处理环境状态、工具结果和延迟奖励。
### ③ 学习信号：系统怎样定义“更好”
信号可能来自目标 Token、人类偏好、AI 评价、规则、Verifier 或环境最终结果。
人类评价昂贵且有分歧；AI 评价可以规模化但会继承模型偏差；可验证奖励便宜明确，却可能诱导模型寻找验证器漏洞。
### ④ 信号粒度与信用分配：好坏归到哪一步
奖励可以只落在整条 Sequence，也可以细化到 Turn、Step 或 Token。
粒度越粗，信号越容易获得，但越难判断中间步骤的贡献；粒度越细，归因更有表现力，但需要 Critic、过程监督或可靠的中间验证器，并会引入新的估计误差。
### ⑤ 优化方法：参数怎样更新
走到这一层，才开始选择：
- 有高质量示范，先考虑 SFT；
- 有离线偏好对、不能承担在线采样，DPO 类路线更自然；
- 能廉价生成同题多条可比答案、组内奖励有差异、Critic 成本敏感，GRPO 类路线更自然；
- 轨迹长而不规则、单条样本也必须学习、需要细粒度信用分配，Critic-based PPO 更自然。
“更自然”只表示方法假设更贴近问题，不等于无需实验验证。
### ⑥ 模型与辅助组件：运行时需要哪些模型
| 路线 | 主要组件 | 系统直接接走什么代价 |
|---|---|---|
| SFT | Policy | 示范数据质量与覆盖 |
| DPO 类 | Policy + Reference Policy 或预计算参考 Log-prob（参考模型给某段文本的概率记录） | 偏好对生产、参考计算、离线分布限制 |
| GRPO 类 | Policy + Reward/Verifier，通常无独立 Critic | 同 Prompt 多样本、组完整性、组内方差 |
| Critic-based PPO | Actor + Critic + Reward/Verifier，通常还有 Reference Policy | 多模型显存、GPU 调度、价值学习与同步 |
省掉 Critic 并不是白赚：省下模型和 GPU 的同时，系统接走了成组采样和相对比较的约束。
### ⑦ 训练系统拓扑：组件如何生成、训练和同步
```text
任务 / Prompt
↓
Rollout Workers（负责生成经验的工作进程）
├──────────────▶ 环境 / 工具 / Verifier
↓
轨迹与奖励
↓
Trainer（负责更新参数）◀── Policy / Critic / Reference
↓
新 Policy 版本 ──▶ 下一轮 Rollout
```
此时要判断：Rollout 与训练同步还是异步；Actor、Critic 与 Verifier 共置还是分离；旧 Policy 生成的数据过期到什么程度还能用；环境失败时补样本、丢整组还是保留部分轨迹。
算法论文里的一个选择，进入生产后会变成队列、调度、版本、容错和可观测性问题。
### ⑧ 晋级证据：怎样证明收益大于新代价
训练完成不等于方案成立。至少需要证明：
- 目标能力提升；
- 非目标能力没有不可接受的回退；
- 训练足够稳定；
- 单位算力收益合理；
- 没有通过 Reward Hacking 虚增分数；
- 结论来自受控消融，而不是同时改变数据、算法和模型规模。
其中：
- **Reward Hacking（奖励投机）**：模型找到评分规则的漏洞，分数变高了，真实能力却没有提高。例如 Coding Agent 读取隐藏测试答案，而不是自己解决问题。
- **消融实验（Ablation Study）**：尽量只改变一个因素，其余条件保持一致，用来判断提升究竟来自数据、奖励、算法还是模型规模。
> **架构智慧：**训练方法不是从论文标题直接落到集群配置。中间必须经过“目标—材料—信号—归因—优化—组件—系统—证据”八层翻译。
---
## 六、真实案例：GLM-5.2 为什么转向 Critic-based PPO
现在基础概念齐了，再来看本章的真实案例。
[GLM-5 技术报告](https://arxiv.org/abs/2602.15763)分别说明其 RL 算法建立在 GRPO 之上、Agentic RL 采用组式策略优化：同一个问题生成多条轨迹，用组内相对结果形成训练信号。
到了 GLM-5.2，任务形态发生变化：[官方说明](https://z.ai/blog/glm-5.2)描述了面向超长程 Agent 任务的训练问题：
```text
任务变成长程、多轮 Agent 交互
↓
超长轨迹经过 Compaction，被切成多个可训练子轨迹
↓
同一 Prompt 产生的子轨迹数量不同、长度差异很大
↓
“同一 Prompt 采一组规整、可比较轨迹”的假设不再自然
↓
转向 Critic-based PPO
↓
从单条 Rollout 学习，由 Critic 估计 Token 级 Advantage
```
把它放回八层坐标系：
| 判断层 | GLM-5 报告中的组式路线 | GLM-5.2 的长程任务约束 |
|---|---|---|
| 能力目标 | Agentic、Reasoning、Coding | 更长程、更复杂的 Agentic 工程任务 |
| 训练材料 | 同一 Prompt 下成组生成多条轨迹 | Compaction 后数量、长度不规则的子轨迹 |
| 信用分配 | 组归一化的相对 Advantage | Critic 估计 Token 级 Advantage |
| 优化方式 | GRPO 与组式策略优化 | Critic-based PPO、单 Rollout 训练 |
| 模型组件 | 不需要独立 Critic | 增加 Critic |
| 系统影响 | 必须生成并维护可比较样本组 | Actor、Critic、Rollout 的额外资源与同步 |
| 主要风险 | 全对/全错、组不完整、轨迹不可比 | Critic 偏差、Value 不稳、资源成本上升 |
[slime 官方文档](https://github.com/THUDM/slime/blob/main/docs/en/get_started/usage.md)直观展示了系统成本：GRPO 不需要 Critic；其 PPO 工作流则要分别考虑 Actor、Critic 和 Rollout 的 GPU 资源。
因此，GLM-5.2 的判断不是：
> PPO 比 GRPO 更先进。
而是：
> **长程、变长、经过 Compaction 的轨迹不再匹配规整组内比较的前提，因此团队愿意支付 Critic 的训练和资源成本，换取单轨迹学习与 Token 级信用分配。**
这也不代表智谱在所有任务上放弃组内相对方法。如果任务是短答案、同题可以便宜地产生多条可比较结果、Reward 有足够组内方差，而且 Critic 成本很高，GRPO 类路线仍可能更合理。
正确复用的不是“选择 PPO”这个答案，而是：
```text
任务形态
→ 数据与轨迹形态
→ 方法依赖的假设
→ 模型与系统拓扑
→ 新成本和失败模式
→ 晋级证据
```
---
## 七、同一坐标系怎样解释预训练与后训练
预训练和后训练通常延续同一模型族的主体骨架，但数据、学习信号和控制系统并不相同。
| 判断层 | 预训练中的典型问题 | 后训练中的典型问题 |
|---|---|---|
| 能力目标 | 通用语言、代码、数学、多语言、长上下文基础能力 | 指令遵循、偏好、推理、工具使用、安全行为 |
| 训练材料 | 大规模 Token 序列和数据混合 | 示范、偏好对、合成数据、Rollout 轨迹 |
| 学习信号 | 主要来自目标 Token | 示范目标、偏好、Reward、Verifier、环境反馈 |
| 信号粒度 | 通常是 Token 级训练目标 | Sequence、Turn、Step 或 Token 级反馈与归因 |
| 优化选择 | 数据配方、模型结构、优化器与并行训练协同 | SFT、DPO、PPO、GRPO、蒸馏等组合 |
| 辅助组件 | 数据管线、训练器、Checkpoint、基础评测 | Reward Model、Critic、Verifier、环境、Rollout Workers |
| 系统瓶颈 | 数据吞吐、显存、通信、数值稳定性、故障恢复 | Rollout 吞吐、奖励质量、多模型资源、Policy Lag |
| 晋级证据 | 基础能力、随数据/模型/算力扩展获得的收益、污染检查、训练稳定性 | 目标行为、能力回退、安全、Reward Hacking、真实任务表现 |
后续章节可以分别深入 Dense/MoE、数据配方、并行策略、Checkpoint、SFT、偏好优化和强化学习，但每一章都会继续使用同一套判断语言。
---
## 八、以后每个训练决策都写成一份 ADR
训练实验经常只记录配置和最终分数，却没有记录“为什么选择这条路线”。可以把 [08 · 架构决策记录与演进](08-架构决策记录与演进.md) 的 ADR（Architecture Decision Record，架构决策记录）方法直接带进模型训练。
```markdown
# ADR-Txx：训练方案决策标题
## 1. 能力目标
我们要提升什么？用什么指标判断？哪些能力不能回退？
## 2. 工作负载与训练材料
样本是 Token、偏好对还是交互轨迹？单轮还是长程？长度和质量怎样分布？
## 3. 学习信号与信用分配
谁定义“更好”？信号落在 Sequence、Turn、Step 还是 Token？
## 4. 候选方案及其假设
每个方案成立需要哪些数据、采样、模型和稳定性前提？
## 5. 决策
选择什么？为什么当前约束更匹配它？
## 6. 系统影响
新增或删除哪些模型、数据管线、队列、GPU 角色、Checkpoint 和监控？
## 7. 代价与失败模式
复杂度被转移到了哪里？最可能怎样失败？
## 8. 验证与晋级门禁
做哪些消融？哪些指标必须提升？什么回退会阻止 Checkpoint 晋级？
## 9. 退出条件
出现什么信号时切换方案或回滚？
```
这份模板强迫团队把“某篇论文效果很好”翻译成当前系统能够检验的假设。
---
## 九、五种最常见的错误判断
### 错误 1：按发布时间排列先进程度
新方法可能只在特定数据、任务、模型或硬件约束下更合适。离开原约束，结论不自动成立。
### 错误 2：把不同层级的概念做成单选题
“RLHF 还是 PPO”类似于问“支付流程还是数据库事务”：一个描述整体流程，一个描述其中可能采用的机制。
### 错误 3：只比较算法效果，不画系统拓扑
如果比较没有计入 Reward Model、Critic、Rollout、环境和通信成本，算法收益就不是完整的工程收益。
### 错误 4：复制别人的答案，不复制别人的约束
看到 GLM-5.2 使用 PPO 就跟进，却没有长程、变长、Compaction 轨迹，也不需要 Token 级信用分配，复制的只是结论，不是推理过程。
### 错误 5：分数提高就宣布架构成立
一次改动可能提高目标榜单，同时损害通用能力、安全性、训练稳定性或单位算力效率。模型晋级必须看一组证据，而不是一个最好看的数字。
---
## 🎯 随堂检验
---
## 本章小结
- **Policy 是当前要优化的模型策略；Actor 是它在 Rollout 中执行策略的角色。**
- **Rollout 是实际尝试，Trajectory 是留下的完整经验记录。**
- **Reward 评价结果；Critic 估计未来 Value；Advantage 衡量实际表现相对基线好多少。**
- **SFT 学示范，DPO 学离线偏好，GRPO 用同题成组比较省掉 Critic，Critic-based PPO 用额外价值模型换取单轨迹与细粒度归因能力。**
- **RLHF、RLAIF 和可验证奖励主要描述反馈来源或训练流程，不与 PPO、GRPO 构成简单的互斥关系。**
- **训练方案不是算法排行榜。** 正确顺序是目标 → 材料 → 信号 → 归因 → 优化 → 组件 → 系统 → 证据。
- **GLM-5.2 的启示不是 PPO 胜过 GRPO。** 它说明长程、变长、经过 Compaction 的轨迹不再自然匹配规整组内比较，于是团队愿意支付 Critic 成本，换取单轨迹学习与 Token 级归因。
- **复用推理，不复制答案。** 每项训练决策都要写清候选方案的前提、系统影响、消融证据和退出条件。
> **下一章的问题：**建立判断坐标系以后，预训练的第一项根本决策不是选框架，而是确定有限计算预算应该分给模型参数、训练 Token，还是更高质量的数据。
---
## 基础术语速查
| 术语 | 初学者可以先怎样理解 |
|---|---|
| Policy | 当前模型关于“下一步做什么”的概率规则 |
| Actor | Policy 在系统中实际生成答案或执行动作时的角色 |
| Rollout | 让当前 Policy 完整尝试一次 |
| Trajectory | 一次尝试留下的输入、输出、动作、环境结果记录 |
| Reward | 对已经产生的结果给出的分数 |
| Verifier | 用规则、测试或环境状态计算 Reward 的组件 |
| Reward Model | 从偏好数据中学会给结果打分的模型 |
| Value | 从当前状态继续行动，预计最终能得到的回报 |
| Critic | 学习并估计 Value 的模型 |
| Advantage | 实际表现相对预期基线好多少或差多少 |
| Credit Assignment | 把最终结果归因到中间 Turn、Action 或 Token |
| Reference Policy | 冻结的参考模型，用于约束当前 Policy 不要漂移太远 |
| On-policy | 训练数据来自当前或非常接近当前版本的 Policy |
| Policy Lag | 生成数据的 Policy 版本落后于正在训练的版本 |
| Compaction | 压缩长程历史，并可能把超长轨迹拆成多个子轨迹 |
| Fine-tuning | 在已有模型上继续训练，而不是从零开始 |
| Offline Training | 使用训练前已经准备好的固定数据 |
| Online Rollout | 训练期间让当前 Policy 持续产生新经验 |
| Checkpoint | 某个训练时刻保存的模型参数及恢复训练所需状态 |
| Reward Hacking | 钻评分规则漏洞获得高分，但没有真正完成目标 |
| Ablation Study | 每次尽量只改一个因素，用来确认提升来自哪里 |
---
## 相关链接
- 本仓库方法论：[02 · 架构师的思考框架](02-架构师的思考框架.md) · [08 · 架构决策记录与演进](08-架构决策记录与演进.md) · [13 · 规模化的力学](13-规模化的力学.md)
- 案例材料：[GLM-5 技术报告](https://arxiv.org/abs/2602.15763) · [GLM-5.2 官方说明](https://z.ai/blog/glm-5.2) · [slime 使用文档](https://github.com/THUDM/slime/blob/main/docs/en/get_started/usage.md)
- 方法来源：[InstructGPT / RLHF](https://arxiv.org/abs/2203.02155) · [DPO](https://arxiv.org/abs/2305.18290) · [DeepSeekMath / GRPO](https://arxiv.org/abs/2402.03300) · [PPO](https://arxiv.org/abs/1707.06347)