ToolGen：生成による統一されたツールの検索と呼び出し

ToolGenは、大規模言語モデル（LLM）にツール知識を直接統合するためのフレームワークであり、各ツールを一意のトークンとして表現することで、シームレスなツール呼び出しと言語生成を可能にする。ツール検索とタスク完了のパフォーマンスを向上させるために、Renxi Wangらによって開発された。 ツールのマークアップ ...

• ツールのトークン化：ツールを一意のトークンに変換し、モデルの起動を容易にする。
• ツールコールの生成：モデルはツールコールとパラメータを生成できる。
• タスクの完了：ツールの呼び出しによる複雑なタスクの自動化。
• データセットのサポート：モデルのトレーニングと評価をサポートする豊富なデータセットを提供。

抄録

大規模言語モデル(LLM)が進化するにつれ、外部ツールとの直接対話によって自律的にタスクを実行できない限界が特に明らかになる。従来のアプローチは、コンテキスト入力としてツール記述を使用することに依存しており、これはコンテキストの長さによって制限され、しばしば非効率的である別の検索メカニズムを必要とする。我々は、各ツールを一意な トークン LLMは、ツール知識をLLMパラメータに直接統合するパラダイムを持つ。これによりLLMは、ツール呼び出しとパラメータを次のトークンの予測能力の一部として使用することができ、ツール呼び出しと言語生成がシームレスに統合される。我々のフレームワークにより、LLMは追加の検索ステップなしに多数のツールにアクセスし使用できるようになり、パフォーマンスとスケーラビリティが大幅に改善される。47,000以上のツールに基づく実験結果は、ToolGenがツールの検索と自律的なタスク完了において優れた結果を達成するだけでなく、幅広いドメインのツールに適応できる新世代のAIエージェントの基礎を築くことを示している。ToolGenは、ツール検索を生成プロセスに根本的に変換することで、より柔軟で効率的かつ自律的なAIシステムへの道を開く。ToolGenは、エンドツーエンドのツール学習をサポートし、チェーン思考や強化学習などの他の先進技術との統合の機会を提供することで、LLMの有用性を拡張する。

1 はじめに

大規模言語モデル（LLM）は、外部入力を処理し、操作を実行し、自律的にタスクを完了する素晴らしい能力を実証してきた（Gravitas, 2023; Qin et al. 2023; Yao et al. 2023; Shinn et al.）LLMが外界と対話できるようにするための様々なアプローチの中で、APIを介したツール呼び出しは、最も一般的で効果的なものの1つとなっている。しかし、ツールの数が数万に増えるにつれて、既存のツール検索と実行の方法は、効率的に拡張することが難しくなっている。

実世界のシナリオでは、一般的なアプローチは、ツールの検索とツールの実行を組み合わせることであり、検索モデルは、最終的な選択と実行のためにLLMに渡す前に、まず関連するツールをフィルタリングする(Qin et al., 2023; Patil et al., 2023)。検索モデルは、複雑なツールやクエリのセマンティクスを包括的に捕捉することが困難な小さなエンコーダに依存することが多く、検索と実行を分離することは、タスク完了プロセスにおける非効率やステージバイアスにつながる可能性がある。

さらに、LLMとその曖昧性解消器は、主に自然言語データで事前訓練されており (Brown et al., 2020; Touvron et al., 2023)、ツール関連の機能に関する固有の知識は限られている。この知識ギャップは、特にLLMが意思決定のために検索されたツール記述に依存しなければならない場合、パフォーマンスの低下につながる。

本研究では、実世界のツール知識をLLMパラメータに直接統合し、ツール検索と実行を統一的な生成タスクに変換する新しいフレームワークであるToolGenを紹介する。具体的には、ToolGenは、ツールを特定の仮想トークンとして表現するためにLLM語彙を拡張し、対話コンテキストの中でこれらのトークンを生成するためにモデルを訓練することによって、ツールの検索と呼び出しのためにLLMの既存の知識をより効果的に利用する。

具体的には、各ツールはLLM語彙内の一意な仮想トークンとして表現される。事前に訓練されたLLMに基づき、ToolGenの訓練プロセスは3つのフェーズから構成される：ツール記憶、検索訓練、エージェント訓練。ツール記憶フェーズでは、モデルは各仮想ツール・トークンをその文書に関連付ける。最後に、エンドツーエンドのエージェント・チューニングにおいて、モデルは自律的なエージェントとして動作するように訓練され、プランとツールを生成し、タスクを完了するための適切なパラメータを決定します。ツールを起動し、外部環境からフィードバックを得ることで、モデルは効率的かつ統合的にユーザのクエリを処理することができます。図 1 に、ToolGen と従来のパラダイムとの比較を示します。

すなわち、与えられたクエリに対してモデルが正しいツールを検索するツール検索タスクと、モデルが実際のAPIコールを含む複雑なタスクを完了するLLMベースのエージェントタスクである。47,000の実世界ツールのデータセットを用いて、ToolGenは主要なツール検索手法と同程度の性能を示すが、大幅に低コストかつ高効率である。さらに、従来のツール学習のパラダイムを超え、より効果的なツール利用システムを発展させる可能性を強調している。

図1：ToolGenと従来の検索ベースのアプローチとの比較。ToolGenは、ツール・トークンを直接生成することで、ツール検索を可能にし、外部リトリーバに依存することなくタスクを達成することができる。

ToolGenは、ツールとのインタラクションのための新しいパラダイムを示し、検索と生成を統一されたモデルに融合している。この革新は、広範なドメイン・ツールに適応できる新世代のAIエージェントの基礎を築くものである。さらに、ToolGenは、連鎖思考推論や強化学習のような高度な技術を、ツール使用のための統一された生成的アプローチと組み合わせるための新たな機会を創出し、実世界のアプリケーションにおける大規模な言語モデルの能力を拡張する。

まとめると、我々の貢献は以下の通りである：

• ツール検索と実行を仮想トークンを介した大規模言語モデルの生成プロセスに統合する新しいフレームワーク、ToolGenを提案する。
• ToolGenをツール検索とAPI呼び出しのために効率的かつスケーラブルにするために、3段階のトレーニングプロセスが設計された。
• 実験的検証の結果、ToolGenは、大規模なツール・リポジトリにおいて、利用可能な最良のツール検索手法に匹敵する性能を示すが、より低コストで、より効率的に、従来のツール学習のパラダイムを超えていることが示された。

2 関連作品

2.1 ツールの検索

ツール検索は、大規模な言語モデルエージェントの実用的なタスク実行において重要である。スパース検索(例. BM25 (Robertson et al., 2009)) や集中的検索 (DPR (Karpukhin et al., 2020), ANCE (Xiong et al., 2021) など) は、大規模な文書インデックスと外部モジュールに依存しているため、非効率であり、エンドツーエンドのエージェントフレームワークでの最適化が困難である。いくつかの研究では、代替的なアプローチが検討されている。例えば、Chenら(2024b)は、教師なし検索の設定に向けて、クエリを書き換え、その意図を抽出するが、結果は教師ありの手法ほど良くない。Xuら(2024)は、ツールのフィードバックに基づいてクエリを反復的に最適化することで、検索精度を向上させるが、待ち時間を増加させるアプローチを提案する。

