机器之心发布

作者:符尧、何俊贤

本项目由上海交通大学,清华大学,爱丁堡大学共同完成。

ChatGPT 的出现,使中文社区意识到与国际领先水平的差距。近期,中文大模型研发如火如荼,但中文评价基准却很少。

在 OpenAI GPT 系列 / Google PaLM 系列 / DeepMind Chinchilla 系列 / Anthropic Claude 系列的研发过程中,MMLU / MATH / BBH 这三个数据集发挥了至关重要的作用,因为它们比较全面地覆盖了模型各个维度的能力。最值得注意的是 MMLU 这个数据集,它考虑了 57 个学科,从人文到社科到理工多个大类的综合知识能力。DeepMind 的 Gopher 和 Chinchilla 这两个模型甚至只看 MMLU 的分数,因此我们想要构造一个中文的,有足够区分度的,多学科的基准榜单,来辅助开发者们研发中文大模型

我们花了大概三个月的时间,构造了一个覆盖人文,社科,理工,其他专业四个大方向,52 个学科(微积分,线代 …),从中学到大学研究生以及职业考试,一共 13948 道题目的中文知识和推理型测试集,我们管它叫 C-Eval,来帮助中文社区研发大模型。

这篇文章是把我们构造 C-Eval 的过程记下来,与开发者们分享我们的思考和我们视角下的研发重点。我们的最重要目标是辅助模型开发,而不是打榜。一味地追求榜单排名高会带来诸多不利后果,但如果能够科学地使用 C-Eval 帮助模型迭代的话,则可以最大化地利用 C-Eval。因此我们推荐从模型研发的视角来对待 C-Eval 数据集和榜单。

打开网易新闻 查看精彩图片

网站:
https://cevalbenchmark.com/

Github: https://github.com/SJTU-LIT/ceval

论文:
https://arxiv.org/abs/2305.08322

目录

打开网易新闻 查看精彩图片

1 - 模型强弱的核心指标

首先,把一个模型调成一个对话机器人这件事情并不难,开源界已经有了类似于 Alpaca, Vicuna, RWKV 这样的对话机器人,跟它们随便聊聊感觉都还不错;但要真正希望这些模型成为生产力,随便聊聊是不够的。所以构造评价基准的第一个问题是要找到区分度,弄明白什么样的能力才是区分模型强弱的核心指标。我们考虑知识推理这两项核心。

1.1 - 知识

为什么说知识性的能力是核心能力?有以下几点论点:

我们希望模型可以通用,可以在不同领域都贡献生产力,这自然需要模型知道各个领域的知识。

我们同时希望模型不要胡说八道,不知为不知,这也需要扩大模型的知识,让它可以在更少的时候说它不知道。

斯坦福的 HELM 英文评价榜单中,一个重要的结论是,模型大小与知识密集型任务的效果显著正相关,这是因为模型的参数量可以被用来储存知识。

上文已经提到,已有的重要模型,比如 DeepMind 的 Gopher / Chinchilla,在评价的时候几乎只看 MMLU,MMLU 的核心就是测模型的知识覆盖面。

GPT-4 的发布博客中,首先就是列出模型在各个学科考试上的效果,作为模型能力的衡量标准。

因此,知识型能力可以很好地衡量底座模型的潜力。

1.2 - 推理

推理能力是在知识的基础上进一步上升的能力,它代表着模型是否能做很困难,很复杂的事情。一个模型要强,首先需要广泛的知识,然后在知识的基础上做推理。

推理很重要的论点是:

GPT-4 的发布博客中,OpenAI 明确写道 “The difference comes out when the complexity of the task reaches a sufficient threshold” (GPT-3.5 和 GPT-4 的区别只在任务复杂到一定程度之后才会显现)。这说明推理是很显著的强的模型有,弱一点的模型不大有的能力。

在 PaLM-2 的 Tech Report 中,BBH 和 MATH 这两个推理数据集被专门列出来讨论划重点。

如果希望模型成为新一代的计算平台,并在上面孕育出全新的应用生态的话,就需要让模型能够做足够强的完成复杂任务的能力。

这里我们还需要厘清推理和知识的关系:

知识型的能力是模型能力的基础,推理能力是进一步的升华 — 模型要推理也是基于现有的知识图里。

知识性任务的榜单上,模型大小和模型分数一般是连续变化的,不大会因为模型小就出现断崖式下跌 — 从这个角度来说知识型的任务更有区分度一点。

推理型任务的榜单上,模型大小和模型分数可能存在相变,只有当模型大到一定程度之后(大概是 50B 往上,也就是 LLaMA 65B 这个量级),模型推理能力才会上来。

