SWE-fficiency: Can Language Models Optimize Real-World Repositories on Real Workloads?
该论文介绍了 SWE-fficiency，这是一个包含 498 个真实世界仓库任务的基准测试，旨在评估语言模型在保持正确性的同时优化代码性能的能力，并揭示了当前最先进的智能体在定位瓶颈和在复杂代码库中进行推理方面，其表现显著低于人类专家。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你拥有一个庞大且极其复杂的软件代码库（就像那些驱动数据科学和人工智能的代码库一样）。在这个库中，有一些特定的任务运行得非常缓慢，就像一位图书管理员必须通过逐一走遍每一个书架来寻找一本书。
这篇论文引入了一个新的挑战，叫做 SWE-FFICIENCY。你可以把它想象成一场针对 AI 智能体的“速通比赛”（speed-running competition）。目标不仅仅是修好一个坏掉的书架（这是大多数以往 AI 测试关注的重点）；目标是重新组织图书馆，让图书管理员找书的速度提高两倍，同时又不能意外丢失任何书籍或改变图书馆的规则。
以下是研究人员所做的工作以及他们的发现，使用了简单的类比：
1. 问题所在：AI 擅长修复，但不擅长提速
目前的 AI 编程助手大多被训练成“机械师”，专门修理坏掉的汽车。如果车发动不起来，他们能找出原因并修复它。但本论文提出了一个问题：这些 AI 机械师能否也成为“赛车工程师”，在不弄坏汽车的前提下，将引擎调校得快 50%？
研究人员发现，虽然 AI 在修复漏洞方面做得越来越好，但目前在让代码运行得更快方面表现得很糟糕。
2. 测试：现实世界的“障碍赛”
为了测试这一点，作者利用来自著名软件库（如 pandas、numpy 和 scipy）的 498 个真实世界任务构建了一个巨大的障碍赛场。
- 设置： 他们给了 AI 一个完整的代码库和一个特定的“慢速任务”（例如一个处理时间很长的重型工作负载）。
- 规则： AI 必须编写一个补丁（代码修复方案），使该任务运行得更快。
- 难点： AI 必须通过严格的“安全检查”。它不能仅仅为了让某一个特定的测试运行变快而对代码进行“黑盒式”修改；它必须确保代码在处理该库中的所有其他测试时依然能正确运行。如果 AI 搞坏了整个库，它就算失败。
这就像要求一位厨师让汤煮得快 10 倍，但他们不能把食谱改得太离谱，以至于汤喝起来像洗碗水或者烧毁了厨房。
3. 结果：AI 仍在学习驾驶
结果令人深思。研究人员将 AI 的表现与人类专家（最初编写这些加速方案的“金标准”工程师）进行了对比。
- 得分： 平均而言，AI 智能体仅实现了人类专家所能达到的加速效果的 23%。
- 类比： 想象一下，人类专家可以将 10 分钟的通勤时间缩短到 2 分钟。而 AI 平均只能将其缩短到 8 分钟。
- 错误类型：
- 目标错误： AI 经常尝试加速代码中错误的部位。这就像试图通过抛光轮胎来修理一辆慢车，而真正的难题其实在引擎上。
- “快速修复”陷阱： AI 喜欢使用“捷径”。它们会添加一些临时性的补丁（比如记住特定测试的答案），这使得某一个测试运行很快，但如果输入稍有变化，就会失效。而人类专家则会寻求深层的、结构性的改变，从而让整个系统更加高效。
- 过早放弃： 当 AI 发现一个微小的提速效果时，它往往会停在那里，满足于一个“足够好”的结果，而人类专家则会不断挖掘，以找到最佳的加速方案。
4. 为什么这很重要
论文指出，我们不能仅仅依赖 AI 来修复漏洞了。随着计算机变得越来越昂贵且耗能，我们需要运行效率更高的软件。
研究人员创建了这个基准测试（SWE-FFICIENCY），旨在向世界展示：目前的 AI 能力与成为一名真正的“性能工程师”之间还存在着巨大的差距。他们发布了所有的相关数据和工具，以便其他研究人员可以尝试缩小这一差距。
简而言之： AI 目前是一个优秀的“漏洞粉碎者”，但却是一个很差的“速度优化器”。它需要学会如何观察全局，并进行深层的、结构性的改进，而不是仅仅应用肤浅的、表面的补丁。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。