ToolGen : Recherche et invocation d'outils unifiés par la génération

ToolGen est un cadre permettant d'intégrer la connaissance des outils directement dans les grands modèles de langage (LLM), ce qui permet d'invoquer des outils et de générer des langages de manière transparente en représentant chaque outil comme un jeton unique. Il a été développé par Renxi Wang et al. pour améliorer les performances de la recherche d'outils et de l'accomplissement des tâches.

• La tokenisation des outils : convertir les outils en jetons uniques pour faciliter l'invocation du modèle.
• Génération d'appels d'outils : le modèle est capable de générer des appels d'outils et des paramètres.
• Achèvement des tâches : automatisation des tâches complexes grâce à des appels d'outils.
• Support de données : fournit de riches ensembles de données pour soutenir la formation et l'évaluation des modèles.

résumés

Au fur et à mesure de l'évolution des grands modèles de langage, les limites de leur incapacité à exécuter des tâches de manière autonome en interagissant directement avec des outils externes deviennent particulièrement évidentes. Les approches traditionnelles s'appuient sur l'utilisation des descriptions d'outils en tant que contexte d'entrée, ce qui est limité par la longueur du contexte et nécessite un mécanisme de récupération distinct qui est souvent inefficace. Nous proposons ToolGen, une méthode pour récupérer les descriptions d'outils en représentant chaque outil comme un Jeton un paradigme qui intègre la connaissance des outils directement dans les paramètres du LLM. Cela permet aux LLM d'utiliser les appels d'outils et les paramètres dans le cadre des capacités prédictives de leur prochain jeton, intégrant ainsi de manière transparente les appels d'outils à la génération de langage. Notre cadre permet aux LLM d'accéder à un grand nombre d'outils et de les utiliser sans étapes de recherche supplémentaires, ce qui améliore considérablement les performances et l'évolutivité. Les résultats expérimentaux basés sur plus de 47 000 outils montrent que ToolGen obtient non seulement des résultats supérieurs dans la recherche d'outils et la réalisation autonome de tâches, mais pose également les bases d'une nouvelle génération d'agents d'intelligence artificielle capables de s'adapter à une large gamme d'outils de domaine. En transformant fondamentalement la recherche d'outils en un processus génératif, ToolGen ouvre la voie à des systèmes d'IA plus flexibles, plus efficaces et plus autonomes. ToolGen étend l'utilité de LLM en prenant en charge l'apprentissage d'outils de bout en bout et en offrant des possibilités d'intégration avec d'autres technologies avancées telles que la pensée en chaîne et l'apprentissage par renforcement.

1 Introduction

Les grands modèles de langage (LLM) ont démontré des capacités impressionnantes dans le traitement des entrées externes, l'exécution d'opérations et la réalisation autonome de tâches (Gravitas, 2023 ; Qin et al. 2023 ; Yao et al. 2023 ; Shinn et al. 2023 ; Wu et al. 2024a ; Liu et al. 2024). Parmi les différentes approches permettant aux LLM d'interagir avec le monde extérieur, les appels d'outils via des API sont devenus l'une des plus courantes et des plus efficaces. Cependant, comme le nombre d'outils augmente jusqu'à des dizaines de milliers, les méthodes existantes de recherche et d'exécution d'outils sont difficiles à mettre à l'échelle de manière efficace.

Dans les scénarios du monde réel, une approche courante consiste à combiner l'extraction d'outils avec l'exécution d'outils, où le modèle d'extraction filtre d'abord les outils pertinents avant de les transmettre au LLM pour la sélection finale et l'exécution (Qin et al., 2023 ; Patil et al., 2023). Bien que cette approche combinée soit utile lorsqu'il s'agit d'un grand nombre d'outils, elle présente des limites évidentes : les modèles de recherche s'appuient souvent sur de petits encodeurs qui rendent difficile la capture complète de la sémantique d'outils et de requêtes complexes, tandis que la séparation de la recherche et de l'exécution peut conduire à des inefficacités et à des biais d'étape dans le processus d'achèvement des tâches.

En outre, les LLM et leurs désambiguiseurs sont préformés principalement sur des données de langage naturel (Brown et al., 2020 ; Touvron et al., 2023), et ont une connaissance intrinsèque limitée de la fonctionnalité liée à l'outil de leur propre chef. Ce manque de connaissances conduit à une performance médiocre, en particulier lorsque les LLM doivent s'appuyer sur des descriptions d'outils récupérées pour prendre des décisions.

Dans cette étude, nous présentons ToolGen, un nouveau cadre qui intègre la connaissance des outils du monde réel directement dans les paramètres LLM et transforme la recherche et l'exécution d'outils en une tâche de génération unifiée. Plus précisément, ToolGen utilise plus efficacement les connaissances préexistantes de LLM pour la recherche et l'invocation d'outils en étendant le vocabulaire LLM pour représenter les outils en tant que tokens virtuels spécifiques et en entraînant le modèle à générer ces tokens dans le contexte du dialogue.

En se basant sur le LLM pré-entraîné, le processus de formation de ToolGen se compose de trois phases : la mémoire des outils, la formation à la récupération et la formation des agents. Au cours de la phase de mémorisation des outils, le modèle associe chaque jeton d'outil virtuel à son document. Enfin, dans le cadre de l'apprentissage de l'agent de bout en bout, le modèle est entraîné à agir comme un agent autonome, en générant des plans et des outils et en déterminant les paramètres appropriés pour mener à bien la tâche. En invoquant des outils et en obtenant un retour d'information de l'environnement externe, le modèle peut traiter efficacement et de manière intégrée les requêtes des utilisateurs. La figure 1 montre comment ToolGen se compare au paradigme traditionnel.

Nous validons la supériorité de ToolGen dans deux scénarios : une tâche de recherche d'outils où le modèle récupère le bon outil pour une requête donnée, et une tâche d'agent basée sur LLM où le modèle accomplit des tâches complexes impliquant des appels d'API réels. En utilisant un ensemble de données de 47 000 outils du monde réel, ToolGen est aussi performant que les principales méthodes de recherche d'outils, mais à un coût nettement inférieur et avec une plus grande efficacité. En outre, il va au-delà du paradigme traditionnel d'apprentissage des outils, soulignant son potentiel pour faire progresser les systèmes d'utilisation d'outils plus efficaces.

Figure 1 : Comparaison de ToolGen avec les approches précédentes basées sur la recherche d'outils. Les approches précédentes utilisent des extracteurs pour récupérer les outils pertinents au moyen d'une correspondance de similarité, puis placent ces outils dans les invites LLM pour la sélection. ToolGen permet la récupération d'outils en générant directement un jeton d'outil, et peut accomplir la tâche sans s'appuyer sur des extracteurs externes.

ToolGen représente un nouveau paradigme pour l'interaction avec les outils, en fusionnant la recherche et la génération dans un modèle unifié. Cette innovation jette les bases d'une nouvelle génération d'agents d'intelligence artificielle capables de s'adapter à une grande variété d'outils. En outre, ToolGen crée de nouvelles opportunités pour combiner des techniques avancées telles que le raisonnement en chaîne et l'apprentissage par renforcement avec une approche générative unifiée pour l'utilisation d'outils, étendant les capacités des grands modèles de langage dans les applications du monde réel.

En résumé, nos contributions comprennent

• Un nouveau cadre, ToolGen, est proposé pour intégrer la recherche et l'exécution d'outils dans le processus de génération de grands modèles linguistiques par le biais de jetons virtuels.
• Un processus de formation en trois phases a été conçu pour rendre ToolGen efficace et évolutif pour la recherche d'outils et les appels API.
• La validation expérimentale montre que ToolGen présente des performances comparables à celles des meilleures méthodes de recherche d'outils disponibles dans les référentiels d'outils à grande échelle, mais à un coût moindre, de manière plus efficace et au-delà du paradigme traditionnel d'apprentissage des outils.

2 Travaux connexes

2.1 Recherche d'outils

La recherche d'outils est cruciale dans l'exécution des tâches pratiques des grands agents de modèles de langage, où les outils sont généralement décrits par leurs documents. Les approches traditionnelles telles que la recherche éparse (par ex. BM25 (Robertson et al., 2009)) et la recherche intensive (par exemple DPR (Karpukhin et al., 2020), ANCE (Xiong et al., 2021)) reposent sur de grands index de documents et des modules externes, ce qui entraîne des inefficacités et des difficultés d'optimisation dans un cadre d'agent de bout en bout. Plusieurs études ont exploré d'autres approches. Par exemple, Chen et al. (2024b) réécrivent la requête et extraient son intention dans un cadre de recherche non supervisée, bien que les résultats ne soient pas aussi bons que les méthodes supervisées. Xu et al. (2024) proposent une approche qui améliore la précision de la recherche mais augmente la latence en optimisant itérativement la requête en fonction du retour d'information de l'outil.

