LLM評価

評価は、厳密な機械学習パイプラインの基盤です。それにもかかわらず、大規模言語モデルの開発では最も過小評価されている要素かもしれません。正解ラベル付きのホールドアウトテストセットが明確な信号を与える古典的な教師あり学習とは異なり、LLMの評価では、オープンエンド生成、主観的な品質判断、多段階の推論チェーン、そして常につきまとうベンチマーク汚染のリスクに向き合う必要があります。本節では、評価タイプの分類、人手アノテーションの仕組み、ランキング指標の数学、LLM-as-judgeの実務、評価パイプラインを静かに壊す落とし穴まで、評価の全体像を体系的に扱います。

Important

LLMの評価が難しい理由

3つの根本的な課題 が、LLM評価を古典的なML評価と区別します。

出力空間は無限です。 言語モデルは任意の文字列を生成でき、単一の正解が存在することはほとんどありません。

品質は多次元です。 有用性、事実性、安全性、一貫性、スタイルは別々の軸であり、互いにトレードオフになることがあります。

評価自体が言語タスクです。 応答が良いかを判断するには理解が必要であり、評価も生成と同じ失敗モードの影響を受けます。

評価スキームの設計

1つのデータ点を集める前に、実務者は何を測定し、どのように測定するかを決めなければなりません。原理に基づく分類は、配備目的との整合ではなく、便利さで指標を選ぶというよくある誤りを防ぎます。

評価タイプの分類

内在的評価と外在的評価

内在的評価は、下流アプリケーションを参照せず、モデル出力そのものの性質を測定します。ホールドアウトコーパスのパープレキシティ、参照訳に対するBLEUスコア、コーディングベンチマークのpass@$k$はいずれも内在的評価です。外在的評価は、現実世界のタスクやシステムに対するモデルの影響を測定します。LLMをカスタマーサービスのパイプラインに統合すると、チケットのエスカレーション率は下がるでしょうか。コーディングアシスタントは開発者の生産性を高めるでしょうか。

Tip

内在的評価と外在的評価の隔たり

内在的指標は安価で再現可能ですが、現実世界の有用性との相関が低いことがよくあります。パープレキシティが低いモデルが必ずしも有用とは限りません。外在的指標は高価で時間がかかりますが、私たちが重視するものを直接測定します。成熟した評価戦略では、迅速な反復に内在的指標を使い、最終検証に外在的指標を使います。

自動評価と人手評価

自動評価は、決定論的な関数（BLEU、完全一致）や学習済みモデル（BERTScore、LLM-as-judge）を使い、人手を介さずに出力を採点します。人手評価では、アノテーターがモデル出力を評価または順位付けします。表 1.1にトレードオフをまとめます。

タイプ	コスト	速度	再現性	妥当性
ルールベース自動	とても低い	とても速い	完全	低〜中
モデルベース自動	低い	速い	高い	中〜高
クラウドソーシング人手	中程度	日単位	中程度	中程度
専門家による人手	高い	週単位	低〜中	高い
外在的／A/Bテスト	とても高い	月単位	低い	とても高い