近年、生成的検索は、従来の検索メカニズムに依存するのではなく、モデルが関連する文書識別子を直接生成する、有望な新しいパラダイムとして浮上してきた（Wang et al.）これに触発されて、ToolGenは、ツールの検索と呼び出しを生成タスクとして扱うことができるように、各ツールを一意なトークンとして表現する。検索を単純化するだけでなく、この設計は、連鎖思考推論（Wei et al. リ・アクト (Yao et al., 2023））がスムーズに統合される。検索とタスク実行を単一の大きな言語モデルエージェントに統合することで、待ち時間と計算オーバーヘッドを削減し、タスク完了の効率と効果を向上させる。

2.2 ツールコールを持つ大規模言語モデルエージェント

大規模言語モデルは、様々なタスクに必要なツールを使いこなす強い可能性を示している。しかし、既存の研究のほとんどは、限られた動作のセットに焦点を当てている（Chen et al.）例えば、Toolformer (Schick et al., 2023)は、GPT-Jを微調整して、5つのツール（例えば、電卓）のみを扱うようにした。ToolBench (Qin et al., 2023)は、16,000以上のツールを導入することで研究を拡張し、複雑な環境におけるツール選択の課題を浮き彫りにしている。

ツール選択を実行するために、現在のアプローチは通常、検索生成パイプラインを採用しており、大規模言語モデルがまず関連ツールを検索し、次にそれを利用する（Patil et al.）しかし、パイプラインアプローチは、2つの主な問題に直面している：検索ステップのミスパスと、大規模言語モデルが単純なプロンプトを通じてツールを完全に理解し、利用することの難しさである。

これらの問題を軽減するために、研究者は行動をトークンとして表現し、行動予測を生成タスクに変換することを試みてきた。例えば、RT2(Brohan et al., 2023)はロボットの行動を表すTokenを生成し、Self-RAG(Asai et al., 2023)は文書を取得するタイミングを決定するために特別なTokenを使用する。ToolkenGPT(Hao et al., 2023)は道具の使用をトリガーするために道具固有のTokenを導入するが、これは我々のアプローチに最も近い概念である。私たちのアプローチに最も近い概念である。

我々のアプローチは、ToolkenGPTとは大きく異なります。第一に、ToolkenGPTが入力数の少ないより単純なツール（例えば、2つの数値を持つ数学関数）に限定されているのに対して、複雑なタスク（例えば、YouTubeチャンネル検索）のために柔軟なパラメータを必要とする実際のツールに焦点を当てています。さらに、ToolkenGPTは、より少ないサンプル・キューに依存するのに対し、ToolGenは、完全なパラメータ微調整を通じて、より大きな言語モデルにツール知識を直接統合し、自律的にタスクを検索し、実行することを可能にする。最後に、我々の実験では、ToolkenGPTの13-300個に対して、47,000個というはるかに大規模なツール・セットを使用しています。

ToolPlanner (Wu et al., 2024b)やAutoACT (Qiao et al., 2024)などの他の研究では、強化学習やマルチエージェントシステムを使用して、ツールの学習やタスクの完了を強化している(Qiao et al., 2024; Liu et al., 2023; Shen et al., 2024; Chenら、2024a）。(1)これらの取り組みのほとんどは、Reflection (Shinn et al., 2023)や報酬モデルのようなフィードバックメカニズムに依存しており、ToolBenchの評価設計に類似している。しかしながら、これは我々の研究の焦点ではなく、我々のエンド・ツー・エンドの実験はそのようなフィードバック・メカニズムに依存しない。 (2)我々のアプローチはこれらの手法と対立するものではなく、むしろ統合することができる。そのような統合の探求は今後の研究に委ねられる。

3 ツールジェン

本節では、まず本稿で使用する記号表現を紹介する。次に、図2に示すように、ツールの仮想化、ツールメモリ、検索トレーニング、エンドツーエンドのエージェントチューニングを含むToolGenの具体的なアプローチについて詳細に説明する。最後に、我々の推論手法を示す。

図 2: ToolGen フレームワークの概略図。ツールの仮想化フェーズでは、ツールが仮想トークンにマッピングされ、次の3つの学習フェーズでは、ToolGenはまず、ツール・ドキュメントからツール・トークンを予測することによってツールを記憶する。次に、ToolGenはクエリからツール・トークンを予測することで、ツールを検索することを学習する。最後に、パイプライン・データ（すなわち軌跡）は、最後の段階で検索モデルを微調整するために使用され、ToolGenエージェント・モデルを生成する。

3.1 予備知識

与えられたユーザクエリqに対して、ツール学習の目標は、ツールの大規模な集合D={d1,d2,...,dN}からツールを使用してqを解くことである。ここで、｜D｜=Nは大きな数であり、大規模な言語モデリング環境においてDにすべてのツールを含めることは非現実的である。したがって、現在の研究では、通常、Dk,R={dr1,dr2,...,drk}=R(q,k,D)、ここで｜Dk,R｜≪N]と示される、Dからk個の関連ツールを検索するためにリトリーバRを使用する。タスク（クエリ）を完了するために、大規模言語モデルに基づくエージェントは、通常、4段階の反復を使用する（Qu et al.このモデルは、タスクが完了するまでこれらのステップを繰り返し続け、その時点で最終的な回答aが生成される。 軌跡全体は、Traj=[Prompt,(p1,ds1,c1,f1),...,(pt,dst,ct,ft),a]=[q,R(q,D),(p1,ds1,c1,f1),...,(pt,dst,ct,ft),a].この反復的アプローチにより、モデルは、受け取ったフィードバックに基づいて、各ステップで動的にその操作を調整し、改良することができ、その結果、複雑なタスクを達成する性能が向上する。

3.2 ツールの仮想化

ToolGenでは、アトミックインデキシングと呼ばれるアプローチによって、各ツールを一意の新しいトー クンにマッピングすることにより、ツールの仮想化を実装する。このアプローチでは、大規模な言語モデルの語彙を拡張することで、各ツールに一意のTokenが割り当てられる。各ツールTokenの埋め込みは、対応するツール名の平均埋め込みに初期化されるため、各ツールに意味的に意味のある開始点が提供される。

ここで、Indexはツールをトークンにマップする関数である。アトミックインデッ クス作成は、他のインデックス作成方法（セマンティックマッピングや数値マッピングなど。）

3.3 ツールメモリー

Tokenをツールに割り当てた後、ビッグ言語モデルはツールに関する知識をまだ欠いている。この問題に対処するため、ツール記述を入力とし、それに対応するトーケンを出力とすることで、ツール記述を微調整する。次のような損失関数を用いる：

ここで、θは大規模言語モデルのパラメータを表し、ddocはツールの記述を表す。このステップでは、大規模言語モデルに対するツールの基本および関連する操作を提供する。

3.4 検索トレーニング

次に、仮想ツール・トークン（およびその文書）の隠れた空間をユーザー・クエリの空間と関連付けるようにビッグ・ランゲージ・モデルを訓練する。この目的のため、ユーザークエリを入力とし、対応するツールTokenを出力とすることで、ビッグ言語モデルを微調整する：

ここで、θ′はツール記憶後の大規模言語モデルのパラメータを表し、Qはユーザー・クエリの集合であり、Dqは各クエリに関連付けられたツールの集合である。このプロセスはToolGenレトリーバーを生成し、与えられたユーザー・クエリに対して適切なツール・トークンを生成することを可能にする。

3.5 エンド・ツー・エンド・エージェントのチューニング

検索学習後、ビッグランゲージモデルはクエリからTool Tokenを生成することができる。最終段階では、Agent-Flanタスクを使用して軌道微調整モデルを完成させる。私たちのパイプラインは、まずモデルがThoughtを生成し、次に対応するAction Tokenを生成し、このAction Tokenはツール文書をフェッチするために使用され、次にビッグ・ランゲージ・モデルが必要なパラメータを生成するために使用される。このプロセスは、モデルが「完了」トークンを生成するか、最大ラウンド数に達するまで繰り返される。生成された軌跡は、Traj=[q,(p1,Index(ds1),c1,f1),...,(pt,Index(dst),ct,ft),a]のように表される。この構造では、連想ツールはもはや必要ない。

3.6 推論

推論過程において、大規模な言語モデルは、予め定義された道具トークンの集合を超えるアクション・トークンを生成する可能性がある。これを防ぐために、我々は、出力トークンを道具トークンの集合に限定する制約バンドル探索生成法を考案する。この制約バンドル探索を、ツール検索(ここでモデルはクエリ選択ツールに基づく)やエンドツーエンドのエージェントシステムに適用し、アクション生成ステップにおける錯覚を効果的に低減する。詳細な分析については5.4を参照のこと。実装の詳細については付録Cを参照のこと。

4 ツール検索評価

4.1 実験セットアップ

学習済みのLlama-3-8Bモデル(Dubey et al., 2024)を128,256の語彙を持つベースモデルとして使用し、アトミックインデッ クス法によりツールの仮想化中に46,985のトークンが追加され、最終的に175,241の語彙となった。学習率スケジューラと3%のウォームアップステップを適用した。最大学習率は4×10-5であった。全てのモデルは4×A100 GPU上のDeepspeed ZeRO 3を通過させた（Rajbhandari et al.2020)を訓練した。道具記憶訓練8ラウンドと検索訓練1ラウンドが行われた。

データセット

各APIは、API名、説明、呼び出しパラメータを含む辞書を使用して文書化されている。実際の例については付録を参照のこと。 A各APIを操作として扱い、トークンにマッピングする。私たちは各APIを操作として扱い、それをトークンにマッピングします。私たちの検索とエンドツーエンドのエージェント・チューニング・データは、ToolBenchの生データから変換されます。詳細は付録を参照 G.各ツールは複数のAPIを含む可能性があるが、簡略化のため、本文書では各APIをまとめてツールと呼ぶ。

