WildToolBench: Por que nenhum LLM excede 15% de acurácia de sessão no uso de ferramentas no mundo real

Os benchmarks de uso de ferramentas que venho acompanhando — BFCL, ToolBench, τ-bench — todos compartilham uma falha de design comum: eles constroem tarefas a partir da imaginação dos autores do benchmark sobre o que os usuários fazem. O WildToolBench, aceito no ICLR 2026, volta aos logs de usuários reais e pergunta o que os usuários realmente fazem. A resposta é humilhante: 57 LLMs avaliados, zero excedem 15% de acurácia de sessão.

O artigo

Peijie Yu, Wei Liu, Yifan Yang e colegas do Alibaba apresentam o WildToolBench (arXiv:2604.06185), um benchmark de 256 cenários de diálogo multiturno com 1.024 tarefas extraídas de padrões autênticos de comportamento do usuário e baseadas em cerca de 1.600 APIs públicas. O argumento central é que os benchmarks existentes estão saturando não porque os modelos são bons, mas porque as tarefas são artificiais. Usuários reais agrupam solicitações, omitem o contexto compartilhado dois turnos atrás e alternam entre fazer uma pergunta sobre ferramenta, conversa fiada e pedido de esclarecimento — às vezes em uma única mensagem. O WildToolBench operacionaliza esses modos de falha em três categorias de desafio estruturadas e mede tanto a acurácia no nível da tarefa quanto a acurácia muito mais rigorosa no nível da sessão, que exige sucesso em todas as quatro tarefas de um diálogo.

Ideias-chave

• A acurácia de sessão entra em colapso para dígitos únicos na maioria dos modelos: Gemini-2.0-Flash-Thinking lidera com 14,45% de acurácia de sessão, Claude-4-Sonnet com 12,50%, GPT-4o com 11,72%. Passar por todas as tarefas em uma sessão de quatro turnos é difícil o suficiente para que até mesmo 60% de acurácia de tarefa se traduza em menos de 15% de acurácia de sessão — um imposto de probabilidade composta sobre cada interação.
• A orquestração composicional é o penhasco mais íngreme: Topologias de ferramentas mistas (sequencial mais paralelo) limitam os modelos de ponta a 25% de acurácia de tarefa, contra 54–62% para cadeias puramente paralelas ou sequenciais. Quando uma tarefa exige um desdobramento paralelo seguido por uma fusão sequencial, o problema de coordenação excede o que qualquer modelo atual lida de forma confiável.
• A intenção oculta é uma lacuna maior do que qualquer outra medida anteriormente: O WildToolBench garante que 100% das tarefas envolvam informações implícitas ou entre turnos; o BFCL v3 alcança apenas 15,7%. Tarefas de dependência de longo alcance — onde a informação ausente está há mais de dois turnos — são o subtipo mais difícil, com nenhum modelo ultrapassando 50%, mesmo no nível da tarefa.
• As transições de instrução compõem erros a uma taxa linear: Cada troca de política adicional (tarefa de ferramenta → chat → esclarecimento → tarefa de ferramenta) reduz a acurácia em aproximadamente 5 a 15 pontos percentuais. Com três transições, os modelos mais afetados perdem 30 pontos. Os autores chamam isso de "autocondicionamento": respostas anteriores enviesam a interpretação do modelo das instruções subsequentes de formas difíceis de corrigir no meio da sessão.
• A Taxa de Caminho Ideal (Optimal Path Rate) permanece abaixo de 43%: Mesmo quando os modelos concluem as tarefas corretamente, eles desperdiçam chamadas de API em excesso. O Claude-4-Sonnet atinge a melhor Taxa de Caminho Ideal com 42,74%, o que significa que a maioria das conclusões corretas leva mais passos do que o necessário — um custo direto em latência e tokens para qualquer sistema de produção.
• Modelos especializados no uso de ferramentas apresentam desempenho inferior aos modelos generalistas de fronteira: xLAM-2-70B e ToolACE2-8B apresentam taxas de erro de nome de função incorreto superiores a 30%, pior do que GPT-4o ou Claude-4-Sonnet. O ajuste fino em corpora estreitos de uso de ferramentas parece criar fragilidade em vez de robustez sob mudança de distribuição para comportamentos de usuários reais.

