GRPO 长程任务局限

← 中文导读 · ← 仓库首页（EN） · ← RL 笔记索引 · ← RLVR · GRPO · ← 演进总览 §3.4 R1 · 书中对应

作者：划水的青蛙 · 知乎原文
性质：社区讨论整理；非 DeepSeek 官方文档。商业转载请联系原作者。

一句话

GRPO 仍是好算法，但 R1 时代验证的是 短程、可终局判分 的任务；硬搬到 长程 Agent / 编程 时，会在 吞吐、奖励稀疏、组内可比性 上同时吃瘪——智谱、MiniMax、DeepSeek 的后续路线都在 绕开或补 GRPO 的短板。

背景：短程优化 vs 长程 Agent

R1 的 RLVR + GRPO 针对的是 同一 prompt、$G$ 条 rollout、终局 verifier 打分——在短 CoT 上成立。长程任务把 轨迹长度、上下文压缩、延迟归因 拉进同一个组内比较，前提就被动摇了。

核心结论

工程瓶颈：吞吐 vs 样本多样性

长程 RL 要先解决 怎么跑起来，再谈算法：

1. 先短后长：课程从短任务切到长任务时，梯度信号剧烈震荡。
2. 长短混训、同组打分：短 rollout 先结束，长 rollout 还在跑 → 组内 advantage 汇总前 大量 GPU 空转。
3. 全组长程失败：一组任务跑数小时、$G$ 条全败 → 零 reward，等于白烧资源（见下文「全败退化态」）。

GRPO 的三条前提

社区归纳 GRPO / RLVR 能 work 的三条前提，以及长程下的裂缝：

同题可比较：A/B/C/D 反例

同一长程 prompt 采样 $G=4$，终局成功 $=1$、失败 $=0$，组内均分 $\bar r = 0.5$：

问题在于：

• 同样的 $+0.5$，A 与 B 不是一回事：B 里大量 冗余 token 也被正向奖励 → per-token 信用分配不一致。
• B 后半段 可能在 摘要/压缩后的上下文 上生成，与 A 全程单一状态 的轨迹 不可比。
• GRPO 只奖终局：无法表达「前半段垃圾、后半段正确」这类 过程结构。

信号可验证 → 延迟归因

模型收到的是 「这次整体不行」，而不是 「第 $X$ 步动作错了」。错误可能要 几十步之后 才暴露，需要 反传归因——critic / 过程奖励 擅长，纯组内终局比较 不擅长。

组内降噪 → 两种退化态

短程任务里「独赢」相对少见；长程里 二者都更常出现。

业界应对

三家路径不同，共同点：承认 GRPO 直接硬上长程不够，要在 critic、过程奖励、蒸馏监督 上补洞。

与本地文档的对照：

延伸阅读