Resumen Técnico: Mitigación de Errores en Invocaciones de API Web Generadas por LLM

Planteamiento del Problema

La integración de APIs web es fundamental para el desarrollo de software moderno, sin embargo, escribir código de invocación correcto sigue siendo un desafío significativo debido a las especificaciones complejas y evolutivas definidas en los documentos OpenAPI. Aunque los Modelos de Lenguaje de Gran Escala (LLMs) muestran promesa en la generación de código, estudios empíricos (específicamente el trabajo previo de los autores, WAPIIBench) han demostrado que frecuentemente generan invocaciones de API web incorrectas. Estos errores varían desde la selección de endpoints o métodos HTTP erróneos hasta la alucinación de argumentos ilegales o la omisión de parámetros requeridos.

Las técnicas de mitigación existentes, como la Generación Aumentada por Recuperación (RAG) y la Decodificación con Restricciones (CD), han mostrado éxito en otros dominios, pero siguen estando insuficientemente comprendidas para los desafíos específicos de las invocaciones de API web. A diferencia de las llamadas a funciones locales, las invocaciones de API web requieren la construcción de solicitudes HTTP explícitas (URL, método, encabezados, cuerpo) basadas en especificaciones externas que evolucionan independientemente del código del cliente. Este artículo aborda la pregunta abierta de cómo mitigar eficazmente estos tipos de errores específicos utilizando RAG y CD.

Metodología

Los autores proponen y evalúan sistemáticamente dos enfoques complementarios para mejorar el código de invocación de API web generado por LLM:

1. Generación Aumentada por Recuperación (RAG)

• Diseño del Recuperador: Los autores diseñaron un recuperador que procesa especificaciones OpenAPI. A diferencia del fragmentado de documentos estándar, dividen las especificaciones por endpoint, asegurando que cada fragmento contenga la documentación completa de un único endpoint (incluyendo referencias en línea, esquemas de seguridad y parámetros de ruta) para mantener el contexto.
• Embedding y Almacenamiento: Los fragmentos se incrustan utilizando el modelo all-MiniLM-L6-v2 y se almacenan en una base de datos vectorial Chroma. Para mejorar las tasas de acierto en la recuperación, cada endpoint se almacena con hasta cinco variantes de embedding diferentes (por ejemplo, variando la inclusión de listas de parámetros o esquemas de respuesta).
• Inyección de Prompt: La documentación del endpoint recuperada se formatea en una representación compacta inspirada en TypeScript (Listado 2) y se inyecta en el prompt del modelo. Un mecanismo de truncamiento gestiona los límites de longitud de contexto.

2. Decodificación con Restricciones (CD)

• Generación de Restricciones: Los autores desarrollaron un traductor automático que convierte las especificaciones OpenAPI en restricciones de expresiones regulares (regex). Estas restricciones están diseñadas para imponer un cumplimiento estricto con la especificación de la API durante la generación de tokens.
• Estructura Jerárquica: Las restricciones se organizan jerárquicamente:
  1. Método HTTP: Restringe la generación a los métodos soportados.
  2. URL: Limita las rutas válidas a aquellas definidas para el método seleccionado.
  3. Parámetros: Una vez identificado un endpoint, las restricciones limitan los parámetros a aquellos definidos para ese endpoint, manejando la opcionalidad, el orden y los tipos de datos.
• Implementación: Un motor de completado personalizado filtra dinámicamente la distribución de probabilidad del siguiente token del modelo, estableciendo en cero la probabilidad de los tokens que violan las restricciones. Esto asegura que las URLs, los métodos HTTP y los argumentos generados sean siempre conformes a la especificación.

3. Marco de Evaluación

El estudio utiliza dos conjuntos de datos:

• Conjunto de Datos Sintético: Derivado de WAPIIBench, cubre 395 tareas en cuatro APIs (Asana, Google Calendar, Google Sheets, Slack) con una verdad de campo precisa.
• Conjunto de Datos del Mundo Real: Un nuevo conjunto de datos construido mediante la minería de repositorios de GitHub por archivos JavaScript basados en Axios. Incluye 28 tareas en 11 APIs, reflejando patrones de uso comunes y contexto de código a nivel de archivo.

