《评估在代码上训练的大语言模型》（Codex / HumanEval）

要解决的问题

语言模型学习的是预测下一个词，当训练文本是源代码时，它写出来的东西往往看起来很像程序。但看起来像，不等于能跑通。评价生成文本的常规办法是拿它和参考答案比对，这套办法用在代码上很别扭：两段写法完全不同的程序可以都对，而一段和参考答案很像的程序也可能出错。这篇由 Mark Chen、Jerry Tworek、Heewoo Jun 以及 50 多位 OpenAI 作者共同完成的论文于 2021 年 7 月 7 日提交到 arXiv，它同时处理了这个问题的两半：一个在代码上训练的模型，和一套判断模型写出的代码是否真能运行的度量方式^[1]。

Codex 与 HumanEval

Codex 是一个在 GitHub 上公开可得的代码上微调（fine-tune）过的 GPT 语言模型，论文研究的是它编写 Python 代码的能力^[1]。微调的意思是：从一个已经学会了通用语言统计规律的模型出发，继续在范围更窄的文本上训练，让它的预测偏向这批文本里的模式。这里的窄文本就是大量真实的源代码，而不是以散文为主的内容。

为了评测，作者发布了 HumanEval，一套新的评测集，用来衡量「根据文档字符串（docstring）合成程序」这一任务上的功能正确性（functional correctness）^[1]。这个设定对程序员来说很熟悉：给模型一段文档字符串，也就是说明某个函数该做什么的注释块，让它把函数本身写出来。因为评判标准是功能正确性，生成的程序要看行为对不对，而不是看它写成了什么样。这样一来，评测考的就是能不能产出可用的代码，而不是表面的相似度。

结果

在 HumanEval 上，Codex 解出了 28.8% 的题目，而 GPT-3 解出 0%，GPT-J 解出 11.4%^[1]。这个对比有信息量，因为三者的主要差别在于接触过多少代码：通用的 GPT-3 基本上写不出能用的解，而在这一比较中并非专门代码模型的 GPT-J 大约每九道题能解出一道。

第二个结果关于模型该怎么用。重复采样是一种出乎意料有效的策略：每题采样 100 次时，Codex 能解出 70.2% 的题目^[1]。换句话说，多问很多遍、再从中挑出能用的那一个，效果远好于只问一次就认账。这个发现的前提是存在某种办法能分辨哪个解是能跑的、哪个是坏的，而这正是功能正确性这套框架提供的东西：把候选程序跑一遍就知道了。

局限与更广的影响

论文明确写了模型吃力的地方：当文档字符串描述一长串连续的操作，或者需要把操作绑定到变量上时，它就容易出错^[1]。这两种情况都属于说明分散在若干步骤里、模型必须跟踪中间结果并把它们和名字对应起来的场合，而不是写一个自成一体的表达式。作者还讨论了代码生成在更广层面上的影响，涉及安全、安保与经济^[1]。

为什么重要

这项工作留下两样比具体数字更持久的东西。第一是 HumanEval 本身：把评测绑在功能正确性上，代码生成就有了一个含义具体的分数，模型之间可以比「写出来的程序能不能用」^[1]。第二是覆盖面。Codex 的一个独立的生产版本为 GitHub Copilot 提供支持^[1]，把模型写的代码直接放进程序员干活的编辑环境里。论文里那个采样结果也提示了这类系统在实践中的用法：它不是答一次就该被信任的权威，而是一个候选生成器，后面还要由人或者测试套件去检验。