复盘与产出固化

阶段: B11 · GRPO/后训练机理 + 首跑（Day 101-110） 标签: #GRPO #PPO #TCO #attribution

今日导引（由浅入深）

B11 收口日，是 B1→B18 能力曲线上「跑通一次后训练 → 把它讲成作品」的闭环点。Day 101-109 走完了「机理 → 数据 → 训练循环 → 监控 → 评测」整条 GRPO 首跑链路；今天 Day 110 做两件收尾事：

1. 对首跑成败做归因——从 reward 上升斜率反推问题出在 reward/数据还是 grader/G。
2. 把 GRPO 与 PPO 路线做TCO 对比，讲清「小团队为什么选 GRPO」。

这是把一次 RL 实验沉淀成可面试讲述的工件的最后一步。明天起进入 B12（Day 111-120：RLVR 原理 + 模型策略 memo），把今天的可验证奖励经验上升为系统方法论。今天最小可判定产出：reward-vs-step 上升图 + 已保存 adapter + 一段 PPO-vs-GRPO 的 TCO 对比文。

1. 机理精读

从 reward 斜率做归因。 首跑成败看 reward 曲线形状，对应不同根因与处置：

斜率是诊断的入口，配合 Day 108 的 KL 曲线能定位到具体成因——reward 与 KL 联读，几乎能把每种病态对到唯一根因。

GRPO vs PPO 的 TCO 差在哪。 PPO 需要一个独立的 critic / value 网络来估计基线（advantage = reward − value），还常需先训一个 reward model。GRPO 用组内均值当基线（Day 107 走读的 groupRelativeAdvantage），直接省掉 critic 网络；配合 RLVR 用确定性 grader 当奖励，又省掉 reward model 训练。结果是：单位 step 的显存占用（少一个网络的前向/反向 + 优化器状态）与训练成本都更低。这正是小团队、单卡场景选 GRPO 的关键理由——不是 GRPO 永远更优，而是它把「养两个额外网络」的成本砍掉了。

PPO vs GRPO 的 TCO 四维对比表。

TCO 不止显存。 完整 TCO 还含：标注成本（RLVR 无须人标偏好 → 趋零）、工程复杂度（少维护 critic/RM 两条管线）、调参面（GRPO 主要调 lr/beta/G，PPO 还要调 critic 那套）。对资源受限团队，这些隐性成本的节省往往比单卡显存更决定性。

但 GRPO 不是免费午餐。 它把成本从「养 critic/RM」转移到「每步采 G 个 rollout」——G 次生成本身有算力账，且只在「任务有可验证答案」时奖励信号才干净。开放式生成、风格/安全等需要细腻偏好的任务，RLVR 的硬奖励信号不够，仍需偏好建模（DPO/RLHF）。所以 build-vs-buy 式的论证应是「GRPO 适合可验证任务的低成本后训练，不适合替代所有 RLHF」。

为什么复盘要落成可链接工件而非心得。 AICAP 的 KPI 是「可链接资产 + eval 数字 + 单位成本」而非笔记数量。一次 GRPO 首跑若只留下「感觉学到了」，对求职/能力证明毫无价值；落成 reward-vs-step 图 + 保存的 adapter + 带 CI 的 Δ + TCO 对比段，才是 hiring manager 能点开、能追问「数据流/评测/成本/为什么」的工件。这也是 Day 110 把「跑」沉淀成「可讲」的根本目的。

与相邻概念的边界。 与 Day 109 边界：109 出「涨了多少、可不可信（Δ + κ）」，110 出「为什么涨/不涨 + 值不值（归因 + TCO）」。与 B12（明天起）边界：B11 是「跑通一次 GRPO」的实操，B12 把可验证奖励抽象成 RLVR 原理 + reward-hacking 谱系 + 模型策略 memo，是从「我跑过」到「我能系统讲」的跃迁。资源：GRPO 论文（arXiv:2402.03300）+ R1（arXiv:2501.12948）。

2. 推导 / 手算 / 代码走读

本日不是新代码日，而是把 B11 跑过的工件归因固化。回看本仓两个支撑工件（前几日已走读，此处串成 TCO 论证）：

