開源LLM排行榜出了什麼問題？

最近，在釋出了Falcon 🦅 並將其新增到開源LLM排行榜（一個比較開源大型語言模型的公共排行榜）之後，Twitter上出現了一場有趣的討論。

討論圍繞排行榜上顯示的四項評估之一展開：一項用於衡量大規模多工語言理解（簡稱：MMLU）的基準。

社群驚訝地發現，排行榜上當前排名最高的模型——LLaMA模型 🦙 的MMLU評估結果遠低於已釋出的LLaMa論文中的資料。

因此，我們決定深入研究這個問題，以瞭解發生了什麼以及如何解決它 🕳🐇

在我們的探索中，我們與在LLaMA評估中合作的優秀@javier-m以及Falcon團隊出色的@slippylolo進行了討論。話雖如此，下面所有的錯誤當然都應該歸咎於我們，而不是他們！

在這次旅程中，您將學到很多關於如何在一個評估上評估模型，以及是否應該相信您在網上和論文中看到的資料。

準備好了嗎？繫好安全帶，我們起飛了 🚀。

開源LLM排行榜是什麼？

首先，請注意開源LLM排行榜實際上只是一個執行開源基準測試庫Eleuther AI LM Evaluation Harness的包裝器。這個庫是由EleutherAI非營利AI研究實驗室建立的，該實驗室以建立The Pile並訓練GPT-J、GPT-Neo-X 20B和Pythia而聞名。這是一個在AI領域擁有強大實力的團隊！

這個包裝器利用Hugging Face計算叢集的空閒週期執行Eleuther AI harness的評估，並將結果儲存在hub上的資料集中，然後顯示在線上排行榜空間上。

對於LLaMA模型，使用Eleuther AI LM Evaluation Harness獲得的MMLU數字與LLaMa論文中報告的MMLU數字顯著不同。

為什麼會出現這種情況？

1001種MMLU風味

事實證明，LLaMA團隊採用了另一種線上程式碼實現：由開發MMLU基準的原始加州大學伯克利分校團隊提出的評估程式碼，可在https://github.com/hendrycks/test獲取，我們在這裡稱之為“原始實現”。

深入研究後，我們發現了另一個有趣的實現在同一個MMLU資料集上進行評估：斯坦福大學CRFM非常全面的評估基準語言模型整體評估中提供的評估程式碼，我們在這裡稱之為HELM實現。

EleutherAI Harness 和 Stanford HELM 基準都很有趣，因為它們將許多評估（包括 MMLU）收集在一個程式碼庫中，從而全面瞭解模型的效能。這就是 Open LLM Leaderboard 包裝這些“整體”基準而不是為每個評估使用單獨程式碼庫的原因。

為了解決這個問題，我們決定在一些模型上執行這三種可能的MMLU評估實現，並根據這些結果對它們進行排名。

• Harness實現（commit e47e01b）
• HELM實現（commit cab5d89）
• 原始實現（由出色的@olmer在https://github.com/hendrycks/test/pull/13處集成了Hugging Face）

（請注意，Harness 實現最近已更新 - 更多內容請參閱我們文章的末尾）

結果令人驚訝

您可以在文章末尾找到完整的評估資料。

同一基準的這些不同實現給出了截然不同的數字，甚至改變了排行榜上模型的排名順序！

讓我們試著找出這種差異的來源🕵️但首先，讓我們簡要了解一下我們如何在現代LLM中自動評估行為。

在當今LLM世界中我們如何自動評估模型

MMLU 是一個多項選擇題測試，因此是一個相對簡單的基準（相對於開放式問題），但正如我們將看到的，這仍然為實現細節和差異留下了很大的空間。該基準由包含四個可能答案的問題組成，涵蓋 57 個常識領域，這些領域被分為粗粒度類別：“人文學科”、“社會科學”、“STEM”等。

每個問題只有一個正確答案。以下是一個示例

Question: Glucose is transported into the muscle cell:


Choices:
A. via protein transporters called GLUT4.
B. only in the presence of insulin.
C. via hexokinase.
D. via monocarbylic acid transporters.


