💬 NLP

Evaluating LLMs on Real-World Software Performance Optimization

本文介绍了 SWE-Pro，这是一个源自 102 项专家级优化的严谨仓库级基准测试，它揭示了当前的大型语言模型在现实世界软件优化方面显著无法达到人类水平，与专家工程师所实现的实质性加速和内存减少相比，其取得的收益微乎其微。

原作者： Ezgi Sarıkayak, Wenchao Gu, Hesham Ghonim, Chunyang Chen

发布于 2026-06-25

📖 1 分钟阅读☕ 轻松阅读

原作者： Ezgi Sarıkayak, Wenchao Gu, Hesham Ghonim, Chunyang Chen

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

大局观：“速效厨师” vs. “大师级厨师”

想象一下，你经营着一家规模庞大、繁忙的餐厅厨房（一个现实世界的软件代码库）。你雇佣了一支 AI 厨师团队（大语言模型或 LLM）来协助 大师级厨师（人类专家）让烹饪速度更快、消耗更少的能量。

大师级厨师非常清楚如何高效地切菜、如何通过整理储藏室来节省步骤，以及如何调整炉火温度以节省燃料。他们拥有多年的经验。

AI 厨师非常聪明。他们能读懂食谱，理解食材，甚至能写出在纸面上看起来完美的全新食谱。但本文提出的核心问题是：这些 AI 厨师真的能在现实世界中让厨房运行得更快、更省能耗吗？还是说，他们只是让事情看起来变好了，但实际上并没有提升速度？

问题所在：旧的测试太简单了

以前，研究人员通过给 AI 厨师布置一个微小的单一任务来测试他们，比如：“切这一根胡萝卜。”

缺陷： 在真实的厨房里，你不仅仅是切一根胡萝卜。你会切 10 根、1,000 根甚至 100,000 根。有时候胡萝卜是湿的，有时候是冻上的。
结果： 旧的测试就像是在一个安静的房间里评判一位厨师切单根胡萝卜的能力。它们没有测试这位厨师是否能在有 1,000 个订单的繁忙高峰期应对自如，或者是否在追求速度的同时不小心使用了过多的水（内存）。

本文认为，这些旧的测试过于简单，无法捕捉到真实计算机中发生的“噪声”（随机波动）。

解决方案：SWE-Pro（“真实厨房”模拟器）

作者构建了一个更难的新测试，名为 SWE-Pro。你可以把它看作是一个高科技模拟的、混乱的真实厨房。

真实的食谱： 他们没有编造虚假任务。他们研究了 102 个真实的案例，在这些案例中，人类专家成功优化了著名开源项目（如 pandas、scikit-learn 和 xarray）中的代码。这些是“金标准”食谱。
压力测试： SWE-Pro 不仅仅测试 AI 在一种输入下的表现，而是测试他们在许多不同场景下的表现。
- 类比： 这不仅仅是“切 10 根胡萝卜”，而是“切 10 根”、“切 100 根”、“切 10,000 根”，并且要处理湿胡萝卜、冻胡萝卜以及不同大小的胡萝卜。
噪声过滤器： 计算机是很杂乱的。有时程序运行慢仅仅是因为计算机当时正在处理其他事情（比如服务员掉落了一个托盘）。SWE- پرو 对测试进行了多次运行，并使用了一种特殊的统计“噪声过滤器”，以确保如果 AI 声称“我更快了”，那确实是真的，而不是仅仅因为运气好。
两个指标： 他们测量两件事：
- 速度： 食物上菜的速度（运行时间/Runtime）。
- 内存： 厨师使用了多少台面空间和存储空间（峰值内存和时间加权内存使用量）。

结果：AI 厨师陷入苦战

当他们让顶尖的 AI 模型（如 GPT-5.2、Claude Sonnet 4.6 等）接受这种严苛的“真实厨房”测试时，结果令人惊讶且令人失望。