• src/agent/train/grpo.ts 的 groupRelativeAdvantage：用 (r−mean)/(std+eps) 的组内标准化当 advantage，完全不引用任何 value/critic 网络——这就是「GRPO 省掉 critic」在代码层的实证。PPO 这里会是 reward − V(state)，需要一个学习型 V。
• src/agent/train/grpo.ts 的 exactMatchReward/formatReward/composeRewards：确定性 verifier 直接产奖励，不引用任何 reward model——这是「RLVR 省掉 RM 训练」在代码层的实证。把这两点写进 TCO 段，就是「为什么 GRPO 单位 step 成本更低」的可信支撑。
• A/B 严谨性工件 src/agent/eval/stats.ts：requiredNForDelta(delta, sdDiff) 用正态近似 n=((z_{α/2}+z_β)·sd/|delta|)²（α=.05 双侧、power=.8）算「要检出某 Δ 需多少配对样本」。这把「首跑 Δ 也要看 CI/N」从口号变成可算的数——见下方 real 锚点的教训。

real 锚点的统计教训（逐字保留、非新增测量）：同 harness 的 V4-Pro vs V4-Flash Δ+10.3pp，95% CI[0,20.7]，在 N=29 时不显著——CI 下界压到 0，意味着「真实差异可能为零」。requiredNForDelta 估算需 ~70 任务才有足够 power 检出这个量级的差。这条直接迁移到 GRPO 首跑：终点 reward 相对 step-0 即便看着涨，也必须报 CI/N，否则可能是噪声。

requiredNForDelta(delta, sdDiff) 的公式与直觉（非新增测量）：n = ((z_{α/2}+z_β)·sd/|delta|)²，其中 z_{α/2}=1.96（双侧 α=.05）、z_β=0.84（power=.8）。直觉：要检出的差越小（delta↓）或配对差波动越大（sdDiff↑），所需样本量越大（平方关系，增长很快）。这把「Δ 看着不小但不显著」翻译成可操作的结论——「再标更多任务到 ~70 才有把握」，而不是含糊地说「样本有点少」。

groupRelativeAdvantage 省 critic 的代码级证据（非新增测量）：它只用 mean/std/(r−mean)/(std+eps)，整段没有任何 V(state)、没有第二个网络的前向。把这段贴进 TCO 段，就是「GRPO 单位 step 比 PPO 少一个网络」最直接的代码佐证——面试时可以指着这 8 行说「这就是为什么我们不用 critic」。

3. 今日实战

1. 生成 reward-vs-step 上升图（接 Day 108 的 csv），标注：
   • step-0 基线（来自 Day 107）。
   • 终点 reward 与相对 step-0 的提升百分比。
   • KL 曲线叠加（用于归因）。
2. 保存 LoRA adapter 至 agent-evals/；同时确认/定下 agent-evals/baseline.json 基线（固化前必须先定，否则无法量化相对提升）。
3. 提交全部 Day 101-110 产出（笔记 + grpo_train.jsonl + reward-vs-step.csv + 曲线图 + adapter）。
4. 写 PPO vs GRPO 的 TCO 对比段：列 critic 网络、reward model、标注成本、调参面四维，结论指向「小团队/单卡选 GRPO，开放式任务仍需偏好建模」。
5. 里程碑判定（待 GPU）：终点 reward 相对 step-0 是否 ≥+20%、tasks.ts 子集 Δ 是否 ≥+5pp，且 Δ 的 CI 是否排除 0。
6. 交叉引用 docs/aipa/day110-grpo-firstrun.md 固化归因结论与里程碑达成情况。

4. 今日实测 / 产出

• docs/aipa/day110-grpo-firstrun.md + reward曲线图.png + 已保存 adapter。
• 待 GPU：曲线图与 adapter 需训练完成（里程碑目标：终点 reward 相对 step-0 ≥+20%，tasks.ts 子集 Δ≥+5pp）。
• 离线产出（不依赖 GPU）：
  • 归因分析文：reward 斜率 → 根因表 → 下次改法。
  • PPO vs GRPO 的 TCO 对比段：critic / reward model / 标注成本 / 调参面四维。
  • 统计纪律段：requiredNForDelta 估算 + CI 报告要求。
• real 锚点：A/B 严谨性教训——V4-Pro vs Flash Δ+10.3pp，CI[0,20.7]，在 N=29 不显著（需 ~70 任务才有 power），提醒首跑 Δ 也须看 CI/N。
• 状态诚实标注：归因/TCO 文已可离线写；曲线图与 adapter 待 GPU；里程碑达成判定 gated on 训练完成；agent-evals/baseline.json 尚未定基线（gated on 选定基线 run）——均未升级为已完成。

