小论文评论 & AutoCodeRover

最近，我一直在阅读我研究领域——AI Agent和规划——的许多论文，我想在这里收集一些它们的TL;DRs（太长不读）和评论 💫

写评论有助于我更深入地研究材料，因为当我只是阅读时，有时我会忽略一些东西或者错误地认为我已经理解了它们。真正的理解和信心来自于当我将我所读到的内容分享给其他人时，我先在脑海中处理内容，然后通过写作，努力组织它并将其与我已有的知识联系起来。我希望通过在 Hugging Face 上分享文章，我可以取代对对话伙伴的需求，并找到动力和时间来坚持这种做法，定期分享我获得的见解。

我所有的笔记（斜体）都是主观的，并且可以讨论，所以如果您有任何意见，请在本文章下方给我留言。此外，我想提一下，我审阅这些论文是基于它们高质量的假设，这也是我选择它们进行阅读和学习的原因。然而，我的许多笔记可能包含批评或改进建议。我使用这种方法来训练自己进行批判性思维，并培养成为一名优秀研究人员所需的硬技能。所以，如果我正在审阅您的论文，请不要往心里去 🤗

AutoCodeRover：自主程序改进

而第一项，希望不是最后一项我将在此展示和理解的工作将是 AutoCodeRover。

📄 AutoCodeRover：自主程序改进
👩‍💻 https://github.com/nus-apr/auto-code-rover
🌐 https://autocoderover.dev

主要思想和结果

这篇论文提出了另一个 SWE 代理。通过添加复杂的代码搜索功能、基于 AST 的项目树表示（而非文件集合）和测试执行，他们声称解决了 SWE-bench-lite 中 19% 的问题，平均处理 57 个 GitHub 问题约 4 分钟，每个问题花费 0.43 美元。

背景

当前SWE-bench任务和解决方案的简要概述。任务：给定问题和仓库内容（Python语言，排名前12的开源仓库），你需要解决该问题（通过所有隐藏测试）。在论文中的表格中，他们将自己的解决方案与之前依赖的解决方案进行了比较，因此排行榜如下所示

解决方案

工作流程分为两个阶段：(1) 上下文检索循环，使用 API Agent 搜索足够的上下文；(2) 补丁生成循环，生成问题修复补丁，直到其中一个适用。每个阶段都调用单独的基于 LLM 的 Agent。

上下文检索

为了进行上下文检索，他们建议使用不同粒度的代码搜索工具。

注意：为了最小化上下文大小，作者将签名和内容分离，并使用API进行检索，假设LLM会首先调用签名API，然后仅在认为必要时才请求内容。然而，检查轨迹是否证实了这一假设会很有趣，因为如果此类签名API调用总是伴随着内容调用，我们就可以只保留第二个调用并减少工具调用次数。

API 以分层策略调用。在每个层级中

1. 提示 LLM 根据当前上下文（问题陈述 + 迄今为止搜索到的代码）选择一组必要的 API 调用
2. 提示 LLM 分析当前上下文是否充分

注：没有附录揭示提示，从代码中也很难读懂。此外，在仓库中发现的提示不包含任何关于上下文“必要性”和“充分性”的示例（依赖于零样本方法），因此对我来说，很难相信作者和 LLM 本身在结果上下文相关性方面的判断。

补丁生成

在收集到的上下文的基础上，代理迭代地尝试生成“适用”的问题解决补丁。作为额外的改进，作者应用了 Python 代码规范检查器来控制缩进。代理被允许重试，直至达到预设的尝试限制（目前设置为三次），之后将返回迄今为止最好的补丁作为输出。

注意：如果上下文不完整（例如，要修复的方法正确，但其中添加的行数不足）怎么办？在这种情况下，我们永远无法得到正确的补丁。也许我们可以在这里提供一些工具，以便在需要时扩大检索到的代码内容区域？此外，作者没有详细说明额外的内容长度（+/- 3 行），那么 5 行是否是最佳的呢？

