腾讯混元ら、製品原型の AI 智能体評価ベンチ「E-Bench」を共同発表

腾讯混元 2026-08-03 20:35 广东

王者荣耀、QQ 音乐、腾讯会议……AI 智能体迎来一场“大考”

腾讯混元团队联合清华大学智能产业研究院（AIR）与东南大学计算机科学与工程学院，以腾讯真实业务场景为原型推出了 E-Bench。这项基准测试旨在为 AI 智能体设计一场公平的考核。

论文标题：E-Bench: Benchmarking Multi-Step Tool-Use Agents in Real-World Product Scenarios

论文地址：https://arxiv.org/abs/2607.23722

试想这样一个场景：你让 AI 帮你做一件事——在 QQ 音乐里，把最近播放列表中的所有周杰伦歌曲收集起来，创建一个新歌单，然后分享给最好的三个朋友。听起来很简单，对吧？

但对当下的 AI 智能体而言，这件“小事”实则是一连串环环相扣的考验：它必须先翻遍你的播放历史找出所有周杰伦的歌（一首都不能漏），接着新建歌单、批量添加歌曲，再判断谁是你“最好的三个朋友”，最后逐一完成分享。任何一步出错、遗漏或顺序混乱，整件事就算失败——而且不存在“部分正确”这种说法。

即便是当今能力强大的人工智能模型，在面对此类多步骤任务时，平均仍有近一半的概率会出错：

• 能力较强的模型成功率仅为 73.79%；
• 11 个前沿模型的平均成功率只有 54.56%，这意味着一个典型智能体单次尝试失败率接近一半；
• 在要求“稳定靠谱地完成”（Pass³，即同一任务三次独立尝试全部成功）的严苛标准下，最强模型的成功率也仅有 58.82%。

图：各模型在 E-Bench 与 E-Bench-Code 上的成本—性能对比（性价比）：横轴为每任务 API 成本，纵轴为 Avg@3

这正是 E-Bench 试图回答的问题：当 AI 不再只是“聊天问答”，而是要真正帮你“动手办事”时，它们到底行不行？答案令人担忧——远未解决。

AI 智能体的「听说读写」困境

大模型正从“回答一个自包含的问题”，走向“作为智能体（Agent）与外部环境进行多步交互、完成复杂任务”。

要真正做成一件事，模型给出一个看似合理的回答是远远不够的。它必须反复执行以下四件事：

1）识别当前还缺哪些信息 ➡️ 2）决定该调用哪个工具去获取 ➡️ 3）跨多个步骤整合观察到的结果 ➡️ 4）把改动写回一个有状态的环境。

この能力は「多段階ツール使用（Multi-Step Tool Use）」と呼ばれ、現在最も価値ある実装シーンの基盤となっています。具体的には、ソフトウェアの操作、データベースへの照会、業務フローの編成などが該当します。

単なる「回答」から「行動」へと移行するには、全く異なる評価手法が必要です。既存のエージェント評価ベンチマークはこの分野の発展を促してきましたが、普遍的に存在する 3 つの盲点があります。

1. 「単発・短距離」の評価に限られている：多くの場合、孤立した API 呼び出しや極めて短いインタラクション軌跡、あるいは環境状態を変更しない静的な質問応答に焦点が当てられています。これでは、「部分的な観測可能性」「多様なツール」「長期的な依存関係」「正確な状態変更」という条件下での真の能力を評価できません。

1. 実システムに基づくベンチマークはスケーラビリティと汚染防止が困難：コストが高く、注釈付けが難しく、データセキュリティやプライバシーの制約を受けます。また、オンラインサービスの進化に伴って再現性が低下します。さらに厄介な点は「汚染」を防ぎにくいことです。タスクが公開された事実や誰もが熟知したインターフェースに依存している場合、モデルの高いスコアは「実際にツールを使って隠れた状態を取得したから」ではなく、「過去に見たことがあるから」という結果である可能性があります。

1. 合成環境が「過度にクリーンすぎる」：手間を省くため、多くの合成環境には「タスクに必要な数行のデータ」しか含まれていません。データ量が少なくノイズも指向性も強いため、モデルは検索ですぐに目標にヒットし、検索結果が非現実的に綺麗になります。これは実質的に「答えを漏らしている」状態であり、「正確に推測できるか」を試すものであって、「膨大な情報の中から本当に全てを見つけ出せるか」を試すものではありません。実際の製品ではその逆で、データは膨大でノイズも至るところに存在し、これ自体が難易度の重要な源泉となっています。

