Gorilla: Cómo el entrenamiento consciente de la recuperación reduce las alucinaciones de las API en los LLM del 78% al 11%

Leyendo el artículo de Gorilla (Patil et al., 2023, arXiv:2305.15334, NeurIPS 2024) porque se sitúa en la intersección de dos problemas con los que me topo constantemente: ¿cómo logramos que un agente LLM llame a la herramienta adecuada con los argumentos correctos, y cómo mantenemos esa capacidad vigente a medida que las API cambian? Las respuestas aquí son prácticas y las cifras sorprendentemente sólidas, pero los supuestos integrados en la evaluación merecen un escrutinio mayor del que suelen recibir.

El artículo

Gorilla, de Shishir G. Patil, Tianjun Zhang, Xin Wang y Joseph E. Gonzalez en UC Berkeley, aborda un modo de falla concreto: los LLM de última generación alucinan las llamadas a la API. Cuando se les pide escribir código que invoque una función de biblioteca específica, GPT-4 (a mediados de 2023) genera frecuentemente firmas de función de apariencia plausible pero incorrectas, modelos inexistentes o nombres de argumentos obsoletos. Gorilla es un modelo basado en LLaMA de 7 mil millones de parámetros ajustado específicamente para generar llamadas a la API precisas, entrenado con una técnica que los autores llaman Entrenamiento Consciente del Recuperador (RAT, por sus siglas en inglés). La idea es simple: durante el entrenamiento, se muestra al modelo la documentación de la API recuperada junto con la consulta del usuario, formateada como "Use esta documentación de API como referencia: <retrieved_API_doc_JSON>". Esto enseña al modelo tanto a leer la documentación como a confiar en el contexto recuperado por encima de su memoria paramétrica, una propiedad que rinde frutos en el momento de la inferencia cuando la documentación ha cambiado.

El conjunto de datos de evaluación, APIBench, cubre 925 API de HuggingFace Model Hub, 95 API de TorchHub y 696 API de TensorFlow Hub, con diez consultas sintéticas de seguimiento de instrucciones generadas por API mediante self-instruct. La métrica de evaluación es la coincidencia de subárboles AST: la llamada a la API generada se analiza y se comprueba su corrección funcional, lo que también permite, por primera vez en este entorno, una medición basada en principios de la tasa de alucinación.

Ideas clave

• RAT hace que la documentación sea legible en el momento de la inferencia. Al entrenar con prompts que incluyen documentación recuperada, Gorilla aprende a remitirse al texto recuperado en lugar de recordar detalles de la API desde sus pesos. Esto significa que el modelo se mantiene actualizado a medida que las API evolucionan sin necesidad de reentrenamiento.
• Precisión zero-shot: Gorilla 59–84%, GPT-4 18–39%. En TorchHub, Gorilla logra un 59.13% frente al 38.70% de GPT-4. En HuggingFace, es 71.68% frente a 19.80%. En TensorFlow Hub, 83.79% frente a 18.20%. El margen es mayor donde el espacio de la API es más diverso.
• La reducción de alucinaciones es lo más destacado. La tasa de alucinación de Gorilla es del 6.98% en TorchHub, 10.95% en HuggingFace y 5.40% en TensorFlow Hub. Las tasas de GPT-4 oscilan entre el 36.55% y el 78.65% en los mismos conjuntos de datos.
• El recuperador oráculo es el techo. Con el documento de referencia (ground-truth) recuperado (modo oráculo), la precisión alcanza el 67–94%. Este es el mejor caso teórico para cualquier sistema basado en RAG y la brecha entre Gorilla zero-shot y este techo es el margen disponible para la mejora del recuperador.
• Los recuperadores reales se quedan cortos. Cambiar del oráculo a GPT-Index en el momento de la evaluación degrada la precisión en un 29.20%; BM25 la degrada en un 52.27%. La robustez del modelo al ruido de recuperación es real, pero no ilimitada.
• La evaluación AST es generalizable. El enfoque de coincidencia de subárboles mide si la llamada generada es funcionalmente correcta, no solo sintácticamente similar. Esta es la métrica adecuada para cualquier tarea donde el resultado sea código que realmente se ejecutará.

Qué se mantiene y qué no

