Gorilla: Como o Treinamento Consciente de Recuperação Reduz as Alucinações de APIs em LLMs de 78% para 11%

Lendo o artigo sobre o Gorilla (Patil et al., 2023, arXiv:2305.15334, NeurIPS 2024) porque ele se situa na junção de dois problemas que encontro repetidamente: como fazemos um agente LLM chamar a ferramenta certa com os argumentos corretos e como mantemos essa habilidade ativa à medida que as APIs mudam? As respostas aqui são práticas e os números são surpreendentemente sólidos — mas as premissas embutidas na avaliação merecem mais escrutínio do que costumam receber.

O artigo

O Gorilla, de Shishir G. Patil, Tianjun Zhang, Xin Wang e Joseph E. Gonzalez da UC Berkeley, aborda um modo de falha concreto: os LLMs de última geração alucinam chamadas de API. Quando solicitados a escrever um código que invoque uma função específica de uma biblioteca, o GPT-4 (em meados de 2023) frequentemente gera assinaturas de função que parecem plausíveis, mas estão incorretas, modelos inexistentes ou nomes de argumentos obsoletos. O Gorilla é um modelo baseado em LLaMA de 7 bilhões de parâmetros, ajustado especificamente para gerar chamadas de API precisas, treinado com uma técnica que os autores chamam de Treinamento Consciente de Recuperação (Retriever-Aware Training - RAT). A ideia é simples: durante o treinamento, o modelo visualiza a documentação da API recuperada junto com a consulta do usuário, formatada como "Use esta documentação de API para referência: <retrieved_API_doc_JSON>". Isso ensina o modelo tanto a ler a documentação quanto a confiar no contexto recuperado em vez de sua memória paramétrica — uma propriedade que traz benefícios no momento da inferência quando a documentação muda.

O conjunto de dados de avaliação, APIBench, abrange 925 APIs do HuggingFace Model Hub, 95 APIs do TorchHub e 696 APIs do TensorFlow Hub, com dez consultas sintéticas de acompanhamento de instruções geradas por API via self-instruct. A métrica de avaliação é a correspondência de subárvore AST — a chamada de API gerada é analisada sintaticamente e verificada quanto à correção funcional — o que também permite, pela primeira vez neste cenário, uma medição fundamentada da taxa de alucinação.

Ideias principais

• O RAT torna a documentação legível no momento da inferência. Ao treinar com prompts que incluem documentação recuperada, o Gorilla aprende a se basear no texto recuperado em vez de recordar detalhes de API de seus pesos. Isso significa que o modelo permanece atualizado conforme as APIs evoluem, sem necessidade de retreinamento.
• Precisão zero-shot: Gorilla 59–84%, GPT-4 18–39%. No TorchHub, o Gorilla alcança 59,13% contra 38,70% do GPT-4. No HuggingFace, é 71,68% contra 19,80%. No TensorFlow Hub, 83,79% contra 18,20%. A margem é maior onde o espaço da API é mais diversificado.
• A redução da alucinação é o destaque principal. A taxa de alucinação do Gorilla é de 6,98% no TorchHub, 10,95% no HuggingFace e 5,40% no TensorFlow Hub. As taxas do GPT-4 variam de 36,55% a 78,65% nos mesmos conjuntos de dados.
• O recuperador oráculo é o limite máximo. Com o documento de referência (ground-truth) recuperado (modo oráculo), a precisão atinge 67–94%. Este é o melhor caso teórico para qualquer sistema baseado em RAG e a lacuna do Gorilla zero-shot para este teto é o espaço disponível para melhoria do recuperador.
• Recuperadores reais deixam a desejar. Mudar do oráculo para o GPT-Index no momento da avaliação degrada a precisão em 29,20%; o BM25 a degrada em 52,27%. A robustez do modelo ao ruído de recuperação é real, mas não ilimitada.
• A avaliação AST se generaliza. A abordagem de correspondência de subárvore mede se a chamada gerada é funcionalmente correta, não apenas sintaticamente semelhante. Esta é a métrica correta para qualquer tarefa onde a saída é um código que será efetivamente executado.

O que se sustenta — e o que não