Récemment, la recherche générative est apparue comme un nouveau paradigme prometteur où les modèles génèrent directement des identifiants de documents pertinents plutôt que de s'appuyer sur des mécanismes de recherche traditionnels (Wang et al., 2022 ; Sun et al., 2023 ; Kishore et al., 2023 ; Mehta et al., 2023 ; Chen et al., 2023b). Inspiré par cela, ToolGen représente chaque outil comme un jeton unique de sorte que la recherche et l'invocation d'outils peuvent être traitées comme des tâches génératives. En plus de simplifier la recherche, cette conception peut être utilisée en conjonction avec d'autres grands modèles de langage et des fonctions d'agent basées sur les grands modèles de langage, telles que le raisonnement par pensée enchaînée (Wei et al., 2023) et les fonctions de l'agent basé sur les grands modèles de langage, telles que les fonctions de l'agent basé sur les grands modèles de langage. ReAct (Yao et al., 2023)) est intégré en douceur. L'intégration de la recherche et de l'exécution des tâches dans un seul grand agent de modèle linguistique permet de réduire la latence et les frais généraux de calcul et d'améliorer l'efficacité et l'efficience de l'exécution des tâches.

2.2 Agents à modèle linguistique étendu avec appels d'outils

Les grands modèles de langage présentent un fort potentiel pour la maîtrise des outils nécessaires à diverses tâches. Cependant, la plupart des recherches existantes se sont concentrées sur un ensemble limité d'actions (Chen et al., 2023a ; Zeng et al., 2023 ; Yin et al., 2024 ; Wang et al., 2024). Par exemple, Toolformer (Schick et al., 2023) affine GPT-J pour gérer seulement cinq outils (par exemple, des calculatrices). ToolBench (Qin et al., 2023) étend l'étude en introduisant plus de 16 000 outils, soulignant les défis de la sélection d'outils dans des environnements complexes.

Pour effectuer la sélection des outils, les approches actuelles utilisent généralement un pipeline de récupération-génération, dans lequel le grand modèle de langage récupère d'abord l'outil pertinent et l'exploite ensuite (Patil et al., 2023 ; Qin et al., 2023). Cependant, l'approche par pipeline est confrontée à deux problèmes principaux : le dépassement de l'étape de récupération et la difficulté pour les grands modèles de langage de comprendre et d'utiliser pleinement les outils à l'aide de simples messages-guides.

Pour pallier ces problèmes, les chercheurs ont tenté de représenter les actions sous forme de tokens et de transformer la prédiction d'actions en tâches génératives. Par exemple, RT2 (Brohan et al., 2023) génère des tokens représentant les actions des robots, et Self-RAG (Asai et al., 2023) utilise des tokens spéciaux pour décider quand récupérer un document.ToolkenGPT (Hao et al., 2023) introduit des tokens spécifiques aux outils pour déclencher l'outil à utiliser, un concept qui se rapproche le plus de notre approche. Ce concept est le plus proche de notre approche.

Notre approche diffère considérablement de celle de ToolkenGPT. Tout d'abord, nous nous concentrons sur des outils réels qui nécessitent des paramètres flexibles pour des tâches complexes (par exemple, la recherche de chaînes sur YouTube), alors que ToolkenGPT se limite à des outils plus simples avec moins d'entrées (par exemple, des fonctions mathématiques avec deux nombres). En outre, ToolkenGPT s'appuie sur moins d'indices d'échantillons, alors que ToolGen intègre la connaissance des outils directement dans le modèle de langage plus large par le biais d'un réglage fin des paramètres, ce qui lui permet de récupérer et d'effectuer des tâches de manière autonome. Enfin, nos expériences portent sur un ensemble d'outils beaucoup plus important - 47 000 outils, contre 13-300 pour ToolkenGPT.

D'autres études, comme ToolPlanner (Wu et al., 2024b) et AutoACT (Qiao et al., 2024), ont utilisé l'apprentissage par renforcement ou des systèmes multi-agents pour améliorer l'apprentissage des outils ou la réalisation des tâches (Qiao et al., 2024 ; Liu et al., 2023 ; Shen et al., 2024 ; Chen et al., 2024a). Nous ne comparons pas ces approches à notre modèle pour deux raisons :(1) la plupart de ces efforts s'appuient sur des mécanismes de rétroaction tels que Réflexion (Shinn et al., 2023) ou des modèles de récompense, qui sont similaires à la conception de l'évaluation de ToolBench où le grand modèle de langage agit comme un évaluateur et n'a pas accès aux réponses réelles. Cependant, ce n'est pas l'objet de notre étude, et nos expériences de bout en bout ne reposent pas sur de tels mécanismes de rétroaction. (2) Notre approche n'entre pas en conflit avec ces méthodes, mais peut au contraire être intégrée. L'exploration d'une telle intégration est laissée à la recherche future.

3 ToolGen

Dans cette section, nous présentons d'abord la représentation symbolique utilisée dans le document. Ensuite, nous décrivons en détail l'approche spécifique de ToolGen, y compris la virtualisation des outils, la mémoire des outils, l'entraînement à la récupération et le réglage de bout en bout de l'agent, comme le montre la figure 2. Enfin, nous présentons notre méthodologie d'inférence.

