• 2025-03-10: Swallow LLM Leaderboardとしてリニューアル公開しました。MATHベンチマークを追加しました。
• 2024-07-01: 前身である日本語LLM評価を公開

評価の実行環境が多様

Swallowプロジェクトでは、大規模言語モデルの評価のため、AI Bridging Clud Infrastructure (ABCI) のAノード（NVIDIA A100）の他、東京工業大学のTSUBAME 4.0 (NVIDIA H100)、岡崎研究室内の計算サーバ（NVIDIA RTX A6000 Ada, A6000）、横田研究室内の計算サーバ（NVIDIA A100, RTX 6000 Ada, A6000など）が使われています。まとまった大規模なGPU計算資源は大規模言語モデルの学習に割り当てることになりますので、モデルの評価は学習環境の予備ノードや、クラウド計算環境の通常利用枠、研究室内の計算資源などでやりくりをします。さらに、規模の異なる多数のモデルに対して、20～28個のタスクで評価を行いますので、評価実験は6名くらいの学生で分担しています。したがって、計算環境と評価者の掛け算で、20～30個の評価環境が使われることになります。

(J)HumanEvalの評価にdocker環境が必要

(J)HumanEvalでは、大規模言語モデルが生成したコードを実際に実行するため、dockerを用いてサンドボックス環境を作る必要があります。ところが、ABCIはdockerに対応していないため、(J)HumanEvalの評価は別の実行環境で行う必要がありました（ABCIでは代わりにsingularityが利用できますが、今回の評価実験では採用しませんでした）。

実行環境によって評価スコアが変動する

乱数シードの固定など、評価の再現性を担保するための対策を講じていますが、それでも実行環境によって評価スコアが変動することを観測しています。評価スコアの有効数字3桁目以降は、再現性の担保が困難な状況にあります。

実行環境によってエラーが発生する

XL-Sumのタスクで、以下のエラーに遭遇することがあります。

  File "/.../.venv_harness_jp/lib/python3.10/site-packages/transformers/models/llama/modeling_llama.py", line 1184, in forward
    logits = logits.float()
RuntimeError: CUDA error: unspecified launch failure
CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1.
Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.

この問題はtransformersのversionを上げることで解決しました。

Llama 3にはtransformers 4.40.0以降が必要

Llama 3に対応したtransformersのバージョンは4.40.0以降です。そのため、評価を行うときは、評価担当者のtransformersのバージョンが4.40.0以降になるように指定する必要がありました。また、4.39.3以前のtransformersはLlama 3のtokenizer.jsonを正しく扱えないため、学習データのトークン化もtransformersのバージョンが4.40.0以降を使う必要があり、学習データの準備のやり直しが発生しました。

稀に評価が途中でハングアップする

評価タスクの実行が途中で止まってしまうことがあります。正確には、特定のモデル、タスク、事例において、モデルの出力が停止し、いつまでたっても評価が終わらないという状況に遭遇することがあります。この現象は実行環境を変えると解消することがあるため、Pythonやtransformersのバージョンによる微妙な挙動の違いを疑っていますが、現段階では原因を特定できていません。

GPUのメモリ不足によるエラー

評価したいモデルのサイズやタスクによっては、メモリ不足（out of memory）が発生することがあります。このような場合は、バッチサイズを下げる必要があり、時にはバッチサイズを1に設定することもあります。ところが、それでもメモリ不足が解消しないことがあり、そのような場合はより多くのメモリを積んだGPUの実行環境に変更するなど、対処が必要になります。

評価のジョブが打ち切られる

Swallowプロジェクトではたくさんの評価実験を行っていますが、自分たちが開発しているモデルのハイパーパラメータ調整の実験では、評価結果をできるだけ早く知りたい場合があります（本実験にできるだけ早く移行したいため）。逆に、他で開発されたモデルの評価は、さほど急ぐ必要がありません。このように、評価実験にも優先度があります。ところで、ABCIにジョブを投入する場合、実行時間を短く指定した方がジョブが早く実行されます。ABCIは大変混雑していますので、評価実験を行う担当者は、各タスクの評価実験にかかる実行時間を予測し、ジョブの投入時に経過時間制限値を設定します。ところが、何らかの要因で評価タスクの実行時間が長くなってしまうと、無慈悲にも設定した経過時間でジョブの実行が打ち切られ、評価実験が未完了となります。一部の評価タスクでは、評価中に結果をキャッシュしておくことで、ジョブの実行が打ち切られた場合でも続きから評価が再開できるような対策を講じました。

MT-Benchの評価でOpenAIのAPIを呼び出すときにRateLimitErrorが発生した

