這是 大模型評估排障指南 系列文章的第三篇，敬請關注系列文章:

• 關于推理
• 關于 \(\LaTeX\) 公式解析
• 關于可復現性

假設你讀了一篇最近的新模型技術報告，然后心血來潮想要在本機復現他們的結果，卻發現根本沒法復現，這是為什么？
讓我們來探討一下原因。

代碼庫不同

要想復現論文或報告的評估得分并精確到小數點，首先要確保使用的代碼庫一致。

一般情況下，你可以選擇使用作者提供的默認評估代碼，或者參考標準代碼庫實現，如 EleutherAI 的 lm_eval 或 HuggingFace 的 lighteval 等。但如果作者沒有說明評估代碼的來源，那很遺憾，基本上不太可能精確復現了。

如果你想知道為什么代碼實現不一樣會導致結果差異，可以參考這篇我們與 Hugging Face 評估團隊共同撰寫的 博客 (?)。博客中介紹了對 3 種常見 MMLU 評估代碼 (lm_eval、helm、以及原作者實現) 的研究測試，重點解釋了實現差異以及對模型得分的影響。

注：正因如此，Hugging Face 團隊決定推出 Open LLM Leaderboard，以便統一規范，使得在排行榜上的模型得分之間的對比更加公正。

導致結果微妙差異的其他因素

即便使用的代碼庫相同，也會因為實現上的小細節不同而導致結果差異，可能因素有：

• 隨機種子不同
  • 一般來說，推理階段受隨機種子影響的程度要比訓練階段小得多。不過種子對 CUDA 運算 (可以參考 PyTorch 的 reproducibility 頁面) 會產生一些影響從而改變預測結果，尤其是基于非貪心算法生成的時候。另外如果使用 few-shot 的方式推理，隨機種子還可能影響 prompt、前后處理函數。-> 有時候微小的差距可能導致評估結果好幾分的差異。
• 評估指標不同。在實踐中，哪怕是指標的名字相同，也可能代表不同的含義，比如:
  • 對于 精確匹配 任務，如果原作者使用 對數似然 (計算不同答案的對數概率) 計算評估得分，而你采用 生成式 (只比較貪心生成結果與參考答案)，那你們計算出的指標就會不同。
  • 我們還發現，有一些評估代碼庫雖然定義為 精確匹配，但實際計算的卻是 前綴精確匹配 (只比較生成結果與參考答案的開頭部分)，或者 后綴精確匹配 (與前綴相反)，亦或是 準精確匹配 (歸一化的精確匹配)。-> 因此，不能僅僅依賴于指標名稱來判斷實際評估方式，還是需要查看具體代碼實現。
• 歸一化方式不同
  • 還以 精確匹配 為例，在 lm_eval 庫的 v1 版本中，有一些任務就被簡單地命名為 生成式 精確匹配，如果不看代碼，你可能覺得就是上文提到的那樣，直接對比預測結果和參考答案，不過: 如果查看代碼會發現，在做對比之前預測結果還多做了一步歸一化 (去除標點符號、統一數字格式等)，這明顯會改變對比得分。(現在 lm_eval 庫的 v2 版本已經在多數指標中添加歸一化名稱了。) -> 這是最容易出錯的地方，特別是對于那些需要大量歸一化或答案后處理的任務，例如數學評估 (需要從生成解釋中提取答案)。

Prompt 不同

Prompt 不同會導致模型輸出和評分產生巨大的變化，主要包括 3 個類別:

Prompt 自身

Prompt 格式可能會顯著影響最終得分。

例如在多選題評估中，呈現選項的 prompt 常見格式有以下幾種:

問題: <問題文本>
選項:

| A. <Choice A> | (A) <Choice A> | <Choice A> | 
| B. <Choice B> | (B) <Choice B> | <Choice B> | 
| C. <Choice C> | (C) <Choice C> | <Choice C> | 
| D. <Choice D> | (D) <Choice D> | <Choice D> | 

回答: 

預測格式：A/B/C/D 或 <Choice A/B/C/D>。

這些選項是 語義等價 的，雖然它們包含的內容完全相同，但仍然會導致評估得分差異。我們有一些 實驗結果 (同一模型評估結果差異高達 7 分) 以及 論文 閱讀發現，都得出了類似的結論。

一些評估還會加入任務描述 prompt (例如: 以下問題都是關于 <主題> (The following questions are about <topic>))。同樣地，這些 prompt 的存在與否也會影響評估得分。

這篇 優秀論文? 闡述了這一問題: 許多模型在評估基準數據集上訓練，過擬合了 prompt 和 標準回答的格式，才導致了對其他格式的 prompt 適應能力差。

我們在 Open LLM Leaderboard 2 上的 Llama3.1 系列模型也觀察到了這一現象。它們在標準測試集 MATH-Hard 上預測的答案完全正確，但在 few-shot 簡單模板測試中評估得分反而較低，很可能就是過擬合了 GSM8K 數據集 (另一個數學測試集) 的 prompt 和答案格式。

系統 prompt 和聊天模板

聊天模型的訓練或微調方式通常是指令或偏好，也就是學習推理時遵循模板的能力。例如多輪對話中，模板一般以通用 prompt (也叫 system prompt) 開始，并以特殊 token (一般是 System: ) 作為前綴。通用 prompt 的作用是為模型提供高層次指令，如某個角色的描述或者通用的指令格式。對話中可能還需要在文本前綴添加關鍵詞，如詢問時添加 User，回答時添加 Assistant。

小樣本 (few-shot) 評估時，需要決定這些樣本是一次性提供 (在一個 prompt 中)，還是多輪分次提供 (模仿上一段中的 user/assistant 模式)。

如果不遵循模型推理的最佳模板格式，那么輸出性能就會下降，因為會迫使輸出偏離訓練階段收斂的概率空間。

少樣本 prompt

使用少樣本評估 (不熟悉少樣本可以參考 General knowledge/Model inference) 時，需要注意兩點:

顯然，few-shot 示例數量應與參考任務相同。

此外，必須保證評估時輸入不同模型的 少樣本示例完全一致 (沒錯不用驚訝，不一致時也會影響結果差異，因為不同模型對不同樣本的表現是不一樣的)。甚至你還得保證輸入的 少樣本示例順序完全一致。我們觀察到 MMLU 子測試集上，有些模型因為示例輸入順序的變化導致的評估結果 (點擊 這里 可以查看一些結果) 差異最高可達 3 分。

這里的隨機種子同樣重要。

生成參數不同

對于生成式評估的參數，需要注意:

• 確保使用的 句子終止 token 相同
• 確保模型評估的 生成 token 數相同
• 確保采樣的 種子和溫度系數相同

模型加載不同

我們觀察到的差異點有:

• 硬件不同
  Pytorch 庫并不保證在不同硬件上進行非確定性操作時的可重現性
• 代碼庫不同
  例如推理后端的庫: transformers 和 vllm，它們對矩陣計算的管理方式就不盡相同。
• batch size 不同
  許多評估代碼庫和模型后端已經記錄了這個問題: 推理時使用的 batch size 不同會導致結果差異。如果你想要完全復現結果，必須固定 batch size (當然有時候會因為顯存問題無法做到)。
• 模型加載精度不同
  使用低精度加載模型 (實際上加載的是權重的不同版本) 可以減少內存占用和推理成本，但會導致計算結果改變。

英文原文: https://github.com/huggingface/evaluation-guidebook/blob/main/contents/troubleshooting/troubleshooting-reproducibility.md

原文作者: Nathan Habib

譯者: SuSung-boy

審校: Adeena