SWE-bench：2294 个真实 GitHub Issue 组成的 AI 编程基准测试，从数据到跑通的完整指南

SWE-bench2294 个真实 GitHub Issue 组成的 AI 编程基准测试从数据到跑通的完整指南【免费下载链接】SWE-benchSWE-bench: Can Language Models Resolve Real-world Github Issues?项目地址: https://gitcode.com/GitHub_Trending/sw/SWE-benchSWE-bench 是面向大语言模型的软件工程基准测试它从 12 个热门开源 Python 仓库收集了 2294 个真实 issue让模型根据 issue 描述和代码库现场写出修复补丁。项目还自带一套基于 Docker 的、可复现的评估框架。它把这个模型写代码行不行从一句口号变成了可以互相比较的具体分数。一个任务到底让模型干什么一个任务实例相当于给模型开了一张工单。工单里装着四样东西issue 描述problem_statement、某个提交base_commit时刻的完整代码快照、一个测试补丁test_patch以及两份测试清单——修复前应该失败的 FAIL_TO_PASS 和必须继续通过的 PASS_TO_PASS。每个任务还有唯一编号 instance_id格式是仓库-PR号比如 sympy__sympy-20590后面跑评估、查日志全靠它。数据集里其实还存着参考答案字段跑模型预测时当然要捂住眼睛不看。模型要交回去的是一张标准 diff 补丁不是一段解释也不是整文件重写而是哪个文件第几行改成什么。判分规则相当硬FAIL_TO_PASS 里的测试全部转绿且 PASS_TO_PASS 没有变红才算 1 分安装失败、补丁打不上、测试报错任何一步出问题都是 0。解释得头头是道和补丁差一点就对了都拿不到分唯一算数的是容器里跑出来的真实测试输出。整个过程像给实习生修 bug把 issue 和当时的代码交给他让他自己写再跑测试看结果——只是这个实习生是语言模型而这套流程会被重复跑几千次。数据从哪来可信吗基准数据的质量直接决定评估结果的可信度SWE-bench 的采集流程因此设计成三道关卡。第一道是抓取从 12 个热门 Python 仓库收集历史 PR要求代码里超过九成是 Python第二道是属性过滤PR 必须明确关联一个 issue并且自带测试第三道是执行过滤环境能装成功、PR 能通过全部测试才留下。进入数据集前还有一步双重验证在 base_commit 装好仓库先只打测试补丁跑一遍——FAIL_TO_PASS 应当失败证明 bug 真实存在再打上参考答案跑第二遍——应当全部通过证明任务可解。两步都成功实例才算合格。说白了数据集里未来的每一分都是先用标准答案验证过的。这套流程的完整脚本在 swebench/collect/ 目录里理论上可以拿到自己的仓库上复刻、构造新任务官方目前暂停了新实例创建相关的答疑动手前建议先读 采集流程说明。跑通第一次评估装好 Docker再敲 3 组命令前提是装好 Docker。官方建议的机器配置x86_64、至少 120GB 空闲磁盘、16GB 内存、8 核起步arm64 支持目前是实验性的。git clone https://gitcode.com/GitHub_Trending/sw/SWE-bench cd SWE-bench pip install -e .装完先做一次标准答案体检拿 sympy 的第 20590 号 issue 当样本用参考答案充当模型输出。打出来是 1 分说明镜像构建、补丁应用、测试解析这条链路全部正常。swebench eval verified --gold \ -i sympy__sympy-20590 \ --run-id validate-gold真正评模型时把预测结果整理成 JSONL 文件每行一个 JSON字段是 instance_id、model_name_or_path、model_patch补丁文本。然后swebench eval verified -p preds.jsonl --run-id my-run -j 8-j控制并行容器数官方建议别超过 min(0.75 × 核心数, 24)。评估日志写在当前目录的 logs/ 下汇总结果在 evaluation_results 里每个实例一个文件夹report.json 是判定结论test_output.txt 是测试完整输出patch.diff 是实际打上去的补丁翻分一目了然。老版本的python -m swebench.harness.run_evaluation调用方式也仍然兼容。有个容易踩的坑harness 按 run_id instance_id 缓存结果。同一个任务换个补丁重跑时记得换一个 run_id否则会直接复用上次的缓存。参数、日志字段和排错方法评估指南 里有完整说明。Docker每个任务为什么要关进容器 2294 个任务横跨 12 个仓库Python 版本、依赖、测试框架各不相同。不做隔离的话在我机器上能跑会成为评估的慢性病同样的补丁今天能过明天不能过没人说得清是模型退步了还是环境变了。SWE-bench 的答案是每个任务一个 Docker 镜像。容器里的完整步骤是按版本说明装好 base_commit 的仓库 → 依次打上测试补丁和预测补丁 → 运行测试脚本 → 解析日志判断通过与否全绿给 1 分任何一步失败记 0。日志解析器是内置的按语言区分覆盖 Python、Go、Java、JavaScript、Rust、Ruby、PHP、C 等。这个设计带来两个附带好处一是可复现结果不依赖评估者的机器跨团队对数字才有意义二是可审计分数有争议时打开该实例的 run_instance.log 就能看到 harness 每一步做了什么用swebench report还能跳过容器、直接对已保存的日志重新判分。镜像构建本身也有缓存层级--cache_level 可选 none/base/env/instance磁盘紧张时可以按需降低。数据集怎么选五个变体各管一摊 最常用的三个先说。Full 是完整基准2294 个实例用于论文级评估Lite 从中精选了 534 个适合快速迭代——目标如果是几天内跑通一版 agent 并看到分数变化从它开始最省力Verified 是 500 个由真实软件工程师逐个人工确认可解的实例带难度标签也是目前排行榜的主口径评估含金量最高。另外两个针对特定需求Multimodal 面向带 UI 截图的前端类任务100 个 dev 实例用于调试、500 个 test 实例用于正式评估测试集的答案字段是空的防止偷看Multilingual 覆盖 9 种语言、42 个仓库共 300 个实例适合考察跨语言迁移能力。所有数据集都能在 Hugging Face 上一行 load_dataset 拉下来CLI 也内置了 full、verified、multimodal、multilingual 四个别名。各数据集的字段结构比如多模态版的图片资源字段在哪在 数据集说明 里写得很细infer 跑推理、images 预构建镜像、submit 提交榜单等完整命令则见 命令行参考。多数团队的路径是Lite 跑通流程Verified 定标模型水平需要对外发布数字再上 Full。最后把话收回来下次评估一个 AI 编程工具或者要在汇报里证明微调有效果时手里就多了一组客观数据——不是厂商的自述而是同一批 500 个或 534 个任务、同一套容器环境里跑出来的通过率。【免费下载链接】SWE-benchSWE-bench: Can Language Models Resolve Real-world Github Issues?项目地址: https://gitcode.com/GitHub_Trending/sw/SWE-bench创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考