ToolGen: recuperación e invocación unificadas de herramientas mediante generación

ToolGen es un marco para integrar el conocimiento de las herramientas directamente en los modelos de grandes lenguajes (LLM), lo que permite la invocación de herramientas y la generación de lenguajes sin fisuras mediante la representación de cada herramienta como un token único. Fue desarrollado por Renxi Wang et al. para mejorar el rendimiento de la recuperación de herramientas y la realización de tareas.

  • Tokenización de herramientas: conversión de herramientas en tokens únicos para facilitar la invocación del modelo.
  • Generación de llamadas a herramientas: el modelo es capaz de generar llamadas a herramientas y parámetros.
  • Realización de tareas: automatización de tareas complejas mediante llamadas a herramientas.
  • Soporte de conjuntos de datos: Proporciona ricos conjuntos de datos para apoyar la formación y evaluación de modelos.

 

resúmenes

A medida que evolucionan los grandes modelos lingüísticos (LLM), se hacen especialmente patentes las limitaciones de su incapacidad para realizar tareas de forma autónoma interactuando directamente con herramientas externas. Los enfoques tradicionales se basan en el uso de descripciones de herramientas como entrada contextual, lo que está limitado por la longitud del contexto y requiere un mecanismo de recuperación independiente que a menudo resulta ineficaz. Proponemos ToolGen, un método para recuperar descripciones de herramientas representando cada una de ellas como un único Ficha un paradigma que integra el conocimiento de las herramientas directamente en los parámetros del LLM. Esto permite a los LLM utilizar llamadas a herramientas y parámetros como parte de las capacidades predictivas de su siguiente Token, integrando así a la perfección las llamadas a herramientas con la generación de lenguaje. Nuestro marco permite a los LLM acceder y utilizar un gran número de herramientas sin pasos adicionales de recuperación, lo que mejora significativamente el rendimiento y la escalabilidad. Los resultados experimentales basados en más de 47.000 herramientas demuestran que ToolGen no sólo consigue resultados superiores en la recuperación de herramientas y la realización autónoma de tareas, sino que también sienta las bases para una nueva generación de agentes de IA capaces de adaptarse a una amplia gama de herramientas de dominio. Al transformar fundamentalmente la recuperación de herramientas en un proceso generativo, ToolGen allana el camino a sistemas de IA más flexibles, eficientes y autónomos.ToolGen amplía la utilidad de LLM al soportar el aprendizaje de herramientas de extremo a extremo y ofrecer oportunidades de integración con otras tecnologías avanzadas como Chain Thinking y Reinforcement Learning.

1 Introducción

Los grandes modelos lingüísticos (LLM) han demostrado una capacidad impresionante para procesar entradas externas, realizar operaciones y completar tareas de forma autónoma (Gravitas, 2023; Qin et al. 2023; Yao et al. 2023; Shinn et al. 2023; Wu et al. 2024a; Liu et al. 2024). Entre los diversos enfoques para permitir que los LLM interactúen con el mundo externo, las llamadas a herramientas a través de API se han convertido en uno de los más comunes y eficaces. Sin embargo, a medida que el número de herramientas aumenta hasta las decenas de miles, los métodos existentes de recuperación y ejecución de herramientas son difíciles de escalar eficientemente.

En escenarios reales, un enfoque común es combinar la recuperación de herramientas con la ejecución de las mismas, donde el modelo de recuperación filtra primero las herramientas relevantes antes de entregarlas al LLM para su selección y ejecución final (Qin et al., 2023; Patil et al., 2023). Aunque este enfoque combinado es útil cuando se trata de un gran número de herramientas, existen limitaciones obvias: los modelos de recuperación a menudo dependen de codificadores pequeños que dificultan la captura exhaustiva de la semántica de herramientas y consultas complejas, mientras que separar la recuperación de la ejecución puede dar lugar a ineficiencias y sesgos de etapa en el proceso de finalización de tareas.

Además, los LLM y sus desambiguadores están preentrenados principalmente con datos de lenguaje natural (Brown et al., 2020; Touvron et al., 2023), y tienen un conocimiento intrínseco limitado de la funcionalidad propia relacionada con las herramientas. Esta carencia de conocimientos da lugar a un rendimiento deficiente, especialmente cuando los LLM deben basarse en descripciones de herramientas recuperadas para tomar decisiones.

En este estudio, presentamos ToolGen, un nuevo marco que integra el conocimiento de herramientas del mundo real directamente en los parámetros de LLM y transforma la recuperación y ejecución de herramientas en una tarea de generación unificada. Específicamente, ToolGen hace un uso más efectivo del conocimiento preexistente de LLM para la recuperación e invocación de herramientas extendiendo el vocabulario de LLM para representar herramientas como Tokens virtuales específicos y entrenando el modelo para generar estos Tokens en el contexto de diálogo.

Basándose en el LLM preentrenado, el proceso de entrenamiento de ToolGen consta de tres fases: memoria de herramientas, entrenamiento de recuperación y entrenamiento de agentes. Durante la fase de memoria de herramientas, el modelo asocia cada token de herramienta virtual con su documento. Por último, en la fase de entrenamiento del agente, el modelo se entrena para actuar como agente autónomo, generando planes y herramientas y determinando los parámetros adecuados para completar la tarea. Al invocar herramientas y obtener información del entorno externo, el modelo puede procesar las consultas del usuario de forma eficiente e integradora. La figura 1 muestra la comparación de ToolGen con el paradigma tradicional.

Validamos la superioridad de ToolGen en dos escenarios: una tarea de recuperación de herramientas en la que el modelo recupera la herramienta correcta para una consulta determinada, y una tarea de agente basada en LLM en la que el modelo completa tareas complejas que implican llamadas a API reales. Utilizando un conjunto de datos de 47.000 herramientas del mundo real, ToolGen funciona tan bien como los principales métodos de recuperación de herramientas, pero con un coste significativamente menor y una mayor eficiencia. Además, va más allá del paradigma tradicional de aprendizaje de herramientas, lo que pone de relieve su potencial para avanzar en sistemas de uso de herramientas más eficaces.

ToolGen:通过生成实现统一的工具检索和调用Figura 1: Comparación de ToolGen con enfoques anteriores basados en la recuperación. Los enfoques anteriores utilizan un recuperador para recuperar las herramientas relevantes mediante la comparación de similitudes y, a continuación, colocan estas herramientas en las solicitudes del LLM para su selección. ToolGen permite la recuperación de herramientas mediante la generación directa de un token de herramienta y puede realizar la tarea sin depender de ningún recuperador externo.

ToolGen representa un nuevo paradigma para la interacción con herramientas, fusionando la recuperación y la generación en un modelo unificado. Esta innovación sienta las bases de una nueva generación de agentes de IA capaces de adaptarse a una gran variedad de herramientas del dominio. Además, ToolGen crea nuevas oportunidades para combinar técnicas avanzadas como el razonamiento encadenado y el aprendizaje por refuerzo con un enfoque generativo unificado para el uso de herramientas, ampliando las capacidades de los grandes modelos lingüísticos en aplicaciones del mundo real.

En resumen, nuestras contribuciones incluyen:

  • Se propone un marco novedoso, ToolGen, que integra la recuperación y ejecución de herramientas en el proceso de generación de grandes modelos lingüísticos mediante tokens virtuales.
  • Se diseñó un proceso de formación en tres fases para que ToolGen fuera eficiente y escalable en la recuperación de herramientas y las llamadas a la API.
  • La validación experimental muestra que ToolGen exhibe un rendimiento comparable al de los mejores métodos disponibles de recuperación de herramientas en repositorios de herramientas a gran escala, pero a un coste menor, de forma más eficiente y más allá del paradigma tradicional de aprendizaje de herramientas.