O que se sustenta — e o que não

O design do benchmark é robusto onde mais importa. A distinção entre acurácia de tarefa e acurácia de sessão está corretíssima: a composição de modos de falha é o que mata implementações reais, e a maioria dos trabalhos anteriores relata números no nível da tarefa que mascaram isso. A taxonomia de três desafios (orquestração composicional, intenção oculta, transições de instrução) é bem fundamentada e comprovada empiricamente — as curvas de degradação de desempenho entre os tipos de desafio são reais e impressionantes.

O ponto fraco é a escala. 1.024 tarefas de 256 cenários é um artefato de pesquisa credível, mas escasso para um ranking destinado a acompanhar 57 modelos ao longo do tempo. Os autores reconhecem isso diretamente e mencionam um pipeline de escalonamento automatizado em trabalhos futuros. Outro problema é que "baseado em logs de usuários reais" carrega muita responsabilidade: as tarefas finais são parcialmente sintéticas, construídas por um sistema multiagente a partir de padrões semente e depois verificadas por anotadores humanos. A alegação é fundamentada, mas os dados não são puramente selvagens — são inspirados no real. Isso importa para quão literalmente se interpreta o teto de 15%; uma fração da lacuna pode fechar se o pipeline de geração introduzir dificuldades artificiais que os usuários reais não exibem de fato.

Também sou cético quanto à análise de transição de instrução como uma alegação arquitetônica. O artigo a atribui a uma limitação fundamental, mas o descompasso na distribuição de treinamento entre os objetivos de ajuste fino via RLHF e as sessões de usuários multimodais é a explicação mais simples. Isso é endereçável, não estrutural.

Por que isso importa para a IA financeira

Os três modos de falha mapeiam quase perfeitamente a forma como usuários reais interagem com um agente de escrita (write-back) do Beancount. Um usuário pergunta "quanto gastei em supermercado no mês passado e, aproveitando, adicione o recibo do Whole Foods de hoje" — essa é uma tarefa composicional agrupada em um único turno. Eles seguem com "na verdade, considere $47,23 em vez de $42, eu conferi" — essa é uma correção de parâmetro que exige que o agente acompanhe o estado da sessão. Então perguntam "essa categoria está correta?" — esse é um pedido de esclarecimento, e o agente precisa não reexecutar a operação de escrita que acabou de concluir. O limite de 25% na orquestração mista sequencial-paralela e a queda de 30 pontos nas transições de instrução são exatamente os modos de falha que se manifestariam em um agente de livro contábil lidando com sessões de usuários reais.

A descoberta de que modelos especializados no uso de ferramentas têm desempenho inferior aos modelos generalistas de fronteira é particularmente relevante. Se estivéssemos considerando o ajuste fino de um modelo aberto menor em exemplos específicos de chamada de ferramentas do Beancount — a jogada óbvia de redução de custos — o WildToolBench é um aviso direto de que a especialização pode sacrificar a robustez frente à distribuição do comportamento real do usuário. A descoberta sobre a Taxa de Caminho Ideal também importa: um agente que usa o dobro de chamadas de API para concluir uma tarefa não é apenas ineficiente; para operações de escrita, chamadas intermediárias redundantes podem deixar o livro contábil em estados intermediários inconsistentes.

O que ler a seguir

• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — o framework de treinamento fundamental contra o qual o WildToolBench se posiciona explicitamente; entender seu design de avaliação sintética esclarece exatamente o que a execução em tempo real adiciona.
• τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045) — o trabalho anterior mais próximo sobre o uso realista de ferramentas multiturno; comparar os domínios de varejo/companhias aéreas do τ-bench com a cobertura de APIs públicas do WildToolBench mostra o quanto o desafio se generaliza.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) — se o problema da transição de instrução for endereçável pela descoberta automática de melhores fluxos de trabalho de agentes, em vez de escalar dados de treinamento, o AFlow é o mecanismo mais plausível para isso.