机器添加,人类删除:度量与缓解LLM代码编辑中的删除回避

Hugging Face Daily Papers 论文

摘要

本文介绍了CanItDelete,一个包含200个真实世界纯删除代码编辑任务的基准,并衡量了LLM如何避免删除代码。研究发现,前沿模型经常保留过时的代码,生成可通过测试但无法直接合并的补丁,并且加入以删除为重点的训练数据可以提高性能。

大型语言模型越来越多地编写和修复生产代码,但越来越多的证据表明,它们能通过测试的补丁会使代码库更难维护。我们确定了一个具体来源:删除回避(deletion avoidance),即系统性地倾向于保留那些本应被编辑操作删除的代码。在官方SWE-bench Verified排行榜上的五个领先模型中,即使是五个模型都能解决的任务,删除召回率(deletion recall,相对于开发者补丁)最高也仅达到71.7%;在超过92%的必需删除中,模型能够到达正确的文件,但只有不到52%的情况下精确删除了目标行。相反,29.0%的通过补丁会将目标代码包裹在守卫或回退逻辑中,我们将这种模式称为Guard-and-Go。这类补丁之所以能通过,是因为原始测试很少检查删除行为:当我们为34个Verified任务改造测试,使目标代码存在时测试失败,四个涵盖闭源和开源权重的前沿模型性能从63.2%下降到41.9%。由于真实修复往往混合了删除与添加,我们整理了CanItDelete——一个从真实提交中挖掘的包含200个任务的基准,这些任务的全部必要编辑都是删除。即使没有添加操作,最好的模型仍然每五个任务中会失败一个,而较小的开源模型成功率降至18.0%。随后,我们在四种累积提示下对GPT-5.6 Sol进行消融实验;在提供精确行之前,成功率几乎不变,而提供精确行后,虽然几乎消除了不完整删除,但成功率仅提升到80.5%,因为模型会删除范围之外的代码,或者转而添加代码。最后,通过一项试点研究,我们展示了一种可能的修复方法:在后训练阶段教导模型删除可以减少删除回避,并提高更广泛的代码编辑性能,这表明该行为是训练不足所致,而非无法实现。
查看原文
查看缓存全文

缓存时间: 2026/08/04 17:40

论文页面 - 增加是机器,删除是人类:测量与缓解 LLM 代码编辑中的删除回避

大量 AI 生成的补丁看起来像敷衍了事,因为前沿模型仍然难以完成我们几乎不认为软件工程师需要费心的事情:删除正确的代码并适可而止。

我们构建了 CanItDelete,从真实提交中提取的 200 个任务,其中删除就是全部编辑内容。没有重新接线,没有替换逻辑。它可以诊断保留、部分删除、过度删除和边界错误。

Claude Opus 4.8 仍然在 21% 的任务中失败,GPT-5.6 Sol 为 26%,而 GLM-5.2、Kimi K2 Thinking、MiniMax-M3 和 DeepSeek-V4-Pro 大约每三个任务就有一个失败。大多数失败都留下了需要删除的代码。

给模型提供精确的行号有所帮助,但也暴露了另一个问题。Claude 达到了 97.7%,而 GLM-5.2 仍然失败 12%,GPT-5.6 Sol 18%,Qwen3-235B 42%。对某些模型而言,更好的定位让不完整删除变成了过度编辑。

在真实的仓库工作中,这变成了“Guard-and-Go”。模型不会删除过时的逻辑,而是将其保留在守卫或回退之后,通常作为守卫未捕获输入的默认路径。在五个领先的 SWE-bench Verified 提交中,29% 的通过补丁都采用了这种方式。

这可以通过测试,但还不具备合并条件。

当我们要求代码在删除密集任务中真正消失时,解决率下降了 21.3 个百分点,三分之一的已接受补丁失败。

令人欣慰的结果是,删除是可以学会的。仅增加 0.7% 的删除聚焦数据,就将不完整删除降低了 13.9 个百分点,并将 SWE-bench Verified 提升了 5.3 个百分点。过度删除也增加了,这表明完成删除和在边界处停止是两种不同的技能。

如果编码智能体要产出可合并的代码,我们就需要像训练软件工程师那样训练它们。不仅要学会写什么,还要学会什么必须不再存在。

相似文章

编码模型做得太多了

Hacker News Top

一篇博客文章探讨“过度编辑”问题:编码大语言模型在修复简单错误时改写了过多代码,提出衡量指标与训练方法以鼓励最小化、忠实于原意的编辑。

衡量而非优化:预测LLM遗忘中的恢复

arXiv cs.CL

提出了J-Access,一种使用雅可比透镜的推理时审计方法,用于衡量未学习(unlearned)LLM中残余知识的可访问性,发现可访问性可预测恢复速度,但直接最小化它并不能促进真正的删除。