Evaluating LLMs with Multiple Problems at once

生成日: 2026-05-24 02:20

# Evaluating LLMs with Multiple Problems at once

- LLM に複数の問題を一つのプロンプトで解かせる multi-problem evaluation（MPE）を、ゼロショット設定で体系的に調べた論文である。
- 既存の 6 つの分類ベンチマークと 12 の推論ベンチマークから、53,100 件の multi-problem prompt を持つ ZeMPE を構成している。
- 同じデータソースから来た複数問題はおおむね扱えるが、分類をインデックス選択へ言い換えた場合や、異なる出所の推論問題を混ぜた場合には性能が下がる。

## Abstract（日本語訳）

本論文は、複数の問題を一度に用いて LLM を評価することの利点と有用性を示す。この評価形式を、著者らは multi-problem evaluation（MPE）と呼ぶ。従来の single-problem evaluation では、プロンプトに一つの問題を提示し、その問題に対する一つの特定の答えを期待する。これに対して MPE では、複数の問題を一つのプロンプトにまとめ、LLM が一つの出力の中でそれらすべてにどの程度答えられるかを評価する。著者らは、既存の 6 つの分類ベンチマークと 12 の推論ベンチマークを利用し、53,100 件のゼロショット multi-problem prompt から成る ZeMPE（Zero-shot Multi-Problem Evaluation）という新しいベンチマークを導入する。ZeMPE 上で、5 つのモデルファミリーに属する計 13 個の LLM を実験し、包括的かつ体系的な MPE を提示する。結果は、LLM が同一データソースからの複数問題を、個別に扱う場合と同程度に処理できることを示す一方で、この複数問題処理能力が不足する条件もあることを示している。さらに著者らは、詳しい追加分析を行い、LLM における複数問題処理能力を可能にしていると考えられるモデルレベルの要因を探る。今後の研究を促すため、コーパスとコードも公開する。

## 論文の面白いところ

長いコンテキストを持つ LLM では、一つの指示文の後に複数の問題を並べて処理させる使い方が自然に行われる。従来は、この使い方を主にコスト削減の手段として見る研究が多かった。本論文は、それを評価方法そのものとして扱う。単に「まとめて聞けば安い」という話ではなく、モデルが複数の独立した問題を一つの出力空間で保持し、各位置の情報をどの程度乱さずに使えるかを調べている。ここで興味深いのは、分類問題を普通に行ごとに答えさせると大きな劣化は少ないのに、同じ情報を「該当する行番号を選べ」と言い換えると成績がかなり落ちる点である。人間なら少数の文を分類することと、分類済みの文の番号をまとめることはほぼ同じ作業に見える。しかし LLM では、出力形式と計画の立て方が性能を左右する。これは、LLM の評価を実運用に近づけるうえで扱いやすい観察である。モデルが長い入力を読めることと、複数の小さな課題を安定して管理できることは同じではない。

## 問題設定

この論文が扱う問題は、LLM を一問ずつではなく、複数問を一つのプロンプトに入れて評価することである。著者らは、一問ずつ評価する従来形式を single-problem evaluation（SPE）、複数問をまとめる形式を multi-problem evaluation（MPE）と呼ぶ。MPE は multi-problem prompting（MPP）を評価に用いたものであり、MPP 自体はコスト削減や一括処理にも使われる。MPE の利点の一つは、既存のベンチマークを組み合わせるだけで、新しい組合せの評価データを作れることである。複数の問題を組み合わせるため、事前学習データにまったく同じプロンプトが含まれている可能性も下がる。さらに、問題の数、位置、出所を制御できるため、どの条件で誤りが増えるかを調べやすい。著者らは、分類と推論を混ぜず、それぞれ別に評価している。これは、分類と推論では出力形式も問題の性質も異なり、混ぜると原因の切り分けが難しくなるためである。

## 提案手法

著者らは ZeMPE（Zero-shot Multi-Problem Evaluation）というベンチマークを作成した。ZeMPE は、6 つの分類ベンチマークと 12 の推論ベンチマークから作られる。分類側では SST-2、CoLA、AGNews、MRPC、SNLI、WiC を使い、感情分析、文法性判定、ニュース分類、言い換え判定、自然言語推論、語義判別を含めている。推論側では StrategyQA、Coin Flips、CommonsenseQA、GSM8K などを用い、常識推論、記号推論、算術推論を扱う。分類タスクでは、通常の一問分類である SingleClf、複数文を行ごとに分類する BatchClf、特定ラベルに属する行番号を選ぶ SelectOne、全ラベルについて行番号をまとめて選ぶ SelectAll を比較する。推論タスクでは、同じベンチマークから複数問をまとめる MultiReasonSS と、異なるベンチマークから問題を混ぜる MultiReasonMS を設定する。評価指標は per-problem accuracy（PPA）であり、一つの multi-problem prompt に含まれる各問題を個別に採点して平均する。分類実験では Vicuna、Mistral、Mixtral、Llama-3、GPT-3.5、GPT-4 などを使い、推論実験では主に GPT-3.5 と Llama-3 70B を用いる。追加分析では、instruction tuning、モデルサイズ、アーキテクチャの違いが MPP に与える影響も調べている。

