Selecionar idioma

Framework de Classificação de APIs e Geração de Dados Sintéticos com LLMs

Um sistema inovador que utiliza Modelos de Linguagem de Grande Porte para classificar entradas em linguagem natural em chamadas de API e gerar conjuntos de dados sintéticos para avaliação de modelos.
apismarket.org | PDF Size: 0.7 MB
Avaliação: 4.5/5
Sua avaliação
Você já avaliou este documento
Capa do documento PDF - Framework de Classificação de APIs e Geração de Dados Sintéticos com LLMs

1. Introdução

Este artigo aborda o desafio de tornar as Interfaces de Programação de Aplicações (APIs) de software mais acessíveis através da utilização de Modelos de Linguagem de Grande Porte (LLMs). A interação tradicional com APIs requer conhecimento técnico sobre estrutura, parâmetros e chamadas específicas, criando uma barreira para utilizadores não técnicos. O sistema proposto utiliza LLMs para duas funções principais: 1) Classificar entradas do utilizador em linguagem natural nas chamadas de API correspondentes, e 2) Automatizar a geração de conjuntos de dados sintéticos e específicos da tarefa para avaliar o desempenho dos LLMs em tarefas de classificação de APIs. Esta abordagem dupla visa reduzir a barreira de utilização do software, fornecendo simultaneamente uma ferramenta prática para os programadores avaliarem a adequação dos LLMs para a gestão personalizada de APIs.

2. Trabalhos Relacionados

A investigação baseia-se em trabalhos existentes em Processamento de Linguagem Natural (PLN) e engenharia de software, focando-se na ponte entre a linguagem humana e os comandos executáveis por máquina.

2.1 LLMs para Mapeamento de Linguagem Natural para API

Estudos anteriores exploraram o uso de modelos sequência-para-sequência e variantes do BERT ajustadas para mapear linguagem natural para código ou sequências de API. O advento de LLMs poderosos e de propósito geral, como o GPT-4, mudou o paradigma, permitindo um mapeamento mais flexível e contextual sem necessidade de treino extensivo específico da tarefa.

2.2 Geração de Dados Sintéticos em PLN

A geração de dados sintéticos, crucial para treino e avaliação quando os dados reais são escassos, evoluiu de modelos baseados em regras para geração alimentada por LLMs. Modelos como o GPT-4 podem produzir exemplos textuais diversos e contextualmente relevantes, o que é aproveitado neste trabalho para criar conjuntos de dados para funções de API específicas.

3. Framework Proposto

A inovação central é um framework unificado que lida tanto com a tarefa de classificação como com a criação do seu próprio benchmark de avaliação.

3.1 Arquitetura do Sistema

O sistema consiste em dois módulos interligados: o Módulo de Classificação e o Módulo de Geração de Dados Sintéticos. Um orquestrador central gere o fluxo de trabalho, recebendo as especificações da API como entrada e produzindo como saída uma chamada de API classificada ou um conjunto de dados de avaliação gerado.

3.2 Classificação de Linguagem Natural para API

Dada uma consulta em linguagem natural $q$ e um conjunto de possíveis chamadas de API $A = \{a_1, a_2, ..., a_n\}$, o LLM atua como um classificador $C$. O objetivo é encontrar a API $a_i$ que maximiza a probabilidade condicional: $a^* = \arg\max_{a_i \in A} P(a_i | q, \theta)$, onde $\theta$ representa os parâmetros do LLM. O sistema utiliza few-shot prompting com exemplos para orientar o modelo.

3.3 Pipeline de Geração de Conjuntos de Dados Sintéticos

Para uma função de API alvo, o módulo de geração utiliza um LLM (por exemplo, GPT-4-turbo) para criar um conjunto diversificado de consultas em linguagem natural $Q = \{q_1, q_2, ..., q_m\}$ que correspondem a essa API. O processo é orientado por prompts que especificam o propósito da API, os parâmetros e as variações desejadas na formulação, complexidade e intenção do utilizador.