对于知识性的任务,Chain-of-thought (CoT) prompting 和 Answer-only (AO) prompting 的效果是差不多的;对于推理型任务,CoT 显著好于 AO.

所以这边需要记住一下,CoT 只加推理效果不加知识效果。在 C-Eval 数据集中,我们也观察到了这个现象。

2 - C-Eval 的目标

有了上述对于知识和推理的阐述,我们决定从知识型的任务出发,构造数据集测试模型的知识能力,相当于对标一下 MMLU 这个数据集;同时,我们也希望带一点推理相关的内容,进一步衡量模型的高阶能力,所以我们把 C-Eval 中需要强推理的学科(微积分,线性代数,概率 …)专门抽出来,命名为 C-Eval Hard 子集,用来衡量模型的推理能力,相当于对标一下 MATH 这个数据集。

在 C-Eval Hard 上面,模型首先需要有数学相关知识,然后需要有逐步解题的思路,然后需要在解题过程中调用 Wolfram Alpha/ Mathematica/ Matlab 进行数值和符号 / 微分和积分计算的能力,并把计算过程和结果以 Latex 的格式表示出来,这部分的题目非常难。

C-Eval 希望可以在整体上对标 MMLU (这个数据集被用于 GPT-3.5, GPT-4, PaLM, PaLM-2, Gopher, Chinchilla 的研发),希望在 Hard 的部分对标 MATH (这个数据集被用于 GPT-4, PaLM-2, Minerva, Galactica 的研发)。

这里需要注意的是,我们的最重要目标是辅助模型开发,而不是打榜。一味地追求榜单排名高会带来诸多不利后果,这个我们马上会阐述;但如果能够科学地使用 C-Eval 帮助模型迭代的话,则会得到巨大收益。我们推荐从模型研发地视角来对待 C-Eval 数据集和榜单。

2.1 - 目标是辅助模型开发

在实际研发的过程中,很多时候我们需要知道某种方案的好坏或者某种模型的好坏,这个时候我们需要一个数据集帮助我们测试。以下是两个经典场景:

场景 1 ,辅助超参数搜索:我们有多种预训练数据混合方案,不确定哪种更好,于是我们在 C-Eval 上相互比较一下,来确定最优预训练数据混合方案。

场景 2 ,比较模型的训练阶段:我有一个预训练的 checkpoint ,也有一个 instruction-tuned checkpoint,然后我想要衡量我的 instruction-tuning 的效果如何,这样可以把两个 checkpoint 在 C-Eval 上相互比较,来衡量预训练和 instruction-tuning 的相对质量。

2.2 - 打榜不是目标

我们需要强调一下为什么不应该以榜单排名作为目标:

如果把打榜作为目标,则容易为了高分而过拟合榜单,反而丢失通用性 — 这是 GPT-3.5 之前 NLP 学术界在 finetune Bert 上学到的一个重要教训。

榜单本身只测模型潜力,不测真实用户感受 — 要模型真的被用户喜好,还是需要大量的人工评价的

如果目标是排名,则容易为了高分想走捷径,失去了踏实科研的品质与精神。

因此,如果把 C-Eval 作为辅助开发的工具,那么可以最大程度上的发挥它的积极作用;但是如果把它作为一个榜单排名,则存在极大的误用 C-Eval 的风险,最终也大概率不会有很好的结果。

所以再一次,我们推荐从模型研发地视角来对待 C-Eval 数据集和榜单。

2.3 - 从开发者反馈中持续迭代

因为我们希望模型可以最大程度的支持开发者,所以我们选择直接跟开发者交流,从开发者的反馈中持续学习迭代 — 这也让我们学到了很多东西;就像大模型是 Reinforcement Learning from Human Feedback 一样,C-Eval 的开发团队是 Continue Learning from Developers’ Feedback.

具体来说,我们在研发的过程中,邀请了字节跳动,商汤,深言等企业将 C-Eval 接入到他们自己的工作流中做测试,然后相互沟通测试过程中存在哪些比较有挑战的点。这个过程让我们学习到很多开始时没想到的内容:

很多测试团队,即使是在同一个公司,也无法知道被测试模型的任何相关信息(黑盒测试),甚至不知道这个模型有没有经过 instruction-tuning ,所以我们需要同时支持 in-context learning 和 zero-shot prompting.

因为有些模型是黑盒测试,没办法拿到 logits,但是小模型没有 logits 就比较难确定答案,所以我们需要确定一套小模型定答案的方案。