信頼性の高いベンチマークとは、モデルが意図的な推論を迂回して「近道」を行えないよう、完全かつ制御された環境を提供すると同時に、低コストで拡張可能であるべきです。

核心の解明——E-Bench はどのように「公平な試験」を設計したか

E-Bench は、3 つの実在する製品を原型とした全合成仮想世界で出題を行います：

🎮 王者栄耀（王者荣耀）：MOBA ソーシャルプラットフォーム。友達追加、ブラックリスト管理、ルームの作成・解散、ルーム招待の送受信、チーム申請の承認、対局のお気に入り登録、ヒーロー購入など。

🎵 QQ 音楽：音楽コンテンツプラットフォーム。曲・歌手・アルバムの検索、プレイリストの作成と削除、曲の追加と削除、お気に入り登録、歌手へのフォローなど。

📅 テンセント会議（腾讯会议）：企業コラボレーションプラットフォーム。会議の作成、会議室の予約、スケジュールの作成、会議のキャンセル、グループメンバーの管理、部門間の異動など。

これらは合計 323 の「状態変更」タスクで構成され、41 個のデータベーステーブルと 76,000 行超のデータ、60 万を超えるデータユニットをカバーしています。各領域は孤立したツールのスタックではなく、一貫性のある「製品の世界」として設計されています。

図：3 つの環境における代表的なタスク例

「エージェント評価」の再定義

E-Bench の最も重要なステップは、構築プロセスを「環境合成」と「タスク合成」の 2 つの独立した段階に分離することです。各タスクごとに個別の状態スナップショットを作成するのではなく、まず各領域に対して再利用可能で完全にシミュレートされた製品環境を構築し、その共有環境の上でバッチ処理によりタスクを生成します。

環境はどのように作成されるのでしょうか？それは「グラフ誘導型データベース充填（Graph-Guided Database Filling）」によって行われます：

• リレーショナルスキーマから出発して、テーブル間の依存関係をグラフ化します。
• 主キー・外部キー制約を持つ空のデータベースを初期化し、外部キーチェックを有効にします。
• トポロジ順序に従ってデータを充填します。まず根となる表（歌手、部署、会議室など）を生成し、それらに依存する下流テーブルを後から作成します。
• 強力な LLM を制約付き合成器として使用し、自由なデータベース生成は行いません。データの挿入はツール経由でのみ可能であり、下流テーブルは現在のデータベースから候補エンティティを検索して参照する必要があり、ID をでっち上げることはできません。

最終的には、決定論的なスクリプトを用いて検証と修復を行います。これにより、時間順序の修正、集計数の統合、状態フィールドなどの意味的な誤りを正します。

このプロセスを通じて、孤立したレコードが存在せず、テーブル間の一貫性が保たれ、データが豊富でツールとの対話も可能な製品の状態空間が構築されます。E-Bench の各データベースはより大規模に拡張され、対象となるエンティティは構造が類似し意味も近い多数の記録に囲まれます。これにより、モデルは「データベースには数件しかない」といった推測で正解を当てることはできなくなります。十分な文脈の中で真に検索・フィルタリング・比較を行い、初めて完全な目標集合を構成することが可能になります。

環境が完全に整い、自己完結しており、実際の規模に近いからこそ、タスクの難易度は「どのデータを取得すべきか」「どのように状態を変更すべきか」という点に集中します。モデルは環境の希薄さや欠落を利用して近道をするわけにはいかず、その結果として得られる評価結果は信頼性が高まります。

出題方法：出題者と解答者の能力に非対称性を生み出す

タスクが「環境と相互作用しなければ解決できない」状態をどう保証するか。それは、出題側が解答側よりも圧倒的に「多くを見渡し、多くの計算を行える」という、綿密に設計された能力の非対称性によって実現されます。

• 出題モデルの特権: 完全なデータベースへのアクセス権を持ち、SQL やコードを実行可能
• 被験モデルの制限: 試験中は限定的なドメインツールを通じてのみ環境を観察でき、これは実際の使用シーンに即したものです

