社区所有版块导航
Python
python开源   Django   Python   DjangoApp   pycharm  
DATA
docker   Elasticsearch  
aigc
aigc   chatgpt  
WEB开发
linux   MongoDB   Redis   DATABASE   NGINX   其他Web框架   web工具   zookeeper   tornado   NoSql   Bootstrap   js   peewee   Git   bottle   IE   MQ   Jquery  
机器学习
机器学习算法  
Python88.com
反馈   公告   社区推广  
产品
短视频  
印度
印度  
Py学习  »  Git

Github热榜第二:仅靠“自验证”框架让 DeepSeek V4 Flash 反超 Fable 5,成本不到 1/11

AI前线 • 2 天前 • 35 次点击  
作者 | 四月

一个已经训完的大模型,不换参数、不做微调,究竟还能榨出多少性能?

当行业纷纷把目光投向 Test-time Scaling,指望在推理阶段‘大力出奇迹’的当下,一份名为 LLM-as-a-Verifier 的开源框架在社区引发了现象级讨论,并迅速冲上 GitHub 热榜第二。

当 AI Agent 任务越来越复杂,如何评判大模型输出的对错,一直是个昂贵且棘手的难题。而由 Jacky Kwok 牵头,联合斯坦福大学、加州大学伯克利分校和英伟达研究院学者组成的团队,给出了惊艳的解法。

在极具挑战的 Terminal-Bench 2.1 基准测试上,DeepSeek V4 Flash 仅靠对每个任务采样 5 条候选轨迹,再以自身作为 Verifier 从中挑选最优解(Best-of-5),系统成功率即从 79%飙升到了 88%,一举超越了闭源前沿模型 Claude Fable 5。

更受关注的是调用成本:DeepSeek 自验证单任务成本约 0.11 美元,而 Fable 5 则约 1.3 美元,成本不到后者的十分之一。有网友质疑,11 倍的成本差距可能只来自单 Token 价格差。由于自验证需要多次采样和检查,完成每个任务实际上消耗了多得多的 Token,总价未必便宜。

论文一作 Jacky 回应称,公布的成本已经包含“生成 N 条候选轨迹”与“后续验证”两部分的全部开销。虽然消耗了更多 Token,但得益于开源模型极低的 Token 单价,最终核算下来的“单任务总成本”依然实现了碾压级的优势。

 DeepSeek V4 Flash 的自验证实验

