回答这道题的第一步是纠正题干：GRPO 的全称是 Group Relative Policy Optimization，也就是组相对策略优化，不是 Generalized Reward-free Policy Optimization。它并不 reward-free，仍然要给每条回答奖励。奖励可以来自规则、可执行验证、环境结果或奖励模型。它省掉的是单独学习的价值模型或 critic，而不是奖励本身。
PPO 在大模型对齐里通常让当前或近当前策略生成回答，再由奖励模型、规则或环境打分，用价值函数估计 advantage，最后用 clipped objective 更新策略。很多 RLHF 实现还会增加相对参考模型的 KL 惩罚。逻辑上常见 policy、reference、reward 和 value 四种角色，但它们可以共享骨干或用不同部署方式，不能说 PPO 永远是四个完全独立模型，也不能保证“复杂但非常稳定”。它会对奖励尺度、价值估计、KL 和 rollout 分布敏感。
DPO 使用固定的偏好对：同一个 prompt 下有 chosen 和 rejected。它不训练独立奖励模型，不需要 value model，也不做在线 rollout，而是利用策略与冻结参考策略的对数概率比，直接优化 chosen 相对 rejected 的偏好。工程链路更接近 SFT，适合已有高质量离线偏好数据的场景。但它仍受 beta、标签噪声、长度偏差、参考模型和分布覆盖影响，不能用一句“长文本下 BT 假设自然失效”概括效果。
GRPO 则对同一个 prompt 采样一组回答，分别得到奖励，再用组内均值和方差把每条回答转换为相对 advantage。高于组平均的样本被鼓励，低于平均的被抑制，然后使用类似 PPO 的裁剪策略目标，并可加入参考模型 KL。这样不需要 learned critic，减少了一类模型和价值估计误差；代价是每个 prompt 要生成一组候选，奖励必须能把组内答案区分开。如果奖励几乎相同，归一化信号就很弱；如果规则有漏洞，也会出现 reward hacking。
我的选型顺序是先看反馈。只有静态偏好对、预算有限，优先 DPO；有可信在线奖励、需要策略持续探索，而且能承担 value training，考虑 PPO；同一问题可以采多条回答并可靠验证，希望省掉 critic，GRPO 更合适。数学或代码任务经常适合可验证奖励，但这不是算法保证。
评估时三者都要在同模型、同 token 预算下看真实任务成功率、人工盲评、KL、回复长度和失败切片。PPO 看 value loss 与 advantage，DPO 看偏好留出集和长度偏差，GRPO 还要看组内奖励方差。专业回答的关键，是把“奖励来源、是否在线采样、是否需要 critic”讲清楚。
如果奖励来自可执行验证，我还会检查奖励是否能被格式投机，例如只匹配最终字符串却忽略过程；若来自奖励模型，则检查分布外样本和过优化。三种算法共同的底线是用独立评测与人工审查验证真实质量，而不能把训练 reward 当最终答案。