Hugging Face Open LLM Leaderboard DROP ベンチマーク分析

TL;DR

Hugging Face は、Open LLM Leaderboard から DROP (Discrete Reasoning Over Paragraphs) ベンチマークを削除しました。技術的な深掘り調査により、ベンチマークの元の実装（EleutherAI Harness で再現）には、正規化と生成ストップトークンに重大な欠陥があり、それが高性能なモデルを体系的に不利にし、浮動小数点の回答を無効にしていることが明らかになりました。

DROP ベンチマークと初期の異常

DROP は、英語の段落から情報を抽出し、カウントやソートなどの離散的な推論ステップを実行して最終的な答えに到達することをモデルに要求します。パフォーマンスは、カスタム f1 スコアと exact match スコアを使用して測定されます。

Hugging Face が Open LLM Leaderboard に DROP を組み込んだ際、スコアの二峰性分布が観察されました：少数のモデルのみが DROP スコアと全体のリーダーボード平均（ARC, HellaSwag, TruthfulQA, MMLU）の間に相関を示しましたが、大多数のモデルは一般的な能力にかかわらず f1 スコアが 10 未満にとどまりました。

ルート原因 1: 正規化の失敗

調査の結果、正規化プロセスが標準のスペース以外の空白文字（例：改行）が続く数値回答を正しく識別できないことが明らかになりました。

故障メカニズムは次のように機能します：

  1. Separation: システムは文字列を |, -, または で分割します。
  2. Punctuation Removal: 句読点が削除されます。
  3. Number Homogenization: float にキャストできる文字列は float に変換され、その後文字列に戻されます（例：10 は 10.0 になります）。

もしモデルが改行を含む正しい答えを生成した場合（例：`10

Passage:）、正規化ステップはその文字列全体を float にキャストできません。その結果、答えは非数値の文字列として扱われ、正解（これは 10.0` に正規化されます）と一致しなくなります。これにより、モデルが正しい値を予測していたとしても失敗となります。

ルート原因 2: ストップトークンの干渉

Zeno との共同分析により、生成を終了するストップトークンとしてピリオド (.) を使用することによって引き起こされる、2 つの追加的なシステム的な問題が特定されました。

  • 浮動小数点の消去: ストップトークンがピリオドであるため、浮動小数点数を必要とする答え（例：12.25）は小数点で即座に中断され、どのモデルも正しい浮動小数点結果を達成することが不可能になります。
  • 長形式の回答へのペナルティ: ファewショットプロンプト形式に従おうとする高品質なモデルは、答えに続いて次の質問のための妥当なプロンプトを生成することがよくあります。生成はその後のプロンプトで最初に遭遇するピリオドでのみ停止するため、モデルは過剰なトークンを生成し、これが f1 スコアを低下させます。

影響と解決策

Hugging Face は、ピリオドではなく最初の改行 ( ) で生成された回答を分割する部分的な修正をテストしました。この近似により、DROP スコアと全体のモデルパフォーマンスの間の相関がはるかに強くなり、ストップトークンが結果の偏りの主な要因であることが確認されました。

ただし、完全な修正には、正規化の影響を受けるすべての浮動小数点の回答を含む例の 50% 以上を再実行する必要があり、これには莫大な GPU 時間が必要になります。

EleutherAI Harness の実装が元の 'official DROP' コードに厳密に従っているため、Hugging Face はベンチマークの評価ロジック自体が欠陥があると結論付けました。その結果、DROP は Open LLM Leaderboard から削除されました。現在、チームはスコアリングと正規化ロジックを修正するためにコミュニティと学術界の協力を呼びかけています。

Sources