不要声称面向基准测试的优化能提升通用编码能力——需要多样化的评估

# 不要声称面向基准的优化能提升通用编码能力——需要多样化评估 来源：https://arxiv.org/html/2608.13566 作者：Vera Kudrevskaia, Timur Galimzyanov, Mikhail Evtikhiev, Ana Terna, Rastislav Rabatin, Timur Kudashev, Timofey Bryksin, Arina Puchkova, Patrik Bartak, Egor Bogomolov, Sergey Titov

###### 摘要
后训练论文、模型卡片和博客文章常将少量编码基准（如SWE-bench和LiveCodeBench）上的分数作为研究产物和面向用户系统的广泛“编码能力”的证据。我们认为，针对这些基准的优化导致了对任务特定性能的测量，造成了测量分数与通用编码能力声明之间的*意义差距*。我们通过构建一个基于Django的案例研究基准套件来检验这一差距。通过评估在SWE-bench轨迹上后训练的基础模型和检查点，我们发现基准排名常常无法泛化。后训练的检查点表现出有限的跨任务迁移能力，而SWE-bench优化在我们的任务或LiveCodeBench上带来的收益有限或为零。类似地，在单个Django模态上进行微调也无法实现迁移。我们得出结论：少量基准不足以评估在基准优化压力下的多样化模型。我们鼓励社区采用差异化评估——对前沿模型进行整体评估，为研究提供多任务套件，并对狭窄任务应用进行人在环路研究。最后，我们主张创建能力分类体系并持续维护基准，而非一次性发布基准。没有可靠的评估标准，使用大语言模型和智能体的工程师和研究人员将不得不依赖不充分的证据进行研究、开发和部署决策。 大语言模型、基准、评估、软件工程中的机器学习

