現場から学ぶ言語モデルの再現可能な評価

https://scrapbox.io/files/6654d385349ea2001db3f712.png

論文情報

タイトル：Lessons from the Trenches on Reproducible Evaluation of Language Models

発行日：2024年5月

著者：Stella Biderman et al

所属：EleutherAI, Stability AI

論文のポイント

論文を読んで感じたこと

実際にどうする？

概要

言語モデルの有効な評価は、自然言語処理において未解決の課題であり続けています。研究者やエンジニアは、評価設定へのモデルの感度、異なる手法間での適切な比較の難しさ、再現性と透明性の欠如など、方法論的な問題に直面しています。本論文では、大規模言語モデルの評価における3年間の経験に基づいて、研究者への指針と教訓を提供します。まず、言語モデルの評価において一般的に直面する課題について概観します。次に、これらの課題が研究に与える影響に対処または軽減するためのベストプラクティスを示します。第三に、これらの問題に対処することを目的とした、言語モデルの独立した、再現可能な、拡張可能な評価のためのオープンソースライブラリである「言語モデル評価ハーネス（lm-eval）」を紹介します。本論文では、ライブラリの機能と、ライブラリがこれらの方法論的懸念を緩和するために使用された事例研究について説明します。

1 はじめに

共有ベンチマークタスクにおける評価は、機械学習と言語モデリングのコミュニティにおける進捗状況を追跡し、伝えるために使用される重要なツールです（Ruder, 2021）。ベンチマークは、共有されたコミュニティ目標に向けた進捗状況を追跡し、以前に提案された手法に対する新規手法の改善点を示すために使用されます。したがって、評価慣行は、分野の方向性に重要な役割を果たします。評価慣行における矛盾やバイアスは、歪んだパフォーマンス比較につながる可能性があり、将来の研究の方向性やコミュニティによる新手法の採用に影響を与えたり（Dehghani et al., 2021）、不適切なタスクに最適化されていないモデルを配備することから生じる悪影響をもたらしたりする可能性があります（Bender & Friedman, 2018）。

残念ながら、大規模言語モデルの透明かつ再現可能な評価は非常に困難です。私たちの研究では、さまざまな論文で報告されている結果を再現することや、新しい評価を自分で実行することに頻繁に苦労してきました。この問題に対処するために、評価のための研究インフラストラクチャとして機能する、柔軟な評価ライブラリである「言語モデル評価ハーネス（lm-eval）」を構築しました（Gao et al., 2021）。lm-evalの目的は、研究者が可能な限り簡単にあらゆるモデルで任意のベンチマークを実行できるようにすることです。同時に、新しいモデル推論ライブラリまたは評価ベンチマークの作成者が、自分の仕事とより広範なエコシステムを連携させることも容易にすることを目指しています。

過去3年間、lm-evalの設計は、オープンソースコミュニティのニーズと、言語モデルの評価に関する私たちの理解の進化とともに進化してきました。本論文では、特に有益な発見を得るために役立った教訓を詳しく説明します。自然言語応答の正確性の評価の難しさ、ベンチマーク設計の課題、多くの場合不明瞭または報告されていない実装の詳細への依存性など、言語モデルの評価において一般的に直面するいくつかの課題を強調します（セクション2）。次に、これらの課題にもかかわらず、言語モデリングコミュニティにおける結果の伝達方法を改善し、評価の厳密性を向上させるために特定したベストプラクティスについて説明します（セクション3）。最後に、これらの教訓をどのようにlm-evalの設計に反映させたかについて詳しく説明します（セクション4）。

2 言語モデルの評価における課題

2.1 自然言語能力の評価とスコアリング

言語モデルの評価における最大の課題は、「主要な問題」と呼ばれる概念です。言語モデルを評価する際に、同じアイデアを表現するのに、意味的には同等だが構文的には異なる方法が数多く存在する可能性があります。理想的な状況では、2つの文が異なる単語で同じ内容を表現しているかどうかを自動的に検出する方法があるでしょう。残念ながら、2つの文が意味的に同等かどうかを判断するための最善のツールは、評価しようとしているモデルそのものです。この問題は、多くのLMベンチマーク手法を駆り立てており、LM評価における多くの問題はこの問題に対する特効薬が存在しないことから生じているのです。

原則として、これは単に専門の人間アノテーターにモデル応答の正確性を評価させれば解決できる問題です。これが一般的ではない主な理由はコストです。正確な人間研究を行うことは、公正な報酬が必要なため、難しいだけでなく時間と費用がかかります。そのため、小規模な企業や組織は、このような評価を行うことを諦めてしまうのです。さらに、人間による評価だけに頼ることは、特に事実性などの複雑な判断においては、慎重に実施する必要があることに注意が必要です（Hosking et al., 2024; Xu et al., 2023; Wu & Aji, 2023）。訓練された専門家による判断はこれらの問題を軽減する可能性がありますが、本質的にスケーラブルではありません。

