我们用几乎无法预测真实世界性能的基准来评估AI

# 测量2025年初AI对经验丰富的开源开发者生产力的影响 来源：https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ 预测与观察的减速对比图 ### 动机 虽然编码/智能体基准测试¹（https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/#fn:1）在理解AI能力方面已被证明有用，但它们通常为了规模和效率而牺牲了真实性——这些任务是自包含的，不需要事先了解上下文，并且使用算法评估，无法捕捉许多重要能力。这些特性可能导致基准测试高估AI能力。另一方面，由于基准测试在没有实时人类交互的情况下运行，模型可能会在取得实质性进展的情况下失败，因为存在人类在实际使用中会修复的小瓶颈。这可能导致我们低估模型能力。总的来说，直接将基准测试得分转化为实际影响可能很困难。 我们有兴趣评估AI在实际环境中的影响的一个原因是，为了更好地理解AI对AI研发本身的影响，这可能带来重大风险。例如，极其快速的AI进展可能导致监督或保障措施的失效。测量AI对软件开发者生产力的影响，为基准测试提供了补充证据，有助于了解AI对AI研发加速的整体影响。 ### 方法 为了直接测量AI工具对软件开发的真实世界影响，我们从大型开源代码库（平均星标超过22k，代码行数超过100万行）招募了16名经验丰富的开发者，这些开发者已经为这些代码库贡献了多年。开发者提供他们认为对代码库有价值的真实问题列表（共246个）——包括错误修复、功能添加和重构，这些通常是他们日常工作的一部分。然后，我们将每个问题随机分配到允许或禁止使用AI的组别。当允许使用AI时，开发者可以使用任何他们选择的工具（主要是Cursor Pro与Claude 3.5/3.7 Sonnet——研究时的前沿模型）；当禁止使用AI时，他们在没有生成式AI辅助下工作。开发者在录制屏幕的同时完成这些任务（每个平均耗时两小时），然后自我报告所需的总实现时间。我们向开发者支付每小时150美元的参与研究补偿。 方法概述 ### 核心结果 当开发者被允许使用AI工具时，完成问题所需的时间增加了19%——这是一个显著的减速，与开发者的信念和专家预测相悖。这种感知与现实之间的差距令人震惊：开发者预计AI能让他们提速24%，即使在经历减速后，他们仍然认为AI使他们提速了20%。 下面，我们展示了原始的平均开发者预测时间和观察到的实现时间——我们可以清楚地看到，当允许使用AI工具时，开发者花费的时间明显更长。 预测时间与观察实现时间对比图 鉴于理解AI能力/风险以及对此话题多样的观点的重要性，我们认为有必要避免对我们结果的潜在误解或过度概括。我们在表2中列出了我们**不**提供证据支持的声明。 **我们不提供证据支持：** | **说明** --- | --- AI系统目前能加快多数或大多数软件开发者的速度 | 我们不声称我们的开发者或代码库代表了软件开发工作的大多数或多数 AI系统能加快软件开发之外领域个人或团体的速度 | 我们只研究软件开发 近期未来的AI系统不会在我们确切的环境下加快开发者的速度 | 进展难以预测，且过去五年AI已有实质性进展²（https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/#fn:2） 在我们确切的环境下，没有更有效地使用现有AI系统以实现积极提速的方法 | Cursor并不从LLM采样大量token，可能未使用最优提示/框架，且领域/代码库特定的训练/微调/少样本学习可能带来积极提速 ### 因素分析 我们调查了20个可能导致减速的潜在因素，发现其中5个可能有所贡献： 因素分析表 我们排除了许多实验假象——开发者使用了前沿模型，遵守了他们的分组安排，没有差异化放弃问题（例如放弃困难的AI禁止组问题，从而降低AI禁止组的平均难度），并且在有AI和没有AI的情况下提交了质量相似的PR。减速现象在不同结果测量指标、估算方法以及我们数据的许多其他子集/分析中持续存在。详情和分析请参见论文（https://arxiv.org/abs/2507.09089）。 ### 讨论 那么，我们如何将我们的结果与令人印象深刻的AI基准测试得分以及关于AI有用性和广泛采用AI工具的轶事报告相协调？综合来看，这些来源的证据对于AI代理是否能有用完成任务或加速人类给出了部分矛盾的答案。下面的**表格总结**分解了这些证据来源，并总结了这些来源的证据状态。请注意，这并非全面——我们旨在非常粗略地指出一些显著的重要差异。 | | 我们的RCT | 基准测试如SWE-Bench Verified、RE-Bench | 轶事和广泛AI采用 | | --- | --- | --- | --- | | **任务类型** | 来自大型、高质量开源代码库的PR | SWE-Bench Verified：带有作者编写测试的开源PR；RE-Bench：手动设计的AI研究问题，具有算法评分指标 | 多样化 | | **任务成功定义** | 人类用户满意代码能通过审查——包括风格、测试和文档要求 | 算法评分（例如自动化测试用例） | 人类用户认为代码有用（可能作为一次性原型或单次研究代码） | | **AI类型** | 聊天、Cursor代理模式、自动补全 | 通常为完全自主的智能体，可能采样数百万个token，使用复杂的代理框架等。 | 各种模型和工具 | | **观察结果** | **模型在20分钟-4小时的真实编码任务上使人类减速** | **模型在人类难以完成的基准任务上经常成功** | **许多人（尽管并非所有人）报告发现AI对>1小时的重要软件任务非常有帮助，应用范围广泛。** | 任务类型 来自大型、高质量开源代码库的PR 任务成功定义 人类用户满意代码能通过审查——包括风格、测试和文档要求 AI类型 聊天、Cursor代理模式、自动补全 观察结果 模型在20分钟-4小时的真实编码任务上使人类减速 任务类型 SWE-Bench Verified：带有作者编写测试的开源PR RE-Bench：手动设计的AI研究问题，具有算法评分指标 任务成功定义 算法评分（例如自动化测试用例） AI类型 通常为完全自主的智能体，可能采样数百万个token，使用复杂的代理框架等。 观察结果 模型在人类难以完成的基准任务上经常成功 任务类型 多样化 任务成功定义 人类用户认为代码有用（可能作为一次性原型或单次研究代码） AI类型 聊天、Cursor代理模式、自动补全 观察结果 许多人（尽管并非所有人）报告发现AI对>1小时的重要软件任务非常有帮助，应用范围广泛。 调和这些不同的证据来源困难但重要，部分取决于我们试图回答什么问题。在某种程度上，不同来源代表了关于模型能力的合理子问题——例如，我们既对在最大激发下（例如每个问题采样数百万个token或数十/数百次尝试/轨迹）模型的性能感兴趣，也对标准/常见使用下的性能感兴趣。然而，某些属性可能使结果对最重要的关于现实世界有用性的问题无效——例如，自我报告可能不准确且过于乐观。 以下是我们认为最合理的几种广泛假设类别，用于解释这些观察结果如何被调和（这旨在作为一个非常简化的思维模型）： **观察结果总结**：在我们的RCT中，AI使经验丰富的开源开发者减速，但在基准测试中表现出色，且轶事上被广泛认为有用。 图表 **假设1：我们的RCT低估了能力**：基准测试结果和轶事基本正确，而我们环境中存在一些未知的方法论问题或其他重要环境不同的属性。 图表 **假设2：基准测试和轶事高估了能力**：我们的RCT结果基本正确，而基准测试得分和轶事报告可能高估了模型能力（可能各自有不同的原因）。 图表：高估能力 **假设3：不同环境的互补证据**：所有三种方法论基本正确，但分别测量了“真实”任务分布中模型更具挑战性或不具挑战性的子集。 图表：混合 在我们的RCT中，AI使经验丰富的开源开发者减速，但在基准测试中表现出色，且轶事上被广泛认为有用。 总结图表 基准测试结果和轶事基本正确，而我们的环境中存在一些未知的方法论问题或其他重要环境不同的属性。 RCT低估图表 我们的RCT结果基本正确，而基准测试得分和轶事报告可能高估了模型能力（可能各自有不同的原因） 基准测试高估能力图表 所有三种方法论基本正确，但分别测量了"真实"任务分布中模型更具挑战性或不具挑战性的子集 混合图表 在这些示意图中，红色表示证据来源与模型“真实”能力水平之间的测量误差或偏差，导致证据具有误导性；蓝色差异（例如在“混合”场景中）表示不同证据来源所代表的真实差异，例如它们只是针对任务分布的不同子集。 使用这个框架，我们可以考虑支持和反对各种调和不同证据来源方式的证据。例如，在我们能对模型采样数百或数千条轨迹的环境中（我们的开发者通常不尝试这样做），我们的RCT结果相关性较低。也可能对于像Cursor这样的AI工具存在强学习效应，只有在数百小时的使用后才会显现——我们的开发者通常只在研究前和研究期间使用Cursor几十个小时。我们的结果还表明，在质量标准非常高，或有大量隐含要求（例如文档、测试覆盖、代码检查/格式化相关）需要人类花费大量时间学习的环境中，AI能力可能相对较低。 另一方面，基准测试可能高估模型能力，因为它们只测量了范围明确、可算法评分的任务。现在我们有了强有力的证据表明，关于提速的轶事报告/估计可能非常不准确。 没有一种测量方法是完美的——人们希望AI系统完成的任务是多样化、复杂且难以严格研究的。方法之间存在有意义的权衡，继续开发和使用多样化的评估方法以形成更全面的当前AI状态及未来方向的图景将非常重要。 ### 未来方向 我们很高兴在未来进行类似版本的研究，以跟踪AI带来提速（或减速）的趋势，尤其是因为这种评估方法可能比基准测试更难以作弊。如果AI系统能在我们的环境中显著加速开发者，这可能标志着AI研发进展的普遍快速加速，进而可能导致扩散风险、保障和监督失效，或权力过度集中。³（https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/#fn:3）这种方法为基准测试提供了互补证据，专注于真实部署场景，这有助于我们更全面地理解AI能力和影响，而不仅仅是依赖基准测试和轶事数据。 **联系我们！** 我们正在探索在其他环境中进行此类实验——如果您是开源开发者或公司，有兴趣了解AI对您工作的影响，请联系我们（https://forms.gle/pBsSo54VpmuQC4CK9）。 **更新：** 2026年2月，我们发布了关于2025年底AI工具生产力影响的新数据（https://metr.org/blog/2026-02-24-uplift-update/）。 ### 常见问题 **既然开发者在有AI的情况下可以选择不使用它，他们实际上是如何被减速的？** 研究结束后，开发者估计在使用AI时平均提速了20%——因此他们对AI对生产力的影响判断有误。此外，开发者使用AI工具可能是出于生产力以外的原因——例如，他们可能觉得使用AI更愉快/享受，或者将其视为对学习技能的投入，期望在未来（更强大的）系统中这些技能会有用。 **这项研究的动机是什么？我们是否有动机/激励去发现这个结果？** METR是一个非营利组织（由捐款资助），致力于了解AI系统距离加速AI研发过程有多近，这可能带来重大的不稳定风险¹（https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/#fn:1）。 本研究旨在为我们提供关于类似领域的证据：经验丰富的开源开发者在他们高度熟悉的项目上工作。我们最初大致预期会看到积极的提速——科学诚信是我们的核心价值观，我们（过去和现在都）致力于无论结果如何都分享发现。 **你只有16名开发者，因此这些结果不会泛化或可复制。** 我们通过使用聚类标准误（在已发布的论文中未报告，但即将提供）来计算考虑了开发者数量的置信区间。由于我们没有观察到有意义的开发者内部结构，且每个开发者都在两种条件下完成问题，总共246个已完成的（恰好）赋予了我们足够的统计功效，以拒绝零提速/减速的零假设。关于我们实证策略的讨论请参见附录D（https://arxiv.org/pdf/2507.09089#page=27）。 代表性仍是一个问题——即参与研究的开发者可能存在偏差。例如，可能有一些经验丰富的开源开发者决定不参与，因为他们相信自己能通过AI获得显著的积极提速，并且不希望被强制在50%的任务中不使用AI。没有开发者报告认为如此，但我们不能排除这种（或其他抽样偏差）可能性。 **开发者是Cursor/AI工具的初学者吗？这能解释结果吗？** 开发者似乎从性质上符合Cursor Pro用户的分布，尽管我们不能排除超过50小时Cursor使用后的学习效应。几乎所有开发者都有大量的（几十到几百小时）先前提示LLM的经验。参见附录C.2.7（https://arxiv.