Figure 2 : Schéma du cadre de ToolGen. Dans la phase de virtualisation des outils, les outils sont mis en correspondance avec des jetons virtuels, et dans les trois phases de formation suivantes, ToolGen se souvient d'abord des outils en prédisant les jetons d'outils à partir des documents d'outils. Ensuite, ToolGen apprend à récupérer les outils en prédisant les jetons d'outils à partir des requêtes. Enfin, les données relatives au pipeline (c'est-à-dire les trajectoires) sont utilisées pour affiner le modèle de recherche lors de la dernière étape, qui génère le modèle de l'agent ToolGen.

3.1 Connaissances préparatoires

Pour une requête d'utilisateur donnée q, l'objectif de l'apprentissage d'outils est de résoudre q en utilisant des outils d'un grand ensemble d'outils D={d1,d2,...,dN}, où |D|=N est un grand nombre, ce qui rend peu pratique l'inclusion de tous les outils dans D dans un environnement de modélisation du langage de grande taille. Par conséquent, la recherche actuelle utilise généralement un extracteur R pour extraire k outils pertinents de D, désigné par Dk,R={dr1,dr2,...,drk}=R(q,k,D), où |Dk,R|≪N. Le prompteur final est une concaténation de q et de Dk,R, désigné par Prompt=[q,Dk,R]. Pour réaliser une tâche (requête), les agents basés sur de grands modèles de langage utilisent généralement une itération en quatre étapes (Qu et al., 2024 ) : génération d'un plan pi , sélection d'un outil dsi , détermination des paramètres de l'outil ci , et collecte d'informations à partir du retour d'information de l'outil fi . Nous désignons ces étapes par pi,dsi,ci,fi pour la i-ième itération. Le modèle continue d'itérer à travers ces étapes jusqu'à ce que la tâche soit terminée, moment auquel la réponse finale a est générée. La trajectoire entière peut être représentée comme Traj=[Prompt,(p1,ds1,c1,f1),...,(pt,dst,ct,ft),a]=[q,R (q,D),(p1,ds1,c1,f1),...,(pt,dst,ct,ft),a]. Cette approche itérative permet au modèle d'ajuster et d'affiner dynamiquement ses opérations à chaque étape sur la base du retour d'information reçu, améliorant ainsi ses performances dans l'accomplissement de tâches complexes.

3.2 Virtualisation des outils

Dans ToolGen, nous mettons en œuvre la virtualisation des outils en associant chaque outil à un nouveau token unique par le biais d'une approche appelée indexation atomique. Dans cette approche, un jeton unique est attribué à chaque outil en étendant le vocabulaire d'un grand modèle de langage. L'intégration de chaque jeton d'outil est initialisée à l'intégration moyenne du nom de l'outil correspondant, fournissant ainsi un point de départ sémantiquement significatif pour chaque outil.

Formellement, un ensemble de tokens est défini comme T = Index(d)|∀d ∈ D, où Index est une fonction qui associe des outils à des tokens. Nous montrons que l'indexation atomique est plus efficace et réduit les phénomènes fantômes par rapport à d'autres méthodes d'indexation (par exemple, les mappings sémantiques et numériques ; voir 4.3 et 5.4 pour la discussion).

3.3 Mémoire des outils

Après l'attribution d'un token à un outil, le grand modèle linguistique ne dispose toujours pas de connaissances sur l'outil. Pour résoudre ce problème, nous affinons la description de l'outil en l'utilisant comme entrée et en utilisant le token correspondant comme sortie, ce processus étant appelé mémoire de l'outil. Nous utilisons la fonction de perte suivante :

où θ désigne les paramètres du grand modèle linguistique et ddoc désigne la description de l'outil. Cette étape fournit les bases de l'outil et des opérations connexes pour le grand modèle de langue.

3.4 Formation à la recherche

Nous entraînons ensuite le grand modèle linguistique à associer l'espace caché du token d'outil virtuel (et de ses documents) à l'espace des requêtes de l'utilisateur, de sorte que le modèle puisse générer l'outil correct en fonction de la requête de l'utilisateur. À cette fin, nous affinons le grand modèle linguistique en prenant les requêtes de l'utilisateur en entrée et l'outil Token correspondant en sortie :

où θ′ représente le paramètre du modèle du grand langage après la mémoire de l'outil, Q est l'ensemble des requêtes de l'utilisateur et Dq est l'ensemble des outils associés à chaque requête. Ce processus génère le récupérateur ToolGen, ce qui lui permet de générer le jeton d'outil approprié pour une requête d'utilisateur donnée.

3.5 Mise au point de l'agent de bout en bout

Après l'entraînement à la recherche, le modèle Big Language est capable de générer un jeton d'outil à partir de la requête. Dans l'étape finale, nous utilisons des tâches Agent-Flan pour compléter le modèle de réglage fin de la trajectoire. Nous adoptons une stratégie d'inférence de type Agent-Flan (Chen et al., 2024c), où notre pipeline utilise un processus itératif, où le modèle génère d'abord la Pensée, puis génère le jeton d'action correspondant, qui est utilisé pour récupérer le document de l'outil, qui est ensuite utilisé par le modèle de grand langage pour générer les paramètres nécessaires. Le processus est itératif jusqu'à ce que le modèle génère un jeton "terminé" ou atteigne le nombre maximal de tours. La trajectoire générée est représentée par Traj=[q,(p1,Index(ds1),c1,f1),...,(pt,Index(dst),ct,ft),a]. Dans cette structure, l'outil d'association n'est plus nécessaire.

3.6 Raisonnement

Au cours du processus de raisonnement, un grand modèle de langage peut générer des jetons d'action au-delà de l'ensemble prédéfini de jetons d'outils. Pour éviter cela, nous concevons une méthode de génération de recherche de bundle contraint pour limiter le jeton de sortie à l'ensemble de jetons d'outils. Nous appliquons cette méthode à la recherche d'outils (où le modèle est basé sur un outil de sélection de requêtes) et aux systèmes d'agents de bout en bout, ce qui permet de réduire efficacement les illusions lors de l'étape de génération d'actions. Voir 5.4 pour une analyse détaillée. Voir l'annexe C pour les détails de la mise en œuvre.

4 Évaluation de la récupération des outils

4.1 Dispositif expérimental

Nous utilisons le modèle pré-entraîné Llama-3-8B (Dubey et al., 2024) comme modèle de base avec un vocabulaire de 128 256. 46 985 tokens ont été ajoutés pendant la virtualisation de l'outil par la méthode d'indexation atomique, ce qui donne un vocabulaire final de 175 241. nous avons affiné le modèle en utilisant le modèle de chat Llama-3 avec un planificateur de taux d'apprentissage cosinus et en appliquant une étape d'échauffement de 3%. nous avons utilisé le modèle de chat Llama-3 avec un planificateur de taux d'apprentissage cosinus. et en appliquant une étape d'échauffement de 3%. Le taux d'apprentissage maximal était de 4 × 10-5. Tous les modèles ont été passés par Deepspeed ZeRO 3 sur 4 × A100 GPU (Rajbhandari et al.2020). Huit cycles de formation à la mémoire des outils et un cycle de formation à la récupération ont été menés.

ensemble de données

Nos expériences sont basées sur ToolBench, un benchmark d'outils du monde réel contenant plus de 16 000 collections d'outils, chacune contenant plusieurs API, pour un total d'environ 47 000 API uniques. Chaque API est documentée à l'aide d'un dictionnaire contenant le nom de l'API, la description et les paramètres d'appel. Voir l'annexe pour un exemple concret ANous traitons chaque API comme une opération et l'associons à un jeton. Nous traitons chaque API comme une opération et l'associons à un jeton. Nos données d'extraction et de réglage de bout en bout de l'agent sont converties à partir des données brutes de ToolBench. Voir l'annexe pour plus d'informations G. Bien que chaque outil puisse contenir plusieurs API, par souci de simplicité, le présent document fait référence à chaque API collectivement en tant qu'outil.

Nous avons suivi la méthodologie de partitionnement des données de Qin et al. (2023) et classé les 200 000 paires (requêtes, API associées) en trois catégories : I1 (requêtes à outil unique), I2 (requêtes à outils multiples au sein des classes) et I3 (commandes à outils multiples au sein des collections), contenant respectivement 87 413, 84 815 et 25 251 instances.

Méthodologie de référence

Nous comparons ToolGen aux critères suivants :

• BM25 : Une méthode classique de recherche non supervisée basée sur TF-IDF et sur la similarité des mots entre la requête et le document.
• Similitude d'intégration (EmbSim) : intégration de phrases générée à l'aide du modèle d'intégration de phrases de l'OpenAI ; en particulier text-embedding-3-large utilisé dans nos expériences.
• Re-Invoke (Chen et al., 2024b) : une méthode de recherche non supervisée intégrant la réécriture des requêtes et l'expansion des documents.
• IterFeedback (Xu et al., 2024) : un récupérateur basé sur BERT qui utilise gpt-3.5-turbo-0125 comme modèle de rétroaction pour jusqu'à 10 tours de rétroaction itérative.
• ToolRetriever (Qin et al., 2023) : un récupérateur basé sur BERT entraîné par apprentissage par contraste.

mettre en place

Nous menons des expériences dans deux contextes. Dans le premier cas, la recherche dans le domaine restreint la recherche d'outils dont l'espace de recherche se situe dans le même domaine. Par exemple, lors de l'évaluation des requêtes dans le domaine I1, la recherche est limitée aux outils du domaine I1. Ce paramètre est cohérent avec le paramètre ToolBench. Le deuxième paramètre, la recherche multi-domaine, est plus complexe, l'espace de recherche étant étendu aux outils des trois types de domaines. Dans ce cas, le modèle est entraîné sur des données fusionnées, ce qui augmente l'espace de recherche et la complexité de la tâche. Contrairement à ToolBench, le cadre multi-domaines reflète des scénarios réalistes dans lesquels les tâches de recherche peuvent impliquer des domaines qui se chevauchent ou qui sont mixtes. Ce cadre permet d'évaluer la capacité du modèle à se généraliser entre les domaines et à gérer des tâches de recherche plus complexes et plus diversifiées.

norme

Nous avons évalué les performances de recherche à l'aide de l'indicateur NDCG (Normalised Discount Cumulative Gain) (Järvelin & Kekäläinen, 2002), une mesure largement utilisée dans les tâches de classement, y compris la recherche d'outils.

Tableau 1 : Évaluation de la récupération d'outils dans deux contextes : (1) récupération intra-domaine, où les modèles sont formés et évalués sur les mêmes domaines, et (2) récupération multi-domaine, où les modèles sont formés sur tous les domaines et évalués sur l'ensemble des outils de tous les domaines.BM25, EmbSim, et Re-Invoke sont des méthodes d'évaluation non formées et non supervisées.IterFeedback est un système de récupération avec plusieurs modèles et mécanismes de rétroaction.ToolRetriever est formé à l'aide de l'apprentissage par contraste, tandis que ToolGen est formé à l'aide de la prédiction du prochain jeton. ToolRetriever est entraîné à l'aide de l'apprentissage par contraste, tandis que ToolGen est entraîné à l'aide de la prédiction du prochain jeton. Les éléments marqués d'un * dans les résultats indiquent des modèles que nous n'avons pas mis en œuvre, et les données proviennent de l'article original et ne sont donc répertoriées que dans le cadre du domaine. Pour ToolGen dans l'environnement in-domain, nous permettons à l'espace de génération d'inclure tous les tokens, ce qui est un scénario plus difficile que pour les autres modèles. Les meilleurs résultats dans chaque catégorie sont indiqués en gras.

4.2 Résultats

Le tableau 1 montre les résultats de la recherche d'outils. Comme prévu, tous les modèles entraînés sont nettement plus performants que les modèles de référence non entraînés (BM25, EmbSim et Re-Invoke) pour toutes les mesures, ce qui montre les avantages de l'entraînement sur les données de recherche d'outils.

Le modèle ToolGen que nous proposons obtient systématiquement les meilleurs résultats dans les deux contextes. Dans le cadre du domaine, ToolGen fournit des résultats très compétitifs, avec des performances comparables à celles du système IterFeedback utilisant plusieurs modèles et mécanismes de retour d'information. En tant que modèle unique, ToolGen est nettement plus performant que ToolRetriever pour toutes les mesures et surpasse même IterFeedback dans plusieurs scénarios (par exemple, NDCG@5 pour le domaine I1 et NDCG@1, @3, @5 pour I2).

Dans le cadre multidomaine, ToolGen reste robuste, surpassant ToolRetriever et restant devant les modèles de base, malgré l'espace de recherche plus grand et la baisse habituelle de la performance globale. Cela montre que ToolGen, bien qu'il s'agisse d'un modèle unique, peut encore rivaliser avec des systèmes de recherche complexes comme IterFeedback, démontrant ainsi sa capacité à gérer des tâches de recherche complexes dans le monde réel avec des limites de domaine floues.

4.3 Comparaison des méthodes d'indexation

Alors que ToolGen utilise des index atomiques pour la virtualisation des outils, nous explorons également plusieurs méthodes alternatives de recherche générative. Dans cette section, nous les comparons aux trois approches suivantes :

• Numérique : chaque outil est associé à un numéro unique. Le jeton généré est purement numérique et ne fournit aucune information sémantique intrinsèque, mais un identifiant unique pour chaque outil.
• Hiérarchique : cette méthode regroupe les outils en groupes qui ne se chevauchent pas et divise récursivement ces groupes pour former une structure hiérarchique. Un index allant du nœud racine aux nœuds feuilles de cette structure représente chaque outil, à l'instar de la technique de regroupement de Brown.
• Sémantique : dans cette approche, chaque outil est associé à son nom, ce qui guide le grand modèle linguistique (LLM) à travers le contenu sémantique du nom de l'outil. Le nom de l'outil fournit directement une représentation significative de sa fonction.

Figure 3 : La distribution du nombre de sous-tokens par outil diffère selon la méthode d'indexation. L'indexation atomique garantit que chaque outil est un token unique, tandis que l'indexation numérique code les outils en N tokens, c'est-à-dire que le nombre d'outils se situe dans l'intervalle (10N-1,10N). En revanche, l'indexation sémantique et l'indexation hiérarchique produisent des nombres variables de sous-tokens, l'indexation sémantique présentant une séquence plus longue de sous-tokens et davantage de valeurs aberrantes.

Les détails de la mise en œuvre sont décrits à l'annexe B.

Tout d'abord, nous avons analysé le nombre de sous-tokens requis par chaque méthode pour représenter chaque outil, comme le montre la figure 3. Le graphique met en évidence la supériorité de l'indexation atomique, où chaque outil est représenté par un seul token, alors que les autres méthodes nécessitent plusieurs tokens. Cette efficacité permet à ToolGen de réduire le nombre de génération de tokens et de raccourcir le temps de raisonnement dans les scénarios de recherche et d'agent.

Ensuite, nous avons examiné l'efficacité des différentes méthodes d'indexation. Comme le montre le tableau 2, l'indexation sémantique présente les meilleures performances de recherche pour un certain nombre de mesures et de scénarios, tandis que l'indexation atomique arrive juste derrière dans de nombreux cas. Nous attribuons ce résultat au fait que l'indexation sémantique correspond mieux aux données pré-entraînées du grand modèle linguistique. Toutefois, cet avantage diminue à mesure que les données d'entraînement et les types augmentent. Par exemple, à la section 5.3, nous montrons que les index atomiques sont plus performants pour les résultats de bout en bout. En tenant compte de ces facteurs, nous choisissons les index atomiques pour la virtualisation des outils de ToolGen.

Tableau 2 : Évaluation de la récupération de différentes méthodes d'indexation dans un contexte multidomaine. Les meilleurs résultats sont en gras et les deuxièmes meilleurs résultats sont soulignés.

Tableau 3 : Études d'ablation pour la récupération d'outils. Les effets de la suppression de la formation à la récupération, de la mémoire des outils et de la recherche de faisceaux contraints sur les performances de ToolGen sont évalués séparément.

4.4 Expériences d'ablation

Nous avons mené des expériences d'ablation pour évaluer les effets des différentes phases d'entraînement de ToolGen, comme le montre le tableau ci-dessous. 3 Illustration. Les résultats montrent que l'entraînement à la récupération est un facteur clé affectant les performances de la récupération d'outils, car il aligne directement la tâche de récupération où l'entrée est une requête et la sortie un jeton d'outil. La suppression des mémoires d'outils entraîne une légère dégradation des performances, bien qu'elle contribue à améliorer les performances de généralisation, comme nous le montrerons dans l'annexe. F Nous y reviendrons plus en détail. De même, la recherche restreinte de paquets, tout en contribuant peu à la tâche de recherche, aide à prévenir la génération d'hallucinations et a donc une certaine valeur dans les tâches d'agent de bout en bout, voir la section 5.4.

5 Évaluation de bout en bout

5.1 Dispositif expérimental

Nous avons apporté plusieurs modifications aux données de trace de ToolBench pour les adapter au cadre de ToolGen. Par exemple, comme ToolGen n'exige pas la sélection explicite d'outils pertinents en entrée, nous avons supprimé cette information des invites du système. Pour plus de détails, voir l'annexe G. Sur cette base, nous avons affiné le modèle de recherche en utilisant les données reformatées pour générer un agent ToolGen de bout en bout.

modèle de base

• GPT-3.5 : Nous utilisons gpt-3.5-turbo-0613 comme l'un des modèles de référence. L'implémentation est la même que celle de StableToolBench (Guo et al., 2024), où la fonctionnalité d'appel d'outils de GPT-3.5 est utilisée pour former des agents outils.
• ToolLlama-2 : Qin et al. (2023) ont présenté ToolLlama-2 en affinant le modèle Llama-2 (Touvron et al., 2023) sur les données de ToolBench.
• ToolLlama-3 : Pour garantir une comparaison équitable, nous avons créé le modèle de base ToolLlama-3 en affinant le même modèle de base Llama-3 que ToolGen sur l'ensemble de données ToolBench. Dans la suite du document, ToolLlama-3 est appelé ToolLlama pour le distinguer de ToolLlama-2.

mettre en place

• Utilisation d'outils authentiques (G.T.) : en référence à Qin et al. (2023), nous définissons les outils authentiques pour les requêtes comme suit ChatGPT Outil sélectionné. Pour ToolLlama, nous avons saisi l'outil réel directement dans l'invite, dans le même format que ses données d'entraînement. Pour ToolGen, comme il n'a pas été entraîné sur des données avec des outils présélectionnés, nous avons ajouté le préfixe : J'utilise l'outil suivant dans la phase de planification : [outil jetons], où [jetons outils] est le jeton virtuel correspondant à l'outil réel.
• Utilisation de récupérateurs : dans les expériences de bout en bout, nous utilisons une configuration basée sur la récupération. Pour le modèle de base, nous utilisons les outils récupérés par ToolRetriever comme outils associés. ToolGen, quant à lui, génère directement des jetons d'outils et n'utilise donc pas de récupérateur.

Tous les modèles ont été affinés à l'aide d'un planificateur en cosinus, le taux d'apprentissage maximal étant fixé à 4 × 10-5. La longueur du contexte a été tronquée à 6 144 et la taille totale du lot à 512. Nous avons également utilisé Flash-Attention (Dao et al., 2022 ; Dao, 2024) et Deepspeed ZeRO 3 ( Rajbhandari et al., 2020) pour économiser de la mémoire.

ToolGen et ToolLlama suivent des paradigmes différents pour accomplir la tâche ; ToolLlama génère des idées, des actions et des paramètres en un seul tour, tandis que ToolGen sépare ces étapes. Pour ToolGen, nous avons fixé un plafond de 16 tours, permettant 5 tours d'actions et 1 tour de réponses finales. Nous comparons cette limite à celle de ToolLlama, qui est de 6 tours.

En outre, nous avons introduit un mécanisme de relance pour tous les modèles afin d'éviter une interruption prématurée, dont les détails sont décrits à l'annexe D. Plus précisément, si un modèle génère une réponse qui contient "abandonner" ou "je suis désolé", nous invitons le modèle à régénérer la réponse à une température plus élevée.

Évaluation des indicateurs

Pour l'évaluation de bout en bout, nous utilisons le benchmark d'évaluation d'outils stables StableToolBench (Guo et al., 2024), qui sélectionne des requêtes résolues dans ToolBench et simule la sortie d'outils ayant échoué en utilisant GPT-4 (OpenAI, 2024). Nous évaluons la performance à l'aide de deux mesures : le taux de réussite solvable (SoPR), qui est le pourcentage de requêtes résolues avec succès, et le taux de victoire solvable (SoWR), qui indique le pourcentage de réponses qui surpassent le modèle de référence (GPT-3.5 dans cette étude). En outre, nous fournissons les scores micro-moyens pour chaque catégorie.

Tableau 4 : Performances de l'évaluation de bout en bout de commandes inédites dans deux contextes. Pour le paramètre R., GPT-3.5 et ToolLlama utilisent ToolRetriever, tandis que ToolGen n'utilise pas de récupérateur externe. Toutes les évaluations SoPR et SoWR résultantes sont effectuées trois fois et présentées sous forme de valeurs moyennes.

5.2 Résultats

Le tableau 4 montre la performance de l'évaluation de bout en bout de chaque modèle dans deux environnements : en utilisant l'outil réel (G.T.) et le récupérateur (R.). Dans l'environnement G.T., ToolGen obtient un score SoPR moyen de 54,19, surpassant GPT-3.5 et ToolLlama, et ToolGen obtient le score SoWR le plus élevé de 49,70. ToolGen conserve la première place dans l'environnement Retriever, avec un SoPR moyen de 53,28 et un SoWR de 51,51. ToolLlama montre une performance compétitive, surpassant l'outil réel sur certaines instances individuelles. ToolLlama a démontré sa compétitivité, surpassant ToolGen sur certaines instances individuelles. Une étude d'ablation ToolGen de bout en bout est présentée à l'annexe G.

Tableau 5 : Évaluation de bout en bout de différentes méthodes d'indexation.

5.3 Comparaison des méthodes d'indexation

Comme pour la comparaison des méthodes d'indexation pour la tâche de recherche (section 4.3), le tableau 5 montre une comparaison des différentes méthodes d'indexation dans la tâche de l'agent de bout en bout. Dans cette configuration, le décodage restreint est supprimé, ce qui permet à l'agent de générer librement des pensées, des actions et des paramètres. Nous attribuons ce résultat aux taux de fantômes plus élevés des autres méthodes, comme nous l'avons vu à la section 5.4.

Figure 4 : montre le taux de fantômes de différents modèles lors de la génération d'outils inexistants. ToolGen ne génère pas d'outils inexistants lorsqu'il utilise un décodage restreint. Cependant, sans cette restriction, ToolGen génère 7% tokens non outils dans la phase de génération d'action lors de l'utilisation de l'indexation atomique, et le taux d'illusion est plus élevé lors de l'utilisation de l'indexation sémantique. Pour ToolLlama et GPT-3.5, l'illusion se produit même si cinq outils réels sont fournis dans l'indice. Si aucun outil n'est spécifié dans l'indice, ToolLlama génère des noms d'outils inexistants dépassant 50%.

5.4 Hallucinations

Nous évaluons la situation fantôme du modèle dans la génération d'outils dans un scénario d'agent de bout en bout. Pour ce faire, nous saisissons des requêtes dont le format est conforme à la formation du modèle. En particulier, pour ToolGen, nous entrons directement la requête et demandons au modèle de générer la réponse selon le paradigme de l'agent ToolGen (c.-à-d., pensée, outil et paramètres dans l'ordre). Nous avons testé le décodage d'action sans les restrictions de recherche de paquets décrites dans la section 3.6. Pour ToolLlama et GPT-3.5, nous avons saisi des requêtes et inclus 5 outils réels. Dans tous les cas, nous indiquons la proportion d'outils non présents dans l'ensemble de données parmi ceux générés dans toutes les actions de génération d'outils. La figure 4 illustre le taux fantôme d'outils inexistants générés par différents modèles. Comme le montre la figure, ToolLlama et GPT-3.5 sont toujours susceptibles de générer des noms d'outils inexistants malgré le fait que seuls cinq outils réels soient fournis. En revanche, ToolGen évite complètement les hallucinations grâce à sa conception de décodage restreint.

