SWE-bench (benchmark) — 软件工程基准

From Systems analysis wiki
Jump to navigation Jump to search

SWE-bench 是一个大规模的基准测试（测试任务集），用于评估大型语言模型（LLM）在自动化软件开发和调试领域的能力[1]。它由普林斯顿大学等机构的研究人员开发，并在 ICLR 2024 会议上提出[2]。SWE-bench 与传统的代码基准测试不同，它使用来自真实开发实践的真实任务：测试集包含 2294 个任务，这些任务基于 GitHub 上 12 个流行的开源 Python 仓库中已关闭的问题 (issues) 和相应的修复 (pull requests)[1][3]。每个任务都包含问题描述 (issue)，并为模型提供对相应项目源代码的访问权限；模型的目标是生成对代码库的最小更改（补丁），以修复指定的问题[1][3]。

评估方法与特点

SWE-bench 模拟了真实的软件开发过程。对于每个任务，模型会接收到原始 GitHub issue 的文本（问题描述）以及在进行修复之前版本的代码仓库快照[4]。模型（或基于模型的智能体）需要分析源代码，理解错误的性质或所需的更改，并对相关代码文件进行编辑以解决问题[4][5]。解决方案验证是自动化的：每个任务都关联了来自关闭该问题的 pull request 中的真实单元测试。这些测试包括“失败-通过”测试（fail-to-pass，即在原始代码上失败，但在应用正确修复后应通过的测试）和回归测试（pass-to-pass，即最初通过且在进行更改后应继续通过的测试）[3]。模型提出的补丁会应用于代码，然后运行相应的测试：如果所有 fail-to-pass 测试都开始通过，并且 pass-to-pass 测试没有被破坏，则任务被视为已正确解决[3]。这种评估方法不仅能检验模型生成语法正确的代码的能力，还能检验其在不破坏现有功能的情况下真正解决问题的能力。同时，模型必须处理庞大的上下文（整个代码仓库），理解组件之间的相互关系，并协调多个文件中的更改[1]——所有这些都比根据描述编写函数的典型任务要复杂得多。

在 SWE-bench 的评估中，参与的通常不仅仅是 LLM 本身，而是智能体系统，这些系统为模型封装了辅助工具（例如，用于文件导航、代码执行、调试器使用等）[4][6]。这样的系统模仿了真实的开发周期：模型可以依次查看文件、运行测试或脚本，并逐步改进解决方案，直到成功为止[4]。值得注意的是，解决 SWE-bench 任务的效率在很大程度上取决于这种“脚手架”（智能体基础设施）的质量：同样的基础模型，根据与代码仓库和工具的交互方式不同，可能会表现出不同的结果[4][7]。因此，SWE-bench 不仅衡量模型本身的能力，也衡量模型及其解决问题策略的综合能力，使评估更接近自主 AI 开发者的真实工作环境[4][7]。

任务集变体

SWE-bench 的作者和社区后续发布了几个衍生数据集，用于不同的评估目的：

  • SWE-bench Lite — 该基准测试的轻量级版本，包含约 300 个任务[8]，这些任务经过筛选，旨在降低测试模型的复杂性和计算成本。该子集用于快速进行模型实验，排除了最耗时的验证，同时保持了主要问题的代表性[7]。实质上，Lite 版本包含更简单、更短的错误修复任务，因此模型在 Lite 上的表现通常优于完整数据集，因为它排除了最复杂的案例[7]。
  • SWE-bench Verified — 于 2024 年 8 月与 OpenAI 联合发布的一个经过人工验证筛选的子集[7]。研究人员邀请了93 名专业开发人员对原始基准测试中的每个任务进行分析，并排除了那些问题描述过于模糊或测试要求的行为无法从任务条件中明确推断的案例[7]。此外，还移除了因环境问题或测试不正确而实际上无法解决的任务[7]。最终形成了一个包含500 个任务的数据集，这些任务保证是可解且表述正确的[7]。SWE-bench Verified 旨在提供更可靠的模型能力评估，消除了那些即使是正确的解决方案也会因测试或任务本身不当而被拒绝的情况[7]。该数据集已取代原始的 SWE-bench 测试集（完整版和 Lite 版），成为比较模型的主要基准[7]。此外，随着 Verified 的发布，还公布了任务的难度评估（例如，区分了“简单”任务，即人类在 <15 分钟内可解决的任务，和“困难”任务，即需要 >1 小时的任务）[7]，并发布了一个基于 Docker 的新工具框架，以实现更稳定和可复现的测试运行[7]。
  • SWE-bench Multimodal — 于 2025 年 1 月推出的基准测试扩展，包含问题描述中不仅有文本，还包含视觉元素（例如，界面图片、错误截图等）的任务[8]。该数据集（517 个任务[8]）用于测试模型和智能体在解决编程任务时理解和使用视觉信息的能力。对多模态数据集的评估方式类似，但要求模型具备多模态能力（例如，识别图像中的文本）。SWE-bench Multimodal 的测试部分保持非公开（隐藏），以防止针对已知答案进行过拟合；开发者可以将其解决方案提交到远程排行榜，以评估其模型在这些任务上的表现[2]。

