SWE-bench：代码理解评测

可视化演示

展示SWE-bench代码理解评测：Issue到代码理解的流程、Agent读取编辑测试流程、修复通过率评估，通过交互理解真实软件工程任务评测。

评测定位

学校里的厨艺考试，通常是“给你一颗土豆，切成均匀细丝”——食材干净、目标明确。但真实餐厅的后厨根本不是这样：几十种食材堆着，油锅咕嘟冒泡，客人的投诉各有各的蹊跷。SWE-bench 选择的就是后者：一间正在营业的真实厨房。

2023 年，普林斯顿团队把 12 个真实的 Python 开源仓库（django、sympy、matplotlib、requests 等）搬进考场，从这些仓库的历史 bug 中整理考题。每个任务实例包含三样东西：一份仓库代码快照、一段 bug 描述（GitHub issue）、一份参考答案（真实修复补丁）。模型全程看不到答案，只能靠自己阅读理解。

任务的形式化定义如下：模型拿到“仓库 + issue”，要产出一个能干净合入的补丁。它考的不是“会不会写函数”，而是“能不能读懂整间厨房”——先定位病灶，再动手修补，最后保证不闯祸。

$$\text{任务}:\;(\underbrace{\text{仓库代码}}_{\text{后厨全貌}},\;\underbrace{\text{Issue 描述}}_{\text{客人投诉}}) \;\longrightarrow\; \underbrace{\text{补丁 Patch}}_{\text{改良方案}}$$

1. 输入—仓库代码：仓库是某个提交状态下的完整源码，对应“后厨全貌”——几万行代码、几十个模块，bug 可能藏在任何角落。

$$\text{仓库代码}$$

2. 输入—Issue 描述：来自真实的 GitHub issue，对应“客人投诉”：现象、复现步骤、期望行为，但不给任何定位提示。

$$(\text{仓库代码},\;\text{Issue 描述})$$

3. 输出—补丁：模型必须产出统一 diff 格式的补丁，能够被 git apply 干净合入——相当于交出一份“后厨能直接照做”的整改方案。

$$(\text{仓库代码},\;\text{Issue 描述}) \;\longrightarrow\; \text{补丁 Patch}$$

所以 SWE-bench 的定位是“代码理解评测”而非“代码生成评测”：它考的是读得懂、找得准、修得对，而不只是写得快。

数据构建

考试委员会的出题人不会自己编菜谱，他们去翻各大餐厅的“投诉记录本”：哪桌客人真的抱怨过、哪位大厨后来真的改了菜，这些“有据可查的事故”才配成为考题。

数据构建分四步走。第一步在 GitHub 上抓取 Pull Request；第二步筛出“该 PR 修复了某个 issue”且改动以代码为主、不含新增依赖的样本；第三步跑通“复现—修复—测试”闭环，确认 bug 可复现、补丁有效；第四步把修复补丁与测试补丁分离存档，模型只能看到前者。

原始版本最终保留 2,294 个实例，来自 12 个 Python 仓库。后来官方又做了人工核验，挑出 500 条“答案没有歧义”的实例，称为 SWE-bench Verified，成为行业通用的报告口径。最关键的原则是时间切分：测试集里的 issue 与补丁，都是模型训练截止时间之后才出现的，防止“偷看答案”。

$$N_{\text{候选 issue}} \;\xrightarrow{\text{关联已合入 PR}}\; N_{\text{可复现}} \;\xrightarrow{\text{含测试补丁}}\; N_{\text{实例}} = 2{,}294$$

1. 候选过滤：只保留“有对应合并 PR”的 issue，代表这个 bug 确实被官方修过，答案客观存在。

$$N_{\text{候选 issue}} \;\xrightarrow{\text{关联已合入 PR}}\; N_{\text{可复现}}$$

2. 测试配对：修复 PR 里必须包含测试补丁，否则无法自动化判分——就像没有评审标准就不能给菜品打分。

$$N_{\text{可复现}} \;\xrightarrow{\text{含测试补丁}}\; N_{\text{实例}} = 2{,}294$$

这些考题全部来自真实事故，“后厨真的救回过这道菜”，所以答案客观、可复现、可自动验证。

评测指标