6 Conclusion

Dans cet article, nous présentons ToolGen, un cadre de modélisation du langage étendu (LLM) qui unifie la recherche et l'exécution d'outils en intégrant des jetons virtuels spécifiques à l'outil dans un vocabulaire modèle, transformant ainsi l'interaction avec l'outil en une tâche générative. En incluant un processus de formation en trois étapes, ToolGen permet aux LLM de récupérer et d'exécuter efficacement des outils dans des scénarios du monde réel. Cette approche unifiée établit une nouvelle référence pour les agents d'intelligence artificielle évolutifs et efficaces capables de gérer de grandes bibliothèques d'outils. À l'avenir, ToolGen ouvre la voie à l'intégration de technologies avancées telles que le raisonnement par chaîne de pensée, l'apprentissage par renforcement et ReAct, ce qui améliorera encore l'autonomie et la polyvalence du LLM dans les applications du monde réel.

Références

• Asai et al. (2023) ↑Akari Asai, Zeqiu Wu, Yizhong Wang, Avirup Sil, et Hannaneh Hajishirzi.Self-rag : Learning to retrieve, generate, and critique à travers l'autoréflexion, 2023.URL https://arxiv.org/abs/2310.11511.
• Brohan et al. (2023)↑ Anthony Brohan, Noah Brown, Justice Carbajal, Yevgen Chebotar, Xi Chen, Krzysztof Choromanski, Tianli Ding, Danny Driess, Avinava Dubey, Chesea Finn, Pete Florence, Chuyuan Fu, Montse Gonzalez Arenas, Keerthana Gopalakrishnan, Kehang Han, Karol Avinava Dubey, Chelsea Finn, Pete Florence, Chuyuan Fu, Montse Gonzalez Arenas, Keerthana Gopalakrishnan, Kehang Han, Karol Hausman, Alexander Herzog, Jasmine Hsu, Brian Ichter, Alex Irpan, Nikhil Joshi, Ryan Julian, Dmitry Kalashnikov, Yuheng Kuang, Isabel Leal, Lisa Lee, Tsang-Wei Edward Lee Sergey Levine, Yao Lu, Henryk Michalewski, Igor Mordatch, Karl Pertsch, Kanishka Rao, Krista Reymann, Michael Ryoo, Grecia Salazar, Pannag Sanketi, Pierre Sermanet, Jaspil Joshi, Ryan Julian, Dmitry Kalashnikov, Yuheng Kuang, Isabel Leal, Lisa Lee, Tsang-Wei Edward Lee Pierre Sermanet, Jaspiar Singh, Anikait Singh, Radu Soricut, Huong Tran, Vincent Vanhoucke, Quan Vuong, Ayzaan Wahid, Stefan Welker, Paul Wohlhart. Jialin Wu, Fei Xia, Ted Xiao, Peng Xu, Sichun Xu, Tianhe Yu, and Brianna Zitkovich.Rt-2 : Vision-language-action models transfer web knowledge to robotic control, 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. Girish Sastry, Amanda Askell, Sandhini Agarwal, Ariel Herbert-Voss, Gretchen Krueger, Tom Henighan, Rewon Child, Aditya Ramesh, Daniel M. Ziegler. Jeffrey Wu, Clemens Winter, Christopher Hesse, Mark Chen, Eric Sigler, Mateusz Litwin, Scott Gray, Benjamin Chess, Jack Clark, Christopher Berner, Sam McCandlish, Alec Radford, Ilya Sutskever et Dario Amodei. Les modèles de langue sont des apprenants à faible nombre d'occasions. Ranzato, Raia Hadsell, Maria-Florina Balcan, et Hsuan-Tien Lin (eds.). Advances in Neural Information Processing Systems 33 : Annual Conference on Neural Information Processing Systems 2020, NeurIPS 2020, December 6-12, 2020, virtuel, 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 et Xueqi Cheng.Continual Learning for Generative Récupération sur des corpus dynamiques. Compte rendu de la 32e conférence internationale de l'ACM sur la gestion de l'information et de la connaissance, CIKM '23, pp. 306-315, New York, NY, USA, 2023b. Association for Computing Machinery. isbn 9798400701245. doi : 10.1145/ 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 planification d'outils, 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, et Tomas Pfister. Tomas Pfister, Re-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 méthodes de réglage efficace des agents pour les grands modèles de langage, 2024c.URL https://arxiv.org/abs/2403.12881.
• Dao (2024)↑Tri Dao.FlashAttention-2 : une attention plus rapide avec un meilleur parallélisme et un meilleur partitionnement du travail.In Conférence internationale sur les représentations d'apprentissage (ICLR), 2024.
• Dao et al. (2022)↑Tri Dao, Daniel Y. Fu, Stefano Ermon, Atri Rudra, et Christopher Ré.FlashAttention : fast and memory-efficient exact attention with IOawareness. IO-awareness.In Progrès dans les systèmes de traitement de l'information neuronale (NeurIPS), 2022.
• Dubey et al. (2024)↑Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schelten, Amy Yang, Angela Fan, et al. The llama 3 herd of models.arXiv preprint arXiv:2407.21783, 2024.
• Gravitas (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 Stable Large-Scale Benchmarking on Tool Learning of 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 In Alice Oh, Tristan Naumann, Amir Globerson, Kate Saenko, Moritz Hardt, and Sergey Levine (eds.) Advances in Neural Information Processing Systems 36 : Annual Conference on Neural Information Processing Systems 2023, NeurIPS 2023, Nouvelle-Orléans, LA, États-Unis, 10 - 16 décembre 2023 États-Unis, 10 - 16 décembre 2023, 2023.URL http://papers.nips.cc/paper_files/paper/2023/hash/8fd1a81c882cd45f64958da6284f4a3f-Abstract-Conference.html.
• Järvelin & Kekäläinen (2002)↑Kalervo Järvelin et Jaana Kekäläinen.Évaluation des techniques d'ir basée sur le gain cumulé.ACM Transactions on Information Systems (TOIS) (en anglais), 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 Dense passage retrieval for open-domain question answering.In Bonnie Webber, Trevor Cohn, Yulan He, and Yang Liu (eds.) Actes de la Conférence 2020 sur les méthodes empiriques dans le traitement des langues naturelles (EMNLP), pp. 6769-6781, Online, 2020. association for Computational Linguistics. doi : 10.18653/v1/2020.emnlp-main.550.URL https://aclanthology.org/2020.emnlp-main.550.
• Kishore et al. (2023)↑Varsha Kishore, Chao Wan, Justin Lovelace, Yoav Artzi, et Kilian Q. Weinberger.Incdsi : Incrementally updatable document retrieval.In Andreas Krause, Emma Brunskill, Kyunghyun Cho, Barbara Engelhardt, Sivan Sabato, and Jonathan Scarlett (eds.). Conférence internationale sur l'apprentissage automatique, ICML 2023, 23-29 juillet 2023, Honolulu, Hawaii, États-Unis, volume 202 de Actes de la recherche sur l'apprentissage automatiquePMLR, 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. Agentbench. Evaluating llms as agents.In Douzième conférence internationale sur les représentations d'apprentissage, 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 Arpit, et al. Bolaa : Benchmarking and orchestrating llm-augmented autonomous agents.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, et Donald Metzler. DSI++ : Mise à jour transformateur In Houda Bouamor, Juan Pino, et Kalika Bali (eds.). Compte rendu de la 2023e conférence sur les méthodes empiriques dans le traitement des langues naturellesAssociation for Computational Linguistics. doi : 10.18653/v1/2023.emnlp-main.510.URL https://aclanthology.org/2023.emnlp-main.510.
• OpenAI (2024)↑OpenAI.Gpt-4 rapport technique, 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, et Huajun Chen.Autoact. Apprentissage automatique d'un agent à partir de zéro pour l'assurance qualité via l'auto-planification, 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, et Maosong Sun. Runchu Tian, Ruobing Xie, Jie Zhou, Mark Gerstein, Dahai Li, Zhiyuan Liu et Maosong Sun.ToolLLM : Facilitating Large Language Models to Master 16000+ Real-world API, 2023. Real-world APIs, 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.Tool learning with large language Apprentissage d'outils avec de grands modèles linguistiques : une étude.arXiv preprint arXiv:2405.17935, 2024.
• Rajbhandari et al. (2020)↑Samyam Rajbhandari, Jeff Rasley, Olatunji Ruwase, and Yuxiong He.Zero : Memory optimizations toward training trillion de paramètres, 2020.URL https://arxiv.org/abs/1910.02054.
• Robertson et al. (2009)↑Stephen Robertson, Hugo Zaragoza, et al. The probabilistic pertinence cadre : Bm25 et au-delà.Fondements et tendances® dans la recherche d'information, 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 : les modèles de langage peuvent s'auto-apprendre à utiliser des outils, 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, et Fei Huang.Small llms are weak tool learners : a multi-llm agent, 2024.URL https://arxiv.org/abs/2401.07324.
• Shinn et al. (2023)↑Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, et Shunyu Yao.Reflexion : agents linguistiques avec apprentissage par renforcement verbal. verbal.In Compte rendu de la 37e conférence internationale sur les systèmes de traitement de l'information neuronale, pp. 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, et Zhaochun. Ren, Learning to tokenize for generative retrieval, dans Alice Oh, Tristan Naumann, Amir Globerson, Kate Saenko, Moritz Hardt et Sergey Levine (eds.). Advances in Neural Information Processing Systems 36 : Annual Conference on Neural Information Processing Systems 2023, NeurIPS 2023, Nouvelle-Orléans, LA, États-Unis, 10 - 16 décembre 2023 États-Unis, 10 - 16 décembre 2023, 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 Goyal, Eric Hambro, Faisal Azhar, Aurelien Rodriguez, Armand Joulin, Edouard Grave, et Guillaume Lample.Llama : open and efficient foundation modèles de langage, 2023.URL https://arxiv.org/abs/2302.13971.
• Wang et al. (2024)↑Renxi Wang, Haonan Li, Xudong Han, Yixuan Zhang, et 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 et 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, et A. Oh (eds.). Advances in Neural Information Processing Systems 35 : Annual Conference on Neural Information Processing Systems 2022, NeurIPS 2022, New Orleans, LA, USA, November 28 - December 9, 2022 Nouvelle-Orléans, LA, États-Unis, 28 novembre - 9 décembre 2022, 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 de la pensée suscite le raisonnement dans les grands modèles de langage, 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 Hassan Awadallah, Ryen W White, Doug Burger et Chi Wang.Autogen : Enabling next-gen llm applications via multi-agent conversation framework.In COLM, 2024a.
• Wu et al. (2024b)↑Qinzhuo Wu, Wei Liu, Jian Luan, et Bin Wang.ToolPlanner : a Tool Augmented LLM for Multi Granularity Instructions with Path Planning. et rétroaction, 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 et Arnold Overwijk. Approximate nearest neighbour negative contrastive learning for dense text retrieval.In 9e conférence internationale sur les représentations d'apprentissage, ICLR 2021, Virtual Event, Autriche, 3-7 mai 2021. OpenReview.net, 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 modèles de langage.In Conférence internationale sur les représentations d'apprentissage (ICLR), 2023.
• Yin et al. (2024)↑Da Yin, Faeze Brahman, Abhilasha Ravichander, Khyathi Chandu, Kai-Wei Chang, Yejin Choi, et Bill Yuchen Lin.Agent lumos : Unified and modulaire pour les agents linguistiques open-source.In Lun-Wei Ku, Andre Martins, and Vivek Srikumar (eds.) Actes de la 62e réunion annuelle de l'Association for Computational Linguistics (Volume 1 : Long Papers), pp. 12380-12403, Bangkok, Thaïlande, août 2024. association for Computational Linguistics. 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 : enabling generalised agent abilities for llms, 2023.

Un exemple d'outil réel

carte 5 Un exemple d'outil réel est présenté. Chaque outil contient plusieurs API. Les champs suivants sont utilisés dans nos expériences : "tool_name" est le nom de l'outil. "tool_description" décrit des informations sur l'outil, par exemple ce qu'il fait. Dans chaque API, "name" est le nom de l'API. "description" décrit les informations relatives à l'API. "method" est la méthode http qui appelle l'API. "required_parameters" est le paramètre qui doit être rempli lors de l'appel de l'API. "optional_parameters" peut être utilisé pour définir des paramètres supplémentaires (facultatifs).

{
"tool_name":"YouTube Hub",
"tool_description":"获取单个视频的点赞数、观看次数、标题、缩略图等详细信息。",
"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":"获取视频的所有基本信息",
"method":"GET",
"required_parameters":[
{
"name":"id",
"type":"STRING",
"description":"",
"default":"fD6SzYIRr4c"
}
],
"optional_parameters":[],
}
]
}

