エージェント評価は「合格/不合格」では足りない — サプライザルで難易度を測り、評価器そのものを評価する¶

作成日: 2026-07-11 出典 / きっかけ: Google Cloud Blog「Evaluating agent performance」（Manav Garg / Sunil Pedapudi, Data Cloud Frontier AI, 2026-07-11） https://cloud.google.com/blog/products/data-analytics/evaluate-agent-performance/ 関連: deutsche-telekom_openai_ai-native通信 / smarthr_aiドリブン開発をチームに定着させた話 / dspy_現場プロンプト改善ループ_metricと所有権境界_整理 / ai生産性パラドックス_メトリクス起点の改善ループ_整理

0. 要点（3行）¶

合格スコアは一番つまらない情報。固定ベンチマークの pass/fail は「どれだけ際どく落ちたか・どれだけ楽に通ったか・次に何を直すか」を全部隠す。必要なのは点数ではなく、能力の地形図（どこで・どれだけ性能が崖落ちするか）。
Google の Discovery Bench は、質問の曖昧さを情報理論の サプライザル（surprisal, 単位: bit） で定量化し、同じ設問を難易度別にスイープして性能曲線を描く（iSQR: iterative surprisal-based query refinement）。同一エージェント・同一クエリでも言い回しだけで F1 が 1.00 → 0.00 まで崖落ちする「静的ベンチでは見えない崖」を可視化する。
核メッセージは "Evaluate your evals"（評価器を評価せよ）。ground truth を直接読み、難易度を（ラベルではなく）測定量として扱い、難易度を推定する LLM 自身も監査対象に置く。実際この目で KramaBench の ground truth 欠陥を発見した。

1. なぜ「合格スコア」は役に立たないか¶

記事の書き出しが本質を突いている:

"A passing grade is the least interesting thing an exam can tell you."（合格点は、試験が教えてくれる最もつまらない情報だ）

固定ベンチマークで走らせ、スコアを出し、「進捗した」と宣言する。これは pass/fail の試験を渡しているのと同じで、本当に欲しい能力の地図（terrain map）— どこで capability が落ち、どれだけ落ちるか — が得られない。

とくにデータエージェント（自然言語→データ発見→分析）では次が効いてくる:

Needle in a haystack: 数千のテーブル/ファイルから正しいデータセットを引き当てる問題。
現実のユーザーは質問が下手。言い回しは不完全。ゆえに本当に測るべきは「質問がどこまで曖昧になったらエージェントは壊れるか」。

固定ベンチはこの「壊れ方の勾配」を測れない。

2. 難易度を「測る」— サプライザルと iSQR¶

2-1. サプライザル = クエリを見た後に残る「どのデータセットか」の不確実性¶

サプライザル（self-information, -log p）は情報理論の量で、ここでは 「クエリが与えられたとき、正解データセットについて残っている不確実性」を bit で測る。主観的な難易度ラベルではなく測定量なのが肝。

識別力の高い語（informative power）は、対象を corpus からシャープに切り出す → サプライザルが小さい。
サプライザルが 0 に近づく = クエリが 1 つのデータセットをピタリと指す。

サプライザル 大 ── クエリが曖昧、多数のテーブルにマッチ（どれか分からない）
     │
     │  識別語を足す / 抜く でスイープ
     ▼
サプライザル 小 ── クエリが 1 テーブルを一意に指す（易しい）

2-2. iSQR — 難易度を 3 段階に較正して振る¶

iSQR（iterative surprisal-based query refinement） は、サプライザルを使って同じ問いを難易度別に作り替える反復ループ:

        ┌─────────────────────────────┐
        │  元クエリ（neutral な言い回し） │
        └──────────────┬──────────────┘
                       │ サプライザルを計測
          ┌────────────┼────────────┐
          ▼            ▼            ▼
   識別語を除去     そのまま      識別語を追加
  （High 曖昧）  （Medium 付近） （Low 曖昧・易しい）
          └────────────┼────────────┘
                       ▼
            各難易度で F1 を測り、性能曲線を描く