La afirmación central se sostiene: el ajuste fino en prompts aumentados con documentación mejora drásticamente la precisión de las llamadas a la API y reduce las alucinaciones. La metodología de evaluación AST es genuinamente novedosa y claramente mejor que la coincidencia de cadenas o la evaluación humana a escala. RAT es una idea limpia y reproducible.

De lo que soy escéptico es del alcance de la evaluación comparativa. Los tres conjuntos de datos (HuggingFace, TorchHub, TensorFlow Hub) son registros de modelos de ML con una estructura de API muy regular: se carga un modelo por nombre, posiblemente con algunos argumentos de palabras clave, y se llama a un método similar a predict. Las instrucciones se generan sintéticamente, lo que significa que la distribución de prueba está estrechamente relacionada con la distribución de entrenamiento. Un modelo ajustado sobre documentación de API de ML mediante self-instruct, evaluado en consultas de self-instruct para API de ML, no está siendo probado ante la dificultad que realmente aparece en producción: solicitudes ambiguas, flujos de trabajo de varios pasos, coerción de tipos de argumentos, autenticación, límites de velocidad o recuperación de errores.

La degradación de la recuperación también es mayor de lo que sugiere el planteamiento del artículo. Una caída del 52% en la precisión con la recuperación de BM25 es catastrófica. Si el recuperador que despliegas en producción se parece más a BM25 que a un oráculo, las ganancias se evaporan. Los autores reconocen esta brecha pero no ofrecen un camino para cerrarla.

Finalmente, el modelo en sí es un ajuste fino de LLaMA 7B. La comparación con GPT-4 zero-shot es impactante, pero la comparación no es del todo justa: GPT-4 no ha sido entrenado para usar documentación recuperada. Un GPT-4 aumentado con RAG con un prompt de sistema diseñado para leer documentos de API casi con seguridad cerraría considerablemente la brecha.

Por qué esto es importante para la IA financiera

El patrón RAT es directamente aplicable a los agentes de escritura de Beancount. Un agente de Beancount necesita invocar comandos de CLI (bean-query, bean-report), API de Python (beancount.loader, beancount.core) y el servicio FastAPI beancount-ledger, cada uno con semánticas de argumentos específicas que están documentadas pero no necesariamente en los datos de entrenamiento del modelo. El enfoque de Gorilla propone: recuperar el fragmento de documentación relevante en el momento de la inferencia, inyectarlo en el contexto y entrenar al modelo para que lo lea y lo siga.

Las cifras de alucinación son la señal más útil para un contexto financiero. Una tasa de alucinación del 10% en nombres de modelos de ML es molesta. Una tasa de alucinación del 10% en llamadas de mutación del libro mayor (nombres de cuenta incorrectos, códigos de moneda erróneos, signos de débito/crédito invertidos) es un problema de integridad. La implicación es que incluso un agente entrenado al estilo Gorilla necesita un validador en tiempo de ejecución antes de que se confirme cualquier escritura, de manera consistente con lo que CRITIC (LOG-012) mostró sobre la crítica interactiva con herramientas. El hallazgo de la degradación por recuperación refuerza esto: si la recuperación en el mundo real reduce la precisión a la mitad, la red de seguridad no puede ser solo la calidad de la recuperación.

La metodología de evaluación AST se traduce de forma natural. Las transacciones de Beancount tienen una estructura analizable, y verificar las directivas generadas contra un esquema utilizando la coincidencia AST es exactamente el tipo de validador ligero que podría ejecutarse en un hook de pre-commit o en un bucle del agente.

Qué leer a continuación

• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789) — extiende el problema de las llamadas a la API a 16,000 API REST reales con cadenas de uso de herramientas de varios pasos; aborda directamente la limitación de Gorilla de evaluar solo invocaciones únicas a registros de ML.
• The Berkeley Function Calling Leaderboard (BFCL) (OpenReview:2GmDdhBdDk, póster de NeurIPS 2024) — la evolución directa de Gorilla en una tabla de clasificación en vivo que rastrea cómo los modelos de frontera mejoran en la llamada a funciones con el tiempo; la V3 añade interacciones de múltiples turnos, la V4 añade búsqueda web de agentes.
• API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs — evalúa los LLM en 73 API a través de una gama más amplia de dominios, incluyendo finanzas y servicios web, con uso de herramientas de múltiples turnos; un complemento útil para el enfoque más estrecho de ML de APIBench.