Illuminum

从可验证奖励中学习推理

RLHF 把 base model 推向了更有用、更安全、更像助手的形态，但它有一个很难绕开的瓶颈：偏好奖励不是一个干净的目标。人类标注、奖励模型、LLM-as-a-judge 都只是代理信号；优化得越久，模型越可能学会利用代理目标的漏洞。典型表现是 reward 继续上升，但真实质量停滞甚至下降；回答变长、变圆滑、变得更像评分 rubric 里的“好回答”，却不一定更正确。

于是，后训练里出现了一条很自然的新路线：把 RL 放到奖励更可验证的任务上。数学题可以检查最终答案，代码题可以跑测试，形式化证明可以交给 proof checker，软件工程任务可以在环境中执行并验证结果。这类训练常被称为 RLVR（Reinforcement Learning from Verifiable Rewards）：奖励不再主要来自主观偏好，而来自某种 verifier。

一个简化对比是：

RLHF : 𝑅 (𝑥, 𝑦) \approx human preference

RLVR : 𝑅 (𝑥, 𝑦) \approx verifier (𝑥, 𝑦)

RLHF 的目标更宽，覆盖聊天、写作、安全和人类偏好；RLVR 的目标更窄，但反馈更硬、更便宜扩展，也更适合让模型通过试错提升推理能力。近年来 reasoning model 的许多进展，都可以理解为：先用 SFT 或蒸馏把模型带进 long CoT 的行为空间，再用可验证奖励对这部分搜索行为做在线优化。

为什么还需要 RL

如果已经有 SFT 和 DPO，为什么还要重新用 RL？关键在于，很多推理任务的天然反馈不是 pairwise preference，而是 outcome。数学题不是“回答 A 比回答 B 好一些”，而是“答案对不对”；代码题不是“这段代码更讨喜”，而是“测试过不过”。当然可以把多个候选配成偏好对，但这样会丢掉在线探索的重要性质。

SFT 学的是已有轨迹。给它一批漂亮的 long CoT，它可以模仿其中的格式、步骤和最终答案。但 SFT 本身不会因为某个新探索路径最终得到正确答案，就自动增加这类路径的概率。RL 则把语言模型当成 policy：模型自己生成候选轨迹，verifier 给出反馈，然后训练过程提高那些更容易得到正确结果的轨迹概率。

形式上，一个完整回答可以看成轨迹

𝑦 = (𝑎_{1}, 𝑎_{2}, \dots, 𝑎_{𝑇})

奖励通常集中在最后：

𝑅 (𝑥, 𝑦) = 1 if the answer is correct, otherwise 0

这很像一个长 horizon 的 bandit problem：中间 token 没有真实环境奖励，只有整段输出结束后才知道结果。困难在于轨迹很长、搜索空间巨大、奖励稀疏。RLVR 的核心挑战就是：如何把这种最终的可验证奖励，稳定地变成 token-level 的更新信号。

PPO：完整但沉重的路线

PPO 是最经典的 RL 路线。语言模型场景下，它大致做这几步：

从 prompt 集合中采样一批输入。
用当前 policy 生成若干回答，也就是 rollouts。
用 reward model 或 verifier 给每个回答打分。
加上 reference model 的 KL 惩罚，形成 token-level reward。
估计 advantage，并用 PPO clipped objective 更新 policy。
训练 value model，让它更好地预测每个状态之后的回报。

把它画成训练循环会更清楚：

PPO 的核心变量是新旧策略的概率比：

𝑟_{𝑡} (𝜃) = \frac{𝜋_{𝜃} (𝑎_{𝑡} | 𝑠_{𝑡})}{𝜋_{old} (𝑎_{𝑡} | 𝑠_{𝑡})}

裁剪目标写作：

𝐿_{clip} (𝜃) = 𝔼_{𝑡} [min (𝑟_{𝑡} (𝜃) 𝐴_{𝑡}, clip (𝑟_{𝑡} (𝜃), 1 - 𝜀, 1 + 𝜀) 𝐴_{𝑡})]

如果 $𝐴_{𝑡} > 0$ ，说明这个 token 所在轨迹比 baseline 好，我们希望提高它的概率；如果 $𝐴_{𝑡} < 0$ ，就降低它的概率。clip 防止 policy 一步偏离旧策略太远。

