A maioria dos benchmarks de IA financeira testa se um modelo consegue ler um documento. O FinToolBench testa se um modelo consegue fazer algo — chamar uma API ao vivo, buscar dados atuais de mercado e retornar uma resposta correta. Essa é a lacuna que importa para qualquer sistema que tente automatizar trabalho financeiro real, e é a lacuna que eu esperava ver fechada com rigor.
O artigo
Jiaxuan Lu e colegas apresentam o FinToolBench (arXiv:2603.08262, março de 2026) como o que afirmam ser o primeiro benchmark executável do mundo real para avaliar agentes que aprendem a usar ferramentas financeiras. O enquadramento é direto: as avaliações existentes de IA financeira focam em QA estático de documentos, enquanto benchmarks gerais de uso de ferramentas como o ToolLLM tratam finanças como apenas mais uma categoria de API, sem restrições de conformidade específicas do domínio. O FinToolBench tenta preencher o espaço entre esses dois modos de falha.
O benchmark combina 760 ferramentas financeiras executáveis — 261 endpoints ao vivo do RapidAPI e 499 interfaces do AkShare — com 295 consultas de avaliação cuidadosamente selecionadas, divididas em 166 casos de ferramenta única e 129 casos de múltiplas ferramentas. As ferramentas abrangem ações, títulos, fundos, câmbio, derivativos, macroeconomia e criptomoedas. Criticamente, estas são APIs reais e chamáveis, não stubs simulados. Os autores também introduzem o FATR (Finance-Aware Tool Routing), um agente de linha de base que usa recuperação BGE-M3 (20 principais candidatos), cartões de ferramentas anotados com atributos financeiros e um planejador ReAct ciente de restrições, limitado a cinco etapas.
Ideias-chave
- A execução não é o gargalo — o raciocínio sobre os resultados é. O GPT-4o tem o maior Conditional Soft Score (CSS = 0,670), o que significa que dá respostas corretas quando chama uma ferramenta com sucesso, mas invoca ferramentas apenas 22,7% das vezes (TIR = 0,227). O Qwen3-8B chama ferramentas 87,1% das vezes, mas obtém a resposta correta apenas 40,4% das vezes quando a chamada é bem-sucedida.
- A incompatibilidade de intenção é a falha de conformidade dominante. A Intent Mismatch Rate (IMR) excede 50% para a maioria dos modelos, o que significa que os agentes emitem rotineiramente chamadas transacionais quando a consulta apenas pede recuperação de informações. Isso é um problema sério em contextos financeiros regulamentados.
- Injetar atributos financeiros ajuda na conformidade sem prejudicar a capacidade. Os cartões de ferramentas da linha de base do FATR — anotando cada ferramenta com frescor, tipo de intenção e domínio regulatório — reduzem chamadas de dados desatualizados (TMR) e violações de domínio (DMR) sem degradar significativamente a taxa de invocação.
- Consultas de múltiplas ferramentas expõem a lacuna de confiabilidade. As 129 consultas de múltiplas ferramentas exigem encadeamento de chamadas e passagem de resultados entre etapas; o desempenho cai substancialmente em comparação aos casos de ferramenta única, consistente com descobertas do FinTrace e do TheAgentCompany.
- Modelos pequenos podem invocar mais que os grandes, mas não raciocinar melhor. O TIR de 0,871 do Qwen3-8B versus 0,227 do GPT-4o mostra que modelos menores são mais propensos a disparar chamadas, mas o CER (Conditional Execution Rate, ou seja, TESR/TIR) de 0,339 para Qwen3-8B versus 0,618 para GPT-4o revela que o GPT-4o é muito mais preciso quando decide chamar uma ferramenta.
O que se sustenta — e o que não se sustenta
A escolha do benchmark de usar APIs genuinamente ao vivo e executáveis é sua principal contribuição, e é substancial. APIs simuladas eram o segredo sujo dos benchmarks de uso de ferramentas: as 16.000 APIs do ToolLLM parecem impressionantes até você perceber que a avaliação usa um LLM como juiz para decidir se uma chamada "teria" funcionado. O FinToolBench evita isso.
As métricas de conformidade (TMR, IMR, DMR) são conceitualmente corretas — agentes financeiros devem saber a diferença entre buscar o preço de fechamento de ontem e iniciar uma negociação — mas a descrição do artigo sobre como essas classificações são aplicadas é superficial. Não está claro se os rótulos de verdade fundamental para tipo de intenção (informacional vs. transacional) foram verificados por especialistas jurídicos ou de conformidade, ou simplesmente atribuídos pelos autores do conjunto de dados. Isso importa muito na prática.
A lista de modelos também é estranhamente estreita: Doubao-Seed-1.6, Qwen3-8B, GLM-4.7-Flash e GPT-4o. Nenhum Claude Sonnet ou Gemini 2.5, que seriam comparações naturais. A tabela de resultados mostra o GPT-4o como um outlier de alta precisão e baixa cobertura; eu gostaria de saber se o comportamento de uso de ferramentas do Claude se aproxima mais do padrão conservador do GPT-4o ou do agressivo do Qwen3-8B.
O conjunto de avaliação de 295 consultas é pequeno para os padrões modernos de benchmarks. Com 760 ferramentas, uma taxa de cobertura de 295 consultas significa que a maioria das ferramentas nunca é testada. O artigo não fornece estatísticas de cobertura por domínio, o que significa que os números principais podem ser impulsionados por um subconjunto de domínios bem cobertos, como ações e macroeconomia.
Por que isso importa para IA em finanças
Agentes de write-back do Beancount — qualquer agente que chame bean-add, patche um arquivo de ledger ou consulte beanquery — enfrentam exatamente os modos de falha que o FinToolBench traz à tona. O problema de incompatibilidade de intenção se mapeia diretamente: um agente do Beancount que emite uma chamada de escrita quando o usuário fez uma pergunta de leitura tem a mesma assinatura de falha que uma violação de IMR. A dimensão de frescor se mapeia na chamada de um estado de ledger em cache desatualizado quando o usuário espera o saldo atual.
A tensão entre precisão e cobertura (GPT-4o vs. Qwen3-8B) também é imediatamente relevante. Para write-back do Beancount, eu preferiria fortemente o comportamento de invocação conservador do GPT-4o — TIR baixo, CER e CSS altos — a um modelo de alta invocação que muitas vezes executa a ferramenta errada. Escritas erradas custam muito mais do que no-ops.
A abordagem do FATR de anotar ferramentas com atributos de conformidade, em vez de confiar no modelo para inferi-los, é um padrão de design que vale a pena adotar. Envolver as ferramentas CLI do Beancount com metadados explícitos sobre se uma chamada é somente leitura ou mutável, e se diz respeito ao estado atual ou arquivado do ledger, é a mesma ideia aplicada em menor escala.
O que ler a seguir
- FinTrace (arXiv:2604.10015) — avaliação em nível de trajetória em 34 categorias de tarefas financeiras com 9 métricas; estende diretamente a avaliação de chamada única do FinToolBench a sequências de múltiplas etapas e ajusta o Qwen-3.5-9B com DPO para melhorar o raciocínio intermediário.
- FinMCP-Bench (arXiv:2603.24943) — 613 amostras em 65 ferramentas financeiras baseadas em MCP, testando invocações de ferramenta única, múltiplas ferramentas e múltiplas interações; o enquadramento MCP é diretamente relevante para interfaces de ferramentas do Beancount.
- ToolLLM (arXiv:2307.16789, ICLR 2024) — o artigo ToolBench contra o qual o FinToolBench se posiciona explicitamente; entender o que a linha de base de API simulada pode e não pode medir esclarece o quanto a executabilidade real do FinToolBench vale.
