2023/6/2 Deep Learning JP http://deeplearning.jp/seminar-2/

1. 大量API・ツールの扱いに特化したLLM
岡田 領 / Ryo Okada（@anonymousgraba）

2. 大量API・ツールの扱いに特化したLLM
2023/5/19 Arxiv 2023/5/24 Arxiv
• 直近見かけた２本

3. ToolkenGPT
• LLMの外部ツール利用
• プロンプトとしてツールの利用例を与える （In context learningを活用する） 場合数ショットの
デモしか与えることしかできない，かつ大量ツール前提だと安定して動作しない．
• Toolformerなど（finetune）では少数のAPIでしか検証されていない，かつ計算コストが大きい
• 提案手法：ToolkenGPT
• Toolをtokenとして表現（Toolken）する発想
• tooklen埋め込みをLLMヘッドに挿入し，学習（LLMは固定）
• LLMは次トークン予測の中でツール利用・選択を判断．
• Finetuneより低コストで大量ツールにおいても安定した動作

4. ToolkenGPTの概要
• LLMモデルのヘッドに単語埋め込みにconcatする形でツールの埋め込み（toolken
embeddings）を追加
• LLMの次トークンの予測確率：
• LLMに単語トークンだけでなく， ツール実行の必要性を判断して，toolken（ツール実行の
トークン）を生成することを期待する．
Word
embeddings
toolken
embeddings
Last
Hidden
state
t: word token

5. ToolkenGPTの概要（推論の流れ）
• LLMはwordだけでなく，必要に応じてtoolken（tool利用を意味するトークン）を生成．（ 推論モード ）
• Toolkenが予測されたらtoolモードに移行し，該当するtool実行
• 結果をテキストに合成
• （上記はLLMが生成途中で数学演算子squareを選択.ツールモードで16を引数として生成．ツールを実行し，結果256を返し，推
論モードに戻る例）

6. データセット・学習
• LLMの重みは固定でtoolken embeddingsを学習する
• 学習データの形式
• Toolkenを予測するタイミング，呼び出すAPI内容を指定．(N/Aは無視の意味合い）
• ”the”, “area”, “is”, “2”, “5”, “6”, “square”, “feet”, ...
• “the”, “area”, “is”, “ [square]”, “[N/A]”, “[N/A]”, “square”, “feet”, ...)
• →”２”の時点でsquareのツールを呼び出す．”2”でツールを呼び出すので，”5”,”6”は無視．
• データの作成
• 教師あり学習で利用するためにKBや計算トレースの自然言語文と正解のツールを前処理
• LLMで今回の構文を指定し，生成
• 上記で教師あり学習（LLM本体の重みは固定でtoolken embeddingsのみ更新）

7. 実験：Knowledge based QA
• KAMEL(Wikipediaの質問応答データセット)
• LLMにこのAPIを与えて，事実関係を答えてもらう
実験（234のツールから選択）
• ToolkenGPT(sup): KAMELの訓練セットで訓練
• ToolkenGPT(syn): LLMで合成したデータで訓練
• ベースモデル: LLaMa-13B
• ツールセットが大きくなるとin context learningは混
乱しやすくなる一方，ToolkenGPT高い結果

8. 実験：エージェントシミュレーション
• LLMをエージェントのコントローラとして利用する実験
（LLMで次アクションを生成）
• 家庭環境シミュレーション環境のVirtual Homeでの実験
• 58のtoolから選択
• 他のLLMがSit at deskで失敗する中，toolkenGPTはchair
に座ることに成功

9. 大量API・ツールの扱いに特化したLLM
2023/5/19 Arxiv 2023/5/24 Arxiv

10. ゴリラの概要
• LLMで正確にAPIコール行うのは難しい
• 大量のAPIから適切なものの選択
• 頻繁に変化するAPI仕様への対応
• APIコール特化したモデル，ゴリラの提案(OSS プロジェクト)
• 大量APIデータセットのAPIBenchの公開
• HF, TF, TouchHubのAPIに対する0shotモデルを公開
• API appstore for LLMを謳ったプラットフォームを意識
• Apache2.0商用利用可で7/5リリース予定

11. ゴリラの能力
• ユーザープロンプトに応じて目的を満たすAPIを選択．API仕様書よりAPIコールするコー
ドを生成

13. APIBench
• ３つのML APIハブより収集したAPIコレクションのデータセット
• TorchHub: 94API
• TensorFlowHub: 646API
• HuggingFace: よく使われているモデル925API
• 収集内容・方法
• APIドキュメントの収集（retrieverとして活用する）
• {domain, framework, functionality, api_name, api-call, api_arguments, environment_requirements, example_code, performance, description}
• GPT-4を用い，APIごとに10個のユーザ質問プロンプトを作成

14. ゴリラの訓練・推論
• 生成したユーザプロンプトとAPIのペアでLLaMa-
7Bを教師ありfinetune（ゴリラ）
• Retriever（APIドキュメントから検索させる）あ
りとなし（ゼロショット）の２通りで訓練（
retrieveを用いることで，単純な性能向上とAPI
仕様変更時の対応を期待）
• Retrieverありの場合プロンプトを加える：”Use
this API documentation for reference: “
• 推論の場合もzero shotとretrieveのモードを利用可
能（Retrieverの場合は事前に関連するAPIドキュメ
ントを検索した上で与える

15. LLMに与えるプロンプトの例
ゼロショット
Retriever利用

16. ゴリラの評価
• 大量のAPIの中から適切なAPIをコールできているか評価．
• API仕様上全く定義がないものをハルシネーション，部分的誤りをエラーと定義

17. API仕様変更（Test Time Changs）への適応
• APIドキュメントに（ テスト時に ）変更をかけて，対応できるか？
• モデルの更新やモデルレジストリーの変更に柔軟に対応

18. ゴリラとToolkenGPTの比較・まとめ
• toolkenGPTは生成の途中で必要に応じてtoolを呼び出すイメージ（Toolformerと同様）．Gorillaは自然言語によるAPIの検索システムに近いイ
メージ．
• ToolkenGPTではAPI選択した後は予め用意したコードでAPI・ツールを実行する想定だが，Gorillaではソースコードを直に生成．API仕様変更
への対応も考慮したパイプライン
• いずれの手法も手法自体の新規性というより，効果的にAPIを利用するためにLLMを調整するための軽微な工夫・パイプラインの提案
実現方法 シナリオ 出力内容 ベースモデル
(実験設定)
扱っているAPI 学習データ生成方法 API仕様変更
ToolkenGPT LLMは固定
追加パラメータを学
習
LLMが必要な段階で
必要なAPIを呼び出
す
APIコール結果を組
み合わせて文書合成
（API実行部分は別
途用意）
LLaMa-13B GSM8K（数値計算
Knowledge
basedQA
VirtualHome
手動＋LLMで生成 考慮なし（手動で対
応が必要）
Gorilla LLMをfinetune ユーザの問い合わせ
内容に応じたAPIを
探して自動でコール
APIコールするソー
スコードを生成し，
実行
LLaMa-7B TorchHub
TensorFlow Hub
HuggingFace
手動＋LLMで生成 APIドキュメント内
容から柔軟に対応