语言模型里的 reward shaping 通常很有特色。最终任务奖励只在最后一个 token 给出，但每个 token 都会加 KL penalty：

𝑟_{𝑡} = - 𝛽 log \frac{𝜋_{𝜃} (𝑎_{𝑡} | 𝑠_{𝑡})}{𝜋_{ref} (𝑎_{𝑡} | 𝑠_{𝑡})}

最后一步再加上 verifier 或 reward model 的分数：

𝑟_{𝑇} = 𝑅 (𝑥, 𝑦) - 𝛽 log \frac{𝜋_{𝜃} (𝑎_{𝑇} | 𝑠_{𝑇})}{𝜋_{ref} (𝑎_{𝑇} | 𝑠_{𝑇})}

这样做的直觉是：模型可以为了更高任务奖励改变输出分布，但每一步都要为偏离 reference model 付费。实践里还会有一些更工程化的稳定技巧，例如当新策略 log probability 小于 reference log probability 时，对 KL 项做 clipping，以免模型坏掉时 KL 贡献失控。

为了把最终奖励传播到每个 token，PPO 需要 advantage。常见写法是 GAE：

𝛿_{𝑡} = 𝑟_{𝑡} + 𝛾 𝑉_{𝜑} (𝑠_{𝑡 + 1}) - 𝑉_{𝜑} (𝑠_{𝑡})

𝐴_{𝑡} = \sum_{𝑙 = 0}^{𝑇 - 𝑡 - 1} {(𝛾 𝜆)}^{𝑙} 𝛿_{𝑡 + 𝑙}

不过在许多语言模型 reasoning 任务中，环境更像 bandit：状态转移主要是模型自己生成 token，真实任务奖励只在序列末端出现。这时 $𝛾 = 1$ 、 $𝜆 = 1$ 的 reward-to-go 直觉也很自然。问题在于，无论怎么估计 advantage，PPO 往往都需要 value model，这会增加显存、计算和调参成本。

PPO 的训练曲线也有一些应当期待的形态：总 reward 上升，任务 reward 上升，KL penalty 通常为负且受控。如果总 reward 上升完全来自 KL 变小或格式奖励，而准确率没有上升，就说明训练可能只是在优化容易的代理项。reasoning RL 中尤其要分开看 accuracy reward、format reward、KL reward、平均输出长度和 pass rate。把所有东西合成一个 scalar，很容易掩盖模型到底学到了什么。

PPO 的缺点并不是理论上不能用，而是实现太重。一个完整系统里可能同时有 policy、old policy、reference model、value model、reward model 或 verifier；rollout 是推理负载，update 是训练负载；长 CoT 让 batch 长度极不均匀。对于想快速做 reasoning RL 的团队来说，这些复杂度很难忽视。

为什么要从 PPO 走向 GRPO

PPO 的 value model 是一大负担。它要占显存，要训练稳定，要和 policy 的更新节奏配合；如果 value 估计不好，advantage 就会带偏 policy。另一方面，DPO 虽然简单，但它是偏好数据上的 offline objective，并不天然适合“对同一道题在线采样多条解法，然后根据正确性更新”的设置。

GRPO（Group Relative Policy Optimization）就是在这个背景下流行起来的。它保留了 PPO 中“采样 - 打分 - 用概率比更新”的基本形态，但去掉 value model。核心做法是：对同一个 prompt 采样一组回答，在组内用 reward 的均值和方差构造 advantage。

设对同一道题 $𝑥$ 采样 $𝐺$ 个回答：

𝑦_{1}, 𝑦_{2}, \dots, 𝑦_{𝐺}

对应奖励为：

𝑅_{1}, 𝑅_{2}, \dots, 𝑅_{𝐺}

组内归一化 advantage 写作：

𝐴_{𝑖} = \frac{𝑅_{𝑖} - mean (𝑅_{1}, \dots, 𝑅_{𝐺})}{std (𝑅_{1}, \dots, 𝑅_{𝐺}) + 𝜀}

这等于问：在同一道题的一组候选解里，第 $𝑖$ 个回答比平均水平好多少？如果它答对，而同组大多数答错，它就是正优势；如果它答错，而别人答对，它就是负优势。

GRPO 的更新目标通常仍然带有 PPO 风格的 clipped ratio 和 KL regularization：

