Grounded Reasoning CupにおけるAIエージェントのライブ評価

今年、Databricksは、複雑な企業スタイルの文書コレクションに対して推論するAIエージェントの能力を評価する、初のライブAIコンペティションである第1回Grounded Reasoning Cupを開催しました。ライブのコンペティション環境下で、新たに公開されたコーパスを用いてエージェントをテストすることにより、Grounded Reasoning Cupは、AI評価における最も難しい問いの1つに答えることを目指して設計されました。それは、「ベンチマークにおけるパフォーマンスの向上が、同様の現実世界のタスクにどの程度一般化されるか」という問いです。

このコンペティションには、U.S.とカナダ全土から11のトップアカデミックチームが集まり、OpenAI、Anthropic、Google DeepMindなどの最先端の研究所（フロンティアラボ）からのリソースやメンターシップが提供されました。2ヶ月間にわたり、各チームは、経済的に価値のある企業のワークフローを反映するように設計された当社の主要な根拠に基づく推論（grounded-reasoning）ベンチマークであるOfficeQA上で、エージェントの開発と最適化を行いました。コンペティション当日、チームは、開発したシステムをリアルタイムで、新たに公開された根拠に基づく推論ベンチマークであるOfficeQA Pro V2に適用し、改善されたパフォーマンスが一般化されるかどうかをテストする課題に挑みました。

スタンフォード大学（Stanford）が63.3%の精度を達成したシステムで優勝し、平均的なチームを約+22ポイント、オフラインの平均的なフロンティアエージェントのベースラインを約+35ポイント上回りました。上位チームは、文書の前処理、ターゲットを絞ったリトリーバル（検索）、並列エージェント、構造化されたツールの使用、および検証を通じて、大幅なパフォーマンス向上を示しました。同時に、全チームが解決できなかった問題が18.8%あり、企業の根拠に基づく推論において、依然としてどれほどの改善の余地（ヘッドルーム）が残されているかが浮き彫りになりました。

このブログ記事では、コンペティションを振り返り、Grounded Reasoning Cupの優勝・上位チームであるスタンフォード大学（Stanford）、マサチューセッツ大学アマースト校（University of Massachusetts Amherst）、イェール大学（Yale）によるエージェントの最適化戦略とインサイトについて解説します。

全体として、以下のようなことがわかりました。

• 一般化には、代表的でホールドアウトされた評価が必要です。 OfficeQAで開発された手法が、新しいベンチマークに常に高い信頼性で引き継がれるとは限りませんでした。このことは、ソリューションが新しい例に一般化できるかを確認するために、OfficeQA Pro V2のようなホールドアウトされたテストセットを活用することの重要性を強調しています。
• エージェントのパフォーマンスは、モデルだけでなくシステム全体に依存します。 同じモデルを使用した最高スコアのチームと最低スコアのチームの平均的な差は30.4ポイントでした。パース（解析）、リトリーバル（検索）、ツールの使用、検証、並列処理、および運用インフラのすべてが、エージェントがエンドツーエンドの根拠に基づく推論タスクを正常に完了できるかどうかの分かれ目となりました。
• 企業の根拠に基づく推論は、依然として解決にはほど遠い状態です。 優勝チームでさえ、ベンチマークのリトリーバル、パース、分析における多くの要求に苦戦しており、継続的な研究と改善の余地が大きく残されています。この取り組みをさらに進めるために、実務者の皆様には公開されているOfficeQAベンチマークスイートを活用することをお勧めします。

コンペティションのセットアップ

Grounded Reasoning Cupの目的は、トップのアカデミックチームを集め、根拠に基づく推論（grounded reasoning）に対する一般化可能なアプローチを開発することでした。これは、大規模で、多くの場合社外秘である文書コレクションからの証拠を用いて複雑な質問に答えるという、企業環境でよく見られるタスクです。