Correct answer: A

注意：您可以在hub上的資料集檢視器中非常輕鬆地探索更多此資料集。

大型語言模型在AI模型庫中是簡單的模型。它們將一段**文字字串**作為輸入（稱為“提示”），該文字被切分成標記（單詞、子詞或字元，取決於模型的構建方式）並饋送給模型。模型根據此輸入，為其已知的所有標記（稱為模型的“詞彙表”）生成下一個標記的機率分佈：因此，您可以獲得任何標記作為輸入提示延續的“可能性”。

我們可以使用這些機率來選擇一個標記，例如最有可能的標記（或者我們可以透過取樣引入一些微小的噪聲，以避免出現“過於機械”的答案）。將我們選擇的標記新增到提示中並將其反饋給模型，可以生成另一個標記，依此類推，直到生成完整的句子作為輸入提示的延續。

這就是 ChatGPT 或 Hugging Chat 生成答案的方式。

總而言之，我們有兩種主要方式從模型中獲取資訊以對其進行評估：

1. 獲取某些特定詞元組作為提示延續的機率——並比較這些機率以確定我們預定義的可能選擇；
2. 從模型中獲取文字生成（透過我們已經看到的方式重複選擇詞元）——並將這些文字生成與各種預定義可能選項的文字進行比較。

有了這些知識，我們深入研究了MMLU的三個實現，以找出傳送給模型的輸入是什麼，期望的輸出是什麼，以及如何比較這些輸出。

MMLU各種形態：檢視提示

讓我們比較一下每個基準針對同一 MMLU 資料集示例傳送給模型的提示示例

它們之間的差異可能很小，你都發現了嗎？它們是：

• 第一句話、指令和主題：差異很小。HELM額外添加了一個空格，而Eleuther LM Harness沒有包含主題行。
• 問題：HELM和LM Harness添加了“問題：”字首。
• 選項：Eleuther LM Harness 在選項前加上了關鍵詞“Choices”

現在我們如何從這些提示中評估模型？

讓我們從原始MMLU實現如何提取模型預測開始。在原始實現中，我們僅比較模型對四個答案的預測機率。

這在某些情況下對模型有利，例如，您可以在這裡看到：

在這種情況下，模型將正確答案排在4個選項中的最高位，獲得了+1分。但是，如果我們檢視完整的詞彙表，它反而會生成一個不在我們四個選項範圍內的詞：“Zygote”（這更多是一個例子而非實際用例 🙂）。

我們如何才能確保模型儘可能少地犯這類錯誤？

我們可以使用“少量樣本”方法，即我們在提示中提供一個或多個示例，以及它們的預期答案。示例如下：

在這裡，模型有一個預期行為的例子，因此不太可能預測超出預期答案範圍的答案。

由於這能提高效能，因此在所有評估中（包括原始實現、EleutherAI LM Harness 和 HELM），MMLU 通常以 5 次少樣本（在每個提示前加上 5 個示例）進行評估。（注意：在不同的基準測試中，雖然使用相同的 5 個示例，但它們引入模型的順序可能不同，這也是一個可能的差異來源，我們在此不作深入探討。您也顯然必須注意避免在少樣本示例中洩露某些答案……）

HELM：現在我們來看看HELM 實現。雖然少數樣本提示通常相似，但模型評估的方式與我們剛才看到的原始實現截然不同：我們使用模型輸出的下一個詞元機率來選擇文字生成，並將其與此處顯示的預期答案文字進行比較。

在這種情況下，如果我們的“受精卵”標記具有最高機率（如我們上面所見），則模型答案（“受精卵”）將是錯誤的，模型在該問題上將不得分。

Harness：現在我們最終轉向——截至2023年1月的EleutherAI Harness實現，該實現用於計算排行榜的第一個資料。正如我們將看到的，我們在這裡又獲得了一種在同一個評估資料集上計算模型得分的方式（請注意，此實現最近已更新——更多內容請見文章末尾）。