模型的测试模型有多种,比如 in-context learning 和 zero-shot prompting;prompt 的格式有多种,比如 answer-only 和 chain-of-thought;模型本身有多种类型,比如 pretrained checkpoint 和 instruction-finetuned checkpoint,因此我们需要明确这些因素各自的影响以及相互作用。

模型的对于 prompt 的敏感度很高,是否需要做 prompt engineering,以及 prompt engineering 是否有碍公平。

GPT-3.5 / GPT-4 / Claude / PaLM 的 prompt engineering 应该怎么做,然后如果从中学习到他们的经验。

以上的这些问题都是我们在跟开发者的交互过程中,从开发者反馈里发现的。在现在 C-Eval 的公开版本的文档和 github 代码中,这些问题都有解决。

上面的这些过程也证明了,从模型研发的视角来对待 C-Eval 数据集和榜单,可以非常好地帮助大家开发中文大模型。

我们欢迎所有的开发者们给我们的 GitHub 提 issue 和 pull request,让我们知道如何更好地帮助你,我们希望可以更好地帮助你 :)

3 - 如何保证质量

这个章节我们讨论在制作的过程中,我们用了哪些方法来保证数据集的质量。这里我们最重要的参考是 MMLU 和 MATH 这两个数据集,因为 OpenAI, Google, DeepMind, Anthropic 这四个最重要的大模型团队都重点参考了 MMLU 和 MATH,所以我们希望可以向这两个数据集看齐。在我们初步的调研和一系列的讨论之后,我们做了两个重要的决策,一个是从头开始手工制做数据集,另一个是在此过程中重点防止题目被爬虫爬到训练集里

3.1 - 手工制作

GPT 的开发过程的一个重要启发是,人工智能这行,有多少人工就有多少智能,这个在我们建立 C-Eval 的过程中也有很好地体现,具体来说,从题目来源看:

C-Eval 里面的题目大多是来源于 pdf 和 word 格式的文件,这类题目需要额外的处理和(人工)清洗才能使用。这是因为网上各种题目太多了,直接是网页文本形式存在的题目很可能已经被用于模型的预训练中

然后是处理题目:

收集到题目之后,先把 pdf 文件做 OCR 来电子化,然后把格式统一成 Markdown,其中数理的部分统一用 Latex 格式来表示

公式的处理是一件麻烦的事情:首先 OCR 不一定能识别对,然后 OCR 也不能直接识别成 Latex;这里我们的做法是能自动转 Latex 就自动转,不能自动转就同学自己手动敲

最终的结果是,13000 多 道题目里面所有跟符号相关的内容(包括数学公式和化学式,H2O 这种)都是被我们项目组的同学一一验证过的,我们大概有十来位同学花了将近两周的时间做这个事情

所以现在我们的题目可以非常漂亮地用 markdown 的形式呈现,这里我们给一个微积分的例子,这个例子可以直接在我们的网站中,explore 的部分看到:

打开网易新闻 查看精彩图片

接下来的难点就是如何构造官方的 chain-of-thought prompt ,这个地方的重点在于,我们需要保证我们的 CoT 是对的。我们一开始的做法是对于每个 in-context example ,我们让 GPT-4 生成一个 Chain-of-thought,但后来发现这个不大行,一来是生成的太长了 (超过 2048 个 token),有些模型的输入长度不一定支持;另一个是错误率太高了,一个个检查不如自己做一遍

所以我们的同学们就基于 GPT-4 生成的 CoT,把微积分,线代,概率,离散这些 prompt 的题目(每个科目 5 道题作为 in-context examples),真的自己做了一遍,以下是一个例子:

打开网易新闻 查看精彩图片

左边是同学自己做的,然后写成了 Markdown - Latex 格式;右边是渲染出来的效果

大家也能感受到为什么题目很难,chain-of-thought prompt 很长,为什么模型需要有能力做微积分的符号和数值计算

3.2 - 防止混入训练集

为了评测的科学性,我们考虑了一系列机制来防止我们的题目被混入训练集

首先,我们的测试集只公开题目不公开答案,大家可以拿自己的模型在本地把答案跑出来然后在网站提交,然后后台会给出分数

然后,C-Eval 的所有题目都是模拟题,从中学到考研到职业考试我们都没有用过任何真题,这是因为全国性考试的真题广泛存在于网上,非常容易被爬取到模型训练集里

当然,尽管我们做出了这些努力,但可能也会不可避免的发生某个网页里能搜到题库里的题目,但我们相信这种情况应该不多。且从我们已有的结果看,C-Eval 的题目还是有足够区分度的,特别是 Hard 的部分。

