GRPO：没有 Critic，模型如何知道这次回答更好
GRPO 是 Group Relative Policy Optimization，群体相对策略优化。它最容易被误解的地方，是名字里有“相对”二字：模型不是只看一个回答拿了多少分，而是在同一个问题的多条回答之间比较谁更好。
先看一个回答组
给定同一个 prompt，模型生成 G 个回答：
prompt
-> response 1 -> reward 0.2
-> response 2 -> reward 0.9
-> response 3 -> reward 0.6
-> response 4 -> reward 0.1GRPO 可以在这个组内计算平均奖励和标准差，再把每条回答转成相对优势：
A_i = (reward_i - mean(rewards)) / (std(rewards) + small_value)于是 response 2 得到正优势，response 1 和 response 4 得到负优势。模型并不需要一个单独的 value model 来告诉它绝对价值是多少，它先知道这组里哪些回答相对更好。
它和 PPO 有什么关系
GRPO 可以看成 PPO 思路的一种变体：仍然需要根据优势调整策略，也通常保留裁剪目标和 KL 约束；变化主要发生在 advantage 的来源。
PPO：通过 critic 或 value model 估计 advantage
GRPO：通过同一 prompt 的回答组计算相对 advantage这带来一个直接的工程好处：训练时不必额外维护和更新一个 critic 模型，显存压力和训练链路可以降低。
但代价也很明确：同一个 prompt 需要生成多条回答，生成成本会上升；如果一组回答的 reward 都一样，标准化后几乎没有有效的学习信号。
为什么相对奖励适合可验证任务
数学题、代码题、结构化输出等任务，往往可以设计相对清晰的 reward：
- 最终答案是否正确
- JSON 是否可以解析
- 字段是否满足 schema
- 代码是否通过测试
- 输出是否包含不允许的额外文字
对于这类任务，组内比较比要求一个 reward model 给出绝对准确的分数更容易落地。
例如 JSON 任务可以拆出多维奖励：
parseable JSON -> +1
schema valid -> +1
required fields -> +1
answer correct -> +2
extra text -> -1具体权重不是越多越好。奖励维度越多，越需要验证每一项是否真的推动了目标行为。
GRPO 的一个最小训练过程
一次更新可以抽象成：
1. 从数据集中取一个 prompt
2. 对同一个 prompt 生成 G 个 completion
3. 用 reward function 给每个 completion 打分
4. 在组内归一化 reward，得到相对 advantage
5. 用策略目标更新模型
6. 用 KL 或其他约束控制策略漂移这个过程的关键不是“生成更多答案”，而是保证同一组回答确实在回答同一个问题，并且 reward 能区分它们。
组内奖励的几个坑
所有回答都拿到同一个分数
如果 reward 只有“通过/不通过”，而采样组里所有回答都通过或都失败，那么这一组提供不了多少方向信息。可以增加难度、扩大任务多样性，或重新检查采样温度和 reward 设计。
奖励被长度带偏
如果长回答更容易碰到关键词，模型可能学会堆砌内容。结构化任务通常应当对额外文字、重复字段和无关推理设置明确惩罚。
格式奖励压过正确性奖励
模型可能先学会输出一个漂亮的 JSON，却没有学会 JSON 里的答案是否正确。格式、结构和语义奖励需要分层观察，不能只看总 reward。
采样随机性不足
如果同一 prompt 生成的回答几乎一模一样，组内比较就失去意义。随机性太高又会让训练信号变得嘈杂，需要通过温度、top-p 和生成长度找到合适范围。
GRPO 并不是“免费 PPO”
GRPO 去掉 critic 并不代表训练成本消失。它把一部分成本换成了同 prompt 多次采样，还需要更仔细地设计 reward、分组和评估。
它更适合这样的场景：
- 有可计算的验证器
- 能接受多次生成的开销
- 任务结果可以在组内比较
- 不希望额外维护 critic
如果任务的好坏只能依靠非常主观的长期判断，GRPO 的相对 reward 可能并不容易稳定工作。
我对 GRPO 的理解
GRPO 的核心不是“不要 Critic”，而是把学习基线放到了同一个问题的回答组里。它关心的问题变成：
针对同一个任务，这些回答谁更值得提高概率？只要 reward 可以验证，组内相对排序就能提供一个简单而有用的训练信号。这也是它在数学推理和结构化输出任务中很有吸引力的原因。