文章翻译|CODET: CODE GENERATION WITH GENERATED TESTS

ASBTRACT

给定一个编程问题，Codex等预训练语言模型已经证明了通过采样生成多种不同代码解决方案的能力。然而，从这些样本中选择正确或最佳的解决方案仍然是一个挑战。虽然验证代码解决方案正确性的一种简单方法是通过执行测试用例，但产生高质量的测试用例是非常昂贵的。在本文中，我们探索使用预先训练的语言模型来自动生成测试用例，我们的方法叫CODET：CODE generation with generated Tests。CODET使用生成的测试用例执行代码解决方案，然后根据生成的测试用例和其他生成的解决方案的双重执行协议选择最佳的解决方案。我们在五种不同的预训练模型上使用HumanEval和MBPP基准来评估CODET。大量的实验结果表明，CODET与以前的方法相比可以取得显著的、一致的、令人惊讶的改进。例如，CODET将HumanEval上的pass@1改进到65.8%，在code- davincin -002模型上绝对提高了18.8%，比以前最先进的结果绝对提高了20%以上。

INTRODUCTION

由于最近在预训练技术方面的进步，许多大型语言模型已经为代码生成进行了预训练，例如Codex (Chen等人，2021年)、AlphaCode (Li等人，2022b年)、INCODER (Fried等人，2022a年)、CODEGEN (Nijkamp等人，2022年)和PolyCoder Xu等人(2022年)，并将代码生成引入了现实世界的应用程序，如Copilot。虽然这些先进的预训练模型能够通过抽样为编程问题生成许多不同的解决方案，但从多个生成的候选方案中选择一个正确的解决方案仍然是一个挑战。以HumanEval基准(Chen等人，2021年)为例，Codex的pass@100(如果给定问题的100个生成的解决方案中有一个或多个可以通过相应的测试用例)为77.4%，而pass@1(单个解决方案的正确率)仅为33.5%2。这一巨大的差距使得探索如何从多个候选方案中选择正确或最佳解决方案变得势在必行。

验证生成的代码是否正确的一种简单方法是执行它，然后检查它是否通过了所有相应的测试用例。这种执行指导方法已被广泛应用于许多与代码相关的任务，如代码生成(Chen等人，2021;Li等人，2022b;Shi等人，2022)、代码翻译(Roziere等人，2021)和程序合成(Chen等人，2018;Ellis等人，2019年)。然而，挑战在于准备足够数量的高质量测试用例来覆盖所有的corner case是非常昂贵和低效的。在像Copilot这样的真实应用程序中，如果用户在使用代码生成工具时需要提供测试用例，这会很麻烦。为了解决这些挑战，我们探索了为任意编程问题自动生成测试用例的方法，然后使用它们快速验证任何解决方案。

虽然Codex等预先训练的模型已被用于生成代码解决方案，但我们首先设计一个详细的指令作为提示，要求相同的语言模型为每个编程问题自动生成大量的测试用例，如图1所示。其次，我们在生成的测试用例上执行每个生成的解决方案，将每个解决方案与它可以通过的所有测试用例关联起来。第三，我们在解决方案和测试用例上应用双重执行协议。我们相信一个解决方案可以得到测试用例和其他解决方案的支持。一个解决方案通过的测试用例越多，这个解决方案就越好。同时，如果有另一个测试驱动的兄弟解决方案可以通过与当前解决方案完全相同的测试用例，那么很可能这两个解决方案具有相同的功能，尽管实现不同。我们认为兄弟解决方案是相互支持的，大量的兄弟解决方案可以直接帮助解决方案的正确性。最后，我们在此双重执行协议的基础上计算一个排序得分，得出最佳解决方案。我们将我们的方法称为CODET:带有生成的测试驱动双执行协议的代码生成。