我々は、Qinら（2023）のデータ分割方法論に従い、200,000のペア（クエリ、関連するAPI）を3つのカテゴリーに分類した：I1（シングルツールクエリ）、I2（クラス内のマルチツールクエリ）、I3（コレクション内のマルチツールコマンド）であり、それぞれ87,413、84,815、25,251のインスタンスを含む。

ベースラインの方法論

ToolGenを以下のベンチマークと比較する：

• BM25: 古典的なTF-IDFに基づく教師なし検索手法で、クエリと文書間の単語の類似度に基づく。
• 埋め込み類似度（EmbSim）：OpenAIの文埋め込みモデルを使用して生成された文埋め込み。
• Re-Invoke（Chen他、2024b）：クエリの書き換えと文書の拡張を組み込んだ教師なし検索手法。
• IterFeedback (Xu et al., 2024): 最大10ラウンドの反復フィードバックのためのフィードバックモデルとしてgpt-3.5-turbo-0125を使用するBERTベースのリトリーバ。
• ToolRetriever（Qin et al, 2023）：コントラスト学習によって訓練されたBERTベースのレトリーバー。

セットアップ

我々は2つの設定で実験を行った。最初の設定では、ドメイン内検索は、検索空間が同じドメイン内にあるツールの検索を制限する。例えば、I1ドメイン内のクエリを評価する場合、I1内のツールに制限される。この設定は、ToolBench設定と一致します。2つ目の設定であるマルチドメイン検索は、より複雑であり、検索空間は、3つのタイプのドメインすべてのツールに拡張される。この場合、モデルはマージされたデータで学習され、検索空間とタスクの複雑さが増加する。ToolBenchとは異なり、マルチドメイン設定は、検索タスクが重複または混合ドメインを含む可能性のある現実的なシナリオを反映する。この設定では、ドメイン間で汎化し、より複雑で多様な検索タスクを処理するモデルの能力を評価する。

規範

NDCGは、検索されたツールの関連性とランキング位置の両方を考慮に入れる。

BM25、EmbSim、およびRe-Invokeは、訓練されていない教師なしベンチマーク手法である。ToolRetrieverは対比学習により学習され、ToolGenは次のトークン予測により学習される。また、データは原著論文のものであるため、ドメイン内設定でのみ記載した。ドメイン内設定のToolGenについては、生成空間に全てのトークンを含めることを許可しており、これは他のモデルと比較してより困難なシナリオである。各カテゴリにおける最適な結果は太字で示されている。

4.2 結果

表1にツール検索の結果を示す。予想通り、すべての学習済みモデルは、すべてのメトリクスにおいて未学習のベースライン（BM25、EmbSim、Re-Invoke）を大幅に上回っており、工具検索データで学習することの優位性が示されている。

我々の提案するToolGenモデルは、どちらの設定においても一貫して最高の性能を発揮する。ドメイン内設定では、ToolGenは、複数のモデルとフィードバック・メカニズムを用いたIterFeedbackシステムに匹敵する性能で、非常に競争力のある結果を提供する。単一のモデルとして、ToolGenは全ての測定基準においてToolRetrieverを大幅に上回り、さらにいくつかのシナリオにおいてIterFeedbackを上回る（例えば、ドメインI1ではNDCG@5、I2ではNDCG@1, @3, @5）。

マルチドメイン設定では、ToolGenは、より大きな検索空間と全体的な性能の通常の低下にもかかわらず、ToolRetrieverを凌駕し、ベースラインモデルよりも優位に立ち、頑健性を維持している。これは、ToolGenが単一モデルであるにもかかわらず、IterFeedbackのような複雑な検索システムに対抗できることを示しており、領域の境界が不明確な複雑な実世界の検索タスクを処理する能力を実証している。

4.3 インデックスの方法の比較

ToolGenは、ツール仮想化のためにアトミック・インデックスを使用するが、我々はまた、いくつかの代替的な生成的検索方法を探求する。このセクションでは、以下の3つのアプローチと比較する：

• デジタル：各ツールを一意の番号にマッピングする。生成されたトークンは純粋にデジタルであり、本質的な意味情報を提供しないが、各ツールの一意の識別子を提供する。
• 階層型：この手法は、ツールを重複しないグループにクラスタ化し、これらのクラスタを再帰的に分割して階層構造を形成する。この構造のルートノードからリーフノードへのインデックスが各工具を表し、ブラウンのクラスタリング手法と似ている。
• セマンティクス：このアプローチでは、各ツールはその名前にマッピングされ、ツール名の意味内容を通してラージ言語モデル（LLM）をガイドする。ツール名は、その機能に関連する意味のある表現を直接提供する。

図3：各インデックス付け方法では、ツールごとのサブトーケン数の分布が異なる。アトミックインデクシングでは、各ツールが単一のトークンであることが保証されるのに対し、数値インデクシングでは、ツールはN個のトークンにエンコードされる。対照的に、セマンティック索引付けと階層的索引付けは可変数のサブトークンを生成し、セマンティック索引付けはサブトークンのシーケンスが長くなり、外れ値が多くなる。

具体的な実施内容は付録Bに記載されている。

まず、図 3 に示すように、各工具を表現するために各手法が必要とするサブ・トークンの数を分析した。この効率性により、ToolGenはトークン生成の回数を減らし、検索とエージェントの両方のシナリオで推論時間を短縮することができる。

次に、異なるインデックス作成方法の有効性を検証した。表2に示すように、セマンティック索引付けは多くの指標とシナリオで最高の検索性能を示すが、アトミック索引付けは多くのケースで僅差の2位である。これは、セマンティック・インデックスの方が、大規模言語モデルの事前学習データによくマッチするためである。しかし、この利点は学習データとタイプが増えるにつれて減少する。例えば、セクション5.3では、atomicインデックスがend-to-endの結果においてより良い性能を発揮することを示す。これらの要因を考慮し、ToolGenツールの仮想化にはアトミック・インデックスを選択します。

表2：マルチドメイン設定における様々なインデックス作成方法の検索評価。最も良い結果は太字で、次に良い結果には下線が引かれている。

表3：工具検索のためのアブレーション研究。ToolGenの性能に対する検索トレーニング、ツール・メモリー、および制約付きビーム検索の削除の効果は、個別に評価されている。

4.4 アブレーション実験

ToolGenの異なるトレーニングフェーズの効果を評価するために、アブレーション実験を行った。 3 示される。この結果から、検索トレーニングは、入力がクエリ、出力がツール・トークンである検索タスクを直接整合させるため、ツール検索の性能に影響を与える重要な要因であることがわかる。付録で示すように、ツールメモリを削除すると、汎化性能の向上には役立つが、性能は若干低下する。 F でさらに議論する。同様に、制限されたバンドル検索は、検索タスクにはほとんど寄与しないが、幻覚の発生を防ぐのに役立つため、エンド・ツー・エンドのエージェントタスクにおいてある程度の価値がある。

5 エンド・ツー・エンドの評価

5.1 実験セットアップ

ToolGenフレームワークに適合させるために、ToolBenchからのトレース・データにいくつかの変更を加えました。例えば、ToolGen は入力として関連ツールの明示的な選択を必要としないため、システム・プロンプトからこの情報を削除した。これに基づいて、再フォーマットされたデータを使用して検索モデルを微調整し、エンドツーエンドの ToolGen エージェントを生成しました。

ベースラインモデル

• GPT-3.5：ベースラインモデルの1つとしてgpt-3.5-turbo-0613を使用する。実装はStableToolBench (Guo et al., 2024)と同じであり、GPT-3.5のツール呼び出し機能がツールエージェントの形成に使用されている。
• ToolLlama-2: Qin et al. (2023)は、Llama-2 (Touvron et al., 2023)モデルをToolBenchデータで微調整することにより、ToolLlama-2を導入した。
• ToolLlama-3：公平な比較を保証するために、ToolBenchデータセット上でToolGenと同じベースモデルLlama-3を微調整することにより、ToolLlama-3ベースラインモデルを作成した。本稿では、ToolLlama-2 と区別するために、ToolLlama-3 を ToolLlama と呼ぶ。

セットアップ

