模型自己写的答案，自己却看不出对错——这事比“AI取代人类”更让人后背发凉！
大模型已经能解高考数学题、能写完整代码、能规划机器人路径，但它搞不定一件事：自己判断自己做得对不对。
这事有多离谱？你让一个模型跑五次任务，五次里可能有一次答对了，但它不知道是哪一次。所有答案在它眼里长得差不多。这就好比一个学生参加了五次考试，其中一次拿了满分，但他完全想不起来是哪张卷子——这学生到底是学霸还是学渣？
斯坦福、伯克利和英伟达的研究者发现，大模型的“自我认知”存在一个结构性漏洞。而补上这个漏洞的方法，可能比训练模型本身更值得关注。
验证——不是训练，不是推理，而是验证——正在成为大模型能力提升的第四条 scaling 曲线。
98.9% 的潜力被卡在哪儿了
先看一个数字：98.9%。
研究者在 Terminal-Bench 这个 AI 编程基准测试上反复做同一个任务，然后假设存在一个“神谕”——一个永远能从一堆候选答案里挑出最优解的神仙。
随着采样次数增加，这个神仙能把成功率一路推到 98.9%。
换句话说，模型本身其实已经“会做”这些题了。你让它跑一百次，总有一次能蒙对。问题是，现实中没有神仙，只有一个裁判。
裁判的水平，直接决定了那 98.9% 的潜力能兑现多少。
当前主流的裁判是谁？就是模型自己——业内管这叫 LLM-as-a-Judge。
做法很简单：让模型看完几个候选答案，然后打一个分，比如 1 到 8 分，选分数最高的那个。
听着挺合理对吧。
但问题出在一个你可能想不到的地方——打分粒度太粗了。
7 分和 7 分，真的“一样”吗
你让一个大模型去比较两段代码、两条 SQL 优化方案、两次机器人操作，谁做得更好。
它看完两边，分别打出 7 分和 7 分。
打平了。
你追问哪个更好，它给不出更细的答案——因为它的判断，从一开始就被压扁成了一个整数。
研究者统计了 Terminal-Bench 上的数据：让 LLM 当裁判去比较两条智能体执行轨迹，打平的比例高达 27%。
超过四分之一的情况是“分不出胜负”。
但真相是，模型心里其实是有差别的。
打个比方：方案 A，模型认为打 5 分的概率是 51%。方案 B，模型认为打 5 分的概率是 90%。
两边都会被记录成“5 分”，判为平局——尽管模型对 B 的把握明显更足。
这就怪了：模型明明“知道”自己更确信哪个答案，但打分机制把这种确信感给吞掉了。
把“概率”而不是“分数”拿出来用
LLM-as-a-Verifier 的核心思路，一句话就能说清楚。
不要只取那个概率最高的分数，而是把打分 token 的整个概率分布拿来加权求期望，得到一个连续分数。
还是上面那个例子：1 到 5 分每个数字都有一个概率，用期望公式算下来，方案 A 可能得到 4.2 分，方案 B 得到 4.7 分。
瞬间就能分出高下，不再是一句“差不多”。
这个转变听起来简单，却打开了三个此前无法规模化（scale）的维度。
第一个维度：打分粒度。与其用 1 到 5 分这种粗刻度，不如换成 1 到 20 分甚至更细，给模型更精细的空间去表达“确信程度”。
第二个维度：重复评估。多评估几次再取平均，把单次判断里的随机噪声磨掉。
第三个维度：标准分解。与其问一句笼统的“这个方案对不对”，不如拆解成“是否满足任务需求”“输出格式对不对”“有没有报错”这几个更简单的子问题，分别打分再综合。
论文在 Terminal-Bench V2 上对三个维度分别做了消融实验。
打分粒度从 1 级提到 20 级，验证准确率从 73.1% 升到 77.5%。
重复评估次数从 1 次提到 16 次，准确率从 74.7% 升到 77.5%。
把单一标准换成三个子标准的集成，准确率从 75.2%—76.4% 提升到 78.3%。
三条曲线各自独立生效、还能叠加。
这就是“scaling”这个词的分量所在——不是拍脑袋调优，而是每一个维度都能稳定地换来更好的判断力。
验证，正在成为第四条 scaling 曲线
预训练是一条 scaling 曲线——模型越大、数据越多，能力越强。
后训练是第二条——微调、对齐，让模型更听话。
测试时计算（test-time compute）是第三条——推理的时候多想想，答案更好。
验证是第四条。
这个判断来自论文的核心论点：scaling pre-training, post-training, and test-time compute 之外，verification 是一个新的 scaling 轴。
什么意思？
你不需要重新训练模型，不需要换更大的参数，不需要花更多的推理时间。你只需要在“验证”这一步投入更多计算——更细的粒度、更多的重复、更系统的标准分解——就能稳定提升最终效果。
这不是玄学。这是有实验支撑的。
LLM-as-a-Verifier 在 Terminal-Bench V2 上跑出了 86.5% 的成功率。在 SWE-Bench Verified 上是 78.2%。在 RoboRewardBench 上是 87.4%。在 MedAgentBench 上是 73.3%。
全部是当时最优（SOTA）。
而且，它不需要额外训练。拿来就能用，插到任何一个 agent 框架里就能生效。
从“裁判”到“验证者”，不只是换了个名字
为什么叫 Verifier 而不是 Judge？
从定义上讲，judge（裁判者）是对整体情况形成总体判断并给出结论的人。而 verifier（验证者）是对具体事项进行真实性及正确性核验的人，需要更细致、更具体的评估。
这不仅是措辞的区别。
Judge 给的是一个“感觉”——这活儿干得怎么样，大概齐 7 分吧。
Verifier 给的是“证据”——这活儿在标准 A 上得了几分，在标准 B 上得了几分，重复验证了五次平均是多少。
前者是印象分，后者是核算单。
在选择最佳轨迹时，LLM-as-a-Verifier 采用循环赛（round-robin tournament）机制。对每一对候选轨迹都计算一遍 reward，赢的晋级，最后胜场最多的被选中。
这不是“看一眼打个分”的事。这是一套完整的筛选流程。
DeepSeek 的反超：不换模型，只靠“自验证”
2026 年 8 月，一个实验让很多人重新审视了验证的价值。
DeepSeek V4 Flash 在 Terminal-Bench 2.1 上对每个任务采样 5 条候选轨迹，自验证后的系统成功率达到 88%，超过了 Claude Fable 5。
注意一个关键细节：生成和验证用的都是 DeepSeek V4 Flash 自己。没有额外接入更强的 GPT 或 Claude。
同一个模型，既当考生又当阅卷老师。
结果呢？把成功率拉到与 Fable 5 相近的水平，DeepSeek 自验证的单任务成本约 0.11 美元，Fable 5 则约 1.3 美元。
成本不到后者的十分之一。
这不是“换了个更强的模型”，这是“把同一个模型用得更好”。
实验的具体数据是这样的：每个任务预先由 DeepSeek V4 Flash 生成 5 条 mini-swe-agent 执行轨迹。Best-of-3 使用前 3 条，Best-of-5 使用全部 5 条。DeepSeek V4 Flash 同时负责给候选轨迹打分，LLM-as-a-Verifier 完成排序和选择。
Best-of-3 将成功率从 79.4% 提到 86.5%。Best-of-5 则把 78.7% 直接推到 88.0%。
还有一个更关键的数字：Oracle（理想选择上限）达到 96.6%。
这说明，对大多数任务来说，5 条候选里已经至少出现了一条成功轨迹。模型能生成正确解，但验证器还没有把它们全部找出来。
差距在验证，不在生成。
27% 的平局率，到底意味着什么
回到那个 27% 的平局率。
这不止是一个统计数字。它揭示了一个结构性问题。
当模型面对两条轨迹都打出 7 分时，它并不是真的认为两者一样好。它只是被打分机制限制了表达能力。它内心的真实判断——比如 7.2 分 vs 6.8 分——被“取概率最高 token”这个操作给抹平了。
这就好比一个老师批改作文，只允许打“优、良、中、差”四个档。两篇水平有明显差距的文章可能都被归入“良”，家长问起来老师也说不出谁更好。
不是因为老师看不出来，是因为评分卡太粗了。
LLM-as-a-Verifier 做的事情，就是把评分卡从 4 档换成 20 档、50 档、100 档，然后还不止打一次分，要打很多次再取平均，还要把“整体表现”拆成“代码能不能跑”“逻辑对不对”“边界情况处理了没”分别打分。
这不是修修补补。这是把“验证”从一个粗略的直觉判断，升级成一个可扩展的计算流程。
验证信号还能用来干什么
验证不只是用来“选答案”的。
论文还展示了一个更深的用法：把验证信号用作强化学习的密集反馈（dense feedback）。
传统的强化学习，反馈往往是稀疏的——机器人走完了整条路，最后告诉你“成功了”或“失败了”。中间每一步走得怎么样，没人知道。
LLM-as-a-Verifier 可以在每一步都给出一个分数。这一步走得稳不稳，那一步有没有偏离目标，每一步都有一个细粒度的评价。
研究者用这个信号改进了 SAC 和 GRPO 算法，在机器人和数学推理基准上都看到了样本效率的提升。
验证不止是终点处的裁判。验证可以是全程的导航仪。
团队还为 Claude Code 做了一个扩展插件，让开发者在写代码的过程中就能实时看到验证反馈。
不是写完再改，是边写边验。
一个具体到让你不舒服的实验细节
论文里有一个细节，值得单独拎出来。
在 Terminal-Bench 上，如果只让模型跑一次，成功率是多少？不同模型不一样，但普遍不高。
如果跑 5 次然后随机选一个，成功率会涨一些——因为总有一次可能蒙对。
如果跑 5 次然后用 LLM-as-a-Verifier 选，成功率能到 88%。
但如果有一个“神谕”帮你从 5 个里挑最优，成功率是 96.6%。
差距是 8.6 个百分点。
这 8.6 个百分点，就是验证器目前还没够到的地方。
不是模型不会做，不是采样不够多，是验证还不够准。
验证器知道哪个答案“看起来不错”，但它还没法每次都精准地找出“哪个才是对的”？
网友灌水：
使用 DeepSeek V4 Flash 进行自身验证有点违反直觉，就像我读过的一项研究一样，该研究表明，在计算预算固定的情况下，基于弱模型、低成本模型进行调优的模型性能优于基于强模型、高成本模型（SE）进行微调的模型（来源： arvix 2024 ）。SE 的优势被其成本所抵消。
备选 SEO 标题
1. 大模型自验证成功率飙至88%！DeepSeek V4 Flash不换模型反超Claude Fable 5！
2. 斯坦福验证框架LLM-as-a-Verifier：Terminal-Bench 86.5% SOTA，成本仅为对手十分之一！
3. 验证即第四条Scaling曲线：LLM-as-a-Verifier把7分平局拆成4.2分和4.7分！
4. 2026实测：DeepSeek V4 Flash自验证5条轨迹成本0.11美元，成功率碾压GPT-5.5！