Frontier and Center: 誰が評価ツールを評価するのか？

※この投稿は米国時間 2026 年 7 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: AI に関する最も興味深い問いとして、新たなクラスの AI エージェントにコンテキストを提供する方法に関して情報理論家が提起しているものがあります。数週間前、Google は Open Knowledge Format に関するブログ記事で、この問題に踏み込みました。Open Knowledge Format は、最新の AI システムを動作させるために必要なメタデータ、コンテキスト、キュレートされた知識を表すために、LLM-wiki パターンを移植可能で相互運用可能な形式に形式化する仕様です。このブログ記事は大きな関心を集めたため、同様のコンテンツを新しい「Frontier and Center」シリーズとして提供する運びとなりました。今回は、Google データクラウドのフロンティア AI チームに属する 2 人のメンバーから、エージェントがコンテキストに基づいて効果的に質問に回答できるかどうかをどのように体系的に評価するかという、繰り返し直面する課題について話を聞きます。詳しくは、記事全文をご覧ください。また、このチームによる今後のブログ記事にもご期待ください。

試験に関して合格点だけを知っても、それほど意味はありません。生徒が合格したかどうかはわかりますが、不合格だった場合は合格点からどれだけ離れていたのか、合格だった場合はどれだけ余裕があったのか、次回のために何を教えるべきなのかはわかりません。しかし、AI エージェントはまさにこのように評価されています。固定のベンチマークを実行し、スコアを計算して、進歩したと宣言しているのが現状です。このような評価では、エージェントに合格 / 不合格の試験を行っているのと同じです。必要なのは、エージェントの能力がどの部分でどの程度不足しているのかを正確に表す地形マップです。

データ エージェントにとって、このマップは検索と取得におけるデータ探索に極めて重要です。このプロセスは、エージェントが曖昧な人間の質問と、数千のテーブルとファイルからなるデータ ウェアハウスまたはデータレイクを受け取った後、推論を行うための前段階として適切なデータセットを見つけなければならないという、地味な最初のステップです。探索は「干し草の山から針を探す」ようなものです。実際のユーザーからの質問は完璧に表現されたものではないため、どのデータセットを取得すべきかを推測するのはエージェントにとって非常に困難です。そのため、真に問うべきことは「エージェントは合格できるか」という点ではないのです。真に問うべきことは、「質問がどれだけ曖昧になるとエージェントが機能しなくなるか」という点です。試験ではこの問いに簡単に答えることはできませんが、マップでなら可能です。

このブログ投稿では、情報理論に基づいたアプローチをご紹介します。このアプローチは、ベンチマークに詳細とニュアンスを追加して忠実度を高めるために活用されており、評価の一環としてエージェントのパフォーマンスをより深く理解できるようになります。忠実度を高めたことで、発生した評価ケース自体の品質に関するより深い問題も明らかになりました。

難易度を測定

取得に関しては、評価ケースは多くの場合、難易度に応じて階層化されます。こうした階層化は、自然に生じることもあります。たとえば、広範囲で発生し、失敗が繰り返されるシナリオが「困難」と判断される場合などです。また、たとえばクエリで提供されたコンテキストに基づいて、エージェントが正しく回答する難易度が低いか高いかについて、人間やマシンが適用したラベルに基づいて、質問を分類することもできます。このような感情ベースのラベル付けは、テストケースにラベルを付ける唯一の方法ではありませんが、再現が難しいなどの欠点があるにもかかわらず、頻繁に使用されています。

すべての評価ケースを手作業で評価する方法も業界では一般的ですが、規模が大きくなれば現実的な方法ではなくなります。必要なのは、評価ケースの難易度を調整できる厳格なアプローチです。Google は、Discovery Bench と呼ばれるメタ ベンチマークの改良を重ねています。このベンチマークは、すべてのケースの「低難易度」バリエーションと「高難易度」バリエーションを生成することで評価ケースを調整するフレームワークです。これにより、エージェントがこれらのケースで成功からどれだけ離れているかを監査できます。

