让答案接受规则核对

前面比较甲乙时，人要检查材料边界。现在换一个有明确核对规则的任务：计算十七乘十九。我先把参考计算做完，十七乘二十是三百四十，再减十七，得到三百二十三。假如生成模型给出最后答案三百二十三，我们就能用规则核对；如果给出三百三十三，检查会失败。这个小例子不是要证明某个模型会算错，而是说明评价来源可以改变。代码任务里，对应的对象可以是程序及一组测试。

完整过程是先生成，再把需要检查的答案提取出来，然后按规则或测试给反馈。这里每一步都可能影响信号。数学答案的格式如果不能正确提取，正确解也可能被误判；代码通过有限测试，也不等于所有输入都正确。验证器的好处是可以自动、重复地检查明确条件，但它的覆盖范围仍然需要设计。我们不能因为评价由程序执行，就把程序的检查范围当成整个研究目标。假如测试只检查正常输入，程序在空输入或边界值上出错也可能拿到高分。这个例子说明，自动化让检查更便宜，却不能替研究者决定哪些失败值得被检查。

反馈再回到生成策略，用来提高较好轨迹再次出现的可能性。它与上一页的关键连接一样：不是规则直接把答案写进参数，而是训练利用生成概率与梯度更新模型。GRPO是一种组织这类训练的方法，常见做法是同一问题生成一组答案，根据组内奖励形成相对评价。要是所有答案得分完全一样，这组就很难提供区分谁更好的信号；有可验证奖励不意味着每批训练都自动有信息。今天把算法名字放在这个位置就够了，完整组内标准化和约束形式在正文继续读。

DeepSeek-R1论文提供了一个重要的公开例子。R1-Zero从已经预训练的DeepSeek-V3-Base出发，没有先做SFT，就用强化学习探索推理任务表现。名字里的Zero容易误导人：它绝不是从随机参数开始，原有语言和推理基础已经由预训练提供。正式R1又采用了多阶段SFT与RL，不能把一个研究变体当成全部生产配方。到这里，后训练的共同点很清楚：根据能获得的示范、偏好或验证反馈，继续塑造生成行为和任务表现。下一步回到我们自己的研究条件：如果数据不多、设备有限，继续训练是否一定要更新所有参数？