02 PPO 与 GRPO 原理

学习理念：这一讲的是"怎么让策略更新既快又稳"。用一个比方记住全部：PPO 就是"改代码时不许一次性改 1000 行，每次最多改 20 行，改完跑测试，通过了再改下一版"。 GRPO 则是"没有测试经理（Critic）了，让同组几个人互相打分来评估"。
预习一道面试题：面试官问你"PPO 为什么比策略梯度法稳定？"——答："因为 PPO 给每次更新加了限制，不允许一步走太远。"

📖 阅读优先级

等级	章节	说明
🔴 必须深入	PPO 裁剪目标	面试必考，但用一个比方 3 秒就能懂
🟡 理解即可	GRPO	知道"去掉了 Critic，用组内对比代替"就够了

一、策略梯度法的"死穴"——一步走太远

🟡 【理解即可】 先搞懂一个问题，才能理解 PPO 解决了什么。

比方：闭着眼睛下楼梯

策略梯度法更新参数，就像闭着眼睛下楼梯：
  你迈出了一步（更新参数）→ 感觉了一下（看新的回报）
  → 如果感觉"哎哟不错"，下次再多迈一点
  → 如果感觉"卧槽要摔"，下次就收回来

问题是：你**步子迈太大了**。
  明明只需下一级台阶，你直接跳了 3 级 → 摔了 → 训练崩溃！

PPO 解决的就是这个问题——给每一步更新加个围栏，不许跨太大。

二、PPO——"规范代码 review 的团队规范"

🔴 【必须深入】 PPO 的裁剪机制，用一个程序员的比方 10 秒就能懂。

2.1 比方：Code Review 卡 diff 大小

想象你们团队有个 git 规范：每次 PR（Pull Request）的 diff 行数不能超过 ±20%。

这次提交（新策略）和 main 分支（旧策略）对比：

文件 A：改了 50 行    ← 超出 ±20%，被 CI 卡住了！不行
文件 B：改了 6 行     ← 在范围内，通过
文件 C：改了 800 行   ← 严重超标，根本不让提 PR

PPO 的裁剪（clip）干的就是一模一样的事：

r(θ) = 新策略概率 / 旧策略概率

如果 r(θ) > 1.2  → 不行！这次更新太大了，clip 到 1.2
如果 r(θ) < 0.8  → 不行！反向也太大，clip 到 0.8
         ↑ 这个 [0.8, 1.2] 就是 PPO 的"diff 限制"

2.2 程序员类比：npm 版本号

PPO 的裁剪范围 [1-ε, 1+ε] 就像 npm 的版本号约束：

策略更新版本号：1.0.0 → 1.0.1（patch，小改） ✅ PPO 允许
策略更新版本号：1.0.0 → 2.0.0（major，大改） ❌ PPO 裁剪掉

🔴 【必须深入】 一句话说清楚 PPO： "PPO 就是给策略更新加了版本号约束——只允许 patch 级更新，不允许 major 级更新。"

2.3 PPO 完整流程（极简版）

每一轮迭代：
  1. 用当前策略去环境里"跑一跑"，收集一些经验数据
  2. 看看哪些动作比预期好（正优势），哪些比预期差（负优势）
  3. 让策略朝着"多做正优势动作"的方向更新一点点
  4. 重点来了——检查更新幅度：如果某动作概率翻了一倍以上？裁掉！
  5. 用裁减后的更新更新策略
  6. 回到 1

2.4 PPO 的完整损失函数（看一眼就行）

python

# PPO 损失 = 策略损失 + 价值损失 + KL 惩罚
L_total = -min(r · A, clip(r, 1-ε, 1+ε) · A) + MSE(V_pred, G) + β · KL

# 你只需要记住"clip"两个字——面试官问 PPO，你就说"clip"

三、GRPO——"没有经理了，小组成员互相打分"

🟡 【理解即可】 GRPO 是 DeepSeek 提出来的，核心是砍掉了 Critic（价值模型）。为什么能砍？用一个大白话的比方说明。

3.1 比方：小组作业打分

传统方式（PPO-RLHF）= 有导师打分：

小组 5 个同学各自做了方案 → 导师（Critic）挨个看 → "小王 85 分，小李 70 分"
→ 大家按导师的分数改进

GRPO 的方式 = 组内互评：

小组 5 个同学各自做了方案 → 没有导师！→ 直接把 5 个方案放一起对比排名
→ "小王比平均好一点，小李比平均差一点"
→ 大家按相对分数改进

GRPO 就是后者——对同一个 prompt 生成多个回答，在组内比高低，而不是用一个单独模型去估值。

3.2 GRPO 的数学（极简）

对同一个 prompt，Actor 生成 G 个回答
→ 给每个回答打分（用 Reward Model）
→ 算这 G 个分数的均值和标准差
→ 每个回答的"优势" = (自己分数 - 平均分) / 标准差
→ 用 PPO 同样的 clip 机制更新

3.3 PPO vs GRPO 一句话对比

维度	PPO	GRPO
需要几个模型	4 个（Actor+Critic+Ref+RM）	3 个（不用 Critic）
怎么算优势	用 Critic 网络预估"这个状态值多少钱"	组内分数归一化
显存省了？	—	省了 25-30%
谁在用	ChatGPT/Claude	DeepSeek-R1

四、本节小结——脑图

RL 更新策略的问题 = 闭眼下楼梯（一步太大会摔）
         ↓
PPO 的解法 = 给每次更新加 diff 限制（±20%）
         ↓ 像 git PR 卡 diff、npm 只允许 patch 版本
         ↓
GRPO 更进一步 = 砍掉 Critic，小组互评代替导师打分
         ↓ 像小组作业没有老师，组内比高低
         ↓
DeepSeek-R1 = GRPO 的典型成功案例

02 PPO 与 GRPO 原理 ​

📖 阅读优先级 ​

一、策略梯度法的"死穴"——一步走太远 ​

二、PPO——"规范代码 review 的团队规范" ​

2.1 比方：Code Review 卡 diff 大小 ​

2.2 程序员类比：npm 版本号 ​

2.3 PPO 完整流程（极简版） ​

2.4 PPO 的完整损失函数（看一眼就行） ​

三、GRPO——"没有经理了，小组成员互相打分" ​

3.1 比方：小组作业打分 ​

3.2 GRPO 的数学（极简） ​

3.3 PPO vs GRPO 一句话对比 ​

四、本节小结——脑图 ​