4 - 提升排名的方法

接下来我们分析有哪些方法可以提升模型的排名。我们先把捷径给大家列出来,包括使用不能商用的 LLaMA 和使用 GPT 产生的数据,以及这些方法的坏处;然后我们讨论什么是困难但正确的路

4.1 - 有哪些捷径可以走?

以下是可以走的捷径:

使用 LLaMA 作为基座模型:在我们另一个相关的英文模型评测项目 Chain-of-thought Hub 中,我们指出了 65B 的 LLaMA 模型是一个稍弱于 GPT-3.5 的基础模型,它有着很大的潜力,如果把它用中文的数据训练,其强大的英文能力可以自动迁移到中文。

但这样做的坏处,一来是研发能力的上限被 LLaMA 65B 锁死,不可能超过 GPT-3.5,更何况 GPT-4 了,另一方面是 LLaMA 不可商用,使用它商业化会直接违反条例

使用 GPT-4 生成的数据:特别是 C-Eval Hard 的部分,直接让 GPT-4 做一遍,然后 GPT-4 的答案喂给自己的模型就可以了

但这样做的坏处,一来是赤裸裸作弊,得到的结果并不能泛化,不能代表模型真实能力;二来是如果商业化,就直接违反了 OpenAI 的使用条例;三来是从 GPT-4 做蒸馏会加剧模型胡说八道的现象,这是因为 RLHF 在微调模型拒绝能力的时候,是鼓励模型知之为知之,不知为不知;但是直接抄 GPT-4 的话,GPT-4 知道的东西,其他的模型不一定知道,这样反而鼓励模型胡说八道。这个现象在 John Schulman 近期在伯克利的一个演讲中被重点讨论了。

很多时候,看似是捷径的道路,其实在暗中标好了价格。

4.2 - 困难但正确的路

最好的方法是自立自强,从头研发。这件事情很难,需要时间,需要耐心,但这是正确的路。

具体来说,需要重点关注以下机构的论文

OpenAI - 这个毋庸置疑,所有文章都要全文背诵

Anthropic - OpenAI 不告诉你的东西,Anthropic 会告诉你

Google DeepMind - Google 比较冤大头,什么技术都老实告诉你,不像 OpenAI 藏着掖着

如果读者在里经验不足,那么可以先不要看其他的地方的文章。先培养判断力,再去读其他地方的文章,这样才能分清好坏。在学术上,要分清好坏,而不是不加判断一味接受。

在研发的过程中,建议关注以下内容:

如何组 pretraining 的数据,比如 DoReMi 这个方法

如何增加 pretraining 的稳定性,比如 BLOOM 的方法

如何组 instruction tuning 的数据,比如 The Flan Collection

如何做 instruction tuning ,比如 Self-instruct

如何做 RL,比如 Constitutional AI

如何增加 reasoning 的能力,比如我们先前的博客

如何增加 coding 能力,比如 StarCoder

如何增加工具使用的能力 (C-Eval Hard 需要模型能调用工具做科学计算),比如 toolformer

4.3 - 不着急

大模型就是一件花时间的事情,它是对人工智能工业能力的全方位大考:

OpenAI 的 GPT 系列从 GPT-3 走到 GPT-4,从 2019 到 2023,一共花了四年的时间。

Anthropic 原班人马从 OpenAI 剥离之后,即使有 GPT-3 的经验,重新做一遍 Claude 也花了一年的时间。

LLaMA 的团队,即使有 OPT 和 BLOOM 的教训,也花了六个月的时间。

GLM-130B 从立项到发布,花了两年的时间。

MOSS 的 alignment 的部分,在 RL 之前的内容,也花了将近半年的时间,这还是没算 RL 的。

因此,不用着急打榜,不用明天就看结果,不用后天上线 — 慢慢来,一步一步来。很多时候,困难但正确的路,反而是最快的路。

5 - 结论

在这篇文章中,我们介绍了 C-Eval 的开发目标,过程,和重点考量的因素。我们的目标是帮助开发者更好地开发中文大模型,促进学术界和产业界科学地使用 C-Eval 帮助模型迭代。我们不着急看结果,因为大模型本身就是一件非常困难的事情。我们知道有哪些捷径可以走,但也知道困难但正确的路反而是最快的路。我们希望这份工作可以促进中文大模型的研发生态,让人们早一点体验到这项技术带来的便利。

附录 1:C-Eval 包含的科目

打开网易新闻 查看精彩图片

附录 2:项目成员的贡献

打开网易新闻 查看精彩图片

注:文中所提论文可以在原文页面找到相应网址。