2 Trabajos relacionados

2.1 Recuperación de herramientas

La recuperación de herramientas es crucial en la ejecución práctica de tareas de grandes agentes de modelos lingüísticos, donde las herramientas suelen describirse mediante sus documentos. Los enfoques tradicionales, como la recuperación dispersa (p. ej. BM25 (Robertson et al., 2009)) y la recuperación intensiva (por ejemplo, DPR (Karpukhin et al., 2020), ANCE (Xiong et al., 2021)) se basan en grandes índices de documentos y módulos externos, lo que conlleva ineficiencias y dificultades de optimización en un marco de agentes de extremo a extremo. Varios estudios han explorado enfoques alternativos. Por ejemplo, Chen et al. (2024b) reescriben la consulta y extraen su intención hacia un entorno de recuperación sin supervisión, aunque los resultados no son tan buenos como los de los métodos supervisados.Xu et al. (2024) proponen un enfoque que mejora la precisión de la recuperación pero aumenta la latencia mediante la optimización iterativa de la consulta basada en la retroalimentación de la herramienta.

Recientemente, la recuperación generativa ha surgido como un nuevo paradigma prometedor en el que los modelos generan directamente identificadores de documentos relevantes en lugar de depender de los mecanismos de recuperación tradicionales (Wang et al., 2022; Sun et al., 2023; Kishore et al., 2023; Mehta et al., 2023; Chen et al., 2023b). Inspirado en esto, ToolGen representa cada herramienta como un token único, de modo que la recuperación y la invocación de herramientas se puedan gestionar como tareas generativas. Además de simplificar la recuperación, este diseño puede utilizarse junto con otros Big Language Models y funciones de agente basadas en Big Language Models como Chained Thought Reasoning (Wei et al., 2023) y ReAct (Yao et al., 2023)). Al integrar la recuperación y la ejecución de tareas en un único agente de modelo lingüístico de gran tamaño, se reducen la latencia y la sobrecarga computacional, y se mejora la eficiencia y la eficacia de la realización de tareas.

2.2 Agentes de modelos lingüísticos grandes con llamadas a herramientas

Los grandes modelos lingüísticos muestran un gran potencial para dominar las herramientas necesarias para diversas tareas. Sin embargo, la mayor parte de la investigación existente se ha centrado en un conjunto limitado de acciones (Chen et al., 2023a; Zeng et al., 2023; Yin et al., 2024; Wang et al., 2024). Por ejemplo, Toolformer (Schick et al., 2023) afina GPT-J para manejar sólo cinco herramientas (por ejemplo, calculadoras). ToolBench (Qin et al., 2023) amplía el estudio introduciendo más de 16.000 herramientas, lo que pone de relieve los retos que plantea la selección de herramientas en entornos complejos.

Para realizar la selección de herramientas, los enfoques actuales suelen emplear una canalización de recuperación-generación, en la que el modelo de lenguaje de gran tamaño primero recupera la herramienta relevante y luego la explota (Patil et al., 2023; Qin et al., 2023). Sin embargo, el enfoque de canalización se enfrenta a dos problemas principales: el paso erróneo de la recuperación y la dificultad de los modelos de lenguaje de gran tamaño para comprender y utilizar plenamente las herramientas a través de simples indicaciones.

Para paliar estos problemas, los investigadores han intentado representar las acciones como Token y transformar la predicción de acciones en tareas generativas. Por ejemplo, RT2 (Brohan et al., 2023) genera Token que representan acciones de robots, y Self-RAG (Asai et al., 2023) utiliza Token especiales para decidir cuándo recuperar un documento.ToolkenGPT (Hao et al., 2023) introduce Token específicos de herramientas para activar el uso de la herramienta, un concepto más cercano a nuestro enfoque. concepto más cercano a nuestro enfoque.

Nuestro enfoque difiere significativamente de ToolkenGPT. En primer lugar, nos centramos en herramientas reales que requieren parámetros flexibles para tareas complejas (por ejemplo, la búsqueda de canales en YouTube), mientras que ToolkenGPT se limita a herramientas más sencillas con menos entradas (por ejemplo, funciones matemáticas con dos números). Además, ToolkenGPT depende de menos pistas de muestra, mientras que ToolGen integra el conocimiento de las herramientas directamente en el modelo lingüístico más amplio mediante un ajuste fino completo de los parámetros, lo que le permite recuperar y realizar tareas de forma autónoma. Por último, nuestros experimentos incluyen un conjunto de herramientas mucho mayor: 47.000 herramientas, frente a las 13.300 de ToolkenGPT.

Otros estudios como ToolPlanner (Wu et al., 2024b) y AutoACT (Qiao et al., 2024) han utilizado el aprendizaje por refuerzo o sistemas multiagente para mejorar el aprendizaje de herramientas o la realización de tareas (Qiao et al., 2024; Liu et al., 2023; Shen et al., 2024; Chen et al., 2024a). No comparamos estos enfoques con nuestro modelo por dos razones:(1) la mayoría de estos esfuerzos se basan en mecanismos de retroalimentación como Reflexión (Shinn et al., 2023) o modelos de recompensa, que son similares al diseño de evaluación de ToolBench en el que el gran modelo lingüístico actúa como evaluador y no tiene acceso a las respuestas reales. Sin embargo, este no es el objetivo de nuestro estudio, y nuestros experimentos de extremo a extremo no se basan en tales mecanismos de retroalimentación. (2) Nuestro enfoque no entra en conflicto con estos métodos, sino que puede integrarse. La exploración de dicha integración se deja para futuras investigaciones.

3 ToolGen

En esta sección, presentamos en primer lugar la representación simbólica utilizada en el documento. A continuación, describimos en detalle el enfoque específico de ToolGen, incluida la virtualización de herramientas, la memoria de herramientas, el entrenamiento de recuperación y el ajuste de agentes de extremo a extremo, como se muestra en la Figura 2. Por último, presentamos nuestra metodología de inferencia. Por último, presentamos nuestra metodología de inferencia.

ToolGen:通过生成实现统一的工具检索和调用Figura 2: Diagrama esquemático del marco ToolGen. En la fase de virtualización de herramientas, éstas se asignan a tokens virtuales y, en las tres fases de formación siguientes, ToolGen primero recuerda las herramientas mediante la predicción de tokens de herramientas a partir de documentos de herramientas. A continuación, ToolGen aprende a recuperar herramientas prediciendo tokens de herramientas a partir de consultas. Por último, los datos de las canalizaciones (es decir, las trayectorias) se utilizan para afinar el modelo de recuperación en la última fase, que genera el modelo del agente ToolGen.

3.1 Conocimientos preparatorios

Para una consulta de usuario dada q, el objetivo del aprendizaje de herramientas es resolver q utilizando herramientas de un gran conjunto de herramientas D={d1,d2,...,dN}, donde |D|=N es un número grande, lo que hace poco práctico incluir todas las herramientas en D en un entorno de modelado lingüístico grande. Por lo tanto, la investigación actual suele utilizar un recuperador R para recuperar k herramientas relevantes de D, denotado como Dk,R={dr1,dr2,...,drk}=R(q,k,D), donde |Dk,R|≪N. El prompter final es una concatenación de q y Dk,R, denotado como Prompt=[q,Dk,R]. Para completar una tarea (consulta), los agentes basados en grandes modelos de lenguaje suelen utilizar una iteración de cuatro etapas (Qu et al., 2024 ): generación de un plan pi , selección de una herramienta dsi , determinación de los parámetros de la herramienta ci , y recopilación de información de la retroalimentación de la herramienta fi . Denotamos estos pasos como pi,dsi,ci,fi para la iteración i-ésima. El modelo continúa iterando a través de estos pasos hasta que se completa la tarea, momento en el que se genera la respuesta final a. La trayectoria completa puede representarse como Traj=[Prompt,(p1,ds1,c1,f1),...,(pt,dst,ct,ft),a]=[q,R (q,D),(p1,ds1,c1,f1),...,(pt,dst,ct,ft),a]. Este enfoque iterativo permite al modelo ajustar y perfeccionar dinámicamente sus operaciones en cada paso en función de la información recibida, mejorando así su rendimiento en la realización de tareas complejas.