评估

• 基准测试：来自 SWE-bench（与 Devin 比较）和 SWE-bench-lite 的完整数据集和 25% 的随机子集。
• 基线和评估指标：与 Devin 和 SWE-Agent 进行比较。所有值均为三次尝试的平均值。报告了 pass@1 和 pass@3 指标。至于指标，作者使用了：(1) 已解决实例的百分比，(2) 平均时间成本，以及 (3) 平均 token 成本来评估工具的有效性。
• 实现和参数：gpt-4-0125-preview，温度=0.2，最大 token 数=1024。

RQ1: AutoCodeRover 在多大程度上能够像人类开发者一样自动化软件问题？

结果显示在下表中。

• AutoCodeRover 和 SWE-agent 在不同场景下互补。
• AutoCodeRover 在 SWE-agent 解决的 23 个独特实例上失败的主要原因是未实现的搜索 API。注意：但我没有弄清楚他们所说的未实现的搜索 API 是什么意思。
• 总的来说，在 SWE-bench lite 上，AutoCodeRover 的正确率为 65.4%（51 个正确/78 个合理）。合理的程序补丁通过了给定的测试（但不总是等同于开发人员的补丁）。
• AutoCodeRover 绝大多数过拟合补丁（除了 2 个之外的所有过拟合补丁）都修改了与开发者补丁相同的方法，但代码修改是错误的。
• 一个原因是问题创建者在描述中给出了初步补丁。这个补丁可能与最终的开发者补丁不同，从而误导了 LLM。
• 另一个有趣的原因是问题创建者提到了一个需要处理的案例。LLM 只修复了提到的案例，但开发者也修复了其他类似的案例。

RQ2: 现有的调试/分析技术能否帮助 AutoCodeRover？

作为一项附加实验，作者尝试为代理配备方法级基于谱的故障定位 (SBFL)。该技术通过分析测试执行结果来识别潜在的易错代码。至于测试套件，可以使用目标任务实例的开发人员测试套件（数据集中提供）。利用 SBFL 的提议方法是在上下文检索阶段之前将其输出添加到上下文中，希望该信息可以扩展问题文本中的提示，并促使代理关注故障代码元素。此外，在补丁生成阶段，他们建议运行测试套件，如果失败，则最多重新生成补丁 3 次。

注意：据我所知，SWE-Bench 不仅包含 Bug 报告，还包含新功能问题，因此在这种情况下，SBFL 可能会偏向 Agent。也许更合理的方法是先将问题分类为与 Bug 相关或不相关，然后仅将 SBFL 应用于与 Bug 相关的问题。

• 从 19% 增加到 22% 注：出乎意料的是，提升幅度不大。
• ACR-sbfl 仍然独立解决了 7 个在其他任何运行中都未解决的任务实例。

RQ3: AutoCodeRover 和未来全自动程序改进面临的挑战是什么？

• 成功：生成的补丁解决了问题。
• 错误补丁：生成的补丁修改了开发者补丁中所有被修改的方法。这意味着补丁内容是错误的，但补丁位置是正确的。
• 正确文件中的错误位置：生成的补丁修改了正确的文件，但在文件中的位置是错误的。
• 错误文件：生成的补丁修改了错误的文件。
• 无补丁：从检索到的上下文中未生成任何补丁。

注意：如果我们简单地向 LLM 提供补丁必须通过的开发者测试套件怎么办？这种预言机估计可以更好地帮助评估测试提示的最大潜力。此外，如果结果良好，我们可以进一步探索根据问题文本生成测试套件！！！这听起来像是一个值得尝试的好研究吗？

总结

总的来说，这篇论文对于那些希望为 SWE 代理配备测试生成和调试等 SE 工具的人来说是鼓舞人心的。然而，缺乏对所提议工具的消融研究是一个缺点，因为它本可以阐明某些细节并支持我笔记中提到的假设。尽管如此，实验设置和评估的质量和清晰度都很好。