4. Configuração Experimental & Resultados

4.1 Processo de Geração do Conjunto de Dados

Foram gerados conjuntos de dados de exemplo para múltiplas funções de API (por exemplo, obtenção de previsão meteorológica, consulta a base de dados, processamento de pagamentos) utilizando o GPT-4-turbo. Cada conjunto de dados continha centenas de consultas em linguagem natural emparelhadas com a etiqueta correta da chamada de API, cobrindo uma gama de paráfrases e expressões do utilizador.

4.2 Comparação de Desempenho dos Modelos

Vários LLMs foram avaliados nos conjuntos de dados gerados utilizando a precisão de classificação padrão.

GPT-4

0.996

Precisão

GPT-4o-mini

0.982

Precisão

Gemini-1.5

0.961

Precisão

LLaMA-3-8B

0.759

Precisão

4.3 Análise dos Resultados

Os resultados mostram uma diferença significativa de desempenho entre o principal modelo proprietário (GPT-4) e um forte concorrente de código aberto (LLaMA-3-8B). Isto destaca a importância crítica da capacidade do modelo para uma implementação fiável no mundo real. A alta precisão dos melhores modelos valida a viabilidade de utilizar LLMs para uma classificação precisa de chamadas de API.

5. Análise Técnica & Principais Conclusões

Conclusão Principal: Este artigo não trata apenas de usar um LLM como classificador de API; é um meta-framework para avaliar qual LLM usar para esse trabalho específico. O verdadeiro produto é o motor de geração de dados sintéticos, que transforma o problema vago da "adequação do LLM" numa métrica mensurável e comparável. Esta é uma jogada astuta, reconhecendo que, na era dos LLMs, a capacidade de criar os seus próprios dados de avaliação de alta qualidade é tão valiosa como o próprio modelo.

Fluxo Lógico: O argumento é elegantemente circular e auto-reforçante: 1) Precisamos de LLMs para compreender a linguagem natural para APIs. 2) Para escolher o LLM certo, precisamos de dados específicos da tarefa. 3) Os dados reais são difíceis de obter. 4) Portanto, usamos um LLM poderoso (GPT-4-turbo) para gerar esses dados. 5) Depois usamos esses dados para testar outros LLMs. É um processo de bootstrap que aproveita o modelo mais forte disponível para avaliar o campo.

Pontos Fortes & Fraquezas: A principal força é a praticidade. Este framework oferece uma solução imediatamente utilizável para empresas que têm um conjunto de APIs e um painel de LLMs disponíveis (OpenAI, Anthropic, Google, código aberto). A fraqueza, que os autores reconhecem, é o risco de "inception de LLM": usar um LLM para gerar dados para testar LLMs pode herdar e amplificar vieses. Se o GPT-4 tiver um ponto cego na compreensão de um certo tipo de consulta, irá gerar dados de teste defeituosos, e todos os modelos serão julgados contra um padrão defeituoso. Isto reflete desafios vistos noutros domínios generativos, como os ciclos de treino de GANs onde o gerador e o discriminador podem desenvolver patologias partilhadas.

Conclusões Acionáveis: Para CTOs e gestores de produto, a conclusão é clara: Não se limite a testar o GPT-4 para a sua interface de linguagem natural de API. Teste este framework. Use-o para realizar uma competição entre o GPT-4o, o Claude 3 e o Gemini nas suas especificações reais de API. A diferença de 24 pontos na precisão entre o GPT-4 e o LLaMA-3-8B é um aviso claro de que a escolha do modelo não é trivial e o custo (gratuito vs. pago) é um substituto perigoso para o desempenho. O framework fornece a evidência quantitativa necessária para tomar essa decisão de plataforma multimilionária.

6. Exemplo de Aplicação do Framework

Cenário: Uma empresa de fintech quer adicionar uma interface de linguagem natural à sua "API de Análise de Transações" interna, que tem funções como get_transactions_by_date(date_range, user_id), flag_anomalous_transaction(transaction_id, reason) e generate_spending_report(user_id, category).