学術機関を代表する2〜4人のチームが、OpenAI、Anthropic、またはGoogle DeepMindの業界パートナーとペアになり、開発期間中、モデルへのアクセスやメンターシップの提供を受けました。チームには、エージェントを動かすためにパートナーラボのモデルファミリーのみを使用するという1つの制約のもと、適切と思われるあらゆるアプローチを使用してエージェントを構築するために約2ヶ月の時間が与えられました。この期間中、彼らはOfficeQAベンチマークを使用して、同様の根拠に基づく推論タスクに一般化できると考えられる新しい手法を評価しました。

コンペティション当日、チームは新たに公開されたばかりのベンチマークに、リアルタイムでエージェントを適用する課題に挑みました。コンペティションは以下のルールに基づいて運営されました。

• ベンチマークの公開： 新しいコーパス（U.S.財務省の「Accounts of Receipts and Expenditures」）は、コンペティションのわずか36時間前に公開されました。これにより、チームにデータの処理とインデックス作成の時間を与えつつ、新しいベンチマークに手法が過学習（オーバーフィット）する機会を制限しました。
• 設計上の制約： 割り当てられた業界ラボパートナーのモデルを使用する限り、チームは任意のエージェントフレームワーク、コーパスのバージョン、リトリーバル戦略、ツールの使用設定、またはヒューマンインザループ（human-in-the-loop）のワークフローを使用することができました。
• フォーマット： コンペティションは、1ラウンド15分、各ラウンド15問の計6ラウンドで構成されました。イベントの進行に伴い、ラウンドは段階的に難しくなりました。
• スコアリング： 正解ごとに1ポイントが与えられました。低遅延（低レイテンシ）を促すため、特定の質問に最初に正解したチームには0.25ポイントのスピードボーナスも与えられました。最も難易度の高い質問で構成される最終ラウンドでは、ポイントが2倍になりました。また、各チームはコンペティション全体を通じて3回までの再提出が認められており、以前の回答を修正するために適用することができました。

チームのパフォーマンスと学び

このコンペティションによって、1つのことが明らかになりました。企業スタイルの文書コーパスに対する根拠に基づく推論は、7ヶ月前にOfficeQAベンチマークを公開して以来向上しているものの、依然として解決にはほど遠いということです。平均チームスコアは約41%で、上位3チームは精度50%を超え、スタンフォード大学（Stanford）チームが63.3%の精度でコンペティションを制しました。これらの結果は、上位チームによる素晴らしい成果を示すと同時に、探索すべき改善の余地がまだ十分に存在していることを示しています。

優勝・上位チームの戦略

それぞれが独自のアプローチをとっていましたが、上位3チームが構築したエージェントにはいくつかの共通パターンが見られました。優れたシステムは、入念な文書の前処理、ターゲットを絞ったリトリーバル、構造化されたツールの使用、および回答の検証ステップを組み合わせる傾向がありました。多くの場合、パフォーマンスは単一のモデル呼び出しよりも、文書がどのようにパースされたか、証拠がどのように取得されたか、中間計算がどのように実行されたか、提出前に回答がどのように検証されたかといった、周囲のシステム全体に依存していました。これらは最もパフォーマンスの高いシステムに一般的に共通する特性でしたが、以下に示すように、各チームはそれぞれ独自で創造的な戦略も採用していました。

1st Place: スタンフォード大学（Stanford University）

スタンフォード大学チームの勝利へのアプローチは、根拠に基づく推論における一般的な失敗パターンを、彼らのClaude Opus 4.8 Claude Codeエージェントが学習してコンペティションの問題に適用できる、再利用可能な運用手順に変換することから生まれました。公開されているOfficeQAベンチマークでの開発中（Opus 4.8や、利用可能だったFable 5を用いたアブレーション実験を含む）、チームは誤答の原因をエージェントの正確なミスステップまで繰り返し追跡し、それらのパターンをテーブルのローカライズ、回答のフォーマット、一般的な財務用語の明確化などのスキルに変換しました。また、パースされたコーパスのテキストとMarkdown形式の文書表現のどちらを検索するか、またパースされたテキストに完全なコンテキストが不足している場合にいつソースPDFにフォールバックするかを決定するスキルも統合しました。コンペティション当日までに、スタンフォード大学は100以上のスキルからなるプレイブックをエージェントに用意していました。彼らは、挑戦した88問中57問の正解を導き出し、正解率で全チームをリードしました。

