SWE-bench：真实仓库问题的代码修复基准¶

原文链接： SWE-bench: Can Language Models Resolve Real-World GitHub Issues? [88]

论文信息¶

年份：2023 [88]
作者：Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik Narasimhan [88]
作者背景（研究领域）：软件工程评测/代码修复 [88]
前后血缘关系（同主题）：前序：无（真实代码修复评测代表）；后续：SWE-agent

主旨¶

SWE-bench 的主旨是用真实 GitHub issue 评测模型解决实际软件工程问题的能力。论文强调，真实仓库带来的上下文复杂度、依赖关系与测试约束，是衡量代理能力的关键因素。[88]

背景与问题定义¶

论文针对代码生成评测过于合成化的问题：许多基准无法反映真实工程中的依赖与测试约束。作者选择真实 issue 与真实仓库作为评测基准，旨在衡量模型在“真实工作流”中的实际效用。[88]

方法与机制¶

论文收集并整理真实仓库中的 bug 报告与修复提交，构建可复现的任务集。每个任务包含问题描述、代码库与测试验证，模型需要生成修改以通过测试。评测以测试通过率为主，强调与真实开发流程一致的验证方式。[88]

实验与结果¶

作者评估了多种模型在 SWE-bench 上的表现，发现真实工程问题远比合成任务更难。失败原因多集中在上下文理解不足、修改范围不准确或依赖处理错误。实验揭示了模型在真实软件工程场景中的系统性短板。[88] 论文还强调，许多失败并非因为代码生成能力不足，而是对仓库结构和测试语义理解不够。这表明在工程场景中，工具辅助的代码检索、测试理解与上下文管理同样关键。[88]

关键数据结果¶

SWE-bench 由 2,294 个真实 GitHub Issue/PR 任务构成，并保证每个实例至少包含 1 个 fail-to-pass 测试。[88]
Claude 2 是最强基线，使用 BM25 检索时仅解决 1.96% 的问题。[88]
40% 的实例至少包含 2 个 fail-to-pass 测试，用于提高评测鲁棒性。[88]

工程启示（优化点）¶

评测必须依赖真实测试套件，保证修复可验证。
需要稳定的代码检索与导航能力，避免遗漏关键文件。
将修改范围控制在最小可行范围，减少副作用。
对失败任务进行分类，形成针对性的改进策略。
把失败案例沉淀为回归集，持续跟踪进步。

局限与延伸¶

SWE-bench 的任务覆盖仍受限于开源仓库，不能完全代表工业级复杂系统。测试本身也可能不完备，甚至存在脆弱或波动的问题，影响评测稳定性。还需要更全面的失败归因体系，不同仓库的构建环境差异也会影响结果。延伸方向包括：扩展到更复杂的企业代码库、引入多语言与多框架任务、建立更健壮的验证协议，以及结合交互式调试与工具增强。[88]