Don't Claim Benchmark-Oriented Optimization Improves General Coding Capability — Diverse Evaluation Is Required¶

会议: NeurIPS 2026
arXiv: 2608.13566
领域: LLM评测
关键词: 代码大模型评测, SWE-bench, 跨任务迁移, 构念效度, 基准优化

一句话总结¶

本文针对代码大模型后训练中以 SWE-bench 等单一代准为优化目标并宣称提升“通用代码能力”的现象提出严肃质疑，通过构建涵盖方法生成、方法补全和程序修复的 Django 基准套件进行跨任务迁移验证，揭示了基准优化导致任务特异化而非通用能力提升的“意义鸿沟”。

研究背景与动机¶

深度学习与代码结合（DL-for-code）的研究近年来逐渐收敛于极少数基准的评测范式。在自包含题目侧，以 HumanEval 为代表的单函数算法题虽然方便评测，但与实际软件工程脱节；在仓库级任务侧，SWE-bench 及其衍生变体（如 SWE-bench Verified）已成为评估代码 Agent 解决真实 GitHub Issue 的事实标准。为了在 SWE-bench 排行榜上争夺榜首，社区投入了海量工程与训练算力，提出了极其复杂的后训练（post-training）轨迹合成方法、专业 Agent 脚手架与强化学习优化管线。业界与学术界在发布模型卡片和技术报告时，也普遍将 SWE-bench 分数的大幅攀升直接等同于模型具备更强的“通用编程能力（general coding capability）”。

然而，这种将单一基准得分跃升推断为通用能力进化的逻辑存在严重的构念效度（construct validity）缺陷。SWE-bench 衡量的是高度特异化的端到端综合表现，混杂了代码库长程检索、Issue 语义理解、Patch 格式遵循、工具调用与特定工作流对齐。模型在基准上的高分，究竟是代表了可泛化到其他软件工程任务的底层代码能力演进，还是仅仅在基准优化压力下迎合了特定的 Agentic 交互范式、指令模板乃至测试用例分布？由于后训练工作通常仅在自身目标对齐的单一代准上汇报提升，这种评测盲区造成了巨大的“意义鸿沟（meaning gap）”，极易导致算法研究误判优化路径、工程落地做出次优部署选型。

面对这一困境，本文的核心切入点是设计一个严格受控的跨任务迁移诊断实验：选择占据 SWE-bench Verified 达 46% 任务份额的核心代码库 Django，固定单一版本快照构建多模态软件工程任务，直接检验在 SWE-bench 轨迹上后训练的模型能否在该代码库的其他常见任务上泛化。核心 idea：通过在相同仓库（Django）内构建涵盖方法生成、补全与修复的多模态基准套件，实证检验基准后训练模型的跨任务迁移能力，揭露单一代准优化导致的任务特异化局限，并提出面向通用代码能力的差异化多元评测框架。

方法详解¶

整体框架¶

本文构建了一套用于诊断代码模型跨任务迁移能力的控制实验平台。为排除代码库分布差异的干扰，研究基于单一真实仓库构建评测闭环。输入为冻结的 Django 4.0.4 源码快照（commit 89807fb），经过严格的类继承树切分与 DeepSeek-R1 生成的标准 Docstring 增强，派生出三类互补的软件工程任务模态；模型生成的候选代码被回填至隔离环境并通过官方测试套件映射的精准测试集进行判定。在此基础上，框架横向对比了基础基座模型、社区开源的 SWE-bench 优化 Checkpoint、以及在单任务模态上微调的对照模型，并引入独立的 LiveCodeBench（LCB）作为远端跨任务验证。

%%{init: {'flowchart': {'rankSpacing': 24, 'nodeSpacing': 28, 'padding': 6, 'wrappingWidth': 400}}}%%
flowchart TD
    A["Django 4.0.4 冻结仓库快照<br/>(SWE-bench 核心占比 46%)"] --> B["防污染继承树划分<br/>Train: 3180 / Test: 359 方法"]
    B --> C["DeepSeek-R1 规范化文档合成<br/>三段式结构化 Docstring 补充"]
    C --> D["三类软件工程任务模态构建<br/>方法生成 / 方法补全 / 程序修复"]
    D --> E["隔离式贪婪采样评估<br/>(无 Agent 脚手架，T=0)"]
    E --> F["官方测试映射验证<br/>Stub 探针映射 pass@1 严格判定"]
    F --> G["跨任务迁移诊断对比<br/>基座 vs SWE微调 vs 任务微调 vs LCB"]

