Toolformer: Uso de Ferramentas Autossupervisionado e seus Limites para IA Financeira

Toolformer (Schick et al., 2023, Meta AI) é o artigo fundamental para ensinar modelos de linguagem a chamar APIs externas por meio de treinamento autossupervisionado. Eu estava adiando uma leitura cuidadosa porque o "uso de ferramentas" tornou-se um termo tão comum que as afirmações originais acabam se misturando. Antes de projetar qualquer agente de write-back que chame ferramentas de razão (ledger), preciso entender o que o Toolformer realmente demonstrou — e onde ele falha silenciosamente.

O artigo

Timo Schick e sete coautores na Meta AI apresentam um método para treinar um modelo de linguagem para decidir quando chamar APIs externas, quais argumentos passar e como incorporar os resultados em suas próprias previsões — sem exigir dados de treinamento rotulados manualmente para cada ferramenta. A abordagem é autossupervisionada: o modelo gera chamadas de API candidatas em posições plausíveis no texto, executa essas chamadas e mantém apenas os exemplos onde o resultado da API reduz genuinamente a perplexidade do modelo nos tokens circundantes. Esse conjunto de dados filtrado é então usado para ajuste fino (fine-tuning). As ferramentas testadas incluem uma calculadora, dois motores de busca (recuperação BM25 e busca na Wikipedia), um modelo de QA, um tradutor e um calendário.

O modelo treinado é um modelo baseado em GPT-J de 6,7B de parâmetros que eles chamam de Toolformer. O artigo foi aceito no NeurIPS 2023.

Ideias principais

• Em problemas matemáticos verbais (SVAMP), o Toolformer 6,7B atinge 29,4% — em comparação com a linha de base GPT-J de 5,2%, OPT 66B de 4,9% e GPT-3 175B de 10,0%. O uso de ferramentas efetivamente achata a curva de escala usual para aritmética.
• No ASDiv math, o Toolformer atinge 40,4% vs GPT-J em 7,5% e GPT-3 em 14,0%; no MAWPS, 44,0% vs GPT-J em 9,9% e GPT-3 em 19,8%.
• Em tarefas de QA factual, o cenário se inverte: o GPT-3 ainda supera o Toolformer em todos os três benchmarks de QA (TriviaQA, WebQuestions, Natural Questions), apesar de o Toolformer usar ferramentas de busca. Toolformer TriviaQA: 53,5% vs GPT-J baseline 31,9%, mas o GPT-3 sem ferramentas é ainda superior.
• O pipeline de geração de dados autossupervisionado produz exemplos de treinamento onde o modelo aprende a não chamar uma API quando ela não é útil — a etapa de filtragem usa a melhoria da perplexidade como o sinal para "esta chamada de ferramenta realmente ajudou?".
• A capacidade de uso de ferramentas só emerge em escala: modelos abaixo de aproximadamente 775M de parâmetros não aprendem de forma confiável quando invocar ferramentas, mesmo com o mesmo sinal de treinamento.
• A ferramenta de calendário é chamada apenas 0,2% do tempo em tarefas de raciocínio temporal; o modelo roteia predominantemente questões temporais para a ferramenta de busca da wiki.

O que se sustenta — e o que não se sustenta

O insight central é duradouro: o truque de filtragem baseado em perplexidade é elegante porque não requer rotulagem humana nem um oráculo que saiba a resposta certa — apenas se o resultado da API inserido tornou o texto circundante mais previsível. Essa é uma contribuição genuína, e os resultados em matemática são impressionantes. Um modelo de 6,7B batendo o GPT-3 no ASDiv não é um truque de avaliação; é uma demonstração clara de que a chamada de ferramenta correta vale cerca de 26 vezes mais parâmetros em tarefas aritméticas.

O que considero menos convincente é a história do QA. O artigo apresenta o Toolformer como uma melhoria ampla de desempenho, mas os resultados de QA mostram que ele não supera o GPT-3 — um modelo muito maior sem nenhuma ferramenta. Os autores reconhecem isso, mas o enquadramento narrativo ("muitas vezes competitivo com modelos muito maiores") subestima o quão seletiva é a vitória: o modelo vence em tarefas que se decompõem claramente em uma única chamada de calculadora ou busca, e perde ou empata em tarefas que exigem raciocínio genuíno sobre o conteúdo recuperado.

