Agentic Repository Mining: A Multi-Task Evaluation
本文表明，能够通过 bash 命令动态探索软件仓库的大语言模型代理，在分类准确率方面与预构建上下文方法相当，同时在应对上下文窗口限制方面表现出更优的鲁棒性，且其扩展能力独立于工件规模。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你正试图弄清楚一个庞大软件项目中的某段特定代码究竟在做什么。它是在修复一个漏洞吗？还是仅仅是一个拼写错误？或者它是一个安全风险？
在过去，人类必须完成这项侦探工作。他们会阅读代码，查看相关文件，检查历史记录，然后做出判断。这既缓慢又昂贵，而且有时人们会因为疲惫而犯错。
最近，我们尝试使用人工智能（大型语言模型，或称 LLM）来执行这项工作。但这里有一个陷阱：上下文是王道。
两位侦探：“公文包”与“探索者”
这篇论文比较了两种利用人工智能解决这些谜题的方法：
1. “公文包”侦探（简单 LLM）
想象一位侦探被递来一个预先打包好的单一公文包。里面装着特定的文件、特定的注释，也许还有项目的摘要。有人告诉这位侦探：“只阅读公文包里的内容，然后告诉我发生了什么。”
- 问题所在： 如果公文包太重（文本太多），侦探的大脑就会过载，无法作答。如果公文包缺少关键线索（例如来自上三层文件夹的文件），侦探就不得不猜测，而且往往猜错。
- 论文发现： 这些侦探便宜且快速，但当“公文包”变得太大，或者他们需要跳出框框思考时，他们就会力不从心。
2. “探索者”侦探（智能体 LLM）
现在，想象一位侦探被直接空降到实际的软件工厂，并配备了一套标准工具（如手电筒、放大镜和地图）。他们被给予一个起点（例如：“查看这行特定的代码”）。
- 工作方式： 他们不等待公文包。他们四处走动。他们打开下一扇门的门（
ls），阅读他们需要的特定页面（cat），搜索关键词（grep），并检查历史记录（git log）。他们只阅读解决特定谜题所需的内容。 - 论文发现： 这些侦探稍微贵一些（需要更多的时间和“令牌”来思考），并且因为需要四处走动而移动较慢。然而，他们永远不会被巨大的工厂压垮，因为他们只拾取所需的线索。他们要稳健得多。
大型实验
研究人员在软件中发现的四种不同类型的“谜题”上测试了这两位侦探：
- 纠缠的提交（Tangled Commits）： 这行代码究竟是在修复漏洞，还是仅仅在清理空白字符？
- 安全审查： 代码审查中的这条注释是否在谈论一个安全漏洞？
- 维护： 这次更新是在修复漏洞、适应新系统，还是仅仅为了让界面更美观？
- 项目类型： 这个 GitHub 仓库是一个真实的软件项目，还是仅仅是一个学生的家庭作业？
他们进行了近 5,000 次测试。
结果：谁赢了？
准确率： 平局。
令人惊讶的是，“探索者”（智能体）的准确率与“公文包”（简单 LLM）一样高，尽管探索者必须自己寻找线索，而公文包则是直接获得线索。这是一个重大突破，因为它意味着人工智能可以在人类预先选择文件之前，自行判断需要寻找什么。
稳健性（真正的赢家）：
当文件过大时，“公文包”侦探不断失败。他们的“公文包”变得太重，导致崩溃（这被称为“上下文溢出”）。
“探索者”侦探从未崩溃。无论软件项目多么庞大，他们只是继续走动，只阅读所需的小片段。
成本：
探索者的成本更高（大约高出 1.2 到 3 倍），但这仅仅是因为他们走了更多的步骤。然而，如果项目非常庞大，探索者实际上会变得更便宜，因为公文包侦探会崩溃并需要重新启动，或者完全失败。
“地面实况”的惊喜
研究人员还查看了两位侦探都与人类专家（即“地面实况”）意见不一致的情况。
他们发现，通常人类专家是错误的，或者规则令人困惑。
- 示例： 有时，人类因为缺乏足够的上下文而将某项更改标记为“不明确”。“探索者”人工智能在走遍整个工厂后，找到了缺失的证据，并给出了清晰的答案。
- 教训： “正确”的答案实际上可能是人工智能找到的那个，而不是人类最初写下的那个。人工智能洞察全局的能力揭示出，原始标签有时是基于有限的信息。
一句话总结
使用能够“四处走动”并自行搜索代码仓库的人工智能智能体，与给人工智能一个预先打包的摘要一样聪明，但在代码庞大时它要可靠得多，而且它经常揭示出原始的人类标签遗漏了重要的上下文。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。