手動による人間評価の高コストに対処するために、多くの場合、自動化されたメトリックが使用されます。これらのメトリックは、理論的には完全に再現可能で、計算がはるかに簡単で安価であり、人間研究で直面するいくつかの問題を回避できるという顕著な利点を提供します（Wei & Jia, 2021; Freitag et al., 2021; Amidei et al., 2020）。BLEU（Papineni et al., 2002）やROUGE（Lin, 2004）などの自動化されたメトリックは、生成された応答と、生成された応答と金標準の応答との間の距離を測定することにより、主要な問題を直接解決することを目指しています。たとえば、2つのテキスト間のn-gramの重複をカウントします。BLEU（およびその派生形）などのヒューリスティックに基づくメトリックには欠陥があり（Callison-Burch et al., 2006）、再現性の課題があります（Marie et al., 2021）。しかし、有用な場合もあります。近年、特に人間の好み評価の代理として、大規模言語モデルをグレーダーとして利用する評価手法を通じて、モデルベースのメトリックが勢いを増しています（Kim et al., 2024; Wang et al., 2024; Liu et al., 2023b）。ただし、これらのメトリックには欠陥があり（Wang et al., 2023; Shen et al., 2023a; Zeng et al., 2024; Hu et al., 2024; Liu et al., 2023c; Chen et al., 2024）、BLEU、ROUGE、およびその派生形と同様の再現性の問題があります。

主要な問題は、応答空間を人為的に制限することによって回避することもできます。最も一般的な方法は、質問を複数の選択肢問題に再構築することです。1つの金標準の回答と、有限で静的な可能な回答の集合が与えられます（Hendrycks et al., 2020; Srivastava et al., 2022; Li’evin et al., 2022; Lin et al., 2022; Robinson et al., 2023; Holtzman et al., 2022）。あるいは、参照回答が既知の場合、モデルの回答が真実に一致するかどうかを判断するために、ヒューリスティックな文字列マッチングアプローチを実行できます（Dua et al., 2019; Joshi et al., 2017; Hendrycks et al., 2021）。

この課題は、ゲームのプレイ（Romstad et al., 2008; Silver et al., 2018; FAIR）、制約が強い科学的アプリケーション（Jumper et al., 2021; Ahdritz et al., 2022）、またはすべてのコンテキストで解が検証できない場合でも実用的な検証者があるドメイン（Biderman, 2020; Biderman & Raff, 2022; Lewkowycz et al., 2022）など、言語モデルや関連するテクノロジーの他のアプリケーションに必ずしも影響を与えるわけではありません。LLMの場合、この真実に基づく検証者が既知である最も顕著なケースは、コーディングと数学の問題です。ただし、単体テストなどの使用される検証者は、エッジケースでまだ失敗する可能性があります（Liu et al., 2023a）。

2.2 ベンチマークの設計と妥当性

一般的に、モデルのベンチマークにおける実際の数値スコアには関心がありません。むしろ、ベンチマークが何らかの現実世界の現象に対する有用な代理として機能することを望みます。評価の妥当性とは、これらの相関関係の程度です（Messick, 1994）。NLPベンチマークにおける妥当性の問題についての最近の概要については、Subramonian et al. (2023) を参照してください。また、LLM評価における構成妥当性についての詳細な議論については、Raji et al. (2021); Saphra et al. (2023); Davis (2023) を参照してください。

妥当性は、言語モデルの評価における継続的な問題ですが、まずは他の懸念を軽減することに焦点を当てます。lm-evalは、（構成）妥当性に関係なく、測定値が実行とモデル間で一貫していることを保証するように設計されているため、後で説明するように、lm-evalは設計されています。これは、lm-evalの目的が、評価のための研究インフラストラクチャを構築することであるためです。研究者としては、ある評価ベンチマークを他のベンチマークよりも好む場合もありますが、私たちの目標は、研究者が任意のモデルで任意の評価ベンチマークを実行できるようにすることです。

2.3 実装の困難と（非）再現性

ベンチマークが設計されたら、世界中の機械学習研究者が実装し、分野における進捗状況を促進するために使用できるようになる必要があります。これにより、誰もが同じ方法でベンチマーク上のモデルを評価し、結果を比較できるようにするために解決する必要がある、多くの新しい課題が発生します。この適応プロセスにより、矛盾が生じ、異なる実装間での結論の導出が困難になる可能性があります。研究者は、自分のワークフローとライブラリにベンチマークを適応させる必要があり、研究における実際の導入を目的としています。

2.3.1 「マイナーな」実装の詳細が重要

