前沿AI基准是怎样炼成的？Terminal-Bench-Science、JudgmentBench、SlopCodeBench 三位负责人圆桌实录

在 Snorkel AI 主办的 Frontier Data Summit 2026 上，Terminal-Bench-Science、JudgmentBench、SlopCodeBench 三个开放基准项目的负责人，与主持人 Vincent Sunn Chen 围绕”如何为前沿大模型构建并维护可靠的公开基准”展开圆桌对话。他们分享了造题过程中最意外的发现、真实性与可测量性之间的艰难权衡、领域专家与 AI agent 协作造题的工作流、评分验证器的设计哲学，以及对 benchmaxing（应试刷分）、测试集污染和自动化造题的看法。

一、圆桌背景：三个基准，三种场景

这场圆桌由 Snorkel AI 创始团队成员 Vincent Sunn Chen 主持，三位项目负责人分别来自不同学科领域：斯坦福大学博士生 Steven Dillmann 是 Terminal-Bench-Science 的项目负责人，该基准面向科学研究场景；微软应用科学家 Russell Yang 负责 JudgmentBench，聚焦法律领域的判断能力评测；威斯康星大学麦迪逊分校（UW-Madison）博士生 Gabriel Orlanski 是 SlopCodeBench 的项目负责人，聚焦代码生成与 agent 编程。三个项目都获得了 Snorkel AI 开放基准资助计划（Open Benchmarks Grants）的支持。圆桌在闪电演讲之后开始，覆盖科学、编程、法律等多个新近涌现的基准方向。

二、建基准最意外的发现

主持人抛出的第一个问题是：在构建各自基准的过程中，最令你意外的事情是什么？

JudgmentBench 的 Russell Yang 首先回答。他最意外的是律师群体愿意无偿（pro bono）参与造题。他原本担心占用律师三十分钟就相当于浪费五百美元的专业时间，但实际接触下来，无论是 Snorkel 的标注员，还是合作大律所的律师，都热情地为开放基准做贡献。他还提到，除了 JudgmentBench，团队近期还发布了另一个开放基准 Library Design Bench。

SlopCodeBench 的 Gabriel Orlanski 的意外则来自对 agent 行为的观察：编程 agent 完全没有”自己写的代码将来会被怎样使用”的概念。在动手做项目之前，他直觉以为 agent 会考虑代码的长期用途，但实际上 agent 只解决眼前这一个问题，根本不关心代码之后会发生什么。

Terminal-Bench-Science 的 Steven Dillmann 则体会到造题本身的难度。半年前他自己试着造一道示例题，本以为难度刚好，结果发现造题极其困难；而到今天，要为前沿模型造出真正有挑战性的题，比半年前还要难得多。

三、真实性与可靠测量：最难的权衡

第二个问题围绕一个核心矛盾：如何在捕捉”真实工作”与”可靠测量”之间取得平衡？

Russell Yang 指出，在法律这类领域，多了一层比较对象的问题：我们到底在比较谁的工作？人类的好工作与人类的差工作之间存在差距，模型的好输出与坏输出之间同样存在差距。基准最终关心的是模型表现，因此必须接受权衡——诱导质量差异的方式，未必等同于优秀律师助理与平庸律师助理处理工作的方式。

Gabriel Orlanski 认为代码领域的处境尤其特殊：题目既要让 agent 能够解出来，又要反映真实用户会怎样给 agent 下指令。用户模拟方面已有不少进展，让用户成为基准的一部分，但”如何写出一份既真实又可解的规格说明书”，至今仍是团队在攻克的难题。

Steven Dillmann 用一句”科学是 sloppy（粗糙、不整齐的）”概括了 Terminal-Bench-Science 的困境：科学并不是简单的”对或错”，但基准又必须提供客观可验证、以结果为准的判据——达到指定结果即通过，否则失败。问题在于，科学是一整个过程，基准不可能自动捕捉全部过程；一位专家用这种方法解题，另一位专家用同样有效的另一种方法，验证器必须对所有有效路径保持宽容。没有任何基准能百分之百映射现实，这是必须接受的现实。

他还提到另一个权衡：科学家并不会把 agent 当成”从零做到一百”的全自动工具，而是把它当成交互式的研究助手使用——这恰恰是基准希望推动的方向，不是让 AI 包办全部科学，而是让它成为可靠的研究助手；但测试任务本身又必须以自主方式运行，这本身就是一对矛盾。

四、领域专家与 AI agent 协作造题

第三个问题是：在”依靠专家”与”用 agent 增强”之间，你们沉淀出了哪些具体的工作流？

