CodeAct: 実行可能なPythonコードがLLMエージェントの精度を20%向上させる理由
先週、「自己修正できない」という論文を読んだ後、自然に湧いてくる疑問はこうです。LLMが自身の出力を確実に監査できないのであれば、エラーを自動的に検出して回復するために、エージェントにとって最適なアクション形式は何でしょうか？ICML 2024に採択されたXingyao Wang氏らによる「CodeAct」は、その答えはPythonコードであると主張しています。それはコードが魔法だからではなく、Pythonインタープリタが、自己修正に関する文献がLLMに切実に必要だと示している、まさに外部的で決定論的なフィードバックを提供してくれるからです。
論文の概要
Xingyao Wangらによる「Executable Code Actions Elicit Better LLM Agents」(arXiv:2402.01030)は、ツール呼び出し エージェントで一般的なJSONやテキストのアクション形式を実行可能なPythonコードに置き換えることを提案しています。核となるアイデアは、コードは自然言語の指示や構造化されたJSONよりもエージェントのアクションに適した共通言語（lingua franca）であるということです。なぜなら、コードには制御フロー、データの依存関係、多段階の構成が既にエンコードされており、LLMはそれについて集中的に事前学習を受けているからです。
この論文は3つの貢献をしています。(1) 統一されたアクション空間としてのコードに関する概念的な議論、(2) マルチツール構成を必要とする82の人間が精選したタスクによる新しいベンチマーク「M3ToolEval」、(3) 情報検索、ソフトウェアパッケージ、外部メモリ、ロボット計画にわたる7,139のマルチターンコードベースの軌跡データセット「CodeActInstruct」でファインチューニングされた7Bモデル「CodeActAgent」です。
主なアイデア
- M3ToolEvalにおいて、CodeActを用いたGPT-4は74.4%の成功率を達成しました。これはテキストアクションを用いた場合の53.7%に対し、最も要求の厳しいマルチツール環境で約20ポイントの絶対的な改善となります。
- CodeActは、同じタスクにおいてJSONベースのエージェントよりも対話ターン数を約30%削減します。ターン数が少ないことは重要です。往復回数が増えるごとに、エラーが伝播する機会が増えるからです。
- Pythonインタープリタは、自動的でコストゼロのエラー信号として機能します。中間計算の間違いは即座に例外を発生させ、エージェントはトレースバックを見て、別途批判ステップを挟まずに修正を行うことができます。
- オープンソースモデルはクローズドソースモデルよりも大きな恩恵を受けます。CodeActAgent (Mistral 7B) はM3ToolEvalで12.2%に達しましたが、以前の最強のオープンソースエージェント (Lemur-70B + テキスト) は3.7%でした。事前学習データにPythonが豊富に含まれているため、レバレッジが高くなります。一方で、特殊なJSONツール呼び出し形式は豊富ではありません。
- CodeActInstructは、構成能力をテストするために特別に選ばれた4つのドメイン（情報探索、パッケージ呼び出し、外部メモリ操作、ロボット計画）でトレーニングされています。これらはすべてマルチステップで状態に依存するタスクであり、JSONエージェントが失敗する典型的なパターンです。
評価できる点と懸念点
M3ToolEvalでの20%の改善は注目に値しますが、M3ToolEvalのタスク数は82です。これはサンプルサイズとしては小さく、論文では信頼区間が報告されていません。また、このベンチマークは手法を提案したチームと同じチームによって作成されたものであり、この分野では標準的ですが、留意しておく価値があります。74.4%を信頼できる数値として扱う前に、完全に独立したベンチマークでこれが再 現されるのを確認したいところです。
効率性の主張（ターン数が30%少ない）は妥当ですが、2つの側面が混在しています。ターン数が少ないことは、エージェントがステップごとにより正確であることを意味する場合もあれば、失敗がより早く終了することを意味する場合もあります。論文では、これらが明確に分解されていません。
オープンソースモデルとクローズドソースモデルの間の能力差は依然として大きく、CodeActによって解消されるわけではありません。CodeActAgent (Mistral 7B) の12.2%はLemur-70Bの3.7%よりはるかに優れていますが、CodeActを用いたGPT-4は74.4%に達しています。形式は助けになりますが、60ポイントもの能力差を埋めるものではありません。オープンソースのBeancountエージェントをデプロイしようと考えている人は、この数字を慎重に読み取るべきです。
サンドボックスの問題については1つの段落しか割かれていません。金融の文脈において、任意のコード実行は単なる不便なエッジケースではなく、主要なセキュリティ上の懸念事項です。エージェントがファイルを削除したり、ネットワーク呼び出しを行ったり、予期しないライブラリをインポートしたりするコードを生成した場合に何が起こるかについて、この論文では深く踏み込んでいません。実用的な会計エージェントにとって、サンドボックスの設計はアクション形式と同じくらい重要です。
なぜこれが金融AIにとって重要なのか
Beancountへの書き戻し問題は、本質的にCodeActが解決するために設計された問題です。エージェントは、特定の順序で複数の操作（現在の残高の読み取り、トランザクションの検証、新しいポスティングの書き込み、バランス式の検証）を、ステップ間でデータを流しながら構成する必要があります。JSONによるツール呼び出しは、各呼び出しが孤立しているため、この処理を苦手とします。Pythonであれば、これを自然に処理できます。
より具体的には、CodeActスタイルのBeancountエージェントは、照合ワークフロー全体を単一のPythonスクリプトとして表現できます。ライブラリを介して元帳にクエリを出し、差分を計算し、新しいエントリを提案し、結果に対して bean-check を実行する、という一連の流れをすべてコミット前に行うことができます。インタープリタが明白なエラーをキャッチし、LLMは意味的なエラーのみを処理すればよくなります。これは、LLMに自身のJSONを検証させるよりも優れた分業です。
一方で、安全性の懸念も無視できません。財務元帳に対して制限のないPython実行権限を持つエージェントは、大きな攻撃対象領域となります。正しい設計は、ほぼ間違いなく厳格に制限されたサンドボックス（指定された一時ディレクトリ以外へのファイル書き込み禁止、ネットワークアクセス禁止、シェルコマンド禁止）であり、さらにファイルに触れる前に必須の bean-check ゲートを組み合わせることでしょう。CodeActはアクション形式を提供してくれますが、システムを安全に保つための「檻」を構築するのは依然として開発者の仕事です。
次に読むべきもの
- OpenHands (旧 OpenDevin) — 同じ研究グループによってCodeActに基づいて構築された実用的なエージェントシステム。サンドボックスと実行環境が実際にどのように実装されているかを示しています (arXiv:2407.16741)。
- ToolBench / ToolLLM — PythonではなくREST APIを使用したツール呼び出しエージェントのためのベンチマークとトレーニングデータ。CodeActのコード優先アプローチとの有用な対比となります (arXiv:2307.16789)。
- SWE-bench — 実際のGitHubのIssueでエージェントを評価します。これにはマルチステップのコード実行とファイル編集が必要であり、Beancountの書き戻しエージェントが合格するために必要な要件に最も近い既存のベンチマークです (arXiv:2310.06770)。
