来源笔记
On the Role of Fault Localization Context for LLM-Based Program Repair
摘要
本文研究故障定位上下文对基于 LLM 的程序修复有多大帮助。作者在 500 个 SWE-bench Verified 任务上使用 GPT-5-mini 进行实验，发现文件级上下文最重要，更宽的上下文只在部分情况下有帮助，额外的行级上下文往往会带来负面影响。
问题
- 基于 LLM 的程序修复仍然依赖故障定位，但以往工作没有测试文件级、元素级和行级上下文如何影响修复成功率。
- 更多上下文可能帮助模型理解 bug，也可能引入无关代码、提高 token 成本，并掩盖真正的修改位置。
- 这对 APR 系统设计很重要，因为在大型代码库中，定位会同时影响修复质量和推理成本。
方法
- 作者在 500 个 SWE-bench Verified 实例上，使用 GPT-5-mini 做了一个包含 61 种故障定位配置 的因子研究。
- 他们在三个层级上变化上下文：文件（无、bug 文件、基于规则的相关文件、LLM 检索文件）、元素（无、bug 元素、调用图元素、LLM 检索元素）和 行（无、bug 行、±10 行窗口、静态切片、LLM 检索行）。
- 为了隔离上下文质量的影响，他们使用 真实补丁位置 来定义有问题的文件、元素和行，然后测试超出这些位置扩展上下文是否有帮助。
- 他们比较了语义型 LLM 检索和结构化启发式方法，并同时测量上下文大小和 token 成本。
结果
- 文件级上下文是主要驱动因素：加入文件上下文带来相对无文件基线 15–17 倍 的提升。
- 当提示中包含大约 6–10 个相关文件 时，成功修复最常见。
- 基于 LLM 的文件检索 在大多数设置下优于基于规则的文件扩展，而且使用的上下文更少：LLM 检索平均为 8.54 个文件 / 58,273 个 token，而基于规则的检索为 18.12 个文件 / 96,237 个 token。
- 真实 bug 文件平均为 1.25 个文件，每个实例大约 12,131 个 token。
- 元素级上下文 比没有元素信息更有帮助，但在 bug 元素之外继续扩展是否有效，取决于文件上下文质量；在大多数配置中，LLM 检索的元素 比 调用图元素 表现更好。
- 行级扩展往往会拖累效果：上下文窗口和静态切片经常降低修复性能，而精确的 bug 行 表现更好；该摘要没有报告 61 种配置全部对应的完整修复率百分比。