• Genuine Tools (G.T.)の使用：Qin et al.(2023)を参照し、クエリに対するGenuine Toolsを以下のように定義する。 チャットGPT 選択されたツール。ToolLlama については、学習データと同じ形式で、プロンプトに実際のツールを直接入力した。ToolGenについては、事前に選択されたツールのデータで訓練されていないため、接頭辞を追加しました：私は計画段階で次のツールを使用しています：[ツールトークン]。
• リトリーバの使用：エンドツーエンドの実験では、検索ベースのセットアップを使用する。ベースラインモデルでは、ToolRetriever によって検索されたツールを関連ツールとして使用する。一方、ToolGen はツール・トークンを直接生成するため、リトリーバを使用しない。

すべてのモデルは、最大学習率を4×10-5に設定したコサイン・スケジューラを使って微調整された。 コンテキスト長は6,144に切り詰められ、総バッチ・サイズは512に設定された。 さらに、フラッシュ・アテンション（Dao et al.、2022; Dao、2024）とディープスピードZeRO 3（Rajshandari et al.Rajbhandari et al., 2020)を使用してメモリーを節約した。

ToolLlamaは1ラウンドでアイデア、アクション、パラメータを生成するが、ToolGenはこれらのステップを分離する。ToolGenでは、最大16ラウンドの上限を設定し、5ラウンドのアクションと1ラウンドの最終回答を可能にした。これをToolLlamaの6ラウンドの上限と比較する。

さらに、早期終了を防ぐために、すべてのモデルにリトライメカニズムを導入した。具体的には、モデルが "give up "または "I'm sorry "を含む応答を生成した場合、より高い温度で応答を再生成するよう促す。

指標の評価

エンドツーエンドの評価には、安定したツール評価ベンチマークStableToolBench (Guo et al., 2024)を使用する。これは、ToolBenchから解決可能なクエリを選択し、GPT-4 (OpenAI, 2024)を使用して失敗したツールの出力をシミュレートする。我々は2つの指標を用いて性能を評価する：解決可能合格率(SoPR)は、成功裏に解決されたクエリのパーセンテージであり、解決可能勝率(SoWR)は、参照モデル(本研究ではGPT-3.5)を上回る回答のパーセンテージを示す。さらに、各カテゴリーのスコアのミクロ平均を提供する。

表4：2つの設定における未読コマンドのエンド・ツー・エンド評価の性能。R.設定では、GPT-3.5とToolLlamaはToolRetrieverを使用し、ToolGenは外部retrieverを使用しない。すべての結果のSoPRとSoWR評価は3回実行され、平均値として報告される。

5.2 結果

表4は、実ツール(G.T.)とレトリバー(R.)を使用した2つの環境における各モデルのエンドツーエンドの評価性能を示しています。G.T.環境では、ToolGenは平均SoPRスコア54.19を達成し、GPT-3.5とToolLlamaを上回り、ToolGenは最高SoWRスコア49.70を達成しました。ToolGenは、平均SoPR53.28とSoWR51.51を達成し、Retriever環境でもリードを維持しています。ToolLlamaは、いくつかの個別インスタンスで実ツールを上回り、競争力を示しました。ToolLlamaは競争力を示し、いくつかの個別インスタンスではToolGenを上回った。ToolGenによるエンド・ツー・エンドのアブレーション研究は付録Gに示されている。

表5：異なるインデックス作成方法のエンド・ツー・エンド評価。

5.3 インデックスの方法の比較

検索タスクにおけるインデクシング手法の比較（セクション4.3）と同様 に、表5はエンド・ツー・エンド・エージェント・タスクにおける各インデクシング 手法の比較を示している。このセットアップでは、制限されたデコードが取り除かれ、エージェントは自由に思考、アクション、パラメータを生成することができる。結果から、アトミックインデクシング法は4つのインデクシング法の中で最も良いパフォーマンスを示した。これはセクション5.4で議論したように、他の手法のファントム率が高いためである。

図4：存在しないツールを生成する際の、異なるモデルのファントム率を示す。ToolGenは、制限付きデコードを使用する場合、非存在ツールを生成しない。しかし、この制限を設けない場合、ToolGenはアトミックインデックスを使用するとアクション生成フェーズで7%の非ツールTokenを生成し、セマンティックインデックスを使用すると錯視率が高くなる。ToolLlamaとGPT-3.5では、ヒントに5つの実ツールが指定されていても錯視が発生する。ヒントでツールが指定されない場合、ToolLlamaは50%を超える存在しないツール名を生成する。

5.4 幻覚

エンドツーエンドのエージェントシナリオにおいて、ツール生成におけるモデルのファントム状況を評価する。そうするために、我々はモデルのトレーニングと一貫したフォーマットでクエリを入力する。具体的には、ToolGen については、クエリを直接入力し、ToolGen エージェントのパラダイム（すなわち、思考、ツール、パラメータの順）に従って応答を生成するようにモデルを促す。セクション 3.6 で説明したバンドル探索の制限なしに Action デコードをテストした。ToolLlamaとGPT-3.5については、クエリーを入力し、5つの実際のツールを含めた。すべての設定において、すべてのツール生成アクションにおいて生成されたツールのうち、データセットに存在しないツールの割合を報告する。図4は、異なるモデルによって生成された存在しないツールのファントム率を示している。図からわかるように、ToolLlamaとGPT-3.5は、5つの実際のツールしか提供されていないにもかかわらず、存在しないツール名を生成する可能性が依然として高い。対照的に、ToolGenは、その制限されたデコード設計により、幻覚を完全に回避します。

6 結論

本論文では、ToolGenを紹介する。ToolGenは、ツール固有の仮想トークンをモデル語彙に埋め込むことにより、ツールの検索と実行を統合する大規模言語モデリング（LLM）フレームワークである。3段階の学習プロセスを含むことにより、ToolGenは、実世界のシナリオにおいてツールを効率的に検索し、実行するLLMを強化する。この統一されたアプローチは、大規模なツールライブラリを扱うことができるスケーラブルで効率的なAIエージェントの新たなベンチマークとなる。今後、ToolGenは、思考連鎖推論、強化学習、ReActなどの先進技術を統合する扉を開き、実世界のアプリケーションにおけるLLMの自律性と汎用性をさらに強化する。

参考文献

