Our Transformers Code Agent beats the GAIA benchmark 🏅

記事一覧に戻る

この記事は中国語版でもご覧いただけます 简体中文.

TL;DR

いくつかの実験の結果、Transformers Agentsによるエージェントシステム構築のパフォーマンスに感銘を受けたため、その実力を確かめてみました！GAIAベンチマークでライブラリで構築したCode Agentをテストしました。GAIAベンチマークは、おそらく最も困難で包括的なエージェントベンチマークであり、結果としてトップの成績を収めました！

このブログ記事で使用したフレームワーク transformers.agents は、現在スタンドアローンライブラリ smolagents にアップグレードされています！2つのライブラリのAPIは非常に似ているため、移行は簡単です。 smolagents の紹介ブログはこちらをご覧ください。

GAIA: エージェント向けの厳しいベンチマーク

エージェントとは？

一言で言うと、エージェントとはLLMを基盤とし、現在のユースケースに応じて外部ツールを呼び出すかどうかを判断し、LLMの出力に基づいてさらなるステップを反復するシステムです。ツールには、Web検索APIからPythonインタープリタまで、あらゆるものが含まれます。

視覚的な例えとして、すべてのプログラムはグラフとして表現できます。Aを行い、次にBを行う。If/elseの切り替えはグラフの分岐ですが、構造自体は変更しません。私たちはエージェントを、LLMの出力がグラフの構造を変更するシステムと定義します。エージェントはツールAやツールB、あるいは何も呼び出さないかを決定し、別のステップを実行するかどうかを決定します。これによりグラフの構造が変わります。LLM judgeのように固定ワークフローにLLMを統合しても、エージェントシステムにはなりません。なぜならLLMの出力がグラフの構造を変更しないからです。

以下は、Retrieval Augmented Generationを実行する2つの異なるシステムの図です。1つは古典的なもので、グラフは固定されています。しかし、もう1つはエージェント的で、グラフの1つのループが必要に応じて繰り返されます。

エージェントシステムはLLMにスーパーパワーを与えます。詳細は、Transformers Agents 2.0のリリースに関する以前のブログ記事をご覧ください。

GAIAは、エージェント向けの最も包括的なベンチマークです。GAIAの質問は非常に難しく、LLMベースのシステムの特定の難しさを浮き彫りにします。

トリッキーな質問の例を以下に示します：

2008年の絵画「Embroidery from Uzbekistan」に描かれた果物のうち、「The Last Voyage」という映画の浮遊小道具として後に使用された客船の1949年10月の朝食メニューに提供されたものはどれか？絵画内の配置に基づき、12時の位置から時計回りに並べ、コンマ区切りのリストで答え、各果物の複数形を使用せよ。

この質問にはいくつかの難しさが含まれていることがわかります：

• 制約された形式での回答。
• 画像から果物を読み取るマルチモーダル能力
• 相互依存する複数の情報の収集：
  • 絵画に描かれた果物
  • “The Last Voyage”の浮遊小道具として使用された客船の特定
  • 上記の客船の1949年10月の朝食メニュー
• 上記により、正しい解決軌道では複数の連鎖したステップが必要になります。

これを解決するには、高レベルの計画能力と厳密な実行の両方が必要であり、これらはまさにLLMが苦手とする2つの領域です。

したがって、これはエージェントシステムにとって優れたテストセットです！

GAIAの公開リーダーボードでは、GPT-4-Turboは平均で7%に達していません。トップの提出は（当時）OpenAIのツール呼び出し機能を利用した複雑なマルチエージェントシステムを備えたAutogenベースのソリューションで、40%に達しています。

それらに挑みましょう。🥊

適切なツールの構築 🛠️

GAIAの質問を解決するために、主に3つのツールを使用しました：

a. Webブラウザ

Webブラウジングについては、主にAutogenチームの提出からMarkdown Webブラウザを再利用しました。これには、現在のブラウザ状態を保持する Browser クラスと、visit_page、page_down、find_in_page などのWebナビゲーション用の複数のツールが含まれます。このツールは現在のビューポートのMarkdown表現を返します。Markdownを使用するとWebページの情報を大幅に圧縮できますが、スクリーンショットを撮影してビジョンモデルを使用するなどの他のソリューションと比較して、いくつかの見落としにつながる可能性があります。ただし、このツールは全体的にパフォーマンスが良く、使用や編集が複雑すぎないことがわかりました。

注：将来的にこのツールを改善する良い方法は、requestsではなくseleniumパッケージを使用してページを読み込むことだと考えています。これにより、JavaScriptを読み込むことができ（多くのページはJavaScriptなしでは正しく読み込めません）、一部のページにアクセスするためのCookieを受け入れることができます。

b. ファイルインスペクター

多くのGAIAの質問は、.xls、.mp3、.pdf など、さまざまなタイプの添付ファイルに依存しています。これらのファイルは適切に解析する必要があります。ここでも、Autogenのツールは非常にうまく機能するため、これを使用します。

Autogenチームが彼らの作業をオープンソース化してくれたことに感謝します。これらのツールを使用することで、開発プロセスが数週間短縮されました！🤗