MT-Benchの評価では、GPT-4のAPIを呼び出す必要があります。MT-Benchの評価を並列で実行すると、OpenAI APIのRateLimitErrorが高頻度で発生し、retry回数の上限を超えてしまい正しく評価が行えないことがありました。FastChatの実装では、retry回数の上限を超えた際はエラーを出すのではなくスコアを-1として記録するため、最終結果のスコアを見るだけでは気づきにくい状況にありました。最終的にはretryの処理を工夫することで、この問題に対処しました。

一部のモデルの評価が正しく行えない

他で開発されたモデルを評価しているとき、過去に自分たちで実施した評価や外部のリーダーボードの評価を大幅に下回るスコアに出くわすことがありました。このようなことが複数のモデルにおいて発生するうえ、その現象を引き起こし得る原因がいくつも考えられる（先ほどのtransformersのバージョンによる動作の違い、評価ソフトウェアのバージョンアップに伴うプロンプトの違い等）ため、評価スコア低下の原因を特定し、デバッグをするのは困難です。そこで、モデルの評価で問題が発生した場合は、Swallowプロジェクトで開発しているモデルと規模や性能で競合する場合だけ原因を特定し修正することにし、競合しないと思われるモデルの評価は優先順位を下げ、場合によっては断念しました。

確率的デコーディングが意図せずに使われていた

2024年度のSwallowプロジェクトで採用している評価フレームワークで初代Swallowモデルの評価をやり直したとき、いくつかのタスクで以前よりも10ポイントくらい低いスコアが出ることがありました。これは、論文やウェブサイト等で報告していたスコアが間違っている可能性を示唆していますので、我々にとって深刻な問題です。結局、この現象は評価ソフトウェアのバージョンアップに伴う初期設定の変更によるものでした。

大規模言語モデルで出力を予測するときは、出力単語の確率分布を計算して、確率の高い単語を選びます。このとき、最も高い確率が計算された単語を出力するのが基本ですが、出力の多様性を高めるため、大規模言語モデルの応用では確率分布に従って単語をサンプリングする手法（確率的デコーディング）が用いられます。ところが、確率的デコーディングを多値選択式質問応答の回答生成に使ってしまうと、（よくデキるモデルでは）正解率が下がります。例えば、「はい」「いいえ」の２択問題を解いているとき、言語モデルが「はい」の確率を80%、「いいえ」の確率を20%と予測した状況を考えましょう。「はい」という答えに比較的自信を持っているようですので、「はい」と答えるのが合理的ですが、確率的デコーディングでは20%の確率で「いいえ」と答えることになります。つまり、回答にある程度自信を持っていたとしても、それとは異なる回答をわざと行うことになります。

出力単語の確率分布の形状は温度パラメータによって変わりますし、大規模言語モデルによっては推奨される温度パラメータがモデルの設定ファイルで指定されていることがあります。評価スコアを安定させるためには、（コード生成や対話などの生成系のタスクを除き）多値選択式のタスクでは確率的デコーディングを使わず、貪欲的デコーディング（最も高い確率が計算された単語を出力すること）を採用することが望ましいです。そのため、大規模言語モデルの評価ソフトウェアでは、しばしば貪欲デコーディングを大規模言語モデルに強制することがあります。我々が経験したケースでは、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をそれぞれ異なる単独のトークンにエンコードしており、この扱いかたに原因があるのかもしれません。

HumanEval, JHumanEvalの元々のデータでは、プロンプトの末尾に改行が付加されています。ところが、Code Generation LM Evaluation Harnessのデフォルトの実行条件では末尾の改行が除去されます。正確には、末尾の改行を除去するか否かを選べるようになっています（ --tasks=humaneval-unstripped を指定すると除去されません）。先に説明した通り、改行の有無でコード生成が変わる問題はトークン化に起因するものと考えられ、実際に多くのモデルではどちらでもかまわないようです。しかし評価の条件をそろえるのが望ましいという原則を鑑みて、(J)HumanEvalは改行を付与するように修正してすべてのモデルを再評価しました。

なお PLaMo 2 8B の場合は、改行を付与しない場合のHumanEval, JHumanEvalがそれぞれ 0.470 と 0.397 で、改行を付与した場合の 0.260 と 0.213 に対して約20ptのスコア差がありました。評価の条件をそろえる原則を鑑みて、一覧表には改行を付与した場合のスコアを表記しています。

生成の冒頭に改行を出力するモデルがある

Sarashina2 7Bと13Bをllm-jp-evalで評価しているとき、特定のタスクで評価スコアが0点になることに気づきました。これは、モデルが生成の冒頭に改行文字\nを出力することが原因で、JMMLUのように出力の完全一致で評価するタスクでは致命的です。Swallowプロジェクトの評価実験では、Sarashina2の出力に対して空白や改行を除去する処理を追加して評価を行っています。

OpenAI系列モデルの評価設定