评审团定下两条铁律：第一，被投诉的菜端上来必须达标，这叫“新增测试必须通过”；第二，原本的招牌菜绝不能因为这次改良而变难吃，这叫“原有测试不能回归”。两条都满足，这道题才算“解决”。

技术术语里，前者叫 FAIL_TO_PASS（修复前失败、修复后必须通过的测试），后者叫 PASS_TO_PASS（修复前后都必须通过的测试）。评分的分母是全部实例，分子是“解决”的实例数——每道题要么记 1 分，要么记 0 分，没有中间地带。

一个补丁哪怕只弄挂了一个 PASS_TO_PASS 测试，也直接判零分。这种“零容忍回归”的设计是有意为之：真实软件工程里，修一个 bug 引入十个 bug 的“假修复”，比不修更糟糕。

$$\text{Accuracy} = \frac{1}{N}\sum_{i=1}^{N} \mathbb{1}\big[\,F_i \subseteq \text{Pass}_i \;\land\; P_i \subseteq \text{Pass}_i \,\big]$$

1. 求和取平均：$N$ 是实例总数，$\frac{1}{N}\sum$ 表示把所有“解决”的题目的得分加起来再求比例。

$$N,\;\;\sum_{i=1}^{N}$$

2. 指示函数：$\mathbb{1}[\text{条件}]$ 在条件成立时等于 1，否则为 0——就像裁判举牌，要么通过要么不通过。

$$\mathbb{1}[\cdot]$$

3. 双条件交集：$F_i \subseteq \text{Pass}_i$ 表示第 $i$ 题的 FAIL_TO_PASS 测试全部通过；$P_i \subseteq \text{Pass}_i$ 表示 PASS_TO_PASS 测试全部通过；$\land$ 表示两者缺一不可。

$$F_i \subseteq \text{Pass}_i \;\land\; P_i \subseteq \text{Pass}_i$$

两条铁律一叠加，想靠“蒙对一半”拿分？门都没有。这个指标逼着模型做“无损修复”，而不是拆东墙补西墙。

评测流程

考试当天，考务组按标准流程走：先把厨房按原样布置好（装好依赖），再请厨师交方案，然后把方案实际做一遍端给评审（跑测试），最后记分归档。

SWE-bench 的评测流水线完全自动化。第一步搭建隔离环境：用 conda 创建虚拟环境、安装依赖、把仓库 checkout 到指定 commit；第二步把模型产出的补丁合入仓库（git apply）；第三步在改动后的仓库上运行全部 P2P 和 F2P 测试；第四步按判定规则汇总得分。

官方还会单独统计一个中间指标——“补丁是否干净合入”。许多模型生成的补丁根本合不进去，属于“连方案都交不上”。于是整个链路可以分解成两个条件概率的乘积，方便定位瓶颈出在哪一环。

$$\text{解决率} = P(\text{补丁合入}) \;\times\; P(\text{全部测试通过} \mid \text{补丁合入})$$

1. 第一道卡口：$P(\text{补丁合入})$ 是补丁能干净 apply 的概率，对应“方案能被后厨直接照做”。

$$P(\text{补丁合入})$$

2. 第二道卡口：$P(\text{全部测试通过} \mid \text{补丁合入})$ 是条件概率——在补丁能合入的前提下，评审团全部通过的概率。

$$P(\text{全部测试通过} \mid \text{补丁合入})$$

流水线上每一环都可能掉链子，评测的价值就是帮你把“哪一环最弱”精确揪出来，再针对性优化。

Agent 评测

静态评测像“闭卷交方案”：厨师不许进厨房，只准在纸上写整改步骤。而 Agent 模式是“开卷实操”：厨师真的走进厨房，可以开火、尝味道、翻冰箱，发现不对立刻改。

2024 年普林斯顿团队推出 SWE-agent，搭建了一个 Agent-计算机接口（ACI），让模型通过终端自动读写文件、运行命令、执行测试，在“修改 → 观察 → 再修改”的循环中逼近正确补丁。评测内容从“一步生成补丁”升级为“多回合决策”。

评测需要给 Agent 设置回合预算：最多执行多少次命令、消耗多少 token。每一回合它都会新增观察（测试输出、报错堆栈），信息集合单调增长；最终分数仍然按“补丁能否通过全部测试”来算，考核方式不变。

