导语
OpenAI在去年曾经使用Github上所有公开的Python代码训练了一个code版本的GPT-3，在当时曾引发广泛争议，本文简要记录对该模型的学习笔记。
- 会议: arxiv
- 链接: arxiv.org/pdf/2107.03…
- 学习资料：OpenAI Codex 论文精读【论文精读】，跟李沐学AI，哔哩哔哩
1 简介
本文主要介绍一种在code语料库上进行预训练的GPT-3模型。单纯的GPT-3在代码生成任务上表现性能为0，为此，作者设计了CodeX模型，它主要有三个不同的类别：
- CodeX：在所有Github上公开的Python文件上进行训练，由docstring生成对应的函数；
- CodeX-S：在CodeX基础上，选取了一些高质量、独立的函数模型进行Fine-tune，也是做由docstring生成对应的Python函数代码的任务；
- CodeX-D：与CodeX任务相反，由Python函数代码生成docstring。
2 评估框架
主流的Seq2seq任务的评估框架是BLEU score，然而，这是一种模糊匹配的相似度衡量，对于代码生成任务，哪怕错一个字符，就会带来完全不同的结果，因此，作者提出了一种用于评估Python代码生成的指标，即Pass@K，其定义如下：
大概意思是在生成的k个答案中，只要有一个能够执行正确就算对。而且，在验证时，作者手工进行书写标注了一个新的数据集，这是因为网上的数据很有可能都在训练集中，下图举了几个自己标注的数据集示例：
3 Code Fine-tuning
作者从Github所有公开的Python文件中经过爬取过滤后得到了最终159GB的训练数据，之后使用这些数据来训练GPT-3。这里作者发现：使用原始GPT-3的weight并不会对最终结果带来提升，但可以加快收敛速度。
由于最后是有k个输出样例，那么最理想的情况就是这k个样例全部运行一遍，找到最正确的那个作为最终输出，这个就是Oracle的那条性能曲线。
然而，现实中，全部运行k个样例可能是代价很大的，所以作者采用了一种最简单的策略，即对decoder每个时间步生成的token的prob进行log后求和，取最大的那个作为最终输出，这个就是图中红色的去心啊，可以阿看到效果也还可以。
最终的实验结果如下表所示;
4 Supervised Fine-Tuning
由于之前训练的数据中很多都是一些项目中的文件，还有很多配置文件等，所以这里作者又通过在编程网站和项目集成中的单元提交数据中收集了40000个高质量的数据，将3中得到的模型继续进行Fine-tune，得到所谓的CodeX-S模型，
可以看到，相比于CodeX，性能又有了很大提升。
5 Docstring Generation
最后，作者还进行了CodeX的反向训练，即通过输入模型Python函数代码，让模型生成docstring，这个模型命名为CodeX-D。
在评估时，作者又将这些docstring输入回3中的CodeX，如果能够预测正确，则表示生成的质量还可以。
可以看到，经过这样验证后，实际上准确率是有所下降的。
6 局限性
只能处理简单问题，训练代价巨大，文档越长生成效果越差等问题。
7 更广泛的影响
- 过度依赖；
- 与实际需求不匹配；
- 男性偏见（Github男性用户居多）；
- 程序员失业；
- 安全隐患（用来写病毒程序）；
- 环境影响（训练耗电）；
- 法律问题（照抄别人的商业代码毫不知情）。
8 相关工作
略
9 总结
CodeX出来之后，引发的争议就一直不断，目前看到相关的使用也比较少
本文转载自: 掘金