## 1 引言
代码领域的深度学习（DL-for-code）社区已收敛于一种狭窄的评估范式。一方面，研究者使用自包含的算法任务，例如HumanEval，这类任务便于基准测试，但与真实世界的软件开发仅有微弱相似性。另一方面，SWE-bench（Jimenez等人，2024 (https://arxiv.org/html/2608.13566#bib.bib39)）已成为衡量“真实世界”编码能力的事实标准，其排行榜排名常被解读为通用编码能力的代理指标。“通用编码能力”是解释模型在多样化编程任务上性能正相关的潜在因素，区别于狭窄的特定任务技能。它类似于Chollet（Chollet，2019 (https://arxiv.org/html/2608.13566#bib.bib14)）对智能的定义。

这种趋同推动了卓越的工程努力：复杂的后训练方法、专用的智能体架构，以及专门设计以最大化SWE-bench分数的训练流程（Zeng等人，2025 (https://arxiv.org/html/2608.13566#bib.bib55)；Pan等人，2024 (https://arxiv.org/html/2608.13566#bib.bib30)）。SWE-bench分数可能确实与编码能力的真实进步相关。最近几代基础模型在许多与编码相关的行为上显示出明确的改进，并且结合前沿专有模型的智能体现在已广泛应用于实践（Christian Mürtz，2025 (https://arxiv.org/html/2608.13566#bib.bib7)）。

然而，SWE-bench和其他编码基准的当前结构通常无法告诉我们分数*为何*提升。SWE-bench式的表现混合了多种因素：代码仓库理解、补丁合成、工具使用、搜索与检索策略，以及对特定工作流和输出格式的遵循。因此，若不进行深入分析，很难识别改进的真正驱动因素。对于基础模型，改进通常在包括非编码任务在内的广泛基准上报告，这为通用智能的真实提升提供了更强有力的证据。相比之下，许多后训练论文主要在SWE-bench（或一小簇类似基准）上报告改进，这为泛化和基础能力变化提供了可能有限且模糊的信号。

这种混淆之所以重要，是因为它塑造了研究优先级。例如，如果在SWE-bench轨迹上的后训练可靠地提升了通用编码能力，这种方法就为模型改进提供了一条路径。但如果它只产生了精于SWE-bench类任务的模型，该领域就有风险为基准本身进行优化，而非解决底层能力或其他编码任务，这严重限制了这种后训练方法的影响。因此，研究编码智能体和大语言模型编码能力的研究人员可能被混淆，从而误解他们的结果，而依赖其工作的工程师可能做出次优的部署决策。

我们的证据支持后一种解释：在SWE-bench上的后训练收益不能持续迁移到其他代码任务，即使在同一代码仓库内也是如此。为说明这一点，我们构建了一个涵盖代码编辑、生成和补全的Django基准，并评估了社区发布的检查点和我们微调的模型。我们在社区发布的面向SWE-bench的检查点和我们微调的模型中都观察到一致的模式。在问题解决轨迹上微调的模型通常不会在我们的Django相关任务或LiveCodeBench（LCB）（Jain等人，2024 (https://arxiv.org/html/2608.13566#bib.bib64)）上有所提升，而在某个Django任务上微调的模型也不会在其他Django任务或LCB上提升。这表明狭窄的训练方案驱动的是任务特定的专业化，而非通用编码能力的提升。此外，SWE-bench（甚至多基准）排名可能并不总能可靠地预测在这些模态上的相对性能。

综合来看，我们的发现表明，SWE-bench排名可能系统性地误报了模型在各个软件工程任务上的相对优势，尤其是当真实世界的使用超越了智能体式的问题解决时。在这篇立场论文中，我们认为不同基准上的性能不匹配反映了一个*构念效度*问题：当少量基准被视为“通用编码能力”的代理时，得出的结论超出了测量所能实际支持的范围。SWE-bench针对的是一个复杂但特定的行为，涉及代码仓库导航、理解问题描述和生成针对性的补丁。这些测量可能混合了多种潜在能力与狭窄的特定任务技能。高性能可能表明编码能力强，但同样可能反映在基准优化压力下形成的特定格式和工作流的熟练程度。在没有跨任务模态评估的情况下，我们无法区分这些假设，无法理解我们后训练方法的优缺点，甚至无法足够细致地评估基础模型。由此产生的误解可能传播给使用大语言模型和智能体的工程师和用户，因为大语言模型辅助编码和编码智能体正变得日益普遍，并最终破坏他们对这些系统的信任。

我们呼吁社区对代码模型的评估方式进行根本性转变。对狭窄基准集的过度依赖导致社区将任务性能等同于通用编码能力，损害了构念效度，使得无法区分真实能力与基准特定优化。评估框架应明确测试任务模态间的迁移，将通用编码提升与狭窄专业化区分开来，并提供模型能力和局限性的完整图景。我们的基准套件和实验方法论阐明了一条可能的前进道路，但我们的主要建议是方法论上的：该领域必须超越排行榜排名，转向更直接地衡量我们声称关心的构念的评估实践。作为实际一步，我们提出一种三管齐下的方法：对前沿模型进行整体评估，为增量研究和较小模型提供多样化的多任务套件，以及对狭窄应用进行人在环路评估。

## 2 背景
### 2.1 编码基准
面向代码的大语言模型的评估大致可分为两类。自包含代码任务将解决任务所需的一切都打包在提示本身中。该类别中许多广泛使用的套件专注于短形式代码生成。一个典型例子是HumanEval（Chen，2021 (https://arxiv.org/html/2608.13566#bib.bib21)），包含164个手工制作的Python函数级生成问题。性能通常用pass@k（常为pass@1）报告，即采样的解决方案是否通过提供的测试。以更广泛的基准套件为例，LiveCodeBench（Jain等人，2024 (https://arxiv.org/html/2608.13566#bib.bib64)）在代码生成的基础上增加了自我修复、代码执行和测试输出预测。

代码仓库级基准在整个代码库中评估模型。给定代码仓库快照和自然语言任务描述，模型必须生成一个解决该任务并通过测试的补丁。SWE-bench Verified（Chowdhury等人，2024 (https://arxiv.org/html/2608.13566#bib.bib8)）是该类别中的事实标准，包含从12个流行Python代码仓库的GitHub问题中提取的500个问题解决实例。虽然问题解决是一项重要任务，但它并不能代表编码智能体能力的全部。最近，同样针对问题解决任务的SWE-bench Pro（Deng等人，2025 (https://arxiv.org/html/2608.13566#bib.bib66)）也开始获得关注。在问题解决之外，唯一相对流行的基准是TerminalBench（Merrill等人，2026 (https://arxiv.org/html/2608.13566#bib.bib13)）。

这两类的评估方法衡量不同的能力，并且尚不清楚基准分数是否应始终相关。在自包含任务上的强表现可能无法预测在需要导航代码库、理解依赖关系和生成针对性编辑的代码仓库级任务上的成功。此外，这两类基准是否涵盖了通用编码能力也不明确。

### 2.2 基础模型
现代基础模型为广泛的多领域能力而训练，模型卡片和技术报告用少量代表性基准总结编码性能。模型创建者为特定领域对这些模型进行基准测试的能力自然受限于时间和生成简洁、可读报告的必要性。例如，GPT-5模型卡片仅包含两个编码基准（SWE-bench Verified和Aider Polyglot）的报告，而Qwen3技术报告（Yang等人，2025a (https://arxiv.org/html/2608.13566#bib.bib49)）包含四个基准，其中三个属于自包含算法任务，第四个是面向执行推理的CRUXEval。报告的基准数量有限，加上基准任务间相关性可能较弱，这意味着某些编码能力可能落入基础模型创建者所用基准套件的盲区，从而导致误导性评估。

### 2.3 基础模型的后训练
对于后训练的检查点，这些限制变得更加明显。与基础模型发布相比，后训练论文面临页数限制、评估的计算成本（Jordan等人，2024 (https://arxiv.org/html/2608.13566#bib.bib61)）以及采用额外测试平台的工程开销。因此，单基准评估通常是务实的默认选择，而非例外。这种限制产生了一种典型模式：后训练工作倾向于在与其预期贡献一致的基准上进行评估。针对代码仓库级软件工程的工作通常仅报告SWE-bench性能（例如，Lingma SWE-GPT（Ma等人，2024 (https://arxiv.org/html/2608.13566#bib.bib50)），R2EGym-Agent（Jain等人，2025 (https://arxiv.org/html/2608.13566#bib.bib51)），SWE-agent-LM（Yang等人，2025b (https://arxiv.org/html/2608.13566#bib.bib52)），Skywork-SWE（Zeng等人，2025 (https://arxiv.org/html/2608.13566#bib.bib55)），DeepSWE-Preview（Luo等人，2025 (https://arxiv.org/html/2608.13566#bib.bib56)））。另一方面，专注于开发通用后训练技术的研究通常在自包含套件如HumanEval上进行评估（例如，（Wei等人，2024 (https://arxiv.org/html/2608.13566#bib.bib9)），（Tang等人，2025 (https://arxiv.org/html/2608.13566#bib.bib58)），（Yu等人，2024b (https://arxiv.org/html/2608.13566#bib.bib59)））。

虽然这完全合理，但这种评估方法无法区分改进是来自任务特定优化，还是反映了编码能力的普遍提升。能力泛化不能被视为理所当然：Yu等人（Yu等人，2024a (https://arxiv.org/html/2608.13566#bib.bib60)）展示了指令微调在提升算法基准分数的同时，底层行为并未获得相应改进的情况。我们所认为不理想的这种模式激发了我们的立场。为了支持这一立场，我们通过评估在特定任务上训练的检查点在多个软件工程模态上的表现，直接测试了跨任务迁移。

## 3 基准测量与能力声明
从通用编码能力的角度来看，任何单一基准最多只能提供对这种潜在能力的噪声化、部分化测量。特别是，当两个模型在整体能力上相差甚远（例如，前沿系统与小型基线）时，在基准上持续且显著的性能差距通常是能力差异的合理简写。困难在于，当基准结果被视为广泛能力声明的充分证据时，尤其是在模型已针对该基准进行优化的情况下。

在有限数量的基准上报告模型性能是务实且合理的。然而，代码基准实际衡量的内容与基准分数的通常解释之间似乎存在系统性的脱节。由于这种“意义差距”，在狭窄基准上的具体成就可能被夸大为关于通用编码能力的广泛断言。我们使用Qwen3-Coder-480B-A35B模型描述的例子来说明意义差距的概念。原始博客文章报告了模型在八个编码相关任务上的性能，其中五个对应于类似SWE-bench的问题解决（QwenTeam，2025 (https://arxiv.org/html/2608.13566#bib.bib57)），并将其总结为“在编码和智能体任务上都表现出色”。最后，一篇比较模型的独立博客文章声称“中国模型不仅在竞争——它们在取胜。Qwen 3 Coder在SWE-bench上以67%领先，超过了GPT-4.1的54.6%”（DigitalAppliedTeam，2025 (https://arxiv.org/html/2608.13566#bib.bib40)）。

每一步单独看都是可以理解的，但它们共同将狭窄的性能测量扩大为关于编码普遍优越性的声明，这可能影响部署决策。概念上，意义差距结合了两个过程：（i）模型和检查点创建者从基准分数到能力声明的泛化，以及（ii）普通受众从科学论文和技术报告中对这些声明的进一步放大。尽管后者可能对DL-for-code社区产生重大影响……