人类专家（金标准）： 当人类优化代码时，他们实现了巨大的改进。
- 类比： 大师级厨师将烹饪时间缩短了 15 倍，并将所需的台面空间减少了 171 倍。他们找到了巧妙的方法来重新布置厨房，从而节省了大量的资源。
AI 厨师：
- 速度： AI 模型几乎没有任何改进。在大多数情况下，它们的“改进”微乎其微，甚至无法与随机噪声区分开来。
- 内存： AI 模型几乎从未实现过节省内存。在这一领域，它们几乎不存在。
- “无信号”问题： 即使 AI 写出的代码通过了基础测试（食物味道是对的），它也极少能产生可衡量的加速效果。这就像是一位厨师虽然把胡萝卜切得很整齐，但花费的时间和之前完全一样。
- 倒退： 有时，AI 甚至会让事情变得更慢。其中一个模型（GPT-5.2）平均竟然让代码变慢了 30%！

核心启示

本文的结论是，虽然 AI 擅长编写看起来正确且符合规则的代码，但它目前非常不擅长处理实现软件显著提速或降低内存消耗所需的深度、复杂工程。

差距： AI 目前的能力与资深人类工程师的能力之间存在巨大的鸿断。
瓶颈： 问题不在于 AI 如果运气好能不能做出巨大的改进（它确实偶尔可以做到），而在于 AI 无法可靠地发现这些改进的机会。

简而言之： 如果你要求 AI “让这个软件更快”，它可能会写出一个看起来很漂亮的补丁，但不要指望它真的能提升你的电脑速度或节省你的内存。目前，这项工作仍属于人类专家。

技术摘要：SWE-Pro —— 评估大语言模型在真实世界软件性能优化中的表现

1. 问题陈述

软件性能优化是一项复杂的、人工驱动的工程任务，其特点是具有多维度的权衡（例如，运行时间 vs. 内存）以及对执行环境和输入数据的极高敏感性。尽管大语言模型（LLMs）在代码生成和错误修复方面已展现出熟练能力，但其在仓库级性能优化方面的能力仍未得到充分评估。

现有的基准测试存在以下关键局限性：

过度简化： 许多基准测试侧重于孤立的函数（如 EffiBench）或单一的固定工作负载，未能捕捉到真实世界代码库的复杂性。
指标缺陷： 当前的框架通常仅评估运行时间，忽略了内存使用情况以及优化过程中至关重要的时空权衡（time-memory trade-offs）。
测量噪声： 基准测试频繁依赖固定次数的剖析（profiling）或粗粒度的聚合，这掩盖了特定输入的性能波动，并且无法将真实的增益与环境噪声（如调度器抖动、缓存效应）区分开来。
缺乏统计严谨性： 缺乏采用自适应测量和统计收敛性的基准测试，以确保观察到的改进是可复现且显著的。

因此，目前尚不清楚当前的大语言模型是否能够驾驭真实世界软件的复杂性，以提供稳健且专家级的优化方案。

2. 方法论：SWE-Pro 基准测试

为了解决这些差距，作者引入了 SWE-Pro，这是一个从三个主要的开源 Python 数据库——pandas、scikit-learn 和 xarray 中提取的 102 个专家编写的优化案例组成的仓库级基准测试。

2.1 数据集构建

来源： 合并了明确标记为性能相关、并在变更日志或文档中得到开发者确认的拉取请求（PRs）。
验证： 通过人工检查确保任务具有可复现性、涉及 Python 源代码修改，并代表了真实的优化机会。
金标准（Gold Standard）： 每个任务都包含原始代码库、专家编写的补丁（金标准解法）以及一组参数化性能测试。

2.2 参数化性能测试

与使用固定输入的基准测试不同，SWE-Pro 采用结构化参数扫描来评估不同工作负载下的性能。

维度： 测试通过改变输入规模、数据分布（稀疏性、重复性）、数据类型和函数级配置来进行。
工作负载生成： 通过笛卡尔积组合参数以生成执行配置（每个任务的中位数为 6 个，最高可达 24 个），从而确保评估能够捕捉优化在不同条件下是如何泛化或退化的。

2.3 可靠测量框架

SWE-Pro 实现了一个分层、具备噪声感知能力的测量流水线，以确保统计显著性：