Figure 5 : Exemple d'un outil réel. L'outil contient une API et les champs inutiles ont été supprimés pour des raisons de simplicité.

B Mise en œuvre de la virtualisation des outils

ToolGen utilise un token unique pour représenter un outil, ce qui démontre sa force dans la recherche et l'invocation d'outils. Nous avons également introduit d'autres méthodes d'indexation des outils, notamment sémantique, numérique et hiérarchique. Vous trouverez ci-dessous une description détaillée de la manière dont nous mettons en œuvre chaque type d'indexation.

atomique

L'indexation est la méthode que nous utilisons dans ToolGen. Contrairement à d'autres méthodes, elle utilise un seul jeton comme outil et ne falsifie pas un outil qui n'existe pas. Nous utilisons <> pour combiner le nom de l'outil et le nom de l'API en un seul jeton. A L'exemple de cette section donne un jeton <>.

sens des mots

L'index associe chaque outil à un nom utilisé dans ToolBench, qui est également une combinaison du nom de l'outil et du nom de l'API. Toutefois, le nom peut être décomposé en plusieurs tokens afin que le modèle puisse en percevoir la signification sémantique. Dans l'exemple de l'annexe A, le mappage résultant est get_video_details_for_youtube_hub.

numérique

L'index associe chaque outil à un numéro unique. Nous commençons par obtenir une liste de tous les outils, longue d'environ 47 000, et pour tous les outils, nous utilisons un nombre à cinq chiffres, séparés par des espaces, pour représenter l'outil. Si l'exemple de l'annexe A est le 128e élément de la liste, nous utilisons 0 0 0 0 1 2 8 pour représenter l'outil. Étant donné que le lexique Llama-3 code chaque nombre