c. コードインタープリタ

エージェントが自然にPythonコードを生成して実行するため、これは必要ありません。詳細は以下をご覧ください。

Code Agentを選ぶ理由

Wang et al. (2024) が示すように、エージェントにコードでアクションを表現させると、JSONのような辞書形式の出力を使用するよりもいくつかの利点があります。私たちにとっての主な利点は、コードは複雑な一連のアクションを表現するための非常に最適化された方法であるということです。もし現在のプログラミング言語よりも詳細なアクションを厳密に表現するより良い方法があれば、それは新しいプログラミング言語になっていたでしょう！

彼らの論文で示された例を考えてみましょう：

これはいくつかの利点を強調しています：

• コードアクションはJSONよりもはるかに簡潔です。
  • 5つの連続したアクションの4つの並列ストリームを実行する必要がある場合、JSONではそれぞれが別々のステップで20個のJSON blobを生成する必要がありますが、コードでは1ステップのみです。
  • 論文によると、コードアクションは平均してJSONより30%少ないステップで済み、これは生成されるトークンの同等の削減に相当します。LLM呼び出しはエージェントシステムのコストを決定づける要素であることが多いため、エージェントシステムの実行コストが約30%安くなることを意味します。
• コードにより、一般的なライブラリのツールを再利用できます
• コードを使用するとベンチマークでのパフォーマンスが向上します。これは2つの理由によるものです：
  • アクションを表現するためのより直感的な方法である
  • LLMのトレーニングデータには大量のコードが含まれており、JSONを書くよりもコードを書く方が流暢である可能性があります。

これらのポイントは、agent_reasoning_benchmarkでの実験で確認されました。

Transformers Agentsの構築に関する最新の実験から、以下のような追加の利点も観察されました：

• コードで要素を名前付き変数として保存するのははるかに簡単です。たとえば、ツールによって生成された岩の画像を後で使用するために保存する必要がある場合：
  • コードでは問題ありません：“rock_image = image_generation_tool(“A picture of a rock”)”を使用すると、変数は変数辞書のキー“rock_image”の下に保存されます。後でLLMは“rock_image”として再度参照するだけで、任意のコードblobでその値を使用できます。
  • JSONでは、この画像を保存する名前を作成するために複雑な操作を行う必要があります。たとえば、画像生成ツールの出力をすべて“image_{i}.png”の下に保存し、LLMが後でimage_4.pngが前のツール呼び出しの出力であることを理解することを信頼するか？あるいは、LLMに“output_name”キーも出力させて変数を保存する名前を選択させ、アクションJSONの構造を複雑にしますか？
• エージェントログが大幅に読みやすくなります。

Transformers AgentsのCodeAgentの実装

LLMが生成したコードの問題は、そのまま実行すると非常に危険である可能性があることです。LLMにガードレールなしでコードを書かせて実行させると、何でも幻覚する可能性があります。たとえば、すべての個人ファイルをDuneの伝承のコピーで消去する必要がある、またはFrozenのテーマを歌うあなたの音声をブログで共有する必要がある、といったことです！

したがって、私たちのエージェントでは、コード実行を安全にする必要がありました。通常のアプローチはトップダウンです：「完全に機能するPythonインタープリタを使用するが、特定のアクションを禁止する」。

より安全にするため、私たちは逆のアプローチを取り、LLMセーフなPythonインタープリタをゼロから構築しました。LLMが提供したPythonコードblobに対して、私たちのインタープリタはast Pythonモジュールによって与えられるコードの抽象構文木（AST）表現から開始します。木構造に従って木のノードを1つずつ実行し、明示的に許可されていない操作で停止します。

たとえば、import文は、まずインポートがユーザー定義の authorized_imports リストに明示的に記載されているかどうかを確認します。記載されていない場合、実行されません。デフォルトの組み込み標準Python関数のリストが含まれており、たとえば print や range などが含まれます。これら以外は、ユーザーが明示的に許可しない限り実行されません。たとえば、open（with open("path.txt", "w") as file: のように）は許可されていません。

関数呼び出し（ast.Call）に遭遇した場合、関数名がユーザー定義のツールの1つである場合、呼び出しの引数でツールが呼び出されます。以前に定義され許可された別の関数の場合、通常どおり実行されます。

また、LLMによるインタープリタの使用を支援するためのいくつかの調整も行っています：

• LLM生成コードの問題による無限ループを防ぐため、実行時の操作数を制限します。各操作でカウンターが増加し、特定の閾値に達すると実行が中断されます。
• print出力の行数を制限し、LLMのコンテキスト長を無駄な情報で溢れさせないようにします。たとえば、LLMが100万行のテキストファイルを読み込み、各行を出力することを決定した場合、出力は途中で切り詰められ、エージェントのメモリが爆発しないようにします。

基本的なマルチエージェントオーケストレーション

Webブラウジングは非常にコンテキスト豊富なアクティビティですが、取得されたコンテキストのほとんどは実際には役に立ちません。たとえば、上記のGAIAの質問では、唯一重要な情報は絵画「Embroidery from Uzbekistan」の画像です。それを取り巻くコンテンツ、たとえばそれが見つかったブログの内容などは、一般的により広範なタスク解決には役に立ちません。

