Resumo Técnico: Benchmarking de Geração de Código de Integração de Web API

Declaração do Problema

A integração de Web API é um componente fundamental da infraestrutura de software moderna, mas escrever o código correto para invocar essas APIs continua sendo uma tarefa desafiadora e tediosa para os desenvolvedores. Embora os Grandes Modelos de Linguagem (LLMs) tenham demonstrado um potencial significativo na automação do desenvolvimento de software, sua eficácia específica na geração de código de invocação de Web API permanece amplamente inexplorada. Diferente das chamadas de funções locais, as invocações de Web API envolvem uma sintaxe complexa, incluindo métodos HTTP específicos, URLs parametrizadas, corpos de requisição, cabeçalhos e parâmetros de consulta, que são frequentemente documentados em especificações externas (ex: OpenAPI) que nem sempre estão acessíveis dentro da janela de contexto do modelo.

A questão central de pesquisa abordada é: Quão correto é o código de invocação de Web API gerado por LLMs, e quais tipos de erros são comumente presentes em tal código?

Metodologia

Para responder a esta questão, os autores introduzem o WAPIIBench, um novo conjunto de dados e um pipeline de avaliação projetado para avaliar sistematicamente as capacidades dos LLMs neste domínio.

1. Criação do Conjunto de Dados (WAPIIBench)

O conjunto de dados consiste em 395 pares de tarefa–configuração derivados de quatro APIs do mundo real que aderem ao padrão OpenAPI: Asana, Google Calendar, Google Sheets e Slack Web.

• Síntese: Ao contrário da coleta de fontes de repositórios existentes (que frequentemente carecem de descrições de tarefas inequívocas), os autores sintetizaram as tarefas usando o Gemini 1.5 Pro. O modelo recebeu especificações completas do OpenAPI e instruções detalhadas para gerar uma descrição de tarefa em linguagem natural ($t$) e uma configuração de requisição correspondente de verdade fundamental ($c$).
• Validação: Os dados gerados passaram por uma rigorosa curadoria automatizada e manual para garantir que cada tarefa tivesse uma configuração única e solucionável e que os argumentos fossem corretamente refletidos.
• Estrutura: Cada amostra representa um endpoint de API, capturando o método HTTP, a URL e os argumentos (corpo, cabeçalhos, parâmetros de consulta).

2. Pipeline de Avaliação

A avaliação segue um processo de quatro estágios:

1. Geração de Código: Os LLMs recebem a tarefa de completar um código inicial (JavaScript usando a biblioteca Axios) com base em uma descrição de tarefa. Dois setups foram testados:
   • Preenchimento Total (Full Completion): O modelo deve gerar o método HTTP, a URL e todos os argumentos.
   • Preenchimento de Argumentos (Argument Completion): O modelo recebe o método e a URL corretos e deve gerar apenas os argumentos.
2. Execução de Código: O código gerado é executado em um ambiente controlado e isolado (Mock) que intercepta as requisições de saída. Esta abordagem prioriza a corretude funcional sobre a similaridade sintática, capturando a configuração de requisição real ($c'$) enviada pelo código.
3. Análise de Corretude: A configuração capturada ($c'$) é comparada com a verdade fundamental ($c$) e validada contra a especificação da API ($s$).
4. Métricas: O estudo utiliza métricas detalhadas, incluindo:
   • Implementações Corretas: Porcentagem de códigos executáveis que correspondem à verdade fundamental.
   • Implementações Ilegais: Código que viola a especificação da API.
   • Precisão de URL/Método: Corretude de endpoints e métodos HTTP.
   • Precisão/Recall de Argumentos: Exatidão de nomes e valores de parâmetros.

3. Modelos Avaliados

O benchmark avaliou 21 LLMs de código aberto de última geração (incluindo StarCoder, DeepSeek-Coder, Qwen-Coder, Code Llama e Llama 3.1) juntamente com modelos comerciais (GPT-4o e GPT-4o mini) para estabelecer linhas de base de desempenho.

Principais Resultados

Os experimentos revelam que gerar código de invocação de Web API correto é um desafio significativo para os atuais LLMs, mesmo para os modelos de código aberto mais capazes.

• Corretude Geral: Nenhum dos modelos de código aberto avaliados resolveu mais de 40% das tarefas.
  • No setup de Preenchimento Total, o melhor modelo de código aberto (Code Llama 70B) alcançou 30% de corretude, enquanto o GPT-4o atingiu 60%.
  • No setup de Preenchimento de Argumentos (onde o endpoint é conhecido), o Code Llama 70B melhorou para 40%, e o GPT-4o atingiu 77%.
• Tipos de Erro:
  • Endpoints Alucinados: Um modo principal de falha é a geração de URLs incorretas ou inexistentes. Até 39% das URLs eram ilegais no setup de preenchimento total.
  • Erros de Argumentos: Os modelos frequentemente alucinam nomes de parâmetros (até 31% de argumentos ilegais) ou omitem argumentos obrigatórios.
  • Falhas de Execução: Vários modelos (ex: Qwen2.5-Coder, Llama 3.1) produziram código não executável no setup de preenchimento total devido a erros de sintaxe ou recusa em completar o código, resultando em métricas de 0% de corretude para esses modelos.
• Comportamento dos Modelos:
  • Os modelos geralmente performam bem na previsão de métodos HTTP (GET/POST), mas têm dificuldade com a natureza irrestrita de URLs e argumentos.
  • Modelos maiores nem sempre superam os menores; em algumas famílias, variantes de tamanho médio performaram pior do que suas contrapartes menores e maiores.
  • O desempenho varia significativamente entre diferentes APIs, provavelmente correlacionando-se com a prevalência de APIs específicas nos dados de treinamento dos modelos.

Significância e Contribuições

O artigo apresenta três contribuições primárias para o campo da engenharia de software e IA:

1. Conjunto de Dados WAPIIBench: O primeiro conjunto de dados deste tipo contendo quase 400 pares de tarefas de invocação de Web API e resultados esperados através de quatro APIs do mundo real, especificamente projetado para análise de corretude baseada em execução.
2. Pipeline de Avaliação de Código Aberto: Um novo pipeline seguro e automatizado para avaliar modelos de geração de código em tarefas de Web API usando métricas detalhadas que distinguem entre corretude sintática, conformidade com a especificação e sucesso funcional.
3. Insights Empíricos: O estudo fornece a primeira evidência sistemática de que, embora os LLMs possuam algum conhecimento memorizado de especificações de API, eles têm dificuldade em sintetizar esse conhecimento em invocações corretas e em conformidade com a especificação sem contexto externo. A alta taxa de endpoints e argumentos alucinados destaca uma lacuna crítica na confiabilidade atual dos modelos para integração de API em nível de produção.

Os autores concluem que, embora os LLMs mostrem promessa, limitações significativas permanecem. Eles enfatizam a necessidade de integrar técnicas de garantia de qualidade (como geração aumentada por recuperação, ajuste fino ou decodificação restrita) nos fluxos de trabalho de geração de código impulsionados por IA para garantir a correção e a confiabilidade do código de integração de Web API. O benchmark serve como uma fundação para pesquisas futuras visando melhorar essas capacidades.