数据中心化 AI 的理念
我叫 Alex，刚才已经介绍过了。简单说，我过去十年一直在做我们所说的“数据中心化 AI”（data-centric AI）：研究如何构建数据集，以及如今所说的评测环境，用来评估、调优和训练 AI 模型。
在这个领域里，要迭代、改进、检查一个 AI 系统，投入往往更多落在输入数据上，而不是具体选什么算法或模型架构。当然，这不是非此即彼。这个想法最早是我们在斯坦福提出的；我后来在华盛顿大学有一个实验室，现在已经不再活跃于学术界。数据中心化 AI 的核心判断是：相对而言，越来越多精力会花在构建合适的数据和环境上，用于评测、强化学习和模型迭代；之后才会去检查单个神经元、调整算法，或设计定制架构。这就是我的研究背景。
如今，我们和 Harbor 团队、Ryan 等人合作构建数据集和基准，合作对象几乎涵盖所有主要的前沿实验室、新型 AI 实验室、超大规模云服务商和垂直 AI 公司，也包括任何认真开展大规模评估、调优、训练和模型或智能体研发的团队。我们专注于数据，很多工作都在研究怎样把人类和自动化方法结合起来，用于数据生成、质量控制等。我们通常更关注人类生成的数据，因为这类数据往往更能反映模型尚未饱和的领域。
如果模型可以把一个数据点或环境连同任务、评分标准——也就是答案和评分规则——整套都生成出来，那么它们很可能就不太适合用来评估和调优模型。这就像让学生自己出考题，再自己给自己打分。我们会把人的工作和弱监督、人机协同自动化等技术结合起来，让评测越来越复杂、能力和任务越来越复杂时，所需工作量仍然足够高效，能够在某种意义上跟上前沿发展。今天……
人与 AI：前沿模型背后的数据引擎
今天我们用“人类加 AI”的同一套流程来做数据，我们把它叫作数据的 RSI 循环。现在想拿到经费，你得说 RSI（笑）。不过严格说，我们做这件事已经十年了，那时还没人用 RSI 这个说法。
简单讲，就是让 AI 智能体和模型帮助人类创造更好的数据，再通过规模化的人类反馈，或所谓的弱监督，进一步调优和改进这些 AI 智能体。这套方法用于构建海量数据集和环境，为大家每天使用的许多前沿模型提供训练和调优支持。我们也用它来开发基准数据集，包括供内部评估的私有基准和公开基准。今天我会讲讲这套流程，重点放在基准测试上。先给一个非常好猜、也相当不避讳宣传，但确实准确的一句话总结……
好的基准究竟靠什么？
一句话总结就是：好的基准，核心在于好的数据。可以把我们说的数据，或强化学习环境，想成一道道练习题或考试题。你有一个希望智能体完成的任务，比如写代码、回答医疗问题，或撰写一份深度研究报告；还要有它执行任务时所处的环境和上下文，最后再配上一套评分标准，用来评估表现。这些就是我们构建的核心内容。
很多人也许都在为内部评估构建这类数据。基准测试最重要的部分之一，就是测试题和评分标准；它们显然是标准化考试的核心。要大规模开展评测，基础设施当然很重要，但如果没有构建正确的数据、没有测量正确的东西、没有写好练习题和测试题，就做不出好的评估和基准。这就是一句话版，下面我再展开讲。
前面已经简单介绍过我的背景。如果你想了解我们在斯坦福、华盛顿大学（Udub）、威斯康星大学等地开展项目的具体细节，相关文献里有不少内容。我想团队今年大概有六篇论文进入评审，其中大多数都与公开基准有关，也包括和 Terminal-Bench 等团队的合作。想了解方法的细节，可以看科学文献。接下来我会介绍一些近期支持的基准案例，先讲公开的例子。我们也为实验室、垂直领域公司和超大规模云服务商商业化地构建了很多评估和基准，那些是私有项目；今天我会讲不少通过我们的开放基准资助计划合作的团队……
Snorkel 开放基准资助计划
通过这个计划，我们已经承诺投入大约三百万美元。接下来一两周，我们还会宣布一项重大扩展，对此我们很期待。计划主要是支持开放和／或学术基准。我们认为这对整个领域很重要。有人听说过“刷榜”（benchmaxing）这个词吗？很好。有人觉得公开基准是有害的吗？看来有一位（笑）。那我先说说……
“刷榜”与过拟合问题
如果你没听过这个词，“刷榜”大概是个新说法，指的是一个非常老的概念。坦白讲，人类社会里也有类似现象；放在机器学习里，以前叫“过拟合”，就像为了考试而学习。它有不同程度：有人指控过实验室直接作弊，比如某个实验室的人联系基准构建者，问能不能拿到封闭数据集，好把它放进训练集里。
更常见的情况，就像专门为考试准备：把大量研发精力不成比例地投入到一个公开基准上。分数确实提高了，但优化结果会像一个很尖的峰：在那个点表现很好，能力稍微往左或往右变化一点，性能就掉下来。这显然对谁都不好。
我们认为，避免这种过度优化的最好办法之一，是模型和应用开发者用一套稳健、多样的指标来指导研发。当然，责任主要在开发者自己。指标应包括公开基准、私有基准，以及持续进行的人类评估和自动化评估。优秀的模型开发者会并行使用这些方法；我们也和许多实验室合作，做其中不少私有版本。归根结底，开发模型时不对基准过拟合是开发者自己的责任。但从帮助构建和资助基准的角度来说，我们非常相信，缓解这一问题的办法是……
为什么我们需要持续更新的基准
缓解刷榜、减少过拟合，以及避免大家都在钻空子后基准价值被稀释，一个办法就是构建更多基准：设计得更稳健、持续维护，并且彼此更加多样，这样也更难被投机取巧。
大家听说过古德哈特定律（Goodhart's law）吗？这句老话大意是：“一旦某个指标成了目标，它就不再是好指标。”这是流传已久的商业和经济学格言。但据我所知，没人把它理解成“什么都别测，不要设 KPI”。它真正想说的是，不要设那些很容易被操纵的 KPI；要谨慎、有意识地设计指标体系，并用相互制衡的指标，防止人们轻易地钻空子。
因此，除了私有评估、持续的人类评估，以及测量工具箱里其他必要的东西，我们这个领域还需要更多样、更稳健的基准。我们资助并合作的 Terminal-Bench 团队就是很好的例子。我们一直很欣赏他们，也持续与他们合作、支持他们和其他团队。Ryan 和团队推动的一个想法是“持续基准”：像开源项目一样维护，不断修补、改进，确保基准没有被模型完全吃透。
总结一下，模型和智能体开发者、数据和基准开发者两边都有办法缓解过拟合或刷榜。我们相信的一种办法是：基准要更多、更好、更持续、更稳健，而不是更少；也要更公开，并由少数大型机构以外的团队独立创建。这正是我们通过基准资助计划想支持的方向。
下面我讲讲基准大致是什么样子，并举一些例子，再深入介绍几个。正如宣传所说，Senior-SWE-bench 是我们与普林斯顿实验室密切合作完成的项目，最初的 SWE-bench 也来自那里。稍后我会详细谈它；先来看几个……
前沿基准案例：Agent's Last Exam 与 OSWorld 2.0
这里有几个很好的例子。我们和伯克利的一支团队合作做了 Agent's Last Exam，关注智能体在长程任务上的表现：任务要像真实世界的工作那样具体，但结果又必须可验证，才能评测和比较。任务通常既涉及电脑操作，也涉及编程、API 和终端的使用。
另一个和伯克利团队合作的项目是 Continual Learning Bench，重点是衡量 AI 模型或智能体能不能从一次任务经历中学到东西，并在下一次应用。也就是说，这像是一个元基准：无论智能体第一次任务完成得怎样，下一次遇到另一个情节或同一任务的变体时，它能不能自动学会一些东西？我们想测量的就是持续学习能力。很多人认为，持续学习是构建真正 AGI、ASI（不管你如何定义）的主要缺口之一。我算是老派研究者；十年前刚开始训练机器学习模型时，我会觉得今天这样的模型已经算 AGI 了。术语当然可以争论，但从经验中学习这项能力，我们认为非常重要。Continual Learning Bench 是开始量化、通过实验测量它的一个好例子。
OSWorld 2.0 是我们支持并合作的另一个项目，是一个先进的电脑操作基准。最近一些个人智能体的发布让我们看到，电脑操作能力有了很大进步。但如果看真实世界任务的多样性，尤其是非网页界面和特定领域的任务，电脑操作智能体仍有很多能力缺口。OSWorld 2.0 就是一个例子。还有 Terminal-Bench 2.0、2.1、3、4、Terminal-Bench Science，以及 Ryan 刚才在现场介绍的其他项目；我们很荣幸能支持这些项目并与团队合作。
接下来我想强调几个主题，也就是我们认为对 AI 能力及其评测基准都很重要的几个主要维度。这只是对庞大基准与评测设计空间的简化。我们既想在开放和学术领域支持沿这些方向探索，也希望大家在构建内部基准、测量和开发自己的 AI 智能体或系统时考虑这些维度。其中一个维度是……
智能体基准测试的三个维度
第一个维度是环境和上下文有多复杂，这是我们特别想探索的方向。如果你正在考虑或实际开发开放基准，只要涉及这些维度中的任何一个，都欢迎联系；我们很愿意通过开放基准资助计划提供支持、开展合作。
先看环境或上下文的丰富程度。以编程为例，我特意选它，因为编程能力已经很强，很多人觉得相关评测快饱和了。但我稍后会谈到“评测缺口”：其实评测落后于真实能力。有些事情 AI 可能已经做得到，只是我们还不够擅长测出来。最后这一段能力空间既有意思、内容丰富，也很有价值，可我们现在甚至还测不准；这正是我们关注的部分。
编程环境最简单的形式，是一道 CS 101 考试题：上下文完全自足。题目可以难得近乎变态，甚至是重大挑战问题，但背景材料可能就只有纸面上的一段话。另一端则是真实世界的环境。要完成任务，可能需要进入 Slack、Notion、Jira，和不同角色沟通，在一堆杂乱的代码仓库里找线索，甚至采访客户或团队成员，才能弄清楚该怎么实现。这就是更丰富、更贴近现实的上下文和环境。我们认为，沿这个维度还有很大空间，可以继续推进和衡量 AI 能力。
第二个维度是“自主执行跨度”：完成一项任务需要多少步骤，执行过程有多动态。比如 Continual Learning Bench，还有一个叫 Slop Code Bench 的项目。光看名字有多严肃，大概就能猜出哪些是学术团队做的（笑）。Slop Code Bench 来自我们首席科学家的威斯康星实验室，关注的是在 Codex 和 Copilot 这类场景里完成任务时，目标会在执行过程中多次改变——而现实里的大多数工作确实如此。用过编程智能体的人，有多少次能从头到尾完成一个跨度较长的任务，而且需求一次都没改过？恐怕很少，至少占比不会高。
因此，我们既要测试更长的任务：从人类五分钟就能在 CS 101 考试环境里答完的题，延伸到可能需要一组程序员花一个月开发的任务；也要测试过程中的动态变化。目标什么时候改变？什么时候需要持续学习，才能适应变化、从经验中调整？
第三个维度是输出本身的复杂度，以及评分标准和评估者对输出的要求。我会结合 Senior-SWE-bench 来讲。就编程而言，这个维度从可以轻松用单元测试验证的结果开始：比如一道 CS 101 题，单测只要求唯一答案是 3，检查答案是不是 3 就行；另一端则是完整的软件产品，需要从品味、风格、真实场景中的效用等各种细腻而难以定义的维度来评判，不能只靠简单的单元测试……
智能体基准测试的三个维度（续）
软件产品不能只用简单的单元测试来判断，对吧？可验证性和 AI 当下擅长或不擅长什么密切相关，这绝非巧合。对那些结果高度可验证的任务，即使难得近乎变态，也远比对可验证性低的任务更容易开发数据、基准和训练集。因此，如何提升 AI 的测量能力，是我们非常感兴趣的另一个维度。我们支持的这些基准都体现了这一点。如果你感兴趣，可以去看看 Senior-SWE-bench 的网站，那里解释得更好。还有开放数据。概括来说，它的方向是……
评估“资深”软件工程智能体，而不是给初级员工的提示
这类基准把 SWE 编程评测推向前面那些维度的另一端。我们与最初发起 SWE-bench 项目的普林斯顿实验室合作开发了 Senior-SWE-bench：它的上下文更复杂，任务描述也没那么精确。这就是名字的由来。它不像给初级工程师的任务那样，提供非常具体、按步骤执行的指令；现在很多编程基准其实就是这样。如果你读一读，会觉得这像是给一个需要辅助轮的初级员工写的过度规定的说明，哪怕任务本身很难。
Senior-SWE-bench 的任务仍然可以验证，也就是说，存在好的解决方案和坏的解决方案；但任务描述会像交给资深工程师那样留有空间，例如“把这个网页做得更好”“把这个功能做出来”。任务跨度更长，需要更多推理步骤、工具使用和实际操作，输出也更丰富、更复杂，需要用更细致的方式评估。评判不能只看单元测试，还要考虑品味、架构决策、代码质量、产品决策等。
这就是从对 AI 来说可能极其困难的基准、数据点或测试题，转向另一类任务的例子：它们看起来认知难度也许没那么高，却更难被今天的智能体做好；它们更接近资深软件工程师会接手的真实工作，而我们现在甚至还无法充分测量。接下来……
评测缺口：AI 能力与测量能力
总结一下，我想说，现在是构建评估和基准最令人兴奋的时刻。无论你做的是评测基础设施、输入数据，还是针对自己的场景做内部私有评估，或是在公开领域大规模开展评测，都是如此。
可以说，在 AI 历史上，或者至少在我参与这个领域的十多年里，这是第一次：AI 的能力明显领先于我们评估它们的能力。回想五六七年前，我们还把它叫作机器学习。当时我们可能只做一百个数据点，比如判断图片里是猫、狗、热狗还是非热狗——那确实是当年的真实任务——然后花好几年一点点爬分数、提高成绩。现在情况第一次反了过来：AI 能力不断涌现、持续增长，既有工程推动，也有自身涌现的部分；它们已经超出了我们的测量能力。
所以我认为，并不是所有事情都饱和了，而是我们在构建更复杂、更真实、更精确的评估数据集和基准方面落后了，因而还没法真正评估和研究 AI。这是最关键的问题之一。这样做不只是为了找方法继续爬分、改进模型，也是为了知道哪些系统可以安全部署、哪些还不行，并衡量它们是否对齐。
因此，我会说，现在是前所未有的……
基准从未如此重要
这是令人兴奋的时代。如果你们有人感兴趣，请联系我们，我们很愿意提供支持。那我就讲到这里，谢谢大家。