[Paper] 长上下文推理在自动化 Bug 修复中的局限性

Source: arXiv - 2602.16069v1

Overview

本文调查了 AI‑for‑coding 社区中的一个热门说法：当今的大型语言模型（LLMs）凭借其巨大的上下文窗口，能够“看到”并推理整个代码库。通过在人为扩大的上下文上严格测试代理式工作流和单次生成，作者揭示了名义令牌限制（64 k–128 k）与模型实际生成正确 bug‑fix 补丁能力之间的巨大差距。

关键贡献

• Systematic benchmark 使用 SWE‑bench Verified 对比 agentic 与 single‑shot 长上下文调试。
• Empirical evidence 表明成功的 agentic 运行保持在约 20 k token 以下，即使模型声称拥有更大的窗口。
• Controlled long‑context experiment 在保证文件检索完美的前提下扩大输入规模，以隔离纯粹的推理能力。
• Quantitative results 显示解决率出现显著下降（例如 GPT‑5‑nano 在 64 k token 时为 0 %，Qwen3‑Coder‑30B‑A3B 为 7 %）。
• Qualitative failure taxonomy（幻觉 diff、错误的文件目标、格式错误的补丁头）阐明了为何更长的上下文会导致失败。
• Critical insight 当前的 agentic 编码基准并未真正衡量长上下文推理能力。

方法论

1. Agentic Harness (mini‑SWE‑agent) – 作者将最先进的 LLM（GPT‑5‑nano、Deepseek‑R1‑0528 等）包装在一个循环中，能够检索文件、运行测试并迭代地完善补丁。
2. Token‑level tracking – 对每一次成功运行，他们记录累计的 token 数，以了解模型实际消耗了多少上下文。
3. Long‑Context Pipeline – 他们通过连接 所有 仓库文件（最多 128 k token）来构建每个 bug‑fix 任务的“拉伸”版本，同时确保相关文件在其中，从而消除检索错误。
4. Single‑Shot Generation – 模型接收大量上下文，并被要求一次性输出补丁，无需任何迭代反馈。
5. Evaluation – 解决率（生成的补丁通过测试套件的任务比例）是主要指标；额外的人工检查揭示了系统性错误模式。

结果与发现

• Agentic 成功与短上下文步骤相关：即使是表现最好的运行也从未超过约 20 k 令牌，这表明“长上下文”优势并未得到利用。
• 随着上下文增长，性能急剧下降：一旦输入超过约 64 k 令牌，模型生成正确 diff 的能力就会骤降。
• 失败模式：随着上下文长度增加，出现幻觉或语法无效的 diff、将补丁应用到错误文件、以及缺失/乱码的补丁头部等问题变得常见。

Practical Implications

• 工具设计者不应假设“大上下文 = 更好调试”。 Agentic 流程需要保持每一步推理简洁，并优先考虑高效检索，而不是一次性倾倒整个代码库。
• LLM 提供商可能需要重新思考上下文窗口的营销。 实际的编码助手应公开“可用上下文”指标，而不是原始的 token 限制。
• 开发者仍然可以从 LLM 中受益，通过构造提示聚焦于 相关 文件，并使用迭代的测试‑反馈循环，而不是尝试单一的 “所有代码一次性提示” 方式。
• 开源模型用户 可以在不等待专有巨头的情况下取得竞争力的结果（例如 Deepseek‑R1），前提是采用 agentic 分解策略。
• 基准设计者 应加入长上下文压力测试，将检索与推理分离，以确保未来的评估真正衡量预期的能力。

Limitations & Future Work

• 该研究仅使用了单一基准（SWE‑bench Verified）；在其他领域（例如系统代码、UI 框架）上的结果可能会有所不同。
• 人为地膨胀上下文可以保证完美的文件召回，但真实场景中的检索错误和噪声仓库未被考虑。
• 只评估了少数几种 LLM；具有更复杂记忆机制的更新模型可能表现不同。
• 未来的研究可以探索混合方法（例如外部向量存储 + LLMs）或专门针对长上下文代码推理的微调策略。

作者

• Ravi Raju
• Mengmeng Ji
• Shubhangi Upasani
• Bo Li
• Urmish Thakker

论文信息

• arXiv ID: 2602.16069v1
• 分类: cs.SE, cs.LG
• 发表时间: 2026年2月17日
• PDF: 下载 PDF