これにより、自然と二つの「溝」が生まれます。

●情報格差（Information Gap）

被験モデルにとってはグローバルなデータベースの状態が隠されており、プロンプトだけを見て回答することは不可能です。「意図の書き換え」というステップを通じて、データベースから派生した具体的な値は、その値を生み出したルールに置き換えられます。例えば、「お気に入りのリストにある販売終了曲をすべて追加して」のように表現され、直接 ID や数を列挙するわけではありません。これは、モデルが行動を起こす前に完全な情報集合を収集できるかどうかを試すものであり、断片的な証拠に基づいて安易に行動に移さないかを問うものです。

●ツール格差（Tool Gap）

出題モデルは計算能力が高く、ページネーション、集計、集合演算、多段のトリアージ、連鎖的な書き込みなどが可能です。しかし、試験時にはこれらの内部ツールは排除され、被験モデルが使用できるのは業務レベルのツールのみです。目標を再現するには、正しい組み合わせと順序で複数のステップ（多くの場合並列実行される）をツール呼び出しとして実行する必要があります。

この二つの格差に基づき、E-Bench は以下の 6 つのカテゴリ的能力を定義しています：全量データ取得、多条件フィルタリング、集計と計算、ステップ間の依存関係、正確な境界判定、エンティティ間のカスケード処理。各タスクは「データの閲覧→目標の特定→状態の変更→意図の要約」という製品化されたサイクルを経て生成され、3 つの異なる強力なエージェントモデルによってクロス検証されます（少なくとも 2 つが再現結果を一致させた場合にのみ採用されます）。

図：出題モデルと被験モデルの間の能力格差

評価方法：決定論的なデータベース状態の違い

E-Bench は決定論的なルールに基づいて判断を行います。各タスクには「正解」として、出題モデルが操作を行う前後のデータベース状態の差分（diff）が紐付けられています。評価時には、エージェントの最終的なデータベース状態がこの標準的な diff と完全に一致した場合のみ、そのタスクは合格とみなされます。部分的な採点はありません。全体的な平均では、1 つのタスクあたり 24.9 箇所の行レベルの変更が発生し（最多で単一タスク 221 箇所）、この評価方法は安定しており再現性が高く、意味的な判定者のばらつきにも影響されません。

また、E-Bench には拡張版として E-Bench-Code も用意されています。これは被験モデルに exec_code ツールを開放し、ドメインツールを関数として呼び出して Python コードを実行できるようにするものです。これによりツール格差は解消されますが、情報格差は残されたままです。そのため、「難易度の要因が『オーケストレーション（編成）の仕組み』にあるのか、『どのデータを取得すべきかという思考』にあるのか」を明確に分離して分析することが可能になります。

11 社のトップモデルの評価結果と主要な発見

E-Bench は、GPT-5.5、Opus-4.8、Grok-4.5、GLM-5.2、Qwen-3.7-Max、Hy3、Seed-2.1-Pro、Gemini-3.5-Flash、MiniMax-M3、Kimi-K3、DeepSeek-V4-Pro の 11 台の最先端大規模モデルを評価対象としました。各タスクは独立して 3 回実行され、毎回完全に新しいデータベースのコピーからスタートします。

発見その 1：最強のモデルであっても、まだ改善の余地が十分にあります。基本版 E-Bench における 11 台モデルの平均スコアはわずか 54.56% です。

発見その 2：信頼性が最大のボトルネックです。「安定して確実に完了できる」割合は、最強のモデルでも 58.82% に留まりました。

発見その 3：コード実行能力は全体的に向上しましたが、依然として信頼性の制約があります。最も優秀な Pass³（Opus-4.8）でさえ、70% を下回っています。

発見その 4：高性能なモデルほどコストも高い——製品化において避けて通れないのがこのコスト問題です。腾讯混元 Hy3 はコスト面で優位性を示しました。各タスクあたりの費用は全 11 台モデルの中で最低水準（E-Bench では約$0.053、コード実行を有効にするとさらに約$0.029まで低下）でありながら、E-Bench-Code において 64.40% の Avg@3 を達成。コストを抑えつつ性能も損ないません。