除了这些主要变体之外，围绕 SWE-bench 还形成了一个工具生态系统：SWE-agent — 一个开源的“智能体”求解器，在基准测试任务上展示了领先的成果[2]；SWE-smith — 一个用于训练自定义开发者模型的框架；SWE-REX — 一个用于从仓库中进行扩展信息提取和处理的工具等。这些项目旨在简化结果的复现，并推动自主编程系统领域的研究。

模型结果与进展

SWE-bench 刚出现时，揭示了现代 LLM 与经验丰富的程序员技能之间的巨大差距。作者报告称，即使是 2023 年初最强大的模型也只能解决百分之几的任务：例如，Anthropic 公司的 Claude 2 模型在完整数据集上成功解决的任务不到 2%[1]。由基准测试作者专门训练的模型（基于 LLaMA，命名为 SWE-Llama）以及 GPT-4 等专有模型主要只能解决最简单的错误[1]。这些最初的低指标凸显了 SWE-bench 的难度，并激励了新方法的开发。

在 2024 年期间，随着更先进的模型和智能体方案的出现，结果显著改善。普林斯顿大学的研究人员推出了 SWE-agent 系统，该系统将 GPT-4 与代码搜索、规划和其他工具相结合，在完整数据集上解决了约 12.5% 的任务，为学术模型树立了新的标杆[5]。到 2024 年中，SWE-bench 官方排行榜上的最佳解决方案（包括专有方案）在完整基准测试上实现了约 20% 的成功率，在简化的 Lite 数据集上则高达 43%[7]。这种增长与模型的改进（例如 GPT-4、Claude 2 和 3 的出现）有关，尤其得益于“脚手架”——即外部策略的发展，这些策略使模型能有效地将任务分解为步骤、阅读文档、运行调试会话等[7]。

在 2024 年底引入 Verified 数据集（清除了不正确的任务）后，可测量的性能进一步提升。GPT-4 模型（GPT-4o 变体）立即在 Verified 上展示了约 33% 的成功率，而之前在原始数据集上约为 ~16%[7]。最好的开源智能体框架（如 Agentless）在 Verified 上的结果从 ~16% 翻倍至 32%[7]。这证实了原始基准测试因存在无法解决的案例而在一定程度上低估了性能的猜测[7]。同时，与 Lite 相比，Verified 上的结果提升并不那么显著（最佳模型在 Lite 上已达到约 43%），这是合乎逻辑的：Lite 最初筛选了较简单的示例，而 Verified 移除了无法完成的案例，但保留了复杂的任务[7]。值得注意的是，转向 Verified 后，性能提升发生在所有难度类别的任务中，而不仅仅是通过消除最困难的任务实现的——也就是说，筛选过程也清除了相对简单任务中隐藏的无法完成的案例[7]。

到 2025 年初，领先的 AI 系统在经过验证的数据集上已经表现出接近人类的效率，尽管距离 100% 的上限还很遥远。2025 年 1 月，Anthropic 公司宣布其新模型 Claude 3.5 Sonnet 与改进后的智能体结合，解决了 SWE-bench Verified 中 49% 的任务[4]，暂时位居榜首。大型科技公司和独立团队也积极参与该基准测试的非正式竞赛。例如，CodeStory 团队开发了一种多模型方法，通过枚举变体（“Midwit Agent”），在 Verified 上达到了创纪录的 62.2% 解决率（数据截至 2025 年初）[5][9]。据指出，为实现这一成果，不得不在模型推理阶段大幅增加计算资源消耗（所谓的推理时间扩展），通过运行多次解决尝试并筛选最佳结果[5]。另外，OpenAI 的资料中提到，一个实验性系统 GPT-03 在有足够计算规模的情况下，据称在 Verified 上成功突破了 70% 的门槛（非官方数据）[5]。然而，这些结果缺乏独立验证，如此高的指标更多是未来研究的指引，而非已达到的标准。

根据 Microsoft Research 的一项研究（2025），即使是最新的模型，在配备调试工具后，在 SWE-bench Lite 的错误修复任务中仍未突破 50% 的大关[6]。在该测试中，表现最好的是 Claude 3.7 Sonnet，解决了约 48.4% 的任务，而基于 GPT-4 (OpenAI 01) 的系统解决了约 30%，更轻量的 03-mini 模型仅解决了 22%[6]。这些结果强调，尽管进展迅速，但现代 AI 仍然逊色于经验丰富的程序员：对于人类来说，解决类似任务（在理解代码的前提下）并不困难，而模型常常无法有效应用调试工具，或因缺乏反映多步错误修复过程的训练数据而受限[6]。

局限性与前景

