論文概要(Abstract)
本記事は arXiv:2302.04761 の解説記事です。
言語モデル(LM)は多くのタスクで優れた能力を示す一方、算術演算や事実検索といった基本的な機能では、はるかに小さな専用モデルに劣ることがある。著者らは、LMが外部ツールのAPIを自己教師あり学習で使用方法を習得するモデル「Toolformer」を提案した。Toolformerは「どのAPIを呼ぶか」「いつ呼ぶか」「どの引数を渡すか」「結果をどう組み込むか」を自律的に判断する。各APIにつき少数のデモンストレーションのみで学習可能であり、計算機・QAシステム・検索エンジン・翻訳システム・カレンダーの5種のツールを統合している。
この記事は Zenn記事: AutoGen v0.7で自律エージェントを構築する実践ガイド の深掘りです。
情報源
- 会議名: NeurIPS 2023(Neural Information Processing Systems)
- 年: 2023
- URL: https://arxiv.org/abs/2302.04761
- 著者: Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, Thomas Scialom(Meta AI Research)
- 発表形式: Main Conference
カンファレンス情報
NeurIPSについて: NeurIPS(Neural Information Processing Systems)は機械学習・計算神経科学分野の最高峰会議の1つであり、採択率は通常25-30%程度である。Toolformerの採択は、ツール使用学習が機械学習コミュニティにおいて重要な研究テーマとして認められたことを示している。
技術的詳細(Technical Details)
課題: LMの能力的限界
大規模言語モデルは以下の基本的タスクで苦戦する:
- 算術演算: 大きな数の計算や複雑な数式の正確な処理
- 事実検索: 学習データに含まれない最新情報の取得
- 日付計算: 曜日や経過日数の正確な計算
これらのタスクは、専用の小型モデルやAPIで容易に解決できる。著者らの着想は「LMがこれらのAPIをいつ・どのように使うべきかを自ら学習できないか」というものである。
Toolformerの学習パイプライン
学習は以下の4段階で行われる:
graph LR
A[Step 1: API呼び出し候補の生成] --> B[Step 2: API呼び出しの実行]
B --> C[Step 3: フィルタリング]
C --> D[Step 4: ファインチューニング]
Step 1: API呼び出し候補の生成
テキストデータセット $\mathcal{C}$ の各テキスト $x = (x_1, …, x_n)$ に対し、LMのIn-context learningを用いてAPI呼び出し候補を生成する。各API $a$ について少数(5個程度)のデモンストレーションを提示し、テキスト中の任意の位置 $i$ にAPI呼び出しを挿入する候補を生成する。
API呼び出しは以下の形式で表現される:
\[e = \langle \text{API}(c_{\text{input}}) \rightarrow r \rangle\]ここで、
- $\text{API}$: 呼び出すAPIの名前(例: Calculator, QA)
- $c_{\text{input}}$: APIへの入力引数
- $r$: APIからの返却値
Step 2: API呼び出しの実行
生成された候補の各API呼び出しを実際に実行し、返却値 $r$ を取得する。
Step 3: フィルタリング(損失ベース)
API呼び出しが「有用」かどうかを、言語モデルの損失関数で判定する。具体的には、API呼び出しの挿入によって後続トークンの予測損失が改善されるかを測定する:
\[L_i^+ = L(e, x_{i+1:n}) \quad \text{(API呼び出しあり)}\] \[L_i^- = \min(L(\epsilon, x_{i+1:n}), \, L(e^{\text{no\_result}}, x_{i+1:n})) \quad \text{(API呼び出しなし)}\]フィルタリング条件:
\[L_i^- - L_i^+ \geq \tau\]ここで、
- $L(e, x_{i+1:n})$: API呼び出し結果を含むテキストでの損失
- $L(\epsilon, x_{i+1:n})$: API呼び出しなしでの損失
- $L(e^{\text{no_result}}, x_{i+1:n})$: API呼び出しはあるが結果なしでの損失
- $\tau$: フィルタリング閾値
この条件により、API呼び出しが実際にテキスト予測を改善するケースのみが学習データとして採用される。
Step 4: ファインチューニング
フィルタリングを通過したAPI呼び出し付きテキストを用いて、言語モデルをファインチューニングする。
統合されたツール
| ツール | API形式 | 用途 |
|---|---|---|
| Calculator | [Calculator(3+2*5)] | 算術演算 |
| Q&A System | [QA("Who is the CEO of...")] | 事実に関する質問応答 |
| Wikipedia Search | [WikiSearch("query")] | Wikipediaからの情報検索 |
| Machine Translation | [MT("text", "en→fr")] | テキスト翻訳 |
| Calendar | [Calendar()] | 現在日時の取得 |
実装の擬似コード
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
import torch
from typing import TypedDict
class APICall(TypedDict):
"""API呼び出しの定義"""
api_name: str
input_args: str
result: str
position: int
def filter_api_calls(
text: str,
candidates: list[APICall],
model: torch.nn.Module,
threshold: float = 0.5,
) -> list[APICall]:
"""損失ベースのフィルタリング
Args:
text: 元のテキスト
candidates: API呼び出し候補のリスト
model: 言語モデル
threshold: フィルタリング閾値 τ
Returns:
フィルタリングを通過したAPI呼び出し
"""
filtered = []
for call in candidates:
# API呼び出しありの損失
text_with_api = insert_api_call(text, call, include_result=True)
loss_with = compute_loss(model, text_with_api, call.position)
# API呼び出しなしの損失
loss_without_empty = compute_loss(model, text, call.position)
text_no_result = insert_api_call(text, call, include_result=False)
loss_without_no_result = compute_loss(model, text_no_result, call.position)
loss_without = min(loss_without_empty, loss_without_no_result)
# フィルタリング条件: L^- - L^+ >= τ
if loss_without - loss_with >= threshold:
filtered.append(call)
return filtered
実験結果(Results)
著者らの実験はGPT-Jベース(6.7Bパラメータ)のモデルで実施されている。
| タスク | GPT-J (6.7B) | Toolformer (6.7B) | GPT-3 (175B) |
|---|---|---|---|
| SQuAD (QA) | 27.3 | 37.2 | 29.9 |
| SVAMP (数学) | 29.4 | 44.0 | 10.0 |
| LAMA (知識) | 24.8 | 36.5 | 38.0 |
| Temp. Datasets (時間) | 22.0 | 32.7 | 25.3 |
| WebQS (Web QA) | 9.3 | 11.8 | 6.3 |
| MultiLingual QA | 11.2 | 13.6 | 12.3 |
(論文Table 1-3より。数値はExact Match / Accuracy。太字は比較群内の最高値)
著者らは「6.7Bパラメータのモデルが、ツール使用により175BのGPT-3を複数タスクで上回った」と報告している。特に数学タスク(SVAMP)では、Calculator APIの活用により44.0%の精度を達成し、GPT-3の10.0%を大幅に上回っている。
重要な制約:
- 著者らは「ツール使用により言語モデルの基本的な能力(一般的なテキスト生成等)が損なわれないことを確認した」と報告しているが、ファインチューニングによるモデル品質への影響は長期的なモニタリングが必要である
- 学習データの品質(フィルタリング閾値 $\tau$ の設定)がツール使用精度に大きく影響する
実装のポイント
AutoGen v0.7との関連で、Toolformerの知見から以下の実装指針が得られる:
ツール定義の品質: Toolformerの学習パイプラインでは、API呼び出しの「いつ使うか」の判断がdocstringの品質に依存する。AutoGenでも同様に、関数のdocstringがツール選択精度に直結する。
ツール使用の判断基準: Toolformerの損失ベースフィルタリングは、「ツールを使わない方がよい場合はツールを使わない」という判断を学習する。AutoGenのreflect_on_tool_use=True設定も、同様の目的でツール使用結果を評価する。
AutoGenでの実践:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Toolformerの知見を活用したツール定義
async def calculate(expression: str) -> str:
"""数学的な計算を正確に実行する。
四則演算、べき乗、平方根等の数値計算に使用する。
自然言語での数学的推論ではなく、正確な数値が必要な場合に呼び出す。
Args:
expression: 計算式(例: "3 + 2 * 5", "sqrt(144)")
Returns:
計算結果の文字列
"""
# 安全な数式評価
import ast
import operator
result = safe_eval(expression)
return str(result)
実運用への応用(Practical Applications)
Toolformerの研究が示した「LMにツール使用を学習させる」パラダイムは、現在のエージェントフレームワークに以下の形で影響を与えている:
- OpenAI Function Calling: GPT-4のFunction Calling機能は、Toolformerの概念を商用LLMに組み込んだものと位置づけられる。AutoGenはこの機能を
FunctionToolとして活用している - ツール選択の自律性: AutoGenの
AssistantAgentがツールを自律的に選択する動作は、Toolformerが示した「LMがAPIを呼ぶタイミングを自ら判断する」能力の延長線上にある - コスト効率: Toolformerは6.7Bの小型モデルでも大型モデルを上回る結果を示した。これは、エージェントのタスクに適したツールを提供することで、モデルサイズを削減できる可能性を示唆している
関連研究(Related Work)
- Gorilla (Patil et al., 2023, NeurIPS 2024): LLMをファインチューニングしてAPI呼び出し精度を向上。Toolformerとは異なり、既存のAPIドキュメントとリトリーバを組み合わせるアプローチ
- ReAct (Yao et al., 2023): 推論(Reasoning)と行動(Acting)を交互に実行するフレームワーク。Toolformerのツール使用判断を推論ステップに組み込んだ拡張として位置づけられる
- HuggingGPT (Shen et al., 2023): GPT-4をオーケストレーターとし、HuggingFace上の専門モデルをツールとして動的に呼び出す。Toolformerの単一モデルアプローチとは対照的なマルチモデルアプローチ
まとめ
Toolformerは、言語モデルが外部ツールの使用方法を自己教師あり学習で習得できることを示した研究である。損失ベースのフィルタリングにより、ツール使用が実際に有用な場合のみAPIを呼び出す判断力を獲得する。この研究は、AutoGen v0.7のツール統合機能(FunctionTool、AssistantAgentのツール自律選択)の学術的基盤として位置づけられ、「LLMにどのようなツールを提供すべきか」「ツール定義をどう設計すべきか」という実装上の問題に理論的な指針を与えている。
参考文献
- Conference URL: https://proceedings.neurips.cc/paper_files/paper/2024/hash/e4c61f578ff07830f5c37378dd3ecb0d-Abstract-Conference.html
- arXiv: https://arxiv.org/abs/2302.04761
- Related Zenn article: https://zenn.dev/0h_n0/articles/b64c0d3cbd4035
:::message この記事はAI(Claude Code)により自動生成されました。論文の主張や実験結果は原著者の報告に基づいています。実際の利用時は原論文もご確認ください。 :::