Resumo Técnico: Diagnosticando Lacunas de Conhecimento no Uso de Ferramentas por LLMs

Declaração do Problema

Modelos de Linguagem de Grande Escala (LLMs) de código funcionam cada vez mais como agentes que devem invocar bibliotecas de software e APIs para resolver tarefas complexas. Um desafio crítico surge quando esses agentes encontram APIs novas — funções ou interfaces ausentes de seus dados de pré-treinamento devido a atualizações de versão de bibliotecas, mudanças de compatibilidade (breaking changes) ou pacotes emergentes. Utilizar essas APIs com sucesso exige mais do que apenas recordar o nome de uma função; demanda a coordenação de tipos heterogêneos de conhecimento:

• Declarativo: Assinaturas, tipos de parâmetros e caminhos de módulos.
• Procedural: Composição correta dentro de fluxos de trabalho e resolução de importação.
• Fundamentado (Grounded): Exemplos de execução concretos e detalhes de implementação.

A infraestrutura de avaliação existente para a aquisição de novas APIs é fundamentalmente limitada. Os benchmarks atuais são frequentemente estáticos (degradando-se rapidamente à medida que os modelos absorvem novos dados), dependem de métricas agregadas grosseiras (ex: pass@k) que obscurecem as causas raízes das falhas e frequentemente sintetizam tarefas artificiais que não refletem a evolução real de bibliotecas. Consequentemente, permanece pouco compreendido quais componentes específicos de conhecimento são aprendidos por diferentes paradigmas de adaptação (ex: Geração Aumentada por Recuperação - RAG vs. Ajuste Fino - Fine-Tuning) e quais componentes ausentes levam a tipos específicos de falha.

Metodologia: NOVELAPIBENCH

Para abordar essas limitações, os autores introduzem o NOVELAPIBENCH, um benchmark totalmente automatizado, dinâmico e baseado em execução, projetado para diagnosticar lacunas de conhecimento em LLMs de código. O framework opera através de um pipeline de quatro estágios:

1. Descoberta de Novas APIs: Dada uma biblioteca alvo $L$ e um modelo base $M$, o sistema identifica APIs introduzidas em versões da biblioteca lançadas após o corte de conhecimento de $M$. O sistema compara as superfícies de API públicas entre a versão pré-corte ($v_{old}$) e a versão pós-corte ($v_{new}$) usando introspecção e análise AST, filtrando entradas privadas, obsoletas ou sem fonte.
2. Extração de Conhecimento: Para cada nova API, o sistema decompõe o conhecimento em quatro componentes distintos:
   • $S$ (Superfície): Nomes totalmente qualificados e assinaturas de parâmetros (tipos, valores padrão, descrições).
   • $E$ (Exemplares): Exemplos de uso canônicos minerados de documentação e GitHub, validados em um ambiente de teste (sandbox).
   • $M_{prose}$ (Prosa de Mecanismo): Descrições em linguagem natural do algoritmo ou design subjacente.
   • $M_{code}$ (Código de Mecanismo): Código-fonte de implementação extraído via AST.
3. Geração de Tarefas: O sistema gera tarefas de codificação executáveis com test harnesses de dificuldade controlada. Crucialmente, cada harness inclui um espião de API-alvo auto-injetado que aplica patches em todos os aliases da API alvo. Isso garante que passar no teste exija uma chamada genuína à API alvo, impedindo que os modelos contornem a tarefa via mimetismo estrutural.
4. Filtragem de Qualidade e Novidade: As tarefas são filtradas para garantir que a solução de referência seja válida, que o modelo base não consiga resolvê-las sem auxílio (novidade empírica) e que a tarefa seja solucionável com o pacote completo de conhecimento.

Taxonomia de Falhas:
Uma contribuição fundamental é uma taxonomia de falhas automatizada que classifica falhas de execução em seis categorias mutuamente exclusivas, ligando erros específicos ao conhecimento ausente:

1. WrongAPISelection (Seleção de API Incorreta): A API alvo nunca foi invocada (alucinação ou uso de símbolo irmão).
2. WrongImport (Importação Incorreta): Símbolo correto, mas caminho de importação errado ou ausente.
3. WrongSyntax (Sintaxe Incorreta): Sintaxe Python inválida.
4. WrongParam (Parâmetro Incorreto): Chamada correta, mas argumentos incorretos.
5. WrongShapeDtype (Erro de Forma/Tipo de Dado): Violação de contrato dentro do corpo da API (ex: incompatibilidade de forma/shape).
6. WrongLogic (Lógica Incorreta): A estrutura do programa circundante está incorreta, apesar do uso correto da API.

Principais Contribuições

1. Benchmarking Dinâmico: Um benchmark regenerável que se adapta a qualquer modelo base e biblioteca em evolução, garantindo que as tarefas permaneçam genuinamente novas.
2. Diagnóstico Granular: Uma taxonomia de falhas automatizada que conecta erros de execução específicos aos componentes de conhecimento ausentes entre os paradigmas de recuperação, ajuste fino e edição de conhecimento.
3. Estudo Empírico Sistemático: Uma avaliação em larga escala abrangendo ~800 novas APIs em 5 domínios, 4 modelos de base e múltiplos métodos de adaptação (RAG, SFT, RAFT, GRACE, MEMIT, AlphaEdit).

