从文本使用大模型自a动生成代码：Codex

OpenAI Codex是由OpenAI开发的人工智能模型。它能解析自然语言并生成相应的代码。该模型驱动了GitHub Copilot，一个为选定的IDE（如Visual Studio Code和Neovim）提供的编程自动补全工具。Codex是OpenAI的GPT-3模型的后代，经过微调以用于编程。

摘要

我们介绍Codex，这是一种在GitHub上公开可用的代码上进行Fine-tuned的GPT语言模型，并研究其Python编写能力。Codex的一个特定生产版本支持GitHub Copilot。在HumanEval上，这是我们发布的新的评估集，用于衡量从文档字符串中合成程序的功能正确性，我们的模型解决了28.8%的问题，而GPT-3解决了0%，GPT-J解决了11.4%。此外，我们发现，重复从模型中采样是一个出人意料的有效策略，用于产生解决困难提示的有效解决方案。使用这种方法，我们对每个问题使用100个样本，解决了70.2%的问题。对我们模型的仔细调查揭示了其局限性，包括描述长操作链的文档字符串和将操作绑定到变量的困难。最后，我们讨论了部署强大的代码生成技术可能产生的更广泛影响，涵盖安全性、安全和经济等方面。

1 介绍

可扩展的序列预测模型已经成为许多领域中的通用生成和表示学习方法，包括自然语言处理、计算机视觉、音频和语音处理、生物学，甚至跨多种模态。最近，语言模型也推动了程序合成这一长期挑战的进展，这得益于大型数据集中存在的代码以及在这些数据集上训练的语言模型的编程能力。像掩码语言建模和跨度预测等流行的语言建模目标也已经被改编用于训练它们的编程对应物CodeBERT和PyMT5。

类似地，我们对GPT-3的早期调查显示它可以从Python的文档字符串生成简单的程序。虽然初级，但这种能力令人兴奋，因为GPT-3并没有明确针对代码生成进行训练。鉴于大型语言模型在其他模态取得的相当成功以及公开可用代码的丰富性，我们假设一种专门的GPT模型，称为Codex，可以在各种编码任务中表现出色。本文描述了几种早期的Codex模型，它们的后代支持GitHub Copilot和OpenAI API中的Codex模型。

图1. 我们模型在HumanEval数据集上的通过率与模型规模的关系。

当针对每个问题生成单个样本时，GPT-12B解决不了任何问题，但Codex（在代码上进行Fine-tuned）解决了28.8%的问题，Codex-S（进一步在正确实现的独立函数上进行Fine-tuned）解决了37.7%的问题。在此基础上，通过针对每个问题生成100个样本并选择平均对数概率最高的样本可以实现进一步的提升（解决率为44.5%），或者通过选择通过单元测试的样本（解决率为77.5%）。所有样本均使用温度为0.8进行生成。

在这项工作中，我们专注于从文档字符串中生成独立的Python函数的任务，并通过单元测试自动评估代码样本的正确性。这与自然语言生成形成对比，后者的样本通常通过启发式方法或人工评估进行评估。为了准确评估我们的模型，我们创建了一个包含164个原始编程问题和单元测试的数据集。这些问题涵盖语言理解、算法和简单数学，其中一些类似于简单的软件面试问题。我们发布了这些数据以及一个评估框架，链接在 https://www.github.com/openai/human-eval 。

为了解决测试集中的问题，我们从模型中生成多个样本，并检查其中是否有任何一个通过了单元测试。仅使用单个样本，一个拥有12B参数的Codex解决了28.8%的这些问题，而一个拥有300M参数的Codex解决了13.2%的这些问题。相比之下，拥有6B参数的GPT-J在同一数据集上达到了11.4%，而所有GPT模型几乎都达不到1%。为了提高我们的模型在从文档字符串中合成函数任务上的性能，我们对Codex进行了对独立、正确实现的函数进行Fine-tune。得到的模型Codex-S，在单个样本下解决了37.7%的问题。图2展示了我们数据集中不同难度的问题，以及模型生成的正确解决方案。

