文章目录
1.引入 2.评估框架 3.评估数据集 4.模型方法 5.实验结果 6.总结 7.参考之前，我已经介绍过Github发布的自动代码Copilot的使用方法，感兴趣的可以看这篇文章：
Copilot要收费了？
今天主要介绍一下github copilot中主要用到的代码生成框架Codex。它主要是由Github和OpenAI联合开发的模型框架，具体链接如下：
https://openai.com/blog/openai-codex/?utm_campaign=Connect%20the%20dots&utm_medium=email&utm_source=Revue%20newsletter
1.引入
Codex主要利用的是GPT-3模型。同时为了评估模型的有效性，研究人员还设置了一个评估数据集：HumanEval。在这个评估数据集下，在GPT-3模型不能够解决任何一个问题，GPT-J模型能够解决11.4%的问题，而Codex模型能够解决28.8%的问题。
同时，在模型中重复采样是一种有效策略，可以为模型多次提供工作解决方案。使用这种方法，能够解决了70.2%的问题。
2.评估框架
代码的生成模型主要通过将样本与参考解进行匹配来进行基准测试，匹配可以是精确的，也可以是模糊的（如BLEU分数）。然而，最近的工作暴露了基于匹配的代码度量的缺陷。可以看出，BLUE是一个模糊匹配的过程，只要意思对了，BLUE的分数就会提高。但是编程是一个比较特殊的问题，一个小的差别可能就会带来灾难性的影响。
因此，论文中提出了自己的度量标准
p
a
s
s
@
K
pass@K
pass@K，
k
k
k表示从每一个问题中生成的代码样本中选择的答案。论文中，生成
n
n
n个代码样例，同时计算
c
c
c个代码能够通过单元测试：
3.评估数据集
论文中新构建了评估数据集，称为HumanEval，数据地址如下：
https://github.com/openai/human-eval
其中包含了164个手写编程问题，数据集中包含“评估语言理解”、“推理”、“算法”和“简单数学”。如下图所示：
每个问题包含：
签名 代码功能解析 主体这些编程为题都是手写而来，这是因为模型在训练的时候用到了大量的Github仓库代码，因此可能会包含很多解答方法，因此需要重新手写编程问题。
4.模型方法
数据集训练数据集于2020年5月从GitHub上托管的5400万个公共软件库中收集，其中包含179 GB的独特Python文件。删除了可能是自动生成的、平均行长度大于100、最大行长度大于1000或包含少量字母数字字符的代码文件。过滤后，最终数据集总计159GB
方法由于Codex是根据自然语言提示进行评估的，Codex直接使用GPT-3模型进行训练。
为了最大限度地利用GPT中的文本表示，论文中使用基于GPT-3文本分词器。由于GitHub代码中单词的分布与自然文本的分布不同，因此该标记器在切割代码时不是很有效。效率低下的最大来源是对空格进行编码，因此论文添加了一组额外的标记来表示不同长度的空格。这种做法，可以减少大约30%的token。
同时，在生成代码的时候，当遇到“\nclass”， “\ndef”，“\n#”，"\nif”，“\nprint”时，则停止。
5.实验结果
模型参数与损失值之间成指数关系：模型指数上涨，损失之线性下降：
在计算softmax的时候，会除上一个T。当T越大时，候选词语概率值较为接近。当T越小时，候选词概率值则较为远离。当在生成的代码例子抽取K个出来，K的个数越大时，T会相应变大。反过来说，如果近抽取1个例子，这个例子应该是最有代码性，概率值最大的代码例子。
为了验证BLUE的评估标准是否有效，论文中在评估集合上给出了正确和错误代码的BLUE分数。可以发现，正确代码和错误代码的BLUE分数值相差不大，说明BLUE分数在代码生成中没有评估效果。
6.总结
整体来说，Codex本质上就是使用了GPT-3模型作为预训练模型，然后进行微调。同时也人工定义了164个编程问题，作为评估数据集。同时还提出了新的评估指标
p
a
s
s
@
k
pass@k
pass@k，并论证了BLUE指标对代码生成的局限性。
从数据层面上，因为采集了Github上的代码，因此可能会存在潜在的代码作者的追究专利的问题。
我是leo，欢迎关注我的公众号“算法一只狗”，我们下期再见~