特筆すべきは、コード実行機能をオフにしても、Hy3 は基本版 E-Bench で複雑な長連鎖タスクを確実に処理できる点です。例えば、編成能力が最も問われる「腾讯会议」の領域では、Hy3 は参加者選択→スケジュール検索→会議室予約→会議作成→カレンダー更新→グループチャット作成という、複数のエンティティにまたがり環状に連なる一連の操作を、一気呵成に完了させました。

重要な洞察

「データ量が多く、ノイズも豊富」であること自体が難易度の要因です。モデルの差を明確に決めるのは、タスク説明がいかに複雑かではなく、環境内に存在する無関係な情報の多さです。E-Bench のデータベースには 7.6 万行以上、60 万以上のデータユニットが含まれており、目的とする情報が大量の類似レコードに埋もれています。モデルは繰り返し検索・フィルタリング・照合を行い、初めて完全な目標セットを揃えることができます。これが「早期行動」が最も一般的な失敗パターンである理由です。モデルができないからではなく、情報が不十分な状態で手を動かしてしまうのです。データ規模と文脈の豊かさが、「本当に全てを見つけられるか」を試す試金石となっています。

優れたエージェントは単に「作業ができる」だけでなく、「安価でなければならない」ことも求められます。能力とコストはセットで評価すべきです。E-Bench では多くのモデルが高性能ですが、タスクあたりのコストが高額になるケースも少なくありません。真に製品価値があるのは、高正確率と低コストの両立を果たすモデルであり、単に計算資源を積み上げるだけでは不十分です。

「何を取得すべきかを明確に理解しているか」こそが真のボトルネックです。E-Bench では成功率とツール呼び出し回数は正の相関を示します。呼び出し回数が少ない場合、探索が不十分なまま「早期行動」してしまった可能性があります。一方、E-Bench-Code では負の相関が弱く現れます。これは 1 つのコードブロックで複数の呼び出しを圧縮できるためです。「呼び出しが少ない＝作業量が少ない」とは限りません。これも E-Bench の設計思想を裏付けています。情報格差こそが最も硬い骨であるという点です。

コードは「難しいタスク」を救うものです。exec_code は、「多条件フィルタリング」「全量取得」「集計計算」のような計算集約型タスクにおいて最大の効果をもたらします。一方、「ステップ依存」「正確な境界判断」などの推論・意思決定タスクへの寄与は限定的です。コードが主にオフロードするのは計算であり、推論ではありません。

「環境の作成」と「タスクの作成」は分けて行うべきです。環境合成とタスク合成を解離させることが、このアプローチにおいて最も省力かつ付加価値の高いステップとなります。一度、完全で整合性があり再利用可能な製品環境が構築されれば、そこから約 100 のタスクを繰り返し出題することが可能になり、限界費用は極めて低くなります。また、環境が十分にリアルでデータ量が十分であれば、タスクの難易度は自然と「情報の非対称性」に依存するようになります。そのため、各問題ごとに手動でポイントを埋め込む必要はありません。これが E-Bench が環境レベルでは制御可能であり、タスクレベルでは拡張可能である理由です。

展望と今後の計画

E-Bench の価値：完全合成による「環境層の制御可能性」と「タスク層の拡張性」；決定論的な差分評価による「審判のばらつきに左右されない安定した評価」；再利用可能な環境により「1 つの環境で約 100 のタスクを支援」；二重の非対称性（双鴻溝）設計によって「モデルが能動的に隠された完全な情報を収集し、複数のステップや並列的なツール呼び出しを正しく組み合わせるよう促す」。

核心となる結論：多段階のツール使用は未だ解決されていません。最上位モデルでも Avg@3 は 73.79% に過ぎず、Pass³ は 60% を下回っています。コード実行が許可されている場合でさえ、最良の結果である Pass³ は依然として 70% を割り込んでいます。

今後の方向性：E-Bench を CLI（コマンドラインインターフェース）へ拡張し、より多くの製品バックエンドに対応させ、単一ドメインからクロスドメインのシナリオへと広げていきます。同時に、E-Bench を制御可能で拡張可能なトレーニングデータソースとして位置づけ、エージェントによる多段階ツール呼び出しの能力と信頼性を継続的に向上させることに活用します。

以下のリンクよりご参加ください：https://doc.weixin.qq.com/forms/AJEAIQdfAAoAa8ALgaVADMCNVsu10zNJf?page=1

WeChat で開く