尽管CODET简单而高效，不需要任何标记数据或额外的排名，但它的性能令人惊讶。我们在五种不同的预训练模型上评估CODET:三种OpenAI Codex模型(Chen等人，2021年)、INCODER (Fried等人，2022b)和CODEGEN (Nijkamp等人，2022年)，以及两个已建立的基准:HumanEval (Chen等人，2021年)和MBPP (Austin等人，2021年)。大量的实验结果表明，CODET能够有效地选择正确的解决方案，显著提高了pass@1的得分:HumanEval (codecushman -001 33.5%→44.5%，codedavinci -002 47.0%→65.8%)和MBPP (codecushman -001 45.9%→55.4%，codedavinci -002 58.1%→67.7%)。此外，结合code-davinci-002和CODET在很大程度上优于以前最先进的方法，例如，HumanEval: 42.7% (Inala等人，2022)→65.8%。我们的工作将在https: //github.com/microsoft/CodeT上公开。

METHODOLOGY

代码生成的任务是解决一个编程问题:基于上下文c生成代码解决方案x。如图2所示，上下文c包含代码注释形式的自然语言问题描述，以及包含import信息、函数签名等语句的代码段。代码解决方案是用于解决上下文中描述的编程问题的代码片段。通常，我们基于上下文c使用预先训练的语言模型M对一组代码解决方案进行抽样，记为$x=x_1,x_2，\cdot \cdot \cdot ，x_K$，可以表示为$x=M(c)$。我们的目标是从生成的代码解决方案x中选择最佳的代码解决方案$\hat{x}$，其中$\hat{x}$是最可能正确解决给定编程问题的解决方案。为此，我们提出CODET，希望释放预先训练的语言模型M的固有力量。具体来说，我们使用M为编程问题生成测试用例(章节2.1)，然后基于双重执行协议选择最佳代码解决方案ˆx(章节2.2)。

TEST CASE GENERATION

我们利用预训练语言模型M来生成代码解决方案和测试用例。当生成测试用例时，为了告诉模型我们想要生成测试用例而不是代码解决方案，我们在上下文c后面添加了一条指令p作为提示。如图2所示，我们使用以下部分构造指令p:一条“pass”语句作为函数体的占位符，一条“检查[入口点]的正确性”的注释来澄清生成测试用例的意图，以及一条“assert”来启动测试用例生成。测试用例生成过程可以表述为$y=M(concat(c,p))$，其中$y=y_1,y_2，\cdot \cdot \cdot ，y_M$表示一组测试用例，$concat$为串联操作。值得注意的是，我们从上下文c中删除了所有的示例输入输出用例，以避免暴露真正的测试用例。

DUAL EXECUTION AGREEMENT

在本小节中，我们试图回答这个问题:给定代码解决方案x和测试用例y，我们如何选择最有可能正确的解决方案$\hat{x}$?

首先，我们在生成的测试用例上执行每个生成的代码解决方案。然后，最直接的方法是根据每个代码解决方案可以通过的测试用例的数量来打分。然而，我们发现这种朴素的方法还不够好(详情见4.1)。图3显示了一个简单的示例。对于编程问题“返回一个数字的平方”，有三个代码解决方案和五个测试用例。得分最高的代码解决方案是$x_3$，它通过了四个测试用例。然而，$x_3$显然不是正确的解，因为它返回一个数的2倍，而不是它的平方。正如所观察到的，虽然$x_1$和$x_2$是两个不同的解，但它们都是正确的，具有相同的返回一个数平方的功能。因此，他们聚在一起是合理的。将$x_1$和$x_2$的得分相加，以6分的综合得分进行选择。(这段的意思是有些测试用例是错误的吗？)

基于这个想法，我们提出了我们的方法CODET来执行我们所谓的双重执行协议。形式上，对于每个代码解决方案$x\in \ast \ast x\ast \ast$，我们用y中的所有测试用例来执行它。如果两个代码解决方案可以通过一组相同的测试用例，那么它们是具有相同功能的兄弟解决方案;因此，我们可以将它们放在同一个集群中。这样，x中的所有代码解都可以被划分为若干簇，记为$x=x_1,x_2，\cdot \cdot \cdot ，x_N$。设$W=w_{ij}$为N × M矩阵，表示执行结果，其中N为代码解决方案集群的数量，M为测试用例的数量。如果集群$x_i$中的代码解决方案能够通过测试用例$y_j$，则$w_{ij}=1$;否则，$w_{ij}=0$。双重执行协议的基本思想是一个好的代码解决方案应该得到测试用例和其他解决方案的一致同意:(1)它能通过的测试用例越多，解决方案就越好。(2)兄弟解的数量越多，就能直接提高解的正确性。因此，我们定义每个集群$x_i$的得分为:

其中$g_0(y_j)=1/M$ 表示测试用例$y_j$的初始归一化得分，$r_i$为聚类$x_i$中code solution数的平方根。我们使用平方根来减少代码解决方案造成的影响，因为直觉上代码解决方案的数量没有通过测试用例的数量重要。例如，可能有一个代码解决方案可以通过五个测试用例，而另外五个代码解决方案可能只通过一个测试用例。我们凭直觉认为前者可能更正确。最后，我们通过从得分最高的集群中选择任何代码解决方案来获得最佳代码解决方案$\hat{x}$。此外，如果我们想要获得k个代码解决方案，我们可以从得分最高的k个集群中每个选择一个代码解决方案。

在CODET中，每个测试用例对代码解决方案的得分都有同等的贡献。所以问题来了:**不同的测试用例有不同的重要性级别吗?**直观地说，如果一个测试用例可以被更多的代码解决方案通过，那么这个测试用例就更有可能是正确的。为此，我们进一步建议CODET-Iter以迭代的方式考虑测试用例的重要性。受二部图排序工作的启发(Kleinberg, 1999;He等人，2016;Yang et al.， 2020)，则$x_i$和$y_j$的得分可以计算为:

其中$f_0(x_i)=\frac{r_i}{{\sum }_{n=1}^N{r}_n}$是$x_i$的初始归一化分数，α和β是要设置在[0,1]之间的超参数，以说明初始分数的重要性。利用公式2迭代计算$x_i$和$y_j$的得分。为了收敛，每次迭代后对所有代码解决方案簇的分数进行归一化处理;同样的情况也适用于测试用例。

EXPERIMENTAL SETUP

在本节中，我们将介绍实验设置，包括预训练的语言模型、代码生成的基准、评估指标和实现细节。

MODELS

我们的主要实验基于Codex (Chen等人，2021)，它是GPT-3的后代(Brown等人，2020)。Codex精通理解提供的上下文和生成功能性程序，并已成功应用于许多编程任务(Drori等人，2021;皮尔斯等人，2021年;Sarsa等人，2022年)。我们使用OpenAI提供的三种不同尺寸的Codex模型:code-cushman-001、code-davinci-001和code-davinci-002。

此外，我们包括两个公开可用的预训练模型:INCODER (Fried等人，2022a)和CODEGEN (Nijkamp等人，2022)。INCODER是一种统一的生成模型，可以通过因果掩码语言建模训练目标执行从左到右的代码生成和代码填充(编辑)(Aghajanyan等人，2022)。CODEGEN是在自然语言和编程数据上训练的大型语言模型家族，用于执行会话程序合成。我们使用INCODER 6.7B版本(INCODER- 6b)和CODEGEN 16B Python单语言版本(CODEGEN- mono- 16B)。

BENCHMARKS

我们使用zero-shot setting在两个公共代码生成benchmark上进行实验。

1. HumanEval是一个代码生成基准测试，包含164个手写的Python编程问题，涵盖语言理解、推理、算法和简单的数学(Chen等人，2021年)。如图2所示，每个问题的上下文可能包括注释、函数头和导入等语句形式的自然语言描述。每个问题都包含一个规范解和几个基本事实测试用例。为了明确起见，每个问题的原始上下文可能包括示例输入-输出用例，我们在实验中删除了这些用例，以避免暴露真实的测试用例。
2. MBPP(经过净化的版本)包含427个众包Python编程问题，从标准库函数的基本使用到需要外部知识的问题(Austin等人，2021年)。最初，每个问题都包括自然语言问题描述、函数头、规范解决方案和几个基本事实测试用例。我们遵循HumanEval来构造MBPP的上下文，其中包含一个格式良好的函数头及其以多行注释形式存在的自然语言描述。

METRICS

我们使用pass@k进行性能评估，并利用真实测试用例来确定代码解决方案的功能正确性。对于每个问题，产生k个代码解作为最终结果。如果k个代码解决方案中有任何一个通过了所有地面真实测试用例，则认为该问题已解决。那么pass@k是已解决问题的百分比。根据Chen等人(2021)，pass@k可以表示为:

其中n≥k为采样数，c≤n为正确代码解的个数。做了一个采样操作，让结果更稳定些。

IMPLEMENTATION DETAILS

对于Codex模型的实验，我们将top p设置为0.95，并将最大生成长度设置为300。为了获得基线pass@1的结果，tempture设置为0，采样数n设置为1。对于其他结果，温度设置为0.8，采样数n设置为100。也就是说，对于基线pass@10和pass@100，我们使用采样数n = 100。对于CODET，我们选择2.2节中提到的前k个代码解决方案，并使用n = k.执行测试用例的超时设置为0.1秒。CODET-Iter(式2)中的超参数α和β均设为0.9，迭代次数设为3。对于代码解决方案的后处理，我们遵循Chen等人(2021)通过五个停止序列截断生成的内容:“\nclass”，“\ndef”，“\n#”，“\nif”，和“\nprint”。对于测试用例的后处理，我们为每个生成的示例提取了前五个符合Python语法的断言。有效的断言应该以“assert”开头，并包含相应的入口点函数的名称。

对于INCODER和CODEGEN模型的实验，我们使用HuggingFace的transformer库(Wolf等人，2019)。设置和后处理过程与Codex实验相同，不同之处在于基线pass@1结果是通过从n = 100个温度接近0的小样本中选取平均对数概率最高的样本获得的。为了加快实验速度，我们以半精度运行两个模型。

EXPERIMENTAL RESULTS

在本节中，我们在五个不同的预训练模型和两个基准上评估CODET，以验证其有效性，然后深入分析生成的测试用例的质量和CODET中不同的设计选择。

MAIN RESULTS

表1总结了各种CodeX模型在HumanEval和MBPP基准上的实验结果。以Baseline列中的HumanEval为例，我们发现12B code-cushman-001模型的复制结果略好于Codex12B模型在Codex原始论文中报告的结果(Chen等人，2021年)(33.5% vs. 28.6%在pass@1, 77.4% vs. 72.3%在pass@100)。我们推测code-cushman-001是一个比原始Codex-12B模型更好的12B预训练模型。另一方面，如果我们比较pass@100和pass@1，很明显前者要比后者好得多，这表明有可能从100个生成的示例中选择最佳的代码解决方案。

当我们比较CODET列和Baseline列时，CODET实现了比基线大约10%的绝对改进。对于HumanEval，改进持续在10%以上。令人惊讶的是，即使是最强的基线，code-davincin-002，改进也达到了18.8%，将pass@1提高到65.8%——比之前报告的最佳结果有20+%的绝对改进(Inala等人，2022)。我们将这种较大的改进归功于由code-davinci-002生成的更高质量的测试用例，它将在下一节中提供更深入的分析。

我们还报告了CODET的pass@2和pass@10，以进一步显示其优势。CODET的pass@2结果接近于基线pass@10结果。与此同时，在HumanEval基准测试中，pass@10上的改进也始终超过10%。由于CODET是在100个生成的代码解决方案上执行的，它的pass@100性能与基线相同。对于MBPP基准，我们继续看到持续且显著的改进，尽管改进的幅度略低于HumanEval。以代码davincin -002为例，pass@1提高了9.6%。

此外，我们还比较了CODET- iter和CODET的性能。结果表明，两者具有可比性，无显著差异。我们猜想，以这种方式考虑测试用例的重要性可能是不必要的，或者一个明显很好的高分测试用例可以通过许多不同的解决方案，而无需引入区分来排名代码解决方案。我们将把对更复杂的迭代方法的进一步研究留给未来的工作。(意思是我设计的这个iter机制好像没啥明显作用)

正如在2.2节中提到的，给代码解决方案评分的一种直接的方法是简单地计算它可以通过的测试用例的数量。然而，这种方法高度依赖于生成的测试用例的整体质量，并且完全忽略了代码解决方案之间的一致性。我们使用CodeX在HumanEval基准上对该方法进行了评估，结果见表2。它清楚地表明，它的性能始终明显地比CODET差，只有codedavinci-002在pass@1上比基线得到了改进。这个观察结果再次证明了CODET的重要性和合理性。