3.2 Virtualización de herramientas

En ToolGen, aplicamos la virtualización de herramientas asignando cada una de ellas a un nuevo token único mediante un método denominado indexación atómica. En este enfoque, se asigna un token único a cada herramienta ampliando el vocabulario de un gran modelo de lenguaje. La incrustación de cada token de herramienta se inicializa con la incrustación media de su correspondiente nombre de herramienta, proporcionando así un punto de partida semánticamente significativo para cada herramienta.

Formalmente, un conjunto Token se define como T = Index(d)|∀d ∈ D, donde Index es una función que mapea herramientas a Token. Demostramos que la indexación atómica es más eficiente y reduce los fenómenos fantasma en comparación con otros métodos de indexación (por ejemplo, los mapeos semánticos y numéricos; véanse 4.3 y 5.4 para más información).

3.3 Memoria de herramientas

Tras asignar un token a una herramienta, el modelo de Big Language sigue careciendo de conocimientos sobre la herramienta. Para solucionar este problema, afinamos la descripción de la herramienta utilizándola como entrada y su correspondiente token como salida, proceso que denominamos memoria de herramientas. Utilizamos la siguiente función de pérdida:

ℒtool=∑d∈D-logpθ(Index(d)|ddoc)

donde θ indica los parámetros del gran modelo lingüístico y ddoc indica la descripción de la herramienta. Este paso proporciona los fundamentos de la herramienta y las operaciones relacionadas con el modelo de lenguaje de gran tamaño.

3.4 Formación para la búsqueda

A continuación, entrenamos el modelo de gran lenguaje para que asocie el espacio oculto de la herramienta virtual Token (y sus documentos) con el espacio de las consultas de los usuarios, de modo que el modelo pueda generar la herramienta correcta en función de la consulta del usuario. Para ello, afinamos el gran modelo lingüístico tomando las consultas de los usuarios como entrada y la herramienta Token correspondiente como salida:

ℒrecuperación=∑q∈Q∑d∈Dqq-logpθ′(Índice(d)|q)

donde θ′ denota el gran parámetro del modelo de lenguaje tras la memoria de herramientas, Q es el conjunto de consultas del usuario y Dq es el conjunto de herramientas asociadas a cada consulta. Este proceso genera el recuperador ToolGen, lo que le permite generar el token de herramienta adecuado para una consulta de usuario determinada.

3.5 Ajuste del agente de extremo a extremo

En la etapa final, utilizamos tareas de Agent-Flan para completar el modelo de ajuste fino de la trayectoria. Adoptamos una estrategia de inferencia similar a la de Agent-Flan (Chen et al., 2024c), en la que nuestro pipeline utiliza un proceso iterativo, en el que el modelo genera primero el Thought y, a continuación, genera el correspondiente Action Token, que se utiliza para obtener el documento de la herramienta, que luego es utilizado por el modelo de big language para generar los parámetros necesarios. El proceso itera hasta que el modelo genera un token de "hecho" o alcanza el número máximo de rondas. La trayectoria generada se representa como Traj=[q,(p1,Index(ds1),c1,f1),...,(pt,Index(dst),ct,ft),a]. En esta estructura, la herramienta de asociación ya no es necesaria.

3.6 Razonamiento

Durante el proceso de razonamiento, un modelo lingüístico de gran tamaño puede generar tokens de acción más allá del conjunto predefinido de tokens de herramientas. Para evitarlo, ideamos un método de generación de paquetes de búsqueda restringida para limitar los tokens de salida al conjunto de tokens de herramientas. Aplicamos esta búsqueda restringida de paquetes a la recuperación de herramientas (donde el modelo se basa en una herramienta de selección de consultas) y a los sistemas de agentes de extremo a extremo, reduciendo eficazmente las ilusiones en el paso de generación de acciones. Véase un análisis detallado en 5.4. Para más detalles sobre la aplicación, véase el Apéndice C.

4 Evaluación de la recuperación de herramientas

4.1 Montaje experimental

Utilizamos el modelo preentrenado Llama-3-8B (Dubey et al., 2024) como modelo base con un vocabulario de 128.256. Se añadieron 46.985 tokens durante la virtualización de la herramienta mediante el método de indexación atómica, lo que dio como resultado un vocabulario final de 175.241. Afinamos el modelo utilizando la plantilla de chat Llama-3 con un programador de tasa de aprendizaje coseno y aplicando un paso de calentamiento de 3%. y aplicando un paso de calentamiento de 3%. La tasa de aprendizaje máxima fue de 4 × 10-5. Todos los modelos se pasaron por Deepspeed ZeRO 3 en 4 × GPU A100 (Rajbhandari et al.2020). Se realizaron ocho rondas de entrenamiento de memoria de herramientas y una ronda de entrenamiento de recuperación.

conjunto de datos

Nuestros experimentos se basan en ToolBench, una herramienta de referencia del mundo real que contiene más de 16.000 colecciones de herramientas, cada una de ellas con varias API, lo que supone un total de unas 47.000 API únicas. cada API se documenta mediante un diccionario que contiene el nombre de la API, su descripción y los parámetros de llamada. Véase un ejemplo real en el Apéndice. ATratamos cada API como una operación y la asignamos a un token. Tratamos cada API como una operación y la asignamos a un token. nuestros datos de recuperación y ajuste del agente de extremo a extremo se convierten a partir de los datos sin procesar de ToolBench. Para más información, véase el apéndice. G. Aunque cada herramienta puede contener varias API, para simplificar, este documento se refiere a cada API colectivamente como una herramienta.

Seguimos la metodología de partición de datos de Qin et al. (2023) y clasificamos los 200.000 pares (consultas, API asociadas) en tres categorías: I1 (consultas de una sola herramienta), I2 (consultas de varias herramientas dentro de clases) e I3 (comandos de varias herramientas dentro de colecciones), que contienen 87.413, 84.815 y 25.251 instancias, respectivamente.

Metodología de referencia

Comparamos ToolGen con las siguientes pruebas de referencia:

  • BM25: Método clásico de recuperación no supervisada basado en TF-IDF y en la similitud de palabras entre la consulta y el documento.
  • Similitud de incrustación (EmbSim): incrustación de frases generada mediante el modelo de incrustación de frases de OpenAI; en concreto, text-embedding-3-large utilizado en nuestros experimentos.
  • Re-Invoke (Chen et al., 2024b): un método de recuperación no supervisado que incorpora la reescritura de consultas y la expansión de documentos.
  • IterFeedback (Xu et al., 2024): un recuperador basado en BERT que utiliza gpt-3.5-turbo-0125 como modelo de retroalimentación para hasta 10 rondas de retroalimentación iterativa.
  • ToolRetriever (Qin et al., 2023): un recuperador basado en BERT entrenado mediante aprendizaje por contraste.

establecer

