[論文紹介] 自律的にツールを作るLLM - Large Language Models as Tool Makers (LATM)
ツールを自分で作るLLMというコンセプトが面白かったので紹介します。
論文情報
Large Language Models as Tool Makers (LATM)
https://arxiv.org/pdf/2305.17126.pdf
2023/05/26 公開
Author欄にはGoogle Deepmindの記載もありますね。
3行で
複数の入出力の例をIn-Context Promptingで渡し、再利用できるToolをPythonの関数としてTool Maker (GPT-4) に作らせる
Toolを使用する際には、入出力の例をもとにTool User (GPT-3.5) に実行させる
強いモデルはTool Makerのみに使い、Tool Userは弱いモデルで実行することでコストを抑えられる
Tool making
以下の3つのステップから構成されます。
Tool Proposing: training datasetから3つの入出力例を与えて、タスクの解き方をPythonの関数として出力させます。関数がエラーになった場合にはエラー文をコンテキストに追加してリトライします。
Tool Verification: validation datasetから別の3つの入出力例を与え、作成された関数を検証するためのユニットテストを出力させます。このステップは関数の動作を検証するだけでなく、与えられた自然言語の指示を関数の入力に変換する具体例を生成する役割も果たします。
Tool Wrapping: Tool Verificationで作成した関数呼び出しの具体例（Toolを呼び出して与えられる自然言語の指示を解くPythonコード）を入力サンプルとして作成することで、Tool Userがサンプルを見て関数を実行できるようにします。
以上のステップにより、
Pythonの関数
実際の使用例（自然言語の指示と、それを解くための関数の呼び出しを行うPythonコード）
が生成されます。
Tool Makingは1つの問題に対して一度のみ実行すればよく、それ以降は作成されたToolを使い回すことができます。ツールの作成には高い推論能力が必要なため、GPT-4など強力なモデルを使うことが推奨されます。
Tool Using
作成されたツールを使用するステップです。
Tool Wrapper Promptと同様のプロンプトを用いて複数の入力サンプルをIn-Context Promptingで渡すことにより、新しい入力に対しても関数の呼び出しを構成することができます。生成されたPythonコードを実際にPythonで実行することで処理が行われます。
このステップにはそこまで高度な推論能力は要求されないため、GPT-3.5相当のモデルで十分に処理することができます。
生成されたToolの例
並び替え問題
与えられた条件（AはBの左、Cは右から2番目など）を全て満たす配置を求める問題です。
contraintをlambda関数として受け取り、全ての並び替えを試して条件を満たしているかチェックする関数が生成されています。また自然言語から正しく関数を呼び出すサンプルもうまく生成されています。
ミーティングの時間調整
より実応用に近い例として、与えられたスケジュールからミーティングの時間を調整する問題も挙げられています。
Dispatcher
実応用では色んな問題がごちゃ混ぜで送られてくるため、どの問題にどのツールを適用するのか、新しいツールが必要なのかを判定するコンポーネント（これもLLM）が必要で、これをDispatcherと呼んでいます。
ツールの一覧を与え、利用できるものがある場合にはその名前を出力させてツールを実行します。適切なツールが存在しない場合には強力なモデルもしくは人間に回答を生成させて入出力例として保持しておき、十分なサンプルが溜まった段階でTool makerを実行してツールを作成します。
Evaluation
全てのタスクでCoTより高い性能を達成した
Tool UserはGPT-3.5でも十分動く
GPT-3.5を使うことでコストを抑えられる
GPT-3.5にはTool Makingは難しい
GPT-4でも、一部のタスクでは失敗することがある
Dispatcherは94%前後の精度でタスクに対する既存のツールを特定できる
Dispatcherは95%前後の精度で未知のタスクを判定できる
感想
基本的なアイデアは素直だが、Verificationのステップで作ったユニットテストをパッケージにしてツール使用時のサンプルとして使うあたりの工夫はなるほどなぁと思いました
実用に向けてはよりタスクやツールの種類が増えたときにDispatcherが正しく判定できるのかが肝になりそうだが、本論文ではそこは深く掘り下げられていなかった
将来的にはlangchainのAgent with ToolsのようにベクトルDBを併用することも考えられそう
実用的なタスクに対してコード生成がどれくらいできるのか、ツールの中で他のツールを呼び出したりする拡張性がどれくらい効くのかが気になるところ
現実的には、LLMに一発生成させるというよりは人間とペアプロしながら作っていくみたいな形になりそう
あればツールを使い、なければ人間に質問しながらツールを作っていくっていう部分のワークフローがSlackのbotとかでうまく組めたらかなり面白そうだなと思いました
（最後に宣伝）LLMのエージェントにツールを作らせて、同じタスクに対してツールを再利用して使うという似たようなアイデアをcommand-agentというレポジトリで作っています。興味がある方は覗いてみてください！
以上です。この記事が皆さんのLLMライフの一助になれば幸いです！
この記事が気に入ったらサポートをしてみませんか？