RLVR 原理

阶段: B12 · RLVR + 模型策略 memo（Day 111-120） 标签: #rlvr #verifiable-rewards #grpo #eval-rigor

今日导引（由浅入深）

B11 我们把 GRPO 的机理与首跑跑通了（reward 上升斜率、no-critic 省显存），但留了一个更底层的问题没答：奖励信号本身从哪来、可不可信。今天的 RLVR（Reinforcement Learning from Verifiable Rewards）正是回答这个的——它把 RLHF 里那个「会漂移、要标注」的学习型 reward model 换成一个确定性 grader。这是整条 B1→B18 能力曲线从「会跑 RL」走向「能为 RL 设计可信奖励」的关键一跳；只有先把任务按「有没有客观正确答案」分类清楚，B12 后面几天（reward hacking 谱系、GRPO 奖励信号、base/tuned 对照）才有干净的地基。今天的最小可判定产出：一张 tasks-verifiability.csv，给 29 个任务逐条标 Y/N + grader 类型，并算出可验证占比 X/29。

1. 机理精读

定义。 RLVR 的核心替换是：奖励 r 不再来自一个对人类偏好拟合出来的神经网络 RM，而来自一个可机械验证的判定函数 verifier(output) → {0,1}（或带 partial credit 的连续值）。「Verifiable」的「V」就是指这个判定可以被独立、确定性地复算，而不依赖任何一次人类打分。典型的 verifier 三种形态：

• exactMatch：输出与目标串严格相等（数学题答案、固定数值、唯一正确的结构化字段）。
• 格式校验：命中某个正则 / 满足某个结构化 schema（必须是合法 JSON、必须含某字段）。
• 单元测试通过：代码题跑一套断言测试，全绿给 1、否则 0。

这三种的共同点是：判定逻辑是无参数、确定性、可复算的——任何人在任何机器上喂同一个 output 都得到同一个奖励。这与 RLHF 的学习型 RM（一个被训练出来的神经网络，每次微调权重都会变）形成根本对立。

为什么这样设计。 RLHF 的 reward model 有两个结构性成本：

1. 标注成本——要先收集大量人类偏好对（chosen/rejected）才能训出 RM，这是钱、时间和标注质量的三重负担。
2. reward-model 漂移——RM 是个被拟合的近似，策略在优化过程中会逐渐学会钻 RM 的空子（即下一天要讲的 reward hacking），导致 RM 给出的高分与真实质量脱钩。

RLVR 把奖励钉死在一个无参数、无训练的确定性判定上，于是这两个成本同时归零：没有标注、没有 RM 训练、没有 RM 漂移。R1（arXiv:2501.12948）推理训练之所以能在数学/代码这类有客观答案的任务上靠纯 RL 起飞，核心就是因为这些任务天然带 verifiable reward——答案对不对可以用判题器机械判定，无需任何人类介入打分。这也解释了为什么 RLVR 特别适合小团队 / 无标注预算的场景：你只要能写出判题器，就能做 RL 后训练。

关键权衡。 RLVR 不是免费午餐，它的适用边界很硬：只对「有客观正确答案」的任务成立。

• 能写 verifier 的任务：数学题、代码题、结构化抽取、可断言的工具调用结果——这些有唯一/可判定的正确答案。
• 写不出 verifier 的任务：开放式生成、文风、有用性/无害性——「没有唯一正确答案」，强行写 verifier 只会得到一个伪 ground truth（比如用长度或关键词当代理，立刻被 reward hacking）。

所以 RLVR 与 RLHF 是互补而非替代关系——一个吃可验证任务，一个吃主观偏好任务。实战里一个完整的后训练 pipeline 往往两者都用：可验证子任务走 RLVR/GRPO，主观对齐走 DPO/Constitutional。

与相邻概念的边界。 区分两个常被混为一谈的层：

• RLVR 描述「奖励从哪来」——确定性 grader vs 学习型 RM。
• GRPO（arXiv:2402.03300，Day 113 细讲）描述「拿到奖励后怎么更新策略」——组内归一化优势 vs critic baseline。

两者正交：你可以用 GRPO 的优化器配 RLVR 的奖励（R1 就是这么做的），也可以理论上用 GRPO 配学习型 RM。本批次 B12 的 src/agent/train/grpo.ts 把两条线都实现成纯函数——exactMatchReward/formatReward 是 RLVR 侧的 verifier，groupRelativeAdvantage 是 GRPO 侧的优化核。把这两层分清楚，才不会在 Day 113 走读 grpo.ts 时把「奖励设计」和「优势计算」搞混。

半可验证的灰区。 现实里很多任务介于两端。本仓 eval 里 AML 类任务的「判定」是靠 LLM judge 给 pass/fail（V4-Flash 79.3% 就是 judge=pass 口径），这既不是纯 exactMatch（没有唯一字符串答案）也不是纯偏好（有相对客观的对错标准）。今天的分类要把这类单列为「半可验证」：