关键设计¶

1. 继承树感知的防数据污染数据集切分：杜绝继承关系导致的信息穿越 为了在同一仓库内构建可信的训练集与测试集，直接按方法或随机抽取文件会导致派生类覆写方法、Mixin 或抽象基类产生严重的跨划分隐式污染。本文在解析 Django 4.0.4 源码时，显式追踪所有类的继承层级树结构。切分规则强制要求：对于任意类，其全部祖先类（ancestors）和派生类（descendants）必须整体划分至同一数据子集。独立函数与模块级导入则严格按源文件归属，不跨集重复。最终在 3,180 个训练方法（覆盖 1,585 条继承链）与 359 个测试方法（覆盖 184 条继承链）之间实现了严格隔离，测试代码（tests/ 目录）被彻底排除在训练和提示词之外。

2. 基于 DeepSeek-R1 的三段式文档合成与标准化：消除规格说明噪音 真实开源项目的内部注释质量高度参差，直接以原始注释评估“根据文档实现方法”会引入大量因提示不明确导致的方差。统计显示 Django 原始代码中无注释方法占比高达 74%~78%。本文利用 DeepSeek-R1 对所有类方法生成标准化 Docstring，并与原有开发者注释深度合并。生成的规格说明严格遵循三段式模式：① 功能描述（1-2 句明确方法行为与核心意图）；② 主要输入（明确参数名称、预期类型及约束条件）；③ 输出与副作用（返回值规范及特定异常抛出行为）。这确保了方法生成任务的完备性与可解性，排除了因需求模糊引起的能力评测失真。

3. 三模态仓库级任务与基于 Stub 探针的精准测试用例对齐：细粒度隔离能力维度 为了精确探查代码能力的结构性变化，基准包含三种互补模态： - 方法生成（Method Generation）：给出类声明、目标方法签名、合成 Docstring 及移除了方法体的完整源码上下文，模型需在最后一个 Markdown 代码块中输出完整实现； - 方法补全（Method Completion）：提供前半部分方法实现上下文（不提供 Docstring），模型需通过上下文推断剩余行（类似实际 IDE 补全场景）； - 程序修复（Program Repair）：输入包含一个缺陷方法的源码及 Django 运行该缺陷时抛出的真实测试栈追踪（Stack Trace），模型需定位并修复该方法。缺陷方法通过 Qwen3 级联生成及非控制 Token 打乱注入。

在测试对齐方面，本文通过在每个待测方法体内注入桩代码（return None），运行全量官方测试套件，精确提取所有因而失败的测试项建立映射字典 $M: \text{method} \to \{t_1, t_2, \dots, t_k\}$。若注入桩代码无法触发任何测试失败，则认为该方法缺乏测试断言保障并直接移出基准。评测时仅运行映射的子测试集，模型生成的代码在插入文件后必须满足所有映射测试均通过： $$\text{Correct}(m) = \mathbb{I}\left( \forall t \in M(m), \text{Result}(t) = \text{PASS} \right)$$ 全部评测在贪婪解码（$T=0$）下进行，计算严格的 $\text{pass}@1$ 指标。

4. 分离 Agentic 脚手架与核心模型能力的诊断设计：剥离格式与执行干扰 为了直接观察后训练对模型原生代码行为的改变，主实验完全移除了复杂 Agent 运行时的中间搜索、多轮调用与工具编排，直接要求模型单步生成符合规范的补丁。同时，针对 SWE-agent Checkpoint 引入对比消融实验：验证在 10 步和 75 步 Agent 脚手架与纯无脚手架生成之间的表现差异。错误流桑基图（Sankey Diagram）分析进一步将错误解耦为格式与解析错误（如 NOT_RUN、IndentationError，占 47.2%）和实质性语义/逻辑错误（如 AssertionError、SyntaxError，占 52.8%），证明迁移失败绝非单纯格式解析不当，而是根本性的跨任务泛化缺失。

实验关键数据¶

主实验¶

主实验系统评测了基础基座模型与开源 SWE-bench 优化模型在 Django 三大任务模态及独立 LiveCodeBench 上的跨任务迁移表现。