Steven Dillmann 强调，Terminal-Bench-Science 全部题目都来自真正的领域专家，而非数据供应商，也不是计算机背景人员替 AI 出题；审题的人类评审同样是各自领域的专家。在此基础上，团队大量使用 AI 分析 agent 的解题轨迹（trajectory）。审题最重要的工作之一就是从轨迹中发现题目隐含的错误假设——题目里有一个没写明的 broken assumption，往往只有通过回放 agent 的思考路径才能暴露出来，因此团队用 AI agent 通读轨迹、识别这类缺陷。

Gabriel Orlanski 认同”领域专家担任最终裁判”是所有基准共通的最重要一环。两个项目都采取同一思路：尽量减少人类评审的工作量，只把指令和高层思路交给他们。他特别提到，开放基准社区正逐渐失去对”真实轨迹、真实思考痕迹”的访问权——前沿实验室的推理过程被隐藏，外部很难判断题目哪里含糊不清。而真实的轨迹是他们分析题目歧义性的关键材料：另一个 agent 阅读轨迹后才能识别出”这里其实完全模糊”。

Russell Yang 补充了一个专家分歧问题：当人类专家意见不一致时，自动评分器应该逼近谁的判断？是逼近聚合后的平均判断，还是把主观性与误差拆开，先消除误差、再保留部分主观性？这是自动打分必须面对的额外维度。

五、评分机制与验证器设计

主持人接着问：各自是如何设计评分机制、让评分方式与所要测量的构念（construct）和指令相匹配的？

Russell Yang 的 JudgmentBench 由一个实证问题驱动，因此准备了两套指标：从基准构建者角度，使用秩相关（rank correlation）指标，衡量标注员隐含的排序与真实排序的吻合程度；从关注逐条输出比较的使用者角度，则采用胜率（win rate）指标。

Gabriel Orlanski 的哲学是”把 agent 留给它自己”：任何额外的评分面都会把 agent 偏导出真正想测的能力之外，尤其是要测重构、代码设计决策这类能力时。团队只给约束，明确表示不关心程序内部长什么样、代码写成什么样，只要程序跑出指定结果即可。以 code search 任务为例，他们不关心 agent 如何构建代码搜索，只关心它是否读了指定目录、遵守给定规则、返回正确结果；即便评测只做 Python，换成 Rust 实现也不影响基准本身——核心只看”运行程序时是否造出了正确的东西”。

Steven Dillmann 重复并细化了验证器原则：验证器不能与参考解决方案过度耦合，这是收到题目中最大的失败模式——验证器只接受参考解法，却拒绝同样有效但不同的解法。其次是阈值问题：以 MRI 图像重建为例，重建质量有多项指标，方法 A 在这项指标上更好，方法 B 在另一项上更好，而参考解法偏向另一边，到底哪个算正确？验证器必须对所有可能的有效解法保持宽容。

六、Benchmaxing（应试刷分）与社区责任

benchmaxing 是当天的热门话题。主持人问：面对”为考而考”的风险，社区与基准构建者各自应承担什么责任？

Russell Yang 提到法律领域私人基准很多，但原因未必是对基准本身的顾虑，更多是保密要求或题目包含客户数据；就防御手段而言，私人留出测试集（private holdout）是他会考虑的方向。

Gabriel Orlanski 认为，一个好基准应该是对”未来走向”的一次有主见的押注；如果公司真的朝着你的基准刷分，而你做得足够扎实，结果对所有人都是净收益。当然现实并不完美，总会有可被利用的怪癖、失控的群体行为。构建者要明白自己造不出完美基准，需要留出测试集、留出示例，更要保证人们据此选择 agent、选择模型时看到的质量，反映的是模型真实水平，而不是造基准时被迫妥协的产物。

Steven Dillmann 先澄清定义：benchmaxing 特指”只抬高特定基准分数、却无法迁移到现实”的行为，这是负面含义；模型单纯提升通用能力、顺带在某基准上得分更高，那是好事。他亲身经历过污染：团队四月开始做 Terminal-Bench-Science 两个月后，他亲眼看到有人试图把与该基准高度相似的题目（改动少量题面）作为训练数据卖给实验室。他认为数据供应商应开发完全独立的题目，实验室也应核查采购的训练数据，否则最终就是在给基准本身打分，而目前没有任何实体来治理这些行为。

主持人 Vincent Sunn Chen 总结道：一方面，机器学习本质上就是设定目标再爬坡，只要目标足够通用、多样、持续更新，爬坡本身是好事；另一方面，经济激励确实会催生”funny business”。构建者一侧的应对包括：提高单题质量门槛、检查评分器是否接纳可利用的解法、设计公开与留出集对比分布差异，并借助独立评测力量、给实验室提供自查训练数据的审计工具。没有银弹，靠的是社区治理与整体严谨。Gabriel Orlanski 补充：开放联网本身就是两难——真实场景里 agent 能上公网，但公网里直接就能搜到答案；而只要基准设计扎实、解法与评分高质量，刷分并不可怕，问题都出在偷工减料。

