LLM 向けの構文エラーのない汎用ツールの使用: ToolDec は構文エラーを排除します

リンク一覧

• 概要と序文
• 関連作業
• ToolDec: 有限状態デコードによる LLM ツールの使用
• 実験: ToolDec が構文エラーを排除
• 実験: ToolDec は汎用的なツール選択を可能にします
• 結論と参考文献
• 付録

4. 実験I: TOOLDECは構文エラーを排除する

このセクションでは、TOOLDEC がツール呼び出しを生成する際に構文エラーを排除できることを示します。コンテキスト内学習と微調整パラダイムを代表する 2 つの最近のベースライン、ToolLLM と ToolkenGPT を選択し、TOOLDEC の能力を紹介します。2 つのベースラインのツール使用設定は異なり、相互に適用できないため、元の論文のベンチマークを使用して、2 つのベースラインに対して TOOLDEC のパフォーマンスを個別にテストします。広範な実験を通じて、TOOLDEC は構文エラーを完全に排除し、精度を向上させ、推論時間を短縮できることを示します。

4.1 ベースラインとベンチマーク

ToolLLM (Qin et al., 2023)。ToolLLMは、ツール拡張言語モデルに対するコンテキスト内学習アプローチです。ツールを使用するために、命令調整された LLaMA-7B モデル (Touvron et al., 2023) を利用します。ツール依存タスクの自然言語命令が与えられると、API リトリーバーは最初に関連する機能の小さなサブセットを取得します。これらの関連する機能のテキスト記述とスキーマは、コンテキストで利用可能になります。次に、ToolLLM は機能を使用して複数段階の推論プロセスを実行し、最終的な答えを生成します。

ToolLLM は、同じ論文で提案されたデータセットである ToolEvalで評価されます。ToolEval には、公開されている REST API の膨大なセット (10,000 以上) を伴うタスクが含まれています。私たちは、ToolEval の最も難しいサブセットである I2-Category と I3-Instruction を使用して、私たちの方法を評価しました。これらには、解決するために複数のカテゴリ (地理位置情報、日付/時刻など) からの複雑で目に見えないツールを必要とするタスクが含まれています。平均して、I2-Category タスクには 6.76 個のツールが必要であり、I3-Category タスクには 8.24 個のツールが必要です。ToolEval には 2 つの主要なメトリクスがあります。合格率は、モデルが一定の推論ステップ数内で回答に到達したタスクの割合を測定します。勝率は、より良いパスを得るために事前定義された一連の基準に従う LLM を搭載した自動評価ツールを利用します。これは、ベースライン回答の品質と正確さを、ChatGPT によって生成された参照回答と比較します。Qin ら。 （2023）は、自動評価ツールと人間の注釈者との相関が75.8％と高いことを発見しました。これら2つの指標の他に、少なくとも1つのツール関連のエラーがあるタスクの割合であるツールエラー率も測定します。

ToolkenGPT (Hao et al., 2023)。ToolkenGPTは、ツールの使用に対する微調整アプローチです。ToolkenGPT は、各ツールを特別なトークンとして表現し、ツールの使用に対するツール トークンの埋め込みのみを最適化します。推論中、ToolkenGPT は、対応する特別なトークンが予測されると、ツールを呼び出します。ツールの呼び出し中は、コンテキスト内のデモンストレーションから学習して引数を渡します。ToolkenGPT は、ベース モデルとして LLaMA-33B (Touvron et al., 2023) を使用します。

4.2 TOOLDECとベースモデルの統合

ToolLLM+TOOLDEC。Qin et al. (2023) に従い、ReAct (Yao et al., 2023) を使用して ToolLLM のツール呼び出しを計画します。これは、セクション 3.2 のモード切り替えの 2 番目のケースに準拠しています。ToolLLM の FSM には 3 つの部分があります。まず、ReAct の「思考、アクション、アクション入力」構文を強制するフォーマット FSM。「アクション:」をデコードした後、この FSM は関数名 FSM の開始状態に遷移し、デコードされた関数名が常に有効であることを保証します。また、JSON ベースの関数引数 FSM も構築しました。LLM が「合格」と見なされるために終了アクションを呼び出す前に、5 ステップの推論を実行できるようにしました。