2-3. 具体例（KramaBench の TLE クエリ）¶

"the total count of satellite major altitude changes for satellite 48445 during 2024 using TLE history"

"TLE" トークンが強い識別語 → TLE_____48445 テーブルを一意に指す（サプライザル小）。
"TLE" を剥ぐ → "the count of satellite altitudes for satellite 48445" は density テーブル・precise-orbit ファイル・decay ログなど複数にマッチ（サプライザル大）。
記事の報告では、この設問はニュートラルな言い回しで F1 = 1.00、高曖昧化すると F1 = 0.00 に崖落ちする。

3. 見えなかった崖（cliff）と非単調性¶

iSQR で難易度を振ると、静的ベンチが平均点で隠していた2つの重要事実が出る。

3-1. 難易度スイープの性能曲線（KramaBench 上の F1 エージェント・記事掲載値）¶

曖昧さレベル	F1（記事の図より）	解釈
High（識別語を除去）	0.34	崖の底
Neutral（元の言い回し）	0.76	素の実力
Medium	0.81	ここが最高（sweet spot）
Low（識別語を追加・易しい）	0.78	易しくしたのに Medium に負ける

※ F1 値は記事に掲載されたチャートからの読み取り。厳密な再現値は原文の図を要確認。

2つの洞察:

性能の崖（performance cliff）: 同じクエリ・同じエージェントでも、言い回しだけで性能が急落する。静的ベンチの単一スコアには一切現れない。
非単調性（non-monotonic）: Medium（0.81）が Low（0.78）を上回る。「易しくすれば上がる」わけではなく、最適化のスイートスポットが存在する。ここから具体的な failure mode が見える:
時系列シャード化テーブル（time-sharded）: precision が ~8% まで崩壊。
コンテキスト膨張（context blow-up）: 探索チェーンが長くなると F1 が 0.75 → 0.32 に低下。

4. "Evaluate your evals" — 評価器を疑え¶

4-1. 信頼していたベンチが壊れていた（KramaBench）¶

Discovery Bench で ground truth を直接読んだ結果、KramaBench に実際の欠陥が見つかった:

ground-truth テーブルがクエリに答えていない
クエリが API の返却上限を超える
日付/月の要件がミスマッチ

評価データもまた成果物（artifact）であり、欠陥を持ちうるのに、ほとんど検証されない — これが見落とされがちな盲点。

4-2. 2つの地図が食い違うとき（LLM vs TF-IDF）¶

曖昧さスイープを LLM で自由生成 した場合と、TF-IDF で ground した 場合で結果が大きく食い違った:

高曖昧化の作り方	High-ambiguity F1（記事値）	含意
LLM が自由生成	≈ 0.34	LLM が「壊しすぎ」or 恣意的な曖昧化をしうる
TF-IDF grounded	≈ 0.85	コーパス統計に足場を置くほうが頑健

→ 難易度をエントロピーで測るのは、エントロピーを推定するモデルの精度までしか信用できない。「エージェントではなく、ものさし（ruler）を最適化してしまう」リスク。だから評価器（推定に使う LLM）を、評価対象と同じ厳しさで監査下に置く。

5. 同時多発する潮流 — メタベンチマーク¶

記事いわく「我々だけではない（We're not alone）」。difficulty を測定量として扱う流れは各所で立ち上がっている。一次資料で裏取りした要点:

系統	代表研究	何を示したか（数値）	出典
IRT（項目応答理論）で難易度を測る	tinyBenchmarks	395 モデルの応答で IRT を当て、100 個の anchor 項目でフルベンチのスコアを平均誤差 ~2% で再現	arXiv 2402.14992
同上	metabench	>5,000 モデルで IRT 較正、Fisher 情報量で項目選抜、GAM で復元。元の 3% 未満のサイズで 6 ベンチの評価力を保持	arXiv 2407.12844
ベンチ品質自体に IRT	PSN-IRT / "Lost in Benchmarks?"	IRT をベンチマークの質そのものの診断に適用	arXiv 2505.15055
ground truth 監査	MMLU-Redux（"Are We Done with MMLU?"）	14 人の専門家が 5,700 問を再アノテート。6.49% に誤り。Virology では 57% に誤り	arXiv 2406.04127
同上	Platinum Benchmarks（"Do LLM Benchmarks Test Reliability?"）	15 個の既存ベンチを手作業で修正。修正後にモデル誤りが過半（>50%）減るケース多数（＝元の誤りの多くはラベルノイズ）	arXiv 2502.03461
曖昧さをシグナルとして扱う	AmbigQA（EMNLP 2020, Sewon Min ら）	NQ-open 由来の 14,042 問（AmbigNQ）。半数超が複数解釈を許す曖昧な問い	arXiv 2004.10645

補足: 見かけ上の「幻覚（hallucination）」の多くが、モデルの失敗ではなくクエリの曖昧さ由来である、という近年の指摘とも整合する。

6. まとめ — いつ・どう使うか¶

エージェント（特に自然言語→データ発見/分析）を評価するときの実践指針:

やりたいこと	従来（pass/fail）	この記事の推奨
モデルの実力把握	単一スコア	難易度スイープで性能曲線を描く
難易度の扱い	主観ラベル	サプライザル（bit）= 測定量として計測
弱点の特定	平均点で埋もれる	崖・非単調点・failure mode（time-shard, context blow-up）を露出
ベンチの信頼	暗黙に信頼	ground truth を直接読む／評価器を監査（evaluate your evals）
曖昧化の生成	LLM に丸投げ	TF-IDF で ground（コーパス統計に足場）

一言で: 「点数を測る」から「難易度を測り、崖の位置を地図にする」へ。そしてものさし（評価器）自体を疑え。

注意・留保¶

記事の "Discovery Bench"（2語） は Google Data Cloud Frontier AI 独自の枠組みで、Allen Institute の DiscoveryBench（1語, arXiv 2407.01725, 264 実タスク+903 合成, 最良系でも 25%）とは別物。名称が紛らわしいので混同注意。記事本文は AI2 版に言及していない。
記事の F1 数値はいずれも掲載チャートからの読み取りで、厳密値は原図を要確認。TLE 例の 1.00→0.00 は「その特定設問」の話、表3-1の 0.34〜0.81 は集計曲線の話で、レイヤが異なる。
KramaBench（テスト台として使用, arXiv 2506.06541）: 104 の実データサイエンスパイプライン, 1,700 ファイル, 24 データソース, 6 ドメイン。最良系で end-to-end 55%（完全 retrieval でも 62% が上限）、重要タスクの識別は最大 42%・完全実装は 20% に留まる — という「そもそも難しい」土俵。

参考リンク¶

Google Cloud Blog: Evaluating agent performance — https://cloud.google.com/blog/products/data-analytics/evaluate-agent-performance/
KramaBench（データレイク上の data-to-insight パイプラインのベンチ, テスト台） — https://arxiv.org/abs/2506.06541
DiscoveryBench（AI2・名称が紛らわしい別物） — https://arxiv.org/abs/2407.01725
tinyBenchmarks（IRT で 100 項目に圧縮） — https://arxiv.org/abs/2402.14992
metabench（IRT スパースベンチ, 元の <3%） — https://arxiv.org/abs/2407.12844
Lost in Benchmarks?（IRT でベンチ品質診断 / PSN-IRT） — https://arxiv.org/abs/2505.15055
Are We Done with MMLU?（MMLU-Redux, 誤り 6.49%） — https://arxiv.org/abs/2406.04127
Do Large Language Model Benchmarks Test Reliability?（Platinum Benchmarks） — https://arxiv.org/abs/2502.03461
AmbigQA: Answering Ambiguous Open-domain Questions — https://arxiv.org/abs/2004.10645

作成: 2026-07-11 ／最終更新: 2026-07-11