【AI4Code】CodeX：《Evaluating Large Language Models Trained on Code》（OpenAI）

代码生成——CodeX （OpenAI）

最近非常火的OpenAI的Copilot背后的模型。文章35页，58位作者，6位共同一作。

顺理成章的，把模型做的再大一点，训练数据集做的再大一些，计算资源再多一些，就可以生成更长的代码。这篇文章做的事情就是把GPT模型应用在代码生成上，具体来说输入函数的签名和注释（prompt），告诉模型这个函数要做什么事情，然后模型输出实现代码。

这里有三个示例，白色背景的是 prompt，黄色背景的是模型补全的代码。

想完成这件事情其实很难，有很多工作要做，所以这篇文章有58个作者，6个共同一作。

评测模型

首先要有一个方法能够评测模型的能力。这里虽然是一个将注释 “翻译”成代码的任务，但是不能用BLEU指标来衡量质量，这是因为基于匹配的方法即使代码语义相近，但是不能评价代码功能的正确性。所以论文将代码功能的正确性作为评测指标，具体来说是用单元测试的方法来评估代码，评测指标用 pass@k，即对于每个编程问题，模型输出 k 个代码答案，只要有一个代码能通过单元测试，则认为该问题被解决。

同样还需要构造一个评测数据集，文章构造了一个HumanEval的数据集，包含164个上图所示的编程问题，对每个编程问题手工设计了8个单元测试。这些编程问题必须是原创的、手工设计的，因为模型是在Github上的数据训练的，训练集中很可能包含大量的已有的编程问题的代码。

模型生成的代码需要在一个Sandbox中执行测试，这是为了防止CodeX生成的代码不可控，有安全隐患，因此评测代码要在隔离的环境中。这点想的有点科幻了。

训练模型

数据集

训练集是OpenAI从Github上五千四百万个项目的代码，包含179GB的Python文件，每个文件小于1MB。过滤了一些代码文件，还剩下159GB。CodeX就使用GPT在这159GB的代码文本上训练。

除了训练集之外，论文还设计了其他三个数据集：评测用的HumanEval数据集；用来fine-tuning的、格式类似HumanEval的Supervised Fine-Tuning数据集；用来训练CodeX-D的docstring数据集。

模型

CodeX

CodeX的模型结构和GPT-3完全一模一样，只不过是一些参数设置和训练方法不同。比如添加了表示不同长度空格的token，这可以减少30%的词典大小。CodeX在生成代码时如果生成的token是：‘\nclass’, ‘\ndef’, ‘\n#’, ‘\nif’, or ‘\nprint’ 时就停止生成。pass@k 就是每次生成token时按照softmax概率sample，pass@1就是每次选择概率最高的那个token，这样就是贪心的选局部最优。

CodeX尝试了从头训练和基于 GPT-3 的参数 fine-tuning，结果发现基于 GPT-3 的参数 fine-tuning 并没有取得效果上的提升，但基于 GPT-3 的参数 fine-tuing 可以收敛的更快，因此，论文中都采用的是这种训练策略。

所以CodeX和GPT-3模型本质上没有区别，训练数据不同，参数权重不同，用代码数据训练出来的一套权重参数就叫CodeX。

CodeX-S

CodeX是在Github的159GB的代码文本上无监督的训练的，论文造了一个和HumanEval数据集格式一致的Supervised Fine-Tuning 数据集，在这个数据集上fine-tuning后的模型效果更好。

CodeX-D

将Supervised Fine-Tuning 数据集中的<函数头>< docstrings><函数体>格式调换成 <函数头><函数体> < docstrings>，fine-tuning得到的模型叫CodeX-D，即让模型根据代码写注释。

实验结果

从评测结果上看，再强大的GPT-3模型也不能生成可用的代码。黄色线是要求CodeX对于每个问题只能输出1个答案；绿色线是在类似HumanEval格式的数据集上有监督的fine-tuning过的CodeX-S；红色线是允许CodeX-S对每个任务生成100个答案，然后挑选平均概率最高的；紫色线是假设能够CodeX-S生成的100个答案中挑选出正确的那个。可以看出如果允许CodeX-S生成100个答案的话，它几乎可以解决所有编程问题。