La evaluación mide la Corrección (código ejecutable que coincide con la verdad de campo), las Alucinaciones (endpoints o argumentos ilegales) y la Ejecutabilidad. Los experimentos se realizaron en 24 LLMs de código abierto (incluyendo CodeLlama, StarCoder, Qwen, DeepSeek) y dos modelos comerciales (GPT-4o, GPT-4o mini) en dos configuraciones: Completado Total (el modelo selecciona el endpoint y los argumentos) y Completado de Argumentos (el endpoint es proporcionado, el modelo selecciona los argumentos).

Contribuciones Clave

1. RAG Especializado para APIs: Un método de recuperación que procesa las especificaciones OpenAPI en fragmentos autónomos a nivel de endpoint, formateados específicamente para la eficiencia de tokens y la comprensión del LLM.
2. Generación Automática de Restricciones: Un sistema que traduce las especificaciones OpenAPI en restricciones basadas en regex, asegurando que el código generado sea estrictamente conforme a las definiciones de la API.
3. Conjunto de Datos del Mundo Real: Un nuevo conjunto de datos derivado de repositorios de GitHub para complementar los benchmarks sintéticos, ofreciendo escenarios de uso diversos y realistas.
4. Evaluación Empírica Sistemática: Un estudio exhaustivo de RAG, CD y su combinación a través de 24 modelos y dos conjuntos de datos distintos.

Resultados

Generación Aumentada por Recuperación (RAG)

• Reducción de Alucinaciones: RAG reduce consistentemente los endpoints y argumentos alucinados en ambos conjuntos de datos.
• Impacto en la Corrección: El efecto sobre la corrección general es ambivalente.
  • En la configuración de Completado Total, RAG mejora significativamente la corrección (por ejemplo, +113% en el conjunto de datos sintético) al ayudar a los modelos a seleccionar el endpoint correcto.
  • En la configuración de Completado de Argumentos, RAG a menudo disminuye la corrección (por ejemplo, -3% en el sintético) porque los modelos tienden a incluir en exceso parámetros opcionales encontrados en el contexto recuperado, incluso cuando no son requeridos para la tarea específica.
• Dependencia del Modelo: La utilidad de RAG depende altamente del modelo; algunos modelos aprovechan el contexto de manera efectiva, mientras que otros sufren de "uso excesivo de parámetros".

Decodificación con Restricciones (CD)

• Cero Alucinaciones: CD reduce de manera fiable las URLs, los métodos HTTP y los argumentos ilegales a cero en todos los modelos y conjuntos de datos.
• Mejora de la Corrección: CD mejora sustancialmente la corrección general. En el conjunto de datos sintético, produjo ganancias promedio de +209% (Completado Total) y +143% (Completado de Argumentos).
• Ejecutabilidad: CD permite que modelos que previamente fallaban al generar código sintácticamente válido produzcan implementaciones ejecutables, aunque aumenta ligeramente la tasa de código no ejecutable en algunos casos debido a la distorsión de la distribución de probabilidad.
• Consistencia: A diferencia de RAG, CD proporciona mejoras consistentes en casi todos los modelos.

Combinación (RAG + CD)

• Rendimiento Máximo: La combinación logra las puntuaciones de corrección absoluta más altas (por ejemplo, 73% en el conjunto de datos sintético para Completado de Argumentos).
• Compromisos: Aunque mantiene la garantía de cero alucinaciones de CD, la combinación es menos consistente que CD por sí sola. Para el Completado de Argumentos, el problema del "uso excesivo de parámetros" de RAG persiste, lo que conduce a ganancias promedio menores en comparación con CD solo en esta configuración específica.

Significado y Reclamaciones

El artículo afirma que la Decodificación con Restricciones es la técnica más robusta y fiable para las tareas de invocación de API web, ofreciendo garantías estrictas contra las violaciones de especificación y las alucinaciones. Argumenta que CD debe recomendarse incondicionalmente para este entorno.

Si bien RAG es efectivo para reducir las alucinaciones y ayudar en la selección de endpoints, su tendencia a inducir el uso excesivo de parámetros hace que su beneficio neto dependa altamente del modelo y la tarea específicos. Los autores concluyen que CD por sí solo es la opción más segura, a menos que la prioridad sea la máxima corrección y se haya validado el comportamiento del modelo específico con el contexto recuperado.

El trabajo subraya la necesidad de integrar técnicas de control de calidad (como CD) en los flujos de trabajo de generación de código impulsados por IA para lograr una fiabilidad práctica, particularmente para tareas que involucran especificaciones externas y evolutivas como las API web. Los autores posicionan su benchmark y metodología como una base para la investigación futura en otros criterios de calidad (por ejemplo, seguridad) y diferentes ecosistemas de programación.