验证器工程作为一门学科

奖励设计才是 RLVR 的实质所在。功劳都算在策略模型头上，但判定什么才算正确的是验证器，而优化器会找出这个判定里的每一个漏洞。验证器设计错了，你不会得到一个弱模型，而是一个在验证器恰好看不见的地方自信地犯错的模型。

正因如此，我把验证器工程当作一门独立的学科：奖励设计、作弊与鲁棒性。它不是训练的注脚，而是决定训练值不值得的部分。

领域地图

两个家族，一根轴。

规则式验证器解析输出并与参考答案比对。确定性、廉价、闭环里没有模型。它们的失败模式是脆弱性：同一个答案换个写法就被判错。

模型式验证器用另一个模型给输出或推理步骤打分。灵活，适合开放式任务，但它们本身就是模型：可被攻破、会漂移、大规模运行成本高。

这根轴是信号所在的位置。结果奖励评判最终答案，过程奖励评判推理步骤。同一验证器家族在轴的两侧表现完全不同。相关 RL 机制见 GRPO 家族树。

精读：三篇论文

规则式验证器以一种特定的方式脆弱

From Accuracy to Robustness: A Study of Rule- and Model-based Verifiers in Mathematical Reasoning（Huang 等，2025）做了那个早该做的实验：在真实 RL 训练中验证器出错时，会发生什么？在常见数学数据集上，开源规则式验证器常常认不出以不同格式呈现的等价答案。论文给出了具体数字：在一个强长 CoT 模型的回答上做静态评测时，规则式验证器精确率保持在 99% 以上，召回率平均却只有 86%，意味着 14% 的正确回答被判为错误；在最难的数据集上，召回率掉到 0.78。这个假阴性率不是常数。策略模型越强，它咬得越狠：更强的策略会产生更多样但同样正确的输出，而这些输出会被验证器拒掉。

静态数字是个陷阱。模型式验证器在静态评测中的验证准确率更高，但在 RL 下会被攻破：它们把某些回答模式误判为正确，策略就会利用这一点，奖励虚高却没有真实收益。静态的验证器准确率无法迁移为优化下的鲁棒性。这是论文的核心教训，也是我不信任不附带训练曲线的验证器准确率数字的原因。

过程奖励需要的是信用分配，而不只是密度

PRPO: Aligning Process Reward with Outcome Reward in Policy Optimization（Ding 等，2026）从同一问题的另一面入手。即使在 GRPO 这类无 critic 的设置里，一个好的验证器每条轨迹也只产出一个标量，中间的推理过程无人监督。过程奖励模型解决了这一点，但单独使用有过早坍缩的风险：早期低奖励的 token 会把策略推向截断的输出。

PRPO 仍然无 critic。它按语义线索切分推理序列，把 PRM 分数归一化为 token 级优势，再通过位置参数平移与结果优势对齐。在 MATH500 上，它只用 8 次 rollout、没有价值网络，就把 Qwen2.5-Math-1.5B 从 GRPO 的 61.2% 提升到 64.4%。我在意的细节是：验证器设计与信用分配如今已密不可分。稠密过程信号的安全性，不会超过分配它的那个机制。

评分器作为产品，以及产品的收尾

OpenAI 的强化微调文档把评分器做成了整个产品。你定义一个可编程的评分器，平台采样回答、打分，然后做策略梯度更新。文档对失败模式出奇地坦诚：任务应当防猜测，因为一个靠蒙也能拿到奖励的模型会得到有噪信号；模型还可能学会攻破评分器，不答对也拿高分。

然后平台开始关停。同一份官方文档称，微调平台已不再对新用户开放，弃用时间表明确了具体期限：现有活跃客户只能在 January 6, 2027 之前创建新的训练任务，微调模型在其基座模型弃用之前仍可用于推理。作为托管服务的 RFT 正在关停。这迫使验证器工作转向内部：团队现在要端到端地自己拥有评分器。端到端地拥有它，也正是托管闭环永远给不了你的：VerifierForge 在训练之外跑了一个随机奖励证伪臂和一份哈希固定的留出考试，而没有任何托管服务会跑一个对照臂，来检查你的评分器到底是不是起作用的那个东西。

OpenRFT: Adapting Reasoning Foundation Model for Domain-specific Tasks with Reinforcement Fine-Tuning（Zhang 等，2024）展示了这个闭环的开源版本：在类似 RFT 的设置下为领域任务微调通用推理模型，使用问题增强、合成的推理过程数据和小样本上下文学习，仅凭每个任务 100 个领域专属样本就在 SciKnowEval 上取得显著提升。样本这么少，每一次奖励判定都举足轻重。这正是验证器工程最重要的场景。

我的立场

前两条规则来自精读，第三条是我必须自己发明、论文没有给我的。

只要程序能定义正确性，就优先用程序化验证器。可以执行的验证器，胜过可以争辩的验证器。

把奖励构造成分层结构，而不是一个标量。每一层的边界都应当是一次真实的检查，到达更高层必须严格得更高分。标量分数掩盖了策略到底获得了哪项能力。三篇论文没有一篇给你这个：它们评测验证器，不设计奖励。分层阶梯是我在构建 VerifierForge 时必须在实践中摸索出来的部分，正是它让失败变成可枚举的，而不是一个神秘的数字。

跑一个证伪臂。随机奖励对照组能告诉你，你的曲线上升是因为验证器，还是没有它也上升。如果对照组也上升，说明你的奖励信号在泄漏。

我下一步想构建的是这门学科本身：验证器 benchmark、标准的证伪臂，以及一份公开的验证器失败模式分类。验证器工程值得与训练同等的严谨。

VerifierForge

VerifierForge 是我把这些规则端到端落地的尝试（github.com/xesws/verifierforge）。一个程序化验证器逐层给 SQL 补全打分：提取只读语句、做解析守护、对着冻结的 schema 执行、比对结果集。达到的最高层级即为奖励：合法且可执行的 SQL 给部分得分，只有结果集完全匹配才给满分。

证伪臂是我最引以为傲的部分。随机奖励对照组的训练池监控指标最终停在 0.40——中途从 0.4 起伏到 0.5，最后一步又回到 0.4——而验证器奖励运行的监控指标停在 0.80。一个重要的澄清：这些是训练池监控指标，与留出考试是不同指标，我不会把任何一个监控指标当作质量主张。这个臂是证伪参考，而不是严格的因果证明，我也这样看待它。在冻结的 60 题留出考试上，pass@1 从基座模型的 58.3% 提升到所选 checkpoint（第 350 步，共 400 步）的 78.3%；最后一步回落到 71.7%，所以上线的模型是验证过的最佳 checkpoint，而不是最后一个。

我的论点：验证器质量而非模型规模，才是杠杆。闭环里的其他一切，从训练到在线服务，都是围绕它的后勤。

本文所引来源均已抓取并核验。