Merge branch 'main' of github.com:swallow-llm/evaluation

swallow-llm · Jun 29, 2024 · d55c824 · d55c824
2 parents cda62d8 + d76c205
commit d55c824
Showing 1 changed file with 5 additions and 5 deletions.
diff --git a/about.ja.md b/about.ja.md
@@ -289,23 +289,23 @@ MT-Benchの評価では、GPT-4のAPIを呼び出す必要があります。MT-B
 
 ### 確率的デコーディングが意図せずに使われていた
 
-2024年度のSwallowプロジェクトで採用している評価フレームワークで初代Swallowモデルの評価をやり直したとき、いくつかのタスクで以前の評価スコアよりも10ポイントくらい低いスコアが出ることがありました。これは、論文やウェブサイト等で報告していたスコアが間違っている可能性を示唆していますので、我々にとって深刻な問題です。結局、この現象は評価ソフトウェアのバージョンアップに伴う仕様変更によるもので、自分たちの評価のミスではありませんでした。
+2024年度のSwallowプロジェクトで採用している評価フレームワークで初代Swallowモデルの評価をやり直したとき、いくつかのタスクで以前よりも10ポイントくらい低いスコアが出ることがありました。これは、論文やウェブサイト等で報告していたスコアが間違っている可能性を示唆していますので、我々にとって深刻な問題です。結局、この現象は評価ソフトウェアのバージョンアップに伴う初期設定の変更によるものでした。
 
 大規模言語モデルで出力を予測するときは、出力単語の確率分布を計算して、確率の高い単語を選びます。このとき、最も高い確率が計算された単語を出力するのが基本ですが、出力の多様性を高めるため、大規模言語モデルの応用では確率分布に従って単語をサンプリングする手法（確率的デコーディング）が用いられます。ところが、確率的デコーディングを多値選択式質問応答の回答生成に使ってしまうと、（よくデキるモデルでは）正解率が下がります。例えば、「はい」「いいえ」の２択問題を解いているとき、言語モデルが「はい」の確率を80%、「いいえ」の確率を20%と予測した状況を考えましょう。「はい」という答えに比較的自信を持っているようですので、「はい」と答えるのが合理的ですが、確率的デコーディングでは20%の確率で「いいえ」と答えることになります。つまり、回答にある程度自信を持っていたとしても、それとは異なる回答をわざと行うことになります。
 
-出力単語の確率分布の形状は温度パラメータによって変わりますし、大規模言語モデルによっては推奨される温度パラメータが設定ファイルで指定されていることがあります。評価スコアを安定させるためには、（翻訳や要約などの生成系のタスクを除き）多値選択式のタスクでは確率的デコーディングを使わず、貪欲的デコーディング（最も高い確率が計算された単語を出力すること）を採用することが望ましいです。そのため、大規模言語モデルの評価ソフトウェアでは、しばしば貪欲デコーディングを大規模言語モデルに強制することがありますが、バージョンアップに伴い、その強制が脱落していることがあります。我々が経験したケースでは、llm-jp-evalのv1.0.0では温度パラメータとして0.1が強制されていたため、貪欲デコーディングに近い状態になっていましたが、v1.3.0でその強制が撤廃されたため、モデルのデフォルト設定により確率的デコーディングが使われ、特定のタスクの評価スコアが低下しました。この問題のため、日本語の理解・生成タスクで評価のやり直しが発生しました。
+出力単語の確率分布の形状は温度パラメータによって変わりますし、大規模言語モデルによっては推奨される温度パラメータがモデルの設定ファイルで指定されていることがあります。評価スコアを安定させるためには、（コード生成や対話などの生成系のタスクを除き）多値選択式のタスクでは確率的デコーディングを使わず、貪欲的デコーディング（最も高い確率が計算された単語を出力すること）を採用することが望ましいです。そのため、大規模言語モデルの評価ソフトウェアでは、しばしば貪欲デコーディングを大規模言語モデルに強制することがあります。我々が経験したケースでは、llm-jp-eval v1.0.0では初期設定の温度パラメータが0.1だったため、貪欲デコーディングに近い状態になっていましたが、v1.3.0でその設定が削除されたため、確率的デコーディングがデフォルトになっているモデルでは、特定のタスクの評価スコアが低下しました。この問題を解決するため、貪欲デコーディングを強制するように修正してすべてのモデルを再評価しました。
 
 ### (J)HumanEvalではプロンプトの末尾に改行が必要だった
 
 Swallowプロジェクトでは2024年度からコード生成タスクをモデルの評価に採用しました。これは、コード生成タスクが大規模言語モデルの論理的思考力を鍛えると期待していることに加え、初代Swallowがコード生成タスクに弱かったことが理由です。
 