RESULTS OF INCODER AND CODEGEN

为了进一步验证CODET的有效性，我们收集了INCODER-6B 和CODEGEN-MONO-16B的实验结果，如表3所示。很明显，CODET可以显著改进pass@1，绝对改进幅度在4.2%到13.1%之间。INCODER-6B 实现了最大的改进，在MBPP基准上增加了13.1%。与Codex的实验结果相似，pass@2的结果接近基线pass@10, CODET和CODET- iter的结果异常接近。所有结果表明，CODET可以持续地提高各种预先训练的语言模型的性能。

ANALYSIS ON TEST CASES

测试用例是至关重要的，因为CODET的核心思想是基于测试驱动的执行。因此，在本小节中，我们想通过回答以下两个研究问题来分析测试用例。

Q1. What is the quality of the generated test cases?

对于测试用例生成，我们为每个问题生成了100个样本，并为每个样本提取了前5个语法正确的测试用例，这意味着每个问题都配备了多达500个生成的测试用例。表4总结了HumanEval上每个问题的测试用例的平均值和中位数。几乎所有的模型都可以生成相当数量的语法正确的测试用例，而CODEGEN会产生大量意想不到的噪音。

我们利用HumanEval基准提供的规范解决方案来评估生成的测试用例的正确性。每个测试用例都是一个断言语句，只有当它的断言条件对标准解决方案的计算结果为真时，我们才认为它是正确的。图4a总结了测试用例准确度的分布。横轴代表每个问题的测试用例精度值。纵轴表示对应精度值的问题的概率密度。我们可以看到，code- davincin -002生成的测试用例具有很高的准确性，而INCODER生成的测试用例则相对不准确。

除了准确性，我们还引入毒性率来评估测试用例的质量。如果有一个生成的代码解决方案通过了测试用例，而规范的解决方案没有通过，那么我们认为测试用例是“有毒的”。有毒的测试用例可能会阻碍CODET的执行协议，并导致性能下降。图4b总结了测试用例毒性率的分布，从中我们可以看到毒性率与不同模型的测试用例准确度高度相关。与INCODER相比，code-davinci-002的有毒测试用例的比例要小得多，这解释了CODET在HumanEval基准上的INCODER性能比code-davinci-002稍有提高。

Q2. Can better test cases further boost the performance of mediocre models?

正如上面所分析的，code-davinci-002是生成高质量测试用例的最有能力的模型。因此，我们使用由code-davinci-002生成的测试用例进行实验，以提高其他四个模型(code-cushman-001、code-davinci-001、INCODER和CODEGEN)的代码生成。表5总结了不同模型在HumanEval和MBPP基准上的性能增益。通常，与使用自己生成的测试用例的结果相比，使用code-davinci-002生成的测试用例的结果显示了显著的改进。对于code-cushman-001和code-davinci-001，在CODET pass@1上的绝对改进范围为1.8%到4.3%，而对于INCODER和CODEGEN，改进范围为6.2%到15.9%。这表明由普通模型生成的潜在正确的代码解决方案可以通过采用更好的测试用例进一步加以利用。

ANALYSIS ON DESIGN CHOICE

Temperature: 使用top p采样时，温度超参数对生成的代码解决方案和测试用例的质量有很大影响。我们在主要实验中使用0.8的高温，因为CODET可以从大量不同的样本中受益。为了研究CODET对温度的敏感性，我们通过使用一系列温度来进行消融研究，报告基线pass@100和CODET pass@1的结果。图5显示了不同温度设置下在HumanEval基准上的code-cushman-001的结果。我们可以发现，更高的温度确实改善了基线pass@100和CODET pass@1，当温度设置为0.8时，CODET实现了良好的性能。

Importance of code solutions : 正如在2.2节中提到的，我们将$r_i$定义为集群$x_i$中代码解决方案数量的平方根，因为我们相信通过的测试用例数量比代码解决方案集群的大小更有价值。为了验证，我们通过比较CODET与“√”、“log”函数的性能，并在代码解的数量上没有任何约束(“线性”)，来进行消融研究。图6显示了三种CodeX模型在HumanEval上的结果。我们可以得出结论，降低代码解决方案的重要性可以提高CODET的性能，这表明我们的$r_i$设计是合理的。