• Asai et al (2023) ↑Akari Asai, Zeqiu Wu, Yizhong Wang, Avirup Sil, and Hannaneh Hajishirzi.Self-rag: Learning to retrieve, generate, and critique.自己反省を通して, 2023.URL https://arxiv.org/abs/2310.11511.
• アンソニー・ブロハン、ノア・ブラウン、ジャスティス・カルバハル、エヴゲン・チェボター、シー・チェン、クシシュトフ・チョロマンスキー、ティンリー・ディン、ダニー・ドリース、アヴィナヴァ・ドゥベー、チェルシー・フィン、ピート・フローレンス、チューユアン・フー、モンセ・ゴンザレス・アレナ、キールタナ・ゴパラクリシュナン、ケハン・ハン、カロルアビナバ・ドゥベー、チェルシー フィン、ピート・フローレンス チューユアン・フー、モンセ ゴンザレス・アレナス、キータナ ゴパラクリシュナン、ケハン ハン、カロル ハウズマン、アレクサンダーヘルゾグ、ジャスミン・シュー、ブライアン・イクター、アレックス・イルパン、ニヒル・ジョシ、ライアン・ジュリアン、ドミトリー・カラシニコフ、ユヘン・クアン、イザベル・レアル、リサ・リー、ツァンウェイ・エドワード・リーセルゲイ・レヴィン、ヤオ・ルー、ヘンリク・ミハレフスキ、イゴール・モルダッチ、カール・ペルシュ、カニシュカ・ラオ、クリスタ・レイマン、マイケル・リュー、グレシア・サラザール、パンナグ・サンケティ、ピエール・セルメネ、ジャスピル・ジョシ、ライアン・ジュリアン、ドミトリー・カラシニコフ、ユヘン・クアン、イザベル・レアル、リサ・リー、ツァンウェイ・エドワード・リーピエール・セルネット、ジャスピアール・シン、アニカイト・シン、ラドゥ・ソリクト、フオン・トラン、ヴィンセント・ヴァンホーク、クアン・ヴオン、アイザーン・ワヒド、ステファン・ウェルカー、ポール・ヴォールハートRt-2: Vision-language-action models transfer web knowledge to robotic control, 2023 URL.ロボット制御、2023.URL https://arxiv.org/abs/2307.15818.
• Brown et al. (2020) ↑Tom B. Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam.ギリシュ・サストリー、アマンダ・アスケル、サンディニ・アガルワル、アリエル・ハーバート＝ボス、グレッチェン・クルーガー、トム・ヘニガン、リウォン・チャイルド、アディティヤ・ラメシュ、ダニエル・M・ジーグラージェフリー・ウー、クレメンス・ウィンター、クリストファー・ヘッセ、マーク・チェン、エリック・シグラー、マテウス・リトウィン、スコット・グレイ、ベンジャミン・チェス、ジャック・クラーク、クリストファー・バーナー、サム言語モデルは少数の学習者である。Ranzato, Raia Hadsell, Maria-Florina Balcan, and Hsuan-Tien Lin (eds.). 神経情報処理システムの進歩33：神経情報処理システム2020年年次大会、NeurIPS 2020、12月6-12日、2020, バーチャル2020.URL https://proceedings.neurips.cc/paper/2020/hash/1457c0d6bfcb4967418bfb8ac142f64a-Abstract.html.
• Chen et al. (2023a) ↑Baian Chen, Chang Shu, Ehsan Shareghi, Nigel Collier, Karthik Narasimhan, and Shunyu Yao.Fireact: Toward language agent fine- tuning.チューニング。arXiv preprint arXiv:2310.05915, 2023a.
• Chen et al. (2023b)↑Jiangui Chen, Ruqing Zhang, Jiafeng Guo, Maarten de Rijke, Wei Chen, Yixing Fan, and Xueqi Cheng.Continual Learning for Generative動的コーパに対する検索。 第32回ACM情報知識マネジメント国際会議論文集CIKM '23, pp. 306-315, New York, NY, USA, 2023b. Association for Computing Machinery.3583780.3614821.url https://dl.acm.org/doi/10.1145/3583780.3614821.
• Chen et al. (2024a)↑Junzhi Chen, Juhao Liang, and Benyou Wang.Smurfs: Leveraging multiple proficiency agents with context-efficiency for tool.プランニング, 2024a.URL https://arxiv.org/abs/2405.05955.
• Chen et al. (2024b)↑Yanfei Chen, Jinsung Yoon, Devendra Singh Sachan, Qingze Wang, Vincent Cohen-Addad, Mohammadhossein Bateni, Chen-Yu Lee, andRe-invoke: tool invocation rewriting for zero shot tool retrieval.arXiv preprint arXiv:2408.01875, 2024b.
• Chen et al. (2024c)↑Zehui Chen, Kuikun Liu, Qiuchen Wang, Wenwei Zhang, Jiangning Liu, Dahua Lin, Kai Chen, and Feng Zhao.Agent-flan: Designing data and methods effective agent tuning, 2024c.大規模言語モデルのための効果的なエージェントチューニングの方法、2024c.URL https://arxiv.org/abs/2403.12881.
• ダオ (2024)↑Tri Dao.FlashAttention-2：より優れた並列性とワーク分割によるアテンションの高速化.In 学習表現に関する国際会議 (ICLR), 2024.
• Dao et al. (2022)↑Tri Dao, Daniel Y. Fu, Stefano Ermon, Atri Rudra, and Christopher Ré.FlashAttention: Fast and memory-efficient exact attention with IO-awareness.IO-awareness.In。 神経情報処理システムの進歩 (NeurIPS), 2022.
• Dubey et al. (2024)↑Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schelten, Amyヤン、アンジェラ・ファン、他。モデルのラマ3群れ。arXiv preprint arXiv:2407.21783, 2024.
• グラビタス (2023)↑Gravitas.AutoGPT, 2023.URL https://github.com/Significant-Gravitas/AutoGPT.
• Guo et al. (2024)↑Zhicheng Guo, Sijie Cheng, Hao Wang, Shihao Liang, Yujia Qin, Peng Li, Zhiyuan Liu, Maosong Sun, and Yang Liu.StableToolBench: Towards Large-scale Benchmark on Tool Learning on Large Language Models.大規模言語モデルのツール学習に関する安定した大規模ベンチマーク, 2024.URL https://arxiv.org/abs/2403.07714.
• Hao et al. (2023)↑Shibo Hao, Tianyang Liu, Zhen Wang, and Zhiting Hu.Toolkengpt: Augmenting frozen language models with massive tools via tool embeddings..Inアリス・オー、トリスタン・ナウマン、アミール・グロバーソン、ケイト・サエンコ、モーリッツ・ハルト、セルゲイ・レヴィン (eds.) 神経情報処理システムの進歩36：神経情報処理システム2023年年次会議、NeurIPS 2023、ニューオーリンズ、LA、米国、2023年12月10日-16日米国、2023年12月10日～16日2023.URL http://papers.nips.cc/paper_files/paper/2023/hash/8fd1a81c882cd45f64958da6284f4a3f-Abstract-Conference.html.
• Järvelin & Kekäläinen (2002)↑Kalervo Järvelin and Jaana Kekäläinen.Cumulated gain-based evaluation of ir techniques.ACM情報システム論文集(TOIS), 20(4):422-446, 2002.
• Karpukhin et al. (2020)↑Vladimir Karpukhin, Barlas Oguz, Sewon Min, Patrick Lewis, Ledell Wu, Sergey Edunov, Danqi Chen, and Wen-tau Yih.Dense passageボニー・ウェバー、トレバー・コーン、何玉蘭、ヤン・リウ（編）。 2020年自然言語処理経験的手法（EMNLP）会議論文集計算言語学会, pp.6769-6781, Online, 2020. https://aclanthology.org/2020.emnlp-main.550.
• Kishore et al. (2023)↑Varsha Kishore, Chao Wan, Justin Lovelace, Yoav Artzi, and Kilian Q. Weinberger.Incdsi: Incrementally updatable document retrieval.In Andreas Krause, Emma Brunskill, Kyunghyun Cho, Barbara Engelhardt, Sivan Sabato and Jonathan Scarlet.Andreas Krause, Emma Brunskill, Kyunghyun Cho, Barbara Engelhardt, Sivan Sabato, and Jonathan Scarlett (eds.). 機械学習国際会議、ICML 2023、2023年7月23-29日、米国ハワイ州ホノルル第202巻 機械学習研究論文集PMLR, 2023.URL。 https://proceedings.mlr.press/v202/kishore23a.html.
• Liu et al. (2024)↑Xiao Liu, Hao Yu, Hanchen Zhang, Yifan Xu, Xuanyu Lei, Hanyu Lai, Yu Gu, Hangliang Ding, Kaiwen Men, Kejuan Yang, et al.エージェントベンチ。llmsをエージェントとして評価する。 第12回学習表現国際会議, 2024.
• Liu et al. (2023)↑ Zhiwei Liu, Weiran Yao, Jianguo Zhang, Le Xue, Shelby Heinecke, Rithesh Murthy, Yihao Feng, Zeyuan Chen, Juan Carlos Niebles, Devansh.Bolaa:ベンチマークとオーケストレーションllm-augmented自律エージェント。arXiv preprint arXiv:2308.05960, 2023.
• Mehta et al. (2023)↑Sanket Vaibhav Mehta, Jai Gupta, Yi Tay, Mostafa Dehghani, Vinh Q. Tran, Jinfeng Rao, Marc Najork, Emma Strubell, and Donald Metzler.DSI++: 新しいドキュメントでトランスフォーマーのメモリを更新する.In Houda Bouamor, Juan Pino, and Kalika Bali (eds.) 自然言語処理における経験的方法に関する2023年会議録計算言語学会. doi: 10.18653/v1/2023.emnlp-main.510.URL https://aclanthology.org/2023.emnlp-main.510.
• OpenAI (2024)↑OpenAI.Gpt-4 テクニカルレポート、2024.URL https://arxiv.org/abs/2303.08774.
• Patil et al. (2023) ↑Shishir G. Patil, Tianjun Zhang, Xin Wang, and Joseph E. Gonzalez.Gorilla: Large language model connected with massive apis, 2023.URL https://arxiv.org/abs/2305.15334.
• Qiao et al. (2024)↑Shuofei Qiao, Ningyu Zhang, Runnan Fang, Yujie Luo, Wangchunshu Zhou, Yuchen Eleanor Jiang, Chengfei Lv, and Huajun Chen.Autoact.自己計画によるQAのためのゼロからの自動学習エージェント、2024.URL https://arxiv.org/abs/2401.05268.
• Qin et al. (2023)↑Yujia Qin, Shihao Liang, Yining Ye, Kunlun Zhu, Lan Yan, Yaxi Lu, Yankai Lin, Xin Cong, Xiangru Tang, Bill Qian, Sihan Zhao, Lauren Hong, Runchu Tian, Ruobing Xie, Jie Zhou, Mark Gerstein, Dahai Li, Zhiyuan Liu, and Maosong Sun.李宏輔、劉志遠、孫茂松、田倫宙、謝汝炳、周杰倫、マーク・ガースタイン、李大海、劉志遠、孫茂松。2023.URL https://arxiv.org/abs/2307.16789.
• Qu et al. (2024)↑Changle Qu, Sunhao Dai, Xiaochi Wei, Hengyi Cai, Shuaiqiang Wang, Dawei Yin, Jun Xu, and Ji-Rong Wen.大規模言語モデルを用いたツール学習：サーベイ。大規模言語モデルを用いたツール学習：サーベイ。arXiv preprint arXiv:2405.17935, 2024.
• Rajbhandari et al. (2020)↑Samyam Rajbhandari, Jeff Rasley, Olatunji Ruwase, and Yuxiong He.Zero: Memory optimizations towards training trillion parameter models.パラメータモデル、2020.URL https://arxiv.org/abs/1910.02054.
• Robertson et al. (2009) ↑Stephen Robertson, Hugo Zaragoza, et al. The probabilistic relevance framework: BM25 and beyond.情報検索の基礎と動向, 3(4):333-389, 2009.
• Schick et al. (2023)↑Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, and Thomas.Scialom.Toolformer：言語モデルは道具の使い方を独学できる、2023.URL https://arxiv.org/abs/2302.04761.
• Shen et al (2024)↑Weizhou Shen, Chenliang Li, Hongzhan Chen, Ming Yan, Xiaojun Quan, Hehong Chen, Ji Zhang, and Fei Huang.小さなllmsは弱いツールである。学習者：マルチllmエージェント、2024.URL https://arxiv.org/abs/2401.07324.
• Shinn et al. (2023)↑Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao.Reflexion: Language agents with verbal.強化学習。 第37回神経情報処理システム国際会議論文集8634-8652頁、2023年。
• Sun et al. (2023)↑Weiwei Sun, Lingyong Yan, Zheng Chen, Shuaiqiang Wang, Haichao Zhu, Pengjie Ren, Zhumin Chen, Dawei Yin, Maarten de Rijke, and Zhaochun.生成検索のためのトークン化の学習. 神経情報処理システムの進歩36：神経情報処理システム2023年年次会議、NeurIPS 2023、ニューオーリンズ、LA、米国、2023年12月10日-16日米国、2023年12月10日～16日2023.URL http://papers.nips.cc/paper_files/paper/2023/hash/91228b942a4528cdae031c1b68b127e8-Abstract-Conference.html.
• Touvron et al. (2023)↑Hugo Touvron, Thibaut Lavril, Gautier Izacard, Xavier Martinet, Marie-Anne Lachaux, Timothée Lacroix, Baptiste Rozière, Naman.ゴヤル、エリック・ハンブロ、ファイサル・アズハル、オーレリアン・ロドリゲス、アルマン・ジュラン、エドゥアール・グラーヴ、ギョーム・ランプル。言語モデル、2023.URL https://arxiv.org/abs/2302.13971.
• Wang et al. (2024)↑Renxi Wang, Haonan Li, Xudong Han, Yixuan Zhang, and Timothy Baldwin.Learning from failure: Integrating negative examples when fine - tuning large language models as agents.-として大規模な言語モデルを微調整する際に、否定的な例を統合する。arXiv preprint arXiv:2402.11651, 2024.
• Wang et al. (2022)↑Yujing Wang, Yingyan Hou, Haonan Wang, Ziming Miao, Shibin Wu, Qi Chen, Yuqing Xia, Chengmin Chi, Guoshuai Zhao, Zheng Liu, Xing Xie, Hao Sun, Weiwei Deng, Qi Zhang, and Mao Yang.Hao Sun, Weiwei Deng, Qi Zhang, and Mao Yang.A neural corpus indexer for document retrieval.In Sanmi Koyejo, S. Mohamed, A. Agarwal, Danielle Belgrave, K . Cho, and A. Oh (2008), a neural corpus indexer for document retrieval.Cho, and A. Oh (eds.). 神経情報処理システムの進歩35：神経情報処理システム2022年年次会議、NeurIPS 2022、ニューオーリンズ、LA、米国、2022年11月28日〜12月9日2022年11月28日～12月9日、米国ロサンゼルス、ニューオーリンズ2022.URL http://papers.nips.cc/paper_files/paper/2022/hash/a46156bd3579c3b268108ea6aca71d13-Abstract-Conference.html.
• Wei et al. (2023)↑Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed Chi, Quoc Le, and Denny Zhou.Chain-of-thought.プロンプトは大規模言語モデルにおける推論を引き出す, 2023.URL https://arxiv.org/abs/2201.11903.
• Wu et al. (2024a)↑Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, Ahmed HassanAutogen: Enabling next-gen llm applications via multi-agent conversation framework.In. コルム, 2024a.
• Wu et al. (2024b)↑Qinzhuo Wu, Wei Liu, Jian Luan, and Bin Wang.ToolPlanner: a Tool Augmented LLM for Multi Granularity Instructions with Path Planning and Feedback.とフィードバック, 2024b.URL https://arxiv.org/abs/2409.14826.
• Xiong et al. (2021)↑Lee Xiong, Chenyan Xiong, Ye Li, Kwok-Fung Tang, Jialin Liu, Paul N. Bennett, Junaid Ahmed, and Arnold Overwijk.密なテキスト検索のための近似最近傍否定的対照学習。 第9回学習表現国際会議ICLR 2021、バーチャルイベント、オーストリア、2021年5月3日～7日. オープンレビューネット、2021.URL https://openreview.net/forum?id=zeFrfgyZln.
• Xu et al. (2024)↑Qiancheng Xu, Yongqi Li, Heming Xia, and Wenjie Li.Enhancing tool retrieval with iterative feedback from large language models.arXiv preprint arXiv:2406.17465, 2024.
• Yao et al. (2023)↑Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao.ReAct: Synergising reasoning and acting in language models.言語モデル.In 学習表現に関する国際会議 (ICLR), 2023.
• Yin et al. (2024)↑Da Yin, Faeze Brahman, Abhilasha Ravichander, Khyathi Chandu, Kai-Wei Chang, Yejin Choi, and Bill Yuchen Lin.Agent lumos: Unified and modular training for open-source language agents.In Lun-Wei Ku, Andre Martins and Vivek Srikumar.オープンソースの言語エージェントのための統一されたモジュール式のトレーニング。 計算言語学会第62回年次大会講演論文集（第1巻：長文論文）計算言語学協会. doi: 10.18653/v1/2024.acl-long.670.URL https://aclanthology.org/2024.acl-long.670.
• Zeng et al. (2023) ↑Aohan Zeng, Mingdao Liu, Rui Lu, Bowen Wang, Xiao Liu, Yuxiao Dong, and Jie Tang.Agenttuning: enable generalised agent abilities.for llms, 2023.