模型局限性

1、CodeX已经看过了数量惊人的代码，但是只能写出比较简单的代码，基本上是在背代码和代码组合

2、Docstrings 很长时，代码质量下降（AlphaCode做的事）

3、和数学相关的代码写的很不好。

所以CodeX对代码任务的理解其实不怎么好，更像是代码翻译（注释 --> 代码）。

安全性讨论

花了很大的功夫在论文和项目中仔细讨论安全、隐私、敏感问题。

Over-reliance

人可能会过度依赖模型生成的代码，有可能存在Bug。

misalignment

模型参数特别大，很复杂时，模型可能会误解docstring，返回一个看起来还算正确，但是在细节地方很不同的代码，很难把它找出来。

Bias and representation

因为这个模型是使用github上的代码，但github上男性用户居多，很有可能带有性别偏见，比如注释里脏词比较多。

Economic and labor market impacts

可能会影响市场占比，比如如果CodeX生成代码总喜欢使用某一些特别的包，会导致某一些特别的工具被用的更多，如果模型被大量使用会导致这些包的使用率发生变化。例如OpenAI做了一个新框架，然后他的模型都是生成自己框架的代码，如果大量使用就没有Pytorch,tensorflow了。

Security implications

可能用来CodeX来写病毒或者恶意软件，而且可以一次写很多不同恶意软件，会导致杀毒软件，安全团队很难做出有效的一个防御。

Environmental impacts

耗电

Legal implications

模型用的是github公开代码，涉及fair use，如果对公共设施有好处，在国外法律认为是没有问题的，但如果将模型商业化就不那么适用。

CodeX经常会出现将别人代码完全抄过来的情况，实际上copliot抄袭代码概率很高，但对用户来说，他不知道代码是否是照搬过来，可能涉及代码专利保护，需要非常小心。

这一点OpenAI强调，Copilot只是一只“笔”，一个“编译器”，使用者要对生成的代码负责。

进一步的安全性讨论

生成恶意代码：论文在附录里做了实验，直接用CodeX独立生成恶意代码不太行，但是用它来生成恶意代码的某些组件还是可以的。
文章调查了CodeX模型是否会建议使用易受攻击的、恶意的或仿冒的软件依赖项,例如特定版本的python包可能包含会使下游应用程序易受攻击的漏洞。文章做实验发现是否会生成域名仿冒的软件包主要和人为设定的 prompt文本有关，如果prompt文本就设定了特定域名的软件包，CodeX也无法纠正，从而有可能成为域名仿冒的攻击媒介。
还有一些安全问题和文本生成模型的安全问题类似，比如偷训练数据的秘密。这一点在Copilot的官网中进一步讨论了，Copilot可能会输出个人邮箱、身份证号之类的隐私数据，Copilot已经做了过滤，但是也不能完全保证，“if you try hard enough.”

数据投毒攻击

由于CodeX是在公共数据上进行预训练和微调，所以攻击者可以在其中插入对抗性的输出，导致模型产生脆弱的、恶意的或未对齐的代码，并且随着模型能力和潜在攻击者兴趣的增加，这种风险可能会增加。 所以CodeX从大量不受信任的数据上进行训练，是可能产生不安全代码的。

作者以两个例子研究CodeX是否会产生不安全代码：是否会产生 调用函数产生RSA keys长度小于2048的代码；AES加密是否推荐ECB。作者在不同模型大小的CodeX上，构造了相关的prompt（产生RSA key和AES），然后产生了三万个代码样本，过滤掉不能用的，探究不安全代码的比例：

可以看出模型的对这个问题的鲁棒性和模型的尺寸大小没有明显的关系。

这一点Copilot在官网的讨论中说你应该自己判断（as well as your own judgment）

下一篇AlphaCode场景没有这么实际，安全性讨论就很少。