相互運用性と完全な再現性の重要性は、言語モデルが、実践者にとって明らかではない正確な詳細に非常に敏感であるという事実から生じています。プロンプト、フォーマット、またはその他のimplementation detailsにおけるわずかな違いでさえ、評価のパフォーマンスと妥当性に大きな影響を与える可能性があります（Weber et al., 2023; Sclar et al., 2023; Mizrahi et al., 2024; Alzahrani et al., 2024; Lu et al., 2022; Webson & Pavlick, 2022; Min et al., 2022）。元の評価コードにアクセスできず、評価手順をゼロから再実装する必要がある場合、結果に影響を与える可能性のある微妙な詳細をすべて考慮することはほとんど不可能です。その結果、これらの実装は、同じベンチマークで評価した場合でも、作品間で公正な比較を保証することが非常に困難な方法で大きく異なる可能性があります。論文にプロンプトが記載されていても、実際の評価コードにアクセスする代わりにはなりません。論文に記載されているプロンプトは、人間が読めるようにスタイルが設定されているため、多くの場合、正確なコード実装に正しく対応しているか、または対応付けが難しい場合があります。

2.3.2 「リンゴとリンゴの比較」についての合意の欠如

ベンチマークが作品間で一貫して実装されていると仮定しても、モデルと手法間で公正な比較を行う方法は、LMでは依然として難しい問題です。

たとえば、異なるインストラクションチューニングされたモデルは、特定のフォーマットを期待するようにトレーニングされている可能性があります（Taori et al., 2023; Sanh et al., 2022; Wei et al., 2022）。これらのモデルの意図されたプロンプトフォーマットを使用すると、評価タスクは本質的に異なるか、難易度が変化する可能性がありますが、これらのフォーマットを使用しないと、タスクの「標準的な」プロンプティングスタイルと一致しないフォーマットでトレーニングされたモデルに対してバイアスがかかってしまう可能性があります。同様に、特定のモデルに合わせて元のベンチマークの実装（プロンプティングと後処理を含む）が調整されている場合、異なる方法でトレーニングされた他のモデルは不利な状況に置かれ、どのテクニックが効果的であるかについての認識が人為的に歪められます。

同様に、制御された実験の設定方法に関するいくつかの質問は、まだ未解決です。パラメータ数、トレーニングFLOPs、推論コストでパフォーマンスと比較を正規化するのが理想的でしょうか？トレーニングデータは同一にしておくべきでしょうか？取得されたドキュメントや外部ツールなどの外部リソースを活用できるモデルをどのように比較すべきでしょうか？これらの質問はすべて状況依存ですが、結果に大きな影響を与える可能性があります。たとえば、Wang et al. (2022) は、アーキテクチャとトレーニング目標の比較を調べ、FLOPsで正規化することにより、パラメータが2倍のエンコーダー・デコーダーモデルを、デコーダーのみのモデルと比較しています。トレーニングFLOPsが等しいモデルの結果を比較することは、パラメータの割り当てに関係なく、一般的です（Hoffmann et al. (2022); Peng et al. (2023); Touvron et al. (2023) など）。しかし、メモリ制約の厳しい環境では、パラメータが等しいモデルを比較することがより合理的かもしれません。これは、異なるアプリケーションコンテキストによって異なる評価基準が求められるため、本質的に問題があるわけではありませんが、そのような注意事項に十分な注意を払わずに、ヘッドラインの主張が一般ケースを指すものとして解釈されることがよくあります。

2.3.3 以前の研究との比較は高価（そして時には不可能）

手法やモデル間の公正な比較を確立するという問題を別として、言語モデリング研究におけるもう1つの重要な課題は、関連する研究との徹底的な比較を阻む多くの障壁が存在することです。

多くの場合、ベンチマークの基準点として使用される、産業用ラボによって開発された多くのLMは、外部に公開されたことがありません（Chowdhery et al., 2023; Hoffmann et al., 2022）。そのため、技術レポートから検証されていない評価数値を取得する場合を除いて、比較することができません。API経由で提供されているモデルは、公開されたバージョンと一致していない、または配備のために別の方法で変更されている可能性があり、透明性がありません。さらに、これらのAPIモデルはすぐに廃止され、アクセスできなくなり、多くの研究が再現不可能になります¹。APIへのアクセス、特に大量の評価の場合、非常に高価です。

さらに、多くの企業は、ベースとなる言語モデルを公開しなくなりました。代わりに、パーソナライゼーション²、安全制御³、またはドメイン固有のツール⁴などの製品機能を含む、チャットインターフェースまたはAPIを介しての対話を強制しています。言語モデルと独自機能を統合した、このようなクローズドシステムを比較しようとすると、多くの新たな複雑さが発生します。

2.4 急速に変化する進捗状況と慣習

