测量与缓解LLM代码编辑中的删除规避倾向

研究表明，大型语言模型编写和修复代码时存在删除规避倾向，即保留本应删除的代码。在SWE-bench Verified排行榜前五模型中，删除召回率最高仅71.7%，且超过29%的通过补丁采用Guard-and-Go模式包裹目标代码。若测试检查删除，模型性能从63.2%降至41.9%。为此，研究者构建了CanItDelete基准并验证了后训练指导的修复效果。

此前关注LLM代码生成能力，但忽视其维护性影响。该研究首次系统量化LLM的删除规避问题，显示模型更倾向添加而非删除代码，导致代码库累积冗余，增加维护负担。若测试不检查删除，模型可能以“伪通过”掩盖问题，影响LLM在真实开发中的可靠性。

LLM在训练中可能偏向于最小化风险或受数据中常见模式影响，导致规避删除操作。Guard-and-Go模式通过包裹代码而非删除来通过测试，说明现有测试集未覆盖删除场景。后训练阶段加入删除任务可部分缓解该问题，但仍存在删除过度或误添加的副作用，表明模型对删除操作的理解不完备。

对于依赖LLM进行代码编辑的产品（如AI编程助手），删除规避会导致代码库冗余和可维护性下降。测试集需补充删除类用例，否则模型性能被高估。模型供应商需在后训练中强化删除任务，以提升修复质量，减少人工干预成本。

• 开发辅助工具自动检测Guard-and-Go模式补丁，提示开发者可能未真正删除目标代码。
• 在代码评审流程中集成删除召回率指标，帮助团队评估LLM编辑质量。
• 构建删除类测试集，供模型训练和评估使用，提升模型对删除操作的理解。
• 提供后训练模块或微调服务，专门提升模型的删除能力，减少冗余代码。

• 删除规避是否广泛存在于其他编程任务或代码语言中？
• 后训练指导的持续效果如何？是否会引入新的偏差？
• 测试集CanItDelete的覆盖范围是否足以代表真实部署场景？
• 模型删除过度或误添加问题能否通过调整推理策略缓解？