IJCAI 22 | 面向第三方代码库的代码生成

PaperReview 一个分享Review的平台

论文：

CERT: Continual Pre-Training on Sketches for Library-Oriented CodeGeneration

单位：

中国科学院，微软亚洲研究院，Korea University，微软Azure

投稿状态：

已中稿 IJCAI 2022

文章链接：

https://arxiv.org/pdf/2206.06888.pdf

Review链接：

IJCAI没有提供open review，本篇为作者提供题材。

其他资源：

https://github.com/microsoft/PyCodeGPT

Who	Recommendation (Total/10)
review#1	3: Weak Reject -> 5:Boraderline Accept
review#2	5: Boraderline Accept
review#3	7: Clear Accept
review#3	7: Clear Accept

01

摘要

代码生成是长期以来的挑战，目的基于自然语言描述生成代码片段。通常，对于训练一个代码生成模型来说，昂贵的文本-代码数据对是非常重要的。最近，由于预训练技术取得了成功，在大规模无标签的代码语料上训练得到的LLMs，能够在代码生成上表现非常好。在这篇文章中，我们调研了如何利用无监督的代码语料去训练一个面向代码库的代码生成模型。因为对于程序员来说去重复使用第三方库是非常常见的事情，在这种情况下，考虑到非常多的代码库，获得text-code数据对是非常困难的。我们观察到面向库的代码片段是更有可能分享相似的代码骨架(code sketches)。因此，我们提出了CERT，它拥有两个步骤：一个sketcher去生成sketch，然后一个generator去为生成的sketch填充细节。Sketcher和generator都是经过在无标签的语料在base model上持续预训练的模型。更进一步，我们创造了两个标准数据集，命名为：PandasEval和NumpyEval去评价面向第三方库的生成。实验结果证明CERT的优异性能。例如，在PandasEval pass@1上，它提升了base model绝对15.67%。我们的工作已经公布在：https://github.com/microsoft/PyCodeGPT。

02

引言

代码生成在人工智能社区是一个长期的挑战，它意在为给定的自然语言描述生成一个代码片段。通常，为了训练一个性能良好的代码生成模型，大量的text-code数据对是必不可少的。然而，构建这么一个数据集是非常昂贵且耗时的。为了避免这个问题，启发于GPT-3强大的零样本(zero-shot)自然语言生成能力

代码生成在人工智能社区是一个长期的挑战，它意在为给定的自然语言描述生成一个代码片段。通常，为了训练一个性能良好的代码生成模型，大量的text-code数据对是必不可少的。然而，构建这么一个数据集是非常昂贵且耗时的。为了避免这个问题，启发于GPT-3强大的零样本(zero-shot)自然语言生成能力，近些年已经关注到使用大规模的代码语料(例如：GitHub)去训练一个LLM以进行代码生成，然后期待这些模型能够直接应用在代码生成任务上，不需要在昂贵的text-code数据对上finetune，且能够工作的比较好。例如，Codex 12B能够解决28.8%的standalone Python编程问题。

在这篇文章中，我们主要关注于：在代码语料上预训练的语言模型(不经过任何finetune)是否且如何生成面向库的代码片段，而不是standalone代码片段。在软件发展期间，程序员为了实现特定的功能，调用第三方代码库(例如：Pandas，NumPy)是非常常用的事情。对于程序员来说，学习如何正确地使用这些库是不容易的。例如，根据我们的统计，在StackOverflow的带有“Python”标签的帖子中至少还有一个第三方库的标签。另外，对于第三方代码库的代码生成，在没有成对数据去训练一个代码生成模型的必要性又增加了，因为程序员通常需要在不同的场景下使用不同的库，导致为大部分的库标注text-code数据对是不显示且昂贵的。

在这篇文章中，我们主要关注于：在代码语料上预训练的语言模型(不经过任何finetune)是否且如何生成面向库的代码片段，而不是standalone代码片段。在软件发展期间，程序员为了实现特定的功能，调用第三方代码库(例如：Pandas，NumPy)是非常常用的事情。对于程序员来说，学习如何正确地使用这些库是不容易的。例如，根据我们的统计，在StackOverflow的带有“Python”标签的帖子中至少还有一个第三方库的标签。另外，对于第三方代码库的代码生成，在没有成对数据去训练一个代码生成模型的必要性又增加了，因为程序员通常需要在不同的场景下使用不同的库，导致为大部分的库标注text-code数据对是不显示且昂贵的。