模型类别 / 具体模型	SWE-bench 验证分	方法生成 (CG)	方法补全 (CC)	程序修复 (PR)	LiveCodeBench
Qwen2.5-Coder-32B 基座	7.00	64.07	60.17	47.35	28.20
OpenHands LM 32B	37.20 (+30.20)	66.57 (+2.51)	48.75 (-11.42)	13.93 (-33.43)	25.80 (-2.30)
Skywork-SWE 32B	38.00 (+31.00)	68.80 (+4.74)	57.66 (-2.51)	41.78 (-5.57)	27.30 (-0.90)
SWE-agent-LM-32B	40.20 (+33.20)	66.57 (+2.51)	55.15 (-5.01)	40.11 (-7.24)	25.20 (-2.90)
R2EGym-32B-Agent	34.40 (+27.40)	67.41 (+3.34)	58.22 (-1.95)	40.67 (-6.69)	29.60 (+1.50)
Qwen2.5-Coder-7B 基座	1.80	52.92	50.97	17.83	15.20
R2EGym-7B-Agent	19.00 (+17.20)	54.87 (+1.95)	41.23 (-9.75)	15.04 (-2.79)	17.30 (+2.10)
SWE-agent-LM-7B	15.20 (+13.40)	5.85 (-47.08)	2.23 (-48.75)	1.67 (-16.16)	6.70 (-8.50)
Qwen3-32B 基座	23.00	67.41	43.45	46.80	61.00
DeepSWE-Preview (Qwen3)	42.20 (+19.20)	67.69 (+0.28)	44.29 (+0.84)	51.25 (+4.46)	60.10 (-0.90)

在商用闭源顶级模型上的验证实验（验证基准的可解性与能力阶梯）：

商用模型	方法生成 (CG)	方法补全 (CC)	程序修复 (PR)	平均表现与排序
OpenAI GPT-4.1	76.60	64.90	61.84	稳健基准水平
OpenAI GPT-5	84.68	77.99	79.67	各项能力高度均衡领先
Google Gemini 2.5 Pro	83.01	51.25	67.97	补全能力较弱，生成较强
Google Gemini 3 Pro	86.35	78.27	61.00	生成与补全极强，修复较弱
Google Gemini 3 Flash	85.79	73.26	62.95	轻量高推理表现
Claude Haiku 4.5	74.65	58.77	61.56	入门级梯队表现一致
Claude Sonnet 4.5	82.73	77.44	69.36	整体稳固超越同系轻量模型
Claude Opus 4.5	88.02	76.60	78.27	方法生成取得全场最高分

消融实验¶

为了进一步探究任务特异性监督微调对跨模态能力的侵蚀，作者在 Qwen2.5-Coder-32B 和 7B 上分别使用 LoRA（Rank 128, Alpha 128, LR $1\times 10^{-5}$）进行了单任务微调与全模态交叉验证。

基座模型	微调目标任务	方法生成 (CG)	方法补全 (CC)	程序修复 (PR)	LiveCodeBench
Qwen2.5-Coder-32B	原始基座 (未微调)	64.07	60.17	47.35	28.20
	方法生成 (CG) 微调	71.03 (+6.96)	54.60 (-5.57)	42.90 (-4.45)	22.90 (-5.30)
	方法补全 (CC) 微调	66.02 (+1.95)	74.65 (+14.48)	24.51 (-22.84)	25.20 (-2.90)
	程序修复 (PR) 微调	69.08 (+5.01)	56.82 (-3.35)	56.27 (+8.92)	25.50 (-2.60)
Qwen2.5-Coder-7B	原始基座 (未微调)	52.92	50.97	17.83	15.20
	方法生成 (CG) 微调	58.22 (+5.30)	50.14 (-0.83)	15.88 (-1.95)	16.40 (+1.20)
	方法补全 (CC) 微调	19.77 (-33.15)	64.07 (+13.10)	1.39 (-16.44)	15.00 (-0.30)
	程序修复 (PR) 微调	55.71 (+2.79)	51.25 (+0.28)	40.95 (+23.12)	15.00 (-0.30)