Realizamos experimentos en dos escenarios. En el primero, la recuperación dentro del dominio restringe la recuperación de herramientas cuyo espacio de búsqueda se encuentra dentro del mismo dominio. Por ejemplo, al evaluar consultas en el dominio I1, se limita a las herramientas de I1. Esta configuración es coherente con la de ToolBench. El segundo escenario, Multi-Domain Retrieval, es más complejo, ya que el espacio de búsqueda se amplía a las herramientas de los tres tipos de dominios. En este caso, el modelo se entrena con datos combinados, lo que aumenta el espacio de búsqueda y la complejidad de la tarea. A diferencia de ToolBench, el escenario multidominio refleja situaciones realistas en las que las tareas de recuperación pueden implicar dominios superpuestos o mixtos. Este escenario evalúa la capacidad del modelo para generalizar entre dominios y gestionar tareas de recuperación más complejas y diversas.

norma

Evaluamos el rendimiento de la recuperación mediante la ganancia acumulativa con descuento normalizado (NDCG) (Järvelin y Kekäläinen, 2002), una métrica muy utilizada en tareas de clasificación, incluida la recuperación de herramientas.

Tabla 1: Evaluación de la recuperación de herramientas en dos escenarios: (1) recuperación intradominio, en la que los modelos se entrenan y evalúan en los mismos dominios, y (2) recuperación multidominio, en la que los modelos se entrenan en todos los dominios y se evalúan en el conjunto completo de herramientas de todos los dominios.BM25, EmbSim y Re-Invoke son métodos de evaluación comparativa no entrenados y no supervisados.IterFeedback ToolRetriever se entrena mediante aprendizaje por contraste, mientras que ToolGen se entrena mediante predicción de la siguiente ficha. Los elementos con * en los resultados indican modelos que no hemos implementado nosotros, y los datos proceden del artículo original, por lo que sólo figuran en la configuración dentro del dominio. En el caso de ToolGen en el entorno dentro del dominio, permitimos que el espacio de generación incluyera todos los tokens, lo que supone un mayor reto en comparación con otros modelos. Los mejores resultados de cada categoría se indican en negrita.

modelizaciónI1I2I3
NDCG1NDCG3NDCG5NDCG1NDCG3NDCG5NDCG1NDCG3NDCG5
región
BM2529.4631.1233.2724.1325.2927.6532.0025.8829.78
EmbSim63.6761.0365.3749.1142.2746.5653.0046.4052.73
Invocar de nuevo*.69.47-61.1054.56-53.7959.65-59.55
IterFeedback*90.7090.9592.4789.0185.4687.1091.7487.9490.20
Recuperador de herramientas80.5079.5584.3971.1864.8170.3570.0060.4464.70
ToolGen89.1790.8592.6791.4588.7991.1387.0085.5990.16
multidominio
BM2522.7722.6425.6118.2920.7422.1810.0010.0812.33
EmbSim54.0050.8255.8640.8436.6739.5518.0017.7720.70
Recuperador de herramientas72.3170.3074.9964.5457.9163.6152.0039.8942.92
ToolGen87.6788.8491.5483.4686.2488.8479.0079.8084.79

4.2 Resultados

La tabla 1 muestra los resultados de la recuperación de herramientas. Como era de esperar, todos los modelos entrenados superan significativamente a los no entrenados (BM25, EmbSim y Re-Invoke) en todas las métricas, lo que demuestra las ventajas de entrenar con datos de recuperación de herramientas.

El modelo ToolGen que proponemos obtiene sistemáticamente los mejores resultados en ambos entornos. En el entorno dentro del dominio, ToolGen proporciona resultados altamente competitivos, con un rendimiento comparable al del sistema IterFeedback utilizando múltiples modelos y mecanismos de retroalimentación. Como modelo único, ToolGen supera significativamente a ToolRetriever en todas las métricas e incluso supera a IterFeedback en varios escenarios (por ejemplo, NDCG@5 para el dominio I1 y NDCG@1, @3, @5 para I2).

En el entorno multidominio, ToolGen sigue siendo robusto, superando a ToolRetriever y manteniéndose por delante de los modelos de referencia, a pesar del mayor espacio de búsqueda y la habitual caída del rendimiento general. Esto demuestra que ToolGen, a pesar de ser un modelo único, puede competir con sistemas de recuperación complejos como IterFeedback, lo que demuestra su capacidad para gestionar tareas de recuperación complejas del mundo real con límites de dominio poco claros.

4.3 Comparación de los métodos de indexación

Aunque ToolGen utiliza índices atómicos para la virtualización de herramientas, también exploramos varios métodos alternativos de recuperación generativa. En esta sección, los comparamos con los tres enfoques siguientes:

  • Digital: asigna a cada herramienta un número único. El token generado es puramente digital y no proporciona información semántica intrínseca, sino un identificador único para cada herramienta.
  • Jerárquico: este método agrupa las herramientas en grupos no superpuestos y divide recursivamente estos grupos para formar una estructura jerárquica. Un índice desde el nodo raíz hasta los nodos hoja de esta estructura representa cada herramienta, de forma similar a la técnica de agrupación de Brown.
  • Semántica: En este enfoque, cada herramienta se asigna a su nombre, que guía al Modelo de Lenguaje Amplio (LLM) a través del contenido semántico del nombre de la herramienta. El nombre de la herramienta proporciona directamente una representación significativa relacionada con su función.
ToolGen:通过生成实现统一的工具检索和调用

Figura 3: La distribución del número de subtokens por herramienta difiere según el método de indexación. La indexación atómica garantiza que cada herramienta sea un único Token, mientras que la indexación numérica codifica las herramientas en N Token, es decir, el número de herramientas se encuentra en el intervalo (10N-1,10N]. En cambio, la indexación semántica y la indexación jerárquica producen números variables de subtokens, y la indexación semántica tiene una secuencia más larga de subtokens y más valores atípicos.

Los detalles específicos de la aplicación se describen en el Apéndice B.

En primer lugar, analizamos el número de subtokens que requiere cada método para representar cada herramienta, como se muestra en la figura 3. El gráfico pone de manifiesto la superioridad de la indexación atómica, en la que cada herramienta se representa mediante un único token, mientras que los demás métodos requieren múltiples tokens. El gráfico pone de manifiesto la superioridad de la indexación atómica, en la que cada herramienta está representada por un único Token, mientras que los demás métodos requieren múltiples Token. esta eficiencia permite a ToolGen reducir el número de generación de Token y acortar el tiempo de razonamiento en escenarios de recuperación y agente.

A continuación, examinamos la eficacia de los distintos métodos de indexación. Como se muestra en la Tabla 2, la indexación semántica presenta el mejor rendimiento de recuperación en una serie de métricas y escenarios, mientras que la indexación atómica queda en un cercano segundo lugar en muchos casos. Atribuimos este hecho a que la indexación semántica se ajusta mejor a los datos preentrenados del modelo lingüístico de gran tamaño. Sin embargo, esta ventaja disminuye a medida que aumentan los datos de entrenamiento y los tipos. Por ejemplo, en la sección 5.3, mostramos que los índices atómicos se comportan mejor en los resultados de extremo a extremo. Teniendo en cuenta estos factores, elegimos los índices atómicos para la virtualización de herramientas ToolGen.

Tabla 2: Evaluaciones de recuperación de distintos métodos de indexación en el entorno multidominio. Los mejores resultados aparecen en negrita y los siguientes, subrayados.

modelizaciónI1I2I3
NDCG1NDCG3NDCG5NDCG1NDCG3NDCG5NDCG1NDCG3NDCG5
numérico83.1784.9988.7379.2079.2383.8871.0074.8182.95
laminación85.6787.3890.2682.2282.7086.6378.5079.4784.15
significado de las palabras89.1791.2993.2983.7184.5188.2282.0078.8685.43
atómica87.6788.8491.5483.4686.2488.8479.0079.8084.79

Tabla 3: Estudios de ablación para la recuperación de herramientas. Los efectos de eliminar el entrenamiento de recuperación, la memoria de herramientas y la búsqueda restringida de haces en el rendimiento de ToolGen se evalúan por separado.

