【DL輪読会】大量API・ツールの扱いに特化したLLM

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

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

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

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

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

データセット・学習 • 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のみ更新）

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

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

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

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

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

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個のユーザ質問プロンプトを作成

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

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

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

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

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