superposition

associe également chaque outil à un numéro. Contrairement à l'index numérique, nous injectons des informations structurelles dans la représentation des outils par le biais d'un regroupement itératif. À chaque itération, nous regroupons les outils en dix groupes, chacun recevant un numéro de 0 à 9. Pour chaque groupe, nous répétons ce processus de regroupement jusqu'à ce qu'il n'y ait plus qu'un seul outil dans ce groupe. Ces étapes forment un arbre de regroupement. Nous allons de la racine au numéro de la feuille pour représenter les outils de cette feuille. Les exemples de l'annexe A peuvent se voir attribuer un numéro de plus de cinq chiffres, tel que 0 1 2 2 3 3 3.

C Détails de la recherche de contraintes

Lors de la récupération et de l'exécution des tâches de l'agent de bout en bout, nous utilisons la recherche de paquets sous contrainte pour restreindre les opérations générées aux jetons d'outils valides.Les étapes détaillées sont décrites dans l'algorithme 1.L'idée de base est de restreindre l'espace de recherche pendant l'étape de recherche de paquets. Pour ce faire, nous construisons d'abord un arbre dictionnaire disjoint, où chaque nœud représente un ID de jeton outil, et les enfants de ce nœud sont tous les ID réalisables qui suivent l'ID actuel. en utilisant cet arbre, nous pouvons déterminer tous les ID de jeton suivants possibles sur la base de l'ID actuellement recherché. dans l'étape de recherche d'ensemble, nous bloquons tous les autres ID de jeton infaisables, forçant ainsi les ID possibles à se limiter aux jetons outils valides. infaisables, forçant ainsi les ID possibles à être échantillonnés ou recherchés.