Aplicação do Framework:

  1. Geração do Conjunto de Dados: A empresa utiliza o Módulo de Geração de Dados Sintéticos (alimentado pelo GPT-4-turbo) com prompts que descrevem cada função da API. Para get_transactions_by_date, pode gerar consultas como: "Mostra-me as minhas compras da semana passada", "Quanto gastei entre 1 e 10 de março?", "Posso ver o meu histórico de transações do mês passado?"
  2. Avaliação do Modelo: Eles usam o conjunto de dados gerado (por exemplo, 500 consultas em 3 funções de API) para testar LLMs candidatos: GPT-4o, Claude 3 Sonnet e um Llama 3 ajustado internamente. Medem a precisão e a latência.
  3. Seleção & Implementação: Os resultados mostram que o Claude 3 Sonnet atinge 98,5% de precisão a metade do custo por chamada do GPT-4o, tornando-o a escolha ideal. O Llama 3 ajustado pontua 89% mas oferece privacidade de dados. O resultado quantitativo orienta uma decisão clara e baseada em evidências.
Este exemplo demonstra como o framework muda a conversa de suposições subjetivas para uma seleção de plataforma baseada em dados.

7. Aplicações Futuras & Direções

As implicações deste trabalho vão além da simples classificação de APIs:

  • Melhoria de Plataformas Low-Code/No-Code: Integrar este framework em plataformas como o Zapier ou o Microsoft Power Platform poderia permitir que os utilizadores construíssem automações complexas usando apenas linguagem natural, que o sistema traduziria numa sequência de chamadas de API através de diferentes serviços.
  • Democratização de Software Empresarial: Suítes complexas de software empresarial (por exemplo, SAP, Salesforce) com centenas de APIs poderiam tornar-se acessíveis a analistas de negócio através de interfaces conversacionais, reduzindo drasticamente a sobrecarga de formação e expandindo a utilidade.
  • Ecossistemas de API Dinâmicos: Em arquiteturas de IoT ou microserviços onde as APIs mudam frequentemente ou são adicionadas novas, o módulo de geração de dados sintéticos poderia ser executado periodicamente para atualizar o conjunto de dados de avaliação e reavaliar o LLM com melhor desempenho, criando uma camada de interface auto-adaptativa.
  • Direção de Investigação - Redução de Alucinação: Um próximo passo crítico é integrar verificação formal ou verificação de restrições, inspirado em técnicas de síntese de programas, para garantir que a chamada de API classificada não é apenas plausível, mas também semanticamente válida e segura para executar.
  • Direção de Investigação - Entradas Multimodais: Frameworks futuros poderiam aceitar consultas multimodais (por exemplo, um utilizador a apontar para um elemento do painel enquanto faz uma pergunta) e mapeá-las para uma chamada de API composta, misturando visão computacional com PLN.

8. Referências

  1. Brown, T. B., et al. (2020). Language Models are Few-Shot Learners. Advances in Neural Information Processing Systems, 33.
  2. OpenAI. (2023). GPT-4 Technical Report. arXiv:2303.08774.
  3. Zhu, J. Y., Park, T., Isola, P., & Efros, A. A. (2017). Unpaired Image-to-Image Translation using Cycle-Consistent Adversarial Networks. Proceedings of the IEEE International Conference on Computer Vision.
  4. Raffel, C., et al. (2020). Exploring the Limits of Transfer Learning with a Unified Text-to-Text Transformer. Journal of Machine Learning Research, 21.
  5. Schick, T., & Schütze, H. (2021). Generating Datasets with Pretrained Language Models. Proceedings of the 2021 Conference on Empirical Methods in Natural Language Processing.
  6. Microsoft Research. (2023). The Era of Copilots: AI-Powered Software Development. Retrieved from Microsoft Research Blog.
  7. Google AI. (2024). Gemini: A Family of Highly Capable Multimodal Models. Technical Report.