早在今年 7 月,研究团队就已发布了论文《LLM-as-a-Verifier: A General-Purpose Verification Framework》,核心突破在于:提出一种不额外训练专门奖励模型(Reward Model)或验证器,就能直接利用现有 LLM 对 Agent 的完整执行轨迹进行细粒度验证和排序的方法。目前该研究已经在 Coding、机器人控制和医疗诊断等多个领域完成验证。(https://arxiv.org/pdf/2607.05391)

这次更新的 v0.2.0 框架,主要新增 DeepSeek V4 Flash 验证支持和 Terminal-Bench 2.1 自验证基准。实验整体架构的巧思之处体现在:LLM-as-a-Verifier 不只用于测试时扩展,验证信号还可以用于进度跟踪和强化学习。过去,我们要对复杂的 AI Agent 进行强化学习微调,最大的阻碍是缺乏高质量的“奖励信号”,而这套框架基于概率加权的“连续验证分数”,恰恰为其提供了极其平滑、高密度的奖励信号(Dense Reward)。

在设计上,在对于每一个具体的终端控制任务,系统首先由 DeepSeek-V4-Flash 生成 5 条 mini-swe-agent 执行轨迹。随后,模型自身同时承担起“裁判员”的角色,为这些候选轨迹打分,最终由 LLM-as-a-Verifier 框架完成细粒度排序并挑出最优解。

实验结果呈现出了极其显著的性能跃迁:

• 阶梯式涨点:在不介入验证时,模型单次生成的原生成功率仅为 78.7%;而在 Best-of-3 设定下(在前 3 条候选轨迹中筛选),系统成功率跃升至 86.5%;当扩大至 Best-of-5 时,成功率直接被推高到了 88.0%

  • 逼近上限的 Oracle 指标:更为关键的一项指标是 Oracle(理想选择上限)达到了 96.6%。原论文进一步汇总不同 Agent 配置后的数据显示,理想选择器下的覆盖率最高甚至可达 98.9%。

换句话说,对于绝大多数复杂任务,只要给模型 5 次尝试机会,正确的解题轨迹其实早就已经包含在候选池中了。大模型从来不缺“生成正确答案”的能力,过去真正限制系统表现的,是一双能把正确答案精准挑出来的“眼睛”。

成本也是这组实验受到关注的重要原因。团队测算中,DeepSeek 一侧使用 DeepSeek V4 Flash Max,价格按照当时 OpenRouter 报价计算,生成多条候选轨迹和后续验证的成本都已经包含在内

从“粗糙裁判”到“概率显微镜”

有人提出,既然候选池中早已存在正确轨迹,为什么行业沿用已久的“LLM-as-a-Judge(大模型裁判)”方案在此前总是挑不准?

事实上,传统裁判机制的核心痛点,在于离散评分的颗粒度过粗。传统的评判方式通常要求大模型直接输出一个 1 到 5 分的整数分数。然而在处理长逻辑代码或复杂系统操作时,两条存在细微质量差异的执行轨迹,往往会被模型同时判定为 4 分或 5 分。

原论文实测表明,单次离散评分的平局率高达 26.7%。当超过四分之一的候选方案陷入平局时,系统根本无法完成最优筛选。

这暴露了离散评分的瓶颈,而后续实验进一步发现,提高评分粒度、增加重复验证和拆分评价标准,都能持续提升验证准确率。这意味着 Test-time Scaling 不只有“多生成”,验证侧计算能力的持续提升本身也可以成为独立的 Scaling 维度。

LLM-as-a-Verifier 的破局点,就在于它不再依赖模型吐出的干瘪文本,而是深入截获模型在输出评价时的“潜意识”——底层对数概率分布(logprob)

核心机制:连续评分

普通 LLM Judge 通常只读取模型最终输出的离散分数,而 LLM-as-a-Verifier 进一步利用不同评分 Token 对应的概率分布,计算一个连续验证分数。

因此即使两条轨迹最终都被判为“4 分”,只要模型对相邻评分档位的概率分布不同,仍然可以继续拉开差距。

验证能力的三维扩展(3D Scaling)

在此基础上,团队还把 Verification Compute 沿三个方向扩展: 增加评分粒度、对同一轨迹重复评估、把复杂评价拆成多个 criteria 分别判断。

实验显示,随着三个方向上的验证预算增加,Verification Accuracy 都继续提升。这也是论文把 Verification 定义为一条独立 Scaling 轴的重要依据。

算法与工程降本:PPT 排序与前缀缓存

在落地工程中,伴随候选数量的增加,全量两两比较(Pairwise Comparison)的计算复杂度会呈现可怕的  爆炸。

团队因此提出Probabilistic Pivot Tournament(PPT),避免对所有候选做完整两两比较,用更少的比较完成候选排序;工程侧又通过前缀缓存进一步降低长 Agent 轨迹的重复输入成本。

重新审视 Agent 的算力账本

过去 Test-time Scaling,更多讨论多采样、多搜索,LLM-as-a-Verifier 补上了另一半:候选生成出来以后,验证本身也值得投入计算。 对开发者而言,模型选型不再只是看单 Token 价格,而要看单位成功任务的总成本。廉价模型多跑几次,再通过 Verifier 筛选,依然可能比直接调用昂贵旗舰模型更划算。

这对开源模型尤其重要。过去高质量验证往往依赖额外训练 Reward Model、PRM,或者调用更强模型做 Judge;Jacky 团队则证明,现成 LLM 本身就能承担相当一部分细粒度验证工作,甚至可以同时作为生成者和验证者。Verifier 因此有机会进一步进入 Agent Harness,成为运行时基础能力。

图片

图片

图片会议推荐

2026 年 AICon 人工智能开发与应用大会 · 深圳站将于 8 月 21 日—22 日举办,聚焦 AI 基础设施、大模型系统、智能体工程、数据智能、多模态技术与行业落地等关键方向,邀请来自腾讯、阿里、华为、百度、蚂蚁集团等 50 + 头部科技企业技术负责人、科研机构一线专家,系统性分享前沿洞察与实战干货,共同探讨 AI 技术从能力到系统、从实验到生产的真实路径。限时 9 折专属优惠,现在报名立减 580,更多详情可扫码或联系票务经理 13269078023 进行咨询。

图片

今日荐文

OpenAI紧急停训GPT-6,安全原因还是另有隐情?

神级反转!GitHub 昨夜大规模宕机7小时,Cursor 火速上线Agent版代码托管平台

3个月身价暴涨5倍!对比解构中美“Token工厂”的造富vs烧钱

中行回应“Token贷”:已投放3户800万元;头部AI大厂员工:90小时工作制成常态;宇树科技中签者不敢发朋友圈:怕被嫉妒|AI 周报

图片
你也「在看」吗?👇

Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/200000