modelizaciónI1I2I3
NDCG1NDCG3NDCG5NDCG1NDCG3NDCG5NDCG1NDCG3NDCG5
ToolGen87.6788.8491.5483.4686.2488.8479.0079.8084.79
-Memoria84.0086.7789.3582.2183.2086.7877.0077.7184.37
-Formación de recuperación10.1712.3113.895.527.017.813.004.004.43
-Encuadernación87.6788.7991.4583.4686.2488.8379.0079.9384.92

4.4 Experimentos de ablación

Realizamos experimentos de ablación para evaluar los efectos de diferentes fases de entrenamiento de ToolGen, como se muestra en la Tabla 3 Se muestra. Los resultados muestran que el entrenamiento en recuperación es un factor clave que afecta al rendimiento de la recuperación de herramientas, ya que alinea directamente la tarea de recuperación en la que la entrada es una consulta y la salida es un Token de herramienta. La eliminación de las memorias de herramientas provoca una ligera disminución del rendimiento, aunque resulta útil para mejorar el rendimiento de la generalización, como mostraremos en el Apéndice F que se analiza más adelante. Del mismo modo, la búsqueda restringida de paquetes, aunque contribuye poco a la tarea de recuperación, ayuda a evitar la generación de alucinaciones y, por tanto, tiene cierto valor en las tareas de agente de extremo a extremo, véase la sección 5.4.

5 Evaluación de principio a fin

5.1 Montaje experimental

Hemos realizado varios cambios en los datos de rastreo de ToolBench para adaptarlos al marco de ToolGen. Por ejemplo, dado que ToolGen no requiere la selección explícita de herramientas relevantes como entrada, eliminamos esta información de las indicaciones del sistema. Para más detalles, véase el Apéndice G. Basándonos en esto, hemos ajustado el modelo de recuperación utilizando los datos reformateados para generar un agente ToolGen de extremo a extremo.

modelo base

  • GPT-3.5: Utilizamos gpt-3.5-turbo-0613 como uno de los modelos de referencia. La implementación es la misma que la de StableToolBench (Guo et al., 2024), donde la funcionalidad de llamada a herramientas de GPT-3.5 se utiliza para formar agentes de herramientas.
  • ToolLlama-2: Qin et al. (2023) introdujeron ToolLlama-2 afinando el modelo Llama-2 (Touvron et al., 2023) en los datos de ToolBench.
  • ToolLlama-3: Para garantizar una comparación justa, creamos el modelo de referencia ToolLlama-3 ajustando el mismo modelo de base Llama-3 que ToolGen en el conjunto de datos ToolBench. En el resto del documento, nos referiremos a ToolLlama-3 como ToolLlama para distinguirlo de ToolLlama-2.

establecer

  • Uso de Herramientas Genuinas (G.T.): refiriéndonos a Qin et al. (2023), definimos las Herramientas Genuinas para consultas como ChatGPT Herramienta seleccionada. Para ToolLlama, introducimos la herramienta real directamente en el prompt, en el mismo formato que sus datos de entrenamiento. En el caso de ToolGen, como no se entrenó con datos de herramientas preseleccionadas, añadimos el prefijo: Estoy utilizando la siguiente herramienta en la fase de planificación:[herramienta fichas], donde [tokens de herramienta] es el Token virtual correspondiente a la herramienta real.
  • Uso de recuperadores: en los experimentos de extremo a extremo, utilizamos una configuración basada en la recuperación. Para el modelo base, utilizamos herramientas recuperadas por ToolRetriever como herramientas asociadas. ToolGen, por su parte, genera tokens de herramientas directamente y, por tanto, no utiliza un recuperador.

Todos los modelos se ajustaron con precisión utilizando un programador coseno con la tasa de aprendizaje máxima fijada en 4 × 10-5. La longitud del contexto se truncó a 6.144 y el tamaño total del lote a 512. Además, utilizamos Flash-Attention (Dao et al., 2022; Dao, 2024) y Deepspeed ZeRO 3 ( Rajbhandari et al., 2020) para ahorrar memoria.

ToolGen y ToolLlama siguen paradigmas diferentes para completar la tarea; ToolLlama genera ideas, acciones y parámetros en una sola ronda, mientras que ToolGen separa estos pasos. Para ToolGen, fijamos un tope de hasta 16 rondas, permitiendo 5 rondas de acciones y 1 ronda de respuestas finales. Lo comparamos con el límite de 6 rondas de ToolLlama.

Además, introdujimos un mecanismo de reintento para todos los modelos con el fin de evitar la terminación prematura, cuyos detalles se describen en el Apéndice D. En concreto, si un modelo genera una respuesta que contiene "ríndete" o "lo siento", pedimos al modelo que vuelva a generar la respuesta a una temperatura más alta.

Evaluación de los indicadores

Para la evaluación de extremo a extremo, utilizamos el benchmark de evaluación de herramientas estables StableToolBench (Guo et al., 2024), que selecciona consultas resolubles de ToolBench y simula la salida de herramientas fallidas utilizando GPT-4 (OpenAI, 2024). Evaluamos el rendimiento utilizando dos métricas: la tasa de respuestas aprobadas solucionables (SoPR), que es el porcentaje de consultas que se resuelven con éxito, y la tasa de respuestas ganadas solucionables (SoWR), que indica el porcentaje de respuestas que superan al modelo de referencia (GPT-3.5 en este estudio). Además, proporcionamos las puntuaciones micromediadas de cada categoría.

Tabla 4: Rendimiento de la evaluación de extremo a extremo de comandos no vistos en dos configuraciones. Para la configuración R., GPT-3.5 y ToolLlama utilizan ToolRetriever, mientras que ToolGen no utiliza un recuperador externo. Todas las evaluaciones SoPR y SoWR resultantes se realizan tres veces y se presentan como valores medios.

modelizaciónSoPRSoWR
I1I2I3Avg.I1I2I3Avg
Utilización de herramientas reales (G.T.)
GPT-3.556.6047.8054.6450.91----
ToolLlama-253.3741.9846.4548.4347.2759.4327.8747.58
ToolLlama55.9348.2752.1952.7850.3153.7731.1547.88
ToolGen61.3549.5343.1754.1951.5357.5531.1549.70
Uso del Recuperador (R.)
GPT-3.551.4341.1934.4345.0053.3753.7737.7050.60
ToolLlama-256.1349.2134.7049.9550.9253.7721.3146.36
ToolLlama54.6049.9651.3751.5549.0861.3231.1549.70
ToolGen56.1352.2047.5453.2850.9262.2634.4251.51

5.2 Resultados

La tabla 4 muestra el rendimiento de la evaluación de extremo a extremo de cada modelo en dos entornos: utilizando la herramienta real (G.T.) y el recuperador (R.). En el entorno G.T., ToolGen alcanza una puntuación SoPR media de 54,19, superando a GPT-3.5 y ToolLlama, y ToolGen alcanza la puntuación SoWR más alta de 49,70. ToolGen sigue manteniendo el liderazgo en el entorno Retriever, con una puntuación SoPR media de 53,28 y SoWR de 51,51. ToolLlama muestra un rendimiento competitivo, superando a la herramienta real en algunas instancias individuales. ToolLlama demostró competitividad, superando a ToolGen en algunas instancias individuales. en el Apéndice G se presenta un estudio de ablación de ToolGen de extremo a extremo.

Tabla 5: Evaluación de extremo a extremo de distintos métodos de indexación.

Métodos de indexaciónSoPRSoWR
I1I2I3Avg.I1I2I3Avg
índice numérico34.7629.8746.9935.4525.7733.0229.5128.79
índice jerárquico50.2045.6032.7945.5038.0443.4029.5138.18
indexación semántica58.7945.2844.8151.8749.6957.5526.2347.88
índice atómico58.0856.1344.8155.0047.8557.5529.5147.58