過去10年間のNLP研究の急速な変化を考えると、妥当なベンチマークの開発には時間がかかり、多くの広く使用されている言語モデル評価ベンチマークは、言語モデルのトレーニングの現在のパラダイムを反映していません。これには、次の2つの大きな影響があります。

ベンチマークが、本来の設計目的とは異なる目的、または妥当性が担保されていない目的で使用されています。たとえば、多くのベンチマークは、既知のトレーニングセットとラベルの閉じた空間でファインチューニングすることに基づいて構築されています（Wang et al., 2019b;a）。

これらの一般的なベンチマークの多くについては、元のベンチマーク作成者による、オート回帰LMで使用するために「改造された」明確な基準となる実装が存在しません。明確な基準が存在しないため、コミュニティによるこれらのベンチマークの評価手法は断片的であるか、文書化されていない場合があります（Clark et al., 2018; Paperno et al., 2016）。

この開発タイムラインの影響を説明するために、図1は、インコンテキスト学習やチャットインタラクションなどの変化が発生する前に設計された、著名なLMベンチマークを多く示しています。そのため、これらのフォーマットやアプローチを考慮して設計されていません。これは、予想外の方法で妥当性または難易度を影響を与える可能性があります。

図1: LMsを評価するために使用される著名なベンチマークのリリース日と、BERT（Devlin et al., 2018）、GPT-2（Radford et al., 2019）、GPT-3（Brown et al., 2020）、ChatGPTのリリース日を比較したタイムライン。これらは、コミュニティがLMを使用する（したがって評価する）方法の変化を表す近似的な代用品として使用されています。今日のオート回帰言語モデルを評価するための一般的な慣行は、リストされているタスクのほとんどの論文で説明されている方法とは異なります。ただし、MMLUとMATHだけは、論文で説明されている方法と一致しています。

3 言語モデルの評価のためのベストプラクティス

LM評価は困難であり、これまで説明した多くの課題がありますが、現在の慣行を大幅に改善するための対策はいくつかあります。これらの対策に関する一般的な推奨事項を提示し、それぞれの動機を簡単に説明します。

常に正確なプロンプトとコードを共有する

可能であれば、使用された完全なプロンプトを含む完全な評価コードと、使用された特定のコミットへのリンクなどのさらなる識別子を提供して、評価の実行を再現できるようにする必要があります。これらが不可能な場合でも、プロンプトを共有することは多くの場合行われませんが、再現性を大幅に向上させることができます。

他のモデルとの公正な比較のため、特別な理由がない限り、同じプロンプトセットを使用して評価を実行する必要があります。プロンプトは、特定のモデルのパフォーマンスに対して最適化するのではなく、他のモデルに対しては最適化しないでください。また、行ったプロンプトエンジニアリングの量は開示する必要があります。

他の実装からの結果のコピーを避ける

プロンプト、サンプルサイズ、メトリックの計算など、さまざまな実験の違いにより、論文間で結果を比較すると誤解を招く可能性があります（Marie et al., 2021）。

可能であれば、他の論文からの結果をコピーまたは報告しないでください（Marie, 2022）。ただし、これらの論文で実験を実行するために、まったく同じコードが使用されたことを確認できる場合はこの限りではありません。そのようなコピーが避けられない場合は、明確にそうであることを示し、慎重に扱う必要があります。

常にモデルの出力結果を提供する

評価コードと一緒にモデルの出力結果を提供すると、他の人がこれらの成果物に基づいてスコアを再計算することができます。これにより、異なる評価メトリックやスコアリングアプローチの影響を評価するための統計的有意性の検定に役立ちます。

大規模モデルまたはAPIの評価は非常に高価になる可能性があります。このような成果物を共有することで、膨大な計算リソースを持たない研究者でも、評価研究に参加することができます。

最後に、出力を共有することで、モデルがその後廃止された場合でも、APIモデルに関する結果はある程度再現することができます。

定性的な分析を実行する

大規模なテストを行う前に、少数の結果と出力結果を定性的にレビューする必要があります。特に複数のベンチマークセット、プロンプト、および異なるアーキテクチャのモデルを扱う場合は、生成コードにバグがあることはよくあることです。問題を早期に発見することで、時間と計算リソースを大幅に節約し、結果に対する信頼性を高めることができます。

定量的なスコアは、それほど多くの情報を提供しません。モデルがなぜそれほど良いスコアまたは悪いスコアを出しているかを理解するために、何らかの定性的な誤差分析を実行することが重要です。これにより、後処理によって簡単に修正できる表面的なエラー、またはより根本的なエラーが明らかになることがあります（Bawden & Yvon, 2023）。

不確実性を測定し、報告する

