Capacitar a un LLM para que llame a herramientas de manera confiable requiere conjuntos de datos que combinen las consultas de los usuarios con las cadenas correctas de uso de herramientas. Producir esos datos a escala ha sido lento y costoso. Un equipo de investigadores de Google, la Universidad de Tokio, RIKEN AIP y la Universidad de Tohoku presentan ToolGrad. El trabajo de investigación invierte el proceso habitual: primero cree una cadena de herramientas verificada y luego escriba la consulta. Los modelos Gemma-3 ajustados en 500 muestras de los datos resultantes alcanzan puntuaciones que se ubican junto a los modelos propietarios de frontera en la tabla de clasificación de llamadas de funciones de Berkeley.
¿Es desplegable? Sí. El código es Apache-2.0, el conjunto de datos ToolGrad-500 y los modelos 1B, 4B y 12B están en Hugging Face y hay un paquete PyPI.
El problema con la consulta de primera generación.
Los canales anteriores, como ToolBench y ToolACE, siguen una receta de consulta primero. El sistema toma muestras de un conjunto de API, solicita a un LLM que invente una instrucción de usuario plausible y luego envía un agente de búsqueda en profundidad (DFS) para encontrar una ruta de uso de herramientas que la satisfaga. La búsqueda no tiene garantía de éxito. Cuando llega a un callejón sin salida, el cálculo gastado en la exploración se desperdicia y la muestra se descarta. El artículo enmarca esto como una destilación de trayectorias valiosas a partir de una exploración de agentes compleja y a menudo fallida, que es inherentemente ineficiente.
ToolGrad invierte el orden. Primero construye una cadena de uso de herramientas real ejecutando API y luego anota esa cadena con una consulta de usuario coincidente. Una cadena de trabajo explícita es mucho menos ambigua que un mensaje hipotético, por lo que el paso de la cadena a la consulta requiere una única llamada de LLM.
Cuatro módulos en un bucle
Cada iteración ejecuta cuatro módulos en secuencia:
API Proposer reduce un conjunto de API de muestra a unos pocos candidatos que podrían ampliar el flujo de trabajo actual. Los API Executors ejecutan esos candidatos en paralelo y producen informes de ejecución detallados. API Selector revisa los informes, selecciona la llamada con mejor rendimiento y la agrega al flujo de trabajo. Su retroalimentación direccional es el gradiente textual. LLM Updater reescribe la consulta sintética del usuario y la respuesta de IA para que coincidan con el nuevo conjunto de API.
Al repetir el ciclo se obtiene una muestra: una consulta de usuario, un flujo de trabajo de API verificado y la respuesta final. La configuración predeterminada del repositorio ejecuta 10 iteraciones en 50 API de muestra por flujo de trabajo.
El equipo de investigación evaluó la generación de datos en la base de datos API de ToolBench, que contiene más de 16 000 API del mundo real, y comparó ToolGrad con el enfoque de consulta primero basado en DFS de ToolBench. Según el trabajo de investigación:
La tasa de aprobación aumentó del 63,8% (DFS) al 99,8% (ToolGrad). El uso de herramientas de verdad sobre el terreno por muestra aumentó de 2,1 a 3,4, lo que significa cadenas más largas. Los pasos de uso de herramientas por muestra cayeron de 34,3 a 20,0. Las invocaciones de LLM por muestra cayeron ligeramente, de 64,5 a 63,9.
El caso de error del 0,2 % se produjo cuando el agente no pudo obtener una respuesta exitosa de 3 API seleccionadas en las 10 iteraciones y guardó una muestra vacía.