𝐿_{GRPO} (𝜃) = 𝔼_{𝑖} [min (𝑟_{𝑖} (𝜃) 𝐴_{𝑖}, clip (𝑟_{𝑖} (𝜃), 1 - 𝜀, 1 + 𝜀) 𝐴_{𝑖}) - 𝛽 KL (𝜋_{𝜃} ‖ 𝜋_{ref})]

其中

𝑟_{𝑖} (𝜃) = \frac{𝜋_{𝜃} (𝑦_{𝑖} | 𝑥)}{𝜋_{old} (𝑦_{𝑖} | 𝑥)}

直观地说，GRPO 是一种组内相对强化学习：同一道题内部产生竞争，好的轨迹被推高，差的轨迹被压低。它非常适合可验证任务，因为 verifier 可以直接给每条轨迹一个 outcome reward。

GRPO 不是免费午餐

GRPO 的简洁来自一个强假设：组内相对 reward 足够替代 value model。这个想法很实用，但也会带来偏差。

标准 policy gradient 允许减去任意只依赖 state 的 baseline：

𝔼 [(𝑅 - 𝑏 (𝑥)) \nabla_{𝜃} log 𝜋_{𝜃} (𝑦 | 𝑥)]

只要 $𝑏 (𝑥)$ 不依赖采样动作，梯度期望不变。组内 reward mean 看起来像这样的 baseline，但它其实来自同一组采样结果，本身依赖这些 actions。更微妙的是，GRPO 还除以组内标准差：

𝜎_{𝑅} = std (𝑅_{1}, \dots, 𝑅_{𝐺})

这个标准差会改变不同 prompt 的权重。比如一道题很容易，大家都答对，reward 方差很小；一道题很难，大家都答错，方差也很小；只有一部分答对、一部分答错的题，方差信号才最丰富。标准差归一化可能放大某些边界样本，也可能让 too easy / too hard 的题产生奇怪权重。实践中会加一个小常数避免除零：

𝐴_{𝑖} = \frac{𝑅_{𝑖} - 𝜇_{𝑅}}{𝜎_{𝑅} + 10^{- 4}}

但这只是数值稳定，不是理论上完全无偏的修复。后续一些变体会尝试用 leave-one-out baseline 或更接近 REINFORCE 的形式，保留 GRPO 的简单性，同时减少组内归一化的偏差。

另一个问题是长度归一化。序列级 log probability 是 token log probability 的和：

log 𝜋_{𝜃} (𝑦 | 𝑥) = \sum_{𝑡 = 1}^{𝑇} log 𝜋_{𝜃} (𝑎_{𝑡} | 𝑠_{𝑡})

如果 loss 对长度的处理不当，长 CoT 可能因为有更多 token、更多梯度位置或更大的累计 log-prob 差异而被系统性偏好。后来一些修正会改变长度 normalizer，使训练目标更接近“每条回答作为一个整体”的相对好坏，而不是让 token 数隐式改变样本权重。

所以，GRPO 的实践重点不只是“把 reward 做 z-score”。还要监控：

每组 reward 方差。
不同难度题目的采样权重。
输出长度随训练的变化。
accuracy reward 和 format reward 的分离曲线。
KL 是否稳定，以及是否只是通过压缩/扩展长度来提高目标。

长 CoT：能力、搜索和偏置混在一起

Reasoning RL 中最显眼的现象是 long CoT。训练过程中，模型会逐渐生成更长的推理链，有时出现自我修正、回看题目、重新计算、表达不确定性等片段。它看起来像“模型学会了反思”，但这个现象需要更谨慎地拆开。

长 CoT 至少可能来自三类因素：

Base model 本来就有自我修正能力，RL 只是把这种行为抽取出来。
可验证奖励确实鼓励更充分的搜索，因为多写步骤更容易发现正确解法。
Objective、采样策略或长度归一化给了长输出额外优势。

因此，不应把输出变长直接等同于推理能力提升。更可靠的判断要看：在控制长度后准确率是否仍然提升；把中间过程截短后最终答案是否受影响；同样 token budget 下是否比 SFT 模型更强；verifier 之外的测试集是否也提升。

所谓“aha moment”也可以这样理解：它不一定是模型突然获得了某种新认知，而可能是训练把已有的自我检查语句、回溯策略和长搜索行为推到了更高概率区域。这个解释更朴素，也更符合语言模型的训练机制。

R1 Zero：纯 RLVR 的启发

