エージェントのツールを作る LLM エージェント

この論文は LLM エージェントの制約から出発する。エージェントが呼び出すツールは人間の開発者があらかじめ実装しておかなければならず、そのことが、生命科学や医学のように高度に専門化されたツールを大量に必要とする分野でエージェントの足かせになっている。公開コードリポジトリとともに発表される科学研究がますます増えていることに着目し、著者らは、エージェントがそうした既存のコードを自律的にダウンロードし、インストールし、ラップできるかどうか、そしてそれによってコードをデプロイする技術的スキルを持たない研究者でもそれを利用できるようになるかどうかを問う。

その答えが ToolMaker である。短いタスク記述、論文の GitHub リポジトリの URL、そして入力引数とその例示値のリストを与えると、ToolMaker は Docker コンテナ内にリポジトリとその依存関係をインストールし、タスクを実行する Python 関数を書き、その関数を閉ループの自己修正サイクルによってデバッグする。これを評価するために論文は TM-Bench を導入する。これは主に病理学、放射線医学、オミクスから集めた 15 の計算タスクで、ホールドアウトされた（開発時には示されない）ユニットテストによって検証される。ToolMaker は 15 タスク中 12 タスクを正しく実装したのに対し、著者らがベースラインとして適応させたソフトウェアエンジニアリングエージェント OpenHands は 15 タスク中 3 タスクにとどまった。

この論文は Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers) に掲載されており、コードとベンチマークは GitHub の KatherLab/ToolMaker リポジトリで公開されている。

要点

• 論文は ツール作成、すなわち LLM が実行時に自らの能力を拡張するために独自のツールを作成できるようにすることを、人間が作ったツールを LLM がより効果的に使えるよう教えるツール学習（tool learning）とは別のものとして位置づけている。
• 論文は、それ以前のツール作成手法（CRAFT、CREATOR、LATM が挙げられている）は、各ツールをゼロから構築し、オペレーティングシステムとやり取りできないため、単純で対象範囲の狭いツールしか作れないと論じる。ToolMaker はこの両方の制約に対処するものとして提示されている。
• ToolMaker のワークフローは 2 段階からなる。システムの再現可能なスナップショットを Docker イメージとして作成する環境セットアップと、Python 関数を作成するツール実装である。
• 環境セットアップの間、インストールを行うエージェントが実行したすべての書き込みアクションが記録される。いずれも bash コマンドとして表現できるため、それらを連結すると環境定義が bash スクリプトまたは Dockerfile として得られる。
• 自己修正ループでは、候補ツールを実行するたびにその前に実行環境がインストール直後の状態にリセットされる。また会話履歴はすべての試行を蓄積するのではなく以前のスナップショットに復元され、その上にこれまでのすべての試行の要約と現在のコードが追加される。
• ToolMaker は TM-Bench の 15 タスク中 12 タスク（80%）を正しく実装した。gpt-4o で動かした、適応版 OpenHands ベースラインは 15 タスク中 3 タスク（20%）を正しく実装した。ツールが正しいと見なされるのは、ホールドアウトされたテスト呼び出しすべてについて、そのユニットテストがすべて通った場合に限られる。
• 著者らは OpenHands の失敗の大半を環境セットアップに帰している。その環境定義のほぼ半数が無効であり、OpenHands はしばしばインストールスクリプトをテストせずに書いたり、手動で実行したセットアップコマンドを省いたりしていた。
• ToolMaker はツールあたりのコストが高い。平均で 21.8 アクション、0.94 ドルかかるのに対し、OpenHands は 7.5 アクション、0.15 ドルである。OpenHands が解けた 3 タスクは ToolMaker にとって最も安価なタスクの部類に入っており、著者らはこれを、OpenHands がごく簡単なツールしか扱えていないことの表れと解釈している。
• 複数ステップからなる stamp_train_classification_model タスクでは、自己修正ループによって ToolMaker は分類器を学習させる前に特徴量を抽出しなければならないことに気づけた。このタスクには 9 回の反復と 33 のアクションを要した。
• esm_fold_predict タスク（タンパク質の配列からそのコンタクトマップを予測する）向けのツールは部分的に正しく、3 つのテスト呼び出しのうち 2 つを通過した。失敗した呼び出しには例示呼び出しにはなかったマスクトークンが含まれており、そのようなトークンを例示に加えて再実行したツールはすべてのテスト呼び出しを通過した。著者らは、例示呼び出しはタスクを代表するものでなければならないと結論づけている。
• タスク固有の論文要約をプロンプトに加えても、どちらのシステムの精度も向上しなかったが、アクション数は減り、ToolMaker では自己修正の反復回数も減った。
• gpt-4o の代わりに o3-mini を使うと、両システムともコストは下がったが性能は低下した。また OpenHands を Claude 3.5 Sonnet で動かすと、gpt-4o の場合より性能が悪かった。

注記

著者らはいくつかの限界を挙げている。このフレームワークは、ある程度よく構造化され、最新の状態に保たれ、ドキュメントが整ったリポジトリを前提としており、あるリポジトリがそもそもインストールしてツールとして利用できる保証はない。TM-Bench のタスクは、著者ら自身が各リポジトリをインストールして利用できるように選定されたものである。ベンチマークのユニットテストに合格しても、あらゆる現実のシナリオで正しいことは保証されず、臨床研究のような重大な結果を伴う用途ではドメイン専門家によるさらなる検証が必要になる。TM-Bench はリポジトリの正確なコミットを固定しているものの、リポジトリの削除、force-push、ブランチ名の変更によって再現性が損なわれる可能性は残る。論文はまた、複雑な生化学ツールを自律的に実装することが悪用されうること、そして完全に自動化された研究システムには技術的能力と並んで安全対策と倫理指針が必要であることにも注意を促している。