图1：一个Python的例子：多个使用Pandas的代码片段，在经过匿名化用户定义的术语之后，可能具有相同的sketch。

相比于standalone的代码片段，面向库的代码片段更容易共享相似的代码骨架(sketches)。sketch是经过匿名化用户定义的术语之后的代码结构，例如变量名字，方法名字，常量等。这在之前软件数据挖掘(software data mining)的研究工作中被命名为API usage pattern。其中图1展示了一个例子。经过匿名化变量和常量之后，多个使用Pandas API的代码片段可能会拥有相同(或者相似)的代码骨架。基于这个观察，一个自然的想法就是将面向库的代码生成任务分解成两个子任务：生成骨架，然后为骨架填充细节。基于这个想法，许多方法已经在不同的代码生成任务上被提出，例如Coarse-to-Fine和PlotCoder，这已经能够证明这个想法能够提升生成的代码片段的质量。然而，这些方法被提出应用于finetune阶段，这需要大量的高质量的text-code数据对去作为监督信号，做这个两阶段的生成任务。因此，在我们没有提供大量数据对的场景中，一个研究问题就被提出了：如何利用代码骨架的想法在无标签的代码语料上通过预训练来增强语言模型，最后能够提升面向第三方代码库的生成质量？

为了迎接这个挑战，我们提出了CERT(for sketCher and gEneRaTor)，一个在代码骨架上针对面向代码库的代码生成的持续预训练的方法。在CERT中，sketcher首先关于于预测代码骨架，这是忽略了用户细节的；然后，generator使用代码骨架作为提示去生成完整的代码。Sketcher和generator都是使用无标签的代码语料，而不是成对的text-code数据针对code在base model上进行持续预训练的。另外，我们为Python库制作了两个标准评价数据集，叫做PandasEval和NumpyEval，每一个分别包括101个用Pandas和Numpy编写的编程问题。我们在CERT上做了大量的实验。结果证明CERT在第三方代码库生成上具有优异的性能。我们也进一步通过分析提出了一些见解。

怼怼批注

不像上面的摘要和引言我们严格按照论文进行了人工翻译，在下面的方法、实验章节我们仅列原论文的关键部分。如有需要可查看原文去了解详情。

03

方法

这个章节主要介绍了base model(使用的是我们自己训练的PyCodeGPT和CodeGen)，另外跟着CERT是如何设计的。

这儿我们就主要说一下CERT的推理(图2)和训练过程(图3)。

图2：CERT的总览：一个sketchor和一个generator。

图3：使用Pandas的一个例子去说明sketcher和generator的训练数据准备和训练过程。

04

实验

在我们自己构建的PandasEval和NumpyEval上的实验结果，baseline包括：CodeT5，CodeGPT，CodeClippy，CodeParrot等。根据结果显示CERT带来的提升还是非常明显的。

除了这些主实验，本文还将CERT应用到standalone的代码生成中，发现提升不大。另外，本文还对比了不同的sketching类型；分析了生成的sketch的质量；并且使用GPT-3和Codex这种gigantic models对我们提出的数据集进行了实验。

05

总结

在这篇文章中，我们为面向库的代码生成提出了一个新颖的方法CERT。它利用代码骨架，并且由sketcher和generator组成。Sketcher和generator都是在大量无标签的代码语料上基于base model进行持续预训练的模型。另外，我们制作了两个数据集去评价面向库的代码生成，命名为PandasEval和NumpyEval。实验结果和详细的分析都展示了CERT的有效性。在未来的工作中，我们对具有更少数据的私有库的代码生成非常感兴趣。

怼

Review#1

分数@3/10

Sketch的粒度是多少？

防

Rebuttal

正如第3.2节中generator段落所描述的，粒度是在函数和类的层面上。我们使用脚注中提到的pip工具来自动拆分块。此外，CERT支持多行代码生成。评估基准PandasEval和NumpyEval都需要多行代码生成，而CERT可以在它们上面表现良好。

怼

Review#1

分数@3/10

Skether和generator在一起配合的细节是缺失的。

防

Rebuttal