一个典型的可验证推理路线是先做“纯 RLVR”实验：从较强的 base model 出发，不先用大量 long CoT SFT，而是直接在可验证任务上做 RL。奖励通常很简单：

Accuracy reward：最终答案是否正确。
Format reward：是否使用指定的思考标签、是否按要求给出 final answer。

这种设置的意义在于验证一件事：只靠 outcome reward 和格式约束，模型能否学出长推理行为？答案是可以到一定程度。训练中往往会看到平均 CoT 长度上升、pass rate 提升、自我检查语句增多。

但纯 RLVR 也有明显缺点。没有 SFT 初始化时，模型的推理过程可读性、语言一致性和格式稳定性可能较差；它可能混用语言，或者形成不太适合用户阅读的内部推理风格。更重要的是，纯 RLVR 得到的是强解题器倾向，而不是完整助手。

这个阶段的重要结论是：复杂的 process reward model 和 MCTS 并不是 reasoning RL 的必要条件。只要 base model 足够强、任务可验证、采样足够多，outcome reward 就能推动推理能力提升。但要把模型做成好用的产品形态，还需要后续阶段。

R1 式完整流程

更完整的 reasoning model 往往不是纯 RL 一步到位，而是多阶段流程：

Base modelreasoning SFTreasoning policyRLVRstrong reasonergeneral SFT / RLHFassistant reasoner

第一步 reasoning SFT 的作用是 bootstrapping。它让模型先学会 long CoT 的格式、可读步骤、最终答案结构，甚至可能包含验证或反思样式。即使样本数不大，长 CoT SFT 也可以显著改善后续 RL 的起点，因为 policy 已经在“会思考的区域”附近。

第二步 RLVR 继续使用 accuracy reward 和 format reward。有些流程还会加入 language consistency reward，避免 CoT 在训练中混杂多种语言。这个现象很有意思：如果只看最终正确性，模型可能自然选择任何它觉得有利的语言或符号形式；但产品层面希望输出可读、稳定，于是需要额外约束。

第三步是回到一般 post-training。reasoning RL 后的模型擅长数学、代码和长推理，但未必擅长普通聊天、写作、安全拒答和非可验证任务。因此还会加入：

reasoning data：包括数学、代码、证明、复杂问答。
non-reasoning data：普通指令、写作、多轮聊天、安全样本。
non-verifiable tasks：例如“写一个证明思路”“解释一个概念”，可能需要强模型或 judge 做评分。
RLHF / DPO / GRPO 风格偏好优化：把模型重新调成通用助手。

这个阶段也说明了一个重要事实：RLVR 强化的是窄域可验证能力，它不能自动解决所有对齐问题。

推理蒸馏：把强模型轨迹压到小模型里

强 reasoning model 还有一个副产品：大量高质量 CoT traces。可以让强模型为大量题目生成推理链和答案，然后用这些数据 SFT 较小模型：

𝐷_{distill} = {(𝑥, 𝑦_{CoT})}

这种 distillation 很有效，因为它把“搜索后的好轨迹”变成了监督数据。小模型不需要亲自经历 RL 的探索过程，也能学到：

长 CoT 的格式。
常见数学/代码推理模板。
自我检查和回溯语言。
最终答案的组织方式。

但蒸馏不是 RL 的完全替代。它学习的是强模型已经生成出来的样本，而不是通过 verifier reward 主动探索。小模型可能学会“看起来在推理”，但在新难题上缺乏在线试错带来的策略改进。因此，蒸馏更像是把强模型能力迁移到小模型的高效手段，而不是发现新能力的主要机制。

Kimi 式路线：数据筛选和长度控制

另一条典型路线把重点放在数据构造、难度筛选、课程学习和长度控制上。对于可验证任务，不是所有题都适合 RL：

太容易：模型几乎都能答对，reward 没有区分度。
太难：模型几乎都答错，组内也没有可学习差异。
边界题：模型 best-of- $𝑛$ 偶尔能做对，但单次采样不稳定，最适合 RL。

因此，一个常见数据筛选方法是 best-of-8 或 best-of- $𝑛$ ：对同一道题采样多个答案，只保留那些模型不是稳定会做、但也不是完全不会做的题。还要过滤多选题、判断题等容易出现 false positive 的样本，因为这些题可能通过猜测拿到 reward。