このような徹底的な準備にもかかわらず、スタンフォード大学は大会中に戦略を適応させる必要がありました。最初の3ラウンドでは、同チームは別のClaude Codeエージェントを検証器（verifier）として使用し、中間値の再抽出、データリネージによる修正値の追跡や単位スケーリングの処理といった一般的な失敗パターンのチェック、そして不一致が検出された場合の計算の修正を行いました。しかし、これらのラウンドでスピードボーナスを2回しか獲得できなかったため、スタンフォード大学は最後の3ラウンドで追加の検証パスを削除しました。この変更によりレイテンシが大幅に削減され、チームは14の質問でスピードボーナスを獲得し、逆転劇を後押ししました。それにもかかわらず、最終ラウンドでは検証器が決定的な役割を果たしました。スタンフォード大学は検証器を再び有効にして、最後の再提出で回答を修正し、最終的に勝利を確実にしました。

2位：マサチューセッツ大学アマースト校（UMass Amherst）

UMassチームはスピードに賭けました。彼らは主要モデルとしてClaude Opus 4.8 Fastを使用し、コーパスを前処理してメタデータカタログを作成することで、パースされたドキュメントに対する迅速な検索とフィルタリングを可能にしました。低レイテンシを維持しながら回答の品質を向上させるため、各質問に対して3つのエージェントを並行して実行し、最後にOpusの検証コールを行って最適な回答を選択しました。

この戦略により、UMassは正解に対する平均提出時間が4分と最も速くなり、これは全チーム平均の8分30秒の半分以下でした。その結果、最初に正解したチームに与えられるスピードボーナス（1回あたり0.25ポイント）を36回獲得しました。これは、2位のスタンフォード大学の合計16回の2倍以上です。これらのボーナスにより、ハーフタイムまでにスタンフォード大学に対して10.25ポイントのリードを築き、3.75ポイントのアドバンテージを維持して最終ラウンドを迎えました。UMassは大会の残り56秒までそのリードを保ちましたが、最も困難な質問において、スタンフォード大学の処理は遅いもののより正確なエージェントが決定的な役割を果たし、逆転して1.75ポイント差で勝利しました。

UMassのアプローチは、高速なモデル、ドキュメントの前処理、およびテスト時スケーリング（test-time scaling）を組み合わせることで、精度を大きく犠牲にすることなく、極めて低いレイテンシを実現できることを示しています。

3位：イェール大学（Yale University）

イェール大学チームは、個々のエージェントが失敗した場合でも堅牢性を維持できるように設計された、マルチアーム検証ハーネスを構築しました。このシステムは、2つのエージェント戦略にまたがる4つの独立したアームを並行して実行しました。2つのアームは自律的なReActエージェントを使用し、一方はGemini 3.1 Pro、もう一方はGemini 3.5 Flashを搭載していました。残りのアームは、より構造化されたプランナー・検証器（planner-verifier）パイプラインを使用し、すべてのLLM呼び出しにGemini 3.1 Proを使用しました。このパイプラインでは、プランナーがソースドキュメントを検査して文脈化し、質問に答えるために必要な根拠を含むスクラッチパッドを組み立てました。その後、検証器が引用されたソースを確認し、最終的な計算を行いました。

Gemini 3.1 Proのメタ検証器が、4つのアームすべてによって生成された回答と推論をレビューし、最終的な回答を選択しました。根拠のない新しい回答が導入されるリスクを減らすため、メタ検証器は既存のアームのいずれかによって提案された回答のみを選択できました。それができない場合、システムは多数決にフォールバックしました。独立し、部分的に非相関化された失敗モードを持つ異なるエージェントアーキテクチャを組み合わせることで、イェール大学は一貫した、根拠に基づく検証を重視しました。このアプローチにより、チームは90問中49問に正解し、大会の6ラウンド中4ラウンドで正解率トップ3に入り、3位を獲得しました。

優勝チームの戦略のまとめ

これらの勝利アプローチから得られる主要な教訓の1つは、エンドツーエンドの根拠に基づく推論（grounded reasoning）タスクにエージェントを正常に適用するには、モデルの選択だけでなく、全体的なシステム思考が必要であるということです。勝利したアプローチ全体を通じて、いくつかの重要な設計レバーが特に重要として際立っていました。