言語モデリングに関するほとんどの研究では、統計的有意性の検定が行われていません。これにより、結果に対する信頼性が大幅に低下する可能性があります（Marie et al., 2021）。

コストがかかりますが、複数のランダムシードで実行された結果を報告することで、結果の妥当性と有用性を大幅に向上させることができます。たとえば、モデルの実行結果を平均化したり（Sellam et al., 2022）、複数回の少ショット例選択の結果を平均化したりします。

モデルを再トレーニングしない場合でも、統計的分析により、モデルのトレーニング実行間で予想される変動を制限することができます（Jordan, 2023）。

4 言語モデル評価ハーネス

これらのベストプラクティスを踏まえ、lm-evalを構築しました。統一されたベンチマークライブラリに関する後の取り組み⁵（Liang et al., 2023; Srivastava et al., 2022; Barton, 2024）とは異なり、評価ハーネスは、正しいベンチマークや評価プロトコルを単に規定することを目指しておらず、ユーザーは希望するタスクとユースケースを選択できます。

lm-evalの役割は、オーケストレーションの問題を解決することです。以前は、徹底的なLM評価を実行するには、以前のタスクを注意深く再実装する必要がありました（これにより、微妙な方法論的な差異が発生する可能性があります）。または、数十の小さなライブラリを個別にインストール、デバッグ、および使用して実行する必要がありました。私たちの目標は、研究者やライブラリユーザーが、1つのコードベースをインストールするだけで、希望するタスクに対して自分の手法と選択したベースラインを制御された方法で簡単に実行できるようにすることです。同時に、ベストプラクティスをライブラリ自体の機能に組み込み、デフォルトで使いやすく、かつ機能的にユーザーがベストプラクティスに従うように誘導することを目指しています。

4.1 設計

lm-evalの主要なコンポーネントと設計哲学の概要を説明します。lm-evalの中核は、2種類のimplementationである評価タスクと、新しいLM implementationとの統合をサポートすることです。

タスク lm-evalは、共通のAPIを使用してTaskクラスとして実装された、評価タスクのモジュール式implementationに基づいて構築されています。これにより、タスクを共通のライブラリに収集したり、新しいタスクを簡単に拡張またはimplementationしたり、新しいタスクを簡単に再現可能に実践者や他のライブラリユーザーと共有したりすることができます。ユーザーは、YAMLベースの構成ファイルを使用するか、提供されたTaskクラスをサブクラス化して特定のメソッドのカスタムコードを提供することにより、タスクを実装できます。図2は、Taskクラス内にパッケージ化された評価ロジックの例を示しています。

図2: lm-evalにおけるTaskオブジェクトによって実行される操作。タスクは、YAMLファイルまたはPythonサブクラスによって構成され、1) データソース（Datasetsライブラリ（Lhoest et al., 2021）を使用）、2) プロンプトとフォーマットを定義するためのツール、3) これらのプロンプトをLMからのレンダリングされた入力と期待される出力タイプ（Requestsの形で）、および4) LMの出力結果を後処理して最終的なタスクメトリックを計算するためのルールを含みます。

一般的なタスクのimplementationをいくつか提供しており、コミュニティからの新しいタスクを受け付けています。ベンチマークデータセットを最初に導入した論文の方法論、可能な場合は同じプロンプトを使用して、対応させようとしています。プロンプトベースの評価が標準になる前に導入されたタスクの場合、プロンプトされたタスクとして評価データセットを最初に提案した論文から評価方法論を取得します。たとえば、多くのタスクは、Brown et al. (2020) によってインコンテキスト学習用に適応されています。

LM lm-evalの次のコア部分

はLM APIです。効果的なオーケストレーションは私たちの主要な目標であるため、任意のソフトウェアライブラリまたは（オート回帰）言語モデルアーキテクチャが、提供されたLMオブジェクト用のインターフェースを拡張できるようにしています。

使いやすさと、カスタムモデルのモデル定義と外部ライブラリの統合をコア評価ロジックから分離するため、LMは、文字列入力をある文字列または確率として出力するとして、ディスパッチされたRequestsで動作すると想定しています。そのため、LMクラス内でトークナイザーを抽象化し、ニューラル言語モデルとそのトークナイザーを、評価される単一のシステムとして扱います。

LMは、すべてのサポートされているタスクでライブラリ内で使用するために、いくつかのタイプのRequestsで構成される単純なインターフェースを実装します。

Requestsのタイプ 言語モデルに送信できる3つの主要なタイプのRequestsをサポートしており、これらはプロンプトされた形式でモデルの応答または潜在的な能力を観察するために実行できる測定値の異なるタイプで構成されます。これらは次のとおりです。

（条件付き）対数尤度（loglikelihood、複数の選択肢） - 与えられた出力文字列の確率を、いくつかの提供された入力に基づいて計算します。