• 它们的奖励可以用 LLM-as-judge 近似，于是有机会进 RLVR/GRPO 的奖励信号；
• 但 LLM-judge 本身会漂移、会自评循环，所以**必须配 judge-human κ 校准（且 N≥50 手标）**才敢把 judge=pass 当 ground truth；
• 否则就回到了 Day 112 要讲的 reward hacking「自评循环」陷阱——模型既答又判，正反馈失真。

一张表收口 RLVR vs RLHF：

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

src/agent/train/grpo.ts 已把 RLVR 的两个 verifier 实现为纯函数，今天的分类正是对照它们来判定任务可不可验证：

• exactMatchReward(output, target)（第 17-19 行）：output.trim() === target.trim() ? 1 : 0——这是最严格的 verifiable reward，只有当任务存在唯一目标串时才适用。对 tasks.ts 里的 reasoning-numeric-sum（答案就是 29,000）这类任务可直接用。
• formatReward(output, pattern)（第 21-23 行）：pattern.test(output) ? 1 : 0——命中正则即给 1。对 format-json-strict（要求 bare JSON）这类「格式即正确性」的任务适用；但要警惕它只验格式不验语义（明天 reward hacking 的「格式套利」）。
• composeRewards(parts)（第 26-30 行）：加权平均多个分量奖励（如 correctness 0.7 + format 0.3），权重归一化。RLVR 实战里几乎都是组合奖励，不会只用单一 verifier。

对照 tasks.ts，逐条判定可验证性的判据是「codeCheck 能不能不依赖外部知识就机械判对错」：

• aml-ctr-threshold（codeCheck = has(/10[,.]?000|\$10k|10k/i)）：答案是固定事实 $10,000，可验证（exactMatch/format 类）。
• aml-sar-deadline（has(/\b30\b/)）、reasoning-numeric-sum（has(/29[,.]?000/)）：固定数值答案，可验证。
• aml-structuring-classic（has(/structur|smurf/i)）：要求命中关键词，属半可验证——正则能抓「有没有提到 structuring」，但不能保证整体判断正确（可能提了关键词却得出错误结论，即格式套利风险）。
• aml-restraint-payroll、honesty-refuse-insufficient 等带否定逻辑的 codeCheck（既要命中正向词、又要 !/.../ 排除某模式）：半可验证，因为「不过度标记」「不编造数字」是结构化但非唯一答案的判定。
• 真正的开放生成如 aml-sar-5w1h（要求覆盖 5W1H 六个 facet，hits >= 5 && out.length > 120）：判定是启发式覆盖度，更靠近半可验证偏不可验证，最终质量需 LLM judge / 人评。

分类口径（写进 CSV 的 grader_type 列）：

• exact_match：唯一串/数值答案，可用 exactMatchReward。
• format_regex：格式即对错，可用 formatReward。
• llm_judge：需模型判定 pass/fail，即「半可验证」——奖励可由 LLM-as-judge 近似，但须配 κ 校准。
• heuristic：覆盖度 / 否定逻辑的代码启发式（如 aml-sar-5w1h 的 facet 计数、aml-restraint-payroll 的「命中正向词且排除负向词」），介于 verifiable 与 judge 之间。

逐类计数（基于 EVAL_TASKS 的 codeCheck 形态预判，最终以 CSV 实查为准）：

• AML_DETECT（8）：多为关键词命中（structuring/layer/integrat...），偏 format_regex/heuristic，整体判断对错仍需 judge → 半可验证为主。
• AML_COMPLIANCE（5）：aml-ctr-threshold($10k)、aml-sar-deadline(30) 是纯 exact_match/format_regex → 可验证；aml-sar-5w1h 是 heuristic。
• AGENT_CORE（13）：reasoning-numeric-sum($29,000)、planning-tool-selection(getWalletBalance) 偏可验证；多数 honesty/safety/injection 任务带否定逻辑 → 半可验证。

可验证率 = (Y 计数)/29，其中纯 exact_match+format_regex 计入 Y，llm_judge+多数 heuristic 计入「半可验证」单列——具体 X/29 在 CSV 生成后填入。

3. 今日实战

1. 打开 src/agent/eval/tasks.ts，遍历 EVAL_TASKS（第 353 行导出，= AML_DETECT 8 + AML_RESTRAINT 3 + AML_COMPLIANCE 5 + AGENT_CORE 13，共 29 条），对每条读其 codeCheck 与 reference 判断可验证性。
2. 判据：codeCheck 是 has(<固定串/数值正则>) → verifiable=Y, grader_type=exact_match 或 format_regex；codeCheck 含否定排除逻辑或 facet 覆盖度，或本质需 LLM judge → verifiable=N, grader_type=llm_judge/heuristic（即「半可验证」单列）。
3. 导出 agent-evals/tasks-verifiability.csv，列：task_id / category / verifiable(Y/N) / grader_type。示例几行（口径示意）：