$$G_t = G_{t-1} \cup \{\text{Obs}_t\},\qquad t = 1,\dots,K_{\max}$$

1. 观察累积：$\text{Obs}_t$ 是第 $t$ 回合拿到的测试输出或报错信息，不断并入信息集合——就像厨师每尝一口汤，对火候的了解就多一分。

$$G_t = G_{t-1} \cup \{\text{Obs}_t\}$$

2. 回合预算：$K_{\max}$ 是最大回合数，防止 Agent 无限试错，逼它在“探索”与“收敛”之间做取舍。

$$K_{\max}$$

会动手、会看火候的 Agent，解决率通常明显高于只会纸上写方案的模型——这也是 2024 年后顶级模型普遍标配 Agent 能力的原因。

RAG 增强

整间厨房太大，总不能把所有食材都搬到操作台上。聪明的做法是让副手先去档案室，翻出与“罗宋汤投诉”最相关的几份菜谱和配料单，只把这几样端过来。

这就是 RAG（检索增强生成）在代码理解评测里的角色：把仓库文件切块、向量化建立索引；当 issue 到达时，用相似度检索挑出 top-k 个相关文件；把“相关代码 + issue”拼接成上下文，让模型在这个精挑细选的上下文里生成补丁。

检索质量直接决定修复质量——检索漏掉真正的 bug 文件，模型再聪明也白搭。实践上常用召回率、命中率来评估检索模块；在几十万行的超长仓库中，RAG 的性价比远高于把全量代码硬塞进上下文。

$$\text{上下文} = \text{Top-}k\big(\cos(\mathbf{e}_{q},\; \mathbf{e}_{d_1}),\; \dots,\; \cos(\mathbf{e}_{q},\; \mathbf{e}_{d_m})\big)$$

1. 向量编码：$\mathbf{e}_q$ 是 issue 的嵌入向量，$\mathbf{e}_{d_j}$ 是第 $j$ 个代码块的嵌入向量——相当于给“投诉”和“菜谱”各自贴标签。

$$\mathbf{e}_{q},\;\mathbf{e}_{d_j}$$

2. 相似度排序：$\cos(\cdot)$ 衡量两个向量在语义空间里的接近程度，值越大表示越相关。

$$\cos(\mathbf{e}_{q},\;\mathbf{e}_{d_j})$$

3. 取前 k：$\text{Top-}k$ 只保留最相关的 k 个代码块作为上下文，避免无关食材干扰判断。

$$\text{Top-}k(\dots)$$

先“精准取料”再下锅，而不是把整个厨房搬上操作台——这正是 RAG 的精髓，也是超长代码库场景下的必备策略。

实践现状

翻看历届考生的成绩单，进步速度快得惊人，但离“满分总厨”仍然很远。在 SWE-bench Verified（500 道人审核验题）上，2023 年初最好的模型解决率不足 5%；2024 年中期约三成；2025 年顶级模型已突破六成、逼近七成。

与此同时，还有三成以上的问题连最强 AI 也束手无策。失败原因大致归为三类：定位不准（找不到 bug 所在文件或函数）、补丁缺陷（语法错误或修复不完整）、环境差异（依赖安装失败、测试不稳定）。对应的优化策略是：强化检索与代码导航、Agent 多轮自检与自我修复、评测基建标准化与多次运行取均值。

$$\text{Verified 解决率}:\quad 2023\text{ 年} < 5\% \;\longrightarrow\; 2025\text{ 年} \approx 60\%$$

1. 起点：2023 年基线模型在真实仓库上几乎全军覆没，说明“看懂整间厨房”远难于“写好单个函数”。

$$2023\text{ 年} < 5\%$$

2. 拐点：2025 年 Agent + 长上下文 + RAG 的组合把解决率推到六成左右，但远未饱和。

$$2025\text{ 年} \approx 60\%$$

这份成绩单告诉我们：代码理解仍是 AI 的“硬骨头”，但每一年都在肉眼可见地变软。谁能啃下剩下的三成，谁就握住了下一代研发工具的门票。

AI 应用场景

Python 演示