当惑度（loglikelihood rolling） - 与えられたデータセットのトークンを生成する平均対数尤度または確率を測定します。

生成（generate until） - 与えられた停止条件に達するまで、いくつかの提供された入力に基づいてモデルからテキストを生成します。

図3: 私たちの評価フレームワークでサポートされている3つの主要なRequestsタイプの概要。これらには、（1）条件付き対数尤度、（2）当惑度、（3）生成ベースのRequestsが含まれます。

これらの3つの基本的な操作により、文献でLMを評価するために使用されてきた主要な方法を実装することができます（Gao et al. (2020), Brown et al. (2020) など）。これらの高レベルのアプローチは標準的ですが、これらすべてには、多くの場合論文で開示されない、多くの微妙な実装上の決定が含まれています。そのため、私たち自身および他の研究者のアプローチに関わる一般的な実装の詳細の完全な形式的記述を、付録Aに完全を期すために含めています。これは、文献への有用な貢献になることを期待しています。

4.2 課題への対応とベストプラクティスの組み込み

ここでは、lm-evalがセクション2で述べた問題に対処し、セクション3で推奨されたベストプラクティスを組み込み、より堅牢な評価エコシステムを促進する方法について詳しく説明します。

再現性 lm-evalは、いくつかの方法で再現可能な評価を奨励および有効にします。まず、多くの一般的なタスクの標準化されたimplementationを提供することで、実践者はこれらのタスクについて報告し、ライブラリの他のユーザーと同じプロンプトとimplementationで評価していることを確認できます。

タスクの結果とともに、versionフィールドを報告します。このフィールドは、タスクをスコアリングに影響を与える方法で変更する必要があるたびに増分されます。したがって、タスクimplementationにバグがある場合、または別の理由で更新する必要がある場合でも、使用されたタスクのバージョンを参照することで、将来の研究で報告された結果を再現することができます。

これは、以前の研究との比較にかかるコストに対する万能薬ではなく、ベースラインを自分で再実行することが推奨されますが、以前の研究で私たちのライブラリを使用した場合、以前の研究の結果は、ライブラリのそのバージョンを使用して自分で再実行した場合に得られた結果と一致することを確信できます（Beeching et al., 2023）。

定性的な分析 lm-evalは、評価スコアの定性的な分析の実行をサポートします。推奨されるベストプラクティスに従って、次のような機能を実装することで、評価ワークフローにおいて定性的なチェックを重要な部分として行うことができます。

特定の評価実行で使用するサンプル数を人為的に制限することで、コードをテストし、出力をフル評価実行の前に小規模なバッチでレビューできます。

サンプルトレーニングのログをサポートすることで、スコアの後処理による再現や、モデルの誤りまたは評価implementationの誤差分析を可能にします。

統計的検定 lm-evalは、ほとんどのサポートされているメトリック⁶の標準誤差（SE）を報告します。これは、ブートストラップ法で計算するか、サンプル標準偏差をサンプルサイズのルートで割ることで計算されます。

これらのSE計算をすべての評価実行で目立つように報告することで、実践者は、結果に信頼区間などの単純な統計的測定値を簡単に追加できるようになります。私たちは、LM評価においてより厳格で広範な統計的検定が必要であると考えていますが、この機能により、コミュニティは統計的有意性の懸念について報告し、認識することを促し、そのような測定値を報告する難しさを軽減することを期待しています。

ここで説明した標準誤差は、評価データが同じ分布から再収集された場合に観察されたスコアの分散の推定値であることに注意してください（Recht et al., 2019; Zhang et al., 2024）。時間的ドリフト（Longpre et al., 2023）、異なるシードでモデルを再トレーニング（現在実験中のパラダイム）、またはプロンプト間の分散（Sanh et al., 2022; Muennighoff et al., 2022）など、他の形式の分散は、別の方法で計算する必要があります。

5 ケーススタディ

最後に、評価の厳密性と理解を向上させるためのlm-evalの利便性を、その成功事例を示すケーススタディを通じて説明します。追加のケーススタディは、付録Bに記載されています。

5.1 BigScienceワークショップでのマルチプロンプト評価

スコアリング基準が同一であっても、評価タスクの特定のプロンプトは、結果に大きな影響を与える可能性があります。BigScienceワークショップとの協力により、PromptSource（Bach et al., 2022）ライブラリがlm-evalのフォークに追加されました。これにより、複数のプロンプトテンプレート⁷を対象として、初めて簡単に評価を行うことができるようになりました。BigScienceワークショップから発表された論文のほとんどは、この機能を使用して、異なるプロンプティングセットアップ全体でスコア分布を報告しました（Sanh et al., 2022; Muennighoff et al., 2022; Yong et al., 2023; Workshop et al., 2023）。PromptSourceは、BigScienceフォークで導入された他の革新とともに、現在lm-evalでネイティブにサポートされています。また、Jinjaテンプレート言語を構成ファイルで直接使用できるように機能を拡張しました。これにより、PromptSourceライブラリを使用するかどうか、関係なく、手動で、そしてアルゴリズム的にカスタム評価テンプレートを簡単に定義できます。