SWE-bench 已成为评估智能代码智能体的标准化平台，但研究也揭示了其一些局限性。主要问题是测试不完备：每个任务的验证测试集取自特定的 pull request，通常只包括在修复错误时被修改的单元测试[3]。正如浙江大学和斯图加特大学的一组科学家（Wang et al. 2025）的分析所示，忽略项目中的其他测试可能会掩盖某些解决方案的不正确性[3]。通过在完整的仓库测试集上重新验证解决方案，发现平均 7.8% 在 SWE-bench 中被标记为成功的补丁，实际上无法通过项目中的其他测试[3]。这导致“已解决任务”指标被高估了约 4-6 个百分点[3]。一个更微妙的情况是，生成的补丁通过了所有原始测试，但与开发人员的解决方案不等效，并且以非预期的方式改变了程序行为。通过生成额外的测试用例（PatchDiff 方法），研究人员发现，近 30% 的 AI 修复方案表现出与参考补丁不同的行为，而约 11% 是明确错误的，尽管现有测试未能发现[3]。因此，如果仅依赖于通过有限的测试集，模型的真实能力可能会被高估。SWE-bench 的创建者承认这一弱点，并强调基准测试应随着时间推移而发展：改进测试覆盖率，增加对不期望的副作用的检查，并扩大任务类型的范围[7]。发展此类评估工具是为迎接日益自主和强大的 AI 开发者出现做准备的重要组成部分，而 SWE-bench 的经验表明，必须密切关注基准测试的质量[7]。

SWE-bench 只是一个静态的任务集，并未涵盖编程的所有方面，但已成为比较代码模型的事实上的标准[3]。它被用于科学论文中以展示新方法和算法，也被工业研究团队用于评估旨在自动化编程的系统的潜力[3]。2023-2025 年间 SWE-bench 上的成绩持续增长，清晰地展示了 LLM 在解决实际开发任务方面的能力迅速提升。同时，它也作为一个难度标尺：即使接近 50-60% 的任务解决率，模型仍然距离完全取代人类还很遥远，尤其是在信息有限和需要对需求进行细致理解的情况下[4][7]。然而，进步并未停止——得益于 SWE-bench 等倡议，社区能够清楚地看到自己的目标和局限，并继续朝着创造一个能够像人类专家一样自主理解和修复代码的完整 AI 开发者的方向前进[4][7]。

链接

参考文献

  • Liang, P. et al. (2022). Holistic Evaluation of Language Models (HELM). arXiv:2211.09110.
  • Chang, Y. et al. (2023). A Survey on Evaluation of Large Language Models. arXiv:2307.03109.
  • Ni, S. et al. (2025). A Survey on Large Language Model Benchmarks. arXiv:2508.15361.
  • Biderman, S. et al. (2024). The Language Model Evaluation Harness (lm-eval): Guidance and Lessons Learned. arXiv:2405.14782.
  • Kiela, D. et al. (2021). Dynabench: Rethinking Benchmarking in NLP. arXiv:2104.14337.
  • Ma, Z. et al. (2021). Dynaboard: An Evaluation‑As‑A‑Service Platform for Holistic Next‑Generation Benchmarking. arXiv:2106.06052.
  • Goel, K. et al. (2021). Robustness Gym: Unifying the NLP Evaluation Landscape. arXiv:2101.04840.
  • Xu, C. et al. (2024). Benchmark Data Contamination of Large Language Models: A Survey. arXiv:2406.04244.
  • Liu, S. et al. (2025). A Comprehensive Survey on Safety Evaluation of LLMs. arXiv:2506.11094.
  • Chiang, W.-L. et al. (2024). Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference. arXiv:2403.04132.
  • Boubdir, M. et al. (2023). Elo Uncovered: Robustness and Best Practices in Language Model Evaluation. arXiv:2311.17295.
  • Huang, L. et al. (2023). A Survey on Hallucination in Large Language Models. arXiv:2311.05232.

注释

  1. ↑ 1.0 1.1 1.2 1.3 1.4 1.5 Jimenez, Carlos E. et al. «SWE-bench: Can Language Models Resolve Real-World GitHub Issues?». arXiv. [1]
  2. ↑ 2.0 2.1 2.2 «SWE-bench/SWE-bench». GitHub. [2]
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 Wang, Shuyang et al. «Are "Solved Issues" in SWE-bench Really Solved Correctly? An Empirical Study». arXiv. [3]
  4. ↑ 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 «Claude SWE-Bench Performance». Anthropic. [4]
  5. ↑ 5.0 5.1 5.2 5.3 5.4 Jain, Sulbha. «SWE Benchmark: LLM evaluation in Software Engineering Setting». Medium. [5]
  6. ↑ 6.0 6.1 6.2 6.3 Hatmaker, Taylor. «AI models still struggle to debug software, Microsoft study shows». TechCrunch. [6]
  7. ↑ 7.00 7.01 7.02 7.03 7.04 7.05 7.06 7.07 7.08 7.09 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20 7.21 7.22 «Introducing SWE-bench Verified». OpenAI. [7]
  8. ↑ 8.0 8.1 8.2 «SWE-bench Leaderboard». [8]
  9. ↑ «SOTA on swebench-verified: relearning the bitter lesson». Hacker News (Y Combinator). [9]
Retrieved from "https://systems-analysis.ru/int/index.php?title=SWE-bench_(benchmark)_—_软件工程基准&oldid=6043"