A questão metodológica mais profunda é que o pipeline autossupervisionado pressupõe que o modelo já seja bom o suficiente para gerar chamadas de API plausíveis antes de ter sido treinado para isso. Este é um problema de bootstrapping. Para ferramentas bem estruturadas, como uma calculadora com um formato de entrada claro, funciona. Para ferramentas com esquemas de argumentos mais complexos — exatamente o tipo que você desejaria para uma API de write-back de um razão real — a qualidade das chamadas amostradas degradaria rapidamente.

O artigo também avalia cada ferramenta isoladamente, não em combinação. Não há demonstração de um pipeline de várias etapas onde, por exemplo, um resultado de busca alimenta uma calculadora. Os autores apontam isso como uma limitação, mas é significativa: fluxos de trabalho contábeis reais quase sempre exigem chamadas de ferramentas encadeadas.

Finalmente, a avaliação é zero-shot. Não há comparação com o GPT-3 ou GPT-4 com prompting few-shot e ferramentas fornecidas no contexto, que se tornou o paradigma dominante poucos meses após este artigo. A data de publicação do NeurIPS 2023 significa que os experimentos precedem a adoção generalizada de APIs de chamada de função (function-calling), tornando o conjunto de comparação um tanto datado no momento da publicação.

Por que isso importa para a IA financeira

O artigo do Toolformer responde a uma pergunta que me interessa para o Bean Labs: um modelo pode aprender a chamar uma API de write-back de forma confiável e a que custo? A resposta dos resultados matemáticos é "sim, se a interface da ferramenta for limpa e a tarefa se decompor em uma única chamada". Os modos de falha, porém, mapeiam diretamente as partes mais difíceis do problema do ledger.

Ações de write-back do Beancount — classificar uma transação, inferir mapeamentos de contas, gerar uma entrada de diário — não são chamadas de calculadora de etapa única. Elas envolvem a recuperação de contexto (entradas anteriores, plano de contas), aplicação de regras (regras de lançamento, restrições de moeda) e produção de saída estruturada que deve ser sintaticamente válida. Isso requer pelo menos três chamadas de ferramentas encadeadas, e a arquitetura Toolformer explicitamente não consegue encadear ferramentas. O sinal de treinamento baseado em perplexidade também seria difícil de aplicar aqui: não está claro o que "menor perplexidade no texto do razão circundante" significa quando a saída é um arquivo .beancount estruturado, em vez de uma continuação de linguagem natural.

A lição mais útil do Toolformer para nossos propósitos é o espaço negativo: um agente de write-back não pode ser apenas um LM ajustado que memorizou quando chamar a API do ledger. Ele precisa de uma camada de raciocínio explícita (ReAct ou similar) que possa planejar, executar e verificar resultados intermediários antes de confirmar uma gravação. O Toolformer demonstra que o uso de ferramentas funciona; ele não demonstra que funciona com segurança em operações estruturadas com efeitos colaterais.

O que ler a seguir

• ReAct: Synergizing Reasoning and Acting in Language Models (arXiv:2210.03629) — adiciona etapas de raciocínio chain-of-thought explícitas intercaladas com chamadas de ferramentas; a arquitetura que aborda a limitação de encadeamento do Toolformer e é a base para a maioria dos agentes modernos.
• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — escala o uso de ferramentas para mais de 16.000 APIs reais via o dataset ToolBench; o que há de mais próximo de um teste de estresse de chamada de ferramentas no nível de complexidade que um agente contábil real enfrentaria.
• FinMaster (arXiv:2505.13533) — benchmarks de fluxos de trabalho contábeis de ponta a ponta, incluindo lançamento de diário e conciliação; mostrará se os ganhos que o Toolformer demonstrou em aritmética se generalizam para as tarefas de várias etapas e restritas por esquema que importam para o Beancount.