weixin_44465920的博客

DEBUGEVAL 引入了四个不同的任务来评估 LLMs 的调试能力。这些评估任务包括错误定位（BUG Localization）、错误识别（BUG Identification）、代码审查（Code Review）和代码修复（Code Repair）。DEBUGEVAL 的数据统计如表 I 所示。对于每个任务，分别使用 Python、C++ 和 Java 提供问题，以评估 LLMs 在不同编程语言上的调试性能。

近年来，基于大语言模型（LLM）的代理推动了自动软件工程（ASE）的显著发展。尽管已有方法被验证有效，但现有方法的设计主要关注代码的局部信息，例如问题、类和函数，这导致在捕获软件系统的全局上下文和相互依赖关系时存在局限性。根据人类软件工程开发者的实际经验，我们认为全面理解整个代码库将是实现自动软件工程的关键路径。然而，理解整个代码库会带来各种挑战，例如超长的代码输入、噪声代码信息、复杂的依赖关系等。

虽然大型语言模型（LLMs）的编码能力迅速发展，但相应的真实编程环境评估基准尚未跟上步伐。构建一个可扩展且互动的测试平台，用于评估通用 AI 编程代理在真实代码中的表现一直具有挑战性，主要是因为缺乏高质量的测试套件。在本文中，我们提出了 Repository to Environment (R2E)，这是一个框架，可以将任何 GITHUB 仓库转变为测试环境，以评估代码生成系统（包括静态和交互式）的性能。R2E 结合了程序分析和 LLMs 的协同作用，构建了任何 GITHUB 函数的等效测试工具。

神经网络（NN）在以前未见过的数据类型（分布外数据或OOD）上的行为通常是不可预测的。如果网络的输出用于决策安全关键系统，这可能是危险的。因此，检测输入是否为OOD对于NN的安全应用至关重要。验证方法无法扩展到实际的NN，使得运行时监控在实际使用中更具吸引力。尽管最近提出了各种监控器，但对特定问题的优化以及彼此之间的比较和结果重现仍然具有挑战性。我们为NN监控器的用户和开发人员提供了一种工具。

大型语言模型（LLM）已成为代码生成任务的首选工具（如GPT-4和Claude-3.5），展示了其根据用户描述合成代码片段的能力。然而，与单一、独立问题的主要评估设置相比，应用LLM解决代码库级别的软件工程任务仍未得到充分研究。软件工程任务如特性添加、程序修复和测试生成需要不仅理解文件内的信息，还要理解文件之间的依赖关系。为了弥补这一差距并评估工具自动解决现实世界软件工程问题的能力，开发了流行的SWE-bench基准测试。每个问题包含一个现实世界的GitHub问题描述及对应的Python代码库。