Utilisation d'outils de syntaxe sans erreur et généralisables pour les LLM : ToolDec permet la sélection d'outils généralisables

Tableau des liens

• Résumé et introduction
• Travaux connexes
• ToolDec : utilisation de l'outil LLM via le décodage à états finis
• Expérience : ToolDec élimine les erreurs de syntaxe
• Expérience : ToolDec permet la sélection d'outils généralisables
• Conclusion et références
• annexe

5. EXPÉRIENCE II : TOOLDEC PERMET UNE SÉLECTION D'OUTILS GÉNÉRALISABLE

Dans l'expérience II, nous montrons comment TOOLDEC se généralise à des outils invisibles sans données de formation supplémentaires ni documentation sur les outils. Nous comparons TOOLDEC avec deux références solides : ToolkenGPT (Hao et al., 2023) en tant qu'approche de réglage fin représentative, et RestGPT (Song et al., 2023) en tant qu'approche représentative d'apprentissage en contexte. Nous avons mené des expériences sur trois benchmarks : FuncQA (Hao et al., 2023) et KAMEL (Kalo & Fichtel, 2022) et RestBench (Song et al., 2023). Ces tests de référence nécessitent divers ensembles d'outils issus de domaines très différents, notamment le raisonnement mathématique, la réponse aux questions de connaissances et les services Web du monde réel. Dans les trois domaines, nos résultats montrent que TOOLDEC est capable de généraliser efficacement à de nouveaux outils sans affiner les données supplémentaires.

5.1 RÉGLAGE FIN DE LA LIGNE DE BASE : TOOLKENGPT

ToolkenGPT est une approche de réglage fin de l'utilisation des outils qui apprend un jeton spécial pour chaque outil. Pour généraliser à de nouveaux outils, ToolkenGPT a encore besoin de données supplémentaires et de réglages supplémentaires impliquant l'utilisation de nouveaux outils. Nous démontrons que TOOLDEC, une fois affiné sur un ensemble donné d'outils vus, n'a pas besoin de données supplémentaires ni d'ajustements supplémentaires pour adopter des outils invisibles. Nous comparons TOOLDEC et les références en les ajustant sur le même sous-ensemble d'outils, appelés « outils vus », puis évaluons leurs performances sur des « outils invisibles ».

Pour garantir une comparaison équitable, nous imitons la méthode de planification de ToolkenGPT pour résoudre le problème du « quand utiliser les outils ». Plus précisément, nous affinons l'intégration d'un seul jeton spécial <T> pour représenter tous les outils, réduisant ainsi la taille du vocabulaire supplémentaire à 1. Une fois <T> généré, un appel d'outil commence.

Nous demandons à LLM de générer un nom d'outil. La génération de ce nom d'outil est guidée par un FSM construit à partir d'une liste de tous les outils disponibles. Ce nom d'outil est ensuite reconnecté au contexte pour démarrer la génération des arguments. Nous montrons un exemple de ce processus à l’Annexe A.2.

Nous avons sélectionné un petit sous-ensemble d'« outils vus » parmi tous les outils disponibles et ajusté l'intégration uniquement avec des démonstrations des outils dans le sous-ensemble sélectionné. Nous avons affiné la ligne de base en utilisant le même sous-ensemble. Ensuite, nous avons évalué notre méthode et les lignes de base sur des tâches impliquant des outils invisibles dans le sous-ensemble pour démontrer la capacité de généralisation de TOOLDEC.

Benchmark sur les fonctions mathématiques. Nous utilisons des questions multi-sauts FuncQA pour évaluer notre méthode. Les outils de FuncQA, tels que permutation, pgcd, puissance, sont des fonctions mathématiques qui limitent strictement leurs arguments aux nombres dans certaines plages. Nous sélectionnons 4 outils sur 13 comme sous-ensemble vu pour ajuster la ligne de base et évaluer différentes approches sur les 9 outils invisibles restants.

Benchmark sur les relations Knowledge Graph. Pour étudier plus en détail la généralisabilité de TOOLDEC sur un ensemble plus large d'outils, nous évaluons également sur KAMEL (Kalo & Fichtel, 2022), un ensemble de données de questions-réponses contenant un total de 234 relations de connaissances qui ressemblent aux caractéristiques des API (par exemple, le nombre d'enfants). D’autres exemples peuvent être trouvés à l’annexe A.4. Les outils de KAMEL sont bien plus nombreux que ceux de FuncQA. Ils sont également plus complexes et diversifiés car le nombre d'arguments de leurs outils varie de 1 à 3 et leurs types incluent des chaînes, des emplacements, des dates, des nombres et d'autres types ad hoc. Nous sélectionnons 30 outils sur 234 comme sous-ensemble vu et évaluons sur 4 ensembles d'évaluation différents, avec respectivement 30, 60, 100 et 234 outils. À la suite de Hao et al. (2023), nous utilisons l'incitation, quelques tirs et zéro tir comme lignes de base supplémentaires. (1) L'invite repose sur les connaissances internes de LLM, puisqu'aucun outil n'a été fourni. (2) Quelques plans démontrent l'utilisation de l'outil à travers des exemples de quelques plans. (3) Zero-shot fournit des descriptions de tous les outils disponibles en contexte. Étant donné que l'ensemble de données de formation et d'évaluation de KAMEL partage le même modèle de questions pour chaque outil, ce qui n'est souvent pas vrai dans des contextes réels, nous comparons TOOLDEC uniquement à ToolkenGPT formé sur l'ensemble de données synthétiques proposé par l'étude originale. Nous utilisons la précision des appels d'outils comme mesure, qui est déterminée par la proportion de réponses qui invoquent la relation de connaissance correcte.

