LLM-as-a-Verifier：验证的Scaling效应与DeepSeek实践

做 Agent 项目久了会有一个特别深的体会单轮对话里模型已经足够聪明可一旦进入“规划 → 调工具 → 看结果 → 再规划”的执行循环小错误就会像滚雪球一样被放大。模型给出的结果看起来完整、语气很自信但拿去做实际校验就露馅更麻烦的是当你让模型自己复查它往往会坚持原来的错误答案。这个问题的根源在于我们整个链路的设计重心几乎都放在了“生成”上而对“验证”环节投入得太少。最近斯坦福一篇关于 LLM-as-a-Verifier 的论文在技术社区里被反复转发核心观点非常直接验证Verification同样存在 Scaling 效应。换句话说与其只堆生成阶段的计算不如把一部分推理计算分配到验证阶段用验证量的增加持续换取结果可靠性的提升。这篇笔记就围绕这个方向展开把概念原理、DeepSeek 在验证上的实践以及一套基于 DeepSeek API 的可运行 Verifier 流水线完整串一遍。适合正在做大模型应用、Agent 开发、RAG 评测的同学也适合想理解“验证扩展”这个概念的新手读者。1. 背景与核心概念1.1 Agent 为什么会“越跑越错”先回到一个基础问题Agent 任务为什么天然比单轮问答更容易出错第一个原因是生成的不确定性。LLM 本质上是概率采样每一步动作都来自一个概率分布单步出错的概率可能不高但多步执行时失败概率会指数放大。假设每一步正确率是 95%执行 10 步后整体成功率只有 60% 左右如果每步正确率是 90%10 步后成功率只有 35%。Agent 的规划链路越长错误累积越严重。第二个原因是错误耦合。前一步的错误结论会成为后一步的上下文背景模型往往会顺着错误方向继续推理而不是主动纠偏。比如工具返回了一个异常值Agent 如果直接把这个异常值当成正常输入继续计算最终结果几乎必然错误。第三个原因是缺乏真实反馈。单轮问答里模型只需要生成一个看起来合理的回答Agent 场景里工具调用是否成功、返回结构是否完整、结果是否符合预期这些都需要被显式检查。但很多 Agent 框架只做了“生成动作”和“执行工具”却没有在动作前后设置验证环节。第四个原因是自信偏差。模型对自己输出的置信度与实际正确性之间相关性很弱它可能非常流畅地编造一个不存在的 API 参数也可能在数学题里一本正经地算出错误结果。这就是为什么“让模型自己检查”不能简单地等同于“让模型验证”——验证环节需要专门设计。所以 Agent 场景比单轮问答更需要验证。这也是“Agent 验证”成为今年工程化落地高频关键词的根本原因可靠性是 Agent 从 Demo 走向生产的最大瓶颈而验证是解决可靠性最直接的杠杆。1.2 LLM-as-a-Verifier 是什么LLM-as-a-Verifier 直译就是“让大语言模型当验证器”。它不是让模型去生成最终答案而是让模型去判断某个答案、某段推理、某次工具调用是否成立。这套思路的核心是 Generator-Verifier 架构Generator生成器负责产出候选答案、动作或方案。Verifier验证器负责对候选内容进行评分、纠错、二分类PASS/FAIL。两者可以来自同一个模型也可以是不同模型。在训练阶段Verifier 还可以退化成规则验证器比如数学题的答案精确匹配、代码的编译器测试用例这也是 DeepSeek 在强化学习中采用的重要策略。这里需要区分两个容易混淆的概念LLM-as-a-Judge 与 LLM-as-a-Verifier。Judge 更偏向主观质量评估比如回答是否有用、语气是否友好、内容是否对齐人类偏好Verifier 更偏向客观正确性验证比如数学答案是否正确、代码用例是否通过、每一步推理是否自洽。Agent 场景通常两者都会用到任务完成度判断可以看作一种验证最终结果质量评估可以看作一种 Judge。1.3 “Verification 也能 Scaling”怎么理解传统意义上的 Scaling 是指扩展模型参数规模、训练数据量或训练算力。而论文里讨论的 Verification Scaling 指的是推理阶段验证计算的扩展。举几个直观的例子生成 N 个候选答案用足够健壮的验证器逐一打分、排序N 越大最终被选中的答案越可靠。用“生成 → 验证 → 带反馈修正”的循环反复迭代多轮验证修正逐步逼近正确结果。对 Agent 的每一步动作做过程验证而不是只验证最终结果让错误在早期暴露。关键结论是验证阶段的 Scaling 与生成阶段的 Scaling 是正交的。即使生成模型固定不变依然可以通过增加验证侧的计算预算来提升最终输出的准确率。这对那些没有足够算力重新训练大模型、但又迫切需要提升 Agent 可靠性的团队来说是一个成本低得多的优化方向。当然验证扩展也不是没有上限。验证本身的准确率、验证成本、以及“生成器能力天花板”都会限制最终效果。理解这个边界比单纯相信“验证越多越好”更重要。2. 核心原理拆解验证的几种形态2.1 结果级验证Outcome Verification结果级验证只检查最终输出是否正确不关心推理过程。最典型的例子是数学题的最终答案精确匹配模型输出“120”标准答案是“120”则判对。代码任务中用单元测试和编译器作为结果验证器Agent 任务结束后用需求清单逐项勾选是否完成也属于结果级验证。结果级验证的优点是便宜、可并行、适合有标准答案的任务。但它的缺点也很明显无法暴露过程错误而且当验证器本身也是 LLM 时它可能被“看起来很有道理但过程错误”的答案误导。结果级验证更适合作为第一道粗筛而不是唯一验证手段。2.2 过程级验证Process Verification过程级验证对推理或执行过程中的每一个关键步骤分别检查。它不仅能判断最终结果对不对还能定位错误发生在哪一步从而给 Agent 提供修正方向。在学术界过程级验证对应的是 Process Reward ModelPRM即对推理链的每一步学习一个奖励模型。OpenAI 的“Let’s Verify Step by Step”是这一方向的代表性工作实验表明过程监督在数学推理上表现优于单纯的结果监督。在 Agent 工程中过程验证落地为两类检查一类是工具调用前的参数校验比如动作是否符合工具 schema、输入是否越界另一类是工具调用后的结果校验比如返回结构是否完整、关键字段是否为空、数值是否在合理范围内。过程级验证成本更高但收益也直接——它能告诉 Agent 具体哪里错了而不是笼统地让模型“再试一次”。2.3 自验证与外部验证自验证Self-Verification是指同一个模型既当生成器又当验证器。优点是部署简单、不依赖额外模型缺点则是“共谋误差”模型生成解答时的盲区在验证时大概率依然存在。如果一个数学问题模型本身就理解错了让它自己检查往往发现不了问题。外部验证External Verification则有三类常见形态规则验证器数学计算器、编译器、数据库约束、正则表达式。这类验证器完全确定没有幻觉。工具验证器把工具执行结果与预期值对比例如 SQL 查询返回行数是否为 0。交叉验证器使用不同 prompt、不同模型甚至是多个模型组成的验证器降低单一模型盲区带来的误判。生产环境最推荐的是“规则优先、LLM 兜底”的混合方案。能用计算器算清楚的问题不要问 LLM能用编译器验证的代码不要靠肉眼LLM 验证只用于规则无法覆盖的语义判断。2.4 验证阶段的计算分配为了理解验证扩展的工程含义可以做一个简单的成本模型。假设生成一个候选答案的推理成本是 g验证一个候选答案的成本是 v。如果直接单次生成返回总成本是 g如果采样 N 个候选并全部验证总成本是 N×(gv)。由于 v 通常小于 g而且验证器可以有效排除错误候选因此在总预算固定的情况下“多花验证算力”的收益往往优于“单纯扩大生成采样”。这正是 Verification Scaling 最直接的工程体现。策略推理成本可靠性适用场景单次生成直接返回g低低风险、对成本敏感采样 N 次 投票N×g中高有标准答案的任务采样 N 次 验证打分N×(gv)高Agent 最终决策、高价值结果生成→验证→修正循环多轮(gv)很高需要逐步纠错、迭代式任务3. DeepSeek 的验证路线从可验证奖励到自验证3.1 可验证奖励Verifiable RewardsDeepSeek 在 R1 系列模型中采用了一个关键思路在强化学习阶段使用可验证奖励Verifiable Rewards。数学推理任务用标准答案的精确匹配来判断对错代码任务用编译器或测试用例的执行结果来判断是否通过。这类奖励函数是外部规则不是模型自己打分所以模型很难通过“写得