自适应迭代： 系统不再使用固定次数，而是根据 90% 相对置信区间宽度（RCIW） 的收敛情况动态确定测量迭代次数。
分层噪声建模： 该框架通过在全新的 Docker 实例中执行工作负载，同时考虑了容器内噪声（调度器抖动、解释器行为）和跨容器噪声（CPU 状态、内存布局）。
信噪比（SNR）： 只有当性能提升超过噪声感知阈值（SNR ≥ 2）时，才被视为有效的改进。
多指标评估： 基准测试追踪三个不同的指标：
- 运行时间（Runtime）： 执行时间。
- 峰值内存（Peak Memory）： 高于基准线的最大内存占用。
- 时间加权内存使用量（TWMU）： 一个整合了随时间变化的内存压力的归一化指标，计算公式为 $\bar{m}_{twmu} = \frac{1}{T} \int_0^T \max(0, m(t) - m_{base}) dt$ 。

2.4 实验设置

模型： 评估了六种最先进的大语言模型（GPT-5.2, Claude Sonnet 4.6, Kimi K2.5, Gemini 3.1 Flash-Lite, GLM-5.1, MiniMax M2.7）。
上下文策略： 模型在两种检索条件下进行测试：
- Oracle（预知型）： 直接提供 ground-truth 相关文件。
- BM25： 通过基于词法相似性的方式从仓库状态中检索上下文。
评估指标： 补丁成功率（适用性）、功能正确性（测试通过率）以及通过工作负载调和平均值计算的性能提升因子（IF）。

3. 关键结果

评估结果揭示了当前大语言模型能力与专家级工程水平之间存在的巨大差距。

3.1 补丁生成与正确性

适用性： 在 Oracle 检索模式下，补丁应用率在 30.4% 到 97.1% 之间。
正确性： 即使补丁应用成功，功能正确率也显著较低（18.6% 至 79.4%），这表明大语言模型经常产生语法正确但语义错误的逻辑。
检索影响： 在 BM25 检索模式下，性能进一步下降，凸显了优化任务对上下文质量的高度敏感性。

3.2 性能优化能力

运行时间： 大语言模型难以产生可测量的运行时间收益。
- 只有极小比例的任务通过了 SNR 过滤器（例如，在 Oracle 模式下，Gemini 3.1 Flash 的通过率为 12.7%）。
- 提升幅度微乎其微（例如，表现最好的模型 IF 仅为 1.27×），相比之下，金标准解法的加速比达到了 15.48×。
- 部分模型（如 GPT-5.2）生成的补丁反而导致了性能下降（IF < 1）。
内存优化： 大语言模型在内存优化方面的能力几乎不存在。
- 所有模型在峰值内存和 TWMU 方面的改进都基本缺失。
- 唯一的显著例外是 Claude Sonnet 4.6 在单个实例（PR #7578）上的表现（在 Oracle 模式下分别实现了 16.61× 峰值内存和 28.82× TWMU 的提升；在 BM25 模式下 TWMU 提升达 3556×）。然而，这些收益并未在不同任务间泛化。
- 与之形成鲜明对比的是，金标准解法在 55.9%–70.6% 的任务中实现了 171.31× 的峰值内存缩减和 619.22× 的 TWMU 缩减。

3.3 工作负载敏感性

研究强调了优化的有效性高度依赖于输入。例如，在 PR #7578 中，运行时间的改进随输入规模显著扩大（对于大规模工作负载可达 100×），而内存改进保持稳定。这强调了参数化测试的必要性，因为单一输入的基准测试会遗漏这些关键行为。

4. 意义与贡献

本文声称了以下贡献：

SWE-Pro 基准测试： 一个全面的、仓库级的基准测试，包含 102 个经专家验证的任务及参数化测试，旨在将评估转向稳健的、感知工作负载的分析。
噪声感知框架： 一个利用自适应采样、分层噪声建模和 SNR 过滤的新型测量流水线，用以区分真实的优化与环境方差。
多指标洞察： 首个系统性研究了运行时间、峰值内存和 TWMU 的联合评估，揭示了当前大语言模型无法有效处理时空权衡的问题。
对局限性的实证证据： 研究结果暴露了一个“巨大的差距”：尽管大语言模型在局部逻辑细化方面表现出色，但在实现真实场景下的可衡量效率增益方面却表现乏力。研究认为，主要瓶颈不在于潜在改进的幅度，而在于能否可靠地识别优化机会本身。

作者总结道，虽然大语言模型在特定、孤立的案例中展现出潜力，但它们目前仍缺乏进行专家级性能工程所需的系统性推理能力，这需要未来针对能够驾驭复杂、多指标优化景观的模型开展研究。SWE-Pro 数据集和评估流水线已开源，以支持进一步的社区研究。