#!/usr/bin/env python3"""SWE-bench 风格评测器 模拟 SWE-bench 判定逻辑: 一个补丁必须让所有 FAIL_TO_PASS 测试通过,且所有 PASS_TO_PASS 测试不回归, 才判定该问题被解决."""  class SWEBenchEvaluator:    def __init__(self, problems):        self.problems = problems        self.results = []     def apply_patch(self, source, patch):        # 逐条执行替换, 模拟 git apply 将补丁合入仓库        for old, new in patch:            source = source.replace(old, new)        return source     def run_tests(self, source, tests):        # 简化测试: 测试特征串出现在源码中即视为通过        passed = []        for test in tests:            if test in source:                passed.append(test)        return passed     def evaluate(self, predict_fn):        solved = 0        for idx, prob in enumerate(self.problems):            patch = predict_fn(prob["issue"])            source = self.apply_patch(prob["source"], patch)            passed = self.run_tests(source, prob["all_tests"])            ftp_ok = all(t in passed for t in prob["fail_to_pass"])            ptp_ok = all(p in passed for p in prob["pass_to_pass"])            ok = ftp_ok and ptp_ok            self.results.append((idx, ok))            solved += int(ok)        return solved / len(self.problems)  def simple_model(issue):    # 实习厨师: 只会按 issue 关键词套用三种固定补丁    if "排序" in issue:        return [("[3,1,2]", "[1,2,3]")]    if "最大值" in issue:        return [("max_value = -999", "max_value = values[0]")]    if "反转" in issue:        return [("return values", "return values[::-1]")]    return []  # 不会修的题就交空补丁  def main():    problems = [        {            "issue": "排序函数输出顺序错误",            "source": "def sort_list(values):\n    return [3,1,2]",            "all_tests": ["def sort_list(values):", "return [1,2,3]"],            "fail_to_pass": ["return [1,2,3]"],            "pass_to_pass": ["def sort_list(values):"],        },        {            "issue": "求最大值函数对负数输入失效",            "source": "def max_val(values):\n    max_value = -999\n    return max_value",            "all_tests": ["def max_val(values):", "max_value = values[0]"],            "fail_to_pass": ["max_value = values[0]"],            "pass_to_pass": ["def max_val(values):"],        },        {            "issue": "反转函数没有真正反转",            "source": "def reverse_list(values):\n    return values",            "all_tests": ["def reverse_list(values):", "return values[::-1]"],            "fail_to_pass": ["return values[::-1]"],            "pass_to_pass": ["def reverse_list(values):"],        },        {            "issue": "空列表输入应该返回 None 而不是抛异常",            "source": "def first_item(values):\n    return values[0]",            "all_tests": ["def first_item(values):", "if not values: return None"],            "fail_to_pass": ["if not values: return None"],            "pass_to_pass": ["def first_item(values):"],        },    ]    evaluator = SWEBenchEvaluator(problems)    accuracy = evaluator.evaluate(simple_model)    print("SWE-bench 风格评测准确率: %.0f%%" % (accuracy * 100))    for idx, ok in evaluator.results:        mark = "解决" if ok else "未解决"        print("问题 %d (%s): %s" % (idx + 1, problems[idx]["issue"], mark))  if __name__ == "__main__":    main()

1. source = self.apply_patch(prob["source"], patch)模拟 git apply，把模型输出的补丁逐条替换进源码。
2. passed = self.run_tests(source, prob["all_tests"])简化版测试执行：测试特征串出现在源码中即认为通过。
3. ftp_ok = all(t in passed for t in prob["fail_to_pass"])检查全部 FAIL_TO_PASS 测试是否通过，对应“投诉菜必须修好”。
4. ptp_ok = all(p in passed for p in prob["pass_to_pass"])检查原有 PASS_TO_PASS 测试是否仍全过，对应“招牌菜不许变难吃”。
5. ok = ftp_ok and ptp_okand 就是评测里的"∧"：两条铁律缺一不可。
6. if "排序" in issue:实习厨师模型只按关键词套固定补丁，对应最简单的规则式基线。
7. return [] # 不会修的题就交空补丁空补丁必然导致 F2P 失败，模拟“不会修”的场景。
8. accuracy = evaluator.evaluate(simple_model)跑完整评测流水线，输出最终解决率。

常见误区

面试题