登陆注册
10674

码农狂喜!微软提出CodePlan,跨168个代码库编码任务,LLM自动化完成

站长网2023-10-05 09:09:550

这一次,微软提出的CodePlan让码农的生产力又提高了!

对于大模型来说,擅长的是本地化编码任务。

但如果任务跨越了多个相互依赖的文件,LLM却无法解决。

对此,微软研究人员设计了一个任务无关的神经网络框架,名为CodePlan。

论文地址:https://arxiv.org/pdf/2309.12499.pdf

论文中,CodePlan综合了多步骤编辑链(chain-of-edits),是一种将程序分析、规划和LLM结合在一起的新方法。

一起来具体看看,CodePlan是如何设计的?

CodePlan:大模型 规划

软件工程活动中,例如软件包迁移、修复静态分析或测试的错误报告,以及向代码库添加类型提示或其他规范,涉及到对整个代码存储库的普遍编辑。

研究人员将这些活动规划,为「存储库级别的编码任务」。

随着编码工具如GitHub Copilot、Code Whisperer得到了大模型能力加持,已经为码农在本地化编码问题提供了解决方案。

然而,现实是,「存储库级别的编码任务」更加复杂,不能直接通过LLM解决,因为存储库中的代码是相互依赖的,整个存储库可能太大而无法纳入提示。

这项研究中,微软团队将库级编码框架作为一个规划问题,并提出了一个任务不可知的框架,称为CodePlan。

CodePlan综合了一个多步骤的编辑链(计划) ,其中每一步都会调用代码位置上的LLM。该代码位置上的上下文来自整个存储库、以前的代码更改和特定于任务的指令。

CodePlan是基于增量依赖分析、变更可能影响分析和自适应规划算法的新型组合。

如下图,展示了复数库API的变化,微软研究人员的任务是根据这一变化迁移代码库。

图3左侧显示了代码库中使用复数库的相关部分。

具体来说,Create.cs文件中的方法func,调用了库中的create_complex方法,Process.cs文件中的方法Process.cs调用了func。

研究人员将图1中的任务描述和func主体传递给LLM,以生成修改后的func代码,如图3右侧所示。

可以看到,LLM已经正确地编辑了对create_complex API的调用,以便它返回一个Complex类型的对象,而不是两个浮点值的元组。

注意,这个编辑导致了方法func的签名发生了变化——它现在返回了一个Complex类型的对象。

这就需要修改方法func的调用者,比如Process.cs中的process方法,如图3左下角所示。如果不对process方法的主体进行适当的修改,代码就不能构建!

图3右下方显示了对process方法的适当修改,它能使版本库达到一致的状态,从而在编译时不会出错。

对于研究人员来说,最主要的是构建一个「存储库级别的编码系统」,能自动生成编辑所需的派生规范。

LLM驱动的库级编码任务定义如下:

CodePlan整体框架中,输入是一个存储库、一个通过自然语言指令或一组初始代码编辑表达种子规范的任务,一个正确性oracle和一个 LLM。

CodePlan构建了一个计划图,图中的每个节点都标识 LLM需要履行的代码编辑义务,而边则表示目标节点需要在源节点之后履行。

CodePlan监控代码编辑,并自适应地扩展计划图。

一旦计划中的所有步骤都已完成,存储库将由oracle进行分析。如果oracle验证了资源库,则任务完成。如果发现错误,错误报告将作为下一轮计划生成和执行的种子规范。

此外,CodePlan算法还维护了一个依赖关系图,图4说明了依赖关系图的结构。

刷新SOTA

研究人员评估了CodePlan在两个存储库级任务上的有效性: 包迁移 (C#)和时态代码编辑(Python)。

每个任务在多个代码库上进行评估,每个代码库都需要对多个文件(2-97个文件)进行相互依赖的更改。

这种复杂程度的编码任务,以前从未使用过LLM自动完成。

研究结果表明,与基线相比,CodePlan更符合基本事实,能够让5/6个存储库通过有效性检查,比如,无差错构建和正确的代码编辑。

总之,CodePlan为自动化复杂的库级编码任务提供了一种有前途的方法,既提高了生产率,又提高了准确性。

它成功应对了许多挑战,为高效可靠的软件工程实践开辟了新的可能性。

参考资料:

https://twitter.com/adityakanade0/status/1706291449674039711

0000
评论列表
共(0)条