ToolkenGPT+TOOLDEC。ToolkenGPTはツールを呼び出すために特別なトークンを使用するため、TOOLDEC は引数の構文を保証するためにのみ適用されます。この実験では、FSM はすべての引数が有効な数値であり、引数がカンマで区切られていることを保証します。また、関数に渡される引数の実際の数が、関数に必要な数とまったく同じであることも保証します。TOOLDEC を Hao ら (2023) のベースラインの 2 つのバリアント (バックトレースありとなし) と比較しました。バックトレースは、失敗したツール呼び出しの代わりに、LLM が戻って次の可能性のあるトークンを試行できるようにすることで、失敗したツール呼び出しを回避しようとします。TOOLDEC を評価するために、精度に加えて、問題ごとの平均推論時間とツール エラー率を報告します。

4.3 実験結果

TOOLDEC は、コンテキスト内学習ツール LLM を強化します。表 3 は、ToolEval での TOOLDEC のパフォーマンスを示しています。TOOLDEC は、I2 カテゴリで 55% の勝率、I3 命令で 60% の勝率を達成しました。元のデコード アルゴリズムのドロップイン リプレースメントとして、TOOLDEC は 3 種類のツール関連エラーをすべて排除し、ChatGPT を上回り、最高の勝率と合格率を達成しました。

ベースラインのツール エラー率が高いことは、命令の微調整後でも、ToolLLM にはツール ドキュメントから外部ツールを正確に呼び出す機能がまだ欠けていることを示しています。この能力の欠如は、I3-Instruction のように、利用可能なツールの種類が多い場合に顕著になります。さらに、これらのエラーは、タスクを完了するモデルの能力に大きな影響を与えました。

図 4 に、2 つのベンチマークにおける各エラー タイプのエラー率を示します。ToolLLM の場合、名前エラー (つまり、存在しないツールの呼び出し) が、ツール呼び出しで最も一般的な構文エラーでした。TOOLDEC は、これら 3 つのエラーをすべて完全に排除しました。

関数名の幻覚が最も一般的なツール関連のエラーであるため、サフィックスによるファジー マッチングでそれを軽減する方がわずかに優れたベースラインでした。ファジー マッチングありのベースラインの結果を ToolLLM + ファジー マッチングとして、ファジー マッチングなしのベースラインの結果を ToolLLM として示します。この軽減により合格率は向上しましたが、モデルが必要なツールを正確に呼び出せない場合に間違った API が選択されることが多いため、表 3 で明らかなように勝率にはほとんど影響がありませんでした。全体として、ToolLLM での実験は、TOOLDEC がコンテキスト内学習 LLM で非常に効果的であることを示しています。次のベースラインである ToolkenGPT を通じて、TOOLDEC は微調整されたツール LLM にも有益であることを示します。

TOOLDEC は、ツール LLM の微調整を強化します。表 4 は、FuncQAmulti の結果を示しています。ToolkenGPT は、特別なトークン埋め込みを微調整することで、存在しないツール名を呼び出す可能性を排除しますが、他の構文エラーが発生する可能性があり、これは 27.9% のツール エラー率で示されています。ドロップイン リプレースメントとして、TOOLDEC は ToolkenGPT の精度を向上させながら、推論を大幅に高速化しました。ToolkenGPT + backtrace は TOOLDEC よりもわずかに優れた精度を達成しましたが、さまざまなツールを試すのに 2 倍の時間がかかりました。TOOLDEC はすべてのツール エラーを排除したため、backtrace が再試行する失敗したツール呼び出しはなかったことに注意してください。結果は、ツール関連エラーの関連性と、最近のコンテキスト内学習とツール拡張 LLM の微調整の両方への TOOLDEC の適用性を強調しています。