-ところが、Llama 3 Swallowの開発を進める中で、JHumanEvalやHumanEvalの評価スコアは8Bのモデルよりも70Bのモデルの方が悪いことに気づきました。Llama 3をHumanEvalで評価してみると、pass@1が0.28 (8B) および0.16 (70B) となり、8Bのモデルよりも70Bのモデルが苦戦しています。この問題を調査していくと、プロンプトの末尾が`"""\n`で終わるならコードが生成されますが、`"""`で終わる場合は`[EOS]`が生成され、コードが生成されない傾向があることが分かりました（三重引用符`"""`はPythonのドキュメンテーション文字列の開始と終了を表すことが多く、コード生成の指示やテストケースの末尾によく出現します）。さらに細かく調べていくと、Llama 3は`"""`, `[SPC]"""`, `[SPC]"""\n`, `[SPC]"""\n\n`をそれぞれ、一つのトークンとして扱うようで、これらを別物として扱うことに原因があるのかもしれません。
+ところが、Llama 3 Swallowの開発を進める中で、JHumanEvalやHumanEvalの評価スコアは8Bのモデルよりも70Bのモデルの方が悪いことに気づきました。Llama 3をHumanEvalで評価してみると、pass@1が0.28 (8B) および0.16 (70B) となり、8Bのモデルよりも70Bのモデルが苦戦しています。この問題を調査していくと、プロンプトの末尾が`"""\n`で終わるならコードが生成されますが、`"""`で終わる場合は`[EOS]`が生成され、コードが生成されない傾向があることが分かりました（三重引用符`"""`はPythonのドキュメンテーション文字列の開始と終了を表すことが多く、コード生成の指示やテストケースの末尾によく出現します）。さらに細かく調べていくと、Llama 3は`"""`, `[SPC]"""`, `[SPC]"""\n`, `[SPC]"""\n\n`をそれぞれ異なる単独のトークンにエンコードしており、この扱いかたに原因があるのかもしれません。
 
-HumanEval, JHumanEvalの元々のデータでは、コード生成の指示の末尾に改行が付加されています。ところが、Code Generation LM Evaluation Harnessの[実装](https://github.com/bigcode-project/bigcode-evaluation-harness/blob/main/bigcode_eval/tasks/humaneval.py#L64)において、データの末尾の空白文字を除去することがあります。正確には、末尾の空白文字を除去する処理がデフォルトで、`strip_prompt=False`を指定することでその処理を回避できます。先に説明した通り、この問題はモデルのトークン化の影響によるものと考えられますので、モデルによっては`strip_prompt=False`を指定しなくてもコードが生成されます。ところが、モデルの評価では実験条件をそろえるのが望ましいですので、(J)HumanEvalの評価を途中でやり直しました。
+HumanEval, JHumanEvalの元々のデータでは、プロンプトの末尾に改行が付加されています。ところが、Code Generation LM Evaluation Harnessのデフォルトの実行条件では末尾の改行が除去されます。正確には、末尾の改行を除去するか否かを選べるようになっています（ `--tasks=humaneval-unstripped` を指定すると除去されません）。先に説明した通り、改行の有無でコード生成が変わる問題はトークン化に起因するものと考えられ、実際に多くのモデルではどちらでもかまわないようです。しかし評価の条件をそろえるのが望ましいという原則を鑑みて、(J)HumanEvalは改行を付与するように修正してすべてのモデルを再評価しました。
 
 ### 生成の冒頭に改行を出力するモデルがある
 
-Sarashina 7Bと13Bをllm-jp-evalで評価しているとき、特定のタスクで評価スコアが0点になることに気づきました。これは、Sarashinaのモデルが生成の冒頭に改行文字`\n`を出力してしまうことが原因で、JMMLUのように出力の完全一致で評価するタスクでは致命的です。Swallowプロジェクトの評価実験では、Sarashinaの出力に対して空白文字の除去を行い処理を追加し、評価を行っています。
+Sarashina2 7Bと13Bをllm-jp-evalで評価しているとき、特定のタスクで評価スコアが0点になることに気づきました。これは、モデルが生成の冒頭に改行文字`\n`を出力することが原因で、JMMLUのように出力の完全一致で評価するタスクでは致命的です。Swallowプロジェクトの評価実験では、Sarashina2の出力に対して空白や改行を除去する処理を追加して評価を行っています。
 
 ## 謝辞