Resumo Técnico: Mitigação de Erros em Invocações de Web API Geradas por LLM

Declaração do Problema

A integração de web APIs é fundamental para o desenvolvimento de software moderno, mas escrever código de invocação correto continua sendo um desafio significativo devido às especificações complexas e em constante evolução definidas em documentos OpenAPI. Embora os Grandes Modelos de Linguagem (LLMs) mostrem promessa na geração de código, estudos empíricos (especificamente o trabalho anterior dos autores, WAPIIBench) demonstraram que eles frequentemente geram invocações de web API incorretas. Esses erros variam desde a seleção de endpoints ou métodos HTTP errados até a alucinação de argumentos ilegais ou a omissão de parâmetros obrigatórios.

Técnicas de mitigação existentes, como Geração Aumentada por Recuperação (RAG) e Decodificação Restrita (CD), mostraram sucesso em outros domínios, mas permanecem insuficientemente compreendidas para os desafios específicos das invocações de web API. Ao contrário das chamadas de funções locais, as invocações de web API exigem a construção de requisições HTTP explícitas (URL, método, cabeçalhos, corpo) baseadas em especificações externas que evoluem independentemente do código do cliente. Este artigo aborda a questão em aberto de como mitigar efetivamente esses tipos específicos de erro usando RAG e CD.

Metodologia

Os autores propõem e avaliam sistematicamente duas abordagens complementares para melhorar o código de invocação de web API gerado por LLM:

1. Geração Aumentada por Recuperação (RAG)

• Design do Recuperador: Os autores projetaram um recuperador que processa especificações OpenAPI. Diferente do particionamento de documentos padrão, eles dividem as especificações por endpoint, garantindo que cada fragmento contenha a documentação completa de um único endpoint (incluindo referências embutidas, esquemas de segurança e parâmetros de caminho) para manter o contexto.
• Embedding e Armazenamento: Os fragmentos são transformados em vetores usando o modelo all-MiniLM-L6-v2 e armazenados em um banco de dados vetorial Chroma. Para melhorar as taxas de acerto da recuperação, cada endpoint é armazenado com até cinco variantes de embedding diferentes (por exemplo, variando a inclusão de listas de parâmetros ou esquemas de resposta).
• Injeção de Prompt: A documentação do endpoint recuperada é formatada em uma representação compacta, inspirada em TypeScript (Listagem 2), e injetada no prompt do modelo. Um mecanismo de truncamento lida com os limites de comprimento de contexto.

2. Decodificação Restrita (CD)

• Geração de Restrições: Os autores desenvolveram um tradutor automático que converte especificações OpenAPI em restrições de expressões regulares (regex). Essas restrições são projetadas para impor conformidade estrita com a especificação da API durante a geração de tokens.
• Estrutura Hierárquica: As restrições são organizadas hierarquicamente:
  1. Método HTTP: Restringe a geração aos métodos suportados.
  2. URL: Limita os caminhos válidos àqueles definidos para o método selecionado.
  3. Parâmetros: Uma vez identificado um endpoint, as restrições limitam os parâmetros àqueles definidos para aquele endpoint, lidando com opcionalidade, ordenação e tipos de dados.
• Implementação: Um mecanismo de completamento personalizado filtra dinamicamente a distribuição de probabilidade do próximo token do modelo, definindo como zero a probabilidade de tokens que violam as restrições. Isso garante que as URLs, métodos HTTP e argumentos gerados sejam sempre conformes à especificação.

3. Estrutura de Avaliação

O estudo utiliza dois conjuntos de dados:

• Conjunto de Dados Sintético: Derivado do WAPIIBench, cobrindo 395 tarefas em quatro APIs (Asana, Google Calendar, Google Sheets, Slack) com ground truth preciso.
• Conjunto de Dados do Mundo Real: Um novo conjunto de dados construído através da mineração de repositórios GitHub por arquivos JavaScript baseados em Axios. Inclui 28 tarefas em 11 APIs, refletindo padrões de uso comuns e o contexto de nível de arquivo.

A avaliação mede Corretude (código executável correspondendo ao ground truth), Alucinações (endpoints ou argumentos ilegais) e Executabilidade. Experimentos foram conduzidos em 24 modelos de código aberto (incluindo CodeLlama, StarCoder, Qwen, DeepSeek) e dois modelos comerciais (GPT-4o, GPT-4o mini) em dois setups: Completamento Total (o modelo seleciona o endpoint e os argumentos) e Completamento de Argumentos (o endpoint é fornecido, o modelo seleciona os argumentos).