GPT-3.5やGPT-4oなどのOpenAI系列モデルは、一部のタスクにおいて通常とは異なる設定のもとで評価を実施しています。

改行文字の取り扱い

MGSMでは、通常、改行文字を文終了トークン（EOSトークン）として扱います。しかし、OpenAI系列モデルはfew-shotの事例を無視して、回答文内に改行を頻繁に挿入する傾向があります。そのため、通常の設定では回答が途中で切れてしまい、スコアが大きく低下します。この問題を防ぐために、OpenAI系列モデルの評価においては改行文字をEOSトークンとして使わないようにしました。

コード生成タスクの処理方法

(J)HumanEvalでは、出力文からコードのみを取り出して動作をテストする必要があります。このため、simple-evalsに倣い、モデルがコードのみを生成するようにプロンプトを調整しました。さらに、出力文からコードブロックのみを抽出する後処理を追加しました。

尤度ベースの評価タスクの扱い

OpenBookQAなど、尤度を用いて回答の選択肢を選ぶタスクについては、OpenAI系列モデルの評価を行いませんでした。これは、OpenAIのAPIからではモデルが計算する文の尤度を取得できないためです。
HELMを参考にして、尤度による選択ではなく回答を直接生成する代替策を検討しましたが、OpenAI系列以外のモデルでは尤度方式と回答生成方式によるスコアの乖離が顕著でした。したがって公平な比較が困難であると判断し、評価を見送ることとしました。

「思考の深い」推論型モデルは従来の評価方法では過小評価になる場合がある

Swallowプロジェクトでは、事前学習済み言語モデル（いわゆるbaseモデル）と指示チューニング後のモデル（いわゆるchatモデル）を同一の評価方法で比較できるように、Few-shot学習による短答を標準的な評価手法としています。具体的には、たとえば {設問1}: {回答1} … {設問N}: のようなプロンプトを与えて、次に続く文字（4択問題なら A/B/C/D いずれかの1文字）を予測させる方法です (Brown et al., 2020)。この手法は、基礎能力や指示追従能力がまだ低かった初期のLLMを想定して開発され、現在も広く利用されています (Biderman et al., 2024) 。

一方、OpenAI o1やDeepSeek-R1 (DeepSeek-AI, 2025) などの推論型モデルは まず○○を考えます。次に[...]。いやしかし[...]。むしろ△△なら[...]。よって答えは××です。 のように、内省や自問に似た深い思考過程を出力したのちに回答を導くという特徴があります。推論型モデルは数学や科学の高度な問題に強いとされており、これらの推論能力は指示チューニングなどの事後学習によって獲得されると考えられています。また事後学習では、<user>{設問}</user><assistant>{回答}</assistant> のようにユーザ指示と回答を専用のタグで囲む「chat template」の形式で微調整を行うのが一般的です。

Swallowプロジェクトでは、事前学習モデルと事後学習モデルを比較しやすくするため、指示チューニング後のモデルについてもchat templateなし、Few-shot学習による短答、貪欲法による文生成という評価手法を主に用いてきました（CoTプロンプトやzero-shot推論を用いるベンチマークもあります）。しかし、推論型モデルを数学や科学の難しい問題に適用する際は、この手法では十分に性能を引き出せない場合があることがわかっています。たとえば、DeepSeek-R1をLlama 3.1で模倣したDeepSeek-R1-Distill-Llama-8BにMATHベンチマーク（高校生レベルの数学）を解かせたところ、Swallowプロジェクトの評価手法では正答率が約70%でした。しかし、chat templateを適用し、zero-shot推論と確率的デコーディングで回答させた場合の正答率は約90%であり、20ポイントもの差が生じました。またリーダーボードには未採用ですが、博士課程レベルの科学問題を集めたGPQAベンチマークでも、同じく正答率が20～25ポイントほど向上することがわかりました。

以上のように、推論型モデルを用いた難しいタスクの評価においては、従来の評価手法よりも、思考過程を自由に出力させる手順やzero-shot推論などの手法が適切な場合があると考えられます。公平性の観点からすべてのモデルを統一的な手法で評価すべきである一方で、推論能力の過小評価を避けるべきと考えて、今回（2025年3月現在）は推論型モデルの評価結果を公表しないことにしました。
推論能力の獲得や汎化はAIのフロンティアを研究する上でも極めて興味深いテーマであり、その性能を正しく評価することも重要です。Swallowプロジェクトでは、モデル間の比較可能性や公平性に留意しながら、上記の評価手法や推論能力に適したベンチマークの導入について、今後も検討を続けていきます。

• Tabler Admin Template licensed under MIT License
• ApexCharts licensed under MIT License
• Swallow icon by Game Icons.net in CC Attribution License via SVG Repo
• The research and development of the large language model Swallow has been supported by the AIST Project "Research and Development on Generative AI Foundation Models in the Physical Domain"