Toolformer：自己教師ありツールの利用とその金融AIにおける限界
Toolformer (Schick et al., 2023, Meta AI) は、自己教師あり学習を通じて言語モデルに外部APIの呼び出しを学習させるための基礎的な論文です。「ツールの利用（tool use）」がバズワード化し、元の主張が曖昧になっていたため、これまで精読を後回しにしてきました。帳簿ツールを呼び出すライトバックエージェントを設計する前に、Toolformerが実際に何を実証したのか、そしてどこでひっそりと失敗しているのかを理解する必要があります。
論文の概要
Timo Schick氏とMeta AIの7名の共著者は、各ツールに対する手動のラベル付けデータを必要とせずに、いつ外部APIを呼び出すか、どの引数を渡すか、そしてその結果を自身の予測にどのように組み込むかを言語モデルに判断 させるための訓練手法を提示しています。このアプローチは自己教師あり（self-supervised）です。モデルはテキスト内の適切な位置で候補となるAPI呼び出しを生成し、それらを実行し、APIの結果が周囲のトークンに対するモデルのパープレキシティ（困惑度）を真に減少させる例のみを保持します。そのフィルタリングされたデータセットがファインチューニングに使用されます。テストされたツールには、電卓、2つの検索エンジン（BM25検索とWikipedia検索）、QAモデル、翻訳機、カレンダーが含まれます。
訓練されたモデルは、GPT-Jベースの67億パラメータモデルで、Toolformerと呼ばれます。この論文はNeurIPS 2023に採択されました。
主なアイデア
- 算術文章題（SVAMP）において、Toolformer 6.7Bは29.4%のスコアを記録しました。これはベースラインのGPT-Jの5.2%、OPT 66Bの4.9%、そしてGPT-3 175Bの10.0%と比較されます。ツールの利用は、算術における通常の性能向上曲線を事実上打破しています。
- ASDiv算術では、Toolformerは40.4%に達し（GPT-Jは7.5%、GPT-3は14.0%）、MAWPSでは44.0%に達しました（GPT-Jは9.9%、GPT-3は19.8%）。
- 事実に基づくQAタスクでは状況が逆転します。Toolformerが検索ツールを使用しているにもかかわらず、GPT-3は依然として3つのQAベンチマーク（TriviaQA、WebQuestions、Natural Questions）すべてでToolformerを上回っています。ToolformerのTriviaQAは53.5%で、GPT-Jベースラインの31.9%よりは高いものの、ツールを 使用しないGPT-3はさらに高いスコアを維持しています。
- 自己教師ありデータ生成パイプラインは、ツールが役に立たない場合には呼び出さないことをモデルが学習するような訓練例を生成します。フィルタリング・ステップでは、パープレキシティの改善を「このツール呼び出しは実際に役立ったか？」の信号として使用します。
- ツール利用能力はスケールによってのみ現れます。約7億7500万パラメータ未満のモデルでは、同じ訓練信号を与えても、いつツールを呼び出すべきかを安定して学習することはありません。
- カレンダーツールが呼び出されるのは、時間的な推論タスクにおいてわずか0.2%です。モデルは時間的な質問の大部分を、代わりにwiki検索ツールへとルーティングしています。
評価できる点、できない点
核心的な洞察は非常に堅実です。パープレキシティに基づくフィルタリングの手法は、人間のラベル付けや正解を知るオラクル（神託）を必要とせず、挿入されたAPIの結果が周囲のテキストをより予測しやすくしたかどうかだけを判断すればよいため、非常にエレガントです。これは真の貢献であり、算術の結果は目を見張るものがあります。6.7BのモデルがASDivでGPT-3を破ったのは評価のトリックではなく、適切なツール呼び出しが算術タスクにおいて約26倍のパラメータ数に匹敵する価値があることを明確に示 しています。
一方で、QAに関する記述にはあまり納得できません。論文ではToolformerが広範にパフォーマンスを向上させるとされていますが、QAの結果を見ると、ツールを一切使わないはるかに巨大なモデルであるGPT-3には勝てていません。著者はこれを認めていますが、ナラティブの構成（「多くの場合、はるかに大規模なモデルに匹敵する」）は、その勝利がいかに限定的であるかを過小評価しています。モデルが勝利するのは単一の電卓や検索呼び出しにきれいに分解できるタスクであり、取得したコンテンツに対する真の推論を必要とするタスクでは敗北するか、同等にとどまっています。
さらに深い手法上の問題は、自己教師ありパイプラインが、訓練される前からモデルが妥当なAPI呼び出しを生成できるほど十分に優れていることを前提としている点です。これはブートストラッピングの問題です。明確な入力フォーマットを持つ電卓のようなツールでは機能しますが、より複雑な引数スキーマを持つツール（現実世界の帳簿ライトバックAPIに必要なものなど）では、サンプリングされた呼び出しの品質は急速に低下するでしょう。
また、この論文では各ツールを個別に評価しており、複数を組み合わせてはいません。例えば、検索結果を電卓に渡すようなマルチステップのパイプラインの実証はありません。著者はこれを限界として挙げていますが、これは重大な欠点です。実際の会計ワークフローでは、ほぼ常に連鎖的なツール呼び出しが必要とされるからです。
最後に、評価はゼロショット（zero-shot）で行われています。この論文の公開から数ヶ月以内に主流となった、コンテ キスト内でツールを提供するフューショット（few-shot）プロンプトによるGPT-3やGPT-4との比較はありません。NeurIPS 2023の出版日を考えると、実験は関数呼び出し（function-calling）APIが普及する前に行われたものであり、出版時点では比較対象がやや古くなってしまっています。
なぜこれが金融AIにとって重要なのか
Toolformerの論文は、Bean Labsにとって重要な問いに答えています。モデルはライトバックAPIを確実に呼び出すことを学習できるのか、そしてそのコストはどのくらいか？ 算術の結果からの答えは、「ツールのインターフェースがクリーンで、タスクが単一の呼び出しに分解できるのであれば、イエス」です。しかし、その失敗モードは、帳簿問題の最も困難な部分に直接当てはまります。
Beancountのライトバック操作（取引の分類、勘定科目のマッピング推論、仕訳エントリの生成）は、単一ステップの電卓呼び出しではありません。これらには、コンテキスト（過去のエントリ、勘定科目表）の取得、ルールの適用（記帳ルール、通貨制約）、および構文的に有効でなければならない構造化データの生成が含まれます。これには少なくとも3つの連鎖的なツール呼び出しが必要ですが、Toolformerのアーキテクチャは明示的にツールの連鎖をサポートしていません。また、出力が自然言語の継続ではなく構造化された .beancount ファイルである場合、「周囲の帳簿テキストにおけるパープレキシティの低下」が何を意味するのかが不明確なため、パープレキシティベースの訓練信号を適用するのも困難でしょう。
私たちの目的においてToolformerから得られるより有用な教訓は、その「空白」の部分にあります。ライトバックエージェントは、単に帳簿APIをいつ呼び出すかを記憶したファインチューニング済みLMであってはなりません。書き込みを確定する前に、中間結果を計画、実行、検証できる明示的な推論レイヤー（ReActなど）が必要です。Toolformerはツールの利用が機能することを証明しましたが、構造化された副作用を伴う操作において安全に機能することは証明していません。
次に読むべきもの
- ReAct: Synergizing Reasoning and Acting in Language Models (arXiv:2210.03629) — ツールの呼び出しと交互に行われる明示的な思考の連鎖（chain-of-thought）推論ステップを追加します。Toolformerの連鎖の限界を解決するアーキテクチャであり、ほとんどの現代のエージェントの基礎となっています。
- ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — ToolBenchデータセットを介して、16,000以上の実際のAPIにツール利用をスケールさせます。実際の会計エージェントが直面する複雑さのレベルで、ツール呼び出しのストレステストに最も近いものです。
- FinMaster (arXiv:2505.13533) — 仕訳入力や照合を含むエンドツーエンドの会計ワークフローをベンチマークします。Toolformerが算術で示した成果が、Beancountにとって重要なマルチステップでスキーマ制約のあるタスクに一般化できるかどうかを示してくれるでしょう。