実際のツールの例

地図 5 実際のツールの例を示す。各ツールには複数のAPIが含まれている。実験では以下のフィールドが使用される。tool_name "は、ツールの名前である。"tool_description "は、そのツールが何をするかなど、ツールに関する情報を記述する。各APIにおいて、"name "はAPIの名前である。「description」にはAPIに関する情報を記述する。「method "は、APIを呼び出すhttpメソッドである。"required_parameters "は、APIを呼び出す際に入力しなければならないパラメータである。"optional_parameters "には、追加のパラメータ（オプション）を設定することができる。

{
"tool_name": "YouTube Hub",.
"tool_description": "1つの動画のいいね数、再生回数、タイトル、サムネイルなどの詳細を取得する".,
"home_url": "https://rapidapi.com/itsrohitofficial-XBPdXttOUQ/api/youtube-hub/"、
"host": "youtube-hub.p.rapidapi.com"、
「api_list":[
{
"name": "動画の詳細を取得"、
"url": "https://youtube-hub.p.rapidapi.com/"、
"description": "動画に関するすべての基本情報を取得する"、

"required_parameters":[
{
"name": "id"、
"type": "STRING"、
"description":"、
"デフォルト": "fD6SzYIRr4c"
}
], "optional_parameters".
「optional_parameters":[], .
}
]
}