• パース品質：上位チームは事前にパースされたドキュメントを使用し、これらのパースされた表現を拡張して追加のメタデータ（チャートの説明やページレベルのメタデータなど）を含めたり、パースされたテキストが不完全な場合にフォールバックするためのソースPDFへのパスを保持したりすることがよくありました。OfficeQA Pro V2に関する独自の調査では、ai_parseを使用してドキュメントを事前にパースすることが、ベースラインのフロンティアエージェントに対するGenieの24.0ポイントのパフォーマンス向上に大きく貢献していることがわかりました。
• 検索品質：強力なシステムは、一般的なtop-kチャンク検索に依存していませんでした。代わりに、何らかの形式の語彙検索（grepなど）を使用し、ハイブリッドアプローチのために高密度検索（dense retrieval）と組み合わせることがよくありました。
• ツールの使用：成功したエージェントは一般に、検索、ドキュメントの検査、計算、比較、および提出を専用のツールに委任していました。
• 検証戦略：いくつかのチームは、回答の品質を高めるために、検証エージェントまたはLLM呼び出しを介した何らかの形式の明示的な検証チェックを組み込みました。
• 堅牢なハーネス：リアルタイムの締め切りのプレッシャーの下では、前処理、リトライロジック、並列処理、提出用足場（submission scaffolding）などの運用上の詳細が、正しい回答が実際に時間内に届くようにするために必要でした。

これらの要因が、モデルが締め切りのプレッシャーの下で、適切な根拠を確実に見つけ、適切な計算を行い、適切な回答を提出できるかどうかを決定しました。

影響と次のステップ

要約すると、Grounded Reasoning Cupの結果は、より広範な多くの教訓を示しています。

• 汎化は想定するものではなく、テストされるべきものです。OfficeQAでの改善が必ずしもOfficeQA Pro V2に引き継がれるわけではなく、フロンティアエージェントは平均してその質問の半分未満しか正しく回答できませんでした。使い慣れたベンチマークでの進歩が、必ずしも新しいコーパスやタスクの分布に反映されるとは限りません。
• 代表的なホールドアウト評価が不可欠です。これらは、重要な汎化の形態を評価する必要があり、理想的にはタスクの核心的な性質（すなわち、ドキュメントに対する根拠ある推論）を固定したまま、コーパスのように変更可能なタスクの要素を変化させるべきです。OfficeQA Pro V2について説明した投稿では、顧客のワークフローに関する知識と合成データを組み合わせて、これらの代表的な評価を迅速に拡張する方法について説明しています。
• エージェントのパフォーマンスはシステム全体に依存します。パフォーマンスはモデルだけでなく、パース、検索、ツールの使用、検証、および基盤となるデータとインフラストラクチャの品質にも依存します。勝利したチームは、これらのコンポーネントを全体的に最適化しました。同様に、ドキュメントを事前にパースするためにai_parseのようなツールを使用し、追加のハーネス最適化戦略を使用する場合、Genieはベースラインのフロンティアエージェントを大幅に上回ります。

Databricksが初めて開催したGrounded Reasoning Cupに参加し、この分野の発展に貢献してくださった、OpenAI、Google DeepMind、Anthropicを含むすべてのチームと業界スポンサーに感謝いたします。また、新しいコーパスの特定やOfficeQA Pro V2の関連する質問の作成へのご協力から、大会自体での提携に至るまで、継続的なパートナーシップを築いてくださったUSAFactsにも感謝いたします。最後に、大会ベンチマークの基礎として「U.S. Accounts of Receipts and Expenditures（米国歳入歳出勘定）」の特定を支援し、このデータセットを初めてまとまったコレクションとして公開してくださった米国財務省に感謝いたします。

著者：Krista Opsahl-Ong、Arnav Singhvi、Josh Joseph、Jasmine Collins、Ivan Zhou、Brooke Wenig、Denny Lee、Michael Bendersky、Erich Elsen、Xing Chen、Matei Zaharia

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事