5. 常见误区 / 陷阱

1. 无显著性检验就宣称提升：终点 reward 看着涨 ≠ 显著，必须报 CI/N——real 锚点 Δ+10.3pp 在 N=29 都不显著就是前车之鉴。
2. 把 GRPO 当"永远更优"：GRPO 的优势是省 critic/RM 的 TCO，不是任务上限更高；开放式生成仍可能要偏好建模。
3. adapter 不固化基线：agent-evals/baseline.json 尚未定基线，没基线就没法量化「相对提升」，固化前必须先定。
4. 斜率不配 KL 读：早平台到底是 grader 太松还是 beta 太大，单看 reward 分不清，要叠 Day 108 的 KL 曲线。
5. 把 reward 提升等同任务能力提升：reward 是 grader 代理信号，最终要看 Day 109 的同 harness Δ + κ；reward↑ 而下游 Δ 不显著，可能是 reward hacking。
6. 里程碑只看 Δ 不看 CI：里程碑写「Δ≥+5pp」时若不要求 CI 排除 0，仍可能把噪声当达标——real 锚点已证 N 不够时 Δ 不可信。

一段可直接用于面试的 TCO 论证骨架（思路，非新增测量）：

「我们这次选 GRPO 而非 PPO，理由是 TCO：PPO 要额外养一个 critic 网络估基线、通常还要先训一个 reward model；GRPO 用组内均值当基线（代码里就是 (r−mean)/std，没有第二个网络），奖励用 RLVR 的确定性 grader（无须人标偏好）。代价是每步要采 G 个 rollout，但对单卡/小团队，省下的 critic 显存 + RM 训练 + 偏好标注远大于这点采样开销。前提是任务有可验证答案——我们的 AML 类型学识别正好满足；若换成开放式生成，我会回到偏好建模。」

这段把代码事实（groupRelativeAdvantage 无 critic）、成本维度（显存/标注/调参）、适用边界（可验证 vs 开放式）串成一个能扛追问的 build-vs-buy 论证。

6. 学习资源（每条带 YYYY-MM）

• GRPO 论文 / DeepSeekMath（arXiv:2402.03300, 2024-02）——组内基线替代 critic、TCO 优势的来源。
• DeepSeek-R1（arXiv:2501.12948, 2025-01）——可验证奖励 + GRPO 的大规模实证与成败归因。
• Unsloth GRPO guide（2026-01）——adapter 保存/合并与单卡成本实操。
• RLVR 谱系综述（arXiv:2604.15149, 2026）——RLVR 适用边界与 reward hacking（B12 主题）的系统化背景。

SOTA检查 (2026-06 更新)

• 当前主线：GRPO 仍是 2026 低成本 RL 后训练首选（省 critic + 省 RM 的 TCO 优势成立）；RLVR 提供干净奖励信号是配套主线。
• 是否仍 SOTA：是。对资源受限团队，GRPO + RLVR 是现役主线；PPO 仍用于需要更强基线/更复杂奖励的场景；变体（Dr.GRPO 去 std 偏置、DAPO 改裁剪）在边际上降本/稳化。
• 过时黑名单：
  • 避免无显著性检验就宣称提升（real 锚点已证 N=29 不够）。
  • agent-evals/baseline.json 尚未定基线（gated on 选定基线 run），固化前需先定。
  • 避免把 GRPO 当能替代所有 RLHF 的银弹（开放式/风格任务仍需偏好建模）。
• 下次复查点：再验 Dr.GRPO / DAPO 等 GRPO 变体是否进一步降本；复查 R1 后续工作（arXiv:2501.12948 续作）的 TCO 数据；进入 B12（Day 111-）时把 RLVR 原理与 reward-hacking 谱系系统化。

衔接

• 昨天：Day 109 — adapter 评测与对齐（同 harness 前后 Δ + Cohen's κ）。
• 今天：从 reward 斜率做首跑归因 + PPO-vs-GRPO 的 TCO 对比，固化 Day 101-110 产出；里程碑 ≥+20% reward / Δ≥+5pp 待 GPU 验。
• 明天：Day 111 — RLVR 原理（B12 开篇：把可验证奖励抽象成系统方法论 + 模型策略 memo）。