5.3 Comparación de los métodos de indexación

De forma similar a la comparación de los métodos de indexación para la tarea de recuperación (Sección 4.3 ), la Tabla 5 muestra una comparación de los distintos métodos de indexación en la tarea de agente de extremo a extremo. En esta configuración, se elimina la descodificación restringida, lo que permite al agente generar libremente Pensamiento, Acción y Parámetros. A partir de los resultados, el método de indexación atómica es el que mejor funciona de los cuatro métodos de indexación. Atribuimos esto a las mayores tasas de fantasmas de los otros métodos, como se discute en la Sección 5.4.

ToolGen:通过生成实现统一的工具检索和调用

Figura 4: Muestra la tasa de fantasmas de distintos modelos al generar herramientas inexistentes. ToolGen no genera herramientas inexistentes cuando utiliza decodificación restringida. Sin embargo, sin esta restricción, ToolGen genera 7% tokens de herramientas inexistentes en la fase de generación de acciones cuando se utiliza la indexación atómica, y el índice de ilusión es mayor cuando se utiliza la indexación semántica. Para ToolLlama y GPT-3.5, la ilusión se produce incluso si se proporcionan cinco herramientas reales en la sugerencia. Si no se especifica ninguna herramienta en la sugerencia, ToolLlama genera nombres de herramientas inexistentes por encima de 50%.

5.4 Alucinaciones

Evaluamos la situación fantasma del modelo en la generación de herramientas en un escenario de agente de extremo a extremo. Para ello, introducimos consultas con un formato coherente con el entrenamiento del modelo. En concreto, para ToolGen, introducimos directamente la consulta y pedimos al modelo que genere la respuesta según el paradigma del agente ToolGen (es decir, Pensamiento, Herramienta y Parámetros en orden). Probamos la descodificación de acciones sin las restricciones de búsqueda de paquetes descritas en la sección 3.6. Para ToolLlama y GPT-3.5, introdujimos consultas e incluimos 5 herramientas reales. En todas las configuraciones, informamos de la proporción de herramientas no presentes en el conjunto de datos entre las generadas en todas las acciones de generación de herramientas. La figura 4 ilustra la tasa fantasma de herramientas inexistentes generadas por distintos modelos. Como puede verse en la figura, ToolLlama y GPT-3.5 siguen siendo propensos a generar nombres de herramientas inexistentes a pesar de que sólo se proporcionan cinco herramientas reales. En cambio, ToolGen evita por completo las alucinaciones gracias a su diseño de descodificación restringida.

6 Conclusiones

En este artículo, presentamos ToolGen, un marco de modelado de grandes lenguajes (LLM) que unifica la recuperación y ejecución de herramientas mediante la incorporación de tokens virtuales específicos de herramientas en un vocabulario modelo, transformando así la interacción con herramientas en una tarea generativa. Al incluir un proceso de entrenamiento en tres fases, ToolGen permite a los LLM recuperar y ejecutar herramientas de forma eficiente en escenarios reales. Este enfoque unificado establece un nuevo punto de referencia para agentes de IA escalables y eficientes capaces de manejar grandes bibliotecas de herramientas. De cara al futuro, ToolGen abre la puerta a la integración de tecnologías avanzadas como el razonamiento de cadena de pensamiento, el aprendizaje por refuerzo y ReAct, mejorando aún más la autonomía y versatilidad de los LLM en aplicaciones del mundo real.

