13948題目，涵蓋微積分、線代等52個學科，上交清華給中文大模型做了個測試集

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：專案成員的貢獻

#######################################：文中所提論文可以在原文頁面找到對應網址。 ##########

以上是13948題目，涵蓋微積分、線代等52個學科，上交清華給中文大模型做了個測試集的詳細內容。更多資訊請關注PHP中文網其他相關文章！