これを解決するために、マルチエージェントステップを使用するのは理にかなっています！たとえば、マネージャーエージェントとWeb検索エージェントを作成できます。マネージャーエージェントは高レベルのタスクを解決し、特定のWeb検索タスクをWeb検索エージェントに割り当てる必要があります。Web検索エージェントは検索の有用な出力のみを返し、マネージャーが無用な情報で混乱しないようにする必要があります。

私たちはワークフローでまさにこのマルチエージェントオーケストレーションを作成しました：

• トップレベルのエージェントはReactCodeAgentです。アクションがPythonで定式化および実行されるため、コードをネイティブに処理します。これらのツールにアクセスできます：
  • file_inspector：テキストファイルを読み取るためのツール。オプションの question 引数を使用して、ファイルの内容全体ではなく、内容に基づく特定の質問への回答のみを返すことができます。
  • visualizer：画像に関する質問に特化して回答するためのツール。
  • search_agent：Webを閲覧するためのツール。具体的には、このツールはWeb検索エージェントのラッパーであり、Web検索エージェントはJSONエージェントです（JSONは、スクロールして新しいページに移動するなどの厳密にシーケンシャルなタスクでは依然としてうまく機能します）。このエージェントはWebブラウジングツールにアクセスできます：
    • informational_web_search
    • page_down
    • find_in_page
    • …（完全なリストはこの行を参照）

エージェントをツールとして埋め込むことは、マルチエージェントオーケストレーションを行うための素朴な方法ですが、どこまで押し進められるかを見てみたかったのです。そして、それはかなり遠くまで到達することがわかりました！

計画コンポーネント 🗺️

現在、計画戦略の動物園全体が存在するため、比較的シンプルな事前計画ワークフローを選択しました。Nステップごとに2つのものを生成します：

• コンテキストからわかっている事実や導き出せる事実、および発見する必要がある事実の要約
• 新しい観察と上記の事実要約に基づいてタスクを解決するためのステップバイステップの計画

パラメータNはターゲットのユースケースでのパフォーマンスを向上させるために調整できます。マネージャーエージェントにはN=2、Web検索エージェントにはN=5を選択しました。

興味深い発見は、計画の前のバージョンを入力として提供しない場合、スコアが上がることでした。直感的な説明は、LLMがコンテキストで利用可能な関連情報に強くバイアスされるのが一般的であるということです。計画の前のバージョンがプロンプトに存在する場合、LLMは必要に応じてアプローチを再評価して計画を再生成するのではなく、それを大きく再利用する可能性があります。

事実の要約と計画の両方が、次のアクションを生成するための追加コンテキストとして使用されます。計画は、目標を達成するためのすべてのステップと現在の状況を目の前に置くことで、LLMがより良い軌道を選択することを促します。

結果 🏅

提出に使用した最終コードはこちらです。

検証セットで44.2%を獲得しました。つまり、Transformers AgentのReactCodeAgentは現在全体で1位となり、2位に4ポイント差をつけました！テストセットでは33.3%を獲得し、Microsoft Autogenの提出を上回る2位となり、最も難しいLevel 3の質問で最高の平均スコアを獲得しました。

これはコードアクションがより良く機能することを支持するデータポイントです。その効率性を考慮すると、コードアクションはまもなくエージェントがアクションを書くための標準としてJSON/OAI形式に取って代わると考えています。

LangChainとLlamaIndexは、私たちの知る限り、コードアクションを標準でサポートしていません。MicrosoftのAutogenはコードアクションのサポートをいくつか持っています（Dockerコンテナでコードを実行）が、JSONアクションの付属品のように見えます。したがって、Transformers Agentsは、この形式を中心的とする唯一のライブラリです！

次のステップ

このブログ記事を楽しんでいただけたでしょうか！そして、作業はまだ始まったばかりで、Transformers Agentsをいくつかの軸に沿って改善し続けます：

• LLMエンジン：私たちの提出はGPT-4o（残念ながら）で行われ、ファインチューニングは一切行っていません。私たちの仮説は、ファインチューニングされたオープンソースモデルを使用することで、解析エラーを排除し、少し高いスコアを達成できるということです！
• マルチエージェントオーケストレーション：私たちのものは素朴なもので、よりシームレスなオーケストレーションがあれば、かなり進展できるでしょう！
• Webブラウザツール：seleniumパッケージを使用することで、Cookieバナーを通過し、JavaScriptを読み込むWebブラウザを実現でき、現在アクセスできない多くのページを読み込むことができるようになります。
• 計画のさらなる改善：文献の他のオプションでアブレーションテストを実行し、どの方法が最適かを確認しています。既存のコンポーネントの代替実装や新しいコンポーネントも試す予定です。より多くの洞察が得られたら、更新を公開します！

今後数ヶ月、Transformers Agentsに注目してください！🚀

そして、私たちがエージェントに関する内部専門知識を構築した今、あなたのユースケースで連絡することを躊躇しないでください。喜んでお手伝いします！🤝