BigScienceによって採用された、プロンプト全体で分布を報告するアプローチは広く採用されていませんが、プロンプトは評価セットアップの一部として考慮する必要があるという考えは広く受け入れられています。今後の研究では、特に、現実的なプロンプトの収集（Shen et al., 2023b; Xie et al., 2023; Hofmann et al., 2024）、または特定の一般的なセットアップによる結果が、より現実的なユースケースにどの程度一般化されるかを測定すること（Lyu et al., 2024）、または他の方法でプロンプティングをヒューマンコンピューターインタラクションの問題として調査することに焦点を当てることが期待されています。

図4: lm-evalを使用して、プロンプトがモデルのパフォーマンスに与える影響を調査した例。これは、Muennighoff et al. (2022) から引用されたものです。点は、ヒストグラムで要約されているように、異なるプロンプトを表しています。同様の図は、Workshop et al. (2023); Sanh et al. (2022); などに記載されています。

5.2 異なる評価セットアップ間のスコア比較の困難さ

セクション2.3で述べたように、評価タスクのスコアは、評価implementationとセットアップの詳細によって大きく影響を受ける可能性があります。ここでは、このような評価方法論の差異に対する感度を調査し、lm-evalを使用して、そのような差異を回避することで、モデル間でのスコア比較に対する信頼性を向上させることができる例を示します。ここでは、2つの一般的な言語モデリングベンチマークである、ARC質問応答ベンチマーク（Clark et al., 2018）とMMLU（Hendrycks et al., 2021）に焦点を当てます。

ARC MMLU Cloze MMLUスタイル MMLUスタイル MMLUスタイル ハイブリッド

GPT-NeoX-20B 38.0 ± 2.78% 26.6 ± 2.53% 24.5 ± 0.71% 27.6 ± 0.74% Llama-2-7B 43.5 ± 2.84% 42.8 ± 2.83% 41.3 ± 0.80% 39.8 ± 0.79% Falcon-7B 40.2 ± 2.81% 25.9 ± 2.51% 25.4 ± 0.72% 29.1 ± 0.75% Mistral-7B 50.1 ± 2.86% 72.4 ± 2.56% 58.6 ± 0.77% 48.3 ± 0.80%

Mixtral-8x7B 56.7 ± 2.84% 81.3 ± 2.23% 67.1 ± 0.72% 59.7 ± 0.77%

表1: いくつかの事前学習済みのLM（Black et al., 2022; Touvron et al., 2023; Penedo et al., 2023; Jiang et al., 2023; 2024）について、ARC（Challengeサブセット）とMMLUにおける0ショットモデルのパフォーマンスを、lm-evalを使用して評価した2つの一般的なプロンプトスタイル間で比較したものです。正規化されていない正解率と、平均のSEによる95%信頼区間を報告しています。

ARCは、最初にBrown et al. (2020) によってインコンテキスト学習の設定に適応されました。彼らは、このデータセットを「Cloze」タスクとして実装しています。モデルには、Question: {question}\nAnswer: というプロンプトが与えられ、各潜在的な完了文字列の尤度が比較されます。対照的に、MMLU（Hendrycks et al., 2020）は、モデルに質問テキストと、各回答文字列の前に回答文字A、B、C、またはDを付加した4つの可能な回答を提供し、正しい回答に対応する文字を生成したかどうかに基づいてモデルを評価します。さらに、Hendrycks et al. (2020) は、主題ごとのスコアに対するマクロ平均ではなく、すべてのサンプルに対するマイクロ平均を使用してスコアを集計します。しかし、すべての論文が、これらのタスクを元のフォーマットと同じように評価しているわけではありません。

しかし、モデルがこれらのアプローチを採用していない場合、または正確な設定を開示していない場合、報告されたモデルパフォーマンスを確実に比較することは不可能です。表5.2で、ARCのChallengeサブセットを、Brown et al. (2020) のプロンプト（「Cloze」）と、MMLUスタイルの回答文字列を明示的に含む複数の選択肢オプション（「MMLUスタイル」）⁸で評価した結果を比較しています。さらに、MMLUのスコアを、元のMMLUプロンプティングスタイル（「MMLUスタイル」）と、MMLUスタイルのプロンプトを使用しますが、回答文字ではなく、回答文字列を継続文字列のセットとして使用する「ハイブリッド」と呼ばれるアプローチ間で比較しています。付録B.2で詳しく説明しますが、これはlm-evalのARCとMMLUの構成ファイルの2行を変更することで実現できます。

