Open LLM 排行榜：DROP 深度解析
最近，三項新基準測試被新增到 Open LLM 排行榜：Winogrande、GSM8k 和 DROP，它們使用了在 EleutherAI Harness 中復現的原始實現。對 DROP 分數的初步檢視發現了一些奇怪的現象，絕大多數模型的 f1-分數低於 10 分（滿分 100 分）！我們進行了深入探究以瞭解發生了什麼，請隨我們一起來看看我們發現了什麼！
初步觀察
DROP（Discrete Reasoning Over Paragraphs，段落離散推理）是一種評估，模型必須從英文段落中提取相關資訊，然後對這些資訊執行離散推理步驟（例如，對專案進行排序或計數以得出正確答案，參見下表中的示例）。使用的指標是自定義的 f1 和精確匹配分數。
我們三週前將其新增到 Open LLM 排行榜中，並觀察到預訓練模型的 f1 分數呈現出意想不到的趨勢：當我們將 DROP 分數與排行榜原始平均值（ARC、HellaSwag、TruthfulQA 和 MMLU 的平均值，這是衡量模型整體效能的合理指標）進行繪製時，我們期望 DROP 分數與它相關（更好的模型表現更好）。然而，這隻適用於少數模型，所有其他模型的 DROP f1 分數都非常低，低於 10。
標準化質疑
在對這些令人驚訝的行為進行首次深入研究時，我們發現標準化步驟可能未按預期工作：在某些情況下，當正確的數值答案後直接跟有除空格之外的空白字元（例如，換行符）時，此標準化會忽略它們。讓我們看一個示例，生成的文字是 10\n\nPassage: The 2011 census recorded a population of 1,001,360，而正確答案是 10。
標準化分幾個步驟進行，包括生成和金標。
- 根據分隔符分割
|,-, 或10\n\nPassage:不包含此類分隔符，因此在此步驟之後被視為單個實體。 - 去除標點符號 第一個標記隨後變為
10\n\nPassage（:被去除） - 數字同質化 每個可以轉換為浮點數的字串都被視為數字並轉換為浮點數，然後重新轉換為字串。
10\n\nPassage保持不變，因為它不能轉換為浮點數，而金標10變為10.0。 - 其他步驟 隨後進行許多其他標準化步驟（刪除冠詞、刪除其他空白字元等），我們原始的示例變為
10 passage 2011.0 census recorded population of 1001360.0。
然而，總體分數並非基於字串計算，而是基於從字串中提取的詞袋（BOW），此處為 {'recorded', 'population', 'passage', 'census', '2011.0', '1001360.0', '10'}，與金標的詞袋進行比較，金標也以上述方式進行了標準化，即 {10.0}。正如您所見，它們沒有交集，即使模型預測了正確的輸出！
總而言之，如果一個數字後面跟著任何一種非簡單空格的空白字元，它將無法透過數字標準化，因此如果它也是一個數字，將永遠無法匹配金標！第一個問題很可能會嚴重影響分數，但顯然它不是導致 DROP 分數如此之低的唯一因素。我們決定進一步調查。
深入探討結果
在我們的調查深入進行中，我們的朋友 Zeno 加入了我們，並對結果進行了更徹底的探索，他們研究了 5 個模型，這些模型代表了我們在 DROP 分數中發現的問題：falcon-180B 和 mistral-7B 的表現低於預期，Yi-34B 和 tigerbot-70B 在 DROP 上表現非常好，與它們的平均分數相關，而 facebook/xglm-7.5B 則處於中間水平。
如果您願意，可以在Zeno 專案中嘗試分析結果！
Zeno 團隊發現了兩個更令人擔憂的特點：
- 沒有一個模型在浮點答案上獲得正確結果。
- 生成長答案的高質量模型實際上獲得了較低的 f1 分數。
此時，我們認為這兩個失敗案例實際上是由同一個根本因素造成的：使用 . 作為停用詞標記（用於結束生成）。
- 浮點答案在生成完成之前系統地被中斷。
- 高質量的模型會嘗試匹配少樣本提示格式，它們會生成
Answer\n\nPlausible prompt for the next question.，並且只在實際答案之後的可行提示延續中遇到第一個.時才停止，因此生成了過多的詞語，導致 f1 分數很低。
我們假設透過使用 \n 代替 . 作為生成結束符，可以解決這兩個問題。
更改生成結束符
所以我們嘗試了一下！我們調查了在現有結果中使用 \n 作為生成結束符。如果生成的答案中包含第一個 \n，我們就根據它進行分割，並重新計算分數。 請注意，這只是對正確結果的近似，因為它無法修復過早地被 . 截斷的答案（例如浮點數答案）——但它也不會給任何模型帶來不公平的優勢，因為所有模型都受到了這個問題的影響。然而，這是我們在不重新執行模型的情況下能做到的最好情況（因為我們希望儘快向社群釋出訊息）。
我們得到的結果如下——以 \n 分割與其他分數以及整體效能都高度相關。
那麼接下來呢？
快速計算顯示，重新執行所有模型的完整評估將耗費巨大（完整的更新花費了 8 年的 GPU 時間，其中很大一部分被 DROP 佔用），我們估算了僅重新執行失敗示例的成本。
在 10% 的情況下，正確答案是浮點數（例如 12.25），模型預測以正確的開頭（例如 12）開始，但被 . 截斷——如果生成繼續，這些預測很可能本來是正確的。我們肯定需要重新執行它們！我們的估計沒有計算以可能被中斷的數字結尾的生成句子（其他生成的 40%），也沒有計算任何因標準化而弄亂的預測。
為了獲得正確的結果，我們將需要重新執行超過 50% 的示例，這將耗費大量的 GPU 時間！我們需要確保這次我們將執行的實現是正確的。
在與 EleutherAI 團隊（在 GitHub 和內部）進行討論後，他們指導我們檢視程式碼並幫助我們進行調查，我們非常清楚 LM Eval Harness 的實現嚴格遵循“官方 DROP”程式碼：因此，需要開發此基準評估的新版本！因此，我們決定在出現新版本之前，將 DROP 從 Open LLM 排行榜中刪除。
本次調查的一個啟示是，社群集體調查基準測試以發現以前遺漏的錯誤具有重要價值。開源、社群和開放式開發的力量再次閃耀，它使得能夠透明地調查一個已經存在多年的基準測試問題的根本原因。
我們希望感興趣的社群成員能與研究 DROP 評估的學者們攜手合作，共同修復其評分和標準化問題。我們很樂意看到它再次可用，因為資料集本身非常有趣和酷。我們鼓勵您在此問題上提供關於我們應如何評估 DROP 的反饋。
感謝許多社群成員指出了 DROP 分數上的問題，也衷心感謝 EleutherAI Harness 和 Zeno 團隊在此問題上提供的巨大幫助。
