※本記事は、スタンフォード大学CS224N「NLPと深層学習」2024年春学期の第11講義「ベンチマーク」の内容を基に作成されています。講義の詳細情報はhttps://www.youtube.com/watch?v=TO0CqzqiArM でご覧いただけます。本記事では、講義の内容を要約しております。なお、本記事の内容は原講義の内容を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの講義映像をご視聴いただくことをお勧めいたします。
講義は、スタンフォード大学博士課程学生のヤン・デュボワ氏によって行われました。デュボワ氏は機械学習を専門とするスタンフォード大学のPh.D.学生で、クリストファー・マニング教授（スタンフォード大学人工知能研究所（SAIL）所長、Thomas M. Siebel機械学習教授、言語学・コンピュータサイエンス教授）の下で研究を行っています。
スタンフォード大学のオンラインAIプログラムについての詳細は https://stanford.io/ai で、この講義の受講登録についての詳細は https://online.stanford.edu/courses/c... で、講義スケジュールとシラバスは https://web.stanford.edu/class/archiv... でご覧いただけます。
1. イントロダクション
1.1. パフォーマンス測定の理由
ベンチマーキングと評価は、正直なところ、アカデミアでは十分に注目されていない分野だと思います。しかし、何かを実際に製品化したいとき、つまり現実世界での機械学習に本当に関心があるなら、評価は非常に重要です。
私の考える機械学習モデル開発のメンタルモデルでは、まず最初にモデルをトレーニングします。この段階でパフォーマンス測定が非常に重要です。なぜなら、最適化すべき損失関数を知る必要があるからです。次のステップは開発段階です。これは通常、ハイパーパラメータチューニングや、例えばモデルの学習中に過学習が起きていることに気づいたら早期停止を行うなどの作業です。開発はいわば第二段階で、ここでもパフォーマンス測定が必要です。なぜなら、ハイパーパラメータチューニングをどうするか、どのようにハイパーパラメータを変更するかを知る必要があるからです。
第三のステップは本質的にモデル選択です。私が本当に関心を持っているタスクがあるとき、そのタスクにどのモデルが最も適しているのか。それは自分が訓練したモデルかもしれませんし、別のグループが訓練したモデルかもしれません。そして最後に、少なくとも現実世界では、モデルをデプロイすることを決定します。この段階でもパフォーマンス測定は非常に重要です。なぜなら、モデルが実運用に十分な品質かどうかを知る必要があるからです。
私たちが生きている並行宇宙では、さらに論文発表というステップがあります。基本的に標準的なベンチマークでモデルを評価する必要があります。その理由は、本質的に異なるグループにモデルの品質を伝えるためです。
このパイプラインの各ステップでパフォーマンス測定が必要ですが、重要なのは、異なるステップで異なる方法でパフォーマンスを測定する必要があるということです。つまり、パフォーマンス測定には単一の理想的な方法は存在しません。例えば、左側のモデルトレーニング段階では、非常に高速で安価、そして微分可能なパフォーマンス測定方法が必要です。これはニューラルネットワークでは通常、損失関数を通じて逆伝播するからです。さらに、モデルが本当に最適化したいことではなく、ショートカットを使って損失を最適化することを防ぐ方法が必要です。
右側に移動すると、基本的にはパフォーマンスの測定頻度が少なくなるので、より費用がかかっても問題ありません。しかし、評価指標の品質がより高い必要があります。なぜなら、モデルを実運用に投入した場合のリスクがより高いからです。開発段階では、高速で安価、そしてショートカットを避ける測定方法が必要です。ハイパーパラメータチューニング時も本質的に特定の目標を最適化しているからです。モデル選択では、多少速度や費用の面での制約が緩和されますが、それでも何度も実行する必要があります。最も重要なのは、モデルをデプロイする際には、評価方法が信頼できるものである必要があるということです。なぜなら、一度実運用に投入すると、その期間に何が起きたかを後から変更することはできないからです。
また、タスク固有の評価が必要です。特定のタスクに関心があるとき、デプロイ時にはそのタスクだけを評価すれば良く、他のタスクは気にする必要はありません。最後に、指標が絶対的なものである必要があります。これを強調する理由は、他の3つのステップでは、本質的に比較だけが重要だからです。例えば、精度が95%未満の場合はモデルを実運用に投入しないという閾値を設けたい場合のように、絶対値が重要になります。
1.2. 学術的ベンチマークの役割
学術界でのベンチマーキングは、実世界での評価とは少し異なります。学術的なベンチマークにおいては、再現可能で標準化されたものであることが重要です。その理由は、今後5年、6年、あるいは10年間、誰もがそのベンチマークで評価されることになり、3年後の論文があなたの論文と比較可能であることを望むからです。
学術的評価が再現可能であることは非常に重要ですが、正直なところ実世界ではそれほど気にする必要はありません。また、扱いやすいものであることも重要です。研究者は通常、必要以上の作業をしたくないものですし、通常はリソースもそれほどないので、高速で安価であることが必要です。
学術的ベンチマークにおいて特に強調したいことは、使用するメトリクスが完璧である必要はないということです。なぜなら、実際に重要なのは、10年間にわたってメトリクスが示す方向性、つまり分野がどのように進化しているかということだからです。メタレベルでは、学術界で粗いメトリクスを使うことは問題ありません。
また、難易度と単純さのバランスをとる必要もあります。これが意味するのは、ベンチマークが複雑すぎると、基本的にすべての手法がランダムなパフォーマンスになってしまい、誰もそのベンチマークを使わなくなります。逆に、ベンチマークが単純すぎると、ベースラインが非常に良い結果を出すため、誰もそのベースラインを上回ることができず、やはり誰もそのベンチマークを使わなくなります。これは学術界特有の問題です。実世界では、モデルの良し悪しに基づいて実行するタスクを変更することはできません。
ベンチマークが学術界でどのように分野を推進するかの例として、MLUベンチマークがあります。これは現在最も標準的なベンチマークで、過去4年ほどの間に、25%の精度（これは本質的にランダムです、なぜなら多肢選択問題で選択肢が4つあるため）から約90%の精度にまで向上しています。ベンチマーキングは本当に分野の進歩を推進するものです。学術界では、小さなポイントの違いが重要なのではなく、10年間にわたってモデルがどのようにパフォーマンスを発揮するかを考え、右上のモデルが左下のモデルよりも優れていることを確認することが重要なのです。たとえベンチマークが完璧でなくても、MLUはその意味で良いベンチマークだと思います。
2. パフォーマンス測定の目的
2.1. トレーニング段階での測定
機械学習モデルの開発における最初のステップはモデルのトレーニングです。この段階でのパフォーマンス測定は非常に重要です。なぜなら、どのように最適化を行うべきかを決めるための損失関数が必要だからです。
トレーニング段階での評価方法には、いくつかの重要な特性があります。まず、評価は「超高速」かつ「非常に安価」でなければなりません。これは、トレーニング中に何百万、何十億回も評価を行う必要があるからです。また、ニューラルネットワークでは損失関数を通じて勾配を逆伝播させるため、評価指標は「微分可能」である必要があります。
さらに重要なのは、モデルが本当に最適化したいことではなく、ショートカットを使って損失を最適化することを防ぐ仕組みが必要だということです。モデルは与えられた目標関数を最適化しようとしますが、時にその過程で意図していない方法（ショートカット）を見つけることがあります。例えば、特定のパターンを認識するのではなく、画像の隅に常に現れる小さなマークなど、偶然の相関に頼ってしまうことがあります。
トレーニング段階では、評価は高速、安価で微分可能であることが最も重要です。そして、モデルが本当に学習してほしいことを学習しているかを確認するための工夫が必要なのです。
2.2. 開発段階での測定
開発段階は、機械学習モデル構築の第二のステップです。この段階では通常、ハイパーパラメータチューニングを行います。または、例えばトレーニング中にモデルのパフォーマンスがあまり良くないことに気づいたり、過学習が起きていると判断した場合、早期停止を行うかもしれません。あるいは、モデルのトレーニング中に学習率を変更することを決めるかもしれません。
この開発段階でもパフォーマンス測定が必要です。なぜなら、実際にハイパーパラメータチューニングをどのように行うか、ハイパーパラメータをどう変更するかを知る必要があるからです。
開発段階での評価方法も、トレーニング段階と同様にいくつかの重要な特性を持っています。評価は「高速」で「安価」である必要があります。そして、ショートカットを避けることも重要です。ハイパーパラメータチューニングの際も、本質的には特定の目標を最適化しているからです。モデルが意図しない方法で目標を達成してしまうリスクがあるため、評価指標は真の性能を反映したものでなければなりません。
2.3. モデル選択段階での測定
モデル選択は実質的に開発パイプラインの第三のステップです。特定のタスクに真剣に取り組みたい場合、どのモデルがそのタスクに最も適しているかを決定する必要があります。それは自分自身が訓練したモデルかもしれませんし、別のグループが訓練したモデルかもしれません。
この段階でのパフォーマンス測定は、開発段階と比べてやや異なる特性を持っています。モデル選択では、評価方法は「少し遅くても」「少し費用がかかっても」問題ありません。なぜなら、開発段階ほど頻繁に評価を行う必要がないからです。しかし、それでも多くの場合に評価を実施する必要があるため、完全に時間や費用の制約から解放されるわけではありません。
モデル選択段階での評価においても、特定のタスクに対する性能を正確に測定できることが重要です。複数のモデル候補から最適なものを選ぶためには、評価指標がモデルの真の能力を反映している必要があります。
2.4. デプロイメント段階での測定
現実世界では、最終的にモデルをデプロイ（実運用に投入）することを決定します。この段階でのパフォーマンス測定は非常に重要です。なぜなら、モデルが実際の環境で使用するのに十分な品質かどうかを知る必要があるからです。
デプロイメント段階では、評価方法に対する要求が最も厳しくなります。まず、評価方法は「信頼できる」ものでなければなりません。一度モデルを実運用に投入すると、その期間に何が起きたかを後から変更することはできないからです。
また、評価は「非常にタスク固有」である必要があります。特定のタスクに関心がある場合、デプロイ時にはそのタスクのみを評価すれば良く、他のタスクのパフォーマンスは二次的な関心事になります。
最後に、評価指標は「絶対的」である必要があります。これを強調する理由は、前の三つのステップでは本質的に「比較」だけが重要だったからです。例えば「精度が95%未満のモデルは実運用に投入しない」というような閾値を設けたい場合には、相対的な比較ではなく絶対的な数値が重要になります。
デプロイメント段階では、モデルの実世界での性能を正確に予測できる、信頼性の高い評価方法を使用することが最も重要なのです。
2.5. 学術的な公開のための測定
学術論文の発表は、実世界での評価とは正直なところかなり異なります。学術的なベンチマーキングと評価を行う際には、「再現可能」で「標準化された」ものであることが重要です。その理由は、今後5年、6年、あるいは10年間、誰もがそのベンチマークで評価されることになり、3年後の論文があなたの論文と比較可能であることを望むからです。
学術的評価が再現可能であることは非常に重要ですが、実世界ではそれほど気にする必要はありません。また、「扱いやすい」ものであることも重要です。研究者は通常、必要以上の作業をしたくないものですし、リソースもそれほど多くないため、評価は「高速」で「安価」であることが求められます。
学術的ベンチマークについて特に強調したいのは、使用するメトリクスが完璧である必要はないということです。本当に重要なのは、10年間にわたってメトリクスが示す方向性、つまり分野がどのように進化しているかということです。メタレベルでは、学術界では粗いメトリクスを使うことは問題ありません。
また、「難易度と単純さのバランス」をとる必要もあります。ベンチマークが複雑すぎると、基本的にすべての手法がランダムなパフォーマンスになってしまい、誰もそのベンチマークを使わなくなります。逆に、ベンチマークが単純すぎると、ベースラインが非常に良い結果を出すため、誰もそのベースラインを上回ることができず、やはり誰もそのベンチマークを使わなくなります。
これは学術界特有の問題です。実世界では、モデルの良し悪しに基づいて実行するタスクを変更することはできません。つまり、学術的な公開のための測定には、再現性、標準化、扱いやすさ、そして適切な難易度という特有の要件があるのです。
3. クローズドエンド評価（分類タスク）
3.1. 感情分析、含意、品詞タグ付け等の例
NLPにおいては、古典的には主に二つのタイプのタスクがあります。まずはクローズドエンドタスクについて説明します。クローズドエンドタスクとは、潜在的な回答の数が限られているタスクです。一般的には10個未満の選択肢があり、多くの場合、正解は1つか、あるいは少数の可能性に限られます。
これは本質的に標準的な機械学習の分類問題です。精度、適合率、再現率などを見るだけで良いので、NLP特有の難しさはありません。複雑ではないということではなく、NLPに固有の問題ではないということです。
クローズドエンドタスクの例としては、まず感情分析があります。これは通常、テキストの感情がポジティブかネガティブかを判断する二値分類タスクです。感情分析の代表的なベンチマークとしては、IMDBとスタンフォード大学のSSTがあります。
もう一つの例は含意（エンテイルメント）タスクです。スタンフォード大学のSNLIが代表的なベンチマークです。ここでは、あるテキスト「複数の男性がサッカーをしている」があり、それに対する仮説「何人かの男性がスポーツをしている」が与えられます。含意タスクでは、この仮説がテキストから含意されるかどうかを判断する必要があります。この例では、仮説はテキストから含意されています。
他のタスクとしては、品詞タグ付け（典型的なベンチマークはPenn Treebank）や固有表現認識（CoNLLベンチマーク）があります。
他にもいくつかのタスクがあります。すべてを知る必要はありませんが、簡単な概要を示します。共参照解決は実際にはかなり難しいNLPタスクで、代名詞がどの名詞を指しているかを判断します。例えば「マークはピートに彼自身について多くの嘘を話した。ピートはそれを彼の本に含めた。彼はもっと正直であるべきだった」という文があった場合、最後の「彼」がピートを指しているかどうかを判断する必要があります。
質問応答も重要なタスクで、長いテキストがあり、それに基づいて質問に答える必要があります。
これらがクローズドエンドタスクの例であり、評価方法は標準的な機械学習と同じです。精度、適合率、再現率、F1スコアなどを使用します。これらの指標については、皆さんすでに知っていると思いますが、もし知らなければ、Chris Peachの講義（CS224u）をチェックすることをお勧めします。彼のオンライン講義は様々な評価指標について本当に優れています。
3.2. SuperGLUEなどの多タスクベンチマーク
これらのベンチマークを評価する一般的な方法は、多くの場合、複数のベンチマークを同時に見ることです。最も一般的なスーパーまたはマルチタスクベンチマークは、SuperGLUEと呼ばれています。ここでは列にSuperGLUEのすべての異なるタスクがあります。全部で8つか9つのタスクがあり、各ベンチマークでの平均パフォーマンスを見て、それに基づくランキングを作成します。これは一般的な言語能力を測定する試みの一つです。
これは2年ほど前までは一般的な手法でした。講義の終わりに、現在何が行われているかについてお話ししますが、SuperGLUEは少なくとも知っておくべきものです。
SuperGLUEに含まれるタスクの例としては、BoolQがあります。これは単純に、テキストと質問があり、その答えが「はい」か「いいえ」かを判断するタスクです。評価は非常に簡単で、精度や適合率・再現率を見るだけです。
すでに説明した含意タスクもSuperGLUEに含まれています。その他には、共参照解決や単語の意味を判断するタスクもあります。例えば、同じ単語を含む2つの文があり、それらが実際に同じ意味を持つかどうかを判断します。例えば「bank」という単語は、水辺の「岸」という意味と金融機関の「銀行」という意味を持ちます。2つの文でこの単語が同じ概念を指しているかどうかを判断する必要があります。また、いくつかの質問応答タスクもSuperGLUEに含まれています。
このように、SuperGLUEは複数の異なるクローズドエンドタスクを組み合わせた総合的なベンチマークであり、モデルの一般的な言語能力を評価するために使用されます。
3.3. 評価指標（精度、適合率、再現率、F1スコア）
何度も言いましたが、これらのクローズドエンドタスクは基本的に標準的な機械学習であるにもかかわらず、評価が単純だということではありません。クローズドエンドタスクを使用する際には、何を見るべきか注意深く考える必要があります。精度、適合率、再現率、F1スコア、ROC曲線、AUC曲線などを見るかどうかを選択する必要があります。もしこれらの名称を知らなければ、scikit-learnのドキュメントか、先ほど紹介したChris Peachの講義を確認すべきです。どちらも本当に優れています。
選ぶ指標によって、非常に異なるタイプのアルゴリズムを選択することになります。一般的な例としては、スパムメールの分類を考えてみましょう。あるメールがスパムかどうかを分類したいとします。ほとんどのメールはスパムではありません。幸いなことに、少なくとも私はそう願っています。例えば、メールの90%が実際にはスパムではなく、わずか10%がスパムだとしましょう。
精度だけを見ると、単に最も可能性の高いラベル（この場合は「スパムではない」）を予測するだけのランダム分類器でも、90%の精度を得ることができます。データセットについて何も知らなければ、90%の精度は良いように見えますが、実際にはこれは何も分類していないことを意味します。そのため、適合率、再現率、F1スコアを見る必要があります。
これはNLP特有の問題ではありませんが、簡単な問題というわけではありません。
もう一つの問題は、複数の異なるタスクがある場合、これらの指標をどのように集約するかです。先ほど、単に全ての指標の平均を取ると言いましたが、正直なところこれは本当にひどい方法です。しかし、それが実際に行われていることです。これらの列は実際には非常に異なるものを意味しています。一部は精度、一部はF1スコア、また別の一部は相関係数です。そして単純にすべての値の平均を取ります。
数年前のあるベンチマークでは、列の一つは値が低いほどパフォーマンスが良いというものでした。それでも単純に平均を取っていましたが、誰かがそこにマイナスをつけるべきだと気づくまでそのままでした。
ですから、注意が必要です。アカデミアや他の場所で人々が行っていることが常に正しいと思わないでください。少し考える必要があります。
さらに考慮すべき質問があります。これらのラベルはどこから来るのでしょうか？通常は実際の答えがあると言いましたが、それらのラベルをどのように取得するかは明確ではありません。次のスライドでいくつかの問題について説明します。また、それに関連して、疑似相関がある可能性があります。それについて今から説明します。
3.4. 疑似相関の問題と事例
先ほどSNLI（含意タスク）について話しました。ここでは、「経済はまだ良くなる可能性がある」という前提と、「経済はこれまで以上に良くなったことはない」という仮説があります。そして、この仮説が前提から含意されるかどうかを判断する必要があります。
2019年の論文では、異なるモデルが実際には非常に良い性能を示していましたが、仮説だけに基づいて分類しても同様に良い性能を示すことが分かりました。つまり、前提を見なくても、タスクの重要な部分であるはずの前提を考慮しなくても、良い性能を出せるのです。
その理由は、人間が実際に仮説を書く際に「前提から含意されない仮説を書いてください」と依頼されると、通常、否定を加えることでそれを行うからです。そのため、仮説だけを見て、そこに否定があれば、前提から含意されない可能性が非常に高いのです。
このように、標準的な機械学習であっても、どの指標を使うか、ラベルがどこから来るのかについて本当に注意する必要があります。人々が行っていることをそのまま使って、「もし問題があれば、誰かが気づいているはずだ」と考えないでください。
これが疑似相関の問題です。モデルが実際のタスクではなく、データセットに存在する偶然のパターンを学習してしまう現象であり、実際のNLPタスクの評価において注意すべき重要な問題点です。
4. オープンエンド評価（生成タスク）
4.1. 要約、翻訳、指示に従うタスク
オープンエンド評価、つまりオープンエンドタスクは本質的にクローズドエンドタスクの反対です。つまり、正解となる可能な回答が多数あり、それらをすべて列挙することはできません。そのため、標準的な機械学習の評価指標を使用することができません。
さらに、考慮すべき点として、可能な回答をすべて列挙できないだけでなく、通常は正解にも異なるレベルがあります。例えば、ChatGPTに本を書くように頼んだ場合、それは適切な本かもしれませんが、もっと良い本を書くこともできたかもしれません。あるいは、別のモデルがより良い本を書く可能性もあります。つまり、単に正解か不正解かではなく、連続的な評価尺度があるのです。
オープンエンドタスクの標準的な例として、最も一般的なものは要約です。要約タスクでは、長いテキストがあり、それをX文字以内で要約するよう求められます。標準的なベンチマークはCNNとDaily Mailのベンチマークです。
このデータセットを収集した方法は、多くのCNN記事を取り、CNN記事の上部にある箇条書きのポイント（記事の最も重要な点を示すもの）をゴールド要約として使用しました。これが要約の古典的なベンチマークです。
翻訳タスクでは、2つの異なる言語の文があり、一方の言語から他方の言語に翻訳する必要があります。これらが古典的なオープンエンドタスクです。
現在、人々が行っている方法は、指示に従うタスク（instruction following）が最も標準的なタスクだと思います。指示に従うタスクは、ある意味ですべてのタスクの親玉と言えます。なぜなら、以前のどのタスクもチャットボット、つまりChatGPTに尋ねる質問として見ることができるからです。分類、要約などどんなタスクでも、ChatGPTに頼むことができます。
本質的に、チャットボットを最も一般的なタイプのタスクとして見ることができ、どんなタスクでも実行するように依頼でき、そのタスクの回答を提供してくれるはずです。これが「指示に従う」と呼ばれるものです。
想像できるように、この領域での評価は非常に難しいです。ChatGPTのようなものをどのように評価するかについては、後ほど説明します。
4.2. コンテンツ重複メトリクス（BLEU、ROUGE）
テキスト生成やオープンエンドタスクの評価方法としては、まず古典的な方法として「コンテンツ重複メトリクス」があります。これは単純に生成されたシーケンスと人間が書いたゴールド回答（参照回答）の間の単語を比較するものです。
コンテンツ重複メトリクスの仕組みを例で説明します。生成されたシーケンスが「女性はハードウェアストアに行った」で、ゴールド参照が「彼らは食料品店に歩いて行った」だとします。このタスクが何であるかも分かりませんが、ここで行うのは、これら2つの異なる文の間で単語レベルでの類似性を比較することです。
これは非常に高速で効率的で、通常はN-gram重複メトリクスを使用して行います。つまり、生成されたシーケンスのすべての単語について、それが参照シーケンスに出現するかどうかを確認し、出現すれば評価を加算します。N-gramは基本的に同じことですが、単一の単語ではなく、バイグラム、トライグラムなど、複数の単語のグループを見ます。
一般的な重複メトリクスとして最も一般的なのはBLEUとROUGEです。BLEUは青、ROUGEは赤を意味しますが、それが略語の意味ではありません。正確な略語は常に忘れてしまいますが、基本的にBLEUはN-gram重複メトリクスで、精度を見ようとするもので、ROUGEは再現率を見るものです。
先ほども言及したように、もしすべてを文の分類に変換するとしても、精度と再現率のどちらを重視するかを考える必要があります。これらのメトリクスは理想的ではありませんが、2年前までは翻訳と要約のゴールドスタンダードでした。翻訳にはBLEUが使用されます。
例えばフランス語から英語に翻訳する場合、英語で生成されたシーケンスと実際の英語の参照シーケンスを比較し、生成したバイグラムがどれだけ参照シーケンスに出現するかを見ます。
ただし、精度だけを見ると問題があります。非常に短いものを予測すれば、高い精度が得られるからです。例えば常に「the」という単語だけを生成すれば、「the」はほとんどすべての文に出現するため、非常に高い精度が得られます。そのため、長さに対するペナルティも加えています。ROUGEは基本的にその逆で、再現率を見ます。
これらが一般的なコンテンツ重複メトリクスですが、なぜこれらが理想的でないかを説明します。多くの問題がありますが、その一つは単語間の意味的な関連性を考慮していないことです。
例を挙げましょう。クリスが「CS224Nの講義を楽しんでいますか？」と尋ねたとします。もちろん、ゴールド回答は「もちろんです」です。ここで、モデルが単に「はい」と生成した場合、BLEUスコアは67%になります。なぜなら、生成した単語（ユニグラム）のうち2つが参照に含まれているからです。
しかし「知っていますよ」と生成すると、参照シーケンスに出現する生成された単語は感嘆符だけになり、BLEUスコアは大幅に低くなります。「はい」だけを言うと、参照シーケンスに全く出現せず、BLEUスコアはゼロになります。これは偽陰性です。なぜなら、「はい」は「もちろんです」とまったく同じ意味を持つからです。
これらのメトリクスには本当に問題があることがわかります。また、偽陽性も発生します。例えば「いいえ」と言うと、単語の大部分は同じなので70%のBLEUスコアが得られますが、意味はまったく異なります。これらの問題は理解できますか？
4.3. 単語埋め込みと意味的関連性
BLEUの問題点を知った今、自然に思い浮かぶ疑問は「単語を見るのではなく、単語間の意味的類似性を維持する学習された表現を見てはどうか」ということでしょう。
これはまさに人々が行ったことです。2019年頃（実際にはもっと前、2016年頃から）、単語埋め込みを取り、参照シーケンスの各単語に単語埋め込みを関連付け、生成されたシーケンスの各単語に対応する単語埋め込みを関連付け、基本的に単語埋め込みを比較し始めました。
単語埋め込みを比較する非常にシンプルな方法は、参照シーケンスの単語埋め込みの平均と生成されたシーケンスの単語埋め込みの平均を取り、コサイン類似度などで比較することです。もっと複雑な方法もありますが、この時点ではそれほど重要ではありません。平均化を考えると良いでしょう。
ご存知のように、単語埋め込みは単語が出現するコンテキストを本当には考慮していません。単語の良い表現を得るためのより良い方法は、基本的にBERTを見ることです。BERTモデルを取り、生成されたシーケンスを通して埋め込みを得て、同じBERTを使って参照シーケンスを通し、別の埋め込みを得てから、再び比較を行います。
BERTScoreという非常に有名な論文では、彼らは賢い比較を行いますが、具体的に何をしているかを理解することはそれほど重要ではありません。重要なのは、単語間でスマートな平均化を行っているということです。
これらの手法は、単語間の意味的関連性を考慮することで、BLEUやROUGEよりも優れた評価を提供できます。単語が同じではなくても、意味が類似している場合に適切に評価できるのです。
4.4. リファレンスベースの評価の限界
これらの方法すべての重要な問題点は、参照文が良い品質である場合にのみ、その評価も良くなるということです。しかし現実には、参照文は通常それほど良くありません。
これは部分的に、ニュースの要約を調査した論文に見られます。先ほど述べたように、ほとんどのニュース要約ベンチマークでは、記事の上部にある箇条書きをリファレンス要約としています。これは通常、あまり良くありません。
この論文の左側のグラフでは、x軸が人間による評価、つまり各モデルの人間評価によるパフォーマンスを示し、y軸がROUGE-Lというルージュの一種を示しています。この2つが相関しているかどうかを見ています。グラフを見ると、基本的に相関がないことがわかります。これは、標準的な参照文を使用したROUGE-Lが、人間が良い要約だと言うものと実際には相関していないことを意味します。
これはルージュが悪いスコアだという意味ではなく、実際には参照文が悪いという意味です。同じことを見て、今度は専門家に非常に良い要約を書いてもらうと、相関関係は大幅に向上します。まだ完璧ではありませんが、少なくともかなり良くなります。
これは、メトリクス自体が常に完璧ではないだけでなく、参照文も通常実際には良くないということを示しています。
このことから、自然な疑問が生まれます。参照ベースの評価を完全に捨てて、参照なしの評価に移行できないだろうかということです。参照ベースの評価とは、人間が書いた参照を何らかのメトリクスを使ってモデルの出力と比較するものです。これらは、約2〜3年前までNLPタスクを評価するための標準的なベンチマークでした。
今でも論文では、例えば翻訳においてはBLEUスコアを必ず示す必要がありますが、実際の現場では誰もそれを使っていないと思います（ただし、この点については間違っているかもしれません）。BLEUとROUGEについてはほとんど話しましたが、BERTScoreは実際にはまだかなり使われており、かなり良いものです。
5. 参照なし評価手法
5.1. モデルベースの評価方法
参照なし評価とは、基本的にモデルがスコアを出すが、人間による参照回答はない評価方法です。これまでの方法は、本質的にBERTのようなモデルを取り、参照回答と生成された回答を比較する代わりに、入力を取ってスコアを予測するというものでした。これが参照なし評価の一つのシンプルな方法ですが、以前はあまりうまく機能しませんでした。
「以前は」と言ったのは、基本的にChatGPTとGPT-4が登場するまでは、という意味です。現在、人々が行っていること、そして実際に非常にうまく機能していることは、単純にGPT-4に人間と同じタスクを依頼することです。例えば、非常に長いテキストを提供し、生成された要約を示して、「これはどれくらい良いですか？」と本質的に尋ねるのです。これは驚くほどうまく機能します。
この方法の一般的なベンチマークとしては、Alpaca EvalとMT-benchがあります。現在、多くの人々がこのタイプの技術を使い始めていますが、少なくともAlpaca Evalについては後ほど説明します。
このアプローチの主な利点は、参照テキストを必要としないため、新しいタスクやドメインに対して柔軟に適用できることです。また、人間による評価と強い相関を示すことが多く、コストと時間の効率も良いです。
モデルベースの評価方法は、特に大規模言語モデル（LLM）の評価において、急速に標準的なアプローチになりつつあります。これは、モデル自体が評価者として機能するという興味深いパラダイムシフトを表しています。
5.2. Alpaca Evalなどのベンチマーク
Alpaca Evalは私たちがAlpacaに取り組んでいた昨年に開発したベンチマークです。先ほど述べたように、開発段階で必要なのは、ハイパーパラメータチューニングのための評価方法です。当時、指示に従うタスクに対する既存のベンチマークをあまり信頼していなかったため、自分たちだけで小さなベンチマークを開発しました。これは私たちがハイパーパラメータチューニングに使用していたものですが、その後独自の存在意義を持つようになりました。
Alpaca Evalをいくつかの数字で説明すると、Chatbot Arenaとの相関性が非常に高く、ランキングの相関係数は98%です。そして評価は約3分で10ドルで実行できます。
その仕組みは、すでに少し説明しましたが、指示を取り、あるモデルからの出力を生成し、比較しているもう一つのモデルからも出力を生成します。そしてGPT-4に、評価しているモデルと比較している基準モデルのどちらを好むかの確率を基本的に出してもらいます。
それから重み付けを行い、その理由は、先ほど言ったように、これらのモデルは長い出力に非常に偏っているためです。出力が長い場合は、少し低い優先度を与えるように重み付けを行います。そして、データセット全体にわたって平均を取り、勝率を得ます。
これが仕組みです。何か質問はありますか？
システムレベルの相関についてですが、x軸に示されているのは基本的にAlpaca Eval（少し変換されていますが）のスコアで、y軸はChatbot Arenaというゴールドスタンダードです。グラフを見ると、これらがかなり高い相関を持っていることがわかります。
下部のプロットでは、異なるベンチマークとChatbot Arenaの相関を示しています。LLMを評価に使用するMT-benchやAlpaca Evalは、Chatbot Arenaと比較的高い相関があります。また、LLMを使用しない自動評価であるMLUも非常に高い相関を示しています。
先ほど、重み付けを行う必要があると簡単に説明しましたが、なぜそれを行うのかについて詳しく説明したいと思います。私たちが実現するのが少し遅すぎた問題の一つは、GPT-4のような何かを取り、より詳細な回答を提供するようにプロンプトすると、ベンチマークでの勝率が50%から64.3%に上昇することでした。逆に、より簡潔にするように求めると、22.9%に低下しました。
これは、ベンチマークがすべきことについての私たちの考え方には合いません。プロンプトを少し変えただけで、モデルのランキングが完全に変わってしまうべきではありません。そのため重み付けを行う必要があり、重み付け後は、詳細になるようにモデルに指示した場合のパフォーマンスが、プロンプトなしの場合のパフォーマンスに非常に近くなります。
自己バイアスについても少し触れました。この結果に非常に驚いていますが、自己バイアスは存在するものの、思ったほど高くはありません。x軸には評価しているさまざまなモデルのランキングが示され、列には評価に使用しているモデルが示されています。どのモデルで評価しても、ランキングは同じになることがわかります。
例えば、Claudeで評価した場合、自分自身に対して高い精度を与えますが、それでもClaudeはGPT-4を好みます。つまり、自己バイアスは想像したほど悪くないのです。しかし、まだ悪い面はあります。
5.3. 人間による評価との比較
人間による評価と比較すると、モデルベースの評価には興味深い特性があります。私たちがAlpaca Evalの開発に取り組み始めた昨年頃、GPT-4を評価に使用することは、現在の価格で見ると、人間による評価と比較して100倍速く、100倍安いことがわかりました。しかし、これは非常に驚くべきことなのですが、人間の一致率よりもモデルの方が人間との一致率が高いのです。
具体的には、4人の人間のプールがあるとして、1人を取り出し、その人の好みと残りの3人の好みのモードとの一致度を見て、これを順番に行い、この一致度を調べるとします。すると、これはモデルに人間のモードの好みを予測させた場合よりも低くなります。つまり、ある意味では、モデルは人間自身よりも人間と高い相関を示すのです。これは非常に驚くべきことで、もう少し詳しく説明します。
この驚くべき結果、つまりモデルが人間自身よりも人間と高い相関を示すという結果の理由は、人間は実際にアノテーター間の不一致が大きく、分散が高いからです。一方、モデルは常に非常に一貫性があります。完全に一貫しているわけではなく、まだ確率的な要素はありますが、基本的には常に同じラベルを予測します。つまり、分散が非常に少ないのです。
このプロットでは、Y軸に推定分散が示されており、人間の分散は約31または33であることがわかります。赤い点を見ると、これは基本的にGPT-4を評価に使用した場合です。バイアスはまだかなり高いですが（定義上、人間のバイアスはゼロで、GPT-4のバイアスは約32％）、分散は人間よりもはるかに低いです。これが、一致率が時には高くなる理由ですが、それは実際にはLLMにはほとんど、あるいはまったく分散がないからです。これは理解できますか？
このアプローチの意味するところは、LLMベースの評価が実用的な目的で人間による評価の代わりになる可能性があるということです。特に、開発サイクルの初期段階や迅速なプロトタイピングの段階では非常に有用です。ただし、最終的な評価としては、やはり人間による評価も併用することが重要です。
6. 人間による評価
6.1. ゴールドスタンダードとしての人間評価
これまで見てきたように、さまざまな評価メトリクスにはすべて欠点があります。その多くは参照に基づいているため、人間による評価はオープンエンドタスクのゴールドスタンダードと見なされています。
人間による評価は、オープンエンドタスクの評価の最高基準であるだけでなく、新しい自動評価手法を開発するための最高基準でもあります。新しい自動評価を開発するたびに、人間が基本的に予測したであろうものと比較したいと考えるでしょう。
人間による評価を行う場合、単に人間に生成されたテキストの品質を評価するよう依頼するだけでなく、通常はさまざまな側面にわたって評価するよう依頼します。例えば、テキストの流暢さ、一貫性、常識的な内容、スタイル、文法的正確さ、冗長性など、気にする可能性のあるさまざまな側面について評価を求めます。
もう一つ注意すべき点は、異なる人間による評価を比較するべきではないということです。ある論文が「人間は私たちのテキストの流暢さを5段階中4と評価した」と述べ、別の論文が「3」と述べている場合、彼らは異なる人間、異なる方法、人間へのプロンプトの方法が異なるため、これらは絶対に比較できません。
人間の判断はゴールドスタンダードと見なされていますが、確かに問題があります。まず、非常に遅いです。予想通り、人間は自動メトリクスほど速くはありません。第二に、少なくとも学術界では、人間による評価は依然としてかなり高額です。ワーカーに適切に報酬を支払うと、人間による評価はかなり高額になります。
6.2. アノテーター間の不一致
人間による評価のもう一つの問題は、アノテーター間の不一致です。この部屋の中から無作為に2人を選んで、生成されたテキストの品質を評価するよう依頼すると、皆さんは本当に意見が一致しないでしょう。特に主観的な場合はひどいのですが、評価の方法について1時間話し合ったとしても、多くの評価において意見が一致しないことをほぼ保証できます。
具体例を挙げると、昨年Alpaca Farmという取り組みを行った際、基本的に入力を取り、2つのモデル（ChatGPTやAlpacaなど）を使い、2つのモデルに回答を予測させ、その後人間にどちらの回答が好ましいかを尋ねるという非常にシンプルなタスクでした。これは非常に単純なタスクですが、後ほど説明するように、現在ChatGPTのようなモデルを評価するために多くの人々が使用している方法です。
自然な疑問として、人間がこうした評価を行うのに良いかどうかということがあります。私たちは5人の研究者でこれを行い、5人で2〜3時間話し合い、評価方法について非常に詳細なルーブリックを作成しました。それでも、私たちの意見が一致したのは67%の時間だけでした。50%はランダムですから、独立してラベル付けした場合、意見の一致率は67%でした。そして私たちは本当に最善を尽くしました。このプロジェクトに取り組んでいたので、手早く済ませようとしていたわけではありません。
人々は本当に意見が一致しません。もちろん、アノテーター間で議論を許可すれば、一致率は向上しますが、そうするとさらに遅く、より高額になります。
このアノテーター間の不一致の問題は、人間による評価の信頼性と再現性に大きな課題をもたらします。詳細なガイドラインを提供し、十分なトレーニングを行っても、人間の主観性や解釈の違いにより、評価結果にはある程度のばらつきが生じることは避けられないのです。
6.3. アノテーター内の不一致
アノテーター内の不一致も非常に厄介な問題です。私自身に今何かを評価するよう依頼し、3時間後、つまり食事を取った後やランニングに行った後にも同じことを評価するよう依頼すると、実際に異なる評価を下すことになります。
この問題は人間の認知処理の本質的な変動性を反映しています。同じ評価者でも、時間帯、体調、気分、あるいは直前に見たサンプルなどの状況要因によって、同じ内容に対する評価が変わることがあります。
これは評価の信頼性にさらなる課題をもたらします。なぜなら、同じアノテーターでさえ、時間の経過とともに一貫した判断を維持できないということは、評価プロセス全体の安定性に疑問を投げかけるからです。
この問題に対処するためには、複数の評価者を使用するだけでなく、同じ評価者に時間をおいて同じサンプルを再評価してもらい、評価の一貫性を測定することが重要です。しかし、これはさらに時間とコストを増加させることになります。
アノテーター内の不一致は特に、微妙な判断や主観的な評価基準を必要とするタスクで顕著になります。そして、このような不一致が存在することは、人間による評価を完全に信頼することの難しさを示しています。
6.4. 費用とスケール問題
人間による評価の課題として特に重要なのは、費用と時間の問題です。予想される通り、人間は自動評価メトリクスと比較して明らかに遅いです。学術界においては、少なくとも現時点では、人間による評価はかなり高額です。評価者に適切に報酬を支払うと、人間による評価を十分に行うことは非常にコストがかかります。
大規模な評価を行う場合、この問題はさらに顕著になります。例えば、複数のモデル設定を比較したり、モデルの改善を継続的に評価したりする場合、人間によるフィードバックの収集は膨大な時間とコストを要します。
また、人間による評価は本質的にスケールしにくいという問題があります。評価の品質を維持しながら評価者の数を増やすことは難しく、調整や管理の複雑さが増します。特に高度な専門知識が必要なタスクでは、適格な評価者を見つけること自体が課題となります。
これらの制約により、開発サイクルの早い段階や頻繁な評価が必要な状況では、人間による評価は現実的ではないことが多いです。モデル開発の反復プロセスでは、より速く安価な自動評価メソッドが実用的な代替となりますが、最終的な品質評価には依然として人間による評価が重要です。
6.5. インセンティブの不一致
もう一つの課題は、インセンティブの不一致です。あなたが望むのは、人間が可能な限り最高の評価を行うことですが、クラウドワーカーが通常望むのは、基本的には時間あたりの報酬を最大化することです。
再び具体例を挙げると、Alpaca Farmを行った際、私たちはカリフォルニアの最低賃金の1.5倍という比較的良い報酬を支払っていたと思います。そして基本的に、私たちが単一の例を可能な限り最高に評価するのにかかる時間を調べ、その時間で割って、各例にいくら支払うかを決定しました。
驚いたことに、彼らは結局、最低賃金の2倍か2.5倍の報酬を得ていました。なぜなら、私たちよりも2〜3倍速く作業を行っていたからです。私たちが遅かったのかもしれませんが、おそらく起きていたのは、彼らが時間あたりの収入を最大化しようとしていて、その結果、評価を行うためのショートカットを見つけていたのです。
これは論文でも実際によく見られることです。例えば私たちの場合、人間は明らかに長い回答を好むことがわかりました。もちろん、もし2つの非常に長い生成文を与えられ、最小限の作業でどちらが良いかを言うよう求められたら、より長いものを見れば「おそらくより多くの詳細があり、おそらく良い」と思うでしょう。
とはいえ、全員がそうだというわけではありませんが、インセンティブが一致していないのは確かです。これに注意する必要があります。
このインセンティブの不一致は、評価の質に直接影響します。クラウドワーカーが効率を優先し、深い分析よりも表面的な特徴（長さなど）に基づいて判断する傾向があると、評価結果の信頼性に疑問が生じます。また、複雑な言語理解や微妙なニュアンスの評価が必要なタスクでは、この問題がさらに深刻になる可能性があります。
6.6. 実験で見られた課題（作業者が長い回答を好む傾向など）
人間による評価にはさらに多くの課題があります。まず、タスクをどのように記述するかを決める必要があります。人間がタスクをどのように評価すべきかについて、非常に詳細なルーブリックを提供する必要があります。
次に、タスクをどのように人間に示すかという問題があります。例えば、例を提示する順序が実際に非常に重要です。私たちの場合、2つの例を並べて表示していたため、どちらが左側でどちらが右側にあるかも非常に重要でした。これらすべての要素が本当に重要なのです。
もちろん、これらの要因をランダム化することでバイアスを減らすことはできますが、課題は増えます。また、どのようなメトリクスを使用するかという問題も、人間に特有というわけではありません。
評価者の選択も非常に複雑です。お金があってAmazon Mechanical Turkに行き、単に評価者に注釈付けを依頼できるかもしれませんが、実際には優れた評価者を確保したいと考えます。Amazon Mechanical Turkでの一般的な仕組みは、「ここにタスクがあり、30人の異なる人にこれらの注釈を付けてほしい」と言うことです。彼らは注釈付けを始め、もし望むレベルに達しなければ、その時点までの注釈に対して支払いを行い、その後は他の人と仕事をすることになります。
ここで、彼らが望むパフォーマンスを達成したかどうかをどのように判断するかという問題が出てきます。おそらく事前にいくつかのゴールドラベルを作成し、あなたやチームの他の研究者とのアノテーター間の一致度などの精度を確認する必要があるでしょう。
したがって、これは非常に複雑で、さらに時間の経過とともにこれを監視する必要もあります。これを監視するための方法はいくつかあります。精度を見ることもできますし、典型的なアプローチとしては、ラベル付けする各バッチの例の中に、既にゴールドラベルが何であるか知っている例をいくつか含め、それでどれだけうまく機能しているかを確認することです。また、注釈付けにかかる時間を見ることもできます。
これらの課題に加えて、実験で観察された具体的な問題点としては、先ほど触れた「評価者が長い回答を好む傾向」があります。これは単純に、詳細な分析をせずに表面的な特徴に基づいて判断してしまうバイアスです。長い回答はより多くの情報を含んでいるように見えるため、詳細な検討なしに「より良い」と判断されがちです。
このようなバイアスは評価結果を歪める可能性があり、本当に優れたモデルよりも単に冗長なモデルが高く評価される結果につながりかねません。同様に、リストの使用や構造化された形式の回答も、内容の質とは無関係に高評価を受ける傾向があります。
以上のように、人間による評価は難しいですが、それでもオープンエンドタスクのゴールドスタンダードです。完璧ではありませんが、適切に設計・管理された人間評価は依然として自動評価メトリクスよりも信頼性が高く、モデルの実際の品質を評価する上で不可欠なアプローチです。
7. チャットボットの評価手法
7.1. Chatbot Arenaの仕組み
さて、参照なし評価とチャットボットについて話しましょう。先ほど簡単に触れましたが、ChatGPTのようなものをどのように評価するかは非常に複雑です。基本的にあらゆるタスクを依頼でき、任意の長さのテキストで回答できるからです。これは評価を非常に難しくします。
先ほど示唆したように、通常の方法は2つのモデルを並べて配置し、同じ質問をして、人間またはモデル（後で説明します）のどちらかに、どちらが良いかを尋ねることです。
これが現在、人間による評価の最も一般的なベンチマークと言えるChatbot Arenaの仕組みです。基本的に誰でもオンラインに行き、無料で最高のモデルのいくつかを試すことができます。彼らが尋ねるのは、右側と左側のどちらを好むかを言うことだけです。
そして20万件という膨大な量の人間の投票に達すると、彼らはそれをリーダーボードに追加します。リーダーボードへの追加方法は、チェスのような仕組みで、基本的にELOレーティングを見ます。すべてをトーナメントのように扱い、すべてのモデルが他のすべてのモデルと対戦する必要がないようにし、それによってELOスコアを得ます。
このサイド・バイ・サイド人間評価は、チャットLLMの評価のゴールドスタンダードですが、それでもいくつかの課題があります。まず、基本的にはオンラインのランダムな人々がランダムな質問をして、彼らの好みを提供しています。これは代表的ではないかもしれませんが、議論の余地はあるものの、これだけ多くの例があれば、実際に人々が望むものを相当程度代表していると言えるでしょう。おそらく私たちが持っているものよりは良いでしょう。しかし、それでも理想的ではありません。
そして本当に大きな問題はコストです。これは巨大なコミュニティの努力と多くの人々の作業を必要とします。また、新しいモデルをベンチマークに載せるまでに多くの時間がかかり、OpenAI、Claude、Google、Facebookのような注目すべきモデルだけがベンチマークされます。あなたのランダムなモデルに対して、20万人が無料で注釈付けをしてくれることはないでしょう。
これは問題です。最初のスライドで話したように、これらの大企業でさえ、モデルの開発には確実にこれを行うことはできません。これは最後に来るもので、おそらくモデル選択のためのものです。
7.2. モデル間の比較手法
チャットボットの評価において、モデル間の比較は最も効果的なアプローチの一つです。この方法では、2つのモデルを並べて配置し、同じ質問を投げかけ、その回答の品質を直接比較します。
この比較方法の主な利点は、絶対的な評価基準を定義する難しさを回避できることです。絶対的な評価基準（例えば「良い会話とは何か」）を定義することは非常に困難で主観的ですが、2つの回答のどちらが良いかを判断することは比較的簡単です。
比較評価の具体的な実装方法としては、まず2つのモデルに同一の入力（質問、指示など）を与えます。次に、それぞれのモデルの出力を並べて表示し、評価者（人間またはLLM）にどちらの回答がより良いかを判断してもらいます。この時、左右のどちらにどのモデルの回答を表示するかはランダム化することが重要です。なぜなら、位置によるバイアスが存在するからです。
比較評価の結果は通常、「勝率」という形で表されます。特定のモデルが他のモデルに対して何パーセントの確率で勝つかを示す指標です。これらの勝率に基づいて、チェスのELOレーティングのような仕組みを使ってモデルのランキングを作成することができます。
この方法の優れている点は、実際の使用状況に近い評価が可能なことです。ユーザーは実際にモデルに質問をし、その回答を比較するため、実世界での有用性を直接評価できます。また、特定の能力やドメインにおける強みや弱みを特定するために、質問のカテゴリ別に結果を分析することも可能です。
ただし、この比較手法にも課題があります。評価者の好みや期待によるバイアス、公平な比較のための適切な質問選択、そして大量の比較を必要とすることによるコストと時間の問題などです。これらの課題にもかかわらず、モデル間の直接比較は、チャットLLMの評価において現在最も信頼性の高い方法の一つと考えられています。
7.3. GPT-4を評価者として使用する手法
より高速に評価する方法は何でしょうか？一つの非常に自然な解決策は、基本的に大規模言語モデルに評価を依頼することです。たとえば、ChatGPTとClaudeを比較したいとします。基本的にGPT-4に、どちらが良いかを評価してもらいます。これは驚くほどうまく機能し、後でいくつかの結果をお見せします。この手法の一般的なバージョンとしては、Alpaca EvalとMT-benchが最も一般的なものでしょう。
私たちがこの方法の開発を始めたのは去年頃です。GPT-4を評価に使用することは、現在の価格で見ると、人間による評価と比較して少なくとも100倍速く、100倍安いことがわかりました。しかし驚くべきことに、人間との一致率は、人間同士の一致率よりも高いのです。
具体的には、4人の人間のプールがあるとして、1人を取り出し、その人の好みと残りの3人の多数意見（モード）との一致度を見て、これを順番に行い、この一致度を調べるとします。すると、これはモデルに人間の多数意見の好みを予測させた場合よりも低くなります。つまり、ある意味では、モデルは人間自身よりも人間と高い相関を示すのです。これは非常に驚くべきことで、もう少し詳しく説明します。
私たちはこの手法を使って、強化学習（RLHF）のための人間の好みを収集しました。これはArchitが先週話したRLHFと呼ばれるものです。
この驚くべき結果、つまりモデルが人間自身よりも人間と高い相関を示すという結果の理由は、人間は実際にアノテーター間の不一致が大きく、分散が高いからです。一方、モデルは常に非常に一貫性があります。完全に一貫しているわけではなく、まだ確率的な要素はありますが、基本的には常に同じラベルを予測します。つまり、分散が非常に少ないのです。
このプロットでは、X軸に推定分散が示されており、人間の分散は約31または33であることがわかります。赤い点を見ると、これは基本的にGPT-4を評価に使用した場合です。バイアスはまだかなり高いですが（定義上、人間のバイアスはゼロで、GPT-4のバイアスは約32％）、分散は人間よりもはるかに低いです。これが、一致率が時には高くなる理由ですが、それは実際にはLLMにはほとんど、あるいはまったく分散がないからです。
7.4. 自己バイアスの問題
人間とLLMの両方で作業する際に注意すべき点があります。疑似相関がいくつか見られるでしょう。すでに疑似相関について話しましたが、多くのケースで見られます。
非常に一般的な例の一つは文章の長さです。先ほど述べたように、クラウドワーカーにどの例を好むか尋ねると、彼らは長い出力に非常に偏っています。青色のグラフは人間を表し、長い出力への好みは約70%であり、モデルもほぼ同じバイアスを示しています。
もう一つの例はリストへの好みです。通常、出力にリストが含まれている場合、モデルはこれらの例を好み、人間もこれらの例を好みます。
別のバイアスまたは疑似相関は位置です。人間に評価を依頼する際、どちらを左側に置き、どちらを右側に置くかという問題があります。モデルでも同じことがありますが、これは通常、両方をランダム化することで簡単に制御できます。
もう一つの問題は、GPT-4の自己バイアスです。非常に自然に、GPT-4に自己評価を依頼すると、おそらく自分自身を他のモデルよりも好むだろうと考えるかもしれません。これは事実ですが、思うほどではありません。後ほど説明します。
自己バイアスについて、この結果に非常に驚いていますが、自己バイアスは存在するものの、思ったほど高くはありません。X軸には評価しているさまざまなモデルのランキングが示され、列には評価に使用しているモデルが示されています。どのモデルで評価しても、ランキングは同じになることがわかります。
例えば、Claudeモデルで評価すると、自分自身に対して高い精度を与えますが、それでもClaudeはGPT-4とClaudeを好みます。つまり、自己バイアスは想像したほど悪くないのです。しかし、まだ問題として存在しています。
このような様々なバイアスの問題は、LLMを評価者として使用する際に考慮すべき重要な要素です。バイアスを完全に排除することは難しいですが、意識してデザインに取り入れることで、より信頼性の高い評価システムを構築することができます。
8. 現在のLLM評価手法
8.1. パープレキシティによる評価
現在のLLM評価方法について説明すると、主に三つの主要な評価方法があります。一つ目はパープレキシティで、これは本質的にトレーニングの損失または検証損失を見ることです。二つ目は基本的にすべてを平均化することで、これは思うより実はかなり一般的です。三つ目はこのArenaのような方法で、モデル間の比較を行い、人間かモデルのどちらかを使って評価します。
通常、事前訓練されたモデル（例えばLlama 4やGPT-5が登場した時）は、主にパープレキシティと「すべての平均」を示します。一方、ファインチューニングされたモデルは、通常「すべての平均」とArenaのようなパフォーマンスを示す傾向があります。
これは、ファインチューニングされたモデルが予測する対数尤度が、データセットに対してキャリブレーションされていないからです。「すべて」とは何を意味するのでしょうか？私が言う「すべて」とは、HelmやHugging Faceのオープンリーダーボードなど、自動的に評価される多くの異なるベンチマークのコレクションで、それらすべてにわたって評価するというものです。
私たちが使用する一般的なベンチマークの一部として、数学のパフォーマンスを測定するGSM 8K、数学・科学・歴史などの多肢選択問題解答のMLU、法的側面のLegal Benchなどがあります。MedQAはHelm用で、医療免許試験です。基本的に自動的に評価できる多くの異なる質問があり、平均を取ることで、モデルのパフォーマンスを示すことを期待します。これは、いわばSuperGLUEの新しいバージョンと言えるでしょう。
特に強調したいデータセットの一つは、おそらく最も広く使用され、最も信頼されているベンチマークであるMLU（大規模多タスク言語理解）です。これは57の異なるタスクにわたる多肢選択問題で、形式論理、概念物理学、計量経済学などのタスクがあります。
例を挙げると、「Ia型超新星について真実なのは何か」という質問で、「このタイプは連星系で発生する」「このタイプは若い銀河で発生する」などの選択肢があり、どの答えが正しいかを選ぶ必要があります。タスクは単純ではありませんが、評価方法は単純に見えます。
また、「キリンの集団における環境変化」についての高校生物学の問題もあります。これは方向選択の例です。これらは単純に見えますが、実際にはより複雑です。後ほど詳しく説明します。
これはおそらく最も一般的なベンチマークで、人々が実際に注目しているものです。例えば、Mark ZuckerbergがLLaMA 3を発表した際、彼はMLUスコアについて言及しましたが、私はこれが少し驚くべきことだと思います。
パープレキシティに関する一つの興味深い点は、事前訓練時のパフォーマンスが、下流タスクでのパフォーマンスと非常に高い相関を示すことです。少なくとも現在のタイプのLLMでは、トレーニングパフォーマンス、つまり次の単語を予測する能力が、下流タスクのパフォーマンスと非常に高い相関があります。
X軸は本質的にパープレキシティ、Y軸は多くの異なるタスクの平均を示しています。パープレキシティで良いパフォーマンスを示すタスクは、実際に高い平均スコアを持つことがわかります。その結果、多くの人々が開発時にはパープレキシティだけを見て、下流の評価を行う必要がないほど十分に信頼することになります。私はこれを推奨しませんが、速くて簡単な方法が必要な場合は、通常うまく機能します。
ただし、注意すべき点が二つあります。パープレキシティは異なるデータセット間で比較できません。したがって、どのパープレキシティを見ているかについて本当に注意する必要があります。また、トークナイザーによっても異なります。Llama 3とGeminiを比較する場合、同じデータセットでも異なるスコアが出ますので、比較できません。
8.2. 複数ベンチマークの平均値
「すべての平均」という評価方法について説明します。私が「すべて」と言うとき、最も一般的な二つのベンチマークコレクションは、HelmとHugging Faceのオープンリーダーボードです。これらは自動的に評価される多数の異なるベンチマークの集まりで、すべてのベンチマークにわたって評価を行います。
使用される一般的なベンチマークにはどのようなものがあるでしょうか。まず、数学的パフォーマンスを測定するGSM 8Kがあります。これは小学校レベルの数学問題のベンチマークです。
次にMLUは、数学、科学、歴史、法律などの分野における多肢選択問題を扱います。
また、Legal Benchは法的側面に焦点を当てています。
MedQAはHelm用で、医師免許試験問題を含みます。基本的に、自動的に評価できる多くの異なる質問があり、それらの平均値を取ることで、モデルの全体的なパフォーマンスを示そうとします。
これはいわば、以前のSuperGLUEの新しいバージョンと考えることができます。複数の異なるタスクのコレクションを作成し、それらすべての平均を取ることで、モデルの総合的な言語能力を測定するアプローチです。
このアプローチの利点は、幅広い能力を評価できることです。単一のタスクではモデルの特定の強みや弱みを見逃す可能性がありますが、多様なタスクの集合では、より総合的な評価が可能になります。
しかし、このアプローチには問題もあります。異なるタスクの重要性は実際の用途によって大きく異なりますが、単純な平均では全てのタスクに同じ重みを与えてしまいます。また、異なるタスクで使用される評価メトリクス（精度、F1スコア、相関係数など）を平均することは、統計的に問題がある場合があります。
それでも、複数ベンチマークの平均値は、特に事前訓練済みモデルの総合的な能力を比較するための標準的な方法として広く使用されています。より細かい分析や特定の用途に対する評価には、個別のタスクに焦点を当てたアプローチが適しているかもしれません。
8.3. Arenaライクな比較評価
最後の評価方法は、すでに説明したArenaのような方法です。基本的に異なるモデルを比較し、本質的にそれらを互いに戦わせて、最終的にELOレーティングを得ます。より一般的な言い方をすれば、実際にはユーザーに決定させるというもので、これもかなりうまく機能します。
Arenaライクな比較評価の中心的な考え方は、モデルの絶対的な性能を測定するのではなく、2つ以上のモデルを直接比較することです。この方法では、同じ入力（質問や指示など）を複数のモデルに与え、それらの応答を人間の評価者あるいはLLM評価者に比較してもらいます。
Chatbot Arenaのような実装では、ユーザーがランダムに選ばれた2つのモデル間で盲検テストを行い、どちらの回答が良かったかを選択します。これらの一対比較から、チェスのELOレーティングのような仕組みでモデルのランキングを作成します。
このアプローチの主な利点は、評価が実際の使用状況に非常に近いことです。ユーザーは実際に関心のある質問を自然に尋ね、どのモデルが最も役立つ回答を提供するかを判断します。また、特定の性能指標を事前に定義する必要もないため、複雑な言語能力の評価に適しています。
さらに、継続的にデータを収集することで、新しいタイプの質問や変化するユーザーの期待に対するモデルのパフォーマンスを追跡できます。これは、固定されたベンチマークよりも、実世界での有用性をより良く反映する可能性があります。
ただし、このアプローチにも課題があります。まず、大量の比較が必要であり、特に新しいモデルや小規模な組織のモデルでは十分なデータを収集するのが難しい場合があります。また、ユーザーの好みにはバイアスが含まれる可能性があり、例えば長い回答や特定のスタイルを好む傾向などがあります。
それでも、Arenaライクな比較評価は、特にチャットボットやアシスタント型のLLMの評価において、現在最も信頼性の高い方法の一つと考えられています。人間による直接比較はゴールドスタンダードであり、GPT-4などのLLMを評価者として使用することで、スケールと効率を維持しながら同様の評価を行うことができます。
8.4. MLUベンチマークの詳細と重要性
おそらく最も広く使用され、最も信頼されているベンチマークの一つはMLU（Massively Multitask Language Understanding）です。これは多肢選択問題に基づく57の異なるタスクからなるベンチマークです。形式論理、概念物理学、計量経済学などさまざまな種類のタスクが含まれています。
MLUの例を紹介すると、例えば「Ia型超新星について真実なのは何か」という問題があり、「このタイプは連星系で発生する」「このタイプは若い銀河で発生する」といった選択肢から答えを選ぶ必要があります。このタスクはシンプルに見えますが、実際には専門知識を要する難しい問題です。
また、「キリンの集団における環境変化」についての高校生物学の問題もあります。これは「方向選択の例」という答えを選ぶ必要があります。このようなタスクは簡単に評価できるように見えますが、実際にはより複雑な問題があります。
MLUは現在、最も一般的なLLM評価ベンチマークの一つであり、多くの研究者や企業がモデルの性能を比較する際に使用しています。例えば、Mark ZuckerbergがLLaMA 3を発表した際には、MLUスコアに言及していました。これは少し驚くべきことですが、それだけMLUが業界内で重要視されていることを示しています。
MLUの重要性は、幅広い学問分野を横断する多様なタスクを含んでいることにあります。これにより、モデルの一般的な知識と推論能力を総合的に評価することができます。また、多肢選択形式のため、評価が比較的直接的で客観的に行えるという利点もあります。
しかし、MLUにも課題があります。選択肢のフォーマット（A、B、C、Dなど）を変更するだけで、生成される回答が変わり、異なるモデル間のランキングも変わることがあります。さらに、MLUの実装方法にも複数のバージョンが存在し、同じモデルでも異なるスコアが出ることがあります。
例えば、約1年間にわたって3つの主要なMLU実装が存在し、それらが異なるスコアを出していたにもかかわらず、人々はそれらを比較していました。主な違いは、異なるプロンプトを使用していたことと、実際の予測を得るための異なるサンプリング方法を使用していたことです。
これらの問題にもかかわらず、MLUは現在のLLM評価において中心的な役割を果たし続けており、モデルの全体的な言語理解能力を測定するための標準的なベンチマークとなっています。
8.5. コーディング能力の評価
人々が注目する他の能力にはコーディングがあります。コーディングは非常に一般的な評価対象であり、いくつかの理由があります。一つはコーディングが優れていると、通常これらのモデルは推論能力も優れているからです。これは実際にかなり興味深いことですが、人々が気にする能力と高い相関があるのです。
二つ目の理由は、私たち多くがコーダーなので、コーディングを支援するためのより良いモデルが欲しいということです。三つ目の理由は、評価が実際にかなり簡単だということです。テストケースを作成できるからです。基本的に、モデルに非常に長いコードや、何かを行うための関数を生成するよう依頼し、テストを実行して成功するかどうかを確認するだけです。
コーディングタスクは構造化されており、正解が明確に定義できるため、評価が比較的客観的に行えます。例えば、特定の入力に対して期待される出力を生成するかどうか、効率的なアルゴリズムを使用しているかどうか、エッジケースを適切に処理しているかどうかなどを確認できます。
コーディング能力の評価に使用される一般的なベンチマークとしては、HumanEvalやMBPP（Multiple-step Basic Programming Problems）などがあります。これらのベンチマークでは、モデルに関数の仕様が与えられ、その仕様を満たす完全な関数を生成することが求められます。
また、より難易度の高いコーディング課題を含むベンチマークも存在します。例えば、CodeForces問題などの競技プログラミングの問題や、実際のソフトウェア開発に近い複雑なコーディングタスクなどです。
コーディング能力の評価では、単にコードが動作するかどうかだけでなく、コードの品質、可読性、効率性、保守性なども考慮することがあります。これらの側面は自動評価が難しいため、人間の専門家による評価が必要になることもあります。
興味深いことに、コーディング能力は他の認知能力と高い相関関係があるとされています。コーディングに優れたモデルは、論理的推論や複雑な手順の理解など、他の知的タスクでも優れた性能を示す傾向があります。このため、コーディング評価はモデルの全体的な知的能力の良い指標となる可能性があります。
8.6. エージェント能力の評価
人々が注目し始めているもう一つの要素はエージェントです。Shakarは後でこれについて講義を行うと思うので、あまり詳しくは話しませんが、LLMが現在できる興味深いことの一つは、基本的にAPIを呼び出し、実世界でアクションを起こすこと、つまり本質的にコンピュータを制御することです。
ただし、コンピュータの制御権を与えるべきではありません。エージェントの評価における最大の課題は、例えばコーディングやターミナルでの操作の評価をしたい場合、ターミナルへのアクセスをLLMに与える必要がありますが、私は本当にターミナルへのアクセスをLLMに与えたくありません。
したがって、特定のユースケースに対してサンドボックス環境が本当に必要です。ターミナルの場合、サンドボックス化は比較的簡単ですが、Slackでメッセージングやメールでの執筆など、他のアプリケーションでLLMを評価したい場合は、LLMにアクセスを与えたいすべてのアプリケーションのサンドボックス環境を作成する必要があります。
これは実際に非常に複雑で、現実世界で人々が対処しなければならない問題の一つです。少なくとも私たちは対処しなければなりません。現在はまだ本番環境に導入されていないからです。
エージェント評価の難しさは、エージェントが複数のステップや複数のツールを使用して複雑なタスクを達成する能力を測定する必要があることです。例えば、「予算内で最適な休暇プランを立てる」というタスクでは、エージェントは検索、カレンダー確認、価格比較、予約システムとの対話など、複数のサブタスクを調整する必要があります。
エージェント評価のためのベンチマークとして、AgentBenchやWebArenaなどが開発されています。これらは、情報検索、計画立案、問題解決などのさまざまなエージェントタスクを含んでいます。また、ReActやAGIXなどのフレームワークを使用して、エージェントの思考プロセスや決定プロセスを評価することもあります。
エージェント評価においては、タスク完了率、効率性（必要なステップ数や時間）、ツール使用の適切さ、エラー処理能力、ユーザーとの対話品質などの側面が考慮されます。
現在のエージェント評価の大きな課題の一つは、安全性とセキュリティの評価です。エージェントに実際のシステムへのアクセスを与えることなく、その能力を現実的に評価するための方法を開発する必要があります。これには、厳密に制御されたサンドボックス環境の開発が必要です。
エージェント技術は急速に発展しており、その評価方法も進化し続けています。将来的には、より標準化されたエージェント評価フレームワークが開発され、異なるエージェントシステム間のより公平な比較が可能になることが期待されています。
9. 現在の評価手法の課題
9.1. 一貫性の問題
現在の評価方法にはいくつかの問題点があります。まず一つ目は一貫性の問題です。質問応答、つまり多肢選択問題を見ると、左上と右上の例に示されているように、ABCDを単にランダムな記号に変えるだけで、生成される回答が実際に異なり、異なるモデル間のランキングも変わってしまいます。
つまり、多肢選択のように単純なこと、つまり4つの選択肢から選ぶという非常にシンプルなことでさえ、選択肢をどのようにフォーマットするかに非常に依存します。
実際の例として、先ほど言及したMLUがあります。MLUは、4つある選択肢のうちどれをモデルが好むかを尋ねるだけのように見えますが、実際には約1年間、MLUには3つの主要な実装があり、人々はこれらの3つの間で比較していました。それぞれが異なるスコアを出していることに気づかずにいたのです。
主な違いは2つありました。1つ目は、人々が異なるプロンプトを使用していたことで、これは明らかに異なる回答を生み出します。2つ目は、実際の最も可能性の高い予測を得るために異なるサンプリング方法を使用していたことです。
例えば、ある実装では、「4つの選択肢のうち最も可能性の高いものは何か」と尋ねていました。正解がDだとすると、ABCDの中で最も可能性の高い回答を見ます。「Z」が最も可能性の高い回答であったとしても、制約付きデコーディングを行うため、それは見ません。制約付きデコーディングを行うと、正解はDと言うことになります。
しかし、実際に最も可能性の高いトークンを見るだけの別の実装では、正解を得られないでしょう。
3つ目の実装は、これらとはかなり異なるように見えますが、ABCDを生成するのではなく、この質問の後に回答として「この文」が来る確率、つまり対数尤度を見るというものです。これは非常に異なる結果をもたらします。
右上のグラフを見ると、Llama 65BがHelmのMLUで63.7%、オリジナルのMLUで63.6%でしたが、Hugging Faceが使用するHarnessでは48.8%でした。これは非常に大きな違いです。
これらの一貫性の問題は、評価結果を解釈する際に注意が必要であることを示しています。同じモデルでも、評価方法やパラメータの小さな違いによって、大きく異なる結果が得られる可能性があるのです。
9.2. コンタミネーション問題（テストデータへの漏洩）
もう一つの問題はコンタミネーション（汚染）です。Harasheさん（Twitterでフォローすべき人物です）が、コードベンチマークを調査していたときのことです。彼はCodeForceの問題を調べていて、2021年以前の問題ではGPT-4が10問中10問正解していたのに対し、2021年以降の最近の問題では10問中0問しか正解できないことに気づきました。これは非常に奇妙に見えます。
これは強く、コンタミネーションが起きていること、おそらくモデルが事前訓練データセットとしてCodeForceのデータセットを使用していたことを示唆しています。もちろん、本質的にテストセットでトレーニングを行えば、非常に良いパフォーマンスを示すでしょう。
また、SuzanaさんもMicrosoft社のClaude 1.5モデルについて同様のことを述べています。
ここで難しいのは、クローズドモデルでは実際に二つの問題があることです。一つは、これらのモデルが非常に大量のデータで事前訓練されているため、たとえデータにアクセスできたとしても、テストセットで事前訓練されていたかどうかを実際に知るのは難しいということです。二つ目は、これらはすべてクローズドソースモデルなので、データセットにもアクセスできず、テストセットで事前訓練されていたかどうかを知る方法がないということです。
オーバーフィッティングの問題もあり、これはコンタミネーションとは少し異なりますが関連しています。ここでは、標準的なデータセットが「引用符付きの」人間レベルのパフォーマンスを達成するまでにかかった時間を示しています。最近のデータセットでは、事前訓練の場合、実際に6ヶ月未満で人間レベルのパフォーマンスを達成しています。
これがコンタミネーションのためなのか、単に多くの人々がこれらのテストセットでハイパーパラメータチューニングを行ってオーバーフィッティングしているためなのか、私たちには分かりません。しかし、これは明らかにオーバーフィッティングの問題です。
この問題を軽減する方法としては、まずプライベートテストセットを持つことが挙げられます。2週間前の論文でGSM 1Kが発表されました。これはGSM 8K（数学データセット）と同じものですが、基本的にこのデータセットを再生成または再サンプリングし、新たに収集しています。そして、異なるモデルがGSM 1KとGSM 8Kの両方でどれだけうまく機能するかを調べています。
結果として、少なくともオープンソースモデルは、人々がチューニングできる既存のデータセットよりも、新しいデータセットでの性能が大幅に低下することがわかりました。ただし、ClaudeやGPT-4などのモデルではこれは当てはまりません。
もう一つの方法は、ダイナミックベンチマークまたはダイナミックテストセットを使用することです。理想的には、X日ごとにモデルへの新しい指示や入力を持ち、データセットを動的に変更することです。これはChatbot Arenaが本質的に行っていることです。
コンタミネーションを軽減するもう一つの方法は、モデルが実際にテストセットで訓練されたかどうかを推定しようとすることです。これを行う非常にシンプルな方法の一つは、異なる回答の確率を見ることです。モデルがある回答について非常に確信を持っている場合、おそらくその回答で訓練されていたと考えられます。
また、テストセットの順序を見ることも効果的です。モデルがテストセット上で事前訓練されていた場合、例2が例1の後に来ると考えている可能性が高いです。例1と例2を入れ替えて対数尤度の低下が見られる場合、モデルはそのデータセットで実際に事前訓練されていた可能性が高いです。
9.3. オーバーフィッティングの問題
オーバーフィッティングの問題はコンタミネーションと関連していますが、少し異なる現象です。標準的なデータセットが「引用符付きの」人間レベルのパフォーマンスを達成するまでにかかった時間を見ると、最近のデータセットでは、事前訓練の場合、実際に6ヶ月未満で人間レベルのパフォーマンスに達しています。
これがコンタミネーションによるものなのか、単に多くの研究者や開発者がこれらのテストセットでハイパーパラメータチューニングを行い、オーバーフィッティングしているためなのか、明確ではありません。しかし、これは明らかに評価における深刻な問題です。
この問題を軽減する方法としては、いくつかのアプローチがあります。一つはプライベートテストセットを持つことです。例えば、2週間前に発表されたGSM 1Kという論文があります。これはGSM 8K（数学データセット）と同じものですが、このデータセットを再生成または再サンプリングし、新たに収集しています。
研究者たちは、異なるモデルがGSM 1KとGSM 8Kの両方でどのように機能するかを調査しました。その結果、少なくともオープンソースモデルは、人々がチューニングできる既存のデータセットよりも、新しいデータセットでの性能が大幅に低下することがわかりました。興味深いことに、ClaudeやGPT-4などのクローズドモデルではこの傾向は見られませんでした。
もう一つの方法は、ダイナミックベンチマークまたはダイナミックテストセットを使用することです。理想的には、一定期間ごとにモデルへの新しい指示や入力を持ち、データセットを動的に変更することです。これはChatbot Arenaが本質的に行っている方法で、常に新しいユーザーの質問が入ってくるため、モデルは特定のテストセットに最適化することができません。
オーバーフィッティングの問題は、特に公開されているベンチマークでは深刻です。あるモデルが特定のベンチマークで優れたパフォーマンスを示していても、それが実際の言語能力の向上を反映しているのか、単にそのベンチマークに特化した最適化の結果なのかを判断するのは難しいのです。
真に一般化可能な言語能力を評価するためには、モデル開発者がアクセスできない新しいテストデータを定期的に導入することが重要です。そうすることで、モデルが本当に言語や推論の能力を向上させているのか、それとも単に特定のベンチマークに過剰適合しているだけなのかをより正確に判断できるようになります。
9.4. NLP評価のモノカルチャー（英語中心主義）
NLPベンチマークにおける別の問題は、モノカルチャーが存在することです。これが意味するのは、主に私たち全員が英語だけを見ているということです。これは2021年か2022年の論文ですが、彼らはACL 2021（おそらくNLPで最も一般的な会議）のベストペーパー、つまり口頭発表論文を調査しました。
461の論文のうち、70%は英語のみを扱っており、40%は精度のみを見ていました。つまり、パフォーマンスだけです。多言語性や効率性、解釈可能性、公平性を見ている論文は非常に少ないのです。2008年の別の会議を分析した同様の論文がありますが、基本的に同じ結論でした。残念ながら、時間の経過とともに改善しているようには見えません。
実際には、多言語性のためのベンチマークは多数存在します。ここでいくつか紹介します。MEGA、GLUE-X、Xtremeはいずれも少なくとも30〜40の言語と多くの異なるタスクをカバーしています。ベンチマークがないわけではなく、これらのベンチマークで評価するインセンティブがアカデミアにないのです。もし機会があれば、これらのベンチマークを使用してください。
この英語中心主義の問題は、単にデータの問題だけではなく、より深刻です。例えば、BLEUやROUGEなどの評価指標は、単語の区切り方が分かることを前提としています。ベトナム語では単語の間にスペースがあり、タイ語には単語間にスペースがありません。そのため、BLEUやROUGEのような指標をどのように実行すれば良いのか分からないのです。これはデータだけの問題ではなく、私たちのアルゴリズムも実際に英語、少なくとも西洋言語に焦点を当てています。
この英語中心主義は、モデルの能力を評価する際に重大な盲点を生み出します。世界の大多数の人々は英語を第一言語としておらず、モデルが本当に役立つためには、多様な言語での性能が重要です。
多言語評価の重要性は、単に公平性の問題だけではありません。異なる言語構造を持つ言語でのテストは、モデルの一般的な言語理解能力を真に評価するためにも不可欠です。例えば、語順が異なる言語や、文法的性別がある言語、あるいは高度に屈折する言語での性能は、モデルの言語能力の重要な側面を明らかにします。
NLP評価のモノカルチャーを打破するためには、より多くの研究者が多言語ベンチマークを採用し、英語以外の言語での評価を標準的な実践にする必要があります。これにより、より包括的で公平、そして実用的な言語モデルの開発が促進されるでしょう。
9.5. 単一指標への還元問題
現在の評価方法のもう一つの問題は、すべてを単一の指標に還元してしまうことです。先ほど、スーパーベンチマークでのメトリクスの集計方法について言及しましたが、これらのスーパーベンチマークのいくつかでは実際に指標の集計方法が破綻しています。しかし、私たちはパフォーマンスだけを見ており、現実世界では計算効率も本当に重視しています。また、バイアスや他の多くの側面も気にしていますが、これらのベンチマークのほとんどはそれらを考慮していません。
さらに、通常は各例に同じ値、つまり同じ重みを与えて全ての例の平均を取ります。これはマイノリティグループにとって明らかに不公平ですが、それ以上に、例えば実運用に投入されるコードを書くというタスクと、最高のハンバーガーを買える場所についての日常的な質問に答えるタスクを考えてみましょう。これらの例から得られる価値は非常に異なります。しかし、現在の評価方法では、実際にこれを考慮していません。これは真の問題だと思います。
また、異なる人々は異なる好みを持っていることも考慮していません。
この問題に対するいくつかの解決策を紹介します。一つは計算効率を考慮することです。ML Perfは素晴らしいベンチマークで、特定のベンチマークでのパフォーマンスを最大化するのではなく、最短時間で一定のパフォーマンスを達成することを目標にします。これにより、トレーニングやインファレンスの両方において、精度とスピードの両方を考慮します。
バイアスについては、Anthropicが開発したDisRiMaLという優れたデータセットがあります。ここでは、保険を維持すべきかどうかなどの質問を含むテンプレートがあり、テンプレート内の人物の人種や性別を変えて、モデルの決定がどのように変化するかを観察します。残念ながらも予想通り、一部のグループは他のグループよりもはるかに差別されていることがわかります。
単一指標への還元は、モデルの実際の能力や有用性を正確に反映しない可能性があります。実世界での応用では、タスクの難易度、社会的影響、計算コスト、バイアス、使いやすさなど、多くの次元が重要です。これらの側面を無視して単一のスコアに頼ることは、モデルの真の価値を見誤る原因となりかねません。
より包括的な評価アプローチでは、複数の異なる観点からモデルを評価し、特定の用途や状況に応じて異なる側面に重みを付ける必要があります。例えば、医療分野での応用では安全性と正確性が最も重要かもしれませんが、消費者向けアプリケーションでは応答性とユーザーエクスペリエンスが優先されるかもしれません。
評価のあり方を進化させることで、より多面的で現実世界の要件に適合したモデル開発を促進することができるでしょう。
9.6. バイアスの問題
評価に関連するバイアスの問題は、NLPベンチマークにおいて非常に重要な課題です。まず言語的バイアスの問題があります。2021年から2022年の研究では、ACL 2021の優秀論文461本を分析したところ、70%が英語のみを扱っており、40%が精度のみを評価していました。2008年の別の会議でも同様の傾向が見られ、残念ながら時間とともに改善されていません。
実際には、多言語対応のベンチマークは多数存在します。例えば、XTREME、GLUE-X、Mega、Global Benchなどがあり、それぞれ30〜40の言語と多様なタスクをカバーしています。ベンチマークが存在しないわけではなく、むしろ学術界でこれらのベンチマークで評価するインセンティブがないのです。
また、すべてを単一のメトリックに還元する問題もあります。スーパーベンチマークでは、異なるメトリックを平均化する方法が本質的に壊れていることはすでに述べましたが、さらに性能だけに注目する問題があります。実際の世界では、計算効率やバイアス、その他の側面も重要ですが、ほとんどのベンチマークではこれらを考慮していません。
すべての例に同じ重みを与えて平均化することも問題です。これは少数派グループに対して不公平であるだけでなく、例えば実際に本番環境に投入されるコードを書くというタスクと、最高のハンバーガーショップを尋ねるような日常的な質問に答えるタスクでは、得られる価値が大きく異なります。現在の評価方法ではこれを考慮していません。また、異なる人々が異なる好みを持つことも考慮されていません。
これらの問題に対するいくつかの解決策として、ML Perf のようなベンチマークは計算効率も考慮しています。バイアスに関しては、Anthropicの DiscoEval のようなデータセットがあり、テンプレートの中で人種や性別を変更し、モデルの判断がどう変わるかを調査しています。残念ながら予想通り、特定のグループが他よりも差別される傾向があります。
言語的バイアスに関しては、BLEUやROUGEといった評価指標は単語を識別できることを前提としていますが、タイ語やベトナム語のような言語では、単語間のスペースの有無が異なるため、これらの指標を直接適用できません。評価アルゴリズム自体が英語や西洋言語に偏っているのです。
LLMベースの評価にもバイアスがあります。GPT-4を評価に使用することは便利ですが、GPT-4に一貫したバイアスがあれば、それがNLPコミュニティ全体に拡大されてしまう恐れがあります。最近の研究では、LLMが世論調査に対してどのような意見を反映しているかを調査しています。事前学習の段階では、モデルは特定のグループに最適化されていないものの、微調整後には特定の好みに最適化される傾向があります。典型的には、白人や東南アジア系の視点が反映される傾向があり、これは教師付き微調整やRHFに使用された人間のデータが東南アジア地域の人々によってラベル付けされたためと考えられます。
評価における最大の課題は、他の方法に移行するインセンティブがないことです。2019年から2020年の機械翻訳に関する論文を分析した研究では、82%の論文がBLEUスコアのみで評価していました。BLEUには多くの問題があり、より良い指標が存在するにもかかわらず、人々は他を見る動機がなく、査読者は通常BLEUスコアの提示を求めます。学術界が他のベンチマークに移行するのは難しいですが、実際の現場では指標に問題があれば単に変更すべきです。
最終的に、最良の評価は自分の出力を確認することです。単に数字を信じるのではなく、実際にモデルがどのように機能しているかを確認することが重要です。
10. 解決策と今後の方向性
10.1. 計算効率を考慮したベンチマーク
LLMの評価における多くの課題に対処するため、いくつかの具体的な解決策が提案されています。そのひとつが計算効率を考慮したベンチマークです。
ML Perfは特に注目すべきベンチマークで、単に性能を最大化するのではなく、特定の性能を最も短い時間で達成することを目標としています。このアプローチでは、精度だけでなく、トレーニングや推論の速度も評価の重要な要素となります。
これは実際の応用シナリオにおいて非常に重要です。実世界でのLLMの利用では、モデルの性能だけでなく、計算コスト、レイテンシー、リソース効率も考慮する必要があります。例えば、同じ精度を持つ二つのモデルがあった場合、より少ないコンピューティングリソースで動作するモデルの方が実用的です。
計算効率を評価に組み込むことで、研究者やエンジニアは単にモデルサイズやパラメータ数を増やすことだけに焦点を当てるのではなく、アルゴリズムの効率化やアーキテクチャの改善にも注力するようになります。これはより持続可能なAI開発への重要なステップであり、計算資源が限られている組織や国でのAI技術の民主化にも貢献します。
このような包括的なベンチマークアプローチは、現在のLLM評価における単一指標への依存という問題に対する重要な解決策の一つとなっています。
10.2. バイアス評価のためのデータセット
LLMのバイアス評価のために特別に設計されたデータセットが開発されています。特に注目すべきものとして、Anthropicが開発した「DiscoEval」があります。このデータセットは、保険を維持すべきかどうかなどの質問に関するテンプレートを使用しています。テンプレート内の人物の人種や性別などの属性を変更し、モデルの判断がどのように変化するかを測定します。
残念ながら、しかし予想通り、これらの評価では特定のグループが他のグループよりも差別される傾向があることが明らかになっています。このようなデータセットを使用することで、モデルの公平性の問題を明確に特定し、対処することが可能になります。
多言語バイアスの評価についても、XTREME、GLUE-X、Mega、Global Benchなどのベンチマークが存在し、30〜40もの言語と多様なタスクをカバーしています。しかし、これらのベンチマークを用いた評価を行うインセンティブが学術界に不足しているという問題があります。
また、「Whose Opinions Do LLMs Reflect」という研究も行われており、これはLLMの出力分布を世論調査と比較することで、モデルがデフォルトでどのグループの意見を反映しているかを調査しています。この研究では、事前学習の段階ではモデルは特定のグループに過度に最適化されていないものの、微調整後には特定の好みに最適化される傾向があることが判明しました。典型的には、モデルは白人および東南アジア系の視点を反映する傾向があります。これは、教師付き微調整やRHFに使用された人間のデータが主にこれらの地域の人々によってラベル付けされた可能性があるためと考えられています。
バイアス評価のためのこれらのデータセットとツールは、LLMの公平性と包括性を向上させるための重要なステップであり、研究者や開発者がモデルの限界をより深く理解し、改善するのに役立ちます。
10.3. 多言語評価の重要性
現在のNLP研究には言語的バイアスという深刻な問題があります。ACL 2021の優秀論文を分析した研究では、70%の論文が英語のみを対象としており、この傾向は2008年から改善されていません。これは研究の多様性と応用範囲を著しく制限しています。
多言語評価の問題は単に言語の多様性だけでなく、評価手法自体にも存在します。BlEUやROUGEのような標準的な評価指標は、単語の分割が明確な西洋言語を前提としています。例えば、タイ語は単語間にスペースがなく、ベトナム語は単語間にスペースがあるというように、言語によって基本的な構造が異なります。このような言語に対して既存の評価指標を適用することは困難であり、言語処理アルゴリズム自体が英語や西洋言語に偏っているという事実を示しています。
幸いなことに、XTREME、GLUE-X、Mega、Global Benchなどの多言語ベンチマークが存在し、30〜40の言語と多様なタスクをカバーしています。これらのベンチマークは言語の多様性を考慮した評価を促進するための重要なリソースです。問題は、これらを使用するインセンティブが学術界に不足していることです。
多言語評価の重要性は、今後AIの公平な普及を考える上で非常に重要です。世界人口の大部分は英語を母語としない人々であり、異なる言語構造を持つ言語に対応できるモデルと評価手法の開発が不可欠です。多言語対応を促進することで、言語技術へのアクセスにおける格差を減らし、より包括的なAIの発展を促進することができます。
研究コミュニティは、英語中心のパラダイムを超えて、真の多言語評価に移行するためのインセンティブ構造を再考する必要があります。これにはジャーナルや会議での多言語研究の価値付け、多言語データセットへのより良いアクセス、そして非英語圏の研究者との協力拡大が含まれるでしょう。
10.4. 学術分野における評価改善へのインセンティブ不足
評価における最も根本的な課題は、学術分野において評価方法を改善するインセンティブが不足していることです。2019年から2020年の機械翻訳に関する論文を調査した研究では、82%の論文がBLEUスコアのみで評価を行っていました。BLEUには多くの問題があり、より優れた評価指標が存在するにもかかわらず、研究者たちは従来の方法に固執し続けています。
この状況が続く理由の一つは、査読者が従来の評価指標（BLEUスコアなど）での結果提示を要求する傾向があるためです。研究者は自分の論文が受理されるために、問題があると知りながらも従来の指標を使用することを強いられます。また、2〜3年前の手法と比較できるようにするためには、同じ評価指標を維持する必要があるという現実的な理由もあります。
この状況は、学術界と産業界で異なる対応が見られます。産業界では、評価指標に問題があると認識したら簡単に切り替えることができますが、学術界では評価指標を変更することが難しい構造的な問題があります。特に、論文の比較可能性や再現性を維持するという学術界の要求が、新しい評価方法への移行を困難にしています。
さらに、新しい評価手法の開発は時間と労力を要するにもかかわらず、主要な貢献として認識されにくいという問題もあります。多くの研究者は、新しいモデルアーキテクチャや手法の開発に集中する方が、学術的評価や引用においてより大きな見返りがあると考えています。
この問題に対処するには、学術コミュニティ全体での意識改革が必要です。例えば、評価手法の革新を独立した研究貢献として正当に評価すること、評価の多様性を促進するジャーナルや会議の方針変更、そして産業界と学術界の協力を通じて実用的かつ厳密な評価基準を開発することなどが考えられます。
改善には時間がかかるかもしれませんが、モデルの真の進歩を測定するためには、評価方法そのものの進化が不可欠です。
11. 評価のまとめ
11.1. 異なる評価方法の特性
まず強調しておきたいのは、評価には様々な種類があり、それぞれ異なる特性や用途があるということです。私は講義の最初に機械学習モデルの開発ライフサイクルについて説明しました。モデルの訓練時、開発時、モデル選択時、そして実際のデプロイ時に必要な評価方法は異なります。
訓練時には、高速で安価、微分可能な評価指標が必要です。開発段階でも同様に高速で安価な指標が重要ですが、モデル選択段階になるとより高品質な指標が必要になり、デプロイ時には何よりも信頼性の高い評価が求められます。デプロイでは特定のタスクに最適化された絶対的な指標が必要であり、一度本番環境に投入すると戻すことができないため、信頼性は極めて重要です。
学術的なベンチマークでは、再現可能性と標準化が重視されます。なぜなら、次の5年、6年、あるいは10年間にわたって、研究者たちが同じベンチマークで評価を行うからです。学術的なメトリクスは完璧である必要はなく、長期的に見て改善の方向性を示せば十分です。また、ベンチマークの難易度と簡易さのバランスも重要で、あまりに複雑すれば誰も使用せず、単純すぎるとベースラインを超えるのが難しくなります。
次に、閉じたタスク（close-ended tasks）と開いたタスク（open-ended tasks）について説明しました。閉じたタスクでは限られた数の正解がありますが、開いたタスクでは多くの可能な正解があり、それぞれ異なる品質を持ちます。
閉じたタスクの評価は標準的な機械学習の手法を使用しますが、それでも注意が必要です。例えば、精度（accuracy）、適合率（precision）、再現率（recall）、F1スコアのどれを使うかは重要な選択です。また、複数のタスクを集約する方法や、ラベルの出所、さらには疑似相関（spurious correlations）の問題もあります。
開いたタスクの評価では、一般的にコンテンツ重複メトリクス（BLEU、ROUGEなど）、モデルベースのメトリクス（BERTScoreなど）、そして人間による評価が使われます。人間による評価は一般的にゴールドスタンダードとされていますが、コストや時間がかかり、評価者間の不一致や再現性の問題があります。
最近のLLMの評価では、GPT-4のような大規模言語モデルを使用して評価を行うアプローチが注目されています。私たちの研究では、GPT-4による評価は人間による評価よりも100倍速く、100倍安価で、しかも人間評価者同士の一致度よりも高い一致度を示しました。ただし、これはモデルが一貫性を持つ反面、バイアスも持つためです。
現在のLLM評価では、次の3つの主なアプローチがあります。1) パープレキシティ（訓練・検証損失の測定）、2) 様々なベンチマークスコアの平均値、3) モデル間の対戦形式（チャットボットアリーナなど）です。
最後に、現在の評価方法の課題として、一貫性の問題、コンタミネーション（学習データにテストデータが含まれる問題）、過学習、モノカルチャー（英語中心主義）、単一指標への還元、計算効率の無視、マイノリティグループの軽視などがあります。
結論として、評価においては数値だけを信じるのではなく、実際の出力を確認することが最も重要です。私たちがAlpacaを開発した際も、標準的なベンチマークではパフォーマンスが低くても、実際に使ってみると良いモデルだとわかったのです。評価指標は重要ですが、最終的には実際の使用感こそが真の評価になります。
11.2. 数値だけに頼らない実用的評価の重要性
評価において最も重要なことは、単に数値に頼るのではなく、実際のモデル出力を確認することです。多くの人々は数値だけを信じる傾向がありますが、これは危険な姿勢です。私たちがAlpacaを開発した初期段階では、Alpaca Evalの結果をある程度信じていましたが、実際にモデルを使ってみて初めて「これは良いモデルだ」と認識しました。標準的な学術ベンチマークではあまり良い結果を示していなかったにもかかわらずです。
実世界での評価においては、いくつかの重要な考慮点があります。まず、モデルの一貫性の問題です。同じ質問でも提示方法を少し変えるだけで（例えば選択肢のフォーマットを変更するなど）、モデルの回答や複数モデル間のランキングが変わってしまうことがあります。MLUのような単純に見えるベンチマークでも、実装の詳細によって大きく結果が変わる可能性があります。
次に、コンタミネーションの問題です。モデルが事前学習データにテストデータを含んでいると、不自然に高いパフォーマンスを示す可能性があります。特に、クローズドソースモデルではこれを検証することが難しいです。
また、人間の介入も重要です。モデルの評価結果を実際に確認し、質的な判断を加えることで、数値だけでは捉えられない側面を評価できます。ただし、この過程で評価者自身のバイアスが入り込む可能性もあるため、バランスが重要です。
LLMベースの評価（GPT-4などを使用）は効率的ですが、同じモデルが評価に使われることでのバイアスや「モノカルチャー」の問題も考慮すべきです。一つの解決策は、単純に「この回答は良いですか？」と尋ねるのではなく、詳細な評価基準を提供することです。これは教授が採点基準を作成し、ティーチングアシスタントがそれに従って採点するのと同様のアプローチです。
最終的に、様々な評価手法を組み合わせ、数値だけでなく実際の出力品質や使用者の体験も含めた包括的な評価が、実用的なモデル開発には不可欠です。
Stanford CS224N: NLP with Deep Learning | Spring 2024 | Lecture 11 - Benchmarking by Yann Dubois
For more information about Stanford's online Artificial Intelligence programs visit: https://stanford.io/ai This lecture covers: 1. Different reasons for measuring performance 2. Text Classification / Close-ended 3. Text Generation / Open-ended a. Automatic Evaluation b. Human Evaluation 4. Current evaluations of LLMs 5. Issues and challenges with evaluations To learn more about enrolling in this course visit: https://online.stanford.edu/courses/cs224n-natural-language-processing-deep-learning To follow along with the course schedule and syllabus visit: hhttps://web.stanford.edu/class/archive/cs/cs224n/cs224n.1246/ Yann Dubois Stanford University PhD Student in Machine Learning Professor Christopher Manning Thomas M. Siebel Professor in Machine Learning, Professor of Linguistics and of Computer Science Director, Stanford Artificial Intelligence Laboratory (SAIL)
youtu.be