Principais Contribuições

1. RAG Especializado para APIs: Um método de recuperação que processa especificações OpenAPI em fragmentos autossuficientes de nível de endpoint, formatados especificamente para eficiência de tokens e compreensão de LLMs.
2. Geração Automática de Restrições: Um sistema que traduz especificações OpenAPI em restrições baseadas em regex, garantindo que o código gerado seja estritamente conforme as definições da API.
3. Conjunto de Dados do Mundo Real: Um novo conjunto de dados derivado de repositórios GitHub para complementar benchmarks sintéticos, oferecendo cenários de uso diversos e realistas.
4. Avaliação Empírica Sistemática: Um estudo abrangente de RAG, CD e sua combinação em 24 modelos e dois conjuntos de dados distintos.

Resultados

Geração Aumentada por Recuperação (RAG)

• Redução de Alucinações: O RAG reduz consistentemente endpoints e argumentos alucinados em ambos os conjuntos de dados.
• Impacto na Corretude: O efeito na corretude geral é ambivalente.
  • No setup de Completamento Total, o RAG melhora significativamente a corretude (ex: +113% no conjunto de dados sintético) ao ajudar os modelos a selecionar o endpoint correto.
  • No setup de Completamento de Argumentos, o RAG frequentemente diminui a corretude (ex: -3% no sintético) porque os modelos tendem a incluir excessivamente parâmetros opcionais encontrados no contexto recuperado, mesmo quando não são necessários para a tarefa específica.
• Dependência de Modelo: A utilidade do RAG é altamente dependente do modelo; alguns modelos aproveitam o contexto de forma eficaz, enquanto outros sofrem de "uso excessivo de parâmetros".

Decodificação Restrita (CD)

• Zero Alucinações: O CD reduz de forma confiável URLs, métodos HTTP e argumentos ilegais para zero em todos os modelos e conjuntos de dados.
• Melhoria na Corretude: O CD melhora substancialmente a corretude geral. No conjunto de dados sintético, rendeu ganhos médios de +209% (Completamento Total) e +143% (Completamento de Argumentos).
• Executabilidade: O CD permite que modelos que anteriormente falhavam em gerar código sintaticamente válido produzam implementações executáveis, embora aumente ligeiramente a taxa de código não executável em alguns casos devido à distorção da distribuição de probabilidade.
• Consistência: Ao contrário do RAG, o CD fornece melhorias consistentes em quase todos os modelos.

Combinação (RAG + CD)

• Desempenho de Pico: A combinação atinge as pontuações absolutas mais altas de corretude (ex: 73% no conjunto de dados sintético para Completamento de Argumentos).
• Compromissos (Trade-offs): Embora mantenha a garantia de zero alucinação do CD, a combinação é menos consistente do que o CD sozinho. Para o Completamento de Argumentos, o problema do "uso excessivo de parâmetros" do RAG persiste, levando a ganhos médios menores em comparação ao CD sozinho neste setup específico.

Significância e Alegações

O artigo afirma que a Decodificação Restrita é a técnica mais robusta e confiável para tarefas de invocação de web API, oferecendo garantias rígidas contra violações de especificação e alucinações. Argumenta-se que o CD deve ser recomendado incondicionalmente para este cenário.

Embora o RAG seja eficaz na redução de alucinações e no auxílio à seleção de endpoints, sua tendência de induzir o uso excessivo de parâmetros torna seu benefício líquido altamente dependente do modelo e da tarefa específicos. Os autores concluem que o CD sozinho é a escolha mais segura, a menos que a máxima corretude seja a prioridade e o comportamento do modelo específico com o contexto recuperado tenha sido validado.

O trabalho ressalta a necessidade de integrar técnicas de garantia de qualidade (como o CD) nos fluxos de trabalho de geração de código impulsionados por IA para alcançar confiabilidade prática, particularmente para tarefas que envolvem especificações externas e evolutivas, como web APIs. Os autores posicionam seu benchmark e metodologia como uma fundação para pesquisas futuras em outros critérios de qualidade (ex: segurança) e diferentes ecossistemas de programação.