Referencias

  • Asai et al. (2023) ↑Akari Asai, Zeqiu Wu, Yizhong Wang, Avirup Sil, y Hannaneh Hajishirzi.Self-rag: Learning to retrieve, generate, and critique a través de la autorreflexión, 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, Chelsea 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 y Brianna Zitkovich.Rt-2: Vision-language-action models transfer web knowledge to control robótico, 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 y Dario Amodei.Language models are few-shot learners.En Hugo Larochelle, Marc'Aurelio Ranzato, Raia Hadsell, Maria-Florina Balcan y Hsuan-Tien Lin (eds.). Avances en Sistemas de Procesamiento de Información Neuronal 33: Conferencia Anual sobre Sistemas de Procesamiento de Información Neuronal 2020, NeurIPS 2020, del 6 al 12 de diciembre, 2020, virtual2020.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 y Shunyu Yao.Fireact: Toward language agent fine- agente lingüístico.arXiv preprint arXiv:2310.05915, 2023a.
  • Chen et al. (2023b)↑Jiangui Chen, Ruqing Zhang, Jiafeng Guo, Maarten de Rijke, Wei Chen, Yixing Fan y Xueqi Cheng.Continual Learning for Generative Recuperación sobre corpus dinámicos. Actas de la 32ª Conferencia Internacional ACM sobre Gestión de la Información y el ConocimientoCIKM '23, pp. 306-315, Nueva York, NY, EE.UU., 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 y Benyou Wang.Smurfs: Leveraging multiple proficiency agents with context-efficiency for tool planificación de herramientas, 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 y 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 y Feng Zhao.Agent-flan: designing data and métodos de ajuste eficaz de agentes para grandes modelos lingüísticos, 2024c.URL https://arxiv.org/abs/2403.12881.
  • Dao (2024)↑Tri Dao.FlashAttention-2: Atención más rápida con mejor paralelismo y partición del trabajo.En Conferencia Internacional sobre el Aprendizaje de Representaciones (ICLR), 2024.
  • Dao et al. (2022)↑Tri Dao, Daniel Y. Fu, Stefano Ermon, Atri Rudra y Christopher Ré.FlashAttention: fast and memory-efficient exact attention with IO-awareness.En Avances en sistemas de procesamiento neuronal de la información (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. La manada de modelos llama 3.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 y Yang Liu.StableToolBench: Towards 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 y Zhiting Hu.Toolkengpt: Augmenting frozen language models with massive tools via tool En Alice Oh, Tristan Naumann, Amir Globerson, Kate Saenko, Moritz Hardt y Sergey Levine (eds.) Avances en Sistemas de Procesamiento de Información Neuronal 36: Conferencia Anual sobre Sistemas de Procesamiento de Información Neuronal 2023, NeurIPS 2023, Nueva Orleans, LA, EE.UU., 10 - 16 de diciembre de 2023 EE.UU., 10 - 16 de diciembre de 2023URL 2023 http://papers.nips.cc/paper_files/paper/2023/hash/8fd1a81c882cd45f64958da6284f4a3f-Abstract-Conference.html.
  • Järvelin & Kekäläinen (2002)↑Kalervo Järvelin y Jaana Kekäläinen.Cumulated gain-based evaluation of ir techniques.ACM Transactions on Information Systems (TOIS) (en inglés), 20(4):422-446, 2002.
  • Karpukhin et al. (2020)↑Vladimir Karpukhin, Barlas Oguz, Sewon Min, Patrick Lewis, Ledell Wu, Sergey Edunov, Danqi Chen y Wen-tau Yih.Dense passage passage retrieval for open-domain question answering. In Bonnie Webber, Trevor Cohn, Yulan He, and Yang Liu (eds.) Actas de la Conferencia 2020 sobre Métodos Empíricos en el Procesamiento del Lenguaje Natural (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 y Kilian Q. Weinberger.Incdsi: Incrementally updatable document En Andreas Krause, Emma Brunskill, Kyunghyun Cho, Barbara Engelhardt, Sivan Sabato y Jonathan Scarlett (eds.). Conferencia Internacional sobre Aprendizaje Automático, ICML 2023, 23-29 de julio de 2023, Honolulu, Hawai, EE.UU.volumen 202 de Actas de investigación sobre aprendizaje automático, pp. 17122-17134. 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. Agentbench. Evaluating llms as agents.In Duodécima Conferencia Internacional sobre el Aprendizaje de Representaciones, 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 y Donald Metzler. DSI++: Actualización transformador En Houda Bouamor, Juan Pino y Kalika Bali (eds.). Actas de la Conferencia 2023 sobre Métodos Empíricos en el Procesamiento del Lenguaje Natural, pp. 8198-8213, Singapur, 2023. Association for Computational Linguistics. doi: 10.18653/v1/2023.emnlp-main.510.URL https://aclanthology.org/2023.emnlp-main.510.
  • OpenAI (2024)↑Informe técnico OpenAI.Gpt-4, 2024.URL https://arxiv.org/abs/2303.08774.
  • Patil et al. (2023) ↑Shishir G. Patil, Tianjun Zhang, Xin Wang, y 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 y Huajun Chen.Autoact. Aprendizaje automático de agentes desde cero para la GC mediante autoplanificación, 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 y Maosong Sun. Runchu Tian, Ruobing Xie, Jie Zhou, Mark Gerstein, Dahai Li, Zhiyuan Liu y Maosong Sun.ToolLLM: Facilitating Large Language Models to Master 16000+ API del mundo real, 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 y Ji-Rong Wen.Aprendizaje de herramientas con grandes modelos lingüísticos. Aprendizaje de herramientas con grandes modelos lingüísticos: estudio.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 parámetros, 2020.URL https://arxiv.org/abs/1910.02054.
  • Robertson et al. (2009)↑Stephen Robertson, Hugo Zaragoza, et al. The probabilistic pertinencia marco: Bm25 y más allá.Fundamentos y Tendencias® en Recuperación de Información, 3(4):333-389, 2009.
  • Schick et al. (2023)↑Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda y Thomas Scialom.Toolformer: los modelos lingüísticos pueden enseñarse a sí mismos a utilizar herramientas, 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 y Fei Huang.Small llms are weak tool aprendices: un agente multi-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 verbal.En Actas de la 37ª Conferencia Internacional sobre Sistemas de Procesamiento Neuronal de la Información, 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 y Zhaochun Ren. Ren, Learning to tokenise for generative retrieval, Alice Oh, Tristan Naumann, Amir Globerson, Kate Saenko, Moritz Hardt y Sergey Levine (eds.). Avances en Sistemas de Procesamiento de Información Neuronal 36: Conferencia Anual sobre Sistemas de Procesamiento de Información Neuronal 2023, NeurIPS 2023, Nueva Orleans, LA, EE.UU., 10 - 16 de diciembre de 2023 EE.UU., 10 - 16 de diciembre de 2023URL 2023 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 y Guillaume Lample.Llama: open and efficient foundation modelos de lenguaje, 2023.URL https://arxiv.org/abs/2302.13971.
  • Wang et al. (2024)↑Renxi Wang, Haonan Li, Xudong Han, Yixuan Zhang, y 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 y 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, y A. Oh (eds.). Avances en Sistemas de Procesamiento de Información Neuronal 35: Conferencia Anual sobre Sistemas de Procesamiento de Información Neuronal 2022, NeurIPS 2022, Nueva Orleans, LA, EE.UU., 28 de noviembre - 9 de diciembre de 2022 Nueva Orleans, LA, EE.UU., 28 de noviembre - 9 de diciembre de 20222022.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 y Denny Zhou.Chain-of-thought prompting elicits reasoning in large language models, 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 y Chi Wang. Awadallah, Ryen W White, Doug Burger y 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, y Bin Wang.ToolPlanner: a Tool Augmented LLM for Multi Granularity Instructions with Path Planning y retroalimentación, 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.Approximate nearest neighbour negative contrastive learning for dense text retrieval.En neighbour negative contrastive learning for dense text retrieval.In 9ª Conferencia Internacional sobre Representaciones de Aprendizaje, ICLR 2021, Virtual Event, Austria, 3-7 de mayo de 2021. OpenReview.net, 2021.URL https://openreview.net/forum?id=zeFrfgyZln.
  • Xu et al. (2024)↑Qiancheng Xu, Yongqi Li, Heming Xia y 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 y Yuan Cao.ReAct: Synergising reasoning and acting in modelos lingüísticos.En Conferencia Internacional sobre el Aprendizaje de Representaciones (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 In Lun-Wei Ku, Andre Martins, and Vivek Srikumar (eds.) Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volumen 1: Long Papers), pp. 12380-12403, Bangkok, Tailandia, agosto de 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 y Jie Tang.Agenttuning: enabling generalised agent abilities para sistemas de información, 2023.

Un ejemplo de herramienta real

busque 5 Se muestra un ejemplo de una herramienta real. Cada herramienta contiene varias API. En nuestros experimentos se utilizan los siguientes campos: "tool_name" es el nombre de la herramienta. "tool_description" describe información sobre la herramienta, como qué hace. En cada API, "name" es el nombre de la API. "description" describe información sobre la API. "method" es el método http que llama a la API. "required_parameters" son los parámetros que deben rellenarse al llamar a la API. "optional_parameters" se puede utilizar para establecer parámetros adicionales (opcionales).

{
"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":[],
}
]
}
ToolGen:通过生成实现统一的工具检索和调用

Figura 5: Ejemplo de una herramienta real. La herramienta contiene una API y se han eliminado los campos innecesarios para simplificar.

B Aplicación de la virtualización de herramientas

ToolGen utiliza un único token para representar una herramienta, lo que demuestra su fortaleza en la recuperación e invocación de herramientas. También hemos introducido otros métodos para indexar herramientas, como el semántico, el numérico y el jerárquico. A continuación se describe detalladamente cómo implementamos cada tipo de indexación.

atómica

La indexación es el método que utilizamos en ToolGen. A diferencia de otros métodos, utiliza un único token como herramienta y no falsifica una herramienta que no existe. Utilizamos <> para combinar el nombre de la herramienta y el nombre de la API en un único token. Por ejemplo, en el apéndice A El ejemplo de esta sección da como resultado un Token de <>.

significado de las palabras

El índice asigna a cada herramienta un nombre utilizado en ToolBench, que también es una combinación del nombre de la herramienta y del nombre de la API. Sin embargo, el nombre puede desglosarse en múltiples tokens para que el modelo pueda percibir su significado semántico. En el ejemplo del Apéndice A, la asignación resultante es get_video_details_for_youtube_hub.

numérico

El índice asigna a cada herramienta un número único. Empezamos obteniendo una lista de todas las herramientas, que tiene unas 47.000, y para todas ellas utilizamos un número de cinco dígitos, separados por espacios, para representar la herramienta. Si el ejemplo del Apéndice A es el elemento 128 de la lista, utilizamos 0 0 0 0 1 2 8 para representar la herramienta. Dado que el léxico Llama-3 codifica cada número

capas

también asigna cada herramienta a un número. A diferencia del índice numérico, inyectamos información estructural en la representación de las herramientas mediante la agrupación iterativa. En cada iteración, agrupamos las herramientas en diez conglomerados, a cada uno de los cuales se le asigna un número del 0 al 9. Para cada conglomerado, repetimos el proceso de agrupación hasta que sólo queda una herramienta. Para cada grupo, repetimos el proceso de agrupación hasta que sólo hay una herramienta en ese grupo. Estos pasos forman un árbol de agrupación. Vamos de la raíz a los números de las hojas como representación de las herramientas en esa hoja. A los ejemplos del Apéndice A se les puede asignar un número mayor de cinco dígitos, como 0 1 2 2 3 3 3.

C Detalles de la búsqueda de restricciones