我们在第3.2节中详细阐述了这些细节。第一段描述了推理过程，在这一过程中，sketcher和generator共同工作（图3清楚地显示了这一点。），剩下的部分是不断进行预训练以获得sketcher和generator的过程。

怼

Review#1

分数@3/10

考虑到两阶段之间的错误放大，为什么两阶段代码生成比端到端方法更好？

防

Rebuttal

虽然CERT是两阶段的，但它没有被错误放大影响。这是因为sketch只是作为generator的prompt，而不是严格的模板（如第5.2节中生成的sketch质量的最后三行所述）。我们还在第5.3节案例3中提供了一个案例研究，即sketcher做了一个错误的预测，generator对其进行了纠正，最终生成了正确的代码。

怼

Review#1

分数@3/10

这项研究与一般的代码生成有什么区别？CERT的技术新颖性较低，因为它看起来与一般的语言模型非常相似，没有考虑到库的特性。

防

Rebuttal

在第1节的第三段中，我们已经讨论了激励我们CERT的库特征：面向库的代码更有可能共享类似的sketch，而一般的（standalone）代码则没有，这在软件工程界是公认的API pattern。图1显示了一个实际案例。然而，我们的 CERT是第一个利用这种模式来加强预训练语言模型的工作，从而提高面向库的代码生成的质量。其他reviewers也强调了这一创新之处，并表示赞同。

怼

Review#1

分数@3/10

在与baselines比较时，这是不公平的，因为baselines不是用你收集的代码语料训练的。

防

Rebuttal

在大模型时代，很难保证提出的模型使用与所有baselines相同的预训练数据，因为预训练的成本太高。CodePyramid、CodePyramid-XL和CERT使用相同的语料库。CERT在PandasEval和NumpyEval上能够持续地以较大的优势胜过两个baselines，这一事实足以证明我们提出的sketcher-generator想法的优越性。重新训练baseliens模型不属于我们的范围。

怼

Review#1

分数@3/10

PyCodeGPT在HumanEval上的表现明显优于baselines模型（CodeClippy和CodeParrot）；为什么会有这么大的差异？

防

Rebuttal

PyCodeGPT的改进来自于：1）大量精心清理的数据用于预训练；2）重新训练的tokenizer，专门用于python，以及3）优先考虑高质量数据的重采样(re-sample)策略。由于篇幅有限，我们在论文中只简单介绍了PyCodeGPT。PyCodeGPT的设计细节不是我们论文的重点，我们将在另一份技术报告中详细介绍它，并将其公开给社区进行进一步研究。

怼

Review#2

分数@5/10

作者是否会公开这项工作？

防

Rebuttal

是的，我们会公开。

怼

Review#2

分数@5/10

如果本文能在面向库的代码语料库上进一步预训练PyCodeGPT，可能会更加公平。

防

Rebuttal

我们完全同意你的观点。PyCodeGPT-XL正是你所说的``PyCodeGPT-NumPy'和``PyCodeGPT-pandas'。正如第5.1节第二段所述，``PyCodeGPT-XL是在提取的面向库的文件上持续预训练的PyCodeGPT'。

怼

Review#3

分数@7/10

HumanEval应该在被介绍的引用。

防

Rebuttal

谢谢，我们会在最终版本中添加参考资料并加以说明。

怼

Review#4

分数@7/10

目前工作的主要局限性是什么，如果有的话？

防

Rebuttal

CERT需要对库的代码文件进行持续预训练。如果一个库是新的或私有的，并且没有可用的代码文件，那么CERT可能没有用。这也是我们未来的工作之一。

怼

Review#4

分数@7/10

What are the threats to the validity with respect to generalizability? (此处不翻译了，怕不精确)

防

Rebuttal

我们已经进行了大量的实验，表明CERT可以提高Python上面向库的代码生成的质量。当我们将其推广到其他编程语言（如Java、C和C++）时，可能存在威胁，因为不同编程语言的第三方库的特性略有不同。

PaperReview会分享顶会paper的review和rebuttal，希望大家能够从中学会如何做科研，从而为国家的科研工作贡献出自己的一份力量。历史分享的paper已经收录在GitHub项目中，欢迎star和fork。

https://github.com/PaperReviewer/PaperReviewer.github.io

我们还开通了网页版的PaperReview，欢迎访问和收藏。

https://paperreviewer.github.io

同时，我们还开放了PaperReview的交流群，可以添加怼怼入群。