ToolGrad: o framework do Google que inverte a geração de dados para uso de ferramentas

Ensinar um modelo de linguagem a chamar ferramentas de forma confiável exige conjuntos de dados que emparelhem perguntas de usuário com cadeias corretas de uso de ferramentas. Produzir esses dados em escala sempre foi lento e caro. Pesquisadores do Google, da Universidade de Tóquio, do RIKEN AIP e da Universidade de Tohoku apresentaram o ToolGrad, uma estrutura que inverte a ordem tradicional do processo: em vez de partir da pergunta e tentar descobrir a cadeia de ferramentas, ela primeiro constrói uma cadeia verificada de fato e só depois escreve a consulta correspondente.

O problema da geração “pergunta primeiro”

Pipelines anteriores, como ToolBench e ToolACE, seguem uma receita “pergunta primeiro”. O sistema sorteia um conjunto de APIs, pede a um LLM que invente uma instrução plausível de usuário e depois dispara um agente de busca em profundidade (DFS) para achar um caminho de uso de ferramentas que a satisfaça. A busca não tem garantia de sucesso: quando chega a um beco sem saída, o cálculo gasto na exploração é desperdiçado e a amostra é descartada.

O ToolGrad inverte essa lógica. Ele primeiro constrói uma cadeia de uso de ferramentas com verdade de campo, executando as APIs de verdade, e então anota essa cadeia com uma pergunta de usuário correspondente. Como a cadeia explícita e funcional é muito menos ambígua do que um prompt hipotético, a etapa de transformar cadeia em pergunta exige uma única chamada ao LLM.

Quatro módulos em loop

Cada iteração roda quatro módulos em sequência:

• API Proposer: reduz um conjunto sorteado de APIs a alguns candidatos que podem estender o fluxo atual.
• API Executors: executam esses candidatos em paralelo e produzem relatórios detalhados de execução.
• API Selector: revisa os relatórios, escolhe a melhor chamada e a anexa ao fluxo — seu feedback direcional é o “gradiente textual”.
• LLM Updater: reescreve a pergunta sintética e a resposta da IA para que correspondam ao novo conjunto de APIs.

Ao repetir o loop, cada amostra ganha uma pergunta de usuário, um fluxo de API verificado e a resposta final. A configuração padrão do repositório roda 10 iterações sobre 50 APIs sorteadas por fluxo.

Eficiência que se mede em números

A equipe avaliou a geração de dados sobre o banco de APIs do ToolBench, que contém mais de 16.000 APIs reais. Segundo o artigo:

• A taxa de sucesso saltou de 63,8% (DFS) para 99,8% (ToolGrad).
• Os usos de ferramentas com verdade de campo por amostra subiram de 2,1 para 3,4 — ou seja, cadeias mais longas.
• Os passos de uso de ferramentas por amostra caíram de 34,3 para 20,0.
• As invocações de LLM por amostra caíram levemente, de 64,5 para 63,9.

O único caso de falha restante (0,2%) acontece quando o agente não consegue resposta bem-sucedida de três APIs selecionadas em todas as dez iterações e salva uma amostra vazia.

Resultados no BFCL com Gemma-3

Os pesquisadores geraram o ToolGrad-500, um conjunto de 500 amostras construído com o Gemini 2.5 Flash-Lite, e o usaram para pós-treinar modelos Gemma-3 de 1B, 4B e 12B parâmetros. A avaliação usou o Berkeley Function Calling Leaderboard, cujo conjunto de ferramentas difere do ToolBench — um teste fora da distribuição, com ferramentas nunca vistas.

• O ajuste fino com o ToolGrad-500 melhorou as notas de uso de ferramentas em todos os tamanhos de modelo.
• O ToolGrad-12B marcou 83,1, ao lado do Gemini 2.5 Pro (83,2), do Claude 4.5 Opus (82,8) e do GPT-5 (74,4) na medição da época.
• O aluno de 12B superou o Gemini 2.5 Flash-Lite, o modelo professor que gerou seus dados de treino.
• O ToolGrad-12B liderou entre especialistas abertos de uso de ferramentas, incluindo ToolACE e Hammer-2.1-7B.

Por que isso importa agora

O ToolGrad é totalmente aberto: o código está sob licença Apache-2.0, o conjunto ToolGrad-500 e os modelos de 1B, 4B e 12B estão no Hugging Face, e há um pacote no PyPI. Para equipes que constroem agentes e assistentes com chamada de função, isso significa que dá para gerar dados de treino de alta qualidade — com quase nenhuma amostra descartada — e destilar essa capacidade em modelos pequenos que custam uma fração de uma API de fronteira. É a diferença entre depender de um serviço proprietário caro e rodar um especialista de 12B que compete com ele.