实际的编程任务通常涉及多次尝试和错误修复的迭代过程，我们通过从模型中生成大量样本并选择通过所有单元测试的样本来近似这个过程。在100个样本内，Codex-S能够为77.5%的问题生成至少一个正确的函数。这个结果表明，可以通过启发式排名选择准确的代码样本，而不是完全评估每个样本，后者在部署中可能不可行或不实际。事实上，我们发现具有最高平均对数概率的样本通过了44.5%的问题的单元测试。

最后，我们讨论了这些Codex模型的局限性和潜在的更广泛影响，以及越来越强大的代码生成模型可能带来的影响。

2 评估框架

在本节中，我们讨论评估框架的细节。我们首先定义了pass@k指标，并解释了它相对于标准匹配度量的优势。接下来，我们描述了手写问题的数据集，“HumanEval”，这个数据集是我们创建的，用于评估我们的模型。最后，我们讨论了我们用来安全执行模型生成代码的沙盒环境。

2.1 功能正确性

针对代码的生成模型主要通过将样本与参考解决方案进行匹配来进行基准测试，其中匹配可以是精确的或模糊的（如BLEU分数）。然而，最近的研究表明，基于匹配的代码度量存在一些不足之处。例如，Ren等人（2020）发现BLEU在捕捉特定于代码的语义特征方面存在问题，并提出了对分数进行若干语义修改。

更根本的是，基于匹配的度量无法考虑到与参考解决方案功能上等价的大而复杂的程序空间。因此，最近在无监督代码翻译和伪代码到代码翻译方面的工作转向了功能正确性，其中如果样本通过一组单元测试，则被视为正确。

我们认为这个度量标准也应该适用于文档字符串条件下的代码生成。

也许评估功能正确性最具说服力的原因是它是人类开发人员用来评判代码的方法。一种称为测试驱动开发的框架规定，在任何实现开始之前，软件需求应该转化为测试用例，并且成功是指通过这些测试的程序。虽然很少有组织采用完全的测试驱动开发，但集成新代码通常依赖于创建并通过单元测试。

Kulal等人（2019）使用pass@k指标评估功能正确性，其中对于每个问题生成k个代码样本，如果任何样本能够通过一组单元测试，则认为该问题已解决。

图2. 来自HumanEval数据集的三个示例问题，单个来自Codex-12B的样本通过单元测试的概率分别为0.9、0.17和0.005。提供给模型的提示显示为白色背景，成功的模型生成完成显示为黄色背景。尽管不保证问题的新颖性，但所有问题都是手写的，而不是通过程序复制自现有来源。附录B中可以找到随机问题和样本。

但是，以这种方式计算pass@k可能会有很高的方差。相反，为了评估pass@k，我们为每个任务生成n ≥ k个样本（本文中，我们使用n = 200和k ≤ 100），计算通过单元测试的正确样本数c ≤ n，并计算偏差估计值。

直接计算这个估计量会导致非常大的数值和数值不稳定性。在图3中，我们包含了一个数值稳定的NumPy实现，简化了表达式并逐项评估乘积。有人可能会尝试用 来估计 pass@k，其中 是 pass@1 的经验估计值，但我们在附录A中展示了它是有偏的。

图3. 一个数值稳定的脚本，用于计算pass@k的无偏估计。

随后，我们提供了证据表明BLEU分数可能不是功能正确性的可靠指标，因为我们展示了由我们的模型生成的功能不等价的程序（在某些输入上保证与参考解决方案不一致）往往具有比功能等价的程序更高的BLEU分数。

2.2 HumanEval: 手写评估集

我们评估功能正确性的数据集包括164个手写编程问题，我们称之为HumanEval数据集。每个问题包括函数签名、文档字符串、主体以及若干单元测试，平均每个问题有7.7个测试。这些任务需要手写，因为我们的模型是在GitHub的大量数据上训练的，GitHub已经包含了来自各种来源的问题解决方案。例如，有超过十个公共仓库包含着Codeforces问题的解决方案，这些问题构成了最近提出的APPS数据集的一部分

HumanEval数据集中的编程任务评估语言理解、推理、算法和简单数学。我们发布了HumanEval数据集，以便其他人可以评估功能正确性并衡量他们模型的问题解决能力。该数据集可以在 https://www.github.com/openai/human-eval 找到。

2.3 执行生成程序的沙盒环境

由于公开可用的程序具有未知的意图，并且生成的程序通常不正确，执行这