Resumen Técnico: Evaluación de Referencia de la Generación de Código de Integración de API Web

Declaración del Problema

La integración de API web es un componente fundamental de la infraestructura de software moderna; sin embargo, escribir el código correcto para invocar estas API sigue siendo una tarea desafiante y tediosa para los desarrolladores. Si bien los Modelos de Lenguaje de Gran Escala (LLM) han demostrado un potencial significativo en la automatización del desarrollo de software, su eficacia específica en la generación de código de invocación de API web permanece en gran medida inexplorada. A diferencia de las llamadas a funciones locales, las invocaciones de API web implican una sintaxis compleja, que incluye métodos HTTP específicos, URLs parametrizadas, cuerpos de solicitud, encabezados y parámetros de consulta, que a menudo están documentados en especificaciones externas (por ejemplo, OpenAPI) que no siempre son accesibles dentro de la ventana de contexto del modelo.

La pregunta central de investigación abordada es: ¿Qué tan correcto es el código de invocación de API web generado por un LLM y qué tipos de errores son comunes en dicho código?

Metodología

Para responder a esta pregunta, los autores introducen WAPIIBench, un nuevo conjunto de datos y un pipeline de evaluación diseñado para evaluar sistemáticamente las capacidades de los LLM en este dominio.

1. Creación del Conjunto de Datos (WAPIIBench)

El conjunto de datos consta de 395 pares de tarea-configuración derivados de cuatro APIs del mundo real que cumplen con el estándar OpenAPI: Asana, Google Calendar, Google Sheets y Slack Web.

• Síntesis: A diferencia de la obtención de datos de repositorios existentes (que a menudo carecen de descripciones de tareas inequívocas), los autores sintetizaron las tareas utilizando Gemini 1.5 Pro. Se le proporcionó al modelo las especificaciones completas de OpenAPI e instrucciones detalladas para generar una descripción de tarea en lenguaje natural ($t$) y una configuración de solicitud correspondiente que sea la verdad de referencia ($c$).
• Validación: Los datos generados se sometieron a una rigurosa curación automatizada y manual para asegurar que cada tarea tuviera una configuración única y resoluble, y que los argumentos se reflejaran correctamente.
• Estructura: Cada muestra representa un endpoint de API, capturando el método HTTP, la URL y los argumentos (cuerpo, encabezados, parámetros de consulta).

2. Pipeline de Evaluación

La evaluación sigue un proceso de cuatro etapas:

1. Generación de Código: Se les pide a los LLM que completen un código inicial (JavaScript utilizando la biblioteca Axios) basado en una descripción de tarea. Se probaron dos configuraciones:
   • Completado Total (Full Completion): El modelo debe generar el método HTTP, la URL y todos los argumentos.
   • Completado de Argumentos (Argument Completion): Se le proporciona al modelo el método y la URL correctos, y este solo debe generar los argumentos.
2. Ejecución de Código: El código generado se ejecuta en un entorno controlado y aislado (Mock) que intercepta las solicitudes salientes. Este enfoque prioriza la corrección funcional sobre la similitud sintáctica, capturando la configuración de la solicitud real ($c'$) enviada por el código.
3. Análisis de Corrección: La configuración capturada ($c'$) se compara con la verdad de referencia ($c$) y se valida contra la especificación de la API ($s$).
4. Métricas: El estudio emplea métricas detalladas, que incluyen:
   • Implementaciones Correctas: Porcentaje de código ejecutable que coincide con la verdad de referencia.
   • Implementaciones Ilegales: Código que viola la especificación de la API.
   • Precisión de URL/Método: Corrección de los endpoints y los métodos HTTP.
   • Precisión/Exhaustividad de Argumentos: Exactitud de los nombres y valores de los parámetros.

3. Modelos Evaluados

El benchmark evaluó 21 LLM de código abierto de última generación (incluyendo StarCoder, DeepSeek-Coder, Qwen-Coder, Code Llama y Llama 3.1) junto con modelos comerciales (GPT-4o y GPT-4o mini) para establecer líneas base de rendimiento.

Resultados Clave

Los experimentos revelan que generar código de invocación de API web correcto es un desafío significativo para los LLM actuales, incluso para los modelos de código abierto más capaces.

• Corrección General: Ninguno de los modelos de código abierto evaluados resolvió más del 40% de las tareas.
  • En la configuración de Completado Total, el mejor modelo de código abierto (Code Llama 70B) alcanzó un 30% de corrección, mientras que GPT-4o llegó al 60%.
  • En la configuración de Completado de Argumentos (donde el endpoint es conocido), Code Llama 70B mejoró al 40%, y GPT-4o alcanzó el 77%.
• Tipos de Errores:
  • Endpoints Alucinados: Un modo de fallo principal es la generación de URLs incorrectas o inexistentes. Hasta el 39% de las URLs fueron ilegales en la configuración de completado total.
  • Errores de Argumentos: Los modelos frecuentemente alucinan nombres de parámetros (hasta un 31% de argumentos ilegales) o de omiten argumentos requeridos.
  • Fallos de Ejecución: Varios modelos (por ejemplo, Qwen2.5-Coder, Llama 3.1) produjeron código no ejecutable en la configuración de completado total debido a errores de sintaxis o por la negativa a completar el código, lo que resultó en métricas de corrección del 0% para esos modelos.
• Comportamiento de los Modelos:
  • Los modelos generalmente funcionan bien prediciendo métodos HTTP (GET/POST), pero tienen dificultades con la naturaleza no restringida de las URLs y los argumentos.
  • Los modelos más grandes no siempre superan a los más pequeños; en algunas familias, las variantes de tamaño medio funcionaron peor que sus contrapartes tanto más pequeñas como más grandes.
  • El rendimiento varía significativamente entre las diferentes APIs, probablemente correlacionándose con la prevalencia de APIs específicas en los datos de entrenamiento de los modelos.

Significado y Contribuciones

El artículo realiza tres contribuciones principales al campo de la ingeniería de software y la IA:

1. Conjunto de Datos WAPIIBench: El primer conjunto de datos de su tipo que contiene casi 400 pares de tareas de invocación de API web y resultados esperados a través de cuatro APIs del mundo real, diseñado específicamente para el análisis de corrección basado en ejecución.
2. Pipeline de Evaluación de Código Abierto: Un nuevo pipeline seguro y automatizado para evaluar modelos de generación de código en tareas de API web utilizando métricas detalladas que distinguen entre corrección sintáctica, cumplimiento de la especificación y éxito funcional.
3. Perspectivas Empíricas: El estudio proporciona la primera evidencia sistemática de que, si bien los LLM poseen cierto conocimiento memorizado de las especificaciones de las API, tienen dificultades para sintetizar este conocimiento en invocaciones correctas y que cumplen con la especificación sin contexto externo. La alta tasa de endpoints y argumentos alucinados resalta una brecha crítica en la fiabilidad de los modelos actuales para la integración de API en entornos de producción.

Los autores concluyen que, si bien los LLM muestran promesa, persisten limitaciones significativas. Enfatizan la necesidad de integrar técnicas de control de calidad (como la generación aumentada por recuperación, el ajuste fino o la decodificación restringida) en los flujos de trabajo de generación de código impulsados por IA para asegurar la corrección y la fiabilidad del código de integración de API web. El benchmark sirve como base para futuras investigaciones destinadas a mejorar estas capacidades.