入力クエリの難易度を調整する手段は、情報理論と ML の分野で実績があり、信頼できるコンセプトであるサプライザル（意外性）、あるいは、ある一連の入力に対する出力の可能性によって実現されます。今回のケースでは、クエリのサプライザルとは、与えられたクエリから正しいデータセットを特定するうえで、依然として残っている不確実性を表します。

このアプローチの背後にある考え方はシンプルです。評価クエリの用語やフレーズは、コーパス内の他のすべてのものからターゲットを明確に特定できる場合、高い情報提供力を持つとみなされます。そのため、さまざまな情報提供力を持つ用語を追加または削除することにより、評価ケースの難易度を調整できます。

一般公開されているベンチマークである KramaBench の実際の例を見てみましょう。KramaBench のデータセットの一つには、地球を周回する衛星に関する情報が含まれます。スイートからのサンプルクエリには、次のテキストが含まれています。「…TLE 履歴を使用して、2024 年に衛星 48445 の高度が大きく変化した合計回数。」

トークン "TLE" が指定されているため、データセットの TLE_____48445 テーブルがほぼ一意に特定されます。これを削除すると、クエリは「衛星 48445 の高度の回数」のように曖昧なフレーズとなり、密度テーブル、精密軌道ファイル、減衰ログなどにも一致します。サプライザルはこれを定量化します。出現頻度の低い、的を絞った用語は、一般的な用語よりも情報量（ビット数）が多くなります。

クエリの残存サプライザルとは、その回答を得るために依然として残っている不確実性の量のことです。サプライザルがゼロに近づくにつれて、クエリはデータセットを 1 つ特定するのに十分な情報量があるとみなされるようになります。

Discovery Bench のアイデアの中核となるのは、この改良ループです。これは、サプライザルベースの反復クエリ改良（iSQR）と呼ばれ、情報提供力の高いケースと低いケースを生成して、エージェントがクエリに正しく回答できるようになる地点をテストします。

重要なのは、評価ケースに組み込まれた課題を調整によって制御できるようにすることです。質問ごとに 1 つの固定された表現を使用するのではなく、同じ質問を調整された 3 つの曖昧性レベル（高、中、低）で生成し、それぞれを（主観的な意見ではなく）ビット数に基づいてグラウンディングします。単語が追加または削除された理由を、用語ごとに説明することもできます。難易度は、感情や分類に基づくプロパティではなく、構築されるプロパティになります。

見えていなかった崖

次に、Discovery Bench の難易度ダイヤルで明らかになったことと、単一フレーズのベンチマークでは構造的に不可能であったことを説明します。

Google には、再現率を重視して構築された F1 エージェント（Gemini 3.1 Pro 上）があります。これを KramaBench に対して、曖昧性レベルのスイープを実行すると、曲線が得られます。曖昧性が高の場合は 0.34、標準の場合は 0.76、中の場合 0.81、低の場合 0.78 です。

すぐに 2 つの知見が得られました。これらはどちらも、従来の評価では得られなかったものです。

まず、崖があるということです。このクエリは、標準のフレーズでは F1 = 1.00 の完璧なスコアが得られましたが、曖昧性が高いフレーズでは 0.00 が得られました。これは、上述の衛星 48445 のケースです。識別トークン「TLE」を削除すると、エージェントはテーブルを検出できなくなります。同じクエリ、同じエージェント、同じグラウンド トゥルースでも、少しでも曖昧になると崖から落ちてしまいます。静的なベンチマークは、標準的な表現をテストし、「解決済み」のスタンプを押して平地であると報告しますが、実際には断崖があります。合格 / 不合格の評価では、崖が見逃されるだけでなく、平地であると報告されるため、特に誤解を招きやすくなります。