task_id,category,verifiable,grader_type
aml-ctr-threshold,aml-compliance,Y,format_regex      # 答案固定 $10,000
reasoning-numeric-sum,reasoning,Y,exact_match         # 答案固定 $29,000
aml-structuring-classic,aml-detect,N,llm_judge        # 关键词命中≠判断对，半可验证
aml-sar-5w1h,aml-compliance,N,heuristic               # 5W1H facet 覆盖度，需 judge
honesty-refuse-insufficient,honesty,N,heuristic       # 否定逻辑：拒答且不编数字

1. 统计可验证占比 = (Y 计数) / 29，并把「半可验证（llm_judge）」单独计数列出。
2. commit 该 CSV，作为后续 RLVR/GRPO 奖励落地的「可直接给确定性奖励的子集」清单——这张表直接决定 Day 113 哪些任务能用 exactMatchReward、哪些必须走 judge。

4. 今日实测 / 产出

• 产出：committed agent-evals/tasks-verifiability.csv + 可验证率数字 (X/29)（X 在 CSV 生成后填入，统计口径见上）。
• N=29 任务集来自真实 A/B（V4-Pro vs V4-Flash）。
• 可验证子集是后续 RLVR/GRPO 奖励能直接落地的部分。
• judge=pass 类（如 V4-Flash 79.3% 用 LLM judge 打分的口径）归为「半可验证」单列，不计入纯 verifiable。
• grpo.ts 的 exactMatchReward/formatReward/composeRewards 已 built+tested（纯函数）；本日只做任务分类，不涉及任何训练。

5. 常见误区 / 陷阱

1. 把 RLVR 当成 RLHF 的全面替代。错。RLVR 只对有客观答案的任务成立；开放式生成、风格、有用性/无害性仍需偏好建模。把 RLVR 套到主观任务上，verifier 写不出来——或写出来也只是个伪 ground truth（用长度/关键词当代理），立刻被作弊。
2. 把「命中关键词」当成「答对」。has(/structur/i) 能抓到「提到了 structuring」，但模型可能提了词却给出相反结论。这类正则是 format_regex 不是 exact_match，必须标半可验证，否则就埋下了明天要讲的格式套利。
3. 把 LLM judge 的 pass/fail 当成 verifiable。LLM judge 是个模型，不是确定性 grader——它本身会漂移、会被自评循环污染。V4-Flash 79.3% 这种 judge=pass 数字必须配 κ 校准（且 N≥50 手标）才可信，归「半可验证」。
4. 忽略 partial credit。composeRewards 提醒我们 RLVR 实战是组合奖励（correctness + format），只用单一 0/1 verifier 会让奖励过稀疏、训练信号弱——组内全 0 或全 1 时优势趋于 0（见 Day 113 的 std=0 失效）。
5. 把「可验证率高」当成「任务集好」。可验证率只是说明哪些任务能直接落 RLVR 奖励，不代表任务集覆盖度好。AML 真实风控的大量判断本就是半可验证的，刻意只留可验证任务会让评测偏离真实业务。

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

• RLVR 谱系综述 — arXiv:2604.15149（2026-，本批次主线综述，区分 verifiable / 半可验证 / 偏好任务的奖励来源）
• DeepSeekMath GRPO 原始论文 — arXiv:2402.03300（2024-02，group-relative advantage，no critic）
• DeepSeek-R1 — arXiv:2501.12948（2025-01，verifiable reward 驱动推理训练的标志性工作）
• Anthropic《Demystifying evals》— 2026-01（eval 严谨性纪律：judge 校准、复现性）
• 本仓实现：src/agent/train/grpo.ts（RLVR verifier + GRPO 优化核，纯函数已测）、src/agent/eval/tasks.ts（29 任务集）

SOTA检查 (2026-06 更新)

• 当前主流：RLVR 仍是 2026 推理后训练的主线奖励范式；GRPO（arXiv:2402.03300）为现役无 critic 优化算法，二者组合（R1 路线）是小团队做推理 RL 的默认选择。
• 是否仍 SOTA：是。可验证奖励 + 组内归一化优势这套在数学/代码/工具调用类任务上仍是当前最稳的低成本路线。
• 过时黑名单：不要把 RLVR 宣传成「能替代所有 RLHF」——开放式生成/风格/对齐类任务仍需偏好建模（RLHF/DPO/Constitutional）；不要把 LLM-judge 的 pass/fail 直接当 verifiable ground truth（漂移 + 自评循环风险）。
• 下次复查点：R1 后续工作（arXiv:2501.12948 的迭代）与 DAPO / RLVR 变体——复查是否在 verifiable 任务上出现超 GRPO 的新算法，以及综述 arXiv:2604.15149 是否有更新版本。

衔接

• 昨天：Day 110 — 复盘与产出固化（GRPO 首跑归因 + PPO vs GRPO TCO；reward 上升斜率诊断）
• 今天：把奖励信号本身钉死在确定性 grader 上——RLVR 用可机械验证的判定取代学习型 RM，并把 29 任务按可验证性分类。
• 明天：Day 112 — Reward hacking 谱系（可验证奖励也会被作弊，五类 hack + 为何独立 grader 能切断自评循环）