Cuando recuperamos y completamos tareas de agente de extremo a extremo, utilizamos la búsqueda restringida de paquetes para restringir las operaciones generadas a tokens de herramientas válidos. los pasos detallados se describen en el Algoritmo 1. La idea básica es restringir el espacio de búsqueda durante el paso de búsqueda de paquetes. Para ello, primero construimos un árbol de diccionario disjunto, en el que cada nodo representa un identificador de token de herramienta y los hijos de ese nodo son todos los identificadores factibles que siguen al identificador actual. no factibles, lo que obliga a muestrear o buscar posibles ID.

Para la recuperación, puede aplicarse directamente durante la generación. Para la tarea de agente de extremo a extremo, como descomponemos el paso de razonamiento en tres rondas de diálogo, podemos detectar fácilmente cuándo ToolGen necesita generar una acción y, por tanto, aplicar la restricción. La figura 6 muestra un ejemplo de razonamiento de extremo a extremo para ToolGen, en el que no hay ninguna herramienta asociada que ToolGen pueda elegir. Sólo tiene que generar el ToolToken y completar la tarea.

Tabla 6: Estadísticas del conjunto de datos para las tres etapas de formación. En el caso de la memoria de herramientas, hay algunos duplicados, lo que resulta en un tamaño de muestra ligeramente superior al número de herramientas que utilizamos.

conjunto de datosmemoria de herramientasBuscar formaciónPuesta a punto del agente de extremo a extremo
I1I2I3completo
#num49,936194,086222,78372,833489,702183,336
系统:您是一个 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 - 特别说明:菜单可能会更改,价格也可能会变动。请向场馆确认最新信息。"}

ToolGen:通过生成实现统一的工具检索和调用Figura 6: Ejemplo de razonamiento con ToolGen. En primer lugar, se da un aviso del sistema, sin ninguna herramienta asociada. A continuación, el usuario realiza una consulta sobre la tarea, ToolGen genera una idea y, a continuación, utilizamos el modelo de consulta sobre la función del usuario para generar una acción. Tras generar la acción, volvemos a utilizar al usuario para que proporcione un documento de herramienta. El modelo generará entradas de herramienta basadas en esta documentación.

E Prueba de ablación

La Tabla 7 muestra los resultados de ablación para la evaluación de extremo a extremo. Para instrucciones no vistas, el Agente ToolGen tiene un rendimiento ligeramente mejor sin entrenamiento de memoria o recuperación de herramientas. Sin embargo, para herramientas no vistas, tanto SoPR como SoWR disminuyen sin las dos primeras etapas de entrenamiento. Esto sugiere que las dos primeras etapas de entrenamiento juegan un papel en la capacidad de generalización de ToolGen, mientras que el entrenamiento de recuperación es más importante que la memoria de herramientas.

Tabla 7: Resultados de ablación de la evaluación integral de ToolGen. Aquí Inst. representa consultas no vistas (comandos) y Tool. y Cat. representan herramientas no vistas durante el entrenamiento.

modelizaciónSoPRSoWR
I1-Inst.I2-Inst.I3-Inst.Avg.I1-Inst.I2-Inst.I3-Inst.Avg.
ToolGen54.6052.3643.4451.8250.3154.7226.2347.28
sin entrenamiento de recuperación56.9546.7050.2752.4249.6950.9434.4347.27
sin memorización56.0347.9657.3853.6949.0859.4334.4349.70
I1-Tool.I1-Cat.I2 Cat.Avg.Herramienta I1I1-Cat.I2 Cat.Avg.
ToolGen56.5449.4651.9652.6640.5139.8737.9039.53
sin entrenamiento de recuperación49.4740.3137.9042.8436.7130.0736.2934.18
sin memorización58.8646.1949.8751.7037.3438.5642.7439.32

F Capacidad de generalización

Para ToolGen Agent, medimos el rendimiento del modelo en consultas sobre herramientas no entrenadas. La tabla 8 muestra la evaluación completa del modelo con herramientas no vistas. El rendimiento de ToolGen Agent es inferior al de ToolLlama, lo que también sugiere una generalización deficiente al completar toda la tarea. El problema de la generalización es frecuente en la recuperación generativa y está fuera del alcance de este artículo. Por lo tanto, lo dejamos para futuras investigaciones.

Tabla 8: Resultados de generalización de ToolGen. Probamos y comparamos el rendimiento de ToolGen con otros modelos en consultas que requerían herramientas no vistas durante el entrenamiento.

modelizaciónestablecerSoPRSoWR
I1-Tool.I1-Cat.I2 Cat.Avg.Herramienta I1I1-Cat.I2 Cat.Avg
GPT-3.5GT.58.9060.7054.6058.07----
ToolLlamaGT.57.3858.6156.8557.6843.0450.3154.8449.04
ToolGenGT.52.3240.4639.6547.6739.2438.5640.3239.30
GPT-3.5recuperar (datos)57.5953.0546.5152.7846.2054.2554.8151.58
ToolLlamarecuperar (datos)57.7061.7645.4354.9648.7350.9844.3548.30
ToolGen56.5449.4651.9652.6640.5139.8737.9039.53

Adaptación de los datos de ToolBench a ToolGen

Nuestros datos ToolGen se adaptan y transforman a partir de los datos de ToolBench. En concreto, utilizamos documentos de herramientas como datos para el entrenamiento de la memoria de herramientas, donde las entradas son documentos de herramientas y las salidas son los Token correspondientes.

Para el entrenamiento de la recuperación, utilizamos datos anotados para la recuperación de herramientas en ToolBench, donde una consulta se anota con múltiples herramientas relacionadas. Tomamos la consulta como entrada y convertimos las herramientas relevantes en tokens virtuales, que luego se utilizan como salida del entrenamiento de recuperación.

Para el ajuste de extremo a extremo del smartbody, utilizamos trayectorias de interacción como fuente con las siguientes transformaciones:(1) Cada trayectoria contiene herramientas disponibles a partir de las sugerencias del sistema que pueden utilizarse para resolver consultas. Al completar una tarea, ToolLlama se basa en las herramientas recuperadas en las sugerencias del sistema para resolver la tarea, mientras que ToolGen puede generar herramientas directamente. Por lo tanto, eliminamos las herramientas de las sugerencias del sistema. (2) Sustituimos todos los nombres de herramientas de la trayectoria por la correspondiente herramienta virtual Token.(3) En la trayectoria original, el Modelo Corporal Inteligente genera Pensamiento, Acción y Entrada de Acción (también conocido como ReAct) secuencialmente. Descomponemos todo el ReAct en tres rondas de diálogo. En la primera ronda, el modelo de cuerpo inteligente genera un Pensamiento y utilizamos al usuario para incitar al modelo a generar una Acción. En la segunda ronda, el modelo genera acciones, es decir, fichas de herramientas virtuales, y después obtenemos los documentos correspondientes a estas fichas para que el modelo sepa qué parámetros especificar. En la tercera ronda, el modelo genera parámetros para la herramienta.

El número de muestras de cada conjunto de datos se muestra en la Tabla 6. Las muestras para el entrenamiento de memoria y recuperación de herramientas se muestran en la Fig. 7. Las muestras para el ajuste de inteligencias de extremo a extremo se muestran en la Fig. 8.

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

Fig. 7: Ejemplo de conjunto de datos para el entrenamiento de memoria y recuperación de herramientas. Utilizamos roles de usuario para representar las entradas y roles de asistente para representar las salidas.

# 端到端代理调优
系统:
您是一个 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"
}

¡! [[Imagen pegada 20241027190429.png]]

Figura 8: Ejemplo de ajuste de agentes de extremo a extremo.

© declaración de copyright

Artículos relacionados

Sin comentarios

Debe iniciar sesión para participar en los comentarios.
Acceder ahora
ninguno
Sin comentarios...