## 結果

分類では、BatchClf の性能は SingleClf より少し下がるが、多くの場合は大きく崩れない。7 つの LLM を 6 つの分類ベンチマークで平均すると、SingleClf の正解率は 75.5%、BatchClf は 72.3% であり、差は 3.2 ポイントであった。タスク数が増えるほど入力指示を使い回せるため、BatchClf はコスト対性能の点で有利になりやすい。著者らの試算では、SingleClf の少なくとも 95% の精度を保てる最大バッチサイズを選ぶと、推論コストは 30.7% から 82.0% 減った。一方で、同じ分類内容を行番号選択として解かせる SelectOne と SelectAll では性能が明確に落ちる。BatchClf と SelectOne の平均正解率差は 32.0 ポイント、BatchClf と SelectAll の差は 12.1 ポイントで、いずれも大きな差であった。推論では、同じデータソースから来た複数問題をまとめる MultiReasonSS は、個別に解く場合と同程度か、それ以上になる場合もあった。しかし異なるデータソースの推論問題を混ぜる MultiReasonMS では、期待値より低い性能になる場合が多かった。追加分析では、BatchClf の誤り分布は SingleClf とよく似ており、入力内の位置による明確な偏りも少ないことが示されている。モデル要因としては instruction tuning が特に重要で、ベースモデルや FLAN-T5 系は multi-problem prompt への応答が不安定になりやすかった。

## 具体例

たとえば、感情分析の評価で、映画レビューの短い文を 5 行まとめて LLM に渡す場面を考える。入力には「各行の sentiment を Positive または Negative で答えよ」という指示が一度だけ書かれ、その下に 1 番から 5 番までの文が並ぶ。BatchClf では、モデルは 1 行目から 5 行目までに対応して、Positive、Negative、Positive のように行ごとのラベルを順に出す。この形式では、論文中の多くのモデルは一問ずつ聞いた場合に近い正解率を保った。ところが同じ 5 行について、「Positive の文の番号を JSON で列挙せよ」と尋ねる SelectOne では、モデルは 2 番を Negative と判断しているはずなのに Positive 側にも入れる、といった矛盾を起こしやすくなる。さらに、どのラベルにも入れない行が出ることもある。分類そのものを誤るだけでなく、複数の対象を集合として管理する段階で失敗しているのである。実際の一括レビュー分類や問い合わせ分類でも、ラベルを行ごとに返させるのか、ラベル別の ID リストとして返させるのかで、同じモデルの信頼性が変わりうる。

Evaluating LLMs with Multiple Problems at once

LLM に複数の問題を一つのプロンプトで解かせる multi-problem evaluation（MPE）を、ゼロショット設定で体系的に調べた論文である。
既存の 6 つの分類ベンチマークと 12 の推論ベンチマークから、53,100 件の multi-problem prompt を持つ ZeMPE を構成している。
同じデータソースから来た複数問題はおおむね扱えるが、分類をインデックス選択へ言い換えた場合や、異なる出所の推論問題を混ぜた場合には性能が下がる。

Abstract（日本語訳）

本論文は、複数の問題を一度に用いて LLM を評価することの利点と有用性を示す。この評価形式を、著者らは multi-problem evaluation（MPE）と呼ぶ。従来の single-problem evaluation では、プロンプトに一つの問題を提示し、その問題に対する一つの特定の答えを期待する。これに対して MPE では、複数の問題を一つのプロンプトにまとめ、LLM が一つの出力の中でそれらすべてにどの程度答えられるかを評価する。著者らは、既存の 6 つの分類ベンチマークと 12 の推論ベンチマークを利用し、53,100 件のゼロショット multi-problem prompt から成る ZeMPE（Zero-shot Multi-Problem Evaluation）という新しいベンチマークを導入する。ZeMPE 上で、5 つのモデルファミリーに属する計 13 個の LLM を実験し、包括的かつ体系的な MPE を提示する。結果は、LLM が同一データソースからの複数問題を、個別に扱う場合と同程度に処理できることを示す一方で、この複数問題処理能力が不足する条件もあることを示している。さらに著者らは、詳しい追加分析を行い、LLM における複数問題処理能力を可能にしていると考えられるモデルレベルの要因を探る。今後の研究を促すため、コーパスとコードも公開する。

論文の面白いところ

長いコンテキストを持つ LLM では、一つの指示文の後に複数の問題を並べて処理させる使い方が自然に行われる。従来は、この使い方を主にコスト削減の手段として見る研究が多かった。本論文は、それを評価方法そのものとして扱う。単に「まとめて聞けば安い」という話ではなく、モデルが複数の独立した問題を一つの出力空間で保持し、各位置の情報をどの程度乱さずに使えるかを調べている。ここで興味深いのは、分類問題を普通に行ごとに答えさせると大きな劣化は少ないのに、同じ情報を「該当する行番号を選べ」と言い換えると成績がかなり落ちる点である。人間なら少数の文を分類することと、分類済みの文の番号をまとめることはほぼ同じ作業に見える。しかし LLM では、出力形式と計画の立て方が性能を左右する。これは、LLM の評価を実運用に近づけるうえで扱いやすい観察である。モデルが長い入力を読めることと、複数の小さな課題を安定して管理できることは同じではない。