Resultados Experimentais

1. Eficácia dos Componentes de Conhecimento (RQ1)

• Exemplos de Uso ($E$) são o componente isolado mais forte: Fornecer apenas exemplos aumentou o pass@1 de 3,1% para 18,2%, principalmente resolvendo erros de WrongAPISelection.
• Assinaturas ($S$) fornecem a âncora mais confiável: A célula de superfície ($S$) alcançou 21,7% de pass@1, superando todos os componentes isolados, ao reduzir erros de seleção de API.
• Prosa de Mecanismo ($M_{prose}$) auxilia na desambiguação semântica: Quando combinada com assinaturas ($S+M_{prose}$), ela reduziu ainda mais os erros de lógica, mas teve impacto mínimo como componente isolado.
• Código-fonte ($M_{code}$) introduz ruído: Adicionar o código-fonte da implementação frequentemente degradou o desempenho. Aumentou significamente os erros de WrongImport, sugerindo que o código-fonte bruto introduz ruído de caminho de módulo que confunde os modelos em vez de resolver erros residuais.
• Configuração Ótima: As melhores configurações de dois componentes parearam assinaturas ($S$) com prosa de mecanismo ou exemplos, dependendo do domínio e do modelo de base. Os pacotes completos ($S+E+M_{prose}+M_{code}$) frequentemente tiveram desempenho inferior devido à interferência negativa do código-fonte.

2. Impacto da Tarefa e do Modelo de Base (RQ2)

• Regularidade da Tarefa: Exemplos ($E$) foram altamente eficazes para tarefas regulares e modeláveis (ex: fixtures de ciência de dados), mas prejudiciais para tarefas heterogêneas (ex: AI4Science), onde os exemplos divergiam do requisito específico. A prosa de mecanismo ($M_{prose}$) foi mais estável entre os tipos de tarefa.
• Preferências de Modelos de Base: O componente secundário ideal dependia da força inerente do modelo de base. Modelos onde as assinaturas ($S$) já eram fortes beneficiaram-se mais da prosa; modelos que dependiam de exemplos beneficiaram-se de estruturas de chamada explícitas.
• Modelos Orientados ao Raciocínio: Modelos de base orientados ao raciocínio (ex: R1-Distill) foram mais resistentes ao ruído de caminho de importação introduzido pelo código-fonte, provavelmente devido à sua capacidade de re-resolver identificadores em vez de apenas copiar caminhos.

3. Adaptação Paramétrica vs. Recuperação (RQ3)

• Não Internalização de Fatos Voláteis: Nenhum paradigma de adaptação paramétrica (SFT, RAFT, GRACE, MEMIT, AlphaEdit) internalizou totalmente o conhecimento de novas APIs. Quando o pacote de conhecimento externo era removido na inferência, o desempenho caía drasticamente (ex: SFT caiu de 85,5% para 3,3%), falhando em fechar a lacuna com os métodos baseados em recuperação.
• Aprendizado de Meta-Habilidades Procedurais: O ajuste fino não memorizou detalhes de API (assinaturas, caminhos), mas sim aprendeu uma habilidade procedural transferível: como utilizar efetivamente os pacotes de conhecimento fornecidos.
  • SFT/RAFT/AlphaEdit reduziram significamente os erros de WrongAPISelection e WrongImport quando um pacote estava presente, deslocando as falhas para WrongLogic.
  • Essa habilidade de "utilização de pacotes" transferiu-se para bibliotecas fora do conjunto de treinamento (OOD), mas o conhecimento específico de caminho de módulo não. Modelos treinados em uma biblioteca podiam identificar a API correta em uma nova biblioteca, mas frequentemente falhavam em resolver o caminho de importação correto, levando a um aumento nos erros de WrongImport.

Significância e Alegações

O artigo argumenta que a aquisição de conteúdo (identificar a API e seu contrato) e a realização procedural (integrá-la ao código com importações e lógica corretas) são sub-habilidades distintas.

• A Recuperação é essencial para fornecer fatos voláteis e de baixa estrutura (nomes de API, assinaturas, caminhos) que são difíceis de serem inferidos ou memorizados pelos modelos.
• A Adaptação Paramétrica (Ajuste Fino) é eficaz para melhorar a integração procedural desses fatos — ensinando o modelo como utilizar corretamente as evidências recuperadas.

Os autores concluem que a arquitetura ideal para adaptar LLMs de código a novas APIs não é uma escolha entre RAG e ajuste fino, mas sim uma combinação: unidades de recuperação compactas e de alto valor (ex: assinaturas + prosa de mecanismo) pareadas com adaptadores treinados através de tarefas heterogêneas de uso de API para dominar a integração procedural. Os métodos atuais de "localizar e editar" ainda não alcançam essa fronteira combinada. O trabalho sugere que o progresso futuro pode exigir supervisão de nível de processo (ex: reforço baseado em execução) para melhor unir a identificação de uma API e sua implementação correta.