評価アプローチの分類と主なトレードオフ。 {#tab:eval-taxonomy}

参照ベース評価と参照なし評価

参照ベース指標（BLEU、ROUGE、BERTScore）は、モデル出力を1つ以上のゴールド標準参照と比較します。参照なし指標（パープレキシティ、LLM-as-judge、人手の選好）は、参照を使わずに品質を評価します。オープンエンド対話のように、出力空間が網羅的な参照収集には大きすぎる場合、参照なしのアプローチが不可欠です。

何をいつ使うか

Note

対話アシスタントの評価戦略

開発フェーズ： 自動指標（パープレキシティ、要約サブタスクのROUGE、ツール利用のpass@$k$）を使って迅速に反復します。標準スイート（MMLU、HellaSwag、HumanEval）で毎晩ベンチマークを実行します。

リリース前フェーズ： 新しいモデルと前のチェックポイントを比較する人手選好研究を実施します。多様なプロンプト集合で、スケール可能なペアワイズ比較にLLM-as-judgeを使います。

リリース後フェーズ： 外在的指標（ユーザー満足度スコア、タスク完了率）を監視し、本番プロンプトの分布シフトに注意します。

役立つ意思決定フレームワーク：

タスクに明確な正解（数学、コード、事実に基づくQA）がある場合：完全一致または実行ベースの指標を使う。
タスクがオープンエンドだが参照出力がある場合：参照ベース指標を下限として使い、LLM-as-judgeで補う。
タスクが主観的（有用性、語調、創造性）な場合：人手評価または十分に校正されたLLM judgeを使う。
タスクが多段階のエージェント振る舞いを含む場合：タスク成功率と軌跡効率（節 1.6）を使う。

評価のためのデータ収集

高品質な評価データは、信頼できるベンチマークの基盤です。本節では、人手アノテーションパイプラインの設計、アノテーション品質の統計的指標、クラウドソーシングと専門家アノテーションの選択を扱います。

人手アノテーションパイプライン

頑健なアノテーションパイプラインは5段階で構成されます。

タスク定義。 アノテーションタスクを正確に指定する：何を、どの尺度で、どの基準で評価するか。この段階の曖昧さはノイズの多いラベルへ伝播します。
ガイドラインの作成。 エッジケースを扱う実例付きのアノテーションガイドラインを書く。全面展開の前に、小規模なパイロットグループで反復する。
アノテーターの募集と訓練。 適切な背景知識を持つアノテーターを選ぶ。アノテーターが同じ例にラベルを付け、意見の相違を議論するキャリブレーションセッションを行う。
品質管理。 既知のラベルを持つゴールド標準の例をアノテーションキューに埋め込む。ゴールド例に対する精度がしきい値を下回るアノテーターにフラグを立てる。
集約。 多数決、平均、確率モデル（Dawid–Skeneなど）を使い、項目ごとの複数アノテーションを統合する。

アノテーター間一致度

生の一致度（すべてのアノテーターが一致する項目の割合）は、偶然の一致を考慮しないため不十分な指標です。偶然一致を補正する標準的な指標は、Cohenの $\kappa$ (Cohen 1960)（2人のアノテーター）とFleissの $\kappa$ (Fleiss 1971)（複数のアノテーター）です。

Cohenのカッパ

2人のアノテーターが $N$ 個の項目を $k$ カテゴリに分類するとき、$p_o$ を観測一致度、$p_e$ を独立性の下での期待一致度とします。

\[ \kappa = \frac{p_o - p_e}{1 - p_e} \label{eq:cohens-kappa} \]

ここで

\[ p_o = \frac{1}{N}\sum_{i=1}^{N} \mathbf{1}[\text{annotator 1 agrees with annotator 2 on item } i] \]

さらに、

\[ p_e = \sum_{c=1}^{k} p_{1c} \cdot p_{2c} \]

ここで $p_{jc}$ はカテゴリ $c$ にアノテーター $j$ が割り当てた項目の割合です。Cohenの $\kappa$ は $-1$（完全不一致）から $0$（偶然一致）を経て $1$（完全一致）までの範囲を取ります。$0.6$ は一般に許容可能で、$0.8$ は強い一致です。

Fleissのカッパ

$n$ 人のアノテーターが $N$ 個の項目を $k$ カテゴリに分類するとき、$n_{ij}$ は項目 $i$ をカテゴリ $j$ に割り当てたアノテーター数です。次を定義します。

\[ \bar{P}_i = \frac{1}{n(n-1)} \sum_{j=1}^{k} n_{ij}(n_{ij} - 1), \qquad \bar{P} = \frac{1}{N}\sum_{i=1}^{N}\bar{P}_i \]

\[ \bar{P}_j^e = \frac{1}{Nn}\sum_{i=1}^{N} n_{ij}, \qquad P_e = \sum_{j=1}^{k} \left(\bar{P}_j^e\right)^2 \]

\[ \kappa_F = \frac{\bar{P} - P_e}{1 - P_e} \]

Warning

カッパの限界

カッパはカテゴリの出現率に敏感です。1つのカテゴリが支配的な場合、生の一致度が高くてもカッパが低くなることがあります（カッパのパラドックス）。順序尺度では、重み付きカッパ（距離に比例して不一致を罰する）がより適切です。LLM評価では、評価が1〜5のリッカート尺度で行われることが多いため、常に重み付きカッパを報告します。

アノテーションガイドラインの設計

効果的なアノテーションガイドラインには、いくつかの共通する性質があります。

操作可能な基準。 「有用」のような曖昧な語を、具体的で観測可能な振る舞いに置き換える：「応答はユーザーの質問に直接答え、述べられたタスクを完了するために必要なすべての情報を提供している」。
実例。 境界事例を含め、各評価レベルについて少なくとも2つの例を提示する。
意思決定木。 複雑なタスクでは、二値判断の系列をアノテーターに案内するフローチャートが認知負荷を減らし、一貫性を高める。
明示的な範囲。 アノテーターが考慮すべきでないことを明示する（例：「文体の好みで減点せず、事実の正確さだけに注目する」）。

クラウドソーシングと専門家アノテーション

項目	クラウドソーシング	専門家アノテーション
1項目あたりのコスト	低（$0.01--$0.10）	高（$1--$50）
処理量	とても高い	低い
ドメイン知識	低い	高い
一貫性	ばらつきあり	高い
適するタスク	単純な選好、流暢さ	技術的正確さ、安全性
プラットフォーム	MTurk、Prolific、Scale AI	分野専門家、社内
品質管理	ゴールド例、注意チェック	キャリブレーション、ピアレビュー

LLM評価におけるクラウドソーシングと専門家アノテーションの比較。

安全性が重要な評価（有害出力の検出、医療助言の評価など）では、専門家アノテーションは不可欠です。大規模な選好収集（報酬モデルの学習セット構築など）では、厳格な品質管理付きのクラウドソーシングが、多くの場合、実行可能な唯一の選択肢です。

評価のための合成データ生成

人手アノテーションは高価で時間がかかります。合成データ生成では、LLM自身を使って評価データを大規模に作成します。本節では主要なパラダイムを扱います。

キャリブレーションのためのLLM-as-Judge

LLMを使って評価ラベルを生成する場合、キャリブレーションが不可欠です。判定モデルのスコアは人手判断と整合していなければなりません。$h_i \in [0,1]$ は項目 $i$ の人手選好スコア、$\hat{h}_i$ は判定モデルの予測スコアとします。キャリブレーション誤差はExpected Calibration Error（ECE） (Guo et al. 2017):

\[ \text{ECE} = \sum_{b=1}^{B} \frac{|B_b|}{n} \left| \text{acc}(B_b) - \text{conf}(B_b) \right| \]

ここで $B_b$ は $b$ 番目の信頼度ビン、$\text{acc}(B_b)$ はそのビンで判定モデルと人間が一致する項目の割合、 $\text{conf}(B_b)$ はそのビンにおける判定モデルの平均信頼度です。

キャリブレーションが良好な判定モデルは、$\mathbb{E}[\hat{h}_i \mid \hat{h}_i = p] = p$ をすべての $p \in [0,1]$ で満たします。キャリブレーションは温度スケーリングで改善できます。判定モデルの生のロジット $z$ を $z/T$ に置き換えます。ここで $T$ は学習に使っていないキャリブレーション集合で負の対数尤度が最小になるよう調整します。

Self-Instruct

Self-Instruct (Wang et al. 2022)は、人手で書かれたタスクのシード集合から指示追従データをブートストラップします。アルゴリズムは次のとおりです。

タスクプールを $175$ 個のシードタスクで初期化します。
プールから $8$ 個のタスクをサンプリングし、少数ショット例として使ってLLMに新しいタスクを生成させます。
生成タスクをフィルタリングします。近重複（既存タスクとのROUGE-L類似度 $> 0.7$ 以上）を除去し、classificationとnon-classificationに分類して、入力・出力インスタンスを生成します。
採用したタスクをプールに追加します。
目的のプールサイズに達するまで繰り返します。

Note

Self-Instructプロンプトテンプレート
system_prompt = """
Come up with a series of tasks:
Task 1: {seed_task_1_instruction}
Task 2: {seed_task_2_instruction}
...
Task 8: {seed_task_8_instruction}
Task 9:"""
モデルはプロンプトを完成させ、新しいタスク指示を生成します。続く別のプロンプトが、新しいタスクの入力・出力ペアを生成します。

Evol-Instruct

Evol-Instruct (Xu et al. 2023)は、指示を反復的に書き換えてより複雑または多様にすることで、シード指示集合を発展させます。2つの進化演算子を適用します。

深さ方向の進化： 制約を追加し、推論ステップを増やし、抽象化を具体化し、ドメイン知識の要件を深める。
幅方向の進化： 関連するが異なるトピックについて新しい指示を生成し、トピックの多様性を高める。

指示は、排除フィルターを通過した場合に採用されます。進化した指示は単純なコピーではなく、「申し訳ありません」などの拒否を含まず、元の指示より短くない必要があります。

Constitutional AIデータ生成

Constitutional AI（CAI）(Bai et al. 2022)は、一連の原則（「constitution」）に従ってモデル自身の出力を批評・改訂させることで選好データを生成します。パイプラインは次のとおりです。

教師あり学習フェーズ： 有害なプロンプトをサンプリングして初期応答を生成し、憲法上の原則に従って応答を批評・改訂するようモデルに促します。改訂後の応答を教師ありファインチューニングのターゲットとして使います。
RLフェーズ： 応答のペア（元の応答と改訂後の応答）を生成し、どちらがより原則に適合するかをモデルにラベル付けさせ、そのラベルで選好モデルを学習します。選好モデルをRLHFの報酬信号として使います。

この方法では、有害な内容を人手でラベル付けせずに選好データを生成できるため、アノテーターが苦痛を伴う素材に触れる機会を減らせます。

評価データの蒸留

強力な教師モデル（例：GPT-4）は、より小さな判定モデルを学習するための高品質な評価データを生成できます。蒸留パイプラインは次のとおりです。

多様なプロンプトとモデル応答の集合を収集する。
教師モデルに詳細な判定（スコアと根拠）を生成させる。
（プロンプト、応答、判定）の三つ組で小さなモデルをファインチューニングする。
学習に使っていない人手アノテーションに対して、学生判定モデルを検証する。

Warning

蒸留バイアス

単一の教師モデルから蒸留された学生判定モデルは、教師モデルのバイアスを引き継ぎます。これには、冗長性バイアス（長い応答を好む）、自己強化バイアス（教師モデル自身が評価対象でもある場合）、位置バイアスが含まれます。蒸留した判定モデルは、必ず独立した人手アノテーションに対して検証してください。

Arena形式のペアワイズ生成

Chatbot Arena (Zheng et al. 2023)は、ユーザーがプロンプトを投稿し、匿名化された2つのモデル応答のどちらを好むか投票するクラウドソーシング型の対戦プラットフォームを通じて評価データを生成します。これにより、大規模で自然に多様なペアワイズ選好データセットが得られます。主な設計上の選択は次のとおりです。

匿名化： ブランドバイアスを防ぐため、モデルの識別情報を隠す。
ユーザー投稿プロンプト： プロンプトの多様性と現実世界への関連性を確保する。
引き分けの扱い： ユーザーは引き分け、または両方の応答が悪いと申告できる。
重複除去： 似すぎたプロンプトを除外し、よくある質問が過剰に代表されるのを防ぐ。

生成タスクの指標

生成指標は、参照解答または明確に定義された正解基準があるタスクにおける、モデル出力の品質を定量化します。

BLEU

BLEU（Bilingual Evaluation Understudy） (Papineni et al. 2002)は、$n$グラム適合率を、仮説 $h$ と1つ以上の参照 $\mathcal{R}$ の間で測定します。

\[ \text{BLEU} = \text{BP} \cdot \exp!\left(\sum_{n=1}^{N} w_n \log p_n\right) \]

ここで $p_n$ は修正 $n$グラム適合率、$w_n = 1/N$は一様重み、BPは短さペナルティです。

\[ \text{BP} = \begin{cases} 1 & \text{if } |h| > |r| \\ e^{1 - |r|/|h|} & \text{if } |h| \leq |r| \end{cases} \]

ここで $\vert r\vert$ は最も近い参照の長さです。修正 $n$グラム適合率では、各 $n$グラムのカウントを、いずれかの参照における最大カウントでクリップします。

\[ p_n = \frac{\sum_{\text{ngram} \in h} \min!\left(\text{count}(\text{ngram}, h),, \max_{r \in \mathcal{R}} \text{count}(\text{ngram}, r)\right)}{\sum_{\text{ngram} \in h} \text{count}(\text{ngram}, h)} \]

Warning

BLEUの限界

BLEUは複数の参照を使う機械翻訳向けに設計されました。参照が1つのオープンエンド生成では、高品質な出力でもBLEUスコアがほぼゼロになることがあります。BLEUは意味的類似性を捉えず、有効な言い換えを罰し、トークン化にも敏感です。多様な参照が複数あり、出力の多様性が低いタスクでのみBLEUを使ってください。

ROUGE

ROUGE（Recall-Oriented Understudy for Gisting Evaluation） (Lin 2004)は、要約向けに設計された再現率重視の指標群です。

\[ \begin{aligned} \text{ROUGE-N} &= \frac{\sum_{r \in \mathcal{R}} \sum_{\text{ngram} \in r} \min(\text{count}(\text{ngram}, h), \text{count}(\text{ngram}, r))}{\sum_{r \in \mathcal{R}} \sum_{\text{ngram} \in r} \text{count}(\text{ngram}, r)} \\[6pt] \text{ROUGE-L} &= \frac{\text{LCS}(h, r)}{|r|} \end{aligned} \]

ここでLCSは最長共通部分列を表します。ROUGE-1とROUGE-2はそれぞれユニグラムとバイグラムの再現率を測定し、ROUGE-Lは文レベルの構造を捉えます。F値の変種は適合率と再現率のバランスを取ります。

\[ \text{ROUGE-N}_F = \frac{(1+\beta^2) \cdot P \cdot R}{\beta^2 P + R} \]

等しい重み付けでは $\beta = 1$ とします。

BERTScore

BERTScore (Zhang et al. 2020)は、事前学習済みBERTモデルの文脈埋め込みを使ってトークンレベルの類似度を計算します。仮説トークン $\hat{\mathbf{x}} = \langle \hat{x}_1, \ldots, \hat{x}_m \rangle$ と参照トークン $\mathbf{x} = \langle x_1, \ldots, x_n \rangle$ があり、埋め込み $\hat{\mathbf{e}}_i$ と $\mathbf{e}_j$ に対して、次のように定義します。

\[ \begin{aligned} R_{\text{BERT}} &= \frac{1}{|x|} \sum_{x_j \in \mathbf{x}} \max_{\hat{x}_i \in \hat{\mathbf{x}}} \frac{\hat{\mathbf{e}}_i^\top \mathbf{e}_j}{|\hat{\mathbf{e}}_i| |\mathbf{e}_j|} \\[4pt] P_{\text{BERT}} &= \frac{1}{|\hat{x}|} \sum_{\hat{x}_i \in \hat{\mathbf{x}}} \max_{x_j \in \mathbf{x}} \frac{\hat{\mathbf{e}}_i^\top \mathbf{e}_j}{|\hat{\mathbf{e}}_i| |\mathbf{e}_j|} \\[4pt] F_{\text{BERT}} &= 2 \cdot \frac{P_{\text{BERT}} \cdot R_{\text{BERT}}}{P_{\text{BERT}} + R_{\text{BERT}}} \end{aligned} \]

BERTScoreは、特に言い換えや、語彙は異なるが意味的に等価な出力について、BLEUやROUGEより人手判断との相関が高くなります。逆文書頻度（IDF）を使った重要度重み付けにより、相関はさらに改善します。

\[ R_{\text{BERT}}^{\text{idf}} = \frac{\sum_{x_j \in \mathbf{x}} \text{idf}(x_j) \max_{\hat{x}_i} \cos(\hat{\mathbf{e}}_i, \mathbf{e}_j)}{\sum_{x_j \in \mathbf{x}} \text{idf}(x_j)} \]

METEOR

METEOR (Banerjee and Lavie 2005)は、ユニグラム一致に対するFスコアを計算し、語幹処理と同義語マッチングの追加モジュールを使うことで、BLEUの再現率軽視に対処します。

\[ \text{METEOR} = F_{\text{mean}} \cdot (1 - \text{Pen}) \]

ここで $F_{\text{mean}} = \frac{10PR}{R + 9P}$（再現率重み付き調和平均）であり、断片化ペナルティ $\text{Pen} = 0.5 \cdot (c/u_m)^3$ は連続しない一致を罰します（$c$ はチャンク数、$u_m$ は一致したユニグラム数）。

パープレキシティ

パープレキシティは、言語モデルがホールドアウトされたテキスト系列 $w_1, w_2, \ldots, w_T$ をどれだけ適切に予測できるかを測定します。

\[ \text{PPL}(w_{1:T}) = \exp!\left(-\frac{1}{T}\sum_{t=1}^{T} \log P_\theta(w_t \mid w_{1:t-1})\right) \]

パープレキシティが低いほど予測性能が高いことを示します。パープレキシティは、同じトークン化とテストセット上でモデルを比較するのに有用ですが、語彙やトークナイザーが異なるモデル間では直接比較できません。評価では、健全性チェックと分布シフトの検出に最も役立ちます。

コードのPass@k

コード生成では、生成コードをテストケースに対して実行し、機能的正しさを測定します。pass@$k$ 指標 (Chen et al. 2021)は、$k$ 個の生成サンプルのうち少なくとも1つがすべてのテストに合格する確率を推定します。

\[ \text{pass@}k = \mathbb{E}_{\text{problems}}!\left[1 - \frac{\binom{n-c}{k}}{\binom{n}{k}}\right] \]

ここで $n$ は問題ごとに生成したサンプル総数、$c$ は合格したサンプル数です。この不偏推定量は、ちょうど $k$ 個の解をサンプリングして合格があるか確認する単純な推定量の高い分散を避けます。実際には $n = 200$ 個のサンプルを生成し、pass@1、pass@10、pass@100を報告します。

Note

Pass@kの計算

import numpy as np
from scipy.special import comb

def pass_at_k(n: int, c: int, k: int) -> float:
    """Unbiased estimator for pass@k.

    Args:
        n: total samples generated per problem
        c: number of samples that pass all tests
        k: number of samples to consider
    """
    if n - c < k:
        return 1.0
    return 1.0 - comb(n - c, k, exact=True) / comb(n, k, exact=True)

# Example: 200 samples, 15 pass, compute pass@1, pass@10, pass@100
for k in [1, 10, 100]:
    score = pass_at_k(n=200, c=15, k=k)
    print(f"pass@{k}: {score:.4f}")
# pass@1:   0.0750
# pass@10:  0.5391
# pass@100: 0.9999

完全一致とF1

抽出型質問応答（例：SQuAD）では、次の2つが標準的な指標です。

完全一致（EM）： 正規化（小文字化、冠詞と句読点の除去）後の予測解答文字列が、いずれかの正解解答と完全に一致するかを示す二値指標。
トークンレベルF1： 予測と正解解答をトークンのバッグとして扱い、F1スコアを計算する。

\[ F1 = \frac{2 \cdot |\text{pred} \cap \text{gold}|}{|\text{pred}| + |\text{gold}|} \]

複数解答がある場合は、すべての正解解答に対する最大F1を報告します。

指標	タスク	参照なし？	人手との相関
BLEU	翻訳	いいえ	低〜中
ROUGE	要約	いいえ	中
BERTScore	一般NLG	いいえ	高
METEOR	翻訳	いいえ	中〜高
Perplexity	LM品質	はい	低
Pass@k	コード生成	いいえ（テスト）	とても高
Exact Match	抽出型QA	いいえ	とても高
Token F1	抽出型QA	いいえ	高

生成指標のまとめ：適用範囲と主な性質。

エージェントタスクの指標

エージェント型LLMは環境内で動作し、一連の行動を取り、多段階タスクを完了しなければなりません。標準的な生成指標だけでは不十分です。エージェント評価では、タスク完了度、効率、途中ステップの品質を捉える指標が必要です。

タスク成功率

エージェントタスクの主要指標はタスク成功率（TSR）です。指定された目標状態をエージェントが達成したタスクの割合を表します。

\[ \text{TSR} = \frac{1}{|\mathcal{T}|} \sum_{\tau \in \mathcal{T}} \mathbf{1}[\text{goal}(\tau) \text{ achieved}] \]

目標の達成は通常、決定論的なオラクル（データベース状態、ファイルシステム状態、テストケースの実行結果など）で検証します。部分点があるタスクでは、段階的な成功指標を定義できます。

\[ \text{TSR}_{\text{graded}} = \frac{1}{|\mathcal{T}|} \sum_{\tau \in \mathcal{T}} \text{score}(\tau) \in [0, 1] \]

軌跡効率

成功するエージェントは、不要な行動を最小限にしてタスクを完了すべきです。軌跡効率は、最適軌跡の長さとエージェントが実際にたどった軌跡の長さの比率を測定します。

\[ \eta = \frac{L^*}{L_{\text{agent}}} \]

ここで $L^*$ は最短の成功軌跡の長さ（オラクルまたは人間の専門家が計算）で、$L_{\text{agent}}$ はエージェントが取った行動数です。$\eta \in (0, 1]$ で、$\eta = 1$ が最適効率を示します。失敗した軌跡では$\eta = 0$。

補完的な指標として冗長率があります。これは、どの最適軌跡にも含まれないエージェントの行動の割合です。

ツール利用精度

外部ツール（API、コードインタープリター、検索エンジンなど）を呼び出すエージェントでは、ツール利用精度がツール呼び出しの正しさを測定します。

\[ \text{TUA} = \frac{\text{# correct tool calls}}{\text{# total tool calls}} \]

ツール呼び出しが正しいとは、(a) 正しいツールを選び、(b) 引数が有効で、(c) 軌跡の適切な時点で呼び出していることです。ツール選択は正しいが引数が誤っている場合には、部分点を与えられます。

多段階推論精度

推論の連鎖を必要とするタスク（マルチホップQA、数学問題の解決など）では、ステップレベル精度が正しい推論ステップの割合を測定します。

\[ \text{SRA} = \frac{1}{|\mathcal{T}|} \sum_{\tau \in \mathcal{T}} \frac{1}{|S_\tau|} \sum_{s \in S_\tau} \mathbf{1}[s \text{ is correct}] \]

ここで $S_\tau$ は軌跡 $\tau$ における推論ステップの集合です。ステップの正しさは、プロセス報酬モデル（PRM）または人手アノテーションで検証できます。

SWE-benchの方法論

SWE-bench (Jimenez et al. 2024)は、現実世界のソフトウェア工学タスクでLLMを評価します。GitHubのIssue説明とリポジトリのコードベースを与え、モデルはIssueを解決するパッチを生成しなければなりません。評価は次のように進みます。

モデルにIssueの説明と関連するコードコンテキストを与える。
モデルがパッチ（unified diff形式）を生成する。
パッチをリポジトリに適用する。
リポジトリのテストスイートを実行し、すべてのテストに合格すればタスク成功とする。

主要指標は 解決率（% Resolved） 、つまり生成パッチがすべてのテストに合格したIssueの割合です。SWE-bench Verifiedは、人手アノテーターが解決可能かつ曖昧でないことを確認した500問の精選サブセットです。SWE-bench Liteは、より高速な評価向けに設計された300問のサブセットです。

Important

SWE-benchの主な統計（2024年時点）

全ベンチマーク： 人気のPythonリポジトリ12個からなる2,294タスク。

最良のオープンソースエージェント： $\sim$43%を解決（SWE-bench Verified）。

人間の性能： $\sim$87%を解決（1タスクあたり15分）。

評価コスト： $\sim$$0.25（APIベースのモデルで1タスクあたり）。

WebArenaの方法論

WebArena (S. Zhou et al. 2024)は、サンドボックス化されたブラウザ環境で現実的なウェブナビゲーションタスクを評価します。ベンチマークには、5つのウェブアプリケーション（EC、ソーシャルフォーラム、共同開発、コンテンツ管理、地図）にまたがる812タスクが含まれます。評価方法は次のとおりです。

機能評価： アプリケーション状態を確認してタスク結果を検証する（例：「商品はカートに追加されたか」「投稿は作成されたか」）。
URLベース評価： ナビゲーションタスクでは、最終URLを期待されるURLと比較する。
プログラムベース評価： カスタム評価スクリプトで複雑な条件を確認する（例：「価格は50ドル未満か」）。

主要指標はタスク成功率です。人間の性能は約78%、最先端エージェントは約35〜45%です。

ベンチマーク	分野	タスク数	評価方法	SOTA（%）
SWE-bench	ソフトウェア工学	2,294	テスト実行	$\sim$43
SWE-bench Lite	ソフトウェア工学	300	テスト実行	$\sim$50
WebArena	ウェブナビゲーション	812	状態／URL／プログラム	$\sim$40
ALFWorld (Shridhar et al. 2021)	家庭タスク	3,553	シミュレーター状態	$\sim$90
AgentBench (X. Liu et al. 2023)	複数分野	1,091	タスク固有	$\sim$45

エージェント評価ベンチマークの比較。

LLM-as-Judge

LLM-as-judge (Zheng et al. 2023)は、高性能なLLMを使って他のLLM（または同じLLM）の出力を評価します。この方法は人手アノテーションなしで大規模な評価集合に拡張でき、判定の詳細な根拠も提供できます。

セットアップとプロンプトテンプレート

判定モデルには、プロンプト、1つ以上のモデル応答、評価ルーブリックを提示します。一般的な形式は3つあります。

点ごとのスコアリング

判定モデルが1つの応答に絶対スコアを付けます。

Note

点ごとの判定プロンプト

POINTWISE_PROMPT = """
You are an expert evaluator. Rate the following response on a scale 
of 1-10 for helpfulness, accuracy, and clarity.

[Question]
{question}

[Response]
{response}

Provide your evaluation in the following format:
Reasoning: <step-by-step analysis>
Score: <integer from 1 to 10>
"""

ペアワイズ比較

判定モデルが2つの応答を比較し、より良い方を選びます。

Note

ペアワイズ判定プロンプト

PAIRWISE_PROMPT = """
You are an expert evaluator. Compare the two responses below and 
determine which is better. Consider helpfulness, accuracy, and 
depth of explanation.

[Question]
{question}

[Response A]
{response_a}

[Response B]
{response_b}

Output exactly one of: [[A]], [[B]], or [[C]] (tie).
Reasoning: <your analysis>
Verdict: <[[A]], [[B]], or [[C]]>
"""

参照に基づくスコアリング

判定モデルに参照解答を与え、それとの相対関係で応答を評価させます。判定モデルが確かな知識を持っていない可能性がある事実タスクで特に有用です。

位置バイアスの緩和

LLM判定モデルには位置バイアスがあります。特定の位置（最初または最後）に現れる応答を体系的に好む傾向です。このバイアスは10〜15パーセントポイントに達することがあります。緩和策は次のとおりです。

入れ替え拡張： 各ペアを両方の順序（A対B、B対A）で評価する。一貫した判定を採用し、一貫しない判定は引き分けとして記録する。
キャリブレーションプロンプト： 「応答が提示される順序に評価を左右されてはいけない」と判定モデルに明示的に指示する。
アンサンブル判定： 位置順序を変えた複数の判定モデルを使い、判定を集約する。
思考の連鎖の強制： 判定前に詳細な根拠を生成させ、表面的な位置手掛かりへの依存を減らす。

Warning

冗長性バイアス

LLM判定モデルには冗長性バイアスもあります。追加内容が無関係または反復的であっても、長い応答を体系的に好みます。これを緩和するには、不要な長さを減点し、量ではなく情報の品質に集中するよう判定モデルに指示します。あるいは、判定前に応答を一定の長さへ切り詰めます。

複数判定モデルのパネル

単一の判定モデルには体系的なバイアスがあることがあります。異なるモデルファミリーの判定モデルによるパネルは、より頑健な評価を提供します。$J$ 個の判定モデルが判定 $v_1, \ldots, v_J \in \{A, B, \text{tie}\}$ のとき、パネルの判定は多数決で決まります。パネル一致率は次のとおりです。

\[ \text{Agreement} = \frac{1}{\binom{J}{2}} \sum_{i < j} \mathbf{1}[v_i = v_j] \]

3判定モデルのパネルでは、全員一致を高信頼、2対1の分裂を中信頼、三者引き分けを低信頼として扱います。

LLM判定モデルの一致度指標

LLM判定モデルを検証するには、学習に使っていない集合で判定結果を人手アノテーションと比較します。主な指標は次のとおりです。

一致率： 判定モデルと人間の判断が一致する項目の割合。
Cohenの $\kappa$: 偶然一致を補正した一致度（式 [eq:cohens-kappa]）。
Spearmanの $\rho$: 判定モデルのスコアと人間のスコアの順位相関。順序尺度に適しています。
Kendallの $\tau$: 引き分けに対してより頑健な、別の順位相関。

代表的なサンプルで、人手アノテーターに対して $\kappa > 0.6$ かつ一致率 $> 80%$ を達成する判定モデルは、信頼できるとみなします。

G-Evalフレームワーク

G-Eval (Y. Liu et al. 2023)は、思考の連鎖プロンプトとトークン確率の重み付けを使い、より信頼できるスコアを生成するLLMベース評価の構造化フレームワークです。手順は次のとおりです。

評価ステップの生成： 評価タスクの詳細なルーブリックをLLMに生成させる（例：「要約の一貫性を評価するために行うステップを列挙せよ」）。
確率重み付きスコアリング： 各スコア値 $s \in \{1, 2, 3, 4, 5\}$ について、判定モデルから対数確率 $\log P_\theta(s \mid \text{prompt, steps, response})$ を取得します。最終スコアは確率重み付き平均です。

\[ \text{G-Eval score} = \sum_{s=1}^{5} s \cdot \frac{e^{\log P_\theta(s)}}{\sum_{s'=1}^{5} e^{\log P_\theta(s')}} \]

正規化： 最大スコアで割り、スコアを $[0, 1]$ に写像する。

G-Evalは、直接プロンプトよりも人手判断との相関が高くなります。特に一貫性や整合性のような微妙な側面で、確率の重み付けが判定モデルの不確実性を捉え、離散的な選択を強制しないためです。

Tip

G-Evalが機能する理由

標準的なプロンプトは判定モデルに単一トークン（例：「4」）を出力させるため、モデルの不確実性を捨ててしまいます。G-Evalはすべてのスコアトークンに対する確率分布を読み、判定モデルの信念の下で期待スコアを実質的に計算します。これは最頻値ではなく事後分布の平均を使うことに相当します。

評価の落とし穴

注意深く設計した評価パイプラインでも、誤解を招く結果を生むことがあります。本節では、よくある失敗モードを整理します。

ベンチマーク汚染

ベンチマーク汚染は、評価データがモデルの学習セットに直接（そのまま含まれる）または間接的（言い換えや意味的に類似した内容）に現れることで起こります。汚染されたモデルは、真の汎化能力を反映しない水増しされたスコアを達成します。

検出方法

$n$グラムの重複： 評価例のうち、学習コーパスと高い$n$グラムの重複（例：ROUGE-L $> 0.8$）を持つものの割合を計算する。
メンバーシップ推論： メンバーシップ推論攻撃を使い、各評価例が学習セットに含まれていた確率を推定する。
カナリア文字列： 評価例に一意でランダムな文字列を埋め込み、モデルがそれを続けられるか確認する。
時間的ホールドアウト： モデルの学習カットオフ日より後に作成された評価データを使う。

緩和策

公開しない非公開テストセットを維持する。
新しい例でベンチマークを定期的に更新する。
学習データのカットオフ日と汚染除去手順を報告する。

ベンチマークへの過適合

直接的な汚染がなくても、繰り返しの評価やハイパーパラメータ調整によって、モデルが特定のベンチマーク向けに暗黙に最適化されることがあります。これは適応的過適合の一種であり、ベンチマークの情報がモデル開発上の判断に漏れ出しています。

Warning

ベンチマークのライフサイクル

研究コミュニティがベンチマーク向けに最適化するにつれて、ベンチマークの有用性は時間とともに低下します。かつては世界知識の難しいテストだったMMLU (Hendrycks et al. 2021)でも、現在は人間に近い性能を達成するモデルがありますが、それらのモデルは新しい知識タスクには依然として失敗します。新しいベンチマークは、永続的な正解ではなく、一時的な信号源として扱うべきです。

評価におけるGoodhartの法則

Goodhartの法則は「指標が目標になると、良い指標ではなくなる」と述べます (Goodhart 1984)。LLM評価では、これは次のように現れます。

報酬ハッキング： RLHFで学習したモデルが、本当に改善するのではなく報酬モデルを出し抜くことを学ぶ。報酬モデルでは高得点だが事実としては誤っている、冗長で自信ありげな応答を生成するよう学習することがあります。
指標のゲーム化： BLEUやROUGEの最大化向けにファインチューニングされたモデルが、これらの指標では高得点だが人間には役立ちにくい出力を生成することがあります。
判定モデルのゲーム化： LLM-as-judgeのフィードバックで学習したモデルが、本当に品質を改善するのではなく、判定モデルのバイアス（例：冗長性バイアス）を学習することがあります。

Important

Goodhartの法則への対策

指標の多様性： 異なる系統の複数指標を使う。1つの指標をゲーム化するモデルが、すべてを同時にゲーム化する可能性は低い。

ホールドアウト評価： 学習やモデル選択に使っていない評価指標を維持する。

人手による抜き取り確認： 自動指標とは独立して、モデル出力を定期的にサンプリングし、人手で確認する。

敵対的評価： 自動指標が見落とす失敗モードを積極的に探る。

外在的検証： 内在的指標を外在的な結果に対して定期的に検証する。

Note

評価設計の重要な問い

評価パイプラインを配備する前に、次を確認してください。

評価指標は配備目的と整合しているか。

評価データは対象分布を代表しているか。

汚染と過適合のリスクを評価したか。

すべての指標について信頼区間を報告しているか。

評価は再現可能か（固定シード、バージョン管理されたプロンプト、公開テストセット）。

評価を人手判断または外在的な結果に対して検証したか。

Keyboard shortcuts

The Hitchhiker's Guide to Agentic AI 日本語版