Pour la recherche, cette contrainte peut être appliquée directement pendant la génération. Pour la tâche d'agent de bout en bout, puisque nous décomposons l'étape de raisonnement en trois tours de dialogue, nous pouvons facilement détecter le moment où ToolGen doit générer une action et donc appliquer la contrainte. La figure 6 montre un exemple de raisonnement de bout en bout pour ToolGen, où il n'y a pas d'outil associé à choisir pour ToolGen. Il peut simplement générer le ToolToken et accomplir la tâche.

Tableau 6 : Statistiques de l'ensemble de données pour les trois étapes de la formation. Pour la mémoire des outils, il y a quelques doublons, ce qui donne un échantillon légèrement plus grand que le nombre d'outils que nous avons utilisés.

系统：您是一个 AutoGPT，能够利用众多工具和功能来完成给定的任务。
1. 首先，我会给您提供任务描述，您的任务将开始。
2. 在每一步中，您需要通过生成一个行动令牌来确定下一步行动。
3. 在令牌之后，您将收到与该令牌对应的行动文档。您需要生成该行动的输入，将您转移到一个新状态。随后，您将决定下一步，并重复此过程。
4. 在生成多个行动和输入的几次迭代后，您将最终完成任务并提供您的最终答案。
... ...
：我最近访问了 Viva City，菜单给我留下了深刻的印象。我想了解更多关于场馆 5a76c927bb5d660001e09731 的菜单项。您能提供菜单类别、价格、可用性、规则、套餐项及其他相关细节吗？请使用语言 'zh-hans' 来提供菜单详情。
：我需要调用 "<<Viva City Documentation&&MenuDetails>>" 函数以检索场馆 5a76c927bb5d660001e09731 的菜单详情。调用此函数的原因是为了向用户提供菜单类别、价格、可用性、规则、套餐项及其他相关细节。该函数的调用参数为 "lang" 设置为 "zh-hans" 和 "is_id" 设置为 "5a76c927bb5d660001e09731"，以确保提供的菜单详情符合所需语言，并且是针对特定场馆。
：生成行动。
：<<Viva City Documentation&&MenuDetails>>
：请给出输入。以下是文档：{'name': '<<Viva City Documentation&&VenueDetails>>', '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"\n}
：{'error': '', 'response': {'menu_id': '5a76c927bb5d660001e09731', 'language': 'zh-hans', 'menu_details': {'sections': [{'section_name': '开胃菜', 'items': [{'item_name': '春卷', 'description': '脆皮春卷，搭配特制酱汁', 'price': 12.99}, {'item_name': '鸡肉串', 'description': '香辣鸡肉串，外焦里嫩', 'price': 15.99}]}, {'section_name': '主菜', 'items': [{'item_name': '宫保鸡丁', 'description': '经典川菜，麻辣鲜香', 'price': 18.99}, {'item_name': '清蒸鲈鱼', 'description': '清新淡雅，营养健康', 'price': 22.99}]}], 'special_notes': '本菜单提供纯素选项，请告知服务员。'}}}
：场馆 5a76c927bb5d660001e09731 的菜单详情如下：\n- 菜单类别：中餐\n价格：\n - 项目 1：12.99 人民币\n - 项目 2：15.99 人民币\n - 项目 3：18.99 人民币\n - 项目 4：22.99 人民币\n可用性：\n - 项目 1：可用\n - 项目 2：可用\n - 项目 3：可用\n - 项目 4：可用\n- 规则：\n - 项目 1：未提及具体规则\n - 项目 2：未提及具体规则\n - 项目 3：未提及具体规则\n - 项目 4：未提及具体规则\n- 套餐项：\n - 项目 1：2份套餐\n - 项目 2：2份套餐\n - 项目 3：2份套餐\n - 项目 4：2份套餐\n- 其他相关细节：\n - 特别说明：菜单可能会更改，价格也可能会变动。请向场馆确认最新信息。\n\n请告诉我是否还有其他我可以帮助您的地方！
：生成行动。
：<<Finish>>
：请给出输入。以下是文档：{'required': [], 'optional': [{'name': 'give_answer', 'description': '输出答案', 'type': 'string'}, {'name': 'give_up_and_restart', 'description': '无法从此步骤处理任务', 'type': 'string'}]}
：{"return_type": "give_answer", "final_answer": "场馆 5a76c927bb5d660001e09731 的菜单详情如下：\n- 菜单类别：中餐\n- 价格：\n - 项目 1：12.99 人民币\n - 项目 2：15.99 人民币\n - 项目 3：18.99 人民币\n - 项目 4：22.99 人民币\n- 可用性：\n - 项目 1：可用\n - 项目 2：可用\n - 项目 3：可用\n - 项目 4：可用\n- 规则：\n - 项目 1：未提及具体规则\n - 项目 2：未提及具体规则\n - 项目 3：未提及具体规则\n - 项目 4：未提及具体规则\n- 套餐项：\n - 项目 1：2份套餐\n - 项目 2：2份套餐\n - 项目 3：2份套餐\n - 项目 4：2份套餐\n- 其他相关细节：\n - 特别说明：菜单可能会更改，价格也可能会变动。请向场馆确认最新信息。"}

Figure 6 : Exemple de raisonnement avec ToolGen. Tout d'abord, une invite du système est donnée, sans outil associé. Ensuite, l'utilisateur donne une requête de tâche, ToolGen génère une pensée, puis nous utilisons le modèle d'invite du rôle de l'utilisateur pour générer une action. Après avoir généré l'action, nous demandons à nouveau à l'utilisateur de fournir un document sur l'outil. Le modèle génère des entrées d'outils sur la base de cette documentation.

E Test d'ablation

Le tableau 7 montre les résultats de l'ablation pour l'évaluation de bout en bout. Pour les instructions inédites, l'agent ToolGen est légèrement plus performant sans formation à la mémoire ou à la récupération des outils. Cependant, pour les outils inédits, le SoPR et le SoWR diminuent sans les deux premières étapes de formation. Cela suggère que les deux premières étapes de la formation jouent un rôle dans la capacité de généralisation de ToolGen, tandis que la formation à la récupération est plus importante que la mémoire des outils.

Tableau 7 : Résultats de l'évaluation de bout en bout de ToolGen. Ici, Inst. représente les requêtes non vues (commandes) et Tool. et Cat. représentent les outils non vus pendant l'entraînement.

F Capacité de généralisation

Pour ToolGen Agent, nous mesurons la performance du modèle sur des requêtes d'outils non formées. Les performances de ToolGen Agent sont inférieures à celles de ToolLlama, ce qui suggère également une mauvaise généralisation lors de l'exécution de la tâche complète. Le problème de la généralisation est prévalent dans la recherche générative et dépasse le cadre de cet article. C'est pourquoi nous le laissons pour de futures recherches.

Tableau 8 : Résultats de la généralisation pour ToolGen. Nous avons testé et comparé les performances de ToolGen avec celles d'autres modèles sur des requêtes nécessitant des outils inédits lors de l'apprentissage.

Adaptation des données ToolBench à ToolGen

Nos données ToolGen sont adaptées et transformées à partir des données ToolBench. Plus précisément, nous utilisons des documents d'outils comme données pour l'apprentissage de la mémoire d'outil, où les entrées sont des documents d'outils et les sorties sont les jetons correspondants.

Pour la formation à la recherche, nous utilisons des données annotées pour la recherche d'outils dans ToolBench, où une requête est annotée avec plusieurs outils connexes. Nous prenons la requête en entrée et convertissons les outils pertinents en jetons virtuels, qui sont ensuite utilisés comme résultat de l'entraînement à la recherche.

Pour le réglage de bout en bout du corps intelligent, nous utilisons les trajectoires d'interaction comme source avec les transformations suivantes :(1) Chaque trajectoire contient des outils disponibles à partir des indices du système qui peuvent être utilisés pour résoudre des requêtes. Lors de l'exécution d'une tâche, ToolLlama s'appuie sur les outils récupérés dans les indices du système pour résoudre la tâche, alors que ToolGen peut générer des outils directement. Par conséquent, nous supprimons les outils des indices du système. (2) Nous remplaçons tous les noms d'outils dans la trajectoire par le jeton d'outil virtuel correspondant. (3) Dans la trajectoire originale, le modèle de corps intelligent génère séquentiellement la pensée, l'action et l'entrée d'action (également appelée ReAct). Nous décomposons l'ensemble du ReAct en trois cycles de dialogue. Dans le premier cycle, le modèle de corps intelligent génère une pensée et nous utilisons l'utilisateur pour inviter le modèle à générer une action. Dans le deuxième tour, le modèle génère des actions, c'est-à-dire des jetons d'outils virtuels, puis nous obtenons les documents correspondant à ces jetons afin que le modèle sache quels paramètres spécifier. Au troisième tour, le modèle génère des paramètres pour l'outil.

Le nombre d'échantillons dans chaque ensemble de données est indiqué dans le tableau 6. Les échantillons pour la formation à la mémoire et à la récupération des outils sont indiqués dans la figure 7. Les échantillons pour l'ajustement des intelligences de bout en bout sont indiqués dans la figure 8.

# 工具记忆
用户: 工具名称：泰国驾驶执照 OCR。工具描述：提取泰国驾驶执照上的信息并返回文本结果，例如驾驶执照号码和个人信息。API 名称：驾驶执照 API 描述：提取泰国驾驶执照上的信息并返回文本结果，例如驾驶执照号码和个人信息。
助手: <<Thai Drivers License OCRDriver's License>>
# 检索训练
用户: 我和我的朋友正在组织一个关于“网页开发”和“移动应用开发”的黑客马拉松。我们需要一些灵感和指导。你能从 Medium.com 获取这些主题的热门故事吗？
助手: <<Medium&&/search/topics>>

Fig. 7 : Exemple de données pour la formation à la mémoire et à l'extraction d'outils. Nous utilisons les rôles d'utilisateur pour représenter les entrées et les rôles d'assistant pour représenter les sorties.

# 端到端代理调优
系统：
您是一个 AutoGPT，能够利用众多工具和功能来完成给定的任务。
1. 首先，我会提供给您任务描述，您的任务将开始。
2. 在每一步中，您需要通过生成一个操作 Token 来确定下一步行动。
3. 在 Token 之后，您将收到与该 Token 对应的操作文档。您需要生成操作的输入，帮助您转到新的状态。随后，您将对下一步进行决策，并重复此过程。
4. 在生成多个操作和输入的若干次迭代后，您最终将完成任务并提供您的最终答案。
记住：
1. 状态变化是不可逆的，您无法返回到之前的状态。
2. 保持您的操作简洁，限制在最适合当前查询的范围内。
3. 您可以进行多次尝试。如果您计划不断尝试不同的条件，请每次尝试一个条件。
4. 如果您认为您已经收集了足够的信息，请生成操作 "<<Finish>> with argument give_answer"，以提供您对该任务的答案。
5. 如果您觉得在这一步无法处理任务，请生成操作 "<<Finish>> with argument give_up_and_restart"。
让我们开始吧！
任务描述：您应该使用操作来处理实时用户查询。记住：
1. 在任务结束时始终生成 "<<Finish>>"。最终答案应包含足够的信息以展示给用户。如果您无法处理任务，或者发现操作总是失败（该功能当前无效），请使用操作 <<Finish>> with give_up_and_restart。
2. 仅生成操作和输入。
用户：
您能否获取邮政编码 'PL11DN' 的地址？我想知道找到的项目数量、区、分区、县、国家以及地理编码详情（东向、北向、纬度和经度）。
开始！
助手：
根据用户的查询，他们想获取邮政编码 'PL11DN' 的地址，并检索特定详情，如找到的项目数量、区、分区、县、国家以及地理编码详情。当前的 API 调用是针对函数 'find_by_postcode'，参数 'postcode' 设置为 'PL11DN'。此 API 很有用，因为它可以根据给定的英国邮政编码提供地址。通过使用此 API，我将能够为用户的查询检索所需的信息。
用户：
生成操作。
助手：
<<Find By PostCode&&Find By PostCode>>
用户：
请给出输入。这是文档：{'name': '<<Find By PostCode&&Find By PostCode>>', 'description': '“Find By PostCode” API 根据给定的英国邮政编码获取地址。此 API 提供 JSON 接口以搜索英国邮政编码的地址。', 'required': [{'name': 'postcode', 'type': 'string', 'description': '', 'default': 'PL11DN'}], 'optional': []}
助手：
{
"postcode": "PL11DN"
}
工具：
{"error": "", "response": "{'status': 200, 'message': '成功', 'noOfItems': 37, 'result': {'postcode': 'PL1 1DN', 'district': '普利茅斯', 'ward': '圣彼得和海滨', 'county': '德文', 'country': '英格兰', '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': '圣安德鲁十字', 'line_1': '5 圣安德鲁十字', 'postcode_outcode': 'PL1', 'postcode_compact': 'PL11DN', 'dependant_thoroughfare': '', 'premise': '5', 'post_town': '普利茅斯', 'building_name': '', 'organisation_name': '', 'postcode': 'PL1 1DN', 'department_name': '', 'postcode_incode': '1DN', 'address': '5 圣安德鲁十字, 普利茅斯, PL1 1DN', 'double_dependant_locality': '', 'sub_building_name': '', 'dependant_locality': '', 'delivery_point_suffix': '4T'}, {'po_box': '', 'line_2': '2 圣安德鲁十字', 'p...
用户：
生成操作。
助手：
<<Finish>>
用户：
请给出输入。这是文档：{'required': [], 'optional': [{'name': 'give_answer', 'description': '输出答案', 'type': 'string'}, {'name': 'give_up_and_restart', 'description': '无法处理此步骤的任务', 'type': 'string'}]}
助手：
{
"return_type": "give_answer",
"final_answer": "找到的项目数量：37\n区：普利茅斯\n分区：圣彼得和海滨\n县：德文\n国家：英格兰\n地理编码详情：\n- 东向：248025\n- 北向：0054420\n- 纬度：50.370001\n经度：-4.138397"
}

! [[Image collée 20241027190429.png]]

Figure 8 : Exemple de réglage de l'agent de bout en bout.