これらのプロンプティングスタイルを比較すると、モデルのパフォーマンスの違いは大きく異なり、どちらのプロンプトがより良い結果をもたらすかについても異なります。特定のモデル作成者が1つのプロンプティングとスコアリングスタイルを選択し、他のモデル作成者が別のスタイルを選択した場合、それぞれのモデル作成者は、それぞれの技術レポートから引用した数値を使用して、自分のモデルを他のベースラインと比較すると、その比較は意味をなさなくなり、どのモデルが「本当に」パフォーマンスが高いのかを示す情報が得られません。さらに、信頼区間を使用するなどのより良い統計的報告は、これらの問題を解決しません。これは、特定の測定値の信頼性を示しますが（たとえば、MMLUは、より多くのサンプルを使用しているため、信頼区間が小さい）、モデルパフォーマンスが異なる測定設定でどの程度変化するかはわかりません。また、比較を行うべきではないという指標も示すことができません。

これは、他の論文で報告された評価スコアの数値をコピーせず、独自の評価セットアップに関する詳細を共有することの重要性を示しています。そのため、lm-evalを使用することで、新しい評価結果の厳密性と信頼性を向上させ、評価セットアップのより良い伝達を促進することを期待しています。

5.3 ベンチマーク作成者とLM評価研究の強化

セクション4で説明したように、構成可能な評価オーケストレーションライブラリを提供することには、他にも多くの利点があり、コミュニティはlm-evalをこれらの目的のために効果的に活用していることを確認しています。

構成可能なタスク設計により、LM評価における複雑さや難易度の実験が容易になりました。Alzahrani et al. (2024) とLyu et al. (2024) は、lm-evalを使用して、プロンプトやその他の妨害要因がモデルの堅牢性とパフォーマンスに与える影響を探求しています。また、対数尤度ベースの評価と生成評価のトレードオフなど、評価方法論の役割も調査しています。付録Aでも詳しく説明しています。

lm-evalは、新しいベンチマークの設計を容易にするためにコミュニティによって採用されています。拡張可能なタスク構成と対応するコードベースは、コミュニティによってlm-evalで新しいベンチマークデータセットの評価のプロトタイプを作成するために使用されています。コミュニティメンバーが新しい評価コードを設計および貢献するための場所を提供することで、さまざまな論文から既存の評価コードを突き止め、使用するという難しい問題を完全に回避することができます。これらの新しいタスクのための参照implementationは、最初からlm-evalに直接存在します。セクション4.1で説明したように、モジュール式構成ファイルなどの摩擦の少ない開発モードを提供したり、タスクを「MMLUのスタイルで」実装した例を提供したりすることで、タスク開発と貢献への障壁を減らすことを目指しています。

lm-evalは、最近、lm-evalを評価とベンチマークのプロトタイプ化と設計に使用したさまざまなデータセットの貢献を受け付けています（Faysse et al., 2024; Son et al., 2024a;b; Kweon et al., 2024; Li et al., 2024）。ベンチマークの作成者が自分の新しい評価タスクをlm-evalに直接貢献することで、評価の普及（Hendrycks & Woodside, 2024）とimplementationを完全に制御することもできます。これにより、言語モデリングコミュニティが、認識または採用されない可能性のある新しいベンチマークの貢献を発見し、認識することをはるかに容易にすることができます（Dehghani et al., 2021）。これがオーケストレーションの力です。目標は、新しい評価ベンチマークをコミュニティに提供し、評価データセットが与えられた場合にベンチマークを作成するためのツールを評価開発者に提供し、セクション2で説明した潜在的な障害を克服することです。具体例として、lm-evalのタスクは、一般的なOpen LLM Leaderboard（Beeching et al., 2023）だけでなく、任意の新しいリーダーボードの構築にも使用されています。これらは、英語以外の言語など、より具体的なユースケースにおけるモデル間のカスタム比較を行うために使用されてきました。

したがって、私たちが採用しているオーケストレーションという観点は、ダウンストリームユーザーと開発者が、自分の目標とアプリケーションに最適なアプローチを作成することを可能にします。これにより、数少ない選択されたメトリックを固定するのではなく、より多くの評価開発とより相互運用可能なエコシステムを促進することができます。

6 まとめ

私たちは、LM評価における一般的な課題と、これらの落とし穴の最悪のものを軽減するための推奨事項を提示しました。lm-evalは、一般的な評価タスクとモデルimplementation全体で、より簡単で再現可能なベンチマークを可能にするために構築された、評価オーケストレーションライブラリです。

私たちは、lm-evalがコミュニティによって引き続き使用され、LM評価の厳密性と集団的な理解を向上させることを期待しています。