問題設定

この論文が扱う問題は、LLM を一問ずつではなく、複数問を一つのプロンプトに入れて評価することである。著者らは、一問ずつ評価する従来形式を single-problem evaluation（SPE）、複数問をまとめる形式を multi-problem evaluation（MPE）と呼ぶ。MPE は multi-problem prompting（MPP）を評価に用いたものであり、MPP 自体はコスト削減や一括処理にも使われる。MPE の利点の一つは、既存のベンチマークを組み合わせるだけで、新しい組合せの評価データを作れることである。複数の問題を組み合わせるため、事前学習データにまったく同じプロンプトが含まれている可能性も下がる。さらに、問題の数、位置、出所を制御できるため、どの条件で誤りが増えるかを調べやすい。著者らは、分類と推論を混ぜず、それぞれ別に評価している。これは、分類と推論では出力形式も問題の性質も異なり、混ぜると原因の切り分けが難しくなるためである。

提案手法

著者らは ZeMPE（Zero-shot Multi-Problem Evaluation）というベンチマークを作成した。ZeMPE は、6 つの分類ベンチマークと 12 の推論ベンチマークから作られる。分類側では SST-2、CoLA、AGNews、MRPC、SNLI、WiC を使い、感情分析、文法性判定、ニュース分類、言い換え判定、自然言語推論、語義判別を含めている。推論側では StrategyQA、Coin Flips、CommonsenseQA、GSM8K などを用い、常識推論、記号推論、算術推論を扱う。分類タスクでは、通常の一問分類である SingleClf、複数文を行ごとに分類する BatchClf、特定ラベルに属する行番号を選ぶ SelectOne、全ラベルについて行番号をまとめて選ぶ SelectAll を比較する。推論タスクでは、同じベンチマークから複数問をまとめる MultiReasonSS と、異なるベンチマークから問題を混ぜる MultiReasonMS を設定する。評価指標は per-problem accuracy（PPA）であり、一つの multi-problem prompt に含まれる各問題を個別に採点して平均する。分類実験では Vicuna、Mistral、Mixtral、Llama-3、GPT-3.5、GPT-4 などを使い、推論実験では主に GPT-3.5 と Llama-3 70B を用いる。追加分析では、instruction tuning、モデルサイズ、アーキテクチャの違いが MPP に与える影響も調べている。

結果

分類では、BatchClf の性能は SingleClf より少し下がるが、多くの場合は大きく崩れない。7 つの LLM を 6 つの分類ベンチマークで平均すると、SingleClf の正解率は 75.5%、BatchClf は 72.3% であり、差は 3.2 ポイントであった。タスク数が増えるほど入力指示を使い回せるため、BatchClf はコスト対性能の点で有利になりやすい。著者らの試算では、SingleClf の少なくとも 95% の精度を保てる最大バッチサイズを選ぶと、推論コストは 30.7% から 82.0% 減った。一方で、同じ分類内容を行番号選択として解かせる SelectOne と SelectAll では性能が明確に落ちる。BatchClf と SelectOne の平均正解率差は 32.0 ポイント、BatchClf と SelectAll の差は 12.1 ポイントで、いずれも大きな差であった。推論では、同じデータソースから来た複数問題をまとめる MultiReasonSS は、個別に解く場合と同程度か、それ以上になる場合もあった。しかし異なるデータソースの推論問題を混ぜる MultiReasonMS では、期待値より低い性能になる場合が多かった。追加分析では、BatchClf の誤り分布は SingleClf とよく似ており、入力内の位置による明確な偏りも少ないことが示されている。モデル要因としては instruction tuning が特に重要で、ベースモデルや FLAN-T5 系は multi-problem prompt への応答が不安定になりやすかった。

具体例

たとえば、感情分析の評価で、映画レビューの短い文を 5 行まとめて LLM に渡す場面を考える。入力には「各行の sentiment を Positive または Negative で答えよ」という指示が一度だけ書かれ、その下に 1 番から 5 番までの文が並ぶ。BatchClf では、モデルは 1 行目から 5 行目までに対応して、Positive、Negative、Positive のように行ごとのラベルを順に出す。この形式では、論文中の多くのモデルは一問ずつ聞いた場合に近い正解率を保った。ところが同じ 5 行について、「Positive の文の番号を JSON で列挙せよ」と尋ねる SelectOne では、モデルは 2 番を Negative と判断しているはずなのに Positive 側にも入れる、といった矛盾を起こしやすくなる。さらに、どのラベルにも入れない行が出ることもある。分類そのものを誤るだけでなく、複数の対象を集合として管理する段階で失敗しているのである。実際の一括レビュー分類や問い合わせ分類でも、ラベルを行ごとに返させるのか、ラベル別の ID リストとして返させるのかで、同じモデルの信頼性が変わりうる。