七、给下一代基准构建者的建议

主持人请三位分享走过整个发布流程、收到社区反馈后的教训。

Russell Yang 的教训是规划要前置：团队为 NeurIPS 截止日期仓促拼装一切，事后建议提前规划好设计、合作标注员、实证结果如何使用，让数据收集、分析与写作顺畅衔接，而不是收集完数据立刻被动分析、赶稿。

Gabriel Orlanski 的建议是”保持简单”：ProgramBench 就是一个用极简思路逼出目标信号的例子；题目越简单，基准越有力，也越难被刷分、越容易评分、越容易被社区使用——如果社区跑不起来，再精巧的失败模式测量系统也无人问津。

Steven Dillmann 的第一建议是”建一支好团队”，尤其大型社区项目：要真正认识合作者，分清谁值得信任，把贡献者当人而不是编号；没有评审团队，Terminal-Bench 社区什么都转不动，而评审必须出于正确的理由被激励，团队的使命沟通、让成员相信使命，排在一切技术工作之前。

八、观众问答：非技术专家、选题、自动化、时间分配

问：如何让非技术领域专家顺畅参与造题？ Steven Dillmann 建议配对制：把技术人员与领域专家组成搭档共同完成一道题（例如他展示过的湖泊封冻与消融的地球科学题，就由一位有地球科学圈朋友的贡献者协作完成）；其次要把贡献流程逐条写下来，细节越多越好，让人照着步骤就能造出题目。Russell Yang 补充，他们为标注员办了培训课，手把手讲平台用法和问题对接人。

问：如何选题以跟上模型能力的指数增长？ Steven Dillmann 不为科学家规定该提交什么问题，信任专家判断难度，但标准化工作流（网上文档充分）的提案通常太简单，细分、小众的科学问题更可能成为有挑战性、能暴露有趣失败模式的题目。Gabriel Orlanski 认为需要健壮的 PR 系统或专家标注来证明：即便 agent 已能拿 70%，从 70 到 80 的提升空间也值得保留；除了接收 PR，还可以从现有代码仓库挖掘题目，标准一旦立下就绝不退让。

问：能否把基准构建者 80% 的工作自动化？ Russell Yang 提到收购企业内部文档与消息、从中提炼离散题目是个有意思的方向，难点在于把杂乱的纵向数据转成专家可审的题目。Gabriel Orlanski 坦言即便能自动化 80%，质量保证仍然极难，agent 做不好”确保题目可解、无歧义、不可解风险”的审查；理想状态是自动化把造题门槛降下来，让人专注最后 20% 的品味与”值不值得测”。Steven Dillmann 明确反对自动生成科学题目：自动化适合辅助审查，但必须有人复核自动产物；Terminal-Bench-Science 只有 70 道题，远不能代表全部科学，瓶颈在于向科学界讲清楚这件事对科学本身有益——他们也常遭遇”你们是不是要抢走我们工作”的抵触。

问：时间是如何分配的？ Steven Dillmann 个人超过 50% 的时间用于聚人：冷启动阶段他亲自跑斯坦福、伯克利、东海岸拜访教授、招募贡献者；其次是搭基础设施，让评审专注审题；第三是以身作则、亲自审题并树立好坏题标准。Gabriel Orlanski 把约 90% 时间花在审题与质量保证上，5% 用于基础设施，最后 5% 用于写作与跟进新题；基准构建者应对质量保持偏执。Russell Yang 同样把最大块时间花在人身上：不仅培训标注员正确使用平台，还要保证他们持续交付高质量产出并处理质量下滑。

九、结语

三个基准、三种场景，但共识高度一致：领域专家是最终裁判，AI agent 只负责增强而非替代；验证器必须宽容所有有效解法；保持题目简单以降低被刷分空间；质量优先于数量；团队与信任是社区基准的根基。面对前沿模型快速进化、训练数据污染与自动化造题的诱惑，这场圆桌给出的答案不是技术银弹，而是前置规划、公开与留出集并举、社区共同治理，以及对质量近乎偏执的坚持。

参考资源

Terminal-Bench-Science：https://www.terminal-bench-science.ai/
JudgmentBench 论文：https://arxiv.org/abs/2605.25240
SlopCodeBench 论文：https://arxiv.org/abs/2603.24755
Snorkel AI Open Benchmarks Grants：https://benchmarks.snorkel.ai/
原视频：https://www.youtube.com/watch?v=99vvfzDalvo