Jason Wei在最近的斯坦福NLP研讨会上展示了这篇文章，OpenAI的同事、GPT-4o团队成员之一William Fedus也转发了这篇推文。
如果评估不够好，进展就会受阻。当我们的评估改进后，一些想法才被发现是好的。当没有可以攀登的单一指标时，良好的评估在训练后尤其重要。
Jason Wei从2023年2月开始加入OpenAI，此前他在Google Brain担任研究科学家。
今年3月他曾在推特上分享OpenAI的「996」作息（为了AGI，全员主动996！OpenAI匿名员工自曝3年工作感受）
也在今年5月GPT-4o发布后主动现身说法，比较了大公司谷歌和初创公司OpanAI在人事策略上的不同思路，为我们解开了OpenAI成功之谜的一角。
那么就让我们看看，这篇博客具体谈了哪些内容。
评估对于LLM有多重要
目前，每个开发LLM的人都在使用基准评估，但是这个领域应该得到更多的关注和投入，因为这是对学界工作的直接激励，与模型的重大性能突破密切相关。
由于LLM大规模、多任务的特性，而且模型通常会给出很长的回答，因此评估工作变得更加困难。目前还没有一个评估集可以充分测评LLM的能力。
当前流行的评估仍然使用非常简单的评分机制（单选/多选、核对数字或运行单元测试）。即使这些简单的机制也存在问题，比如使用了不同的prompt或解析答案的方式。
一个比较好的方案是让LLM采用同一种prompt，比如零样本思维链。
这可能并不是一个完美的解决方案，但为了「控制变量」，更公平地衡量所有LLM的能力，付出一些代价也是值得的。
零样本思维链prompt：https://arxiv.org/abs/2205.11916
什么是成功的评估
首先，如果一个评估测试被用在突破性论文中，而且受到整个领域的信任，那么它显然是成功的。
按照这个标准，过去5年中有一些成功的评估被广泛采用：
- GLUE/SuperGLUE（General Language Understanding Evaluation）：基本被前LLM时代的所有NLP论文所使用，包括BERT、T5等。
论文地址：https://gluebenchmark.com/
- MMLU（Measuring Massive Multitask Language Understanding）：几乎所有LLM论文都使用MMLU，也是DeepMind和Google最喜欢的评估。
这项测试涵盖了基础数学、美国历史、计算机科学、法律等领域的57项任务，模型想要在这项测试中获得高评分，则必须具备广泛的世界知识和解决问题的能力。
论文地址：https://arxiv.org/abs/2009.03300
- GSM8K（Grade Scholl Math 8K）：包括多种语言的小学数学应用题，可以刺激LLM进行多步推理，每一篇关于思想链（CoT）的论文中都会使用。
https://klu.ai/glossary/GSM8K-eval
- MATH：包含超过1.2万个竞赛难度的数学题目，也被大多数LLM论文使用。
论文地址：https://arxiv.org/pdf/2103.03874
- HumanEval：由OpenAI建立的手写评估测试，用于衡量从文档字符串生成程序的功能正确性
项目地址：https://github.com/openai/human-eval?tab=readme-ov-file
当然，这里列出的是一个不完全列表，还有很多其他非常优秀的评估测试，包括HellaSwag、SQuAD以及Jason Wei本人参与开发的MGSM、BBH等。
一篇突破性的论文提出一个全新的评估，并宣称在上面取得了性能突破，再将其推广开来，这是一种常见的范式。
比如GLUE由BERT推广，MMLU 由DeepMind推出的Gopher、Chinchilla和Flan-PaLM推广，首先提出CoT prompting的论文宣称在GSM8K上取得性能突破，Minerva在MATH上体现了数学能力，OpenAI的Codex首先尝试HumanEval。
这些评估为什么可以在LLM领域流行起来？
Jason认为，一个评估集上的高分必须能体现出一些有重要意义而且易于理解的事情。
比如「超越人类表现」是容易理解的，「解决小学水平的数学题」对于模型能力的意义，也不难明白。
此外，评估的主题也直接影响着研究者们的关注程度。
在为某个特定领域（如法律、医疗等）创建高质量评估集时，最重要的是基于领域专家的意见和价值判断，而且不要对流行程度期待过高。
Jason曾做过一个组织病理学的图像基准测试，不出所料，除了医学图像分析领域，这项研究几乎没有引起任何关注，文章只有40次引用。
但也有例外，比如OpenAI曾经投入大量资金开发LLM的代码能力，在Codex和CoPilot等项目获得关注后，人们也开始意识到这个小众领域的重要性，HumanEval也因此流行起来。
另一个现实层面的因素是，如果希望自己开发的评估基准获得更多关注，你应该积极地帮助或激励别人使用它。
Jason Wei说，他开发一个评估集之后，会主动提出帮别人在上面运行模型。如果模型表现良好，开发人员就会喜欢这个评估，并主动帮你推广。
此外，也可以试着让公司或实验室内部的经理认可你的评估，这样他们就会要求研发人员撰写报告，阐述模型在这个评估上表现如何。
评估的「七宗罪」
好的评估是相似的，糟糕的评估各有各的缺陷。大多数不成功的评估都至少犯过以下错误中的一个：
1. 没有足够的示例
这相当于一个嘈杂的且糟糕的用户界面。例如，在训练过程中运行评估时，各个checkpoint之间分数波动很大，研究人员就不会喜欢使用这种评估。
最好有至少1000个示例，对于单选/多选题目组成的评估集，示例数应该更多。GPQA就是这方面的反例，尽管是一个很好的评估，但它随着输入的prompt不同会发生波动，因而很难使用。
2. 质量不够高
如果评估中有很多错误，就得不到大家的信任。
例如，Jason曾经长期使用NQ数据集（Natural Questions）进行评估，但GPT-4的能力强大到跨过了一个阈值——即如果模型给出的答案被判定为错，更可能的情况是评估提供的真实答案错了，因此他不再使用NQ。
3. 指标过于复杂
过于复杂的评估会让人难以理解，因而很少使用，这方面的反例是HELM评估集。
HELM的第一版是一项巨大的努力，但它有太多的指标和子集。拥有单一数字指标至关重要——我想不出任何优秀的评估是没有单一数字指标的。
4. 运行太麻烦
如果运行起来太麻烦，即使其他方面都很好，也不会吸引很多人使用，比如BIG-Bench。
BIG-Bench运行起来非常痛苦，包括对数概率评估和生成评估，子集太多、示例太多，而且需要不同的基础设施，所以运行花了很长时间。这也许就是BIG-Bench没有获得太多关注的原因，尽管它提供了很多信号。
5. 没有针对一项有意义的任务
如果评估不是针对一项有意义的任务，AI研究人员就不会非常关心它。
例如，BIG-Bench Hard有诸如推荐电影或正确结束括号之类的任务。这些任务具有挑战性，并且随着模型大小的改变，体现出良好的的变化趋势。
但是，在这些任务上做得好并不能对模型的智能程度做出实质性结论。成功的评估通常会衡量对模型智能至关重要的方面，例如语言理解、考试问题或数学等。
6. 评分不正确
如果有人因为模型评分不正确需要调试代码，并且他们不同意评分，那么他们可以立即舍弃这个评估。所以，尽量减少解析模型引起的错误，或者尽可能给出最好的自动评分的prompt。
7. 性能饱和过快
大模型的性能飞速发展，为了使评估集能经得起时间考验，因此不能使模型性能饱和过快。
例如，GLUE/SuperGLUE的分数饱和得太快，改进模型很难带来巨大的收益，大家就会停止使用这种评估测试。LM在摘要、翻译等任务上的性能也进步很快，开发评估集的速度很难追上，因此几乎没有人使用这类任务了。
除了传统的评估数据集，还有一种范式正在兴起——以LMSYS为代表的人类成对评估（human pairwise rating），这种机制有很强的普适性，可以用于所有类型的模型。
但这也是一把双刃剑。优势在于，得到的单一的数字指标可以衡量LLM在一组通用prompt上的表现，非常简单直观，而且样本级别的噪声可以在大量样本上得到平均。
另一方面，我们不清楚人类评估者具体在为模型的哪一方面打分——与答案的正确性相比，感觉和风格在评分中有多少占比？
此外，还需要关注到的一个问题是评估集的数据污染。一个良好的评估发布之后，其中的示例往往会在互联网上流传开来，传播到arxiv论文、ChatGPT示例或Reddit帖子中。
解决方法之一是建立隐藏测试集，但这会带来很多分歧和冲突。Christopher Manning曾提出一个很好的建议——
为评估同时建立公开测试集和私有测试集，并监控哪些模型在两个测试集上的分数有较大差异。这种方法可以平衡公开测试集的高认可度和私有测试集的高可信度。
虽然LLM的评估工作如此重要，但一个现实的困境是，投身于评估测试的工作可能比较痛苦，而且通常不会和模型开发的工作得到同等的回报。
但是无论如何，良好的评估发挥着「目标函数」的作用，会对整个领域产生有力影响，也值得我们投入持续的关注和努力。