RELATED WORK

Code Generation with Large Models 最近，人们提出了许多用于代码生成的大型预训练语言模型。受益于数十亿可训练参数和大量公开的源代码，模型可以实现令人惊讶的良好性能。例如，AlphaCode (Li等人，2022b)声称在真实世界的编程比赛中超过了一半的人类竞争对手，Codex (Chen等人，2021年)授权副驾驶提供实时编码建议。除了私有访问AlphaCode和Codex模型，还有开源代码生成模型，如GPT-Neo (Black等人，2021年)、GPTJ (Wang & Komatsuzaki, 2021年)、CodeParrot (Tunstall等人，2022年)、PolyCoder (Xu等人，2022年)、CODEGEN (Nijkamp等人，2022年)和INCODER (Fried等人，2022a)。在我们的研究中，我们利用了OpenAI提供的Codex推断API以及两个竞争性的开源模型CODEGEN和INCODER来执行zero-shot代码生成。

Automatic Test Case Generation 为编程问题自动生成测试用例可以减少开发人员手工编写测试用例的工作量。早期的工作包括Randoop (Pacheco等人，2007年)，EvoSuite (Fraser & Arcuri, 2011年)，MOSA (Panichella等人，2015年)，DynaMOSA (Panichella等人，2017年)，和MIO (Arcuri, 2017年)，被建议为静态类型的编程语言，如Java自动生成测试用例。后来提出的Pynguin (Lukasczyk & Fraser, 2022)可以处理像Python这样的动态类型语言。然而，它们都是基于搜索的启发式方法，对生成的测试用例的多样性和数量有限制。为了克服这些局限性，最近提出了一些方法(Tufano等人，2020;Li等人，2022b)利用了预先训练的语言模型，如BART (Lewis等人，2019年)和T5 (Raffel等人，2020年)，对标记数据进行微调，用于生成测试用例。与以前需要启发式规则或模型训练的工作不同，我们直接从强大的代码生成模型(如Codex)中抽样测试用例，采用zero-shot的方式，并提供详细的提示。

Code Selection from Multiple Samples 尽管大型模型在代码生成中已经取得了很好的性能，但是模型需要多次抽样才能找到正确的答案，这就给从多个样本中选择正确答案带来了挑战。最近，人们提出了几种方法来解决这个问题。在解决数学应用题的领域，Cobbe等人(2021)产生了许多候选解决方案，并选择了一个训练有素的验证者最高的秩。Shen等人(2021)提出通过多任务框架联合培训生成器和排序器。在通用代码生成领域，Inala等人(2022)训练了一个故障感知排序器，以增加代码生成模型的pass@1准确性。除了训练一个额外的验证者/排序者，Shi等人(2022)和Li等人(2022b)提出了利用执行信息，根据给定的输入对输出的相似性进行排序。对于输入数据，Shi等人(2022)使用了基准测试提供的测试用例，而Li等人(2022b)训练了一个额外的生成器。基于一致性的排序思想也出现在推理领域(Wang等人，2022;Li等人，2022a)。不像以前的工作，需要模型训练或者预先存在的测试用例来对生成的代码解决方案进行排序，我们让大型模型为自己生成测试用例，然后根据它们的测试驱动的双重执行协议对解决方案进行排序。

CONCLUSION AND FUTURE WORK

在本文中，我们提出了一种简单而有效的方法，称为CODET，利用预先训练的语言模型来生成代码解决方案和测试用例。CODET使用测试用例执行代码解决方案，并根据双重执行协议选择最佳解决方案。我们证明了测试用例和其他解决方案的双重协议对CODET的成功至关重要，并对生成的测试用例的质量及其对CODET的影响进行了彻底的分析。同时，实验结果清楚地证明了CODET的优越性，在HumanEval和MBPP基准上显著提高了pass@1数字。此外，code- davincin -002和CODET的组合出人意料地将HumanEval上的pass@1提高到65.8%，比以前最先进的结果绝对提高了20%以上。在未来的工作中，我们将探索如何将CODET的思想与训练排序器相结合。另一个方向是将CODET扩展到其他与代码相关的任务。