図5：実際のツールの例。このツールにはAPIが含まれており、簡略化のため不要なフィールドは削除されている。

Bツールの仮想化実装

ToolGenはツールを表現するために単一のユニークなトークンを使用し、ツールの検索と呼び出しに強みを発揮する。また、意味的、数値的、階層的など、ツールを索引付けするための他の方法も紹介しました。以下は、各インデックスの実装方法の詳細です。

アトミック

インデクシングはToolGenで使用している方法である。他の方法とは対照的に、それは単一のTokenをツールとして使用し、存在しないツールをごまかしません。ツール名とAPI名を1つのTokenにまとめるために、<>を使用します。 A このセクションの例では、トークンは <> となります。

言葉の意味

インデックスは各ツールをToolBenchで使用される名前に対応付けますが、これはツール名とAPI名の組み合わせでもあります。しかし、モデルがその意味的な意味を認識できるように、名前は複数のトークンに分解することができます。付録Aの例では、結果のマッピングはget_video_details_for_youtube_hubです。

数値

インデックスは各工具を一意の番号に対応付ける。まず、全工具のリスト（約47,000個）を取得し、すべての工具について、スペースで区切られた5桁の数字を使用して工具を表します。付録Aの例がリストの128番目の要素である場合、0 0 0 0 1 2 8を使用してツールを表します。Llama-3の語彙は各数字をエンコードするので

レイヤリング

また、各ツールを数値にマッピングする。数値インデックスとは異なり、反復的なクラスタリングによって工具表現に構造情報を注入する。各反復では、工具を10のクラスタに分類し、それぞれに0から9までの番号を割り当てる。各クラスタについて、そのクラスタに工具が1つだけになるまで、このクラスタリングプロセスを繰り返す。これらのステップはクラスタリングツリーを形成する。ルートからリーフの番号に進み、そのリーフにあるツールを表現する。付録Aの例では、0 1 2 2 3 3 3 のように、5桁より長い番号を割り当てることができる。

C 制約検索の詳細

エンドツーエンドのエージェントタスクを検索して完了するとき、生成された操作を有効なツールトークンに制限するために、制約付きバンドル検索を使用する。詳細な手順はアルゴリズム1に記述されている。これを行うために、まず、各ノードがツール・トークンIDを表し、そのノードの子ノードが現在のIDに続くすべての実現可能なIDである、不連続な辞書ツリーを構築する。このツリーを使用することで、現在検索されているIDに基づいて、すべての可能な次のトークンIDを決定することができる。ロジットをブロックし、可能なIDを強制的にサンプリングまたは検索する。

検索については、これは生成中に直接適用することができる。エンドツーエンド・エージェント・タスクでは、推論ステップを3つの対話ラウンドに分解するため、ToolGenがいつアクションを生成する必要があるかを容易に検出でき、したがって制約を適用できる。図6は、ToolGenが選択する関連ツールがない場合の、ToolGenのエンドツーエンド推論の例を示しています。ToolGen は ToolToken を生成し、タスクを完了します。

表6：3段階のトレーニングのデータセットの統計。ツールの記憶については、いくつかの重複があり、その結果、使用したツールの数よりも若干サンプルサイズが大きくなっている。

システム：あなたは、与えられたタスクを完了するために数多くのツールや機能を使用する能力を持つAutoGPTです。
1. まず、あなたが始めようとしているタスクの説明を提供します。
2. 各ステップで、あなたはアクショントークンを生成して次のアクションを決定します。
3. トークンの後、トークンに対応するアクション文書を受け取ります。そのアクションの入力を生成し、新しい状態に移行する必要があります。その後、次のステップを決定し、このプロセスを繰り返します。
4.複数のアクションと入力を何度か繰り返した後、あなたはタスクを完了し、最終的な答えを出す。
... ...
最近ビバシティを訪れ、メニューに感銘を受けました。5a76c927bb5d660001e09731のメニューについて詳しく知りたいです。メニューのカテゴリー、価格、在庫状況、ルール、セットメニューなど、関連する詳細を教えてください。メニューの詳細については、'zh-hans'言語を使用してください。
: 会場5a76c927bb5d660001e09731のメニュー詳細を取得するには、「<>」関数を呼び出す必要があります。この関数を呼び出す理由は、メニューのカテゴリー、価格、空き状況、ルール、パッケージアイテム、その他関連する詳細をユーザーに提供するためです。この関数は、パラメータ "lang "を "zh-hans "に、"is_id "を "5a76c927bb5d660001e09731 "に設定して呼び出され、提供されるメニューの詳細が必要な言語であり、会場固有のものであることを確認します。
アクションを生成する。
アクションを生成する。
入力を与える。以下はドキュメントです： {'name': '<>', 'description': 'KVを使用して会場の詳細を取得し（最新のデータを取得するために再同期が必要）、クエリパラメータに基づいて動的な多言語データをフィルタリングします。, 'required': [{'name': 'id', 'type': 'STRING', 'description': '', 'default': '56c467cb7b0d464811a42017'}, {'name': 'lang', 'type': 'STRING', 'description': '', 'default': 'zh-hans'}], 'optional': []}.
::{n "is_id": "5a76c927bb5d660001e09731",{n "lang": "zh-hans"}.
: {'error': '', 'response': {'menu_id': '5a76c927bb5d660001e09731', 'language': 'zh-hans', 'menu_details': {'sections': [{'section_name': 'Appetisers', 'items': [{'item_name': 'Spring Rolls', 'description': 'パリパリの春巻きに特製ソースをかけたもの', 'price': 12.99}, {'item_name': 'Chicken Skewers', 'description': 'スパイシーなチキンケバブ。15.99}]}, {'section_name': 'Mains', 'items': [{'item_name': 'Kung Pao Chicken', 'description': '古典的な四川料理、スパイシーで風味豊か', 'price': 18.99}, {'item_name': 'Steamed Seabass', 'description': '新鮮であっさり、栄養価が高くヘルシー', 'price': 22.99}]}], 'special_notes': 'ベジタリアンメニューもございますので、サーバーにお申し付けください。｝
: 会場 5a76c927bb5d6600e09731 メニューの詳細は以下の通りです。Item 2: Available - Item 3: Available - Item 4: Availablen- Rules: ⅳ- Item 1: 特定のルールについて言及なし - Item 2: 特定のルールについて言及なし - Item 3: 特定のルールについて言及なし - Item 4: 特定のルールについて言及なし Package Items: ⅳ- Item 1: 2包 - Item 2: 2包 - Item 3: 2包 - Item 4: 2包その他：メニューは変更される場合があります。最新の情報は会場にご確認ください。\안녕하세요！
: 行動を起こす。
: <<終了
入力お願いします。以下はドキュメントです：{'required': [], 'optional': [{'name': 'give_answer', 'description': 'Output answer', 'type': 'string'}, {'name': 'give_up_and_restart', '
: {"return_type": "give_answer", "final_answer": "会場5a76c927bb5d660001e09731のメニュー詳細は以下の通りです。Item 3: 18.99 CNYn - Item 4: 22.99 CNYn - Available: ˶ - Item 1: Availability ˶ - Item 2: Availability ˶ - Item 3: Availability ˶ - Item 4: Availability ˶ - Rules: ˶ - Item 1: 特定のルールについて言及なし ˶ - Item 2: 特定のルールについて言及なし ˶ - Item 3: 特定のルールについて言及なし ˶ - Item 4: 特定のルールについて言及なし最新の情報は会場にご確認ください。｝

図6：ToolGenによる推論の例。まず、関連ツールのないシステム・プロンプトが与えられる。次に、ユーザがタスククエリを与え、ToolGenが思考を生成し、ユーザの役割プロンプトモデルを使用してアクションを生成します。アクションを生成した後、再びユーザーを使用してツール文書を提供します。モデルは、この文書に基づいてツールの入力を生成します。

E アブレーションテスト

表 7 にエンド・ツー・エンド評価のアブレーション結果を示す。未使用の命令では、ToolGenエージェントは、ツール記憶または検索トレーニングなしでわずかに良好なパフォーマ ンスを示す。しかし、未見のツールでは、SoPRとSoWRの両方が、最初の2段階のトレーニングなしで低下する。このことは、ToolGenの汎化能力には最初の2段階の訓練が関与し、検索訓練はツール記憶よりも重要であることを示唆している。

表7：ToolGenのend-to-end評価によるアブレーション結果。ここで、Inst.は未見のクエリー（コマンド）を表し、Tool.とCat.はトレーニング中に見られなかったツールを表す。

F 一般化能力

ToolGen Agentについては、訓練されていないツールクエリに対するモデルの性能を測定します。ToolGen Agentの性能はToolLlamaよりも低く、これは完全なタスクを完了する際の汎化が不十分であることを示唆している。汎化の問題は、生成的検索において一般的であり、本稿の範囲を超えている。したがって、今後の研究に委ねる。

表8：ToolGenの汎化結果。ToolGenの性能を、学習中に未知のツールを必要とするクエリについてテストし、他のモデルと比較した。

ToolBenchデータをToolGenに適合させる

我々のToolGenデータは、ToolBenchデータを適応・変換したものである。具体的には、ツール・メモリを学習するためのデータとしてツール・ドキュメントを使用し、入力はツール・ドキュメント、出力は対応するトークンです。

検索学習には、ToolBenchでツール検索用にアノテーションされたデータを使用する。クエリを入力とし、関連するツールを仮想トークンに変換し、検索学習の出力として使用する。

(1)各軌跡には、クエリを解決するために使用できるシステム・ヒントからの利用可能なツールが含まれています。タスクを完了するとき、ToolLlamaはシステム・ヒントで検索されたツールに依存してタスクを解決しますが、ToolGenはツールを直接生成することができます。したがって、システム・ヒントからツールを削除します。(2)軌跡中のすべての道具名を、対応する仮想道具トークンに置き換える。(3)元の軌跡において、知的身体モデルは思考、行動、行動入力（ReActとも呼ばれる）を順次生成する。ReAct全体を3つの対話ラウンドに分解する。最初のラウンドでは、知的身体モデルは思考を生成し、我々はユーザを使ってモデルにアクションの生成を促す。第2ラウンドでは、モデルがアクション、すなわち仮想ツール・トークンを生成し、モデルがどのようなパラメータを指定すべきかを知るために、これらのトークンに対応する文書を取得する。第3ラウンドでは、モデルがツールのパラメータを生成する。

各データセットのサンプル数を表6に示す。ツール記憶と検索トレーニングのサンプルを図7に、エンドツーエンドの知能チューニングのサンプルを図8に示す。

# ツールメモリ
User: Tool Name: Thai Drivers License OCR Tool Description: タイの運転免許証から情報を抽出し、運転免許証番号や個人情報などのテキスト結果を返す API Name: Driver's License API Description: タイの運転免許証から情報を抽出し、運転免許証番号や個人情報などのテキスト結果を返す。
ヘルパー: <> (タイ運転免許証OCRDriver's License)
#検索トレーニング
ユーザー：友人と私は「ウェブ開発」と「モバイルアプリケーション開発」のハッカソンを企画しています。私たちはいくつかのインスピレーションと指導が必要です。Medium.comからこれらのトピックに関する人気のある記事を入手できますか？
ヘルプ： <>を検索してください。

図7：道具の記憶と検索トレーニングのためのデータセット例。ユーザの役割は入力を表し、アシスタントの役割は出力を表す。

# エンド・ツー・エンド・エージェントのチューニング
システム
あなたはAutoGPTであり、与えられたタスクを完了するために多くのツールと機能を利用することができます。
1. まず、タスクの説明を提供し、タスクが開始されます。
2.各ステップでは、Action Tokenを生成して次のアクションを決定します。
3.トークンの後、トークンに対応するアクションのドキュメントを受け取ります。新しい状態に移行するためのアクションのインプットを生成する必要があります。そして次のステップを決定し、このプロセスを繰り返す。
4.複数のアクションとインプットを生成することを何度か繰り返した後、あなたは最終的にタスクを完了し、最終的な答えを提供します。
覚えておいてほしい：
1. 状態の変化は不可逆であり、前の状態に戻ることはできない。
2. 操作はシンプルにし、現在のクエリに最適なものに限定する。
3.複数回の試行が可能です。異なる条件を試し続けるつもりなら、一度に1つの条件を試す。 4.
4. 十分な情報を収集したと思ったら、「<> with argument give_answer」というアクションを生成して、タスクに対する答えを提供する。
5. このステップではタスクを処理できないと思ったら、「<> with argument give_up_and_restart」というアクションを生成する。
始めよう！
TASK DESCRIPTION:この操作は、ライブのユーザークエリを処理するために使うべきである。覚えておいてほしい：
1. タスクの最後には必ず"<>"を生成すること。最終的な答えはユーザーに提示するのに十分な情報を含んでいなければならない。タスクを処理できない場合、または操作が常に失敗する場合（この機能は現在動作していません）、give_up_and_restartで<>操作を使用してください。
2. 操作と入力だけを生成する。
ユーザー
郵便番号「PL11DN」の住所を教えてください。見つかったアイテムの数、地区、小地区、郡、国、ジオコードの詳細（東方向、北方向、緯度、経度）を知りたいのですが。
開始してください！
ヘルパー
ユーザーのクエリに基づいて、郵便番号「PL11DN」の住所を取得し、見つかったアイテムの数、地区、小地区、郡、国、ジオコードの詳細などの特定の詳細を取得したい。現在のAPIコールは、パラメータ'postcode'を'PL11DN'に設定した関数'find_by_postcode'である。このAPIは、指定された英国の郵便番号に基づく住所を提供できるので便利である。この API を使用することで、ユーザーからのクエリに必要な情報を取得することができます。
ユーザー：
操作を生成する。
ヘルパー
<> を実行する。
ユーザー
入力を与える。これはドキュメントである: {'name': '<>', 'description': '"Find By PostCode" APIは、与えられたイギリスの郵便番号に基づいて住所を取得する。このAPIは、英国の郵便番号で住所を検索するためのJSONインターフェースを提供します。, 'required': [{'name': 'postcode', 'type': 'string', 'description': '', 'default': 'PL11DN'}], 'optional': []}.
ヘルパー：
{
"postcode": "PL11DN"
}
ツール
{error": "", "response": "{'status': 200, 'message': 'Success', 'noOfItems': 37, 'result': {'postcode': 'PL1 1DN', 'district': 'Plymouth', 'district': 'St Peter's and Seafront', 'county': 'Devon', 'country': 'England', 'geocode': {'eastings': '248025', 'northings': '0054420', 'lattitude': '50.370001', 'longitude': '-'.4.138397'}, 'addresses': [{'po_box': '', 'line_2': '', 'postcode_type': 'S', 'line_3': '', 'su_organisation_indicator': '', 'building_number'.'5'、'udprn': '18911184'、'thoroughfare': 'St Andrew's Cross'、'line_1': '5 St Andrew's Cross'、'postcode_outcode': 'PL1'、'postcode_compact': 'PL11DN'、'dependent_'.thoroughfare': '', 'premise': '5', 'post_town': 'Plymouth', 'building_name': '', 'organization_name': '', 'postcode': 'PL1 1DN', 'department_name'.''、'postcode_incode': '1DN'、'address': '5 St Andrew's Cross, Plymouth, PL1 1DN'、'double_dependant_locality': ''、'sub_building_name': ''、'dependent_.locality': '', 'delivery_point_suffix': '4T'}, {'po_box': '', 'line_2': '2 St Andrew's Cross', 'p....
ユーザー
オペレーションを生成します。
ヘルパー
<<終了
ユーザー
入力をお願いします。これはドキュメントです: {'required': [], 'optional': [{'name': 'give_answer', 'description': 'output answer', 'type': 'string'}, {'name': 'give_up_and_restart', 'description': 'このステップのタスクを処理できない', 'type': 'string'}]}.
ヘルパー：
{
"return_type":'give_answer', 'return_type'.
"final_answer": "Number of items found: 37nDistrict: PlymouthnSubdivision: St Peter's and the SeafrontnCounty: DevonnCountry: EnglandnGeocode details: ⅳ- Eastbound: 248025ⅳ Northbound: 0054420ⅳ Latitude: 50.370001ⅳLongitude: -4.138397"
}

![[貼り付け画像 20241027190429.png]]

図8：エンド・ツー・エンドのエージェント・チューニングの例。

AIを始めるための素人ガイド

AIツールの活用方法を、低コスト・ゼロベースから学ぶことができます。AIはオフィスソフトと同様、誰にとっても必須のスキルです。 AIをマスターすれば、就職活動で有利になり、今後の仕事や勉強の労力も半減します。

詳細を見る