当前AI编程智能体的基准测试大多回避大规模重构场景;新测评显示即使最强模型在大规模重构任务上解决率仅41.2%,揭示了现有评测体系的重大盲区。
AI coding agent 在大规模重构方面仍然表现吃力,在由上海交通大学、北京大学、抖音集团及其他机构的研究人员开发的一个新的以重构为重点的基准测试中,最佳模型仅达到了 41.2% 的解决率。
AI 基准测试并不完美,这已经不是秘密。研究人员引用的一项最新审计显示,AI coding agent 基准测试可能具有误导性——SWE-bench Verified 中近 60% 未解决的实例包含有缺陷的测试。
"我们还没有能够阅读大型代码库、一次性完整查看并'理解'它的 LLM,"他说道,"这种能力水平仍然遥不可及。"
对于 AI coding agent 来说,评估质量被认为正在下降,因为前沿模型如果解决方案泄露到训练集中,最终可能轻松通过基准测试。但是,当模型能够在没有真正完成所有工作的情况下获得看似惊人的分数时,这就引出了一个问题:这些基准测试是否真的能够准确反映真实世界 agent 的能力。
正如 SUSE 技术策略高级总监、核心基础设施负责人 Vojtěch Pavlík 告诉 The New Stack 的那样,许多备受期待的能力仍然任重道远:
"我们还没有能够阅读大型代码库、一次性完整查看并'理解'它的 LLM,"他说道,"这种能力水平仍然遥不可及。"
一个新的基准测试试图澄清这一问题。SWE-Bench ProMax 是一个多语言代码重构基准测试,包含来自七个编程语言(Python、Java、TypeScript、Go、C、C++ 和 Rust)真实提交的 170 个实例。据其创建者介绍,每个实例都经过多阶段筛选,以解决其他基准测试中存在的质量问题:他们编写了更精确的 issue 描述;手动审查测试套件,移除过于狭窄或宽泛的测试;并过滤掉复杂度不足或跨文件范围有限的任务。
结果是,这个基准测试让前沿模型也难以攻克。
通过将 SWE-Bench ProMax 聚焦于大规模重构,研究人员表示,这个新基准测试"为当前 AI coding agent 提出了一个有意义且尚未被攻克的挑战"。
这是因为重构本身就很难。"严格的重构要求零容错、零容忍行为变化,以及完全可逆性,"ActiveState 首席架构师 Shane Warden 告诉 The New Stack。在他看来,当前 AI 工具能否成功处理大规模重构,取决于源代码是被视为普通散文还是确定性、结构化的信息图:
"我不相信这个前提。我认为 token 相邻性并不能保证结构性理解。"
"将 LLM 主要视为文本处理引擎的工程师们把重构当作文本生成任务,"他解释道,采用这种方法的开发者会将整个代码库输入到一个大上下文窗口中,提示模型,然后等待一系列多文件 diff。
但他并不认同这种观点。"这种方法依赖于当前 LLM 表达对大型系统深刻理解的前提,"Warden 继续说道。"我不相信这个前提。我认为 token 相邻性并不能保证结构性理解。"
Pavlík 提出了另一个问题,他说注意力——或者说注意力的缺失——同样让大规模重构变得复杂:
"对于非常大的 LLM来说,比如 DSA [Deepseek Sparse Attention] 及其类似的高度优化注意力算法,基本上是获得任何可用性能的必要条件,"他说道。"对于在最大化了上下文窗口的大型、复杂或混乱的代码库中进行更改,这很容易导致遗漏重要观察,总体上陷入困惑。"
除了上下文和注意力的困扰,Pavlík 还指出,时间是软件中的一个基本因素,进一步困扰着 LLM,他指出竞态条件错误、幂等性丧失、原子性丧失,以及不正确的重试处理等问题——这些问题在并行任务以不同顺序执行时就会出现,即他所说的"代码与时间相遇的地方"。
"人类生活在基于时间的世界中,"他说道。"LLM 则不太是这样。你的代码通过了所有测试,在用户完全按照合同/清单/规范中描述的任务执行时运作良好,但当用户快速连续点击按钮两次时、当网络连接超时时、或者当两个任务几乎同时完成并相互覆盖结果时,代码就会惨败。"
考虑到所有这些因素,很容易理解为什么许多基准测试忽略大规模重构——但这正是它们需要它的原因。如果没有对复杂跨文件工作的测试,开发者如何判断 agent 真正能做什么?
大多数 coding agent 基准测试的设计目标是快速运行并产生相当确定性、可验证的解决方案。"这排除大规模重构任务,"Pavlík 告诉 The New Stack。
他还说,这就是为什么当今大多数 LLM 基准测试都有缺陷,因为它们通常只在模型表现最佳的短上下文中测试模型。此外,"许多当前的前沿 LLM 现在已经能凭记忆答出大多数常见基准测试的答案,"Pavlík 补充道。"基准测试越普及,结果就越不可靠。"
有了这个新的以重构为重点的基准测试,Pavlík 将其视为测试正变得更加复杂、不再容易被预先学习,从而更好地暴露 agent 困境的信号:
"SWE-Bench ProMax 展示了基准测试的发展方向,从'我们需要衡量 LLM 有多好'的方法转向'我们需要 LLM 在特定任务上改进'的方法。"
建立一个能够识别 agent 性能缺口的基准测试是一回事。但要弥补这些缺口需要什么?
Pavlík 呼吁采用多层方法:开发者首先分析并映射代码库以创建详细规范,使用检索增强生成来回忆代码的相关部分,而不是纯粹依赖注意力,并让人类参与验证。他还建议在开始重构之前,为原始代码库实现一套完整的详细测试套件,以确保其正确性。
Warden 提出了类似的想法:"对我来说,最有前景的研究专注于 LLM 驱动确定性、结构感知的开发者工具,而不是 LLM 输出原始多文件 diff。"
他描述了一种架构:LLM 识别代码异味、评估设计权衡、查询语言服务器协议(LSP)和代码图工具来分析显式代码结构、依赖关系和数据流,发出小的、零熵命令来执行更改,并在测试失败时回滚这些更改。
基准测试永远无法完美地衡量真实世界性能,但忽略重构等困难任务会给 agent 能力描绘一个过于乐观的画面。SWE-Bench ProMax 也许能带来一些现实主义。