FinTrace: Avaliação em Nível de Trajetória de Chamada de Ferramentas de LLM para Tarefas Financeiras

O FinTrace (arXiv:2604.10015) chega uma semana após o FinToolBench, que registrei na última vez, e os dois artigos estão em diálogo direto um com o outro. Enquanto o FinToolBench mede se um agente chama as ferramentas certas, o FinTrace faz a pergunta mais difícil: mesmo quando um agente chama as ferramentas certas, ele realmente raciocina sobre os resultados? Essa distinção é o cerne do artigo e, acredito, o ponto central de todo o problema do agente de write-back do Beancount.

O artigo

Cao et al. apresentam o FinTrace, um benchmark de 800 trajetórias anotadas por especialistas que abrangem 34 categorias de tarefas financeiras do mundo real em níveis de dificuldade fácil, médio e difícil. Os autores constroem sua avaliação em torno de uma rubrica de nove métricas organizadas em quatro eixos: correção da ação (F1 de chamada de ferramenta, relevância da tarefa), eficiência de execução (eficiência de etapa, pontuação de redundância), qualidade do processo (progressão lógica, utilização de informação, pontuação de progresso) e qualidade da saída (taxa de aprovação na tarefa, qualidade da resposta final). Eles avaliam 13 LLMs e também lançam o FinTrace-Training, um conjunto de dados de 8.196 trajetórias de preferência selecionadas para ajuste fino.

A alegação central é que os modelos de fronteira dominaram a seleção de ferramentas, mas falham sistematicamente na etapa mais difícil: usar o que as ferramentas retornam. O benchmark sonda isso com uma escala de 5 pontos para utilização de informação, progressão lógica e pontuação de progresso, além de métricas algorítmicas para F1 de ferramenta e eficiência de etapa.

Ideias principais

• O modelo com melhor desempenho, Claude-Opus-4.6, atinge um F1 de Chamada de Ferramenta de 0,896 — uma seleção forte — mas pontua apenas 3,23/5 em Utilização de Informação, a mais fraca das quatro métricas voltadas para a saída.
• A Taxa de Aprovação na Tarefa do Claude-Opus-4.6 é de 2,65/5, e a Qualidade da Resposta Final é de 3,34/5; mesmo o modelo de topo não produz consistentemente respostas corretas e completas.
• O Qwen-3.5-9B exibe um padrão degenerado: Eficiência de Etapa (1,000) e Redundância (1,000) quase perfeitas porque quase não chama ferramentas, refletido em um F1 de Chamada de Ferramenta de 0,109. Eficiente, mas inútil.
• O treinamento no FinTrace-Training melhora as métricas de processos intermediários (a Progressão Lógica sobe de 2,29 para 2,56 com DPO; a Pontuação de Progresso de 2,00 para 2,30), mas a Qualidade da Resposta Final permanece estagnada — nenhuma variante excede significativamente a média de 1,21 na escala de 1 a 5 para modelos pequenos.
• O DPO supera o SFT na supressão de modos de falha catastrófica: a parcela de pontuações de Progressão Lógica igual a 1 cai de 11,9% (SFT) para 9,5% (DPO).
• A subcategoria universalmente pior em todos os 13 modelos é o QA de Raciocínio, onde o Claude-Opus-4.6 atinge apenas 0,62 no geral — um teto difícil compartilhado até mesmo pelo modelo de fronteira mais forte.

O que se sustenta — e o que não

A descoberta principal — que a seleção de ferramentas e o raciocínio sobre ferramentas são dissociáveis — é bem fundamentada e a rubrica de quatro eixos é uma contribuição genuína. Benchmarks anteriores, como o FinToolBench, param nos rastros de execução; o FinTrace adiciona métricas de qualidade de processo julgadas por LLM que expõem o que acontece no intervalo. O κ de Cohen interavaliador de 0,89 na validação de 100 amostras é encorajador para um benchmark construído parcialmente sobre juízes de LLM.

Dito isso, várias escolhas metodológicas limitam o que posso extrair dos números pelo seu valor nominal. As 34 categorias de tarefas não são enumeradas no artigo principal — elas são adiadas para o Apêndice B — então não posso dizer quão representativas são da prática financeira do mundo real. Os níveis de dificuldade são definidos por classificações percentuais dentro do próprio conjunto de consultas do benchmark, o que é uma medida circular: difícil significa apenas incomum em relação às outras 800 trajetórias, não difícil em qualquer sentido absoluto.

A análise de ajuste fino é frustrante. Treinar um modelo de 9B no FinTrace-Training melhora o raciocínio intermediário, mas a qualidade da resposta final permanece quebrada. O artigo atribui isso a uma "desconexão" entre o processo e a saída, mas não explica o porquê. A explicação mais plausível — de que um modelo de 9B carece da recuperação factual e da capacidade aritmética necessária para tarefas financeiras, independentemente da qualidade da trajetória — não é abordada. Mostrar resultados de DPO apenas para o Qwen-3.5-9B também impossibilita saber se modelos maiores se beneficiam mais.

Também sou cético em relação à agregação da pontuação geral. Combinar métricas algorítmicas (F1 ∈ [0,1]) com pontuações julgadas por LLM em escalas Likert de 1 a 5, normalizando para [0,1] e tirando a média, mistura tipos de falhas muito diferentes. Um modelo que chama as ferramentas erradas inteiramente não é o mesmo tipo de problema de um modelo que chama as ferramentas certas e depois ignora a saída.

Por que isso importa para a IA financeira

A descoberta central mapeia-se diretamente no problema de write-back do Beancount. Um agente que chama de forma confiável as ferramentas CLI do Beancount corretas, mas depois interpreta mal a saída — por exemplo, analisando uma resposta de balanço patrimonial e fazendo um lançamento na conta errada — é pior do que nenhuma automação: produz entradas de livro-razão confiantemente erradas que parecem corretas para um revisor casual.

A métrica de Utilização de Informação é a que eu acompanharia com mais cuidado para qualquer agente Beancount. O fato de o melhor modelo disponível pontuar 3,23/5 nisso em um benchmark financeiro controlado deve ser uma restrição impositiva para qualquer implantação em produção. Isso argumenta a favor da revisão humana obrigatória de qualquer operação de write-back, pelo menos até vermos essa pontuação consistentemente acima de 4,0.

O FinTrace também confirma o que o ReDAct sugeriu na semana passada: a arquitetura correta não é o raciocínio LLM de ponta a ponta, mas um pipeline que externaliza a verificação. Um agente que seleciona bem as ferramentas (F1 de Ferramenta ~0,9) e depois passa os resultados para uma etapa de validação separada antes de agir é mais defensável do que um que tenta raciocinar sobre a saída bruta das ferramentas em uma única passagem.

O que ler a seguir

• FinMCP-Bench (arXiv:2603.24943): o artigo complementar que utiliza o MCP como padrão de interface de ferramenta, o próximo na lista de leitura — diretamente comparável ao FinTrace, mas construído sobre uma camada de protocolo diferente.
• "Benchmarking LLM Tool-Use in the Wild" (arXiv:2604.06185): apareceu simultaneamente e avalia a chamada de ferramentas fora das finanças; esclareceria se a lacuna de utilização de informação é específica do domínio ou geral.
• "Data-Driven Function Calling Improvements in Large Language Model for Online Financial QA" (arXiv:2604.05387): visa os mesmos modos de falha de chamada de ferramenta de uma perspectiva de dados de treinamento e pode explicar o que falta ao DPO do FinTrace-Training.