2 つ目は、スイート スポットです。Discovery Agent では、曖昧性が中のプロンプトの方が標準プロンプトよりも結果が良い場合や、曖昧性が低のプロンプトの方が標準プロンプトよりもパフォーマンスが低い場合がありました。評価対象のシステムにとって、特異性は高いほど良いというわけではなく、最適な調整量があるということです。これは、評価された、実用的なシグナルです。これが、スカラー評価には欠けていた「どれだけ離れているか、どれだけ難易度が高いか」という特性です。これにより、エージェントのどの部分を改良すべきかがわかります。このケースでは、時間でシャーディングされたテーブル（回答が 2 つのテーブルである場合にエージェントがほぼ同一のシャード 21 個を過剰に取得すると、精度が約 8% に低下）や、コンテキストの急増（クエリが長い検索チェーンをトリガーすると、F1 が 0.75 から 0.32 に低下）などの具体的な失敗モードが直接示されます。このマップには、エージェントが失敗したことだけでなく、その場所と理由も示されます。（用語の調整により）曖昧さを減らし、コンテキストを増やすことで取得が改善するという仮説は一般的には当てはまりますが、今回使用した特定の Discovery Agent では、特有の「スイート スポット」があることから、実装におけるトレードオフが明確に示されました。

分野全体での傾向

この分野はメタ ベンチマークを使用する方向に収束しつつあり、エージェントにどのように負荷をかけ、評価するかをより細かく制御できるようになってきています。項目反応理論（標準化されたテストの背後にある潜在能力モデル）を使用して、難易度をラベルではなく測定量として扱う研究が増えています。tinyBenchmarks と metabench は、少数の情報量の多い項目でモデルのフルスコアを再現できることを示しており、PSN-IRT はベンチマークの品質自体にも同じ考えを適用しています。また、グラウンド トゥルースを直接監査する研究もあります。MMLU-Redux では、大規模マルチタスク言語理解（MMLU）の質問の 6.49% に誤ったラベルが付けられていることがわかりました。Platinum Benchmarks では、ラベルエラーと曖昧さの両方を最小限に抑えるために 10 個のデータセットを再クリーニングしました。これらは、Google がスイープするのと同じ 2 つの軸です。また、曖昧性はノイズではなく本質的なものとして扱われることが増えています。AmbigQA では、実際の質問の大部分に複数の解釈があることが示され、後の研究では、見かけ上のハルシネーションは、モデルの失敗ではなく、クエリの曖昧さに起因することが多いと報告されています。他では見られないのは、情報理論的な曖昧性をエンタープライズのライブデータに対してメタ ベンチマークとして適用するという組み合わせです。

信頼していたベンチマークが機能しなくなった

最初の評価は、この分野で確立されたベンチマークである kramabench-astronomy を基に構築しました。他のチームも、独自の評価にこのベンチマークを利用していました。チームはこのデータセットからベンチマークを派生させていましたが、時間の経過とともに微妙な問題が発生するようになった可能性があると仮定しました。Gemini の助けを借りて、チームが使用したベンチマークを実際に読んでみると、重要な問題があることがわかりました。グラウンド トゥルース テーブルがクエリに回答しない、質問の 124 個のシャード テーブルが一部のチームの検索 API で返せる数を超えている、正確な日付が必要なのに月が指定されているなどです。グラウンド トゥルースが気づかないうちに壊れていたということは、今回だけでなく、それに基づいて構築されていた以前の分析についてもすべて、結果が間違っていたということです。

これが一般的な問題の核心です。評価自体が欠陥のあるアーティファクトであり、それを評価する人はほとんどいません。エージェントを計測し、計測ツールを信頼しますが、その計測ツールが正しいことはどこで検証すればよいのでしょうか。

2 つのマップが一致しない場合

ここに再帰的な問題があります。難しさが生成されるものであるなら、生成器自体を評価する必要があります。生成器を盲目的に信頼すべきではありません。