A afirmação central se sustenta: o ajuste fino em prompts aumentados por documentação melhora drasticamente a precisão das chamadas de API e reduz a alucinação. A metodologia de avaliação AST é genuinamente inovadora e claramente superior à correspondência de strings ou avaliação humana em escala. O RAT é uma ideia limpa e reproduzível.

O que me deixa cético é o escopo do benchmark. Todos os três conjuntos de dados — HuggingFace, TorchHub, TensorFlow Hub — são registros de modelos de ML com uma estrutura de API muito regular: você carrega um modelo pelo nome, possivelmente com alguns argumentos de palavra-chave, e chama um método do tipo predict. As instruções são geradas sinteticamente, o que significa que a distribuição de teste está intimamente relacionada à distribuição de treinamento. Um modelo ajustado em documentação de APIs de ML treinado via self-instruct, avaliado em consultas de self-instruct para APIs de ML, não está sendo testado na complexidade que realmente aparece na produção: solicitações ambíguas, fluxos de trabalho de várias etapas, coerção de tipos de argumentos, autenticação, limites de taxa ou recuperação de erros.

A degradação da recuperação também é maior do que o enquadramento do artigo sugere. Uma queda de precisão de 52% com a recuperação BM25 é catastrófica. Se o recuperador que você implanta na produção se assemelha mais ao BM25 do que a um oráculo, os ganhos evaporam. Os autores reconhecem essa lacuna, mas não oferecem um caminho para fechá-la.

Por fim, o modelo em si é um ajuste fino do LLaMA 7B. A comparação com o GPT-4 zero-shot é impressionante, mas a comparação não é totalmente justa: o GPT-4 não foi treinado para usar documentação recuperada. Um GPT-4 aumentado com RAG e um prompt de sistema projetado para ler documentos de API quase certamente fecharia a lacuna consideravelmente.

Por que isso importa para a IA financeira

O padrão RAT é diretamente aplicável a agentes de gravação (write-back) do Beancount. Um agente Beancount precisa invocar comandos CLI (bean-query, bean-report), APIs Python (beancount.loader, beancount.core) e o serviço FastAPI beancount-ledger — cada um com semânticas de argumentos específicas que estão documentadas, mas não necessariamente nos dados de treinamento do modelo. A abordagem do Gorilla diz: recupere o trecho de documentação relevante no momento da inferência, injete-o no contexto e treine o modelo para ler e segui-lo.

Os números de alucinação são o sinal mais útil para um contexto financeiro. Uma taxa de alucinação de 10% em nomes de modelos de ML é irritante. Uma taxa de alucinação de 10% em chamadas de mutação de livro-razão — nomes de contas errados, códigos de moeda incorretos, sinais de débito/crédito invertidos — é um problema de integridade. A implicação é que mesmo um agente treinado ao estilo Gorilla precisa de um validador em tempo de execução antes que qualquer gravação seja confirmada, consistente com o que o CRITIC (LOG-012) mostrou sobre a crítica interativa de ferramentas. A descoberta da degradação da recuperação reforça isso: se a recuperação no mundo real reduz a precisão pela metade, a rede de segurança não pode ser apenas a qualidade da recuperação.

A metodologia de avaliação AST se traduz naturalmente. As transações do Beancount possuem uma estrutura analisável, e verificar diretivas geradas em relação a um esquema usando correspondência AST é exatamente o tipo de validador leve que poderia ser executado em um gancho de pré-commit (pre-commit hook) ou loop de agente.

O que ler a seguir

• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789) — estende o problema de chamada de API para mais de 16.000 APIs REST reais com cadeias de uso de ferramentas de várias etapas; aborda diretamente a limitação do Gorilla de avaliar apenas invocações de registro de ML de chamada única.
• The Berkeley Function Calling Leaderboard (BFCL) (OpenReview:2GmDdhBdDk, pôster NeurIPS 2024) — a evolução direta do Gorilla em um ranking dinâmico que rastreia como os modelos de fronteira melhoram na chamada de funções ao longo do tempo; a V3 adiciona interações de múltiplos turnos, a V4 adiciona busca na web baseada em agentes.
• API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs — avalia LLMs em 73 APIs em uma gama mais ampla de domínios, incluindo finanças e serviços web, com uso de ferramentas em múltiplos turnos; um complemento útil ao foco mais restrito em ML do APIBench.