此外，在 Agent 脚手架的消融实验中，对比了有无 SWE-agent 脚手架对方法生成表现的影响： - Qwen2.5-Coder-7B 在 10 步脚手架下为 0.0%，无脚手架直接生成为 52.92%； - SWE-agent-LM-7B 在 10 步脚手架下为 24.51%，无脚手架为 5.85%（严重过拟合 XML 交互模板导致解析失败）； - Qwen2.5-Coder-32B 在 10 步脚手架下仅为 8.59%，无脚手架达到 64.07%； - SWE-agent-LM-32B 在 10 步脚手架下为 39.62%，无脚手架为 66.57%；当步数放宽至 75 步时，其脚手架得分回升至 63.51%，方才接近无脚手架的单步生成性能。

关键发现¶

跨任务迁移的广泛失效：在 28 项跨任务对比中（7 个公开发布的 SWE-bench 检查点 $\times$ 4 个基准任务），出现 18 次性能下降与 10 次上升。5 个模型在多数任务上发生倒退，无一模型能在全部 4 个任务上取得提升。
基准优化与通用能力脱钩：在 SWE-bench 上相对基座暴涨 30% 以上的检查点（如 OpenHands 32B、Skywork-SWE、SWE-agent-LM-32B），在同为 Django 代码库的方法补全上下滑 2.5%~11.4%，在程序修复上下滑 5.5%~33.4%，在 LiveCodeBench 算法题上也普遍下滑 0.9%~2.9%。
基准排名的逆转与不可靠性：不同评测模态揭示了基座模型能力的非均匀性。Qwen3-32B 在 SWE-bench 上以 23.0% 远超 Qwen2.5-Coder-32B 的 7.0%，但在 Django 代码补全上却以 43.45% 惨败于后者的 60.17%，表明依赖单一排行作选型极其危险。
过拟合陷阱的容量依赖性：7B 规模模型极易对后训练任务格式产生硬编码过拟合（如 SWE-agent-LM-7B 生成多余的 XML 标签或缩进错乱，导致正确率跌至 5.85%）；而 32B 模型虽然能够保持格式规范，但其内在代码逻辑能力在非目标模态下仍未见增长，呈现“在分布内高度专业化、在分布外毫无进益”的特征。

亮点与洞察¶

尖锐揭示“意义鸿沟”与构念效度危机：直击当前代码大模型领域将 SWE-bench 打榜分数机械等同于“通用编程能力提升”的学术浮躁，从测量学角度论证了当前打榜实为窄任务对齐而非能力进化的事实。
极具说服力的“同仓异构”诊断实验设计：巧妙选择占 SWE-bench 近半壁江山的 Django 仓库作为测试床，通过固定代码分布反驳了以往“由于换了新仓库所以迁移较差”的可能辩解，把迁移失败的原因彻底钉死在任务模态的特异化上。
提出切实可行的三层次差异化评测倡议：反对用单一指标评测一切，明确提出前沿旗舰模型需开展全流程/开放式评估、学术微调模型需依赖覆盖多元任务的套件（如 MTEB 式的评测套件）、特定落地系统应依赖人机协作验证的差异化路径。

局限与展望¶

作者承认的局限：实验主要聚焦于单一 Python 核心项目（Django）及 Qwen 家族开源检查点，对于跨多编程语言、跨多框架架构的普适性规律仍有待更广泛的跨生态验证；此外，附录给出的能力分类学（Taxonomy）目前仍属初步讨论草案，未经过深入的心理测量学严格论证。
潜在研究盲区：目前针对 Checkpoint 的微调实验主要基于标准 LoRA 与有限超参，未对不同数据配比、全参数微调或带有通用正则化约束的后训练方案进行穷尽性探索。
具体改进思路：社区需将基准建设作为持久科研基础设施对待，建立类似 MTEB 的代码多任务评测套件（Code-MTEB），并推行“基准长期维护与去污染审计”制度，设立学术会议专项 Track 奖励基准维护工作。

评分¶

新颖性: ⭐⭐⭐⭐⭐ 首次系统性地通过“同仓异构任务”实证击破 SWE-bench 优化等同于通用代码能力提升的神话。
实验充分度: ⭐⭐⭐⭐⭐ 涵盖 7 款公开发布 SWE 模型、6 组自研微调对比、8 款顶级商用模型及详细错误流桑基图，证据链极其闭环。
写作质量: ⭐⭐⭐⭐⭐ 论点极其鲜明，逻辑层层递进，直面社区顽疾且提出了建设性的未来评测范式。
价值: ⭐⭐⭐⭐⭐ 对矫正当前代码智能领域的刷榜风气、引导真实的通用代码能力研究具有重大行业警醒价值。