这类流程通常还会做 topic balancing，避免训练集被某几类数学题或代码题支配。对 code task，可以用 ground truth solution 生成额外测试；对 math task，可以训练或使用答案等价判断模型，避免因为表达形式不同而误判正确答案。

Kimi 式目标还体现出一种和 GRPO 不同的思路：从 KL-regularized RL 的非参数解出发，构造 reference-based reward 或 DPO-like surrogate，再用平方损失、baseline policy gradient 和 regularization 做优化。直观上，它不是简单照搬 GRPO，而是在 policy 和 implied reward 的关系上做了另一种近似。

长度控制是这类路线的重点。长 CoT 对正确率有帮助，但过长会增加推理成本。一个做法是在训练后期引入 length reward。组内较长的序列获得负的长度奖励，较短的序列获得正的长度奖励；同时要小心不要太早加长度惩罚，否则会压制模型探索。直觉可以概括为：

正确答案应该尽量短。
错误答案也不应该无限展开。
长度惩罚最好在模型已经学会基本推理之后再启用。

课程学习也很自然。可以给题目标难度，从易到难推进；也可以根据 success rate 动态采样：

𝑝 (𝑥) \propto 1 - success_rate (𝑥)

这样训练资源会更多流向模型还没稳定掌握的题，而不是反复刷已经解决的问题。

RL 系统效率：算法之外的硬问题

Reasoning RL 的系统效率非常关键。SFT 可以对固定数据打包训练，吞吐高、流程简单；RLVR 则必须不断 rollout，而 rollout 是自回归推理。长 CoT 会让样本长度差异非常大：有的几十 token，有的几千 token。batch 内 padding 浪费、调度不均衡、显存峰值都变得麻烦。

几个系统难点尤其突出：

On-policy 数据：policy 更新后，旧 rollouts 很快变 stale，不能像 SFT 数据那样无限复用。
推理/训练框架切换：rollout 常用高吞吐推理引擎，update 又需要训练框架，二者之间要同步权重和数据。
长序列负载不均：CoT 长度差异导致 GPU 利用率不稳定。
Verifier 成本：代码测试、答案等价模型、环境执行都可能成为瓶颈。
多组件常驻：policy、reference、verifier、judge、工具服务都要协同。

这也是 GRPO 受欢迎的工程原因：省掉 value model 不只是省一个公式，而是省显存、省训练目标、省调参，也减少了一个可能不稳定的组件。

Qwen 式路线：小数据 RLVR 与 thinking mode

另一个有代表性的方向是强调数据过滤质量，而不是盲目扩大 RL 样本数。只要题目足够干净，几千条高质量可验证样本也能产生明显收益。关键过滤包括：

用 best-of- $𝑛$ 找到模型能力边界附近的题。
去掉不需要 CoT 就能答对的题，避免 reward 太容易。
去掉和验证集过近的题，避免污染评估。
人工或模型辅助过滤 CoT 质量，避免“猜对但推理错”的样本。

Qwen 式流程还强调 thinking mode fusion。原因很实际：强 reasoner 不应该每个问题都长篇思考。用户问一个简单事实或短任务时，长 CoT 是成本和体验负担。因此模型需要学会在 thinking 和 non-thinking 两种模式之间切换。

一种做法是混合两类数据：

thinking data：带特殊标签，允许模型生成长思考过程。
non-thinking data：直接回答，或通过特殊终止字符串提前结束思考。

这样模型就能把 test-time compute 变成可控资源。复杂题花更多 token，简单题少花 token。推理 token 本身就是一种计算预算，thinking mode 的价值在于把准确率、延迟和成本之间的选择显式化。

还要注意，不同 post-training 阶段之间会互相影响。强化 reasoning 能力后，再做一般 RLHF 可能会让数学/STEM 指标略降，因为通用助手偏好和严格推理能力并不总是同向。完整 pipeline 需要在 reasoning、聊天、安全、写作和工具能力之间做 trade-off。

Test-time scaling：训练之外的能力来源

可验证推理还有一个重要现象：能力不只来自训练，也来自测试时采样和计算。best-of- $𝑛$ 、self-consistency、长 CoT、工具调用，都是把更多 test-time compute 换成更高正确率。

如果 verifier 可用，最直接的 test-time scaling 是：

对同一道题采样多个解法。
用 verifier 或答案等价检查筛选。
选择通过验证或多数一致的答案。