在這種情況下，我們再次使用機率，但這次是完整答案序列的機率，包括字母和答案文字，例如“C. 第二咽弓”。為了計算完整答案的機率，我們獲取每個詞元的機率（如上所述）並將其收集起來。為了數值穩定性，我們透過對機率的對數求和來收集它們，並且我們可以決定是否計算一個歸一化，其中我們將總和除以詞元數量，以避免對較長答案給予太多優勢（稍後會詳細介紹）。示例如下：

以下是模型提供和生成的答案的彙總表，總結了我們目前所看到的內容：

我們已經涵蓋了所有！

現在讓我們比較一下模型在這三種可能的評估方式上的得分

我們可以看到，對於同一資料集，絕對分數和模型排名（參見第一個圖）都對我們決定使用的評估方法非常敏感。

假設您已經完美復刻了LLaMA 65B模型並使用Harness對其進行了評估（得分0.488，見上文）。現在您將其與已釋出的資料（在原始MMLU實現上評估，得分0.637）進行比較。分數相差30%，您可能會想：“天哪，我的訓練徹底搞砸了😱”。但事實遠非如此，這些數字根本不可比較，即使它們都被標記為“MMLU分數”（並且在同一個MMLU資料集上進行評估）。

那麼，在我們所見的所有評估方法中，是否存在一種“最佳方式”來評估模型呢？這是一個棘手的問題。正如我們上面看到的排名變化所示，不同的模型在不同的評估方式下表現可能不同。為了儘可能公平，人們可能會傾向於選擇一種所有測試模型的平均得分最高的實現，這樣我們就可以“解鎖”模型儘可能多的能力。在我們的案例中，這意味著使用原始實現的對數似然選項。但正如我們上面所看到的，使用對數似然在某種程度上也透過限制可能答案的範圍向模型提供了指示，因此可能對較弱的模型幫助過大。此外，對數似然對於開源模型來說很容易訪問，但對於閉源API模型來說並不總是公開的。

那麼，讀者您怎麼看？這篇博文已經很長了，是時候展開討論並邀請您的評論了。請在開源LLM排行榜的以下討論串中討論此話題：https://huggingface.co/spaces/HuggingFaceH4/open_llm_leaderboard/discussions/82

結論

我們旅程的一個關鍵收穫是，評估與其實現密切相關——甚至細緻到提示和分詞等細節。僅僅一句“MMLU結果”幾乎不能提供任何資訊，讓您將其與在另一個庫中評估的數字進行比較。

這就是為什麼像EleutherAI Eval Harness或Stanford HELM這樣的開放、標準化和可復現的基準對社群來說是無價之寶。沒有它們，模型和論文之間的結果比較將是不可能的，這將阻礙LLM改進的研究。

後記：在開源LLM排行榜的案例中，我們決定堅持使用社群維護的評估庫。值得慶幸的是，在撰寫這篇博文期間，EleutherAI Harness周邊令人讚歎的社群，特別是ollmer，在更新Harness中MMLU的評估以使其與原始實現匹配方面做了出色的工作。

我們目前正在使用更新版的EleutherAI Eval Harness更新整個排行榜，所以預計在未來幾周內會出現來自Eleuther Harness v2的得分！（重新執行所有模型需要一些時間，敬請關注 :hugs:）

致謝：

我們非常感謝LLaMA團隊的Xavier Martinet、Aurélien Rodriguez和Sharan Narang，感謝他們在這篇博文中的寶貴建議並回答了我們所有的問題。

可復現性雜湊：

以下是本博文中所用各種程式碼實現的提交雜湊。

• EleutherAI LM harness實現提交e47e01b: https://github.com/EleutherAI/lm-evaluation-harness/tree/e47e01beea79cfe87421e2dac49e64d499c240b4
• HELM實現提交cab5d89: https://github.com/stanford-crfm/helm/tree/cab5d89fadbff86190f29ddfa497301958eaf2ec
• 原始MMLU實現（由出色的@olmer集成了Hugging Face）：https://github.com/hendrycks/test/pull/13