そこで、同じ曖昧性スイープを 2 つの方法で構築しました。1 つは純粋な LLM の推測から用語を調整する方法、もう 1 つは TF-IDF サプライザルに基づいて用語をグラウンディングする方法です。この 2 つの結果は大きく異なりました。曖昧性が高い場合、LLM で構築されたスイープでは F1 のエージェントのスコアは約 0.34 でしたが、グラウンディングされたスイープでは約 0.85 でした。これらのマップのどちらかが大きく歪んでいます。予想どおり、グラウンディングされた方法の方がより堅牢です。サプライザルにより、グラウンディングされていない LLM にはない基盤が与えられるからです。

これは「評価ツールの評価」を具体化したものです。情報理論の視点からは、エージェントを連続軸に沿って評価するだけでなく、ベンチマーク自体の構築も評価し、両者を判定します。

評価ツールを評価する

Google は何年もかけて、測定したことのない測定ツールに対してエージェントを最適化してきました。皮肉なことに、モデルが優れているほどこの問題は悪化します。エージェントが大まかなベンチマークをクリアすると、スコアは上限近くで飽和し、試験によってエージェントの改良可能な部分を示すことができなくなります。

そのため、必要な行動は心地よいものではなく、遅きに失しています。評価ツールを評価することが必須です。グラウンド トゥルースを確認することが重要です。難易度をラベルではなく測定量として扱い、スイープしてプロットし、システムが機能しなくなるビット幅を見つけます。「合格したか」だけでなく、「合格からどれだけ離れていたか、どれだけの余裕を持って合格できたか、少し曖昧な質問をしたらどうなるか」を尋ねます。判定だけではなく、シグナルを生成する評価を構築します。

ここで、じっくりと考えるべき対立があります。難易度をエントロピーと捉えると、その信頼性はエントロピーを推定するモデルの信頼性に依存します。測定可能な代理の指標を過度に重視すると、エージェントではなく評価ツールを最適化することになるというリスクがあります。でも、これは合格 / 不合格の試験に後退する理由にはなりません。評価対象となるエージェントと同じ精密な調査を、評価ツールにも適用する必要があるということです。誰が評価ツールを評価するのか尋ねるのをやめれば、マップは再び役に立たないものになります。

^{1. Maia Polo, F. 他著『tinyBenchmarks: Evaluating LLMs with Fewer Examples』 ICML 2024 年、arxiv.org/abs/2402.14992}

^{2. Kipnis, A. 他著『metabench: A Sparse Benchmark of Reasoning and Knowledge in Large Language Models』 ICLR 2025 年、arxiv.org/abs/2407.12844}

^{3. 『Lost in Benchmarks? Rethinking Large Language Model Benchmarking with Item Response Theory』（PSN-IRT）、AAAI 2026 年、arxiv.org/abs/2505.15055}

^{4. Gema, A. P. 他著『Are We Done with MMLU?』（MMLU-Redux）、2024 年、arxiv.org/abs/2406.04127}

^{5. Vendrow, J. 他著『Do Large Language Model Benchmarks Test Reliability?』(Platinum Benchmarks)、2025 年、arxiv.org/abs/2502.03461}

^{6. White, C., Dooley, S. 他著『LiveBench: A Challenging, Contamination-Limited LLM Benchmark.』 2024 年、arxiv.org/abs/2406.19314}

^{7. Min, S. 他著『AmbigQA: Answering Ambiguous Open-domain Questions.』 EMNLP 2020 年、aclanthology.org/2020.emnlp-main.466}

^{8. Lai, E., Vitagliano, G. 他著『KramaBench: A Benchmark for AI Systems on Data-to-Insight Pipelines over Data Lakes』 2025 年、arxiv.org/abs/2506.06541}

- データ クラウド フロンティア AI、ソフトウェア エンジニア、Manav Garg

- データクラウド フロンティア AI、テクニカル リード、Sunil Pedapudi