训练中的 RLVR 可以看成把这种测试时搜索的一部分压进 policy：让模型单次采样就更可能产生高质量轨迹。但即使训练后，test-time scaling 仍然有效，因为推理任务常常存在多条可能路径，更多采样能覆盖更大的解空间。

这也解释了为什么 thinking mode 很重要。模型不一定每次都需要最大预算；系统可以根据任务难度、用户偏好和成本约束，动态决定采样数、CoT 长度和是否调用工具。

Agentic RL：从答案验证到环境验证

可验证奖励不只适用于数学答案，也适用于 agent 环境。软件工程任务就是典型例子：模型拿到一个 repository、issue 或 bug report，执行搜索、编辑、运行测试，最终由测试结果或环境检查给奖励。

这时轨迹不再只是纯文本：

𝜏 = (𝑎_{1}, 𝑜_{1}, 𝑎_{2}, 𝑜_{2}, \dots, 𝑎_{𝑇}, 𝑜_{𝑇})

其中 $𝑎_{𝑡}$ 可以是工具调用、文件编辑、命令执行， $𝑜_{𝑡}$ 是环境返回的观察结果。奖励也变成：

单元测试是否通过。
任务描述是否完成。
代码是否可运行。
UI 是否符合要求。
工具调用是否有效且安全。

为了训练这种能力，需要构造大量环境。代码模型的 midtraining 数据可能包括：

GitHub repository 级长上下文数据，例如拼接多个文件，让模型理解项目结构。
Pull request 数据，并用 RAG 检索相关 repository state。
Common Crawl 中的 text+code 文档，并用 LLM 解析 HTML。
面向代码文档的 synthetic QA。
在环境中运行 coding agents 生成的 trajectories。
指令跟随和 fill-in-the-middle 数据。

然后还可以训练不同 expert model：web development expert、UX expert、single-turn QA expert、SWE expert。每个 expert 专注一个能力面，再通过蒸馏合并进一个更通用的 coder model。

Agentic RL 的环境构造尤其重。比如自动构造 SWE-bench 风格任务，需要准备仓库、issue、测试、依赖和可复现执行环境。规模上可以达到数十万级任务，但每个任务都比普通数学题昂贵得多。它更接近真实助手能力，也更吃系统工程。

和 RLHF 的关系

RLVR 不是替代所有 RLHF，而是补上 RLHF 不擅长扩展的那部分：可验证推理。一个更合理的整体流程是：

pretrainingSFTinstruction modelreasoning RL / RLVRstrong reasonergeneral post-trainingusable assistant

reasoning RL 负责提升数学、代码、形式化推理和工具任务；普通 post-training 负责把模型重新调成好用的助手，包括安全、写作、多轮对话、风格控制和非可验证任务。如果只追求可验证 reward，模型可能变成强解题器，但不一定是好助手；如果只做偏好优化，模型可能更会说话，但推理上限受限。

因此，真正的系统往往是多阶段、多数据源、多目标的折中：先用预训练拿到能力基底，再用 SFT 建立行为格式，再用 RLVR 强化可验证推理，最后用通用 post-training 调整用户体验。

总结

从可验证奖励中学习推理，本质上是把强化学习放回它更擅长的位置：目标明确、反馈可检查、允许探索、能够通过试错改进策略。相比 RLHF 中嘈杂的人类偏好代理，RLVR 的奖励更窄但更硬，因此特别适合数学、代码、形式化证明和 agent 环境。

PPO 是完整但沉重的路线；GRPO 通过组内奖励归一化去掉 value model，显著降低了 reasoning RL 的工程门槛。但 GRPO 也带来标准差归一化、长度偏置和 prompt 权重变化等问题。R1、Kimi、Qwen 这类配方展示了几个共同规律：数据要在能力边界附近，SFT 或蒸馏能帮助模型进入 long CoT 空间，RLVR 用 verifier reward 做在线改进，长度和测试时计算都需要控制，最后还要回到通用 post-training。

最值得记住的是，长 CoT 和推理能力不是凭空从奖励里“长出来”的。它们来自 base model 的已有能力、SFT 初始化、可验证反馈、采样探索、长度控制和系统工程共同作用。RLVR 的价值不在于制造神秘的顿悟，而在于给模型一个可以反复试错并被可靠评价的训练场。