5.2 RÉFÉRENCE D'APPRENTISSAGE EN CONTEXTE : RESTGPT

RestGPT (Song et al., 2023) est une approche d'apprentissage en contexte qui apprend à utiliser les outils à partir de la documentation des outils en contexte. Nous démontrons la capacité de généralisation de RestGPT amélioré par TOOLDEC en montrant que RestGPT avec TOOLDEC peut atteindre une meilleure précision sans documentation contextuelle que la référence RestGPT avec documentation. Étant donné que TOOLDEC a besoin d'accéder à la prochaine distribution de jetons, nous utilisons RestGPT basé sur Vicuna (Zheng et al., 2023) comme référence. Pour notre méthode, nous supprimons toute la documentation de l'outil de l'invite, ne laissant que les instructions de raisonnement.

Benchmark sur les API pour les services Web du monde réel. Nous évaluons sur RestBench (Song et al., 2023). Il consiste en des tâches dans des scénarios réels, notamment TMDB, un site Web d'informations sur les films, et Spotify, un lecteur de musique en ligne. Ces tâches proviennent directement d'instructions d'utilisateurs réels et nécessitent plusieurs outils sous la forme d'API RESTful pour être résolues. Les API RESTful constituent le standard de facto pour les services Web (Li et al., 2016) qui utilisent des méthodes HTTP pour manipuler les ressources. Les solutions de vérité terrain sont annotées par les humains sous la forme de chaînes d’appels d’outils. Nous évaluons notre méthode et la baseline sur TMDB, qui se compose de 55 API RESTful. Étant donné que les méthodes HTTP telles que GET et POST ont un format différent de celui de l'appel à l'outil, le format des arguments de l'outil de TOOLDEC. Nous avons réécrit ces API pour suivre ce format. Nous utilisons le taux de trajet correct (CP%) proposé par l'article original comme mesure pour mesurer la précision. Le taux de chemin correct est la proportion de sorties du modèle qui contiennent le chemin d'appel d'outil correct annoté par des humains.

5.3 RÉSULTATS DE L'EXPÉRIENCE

Généralisation aux fonctions mathématiques invisibles. Dans la figure 5a, nous présentons les résultats sur FuncQA. Alors que ToolkenGPT et TOOLDEC ont atteint des précisions similaires sur des tâches impliquant uniquement des outils visibles, ToolkenGPT n'a pas réussi à se généraliser aux outils invisibles, ce qui a entraîné une baisse significative des performances. D'un autre côté, TOOLDEC a pu maintenir une précision comparable même sur des outils invisibles et atteindre une précision 8 fois supérieure sur les problèmes multi-sauts, soulignant sa généralisabilité. Par conséquent, TOOLDEC a largement surpassé ToolkenGPT en termes de précision totale.

Généralisation aux fonctions invisibles du Knowledge Graph. Nous présentons nos résultats sur KAMEL sur la figure 5b. À mesure que le nombre d’outils disponibles augmentait, les deux méthodes ICL ont souffert de la limite de longueur du contexte (Hao et al., 2023) et ont connu une baisse significative de leur précision. ToolkenGPT, affiné sur les 30 premiers outils, n'a pas non plus pu se généraliser à davantage d'outils. L'invite a conservé une faible précision stable car elle ne reposait pas sur la documentation de l'outil en contexte. D'un autre côté, TOOLDEC a pu maintenir sa précision même lorsque le nombre d'outils invisibles a atteint 204.

Généralisation aux services Web invisibles. Les résultats sur RestBench sont présentés dans le tableau 5. TOOLDEC a permis au modèle d'utiliser des API de service Web sans documentation contextuelle, réduisant ainsi la taille de l'invite de 1 974 jetons à seulement 880 jetons. Néanmoins, TOOLDEC a encore largement surperformé la référence en termes d'exactitude indiquée par le rapport de chemin correct (CP), l'élevant de 8 points. Ces résultats suggèrent que TOOLDEC peut également améliorer la généralisabilité de l'utilisation d'outils d'apprentissage en contexte dans des applications Web réelles.

Les résultats des trois paramètres indiquent que non seulement TOOLDEC aide à affiner la généralisation des outils LLM sans données de formation supplémentaires, mais qu'il aide également les outils d'apprentissage en contexte LLM à se généraliser sans documentation contextuelle. Cette capacité de TOOLDEC a été prouvée dans trois domaines différents.