O artigo​

Zhao, Jin, Li e Gao, da Universidade de Pequim, apresentam o FinRAGBench-V, um benchmark bilíngue construído a partir de documentos financeiros reais: relatórios de pesquisa, demonstrações financeiras, prospectos, artigos acadêmicos, revistas e notícias. O corpus de recuperação é substancial — 60.780 páginas em chinês e 51.219 páginas em inglês em aproximadamente 1.100 documentos por idioma — emparelhado com 1.394 pares de P&R anotados por humanos abrangendo sete categorias de perguntas: inferência de texto, extração de gráficos e tabelas, cálculo numérico, consultas sensíveis ao tempo e raciocínio multi-página. Além do conjunto de dados, a contribuição central do artigo é o RGenCite, um sistema de referência que gera respostas juntamente com citações visuais ao nível de pixel na forma de coordenadas de caixas delimitadoras (bounding-box) que marcam as regiões específicas do documento que sustentam cada afirmação.

Ideias principais​

• A recuperação multimodal domina a de apenas texto por uma margem esmagadora: o ColQwen2, um recuperador de visão-linguagem construído em embeddings de imagens de página, atinge um Recall@10 de 90,13% (chinês) e 85,86% (inglês). Os melhores recuperadores baseados em texto, BM25 e BGE-M3, chegam a cerca de 42,71%. Esta lacuna não é um erro de arredondamento.
• A precisão da geração é baixa mesmo para modelos de fronteira: o GPT-4o em inglês atinge 43,41% de precisão (ROUGE 24,66); o o4-mini em chinês atinge 58,13% (ROUGE 38,55). Estes são modelos proprietários de topo com uma forte recuperação implementada.
• A citação ao nível de página funciona; ao nível de bloco, não: o recall ao nível de página situa-se entre 75–93% para os melhores modelos. O recall ao nível de bloco — saber qual célula de tabela específica ou região de gráfico fundamenta uma afirmação — cai para 20–61%. Esta é a lacuna crucial para a auditabilidade.
• O raciocínio numérico e a inferência multi-página quebram os modelos primeiro: perguntas que exigem cálculos entre páginas ou períodos temporais são onde a precisão cai mais drasticamente em todos os sistemas testados.
• Modelos proprietários superam substancialmente as alternativas de código aberto: a lacuna entre APIs fechadas e código aberto é maior aqui do que na maioria dos benchmarks de PLN, sugerindo que o raciocínio financeiro visual permanece sem solução para modelos abertos.
• A autoavaliação para citações é imperfeita: o avaliador de citação por recorte de imagem atinge Pearson r = 0,68 com julgamentos humanos — razoável, mas não fiável o suficiente para confiar totalmente sem amostragem.

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

A descoberta sobre recuperação é o resultado mais credível do artigo. Uma lacuna de quase 50 pontos percentuais entre recuperadores multimodais e apenas de texto em mais de 60 mil páginas é demasiado grande para ser ignorada. Quando se faz o OCR de um documento financeiro antes da indexação, destroem-se os sinais de layout estrutural — em que coluna um número aparece, se a legenda de uma figura modifica a interpretação de uma tabela — que acabam por ser enormemente importantes para a recuperação.

Os números de geração são honestos, mas difíceis de interpretar isoladamente. Os autores não isolam quanto da lacuna de precisão é atribuível a erros de recuperação versus falhas de geração. Dado que o Recall@10 já é de 85,86% para o inglês, uma fração significativa das falhas deve ser do lado da geração e não da recuperação. Conhecer essa repartição esclareceria se o gargalo é o raciocínio multimodal ou algo mais fundamental sobre como os MLLMs lidam com a linguagem financeira.

O conjunto de avaliação de 1.394 pares de P&R é pequeno para o âmbito do benchmark. Dividido por sete categorias e dois idiomas, alguns segmentos têm bem menos de 200 exemplos. A significância estatística das descobertas ao nível de categoria é deixada implícita. Isto não é invulgar para um artigo de benchmark, mas significa que seria fácil construir comparações selecionadas manualmente (cherry-picked).

O protocolo de avaliação de citações é uma contribuição interessante, mas o Pearson r = 0,68 com classificações humanas não é suficientemente forte para tratar a autoavaliação como a verdade absoluta (ground truth) para a fundamentação ao nível de bloco. Os autores reconhecem isso; trabalhos futuros sobre melhores métricas de citação são explicitamente sinalizados.

Por que isto é importante para a IA nas finanças​

O Beancount opera sobre ficheiros de livro-razão (ledger) em texto simples, o que torna o RAG apenas de texto defensável para consultar transações passadas. Mas a tarefa contabilística mais ampla envolve documentos que não são, decididamente, em texto simples: PDFs de extratos bancários, faturas digitalizadas, imagens de recibos, relatórios anuais com tabelas e gráficos incorporados. No momento em que um agente Beancount precisa de reconciliar uma entrada do livro-razão com um documento de origem — verificar se uma determinada cobrança corresponde à fatura em arquivo — está a realizar exatamente a tarefa que o FinRAGBench-V avalia.

A descoberta da citação ao nível de bloco é o que mais importa para este caso de uso. Se um agente deve justificar uma entrada no livro-razão apontando para um item de linha específico num PDF, e o melhor sistema disponível alcança apenas 20–61% de recall ao nível de bloco, isso não está pronto para auditoria. Qualquer pipeline Beancount que lide com documentos de origem digitalizados necessita de revisão humana (human-in-the-loop) até que este número melhore substancialmente.

A lacuna na modalidade de recuperação também argumenta fortemente contra pipelines de puro texto para a ingestão de documentos. Uma imagem de recibo transporta informações de layout — campos de valor, nomes de fornecedores, posições de itens de linha — que o OCR destrói. Essa informação de layout é precisamente o que distingue um total de linha de um valor de imposto, e o FinRAGBench-V mostra que os recuperadores multimodais exploram isso de formas que os recuperadores de texto não conseguem.

O que ler a seguir​

• ColPali: Efficient Document Retrieval with Vision Language Models — o antecessor do ColQwen2 que estabeleceu a abordagem de embedding visual de páginas sobre a qual o melhor recuperador do FinRAGBench-V foi construído [arXiv:2407.01449, ECCV 2024]
• M3DocRAG: Multi-modal Retrieval is What You Need for Multi-page Multi-document Understanding — aborda P&R visual de múltiplos documentos com uma estrutura flexível que lida com raciocínio visual de salto único (single-hop) e múltiplos saltos (multi-hop) entre páginas [arXiv:2411.04952]
• Benchmarking Temporal-Aware Multi-Modal RAG in Finance — um benchmark complementar de 2025 que avalia a sensibilidade temporal no RAG multimodal financeiro, diretamente complementar à categoria de perguntas sensíveis ao tempo do FinRAGBench-V [arXiv:2503.05185]

O artigo​

O EnterpriseArena é uma simulação de 132 meses (11 anos) de alocação de recursos em nível de CFO. Cada passo representa um mês. O agente recebe observações parciais das finanças da empresa, documentos de negócios anonimizados e sinais macroeconômicos extraídos de dados do FRED, CBOE e S&P Global. Ele possui um orçamento de 20 chamadas de ferramentas por mês, distribuídas em quatro operações — verificar a posição de caixa, revisar registros financeiros, analisar condições de mercado e projetar fluxos de caixa — e deve escolher uma de três ações: fechar os livros (reconciliação), solicitar financiamento (capital próprio ou dívida, com resultados estocásticos) ou passar. A restrição principal é que o saldo de caixa da empresa deve permanecer não negativo em todos os passos; a violação encerra o episódio com uma pontuação de zero. Sujeito à sobrevivência, o agente maximiza a avaliação final da empresa sob a fórmula Rev_T × 5 + Cash_T − 5.000 × N_tools, que penaliza explicitamente o uso excessivo de ferramentas.

Onze LLMs foram avaliadas, incluindo Gemini-3.1-Pro, Claude-Haiku-4.5, GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Qwen3.5-397B e Qwen3.5-9B, juntamente com uma linha de base de especialistas humanos validada por dois profissionais de finanças com 8 e 14 anos de experiência, respectivamente.

Ideias principais​

• As taxas de sobrevivência variam drasticamente entre os modelos: Qwen3.5-9B sobrevive a 80% das execuções, Gemini-3.1-Pro a 50%, Claude-Haiku-4.5 e GLM-5 a 20% cada, e GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Mistral-Small-24B e Mixtral-8x7B a 0%. A média geral das LLMs é de 26%.
• Modelos maiores não superam necessariamente os menores: Qwen3.5-9B (9B parâmetros, 80% de sobrevivência, valoração terminal de $78,8M) supera decisivamente o Qwen3.5-397B (397B parâmetros, 20% de sobrevivência) e o GPT-5.4 (0% de sobrevivência).
• A lacuna em relação aos humanos é grande: a linha de base humana atinge 100% de sobrevivência e uma valoração terminal de $152,2M ± $29,6M; a média das LLMs é de $28,2M com 26% de sobrevivência.
• O fechamento de livros é o gargalo crítico: especialistas humanos fecham os livros (reconciliam) em 94,3% dos passos; a média das LLMs é de 19,3%. Esta é a ação que produz demonstrações financeiras confiáveis e permite decisões subsequentes racionais.
• Coleta de informações sem ação é letal: o Qwen3.5-397B usa ferramentas de análise de mercado e previsão em uma taxa alta durante toda a simulação, mas quase nunca fecha os livros (0,0% de taxa de fechamento) e quase nunca solicita financiamento, morrendo por exaustão de caixa apesar de "saber" o que estava acontecendo.
• A penalidade do orçamento de ferramentas é importante: a fórmula de pontuação pune ativamente agentes que verificam compulsivamente em vez de agir, uma restrição que espelha o custo de oportunidade real.

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

O design de objetivo duplo — sobrevivência como uma restrição rígida mais a avaliação terminal — é uma das escolhas mais fortes em benchmarks de agentes recentes. Reflete como os CFOs reais operam: você não pode otimizar o crescimento se estiver sem dinheiro. A anonimização de datas do calendário e identidades de empresas impede que os modelos façam correspondência de padrões com base em resultados históricos memorizados, o que é uma melhoria metodológica genuína sobre benchmarks financeiros que usam tickers e datas reais.

A taxonomia de modos de falha identificada pelos autores através de estudos de caso é crível: o GPT-5.4 atinge uma taxa de aprovação de 99,1% (o que significa que toma uma ação em quase todos os passos ao não fazer nada), enquanto o Qwen3.5-397B confunde análise com ação. Esses são modos de falha comportamentalmente distintos com remediações diferentes.

O que me convence menos: o ambiente macro estocástico usa ruído gaussiano para aproximar choques de mercado, o que os próprios autores reconhecem que não pode replicar eventos de cisne negro ou a irracionalidade humana. O orçamento de 20 chamadas de ferramenta por mês também é um tanto arbitrário — CFOs reais não enfrentam esse tipo de restrição de taxa de consulta em sua própria memória, o que levanta a questão de se o benchmark está medindo o julgamento financeiro de longo prazo ou algo mais próximo de RAG sob pressão de recursos. A estrutura de agente único é outra limitação explícita que os autores citam: CFOs reais operam dentro de hierarquias de controllers, analistas de FP&A e equipes de tesouraria, e o artigo não tenta simular isso.

A descoberta de que o tamanho do modelo não prevê a sobrevivência é impressionante e provavelmente genuína, mas o mecanismo não é bem explicado. Os autores observam isso sem detalhar totalmente se é uma falha de seguimento de instruções, coerência de contexto longo ou calibração de risco.

Por que isso importa para a IA financeira​

A ação de fechamento de livros no EnterpriseArena é essencialmente a asserção balance do Beancount e a etapa de reconciliação do razão — o momento em que o agente se compromete com uma visão real do estado financeiro antes de agir. A descoberta de que as LLMs pulam isso 80% das vezes mapeia diretamente para o problema de segurança de gravação (write-back): um agente que evita a reconciliação antes de agir é um agente que age com base em um estado obsoleto ou alucinado. Para a automação do Beancount, isso sugere que a etapa de reconciliação deve ser obrigatória e verificável — não opcional — em qualquer loop de agente.

O horizonte de 132 meses também é diretamente análogo à gestão de um razão por vários anos. A descoberta de que a consciência situacional sustentada se degrada ao longo do tempo é a mesma degradação que esperaríamos em um agente de Beancount gerenciando cinco anos de histórico de transações: mesmo que o agente tenha todos os dados em contexto, ele pode não agir sobre eles de forma coerente no mês 60. Isso sugere que pontos de verificação periódicos de reconciliação forçada — e não apenas consultas reativas — são necessários em sessões de agentes de Beancount de longa duração.

A armadilha de coleta de informações em que o Qwen3.5-397B cai é um aviso de design útil: agentes equipados com muitas ferramentas de recuperação podem preferir a recuperação ao compromisso, especialmente quando o custo de uma ação errada (corrupção do razão) é alto. Restrições de orçamento de ferramentas do tipo que o EnterpriseArena usa poderiam ajudar a impor disciplina de ação em agentes de gravação do Beancount.

O que ler a seguir​

• EcoGym (arXiv:2602.09514) — benchmark econômico complementar de longo horizonte em ambientes de Vending, Freelance e Operation ao longo de mais de 1.000 passos; nenhum modelo domina em todos os três, sugerindo que os modos de falha no EnterpriseArena não são idiossincráticos de um único design de benchmark.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) — reformula o design de fluxo de trabalho como uma busca em espaço de código com MCTS e feedback de LLM; se o EnterpriseArena mostra que comportamentos de agentes projetados manualmente falham, o AFlow é o próximo passo óbvio para descobrir melhores pipelines automaticamente.
• ToolLLM: Facilitating Large Language Models to Master 16,000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — a estrutura fundamental de treinamento e avaliação de uso de ferramentas; entender como o comportamento de chamada de ferramentas é aprendido no ToolLLM esclarece se a falha de evitação de ação no EnterpriseArena é um problema de treinamento ou de prompting.

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.

O artigo​

Geng, Cai, Wang, Koeppl, Nakov e Gurevych analisam a literatura emergente sobre estimativa de confiança e calibração de LLMs em tarefas que variam de Q&A de múltipla escolha a geração aberta e tradução automática. O problema central: LLMs podem ser tanto altamente precisos quanto completamente não confiáveis de formas difíceis de distinguir externamente. O levantamento organiza o espaço de soluções em dois ramos principais — métodos white-box que exploram o acesso aos estados internos do modelo, e métodos black-box que tratam o modelo como opaco — e, dentro de cada um, distingue entre estimar a confiança e calibrá-la post hoc.

O artigo foi publicado na NAACL 2024 (páginas 6577–6595), revisado em março de 2024 a partir de uma submissão de novembro de 2023 por uma equipe abrangendo a TU Darmstadt, MBZUAI e a Universidade de IA Mohamed bin Zayed.

Ideias-chave​

• Confiança white-box via logits: A abordagem mais simples utiliza probabilidades ao nível de token ou a verossimilhança logarítmica (log-likelihood) normalizada pelo comprimento como um sinal de confiança. Esses métodos funcionam, mas enfrentam uma ambiguidade fundamental: uma baixa probabilidade de token pode refletir baixa confiança factual ou apenas um fraseado incomum — o modelo pode estar incerto sobre a escolha da palavra enquanto tem certeza sobre o fato subjacente.

• Confiança black-box baseada em consistência (SelfCheckGPT): Manakul et al. (EMNLP 2023) amostram múltiplas conclusões e pontuam sua consistência mútua usando BERTScore, NLI ou sobreposição de n-gramas. Não é necessário acesso a logits. A percepção principal: para fatos que o LLM conhece bem, amostras repetidas convergem; para fatos alucinados, elas divergem.

• Entropia semântica: Farquhar et al. (Nature, 2024) agrupam respostas semanticamente equivalentes antes de calcular a entropia. Um LLM pode formular "Paris" e "a capital francesa" de forma diferente — a entropia de tokens bruta trata estas como divergentes, a entropia semântica não. Este é um passo qualitativo à frente da consistência ao nível de token que o levantamento contextualiza.

• A confiança verbalizada está quebrada: Quando solicitados a fornecer uma porcentagem de confiança, os modelos colapsam em excesso de confiança. O trabalho empírico (Groot et al., TrustNLP na ACL 2024) descobriu que o GPT-3, GPT-3.5 e Vicuna apresentam um Erro de Calibração Esperado (ECE) médio superior a 0,377 para confiança verbalizada, com previsões agrupadas na faixa de 90–100%, independentemente da precisão real. Mesmo o GPT-4 — o modelo melhor calibrado avaliado — atinge um AUROC de apenas ~62,7% ao usar confiança verbalizada para discriminar respostas corretas de incorretas, pouco acima do acaso.

• Técnicas de calibração variam por tarefa: Para classificação, a calibração contextual (subtraindo o viés de classe prior estimado com um prompt vazio "[N/A]") e a remoção de viés de posição (PriDE) abordam vieses sistemáticos conhecidos. Para geração, a Calibração de Verossimilhança de Sequência (SLiC) ajusta os modelos em conclusões classificadas. O escalonamento de temperatura (temperature scaling) — a correção post-hoc mais simples — continua competitivo em muitos cenários.

• Não existe um benchmark unificado: A observação estrutural mais contundente do levantamento: não existe um único benchmark que abranja métodos de estimativa de confiança em diferentes tarefas e domínios. Isso torna quase impossível comparar métodos de forma rigorosa. A área está comparando alhos com bugalhos.

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

A taxonomia é sólida. A distinção entre white-box e black-box é genuinamente útil para o design de sistemas, e o tratamento dos métodos baseados em logits é honesto quanto aos seus limites — os autores observam diretamente que a probabilidade do token confunde a confiança factual com a incerteza lexical. Profissionais da área subestimam essa confusão.

Onde o levantamento me frustra: ele é amplamente descritivo. Quase não há benchmarks experimentais comparando os métodos diretamente, e os autores reconhecem isso explicitamente como uma limitação. Saio com um mapa claro do espaço de design, mas sem orientação sobre qual método usar para uma nova tarefa.

Os resultados de confiança verbalizada — o AUROC de ~62,7% do GPT-4 em sua própria confiança declarada — deveriam ser conhecimento canônico para qualquer pessoa que implante LLMs em produção. Não são. As pessoas ainda enviam prompts que perguntam "em uma escala de 1 a 10, quão confiante você está?" e tratam a resposta como significativa. Não é.

O levantamento também é superficial na questão da calibração via RLHF: o pós-treinamento com feedback humano torna os modelos melhor ou pior calibrados? Há evidências em ambos os sentidos, e o levantamento evita o assunto em grande parte.

Por que isso importa para a IA em finanças​

O ReDAct baseia sua estratégia de segurança em ter um sinal de incerteza calibrado do modelo barato. O levantamento deixa claro o quão difícil isso realmente é. Sinais baseados em logit estão disponíveis em ambientes white-box, mas confundem incerteza lexical e factual. Métodos baseados em consistência funcionam em ambientes black-box, mas exigem múltiplas amostras por decisão — o que é caro para um agente de write-back do Beancount de alto rendimento que processa um lote de lançamentos de transações.

A descoberta mais aplicável para o Bean Labs: a entropia semântica agrupa respostas semanticamente equivalentes antes de pontuar a consistência, que é precisamente o que importa para lançamentos contábeis onde um modelo pode expressar a mesma relação de débito/crédito em múltiplas formas sintaticamente distintas. Um agente do Beancount deve usar agrupamento semântico sobre conclusões de lançamentos contábeis amostradas — e não a variância bruta ao nível de token — para detectar quando está alucinando o nome de uma conta ou um valor.

A falha de calibração da confiança verbalizada é um alerta direto para qualquer interface de usuário que apresente "quão confiante está a IA?" ao usuário: não confie no número que o modelo produz. Use um calibrador externo ou um método baseado em consistência, ou simplesmente não apresente essa informação.

O que ler a seguir​

• Farquhar et al., "Detecting hallucinations in large language models using semantic entropy," Nature, 2024 — o método mais rigoroso que surge desta estrutura de levantamento; vale a pena ler na íntegra em vez de apenas pelo resumo do levantamento.
• Manakul et al., "SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection for Generative Large Language Models," EMNLP 2023 (arXiv:2303.08896) — o método canônico baseado em consistência; essencial para entender antes de implantar qualquer sinal de confiança black-box.
• Groot et al., "Overconfidence is Key: Verbalized Uncertainty Evaluation in Large Language and Vision-Language Models," TrustNLP na ACL 2024 (arXiv:2405.02917) — a auditoria empírica mais completa de como a confiança verbalizada falha em diferentes modelos e tarefas.

O artigo​

Saibo Geng, Hudson Cooper, Michał Moskal e colegas da Microsoft Research apresentam o JSONSchemaBench, um benchmark de 9.558 esquemas extraídos de fontes reais de produção: assinaturas de chamada de função da GlaiveAI, repositórios do GitHub estratificados por complexidade de trivial a ultra, configurações da API do Kubernetes, esquemas de análise de eventos Snowplow e a coleção JSONSchemaStore. Eles avaliam seis frameworks de decodificação restrita — Guidance, Outlines, Llamacpp, XGrammar, OpenAI Structured Outputs e Gemini — em três eixos: cobertura (qual fração de esquemas o framework consegue lidar), eficiência (sobrecarga de tokens por segundo em relação à geração irrestrita) e qualidade (precisão da tarefa posterior). A grade de avaliação também inclui o conjunto oficial de testes do JSON Schema (JSON Schema Test Suite), que documenta 45 categorias de recursos que qualquer mecanismo em conformidade deve suportar.

A alegação central é que a complexidade do esquema é a variável decisiva que separa frameworks capazes de frágeis, e que nenhum framework único domina em todos os três eixos.

Principais ideias​

• A cobertura desmorona sob a complexidade do esquema. Em esquemas simples da GlaiveAI, todos os frameworks pontuam acima de 86%. Mas em esquemas GitHub-Hard — aninhamento de vários níveis, definições recursivas, restrições de padrão complexas — o Guidance cai para 41%, o Llamacpp para 39%, o XGrammar para 28% e o Outlines para catastróficos 3%. A OpenAI atinge apenas 9% no GitHub-Hard, e o Gemini não produz nenhuma saída válida em esquemas de média complexidade ou superiores.
• O Kubernetes expõe uma fraqueza específica no XGrammar. Apesar das alegações de velocidade do XGrammar, ele atinge apenas 7% de cobertura em esquemas do Kubernetes, provavelmente porque esses esquemas dependem de padrões dependentes do contexto que a pré-computação independente de contexto do XGrammar não consegue gerenciar. A cobertura contra um benchmark que inclui configurações do Kubernetes não é opcional para agentes de produção.
• Ser sub-restrito é mais perigoso do que uma falha de compilação. O XGrammar exibe 38 falhas sub-restritas contra o JSON Schema Test Suite — o que significa que ele emite JSON que viola o esquema declarado enquanto relata sucesso silenciosamente. O Guidance tem apenas 1 falha desse tipo. Para um agente de gravação (write-back), um erro de compilação é detectado no momento do design; uma falha sub-restrita corrompe os dados em tempo de execução sem qualquer sinal.
• O avanço rápido (fast-forwarding) do Guidance oferece um ganho real de 50% na velocidade. Quando sequências determinísticas longas estão presentes (por exemplo, nomes de campos em uma estrutura de objeto fixa), o Guidance pode avançar vários tokens por etapa de decodificação. No Llama-3.1-8B em uma A100, o Guidance roda de 6 a 9 ms por token de saída, enquanto a geração irrestrita roda de 15 a 16 ms. O Outlines é mais lento que a geração irrestrita, operando de 30 a 46 ms, em grande parte devido à compilação inicial do seu autômato, que leva de 3 a 8 segundos por esquema.
• A decodificação restrita melhora modestamente a precisão do raciocínio. No GSM8K (matemática), o Guidance eleva a precisão de 80,1% (irrestrito) para 83,8%. No Last Letter e Shuffle Objects, os ganhos estão na faixa de 1 a 3 pontos. Isso contradiz a preocupação amplamente citada de que forçar o formato JSON degrada a qualidade da resposta — mas o tamanho do efeito é pequeno o suficiente para que a escolha do formato não deva orientar a seleção do framework.
• Nenhum framework cobre todas as 45 categorias de recursos do JSON Schema. O Guidance cobre 13, Llamacpp e XGrammar cobrem 1 cada, e o Outlines cobre 0. A implicação prática é que qualquer esquema que use if/then/else, unevaluatedProperties ou definições recursivas $ref se comportará de forma imprevisível, dependendo de qual mecanismo está sob o capô.

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

A contribuição mais forte do benchmark é a obtenção dos esquemas. Avaliações anteriores usavam esquemas triviais ou coleções de fonte única. Incluir configurações do Kubernetes ao lado de assinaturas de chamadas de função é o tipo certo de diversidade adversária. A estratificação de complexidade (de trivial a ultra) também fornece aos profissionais uma curva de calibração: se seus esquemas se parecem com chamadas de função da GlaiveAI, o XGrammar ou o Guidance servem bem; se eles se parecem com manifestos do Kubernetes, suas opções diminuem rapidamente.

A principal fraqueza é a avaliação gulosa (greedy) de amostra única. Medir a cobertura com uma geração por esquema subestima a capacidade real — um framework pode falhar 20% das vezes, mas ter sucesso em uma nova tentativa. O artigo reconhece isso, mas não relata números de pass@k amostrados por temperatura, o que importaria para sistemas de produção que realizam tentativas em caso de falha.

A comparação também mistura modelos incomparáveis. Frameworks de código aberto (Guidance, Outlines, Llamacpp, XGrammar) são testados no Llama-3.2-1B, enquanto a OpenAI e o Gemini executam seus próprios modelos não divulgados. A cobertura de 9% da OpenAI no GitHub-Hard pode refletir tanto a capacidade do modelo quanto a arquitetura de decodificação restrita. Uma comparação justa precisaria de acesso controlado ao modelo — o que os autores obviamente não podem forçar de provedores proprietários.

Por que isso importa para a IA financeira​

Todo agente de gravação (write-back) do Beancount gera saídas estruturadas. Se o agente emite diretivas do Beancount como JSON antes de converter para a sintaxe .beancount, ou se ele chama ferramentas via esquemas JSON, a confiabilidade dessa geração JSON não é um detalhe — é o jogo inteiro. O artigo FinTrace mostrou que modelos de fronteira falham ao raciocinar sobre as saídas de ferramentas; o JSONSchemaBench revela um problema ortogonal: mesmo antes do raciocínio, a camada de formatação pode emitir silenciosamente saídas não conformes.

O resultado do Kubernetes é particularmente revelador para o Beancount. Esquemas de livros-razão (ledgers) não são sacos de chave-valor planos. Hierarquias de contas, metadados de transações e estruturas de tags criam padrões recursivos aninhados semelhantes aos objetos da API do Kubernetes. Um framework que pontua 7% no Kubernetes não está pronto para esquemas complexos de livros-razão, independentemente de quão rápida seja sua sobrecarga por token.

O modo de falha sub-restrito é o que me faria perder o sono. Um agente do Beancount usando XGrammar poderia emitir uma transação que passa na verificação de validação interna do framework, mas viola o esquema real — e o agente não teria motivo para tentar novamente. A corrupção silenciosa é pior do que uma falha visível.

O que ler a seguir​

• XGrammar (arXiv:2411.15100, Dong et al.) — o artigo técnico por trás de um dos frameworks mais rápidos testados, explicando a divisão de tokens independente/dependente de contexto e por que os esquemas do Kubernetes o estressam.
• Grammar-Aligned Decoding / ASAp (NeurIPS 2024) — mostra que a máscara de tokens na decodificação restrita pode distorcer a distribuição de probabilidade do modelo e propõe um algoritmo de amostragem corrigido; a base teórica para preocupações de qualidade que o benchmark mede apenas indiretamente.
• XGrammar-2 (arXiv:2601.04426) — uma continuação que estende o XGrammar para esquemas dinâmicos em cenários de agentes onde o próprio esquema muda durante uma sessão de vários turnos, diretamente relevante para agentes Beancount que adaptam seu formato de saída com base em quais tipos de conta estão ativos.

O artigo​

Jie Zhu, Yimin Tian e colegas da equipe Alibaba Cloud Qwen DianJin, YINGMI Wealth Management e Soochow University apresentam o FinMCP-Bench, uma suíte de avaliação com 613 amostras cobrindo 10 categorias de cenários financeiros e 33 subcenários. As ferramentas não são simuladas — 65 servidores de ferramentas financeiras reais em conformidade com o MCP sustentam o benchmark, extraídos de logs de produção reais do assistente financeiro Qieman APP. Os autores categorizam as amostras em três tipos: 145 de ferramenta única, 249 de múltiplas ferramentas e 219 multiturno. Eles testam seis modelos: a família Qwen3 com contagens de parâmetros de 4B, 30B e 235B (todos com raciocínio estendido), além de DeepSeek-R1, GPT-OSS-20B e Seed-OSS-36B. As principais métricas de avaliação são Precisão de Ferramenta, Recall de Ferramenta, F1 de Ferramenta e uma Taxa de Correspondência Exata (EMR) que exige que cada chamada de ferramenta em uma sequência esteja exatamente correta.

Ideias fundamentais​

• MCP como substrato de avaliação: usar definições reais de servidores MCP em vez de esquemas de API sintéticos fecha uma lacuna importante entre a avaliação de benchmark e o que os agentes realmente enfrentam em sistemas financeiros implantados.
• Divisão de dificuldade em três níveis: amostras de ferramenta única, multiferramenta e multiturno não são apenas diferenças de quantidade — elas expõem modos de falha qualitativamente diferentes.
• Colapso multiturno: o melhor modelo (Qwen3-235B) alcança 60% de EMR em ferramenta única, 10,62% de EMR em multiferramenta e 3,08% de EMR em multiturno. A queda de única para multiturno é de 20 vezes.
• F1 de Ferramenta é mais tolerante: o mesmo modelo pontua 66,85%, 69,42% e 41,56% de TF1 nas três configurações — mostrando que os modelos frequentemente escolhem as ferramentas certas, mas falham na ordenação, parametrização ou acompanhamento da conversa.
• Recall vence a precisão em ferramenta única: os modelos tendem a chamar ferramentas em excesso quando estão incertos, em vez de chamar a menos, o que é o modo de falha mais seguro para tarefas financeiras, mas ainda significa chamadas de API desperdiçadas e ruído no rastro de raciocínio.
• Escalonamento de tamanho não monotônico: o Qwen3-30B não supera consistentemente o Qwen3-4B em todos os subcenários, quebrando a suposição de que modelos maiores sempre vencem no uso de ferramentas em múltiplas etapas.

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

O uso de logs de produção reais como fonte para exemplos de ferramenta única é a escolha metodológica mais forte aqui. Isso fundamenta o benchmark no comportamento real do usuário, em vez de cenários inventados por pesquisadores, o que é raro na literatura de IA financeira. As amostras multiferramenta e multiturno são estendidas sinteticamente usando grafos de dependência e prompts de interpretação de papéis, o que é razoável dado o custo de rotulagem, mas introduz um risco: o processo de síntese tende a produzir consultas mais limpas e diretas do que as escritas por usuários reais. O EMR de 3,08% no multiturno é alarmante, mas deve ser interpretado com cautela — o EMR exige que a sequência completa esteja exatamente correta, portanto, uma única chamada de ferramenta intermediária errada invalida toda a tarefa. Esse é um padrão de produção rigoroso e possivelmente irrealista; métricas de crédito parcial como o TF1 contam uma história mais detalhada.

O que o artigo não aborda: não há análise sobre se a lacuna de desempenho é primariamente um problema de compreensão de entrada (o modelo interpreta mal o que o usuário quer), um problema de formatação de saída (intenção correta, mas chamada de ferramenta malformada) ou um problema de raciocínio (conclusões intermediárias erradas). Sem essa decomposição, é difícil saber onde investir o esforço de engenharia. O artigo também avalia os modelos isoladamente; não há teste sobre se a adição de uma etapa de verificação ou reflexão altera o cenário multiturno.

O benchmark também está profundamente ligado às 65 ferramentas específicas da Qieman, o que limita a transferência dos resultados para outras plataformas financeiras com inventários de ferramentas diferentes.

Por que isso importa para a IA nas finanças​

O FinMCP-Bench é a avaliação publicada mais próxima do que um agente de escrita (write-back) do Beancount realmente faria: receber uma solicitação do usuário, identificar qual ferramenta (ou cadeia de ferramentas) se aplica, invocá-las em ordem e lidar com os turnos subsequentes. O EMR multiturno de 3,08% é um choque de realidade. Um agente Beancount que gerencia uma correção de livro-razão em várias etapas — por exemplo, reclassificar um conjunto de transações entre contas em um intervalo de datas, depois conciliar e gerar um relatório — é exatamente o tipo de tarefa multiturno e multiferramenta em que os modelos atuais falham quase universalmente pelos padrões de correspondência exata.

O enquadramento do MCP é diretamente relevante: a API Python do Beancount, a interface beanquery e a camada REST do Fava poderiam todos ser encapsulados como servidores MCP. O FinMCP-Bench nos diz que o protocolo não é o gargalo — o raciocínio sobre sequências de chamadas de ferramentas é.

A descoberta de que o recall de ferramentas excede a precisão (modelos chamam em excesso) também importa para a segurança da escrita: um agente que chama a ferramenta de mutação do razão quando apenas uma leitura era necessária poderia corromper o livro-razão silenciosamente. Métricas de avaliação tendenciosas para precisão, e não para recall, devem ser o principal sinal de segurança para agentes de write-back.

O que ler a seguir​

• JSONSchemaBench (arXiv:2501.10868) — avalia a confiabilidade da saída estruturada em 10 mil esquemas JSON; aborda diretamente se as falhas de formatação de chamada de ferramenta no FinMCP-Bench são um problema de decodificação restrita.
• ToolLLM (arXiv:2307.16789, ICLR 2024) — a estrutura fundamental de treinamento para uso de ferramentas contra a qual o FinMCP-Bench se posiciona; entender sua exploração de árvore de busca em profundidade esclarece o que a metodologia de logs de produção do FinMCP-Bench adiciona.
• WildToolBench (arXiv:2604.06185) — avalia o uso de ferramentas em consultas de usuários reais no mundo real; sua descoberta de que nenhum modelo excede 15% de precisão no comportamento selvagem do usuário complementa a abordagem de logs de produção do FinMCP-Bench.

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.

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 de aprendizado de ferramentas financeiras. O enquadramento é direto: as avaliações de IA financeira existentes concentram-se em QA estático sobre documentos, enquanto os benchmarks gerais de uso de ferramentas, como o ToolLLM, tratam as 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 reais da RapidAPI e 499 interfaces do AkShare — com 295 consultas de avaliação rigorosamente selecionadas, divididas em 166 casos de ferramenta única e 129 de múltiplas ferramentas. As ferramentas abrangem os domínios de ações, títulos, fundos, câmbio (forex), derivativos, macro e cripto. Crucialmente, estas são APIs reais e chamáveis, não stubs simulados. Os autores também apresentam o FATR (Finance-Aware Tool Routing), um agente base que utiliza recuperação BGE-M3 (top-20 candidatos), cartões de ferramentas anotados com atributos financeiros e um planejador ReAct ciente de restrições limitado a cinco etapas.

Ideias principais​

• A execução não é o gargalo — o raciocínio sobre os resultados é. O GPT-4o possui a maior Pontuação Suave Condicional (CSS = 0,670), o que significa que fornece respostas corretas quando consegue chamar 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 tem sucesso.
• O desajuste de intenção é a falha de conformidade dominante. A IMR (Taxa de Desajuste de Intenção) excede 50% na maioria dos modelos, o que significa que os agentes rotineiramente emitem chamadas com intenção transacional quando a consulta solicita apenas uma busca informativa. Isso é um problema sério em contextos financeiros regulamentados.
• A injeção de atributos financeiros ajuda na conformidade sem prejudicar a capacidade. Os cartões de ferramentas do agente FATR — anotando cada ferramenta com tempestividade, tipo de intenção e domínio regulatório — reduzem chamadas de dados obsoletos (TMR) e violações de domínio (DMR) sem degradar significativamente a taxa de invocação.
• Consultas multiferramentas expõem a lacuna de confiabilidade. As 129 consultas multiferramentas exigem o encadeamento de chamadas e a passagem de resultados entre etapas; o desempenho cai substancialmente em comparação com os casos de ferramenta única, de forma consistente com as descobertas do FinTrace e TheAgentCompany.
• Modelos pequenos podem superar os grandes em invocação, mas não em raciocínio. A TIR de 0,871 do Qwen3-8B contra 0,227 do GPT-4o mostra que os modelos menores são mais "precipitados", mas a CER (Taxa de Execução Condicional, ou seja, TESR/TIR) de 0,339 para o Qwen3-8B contra 0,618 para o GPT-4o revela que o GPT-4o é muito mais preciso quando decide chamar uma ferramenta.

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

A escolha do benchmark de usar APIs genuinamente reais e executáveis é sua principal contribuição, e é uma contribuição real. APIs simuladas têm sido 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 de se uma chamada "teria" funcionado. O FinToolBench evita isso.

As métricas de conformidade (TMR, IMR, DMR) estão conceitualmente corretas — agentes financeiros precisam 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 é rasa. Não está claro se os rótulos de verdade fundamental para o tipo de intenção (informativa 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 restrita: Doubao-Seed-1.6, Qwen3-8B, GLM-4.7-Flash e GPT-4o. Nenhum Claude Sonnet ou Gemini 2.5, que teriam sido comparações naturais. A tabela de resultados mostra que o GPT-4o é um ponto fora da curva de precisão com baixa cobertura; eu gostaria de saber se o comportamento de uso de ferramentas do Claude se aproxima 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 dos benchmarks modernos. Com 760 ferramentas, uma taxa de cobertura de 295 consultas significa que a maioria das ferramentas nunca é testada. O artigo não relata 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 macro.

Por que isso importa para a IA financeira​

Agentes de gravação (write-back) do Beancount — qualquer agente que chame bean-add, aplique patches em um arquivo de livro-razão ou consulte o beanquery — enfrentam exatamente os modos de falha que o FinToolBench revela. O problema do desajuste de intenção se traduz diretamente: um agente Beancount que emite uma chamada de gravação quando o usuário fez uma pergunta de leitura tem a mesma assinatura de falha que uma violação de IMR. A dimensão da tempestividade mapeia para o problema de chamar um estado de livro-razão em cache obsoleto quando o usuário espera o saldo atual.

A tensão entre precisão e cobertura (GPT-4o vs Qwen3-8B) também é diretamente relevante. Para gravação no Beancount, eu preferiria muito mais o comportamento de chamada conservador do GPT-4o — TIR baixa, mas CER e CSS altos — do que um modelo de alta invocação que executa frequentemente a ferramenta errada. Gravações falsas são muito mais caras do que operações nulas (no-ops).

A abordagem 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 é apenas de leitura ou de mutação, e se ela toca no estado atual ou arquivado do livro-razão, é a mesma ideia aplicada a um escopo menor.

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 para 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 sobre 65 ferramentas financeiras baseadas em MCP, testando invocação de ferramenta única, multiferramenta e de múltiplos turnos; o enquadramento MCP é diretamente relevante para as interfaces de ferramentas do Beancount.
• ToolLLM (arXiv:2307.16789, ICLR 2024) — o artigo do ToolBench contra o qual o FinToolBench se posiciona explicitamente; entender o que a base de APIs simuladas pode e não pode medir esclarece o quanto a executabilidade do FinToolBench realmente agrega.

O artigo​

O OmniEval constrói uma grade de avaliação bidimensional: cinco classes de tarefas (QA extrativo, raciocínio multi-hop, QA de contraste, QA de formato longo e QA conversacional) cruzadas com 16 tópicos financeiros (mercados de ações, banco de investimento, fundos, seguros de propriedade e outros). O resultado é um benchmark estruturado com 11,4 mil exemplos de teste gerados automaticamente, 1,7 mil exemplos anotados por humanos e um corpus de recuperação de 362 mil documentos reunidos de seis fontes de dados financeiros chineses (BSCF-DB com 193 mil documentos, FinGLM com 55 mil, BAAI-Fin com 48 mil, coletas oficiais da web, PDFs e conteúdo financeiro da Wikipédia). O benchmark também inclui um avaliador LLM ajustado — Qwen2.5-7B-Instruct treinado em 910 instâncias rotuladas por humanos — que pontua a qualidade da geração em precisão, alucinação, completude, utilização e precisão numérica. O artigo foi publicado no EMNLP 2025.

Ideias principais​

• Os casos de teste gerados automaticamente passaram por uma verificação de aceitação humana de 87,47%, o que significa que aproximadamente 1 em cada 8 instâncias geradas foi descartada — uma taxa de ruído não trivial para um benchmark.
• O melhor recuperador (GTE-Qwen2-1.5B) alcançou um MAP de 0,4370 e um MRR de 0,4491 no conjunto gerado automaticamente, o que significa que a passagem melhor classificada está correta em menos da metade das vezes, mesmo com o recuperador mais forte testado.
• A precisão da geração (ACC) em todas as combinações de recuperador-LLM variou de 0,3238 a 0,4476 — a melhor configuração acerta menos da metade das perguntas.
• A precisão numérica (NAC) é a descoberta mais marcante: 0,0659 a 0,3595. O melhor sistema acerta os números financeiros em cerca de 36% das vezes; o pior é próximo de zero.
• O avaliador ajustado alcançou 74,4% de concordância com a anotação humana (κ = 0,6486), superando substancialmente as linhas de base apenas com prompts de 55–71% — mas ainda deixando uma em cada quatro avaliações desalinhada com o julgamento humano.
• O raciocínio multi-hop e o QA conversacional foram consistentemente as classes de tarefas mais difíceis.

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

O design de avaliação em matriz é genuinamente útil. Benchmarks financeiros anteriores (FinanceBench, FinQA, DocFinQA) tratam a avaliação como um eixo único — geralmente a precisão da resposta — e perdem a variação estrutural de como o RAG falha. Saber que um sistema pontua bem em QA extrativo, mas mal em raciocínio multi-hop é acionável; saber que ele tem uma média geral não é. A grade OmniEval torna essa variação visível, e a descoberta de que o desempenho é inconsistente entre os tópicos é exatamente o tipo de resultado que os profissionais precisam ver antes da implantação.

Dito isso, existem limites reais que quero abordar diretamente. O corpus é esmagadoramente chinês: cinco das seis fontes de dados são dados financeiros chineses (BSCF, FinGLM, BAAI-Fin) e a sexta é a Wikipédia chinesa. O artigo não relata resultados divididos por idioma — apenas relata números agregados. Isso torna cada pontuação no artigo suspeita como uma afirmação sobre RAG financeiro em geral, em oposição ao RAG financeiro sobre texto chinês com recuperadores e LLMs especializados em chinês (GTE-Qwen2-1.5B, Qwen2.5-72B, Yi15-34B). Usuários financeiros de língua inglesa não podem usar esses números diretamente.

O avaliador LLM é treinado em 910 instâncias rotuladas. Isso é pouco. A concordância humana de 74,4% em κ = 0,6486 é defensável como ponto de partida, mas significa que o próprio framework de avaliação introduz ruído substancial. Se o benchmark for usado para comparar sistemas que diferem por alguns pontos percentuais, a variância do avaliador ofuscará o sinal.

O pipeline de geração automática — o GPT-4 produz as perguntas de teste, os humanos filtram com 87,47% de aceitação — também levanta uma questão de contaminação que o artigo não aborda: perguntas geradas pelo GPT-4 podem favorecer os pontos fortes dos modelos da classe GPT-4 de formas que desvantagem modelos mais antigos ou menores sistematicamente.

Por que isso importa para a IA financeira​

Os índices de precisão numérica são os números aos quais sempre retorno: 0,0659–0,3595. Se o melhor sistema de RAG testado acerta os números financeiros apenas 36% das vezes em uma avaliação de benchmark, qualquer agente de gravação Beancount construído sobre um pipeline de RAG ingênuo irá corromper os dados do livro contábil. O formato do Beancount é implacável — um valor, data ou nome de conta incorreto produz um erro de análise ou um erro contábil silencioso que pode se propagar pelos anos fiscais. Este benchmark nos fornece evidências concretas de que a recuperação de RAG e a geração de LLM ainda não são confiáveis o suficiente para a gravação direta no livro contábil sem uma camada de validação.

A estrutura de classes de tarefas também se mapeia claramente para os casos de uso do Beancount. O QA extrativo corresponde a simples consultas de saldo. O raciocínio multi-hop corresponde a perguntas como "qual é o meu lucro líquido após impostos no período do Q1 ao Q3?". O QA conversacional corresponde a um usuário refinando iterativamente uma solicitação de conciliação ao longo de uma sessão. A descoberta do OmniEval de que as tarefas multi-hop e conversacionais são as mais difíceis é exatamente a má notícia para o design do agente Beancount: os casos fáceis estão quase bons; os casos realistas são onde o sistema desmorona.

O que ler a seguir​

• ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation (arXiv:2311.09476, NAACL 2025) — o análogo mais próximo de domínio geral para a abordagem de ajuste do avaliador do OmniEval; comparar a metodologia ARES com a do OmniEval esclareceria se as escolhas de design do avaliador-LLM são fundamentadas ou ad hoc.
• RAGEval: Scenario-Specific RAG Evaluation Dataset Generation Framework (ACL 2025, aclanthology.org/2025.acl-long.418) — geração automatizada de cenários para avaliação de RAG; estende a metodologia de autogeração que o OmniEval usa e pode abordar a preocupação com contaminação.
• FinRAGBench-V: A Benchmark for Multimodal RAG with Visual Citation in the Financial Domain (arXiv:2505.17471) — estende a avaliação de RAG para documentos financeiros multimodais (tabelas, gráficos); relevante à medida que os usuários do Beancount têm cada vez mais imagens de recibos e extratos em PDF ao lado de livros contábeis em texto simples.

O artigo​

O levantamento de Xu e Ding (arXiv:2409.01980) propõe organizar a detecção de anomalias e fora de distribuição (OOD) baseada em LLM em duas classes de alto nível: LLMs para Detecção, onde o modelo identifica anomalias diretamente, e LLMs para Geração, onde o modelo aumenta os dados de treinamento ou produz explicações em linguagem natural que alimentam um detector posterior. Cada classe se subdivide ainda mais. A detecção se divide em métodos baseados em prompts (LLMs congelados ou ajustados consultados com prompts em linguagem natural) e métodos baseados em contraste (modelos da família CLIP que pontuam a anomalia comparando fragmentos de imagem com descrições de texto). A geração se divide em métodos centrados em aumento (gerando pseudorrótulos OOD ou amostras sintéticas de minorias) e métodos centrados em explicação (produzindo justificativas em linguagem natural para eventos sinalizados).

A lista de leitura do GitHub que acompanha o artigo cobre aproximadamente 39 artigos: 24 em detecção, 10 em aumento e 5 em explicação.

Ideias principais​

• Métodos baseados em contraste dominam a detecção de anomalias em imagens. O WinCLIP alcança 91,8% e 85,1% de AUROC na classificação e segmentação de anomalias zero-shot no MVTec-AD sem qualquer ajuste específico para o conjunto de dados, o que é competitivo com métodos supervisionados treinados nesse conjunto de dados.
• LLMs congelados enfrentam uma lacuna de modalidade para dados que não são de texto. O levantamento observa explicitamente que "solicitar diretamente prompts a LLMs congelados para detecção de anomalias ou OOD em vários tipos de dados geralmente resulta em um desempenho abaixo do ideal devido à lacuna de modalidade inerente entre texto e outras modalidades de dados".
• Ajustes de LoRA e adaptadores recuperam grande parte dessa lacuna. Métodos como AnomalyGPT e AnomalyCLIP realizam o ajuste fino com técnicas de eficiência de parâmetros e superam substancialmente seus equivalentes congelados.
• A geração como aumento é subutilizada. Pseudorrótulos OOD no nível de legenda gerados pelo BLIP-2 superam as alternativas nos níveis de palavra e descrição na detecção OOD, sugerindo que uma supervisão de texto mais rica importa mesmo para tarefas visuais.
• A geração centrada em explicação é a subcategoria mais recente. Sistemas como Holmes-VAD e VAD-LLaMA vão além dos sinalizadores binários para gerar justificativas em linguagem natural para eventos anômalos, principalmente em vídeos de vigilância.
• Dados tabulares estão quase ausentes. O levantamento cita um método — "Tabular" por Li et al. (2024) — que converte linhas tabulares em prompts de texto e faz o ajuste fino com LoRA, mas não fornece números comparativos.

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

A taxonomia de duas classes é genuinamente limpa e provavelmente a usarei para organizar meu próprio pensamento. A distinção detecção-vs-geração captura uma bifurcação arquitetural real: ou você pede ao LLM para classificar diretamente ou o usa para construir um sinal de treinamento melhor para um detector tradicional.

O que não posso aceitar é o enquadramento do artigo como um levantamento sobre detecção de anomalias de forma ampla. A cobertura está esmagadoramente concentrada em imagens de defeitos industriais (MVTec-AD, VisA) e vídeos de vigilância (UCF-Crime, XD-Violence). Dos cerca de 39 artigos catalogados, quase nenhum aborda dados tabulares ou financeiros. Séries temporais recebem algumas citações. Dados tabulares recebem uma frase. Este não é um mapa de cenário para a Bean Labs — é um mapa de cenário para pesquisadores de visão computacional que desejam usar CLIP para detecção de defeitos.

Os autores reconhecem que "restrições de espaço impedem resumos detalhados de métricas", o que é uma forma educada de dizer que não há tabelas de comparação. Para um artigo de levantamento, a ausência de síntese quantitativa é uma lacuna significativa. Os leitores não podem usar este artigo para decidir qual paradigma é melhor para seu caso de uso sem rastrear cada artigo citado individualmente.

O desafio da alucinação é listado como um problema em aberto, mas o tratamento é superficial — nomeia o risco sem analisar quais paradigmas de detecção são mais ou menos suscetíveis, ou como a geração centrada em explicação poderia tornar as alucinações mais detectáveis por meio de revisão humana.

Por que isso importa para a IA financeira​

Duas subcategorias são relevantes apesar da cobertura focada em imagens. Primeiro, a subcategoria de geração centrada em explicação é exatamente o que os agentes de auditoria do Beancount precisam: não apenas um sinalizador de que um lançamento contábil é anômalo, mas uma frase em linguagem natural explicando o porquê. Auditores financeiros não podem agir sobre uma saída binária. Segundo, o silêncio quase total do levantamento sobre a detecção de anomalias em dados tabulares é, por si só, informativo — confirma que a sequência de AnoLLM, CausalTAD e AD-LLM que venho acompanhando é uma área de fronteira, e não um caminho já percorrido, e que o design de ferramentas de auditoria baseadas em LLM para livros-razão Beancount exige a síntese de insights da detecção de anomalias em visão que ainda não foram portados para contextos tabulares.

O trade-off entre prompting e ajuste (tuning) é a descoberta mais aplicável: o prompting zero-shot funciona como uma primeira aproximação, mas sofre com a lacuna de modalidade; o ajuste fino baseado em LoRA em exemplos rotulados representativos fecha essa lacuna. Para uma implementação do Beancount com exemplos de anomalias rotulados de livros-razão históricos, o caminho do ajuste fino parece mais confiável do que o prompting puro.

O que ler a seguir​

• "Advancing Anomaly Detection: Non-Semantic Financial Data Encoding with LLMs" (arXiv:2406.03614) — utiliza embeddings de sentence-transformers de LLM em lançamentos reais de livros-razão; uma ponte direta do framework deste levantamento para o caso de uso tabular do Beancount.
• "Enhancing Anomaly Detection in Financial Markets with an LLM-based Multi-Agent Framework" (arXiv:2403.19735) — pipeline multi-agente para detecção de anomalias em dados de mercado; o padrão de coordenação multi-agente pode ser transposto para a auditoria de livros-razão.
• AnomalyGPT (arXiv:2308.15366) — LVLM ajustado para detecção de anomalias industriais com localização ao nível de pixel; a leitura deste artigo esclarece o que o "ajuste de LLM para detecção" realmente significa arquiteturalmente, algo que o levantamento descreve, mas não explica.

O artigo​

Hsieh et al. partem de uma observação diagnóstica: LLMs — mesmo aqueles treinados em contextos longos — exibem um padrão de atenção persistente em forma de U. Tokens no início e no final da entrada recebem atenção desproporcionalmente alta, independentemente de serem relevantes, enquanto tokens no meio são sistematicamente subponderados. Os autores conectam isso empiricamente à queda de precisão do tipo "perdido no meio", em vez de tratá-lo como um fenômeno separado.

Sua correção é elegante no conceito. Eles decompõem a atenção em dois componentes aditivos: relevância (o que queremos) e viés posicional (o que não queremos). Para isolar o termo de viés, eles passam um documento "fictício" (dummy) — conteúdo de preenchimento não informativo — através do mesmo contexto em cada posição e registram a distribuição de atenção resultante. Essa atenção do documento fictício aproxima o prior posicional puro. Subtraí-lo das pontuações de atenção reais deixa um resíduo que reflete melhor a verdadeira relevância:

Atenção calibrada = Attn(documento, k) − Attn(fictício, k)

As pontuações reescalonadas são então usadas para reordenar ou reponderar os documentos recuperados antes da etapa final de geração de resposta. Crucialmente, nenhum treinamento é necessário. A calibração é aplicada em tempo de inferência às últimas 16 camadas do decodificador e a todas as cabeças de atenção. O custo é de O(K) passagens para frente (forward passes) adicionais, onde K é o número de documentos recuperados — não trivial, mas previsível.

Ideias principais​

• O viés de atenção em forma de U é intrínseco à arquitetura do modelo e persiste mesmo em modelos explicitamente treinados com objetivos de contexto longo.
• Passar um documento fictício (vazio/ruído) pelo mesmo contexto de recuperação isola o prior posicional; subtraí-lo remove o viés sem qualquer ajuste fino (finetuning).
• O Recall@3 no NaturalQuestion (K=20, documento gold colocado no meio) salta de 20,52% para 68,32% com calibração; com K=10, de 36,38% para 74,27%.
• A precisão de QA de ponta a ponta melhora de 6 a 15 pontos percentuais quando o documento gold está no meio do contexto; as melhorias se mantêm em 22 de 24 configurações experimentais.
• O método supera seis linhas de base de comparação: atenção padrão (vanilla), ordenação por geração de consulta, prompting de geração de relevância, ordenação por atenção (Peysakhovich & Lerer 2023), reordenação de prompts e LongLLMLingua-rk.
• O método foi avaliado no NaturalQuestion (2.655 consultas reais sobre a Wikipedia) e SynthWiki (990 entradas sintéticas geradas pelo GPT-4).

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

O resultado central é impressionante e eu acredito nele. Uma lacuna de Recall@3 de 20,52% → 68,32% para documentos gold no meio do contexto não é o tipo de número que desaparece sob escrutínio — ele mede algo real sobre como a atenção é distribuída. O design sem treinamento é uma vantagem prática genuína: você pode aplicar isso sobre qualquer pipeline RAG existente sem tocar nos pesos do modelo.

Dito isso, tenho algumas ressalvas. Primeiro, a abordagem do "documento fictício" assume que o viés posicional é aproximadamente separável por posição e aditivo — uma decomposição linear que os próprios autores sinalizam como potencialmente simplista. O viés de atenção real pode interagir com o conteúdo de formas não lineares. Segundo, as O(K) passagens para frente extras são precificadas como "aceitáveis", mas nunca avaliadas em termos de latência ou custo. Em um sistema de produção com K=20 recuperações, você está executando 21 passagens para frente em vez de 1 por consulta. Para um agente Beancount fazendo a triagem de centenas de transações, esse multiplicador importa.

Terceiro — e esta é a limitação mais interessante — os autores observam que o viés posicional pode, na verdade, ser útil para certas tarefas. O viés de recência, por exemplo, pode ser o que faz um modelo ponderar corretamente lançamentos recentes de um livro contábil em relação aos mais antigos. Remover o viés indiscriminadamente pode prejudicar tarefas onde a posição é um sinal válido. Isso é reconhecido, mas não estudado.

Finalmente, os experimentos usam o NaturalQuestion e um conjunto de dados sintético. Documentos específicos de finanças — tabelas densas, registros de vários anos, lançamentos contábeis com estrutura repetitiva — são muito diferentes das passagens de domínio aberto da Wikipedia. A calibração precisaria ser validada nessas distribuições antes de afirmar que funcionará para RAG financeiro.

Por que isso importa para a IA financeira​

A conexão direta é clara: todos os logs desde o DocFinQA têm circulado o mesmo problema. Quando um agente Beancount recupera 20 lançamentos relevantes de um livro contábil para responder a uma pergunta como "reconciliar março com o extrato bancário", as entradas do meio da janela recuperada serão sistematicamente subatendidas em relação às entradas no topo e na base do contexto. Isso não é uma falha de recuperação — é uma falha do lado da geração que nenhuma melhoria na ordenação da recuperação corrigirá.

A calibração "encontrado no meio" é uma mitigação plausível que não requer o retreinamento do modelo subjacente e poderia ser aplicada diretamente dentro da etapa de geração de qualquer pipeline de QA de livros contábeis. A preocupação com o custo O(K) é real, mas gerenciável — uma janela de recuperação de 20 documentos com um modelo de tamanho moderado ainda está bem dentro dos limites práticos. O que eu gostaria de ver antes de implantá-lo é uma validação especificamente em dados estruturados do Beancount: a correção posicional ajuda uniformemente ou suprime inadvertidamente o sinal de recência que torna as transações recentes mais confiáveis do que as antigas?

O princípio mais amplo — de que os mecanismos de atenção codificam priors posicionais independentemente da relevância do conteúdo, e que esses priors podem ser calibrados sem retreinamento — vale a pena manter. Isso abre as portas para calibrações semelhantes para outros vieses: viés de frequência de tokens, normalização de comprimento de entrada, viés de verbosidade na geração.

O que ler a seguir​

• "Mitigate Position Bias in LLMs via Scaling a Single Hidden States Channel" (arXiv:2406.02536, ACL Findings 2025) — propõe o escalonamento de uma única dimensão de estado oculto em vez de subtrair pontuações de atenção; vale a pena comparar diretamente com a abordagem do "encontrado no meio".
• "Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey" (arXiv:2409.01980, NAACL 2025) — o próximo na lista de leitura; une os fios de AnoLLM, CausalTAD e AD-LLM em uma taxonomia unificada.
• Liu et al., "Lost in the Middle: How Language Models Use Long Contexts" (arXiv:2307.03172, TACL 2023) — o diagnóstico original ao qual o "encontrado no meio" está respondendo; leitura de base essencial.

O artigo​

O ReDAct (Reason-Defer-Act) baseia-se no paradigma de prompting ReAct e introduz uma arquitetura de agentes de dois modelos. Um modelo pequeno e barato — Qwen3-80B, Llama3.3-70B ou Llama4-Maverick — lida com cada etapa por padrão. Em cada etapa, ele gera um traço de raciocínio e, em seguida, gera uma ação. O sistema mede a incerteza em nível de token apenas sobre a etapa de geração de ação e a compara com um limite calibrado. Se a incerteza exceder esse limite, a etapa é executada novamente por um modelo grande e caro (GPT-5.2, Qwen3-235B ou Qwen3-480B); caso contrário, a ação do modelo pequeno é executada.

As medidas de incerteza são baseadas em teoria da informação e requerem apenas log-probabilidades em nível de token: Probabilidade de Sequência (soma do log-prob negativo), Perplexidade (normalizada pelo comprimento) e Entropia Média de Token (entropia média em todas as posições de token). O limite é calibrado a partir de um conjunto reservado de execuções do modelo pequeno, escolhendo o valor que produz um número alvo de chamadas ao modelo grande por episódio K.

Ideias principais​

• Medir a incerteza na etapa de ação, não na etapa de raciocínio. Um experimento auxiliar em 2.411 etapas do ALFWorld descobriu que a incerteza no nível do raciocínio tem baixo poder discriminativo entre etapas corretas e incorretas; a perplexidade no nível da ação tem ROC-AUC e PRR mensuravelmente maiores como preditor de correção.
• O diferimento por PPL com Qwen3-80B + GPT-5.2 atinge 80,8% ± 1,1% no ALFWorld, superando o GPT-5.2 sozinho com 78,3% ± 1,9%, custando $16,25 vs $45,21 — aproximadamente 64% mais barato.
• ~15% das etapas são diferidas na prática para atingir uma meta de calibração de cerca de 10%; a lacuna surge porque trajetórias com falha (mais curtas) contribuem desproporcionalmente para o orçamento de diferimento.
• O diferimento aleatório na mesma taxa pontua 77,0% — ainda melhor do que apenas o modelo pequeno (68,3%), mas pior do que o diferimento guiado por UQ (quantificação de incerteza). O sinal de incerteza realmente importa, não apenas o ato de chamar mais o modelo grande.
• MiniGrid mostra menos margem de manobra. Qwen3-80B + GPT-5.2 com diferimento PPL atinge 95,0% vs 99,0% para o GPT-5.2 sozinho. O vocabulário menor da tarefa cria um teto mais rígido para a abordagem de diferimento quando o modelo pequeno é estruturalmente inadequado.
• A distribuição do diferimento depende da tarefa. O ALFWorld difere mais em etapas posteriores (histórico de prompt mais longo), enquanto o MiniGrid mostra um padrão bimodal ligado à posição inicial do agente. Isso significa que a calibração de limite fixo generaliza melhor dentro de uma família de tarefas do que entre famílias de tarefas diferentes.

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

A principal descoberta empírica é crível: a perplexidade sobre a string de ação é uma proxy razoável para saber se uma determinada etapa está prestes a dar errado. A decomposição raciocínio/ação no ReAct fornece naturalmente um ponto limpo para anexar um sinal de incerteza, e o experimento auxiliar de predição de correção oferece uma justificativa mecanística genuína para a escolha do design.

O que me convence menos: o resultado "supera o modelo grande sozinho" no ALFWorld. 80,8% ± 1,1% vs 78,3% ± 1,9% se sobrepõem em um desvio padrão. Os autores atribuem isso a forças complementares — o modelo pequeno lida com etapas rotineiras sem a tomada de risco ocasional do modelo grande — mas não há ablação por etapa para verificar essa narrativa. Poderia facilmente ser apenas ruído.

A escolha do benchmark também é limitante. ALFWorld e MiniGrid são simulações domésticas baseadas em texto e navegação em mundo de grade — ambientes estreitos que não exercitam chamadas de ferramentas, execução de código ou recuperação de múltiplos documentos. Se o diferimento calibrado por incerteza se sustenta nesses cenários mais ricos (os cenários relevantes para o Beancount) permanece sem resposta. E a escolha do GPT-5.2 como o modelo grande torna os números de custo difíceis de reproduzir.

O procedimento de calibração tem uma circularidade não abordada: o limite é selecionado na mesma distribuição em que foi calibrado, sem validação em dados não vistos. Os autores reconhecem o desvio de distribuição entre a calibração (execuções do modelo pequeno) e a avaliação (execuções híbridas), mas deixam a robustez do limite para trabalhos futuros.

Por que isso importa para a IA financeira​

Agentes de escrita do Beancount enfrentam exatamente a mesma questão de diferimento em cada transação. Uma compra rotineira de mercado precisa de categorização; um swap incomum de moeda estrangeira com várias pernas e um memorando parcialmente correspondido precisa de um humano. A prática atual é ou automação total (arriscada) ou revisão humana total (cara). O framework do ReDAct sugere um meio-termo viável: executar o modelo barato e escalar quando a perplexidade sobre a entrada candidata no diário exceder um limite calibrado.

O contexto financeiro adiciona duas considerações que o artigo não aborda. Primeiro, o diferimento aqui deve significar frequentemente pausar e perguntar ao usuário, não chamar um LLM maior — o padrão de correção do livro-razão é a intenção do usuário, não uma pontuação de benchmark. Segundo, a irreversibilidade de uma entrada confirmada no Beancount é maior do que um objeto mal posicionado no ALFWorld. O alvo de calibração K provavelmente deve ser ajustado de forma conservadora para uma menor precisão no modelo pequeno antes de diferir, e não o contrário.

O sinal de redução de custo de 64% vale a pena ser levado a sério, mesmo com essas ressalvas. Se um agente Beancount processa um mês de transações e apenas 15% das decisões de categorização precisam do modelo caro, a economia de operar um agente de escrita capaz parece muito melhor.

O que ler a seguir​

• KnowNo (Ren et al., 2023, CoRL): "Robots that ask for help: uncertainty alignment for large language model planners" — usa predição conformal para calibrar uma garantia de cobertura sobre quando pedir ajuda. O ReDAct não se compara a ele; entender o trade-off entre garantias conformais e calibração de limite importa antes de escolher uma abordagem de produção. [arXiv:2307.01928]
• A Survey of Confidence Estimation and Calibration in Large Language Models (Guo et al. atualizado, NAACL 2024) — taxonomia sistemática de confiança verbalizada, métodos baseados em amostragem e calibração pós-hoc; a base teórica para decidir se a perplexidade é a proxy de incerteza correta ou se o escalonamento de logit calibrado teria um desempenho melhor. [arXiv:2311.08298]
• UALA: Uncertainty-Aware Language Agent (Han, Buntine, Shareghi) — aplica um limite de incerteza estruturalmente semelhante à decisão de invocação de ferramenta (chamar uma ferramenta vs. confiar no conhecimento do modelo), reduzindo chamadas de ferramentas em mais de 50%; o complemento direto ao ReDAct para o eixo de uso de ferramentas da incerteza do agente. [https://uala-agent.github.io/]

O artigo​

OpenHands (Wang et al., 2024; ICLR 2025) é uma plataforma de código aberto para construir e avaliar agentes de LLM que atuam como desenvolvedores de software generalistas. Liderado por Xingyao Wang e Graham Neubig em uma equipe de 24 autores, a principal alegação do artigo é que a maioria dos frameworks de agentes existentes é muito limitada para pesquisa (loops de tarefas codificados rigidamente) ou muito limitada para produção (código fechado ou propósito único) para servir como uma base compartilhada para a comunidade de pesquisa. O OpenHands tenta resolver isso fornecendo um runtime padronizado, uma abstração de agente limpa e 15 benchmarks de avaliação integrados sob um único repositório com licença MIT.

O runtime é um ambiente isolado em Docker (sandbox) contendo um shell bash, um servidor Jupyter IPython e um navegador Chromium controlado pelo Playwright. Os agentes interagem por meio de três tipos principais de ação: IPythonRunCellAction para Python, CmdRunAction para comandos de shell e BrowserInteractiveAction para navegação na web. Uma primitiva de coordenação multi-agente, AgentDelegateAction, permite que um agente principal crie sub-agentes especializados. A base padrão é o CodeAct — originalmente publicado como um artigo independente argumentando que o código é o espaço de ação unificado ideal para agentes de LLM — e a plataforma inclui várias implementações de agentes, incluindo um CodeActAgent geral e um BrowsingAgent especializado.

Ideias-chave​

• Código como espaço de ação universal: O CodeAct consolida todas as ações do agente (edições de arquivos, chamadas de API, transformações de dados) em Python ou bash, permitindo que o LLM raciocine no mesmo meio em que foi mais intensamente treinado. Isso contorna a fragilidade dos esquemas JSON que assola agentes baseados em chamadas de função (function-calling).
• Runtime Docker em sandbox: Cada agente é executado em um contêiner isolado, para que os agentes possam executar livremente códigos arbitrários sem comprometer a máquina hospedeira — um pré-requisito para qualquer agente financeiro de produção que possa receber credenciais reais.
• 15 benchmarks em um único suporte: SWE-Bench Lite (reparação de código), HumanEvalFix (correção de bugs), WebArena (navegação na web), GPQA (raciocínio de nível de pós-graduação), GAIA (resolução de tarefas gerais) e mais dez. Ter esses benchmarks no mesmo local evita avaliações enviesadas (cherry-picked).
• CodeActAgent + claude-3.5-sonnet atinge 26% no SWE-Bench Lite e 79,3% no HumanEvalFix; o BrowsingAgent atinge 15,5% no WebArena — resultados competitivos zero-shot sem qualquer treinamento específico para a tarefa.
• Desempenho no GAIA: 32,1% com GPTSwarm, bem abaixo do baseline humano de 92% — consistente com todos os outros benchmarks de agentes gerais que mostram uma lacuna de 60–70 pontos entre humanos e agentes.
• Escala da comunidade: 71,4 mil estrelas no GitHub e mais de 188 contribuidores no momento da submissão ao ICLR; o TheAgentCompany adotou o OpenHands como seu suporte de avaliação, conferindo-lhe o status de infraestrutura de benchmark de fato.

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

O design do runtime em sandbox é uma engenharia sólida. Isolar a execução do agente no Docker é o padrão correto para qualquer sistema que possa vir a ter acesso de escrita em livros-razão financeiros reais, e é genuinamente útil que os benchmarks estejam co-localizados em vez de espalhados por repositórios incompatíveis.

A cobertura dos benchmarks, no entanto, é mais aspiracional do que sistemática. Os 15 benchmarks abrangem tipos de tarefas e níveis de dificuldade vastamente diferentes, sem um framework claro de como os resultados devem ser agregados ou comparados. Relatar 26% no SWE-Bench Lite ao lado de 79,3% no HumanEvalFix no mesmo artigo corre o risco de criar a impressão de que o mesmo agente é simultaneamente medíocre e excelente — as tarefas simplesmente não são comparáveis. Os autores não fornecem uma metodologia fundamentada para agregação de múltiplos benchmarks.

A premissa do CodeAct — de que o código é o formato de ação universal correto — é contestada. Funciona bem para tarefas de desenvolvimento, mas impõe uma camada de mediação Python/bash em cada ação, o que adiciona latência e falha quando a semântica da ação não mapeia de forma limpa para o código (instruções ambíguas do usuário, APIs apenas em linguagem natural). O artigo não faz benchmark contra espaços de ação que não sejam baseados em código para demonstrar que a vantagem é real e não confundida pela base do LLM.

Talvez a lacuna mais importante seja a divisão entre avaliação e implantação. O número de 26% no SWE-Bench vem de um benchmark relativamente limpo e bem especificado. Relatórios da comunidade e tópicos de problemas no GitHub descrevem consistentemente uma confiabilidade muito menor em tarefas complexas ou de longo prazo no mundo real — o mesmo modo de falha documentado pelo TheAgentCompany. O artigo não aborda como medir ou melhorar a robustez sob ruído realista de especificação de tarefas.

Por que isso importa para a IA financeira​

O OpenHands é o que há de mais próximo de um substrato de agente compartilhado para a comunidade. Se o Bean Labs construir uma infraestrutura de avaliação para agentes Beancount, a arquitetura do runtime aqui — sandbox Docker, ações Python/bash, backends de LLM plugáveis — vale a pena ser adotada em vez de reconstruída. A primitiva AgentDelegateAction mapeia-se naturalmente para um pipeline de agente financeiro, onde um orquestrador de alto nível delega para sub-agentes especializados: um para leitura do livro-razão, um para sinalização de anomalias e um para propostas de atualização (write-back) que um humano revisa.

Os números do SWE-Bench e do TheAgentCompany, lidos em conjunto, estabelecem uma base sóbria: mesmo os melhores agentes disponíveis concluem cerca de 26–30% de tarefas de software realistas e inequívocas. A automação de livros-razão financeiros é mais difícil — as transações são frequentemente ambíguas, o raio de impacto dos erros é real e a intenção do usuário é frequentemente subespecificada. A conclusão correta não é que os agentes não estão prontos, mas que as primeiras implantações produtivas serão fluxos de trabalho de escrita única estritamente delimitados (sugestões de categorização, sinalização de conciliação) em vez de edições autônomas de livros-razão em múltiplas etapas.

O que ler a seguir​

• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — combina um modelo barato com um caro e adia para o modelo caro apenas quando a incerteza é alta; aborda diretamente como um agente no estilo OpenHands deve decidir quando encaminhar uma atualização do Beancount para revisão humana.
• FinTrace: Holistic Trajectory-Level Evaluation of LLM Tool Calling for Long-Horizon Financial Tasks (arXiv:2604.10015) — 800 sequências de tarefas anotadas por especialistas em 34 cenários financeiros; a metodologia de avaliação que o OpenHands carece para o uso de ferramentas financeiras de longo prazo.
• FinMCP-Bench: Benchmarking LLM Agents for Real-World Financial Tool Use under the Model Context Protocol (arXiv:2603.24943) — 613 amostras em 65 ferramentas financeiras MCP reais, diretamente relevante para como um agente Beancount construído no runtime do OpenHands seria avaliado em uma implantação MCP real.

O artigo​

O Fin-RATE, publicado em fevereiro de 2026 por Yidong Jiang, Junrong Chen e colegas de Yale e instituições colaboradoras, apresenta um benchmark construído a partir de 2.472 registros da SEC de 43 empresas em 36 setores abrangendo 2020–2025. O benchmark organiza 7.500 pares de perguntas e respostas (P&R) selecionados por especialistas em três tipos de tarefas que espelham os fluxos de trabalho de analistas profissionais: DR-QA (detalhes e raciocínio dentro de um único registro), EC-QA (comparação entre entidades de duas empresas sob um tópico compartilhado) e LT-QA (rastreamento longitudinal da mesma empresa ao longo dos períodos de relatório). Cada tipo de tarefa contém 2.500 perguntas. A avaliação abrange 17 LLMs — modelos de código fechado, incluindo GPT-4.1 e GPT-5, modelos gerais de código aberto como DeepSeek-V3 e Llama-3.3-70B, e modelos especializados em finanças como Fin-R1, Fino1-14B, FinanceConnect-13B e TouchstoneGPT-7B. A pontuação utiliza uma estrutura unificada de LLM-as-Judge com três juízes independentes (GPT-5, DeepSeek-V3.2, Qwen3-235B) avaliando cada resposta quanto à correção e cinco dimensões analíticas.

Ideias principais​

• O desempenho colapsa conforme a complexidade da tarefa aumenta: a precisão cai 18,60% do DR-QA de documento único para o LT-QA longitudinal e 14,35% do DR-QA para o EC-QA entre entidades, na média de todos os 17 modelos.
• O GPT-5 com pesquisa na web é o que apresenta o melhor desempenho, mas sua precisão de pico situa-se em apenas 43–44% nos três tipos de tarefas — um resultado medíocre para um benchmark destinado a espelhar fluxos de trabalho reais de analistas.
• O Fin-R1, o modelo de raciocínio especializado em finanças, atinge 57,48% no DR-QA, mas colapsa para 3,32% no EC-QA — uma queda de 54 pontos que excede em muito a degradação de qualquer modelo geral.
• Sob configurações de RAG, o desempenho em todos os modelos cai bem abaixo de 27%, em comparação com o desempenho em contexto de referência (gold-context) de até 57,48%; o pipeline de recuperação, e não o LLM, é o gargalo limitante.
• O artigo introduz uma taxonomia de erros de 13 tipos em quatro categorias: alucinação e contradições, erros numéricos e semânticos específicos de finanças, erros de compreensão de consulta/contexto e falhas no nível de recuperação. A Evidência Ausente responde por 75,44% dos erros na tarefa EC-QA sob RAG.
• Modelos especializados em finanças mostram taxas de alucinação sistematicamente mais altas do que modelos gerais em tarefas complexas, apesar de possuírem melhor terminologia financeira.

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

A estrutura de três vias é genuinamente bem desenhada. A maioria dos benchmarks financeiros (FinQA, TAT-QA, FinanceBench) trata o P&R como uma tarefa de documento único. O Fin-RATE é um dos primeiros a modelar explicitamente a comparação entre entidades e o rastreamento longitudinal como tarefas de primeira classe, e os resultados expõem uma lacuna fundamental: os LLMs atuais lidam de forma tolerável com P&R de divulgações isoladas, mas desmoronam no momento em que precisam sintetizar informações entre documentos, entidades ou períodos de tempo.

O colapso do Fin-R1 é a descoberta mais impressionante do artigo e creio que seja subestimada. Um modelo ajustado para finanças que se destaca na extração de documento único aparentemente se encurralou durante o treinamento: ele aprendeu modelos para responder dentro de um documento, não estratégias de raciocínio para relacionar entidades e períodos de tempo. Este é um aviso concreto contra o ajuste fino (fine-tuning) de domínio estreito sem supervisão explícita de raciocínio multidocumento. O modelo provavelmente sofre de overfitting para o padrão superficial de "encontrar o número no registro" e não tem caminho de generalização para "comparar este número ao número equivalente em outro registro de outra empresa".

Dito isso, existem preocupações metodológicas que valem ser apontadas. O GPT-5 é simultaneamente um dos modelos avaliados e um dos três juízes que pontuam as respostas. Os autores usam três juízes para reduzir o viés individual, o que ajuda, mas a sobreposição juiz-modelo com o modelo mais forte avaliado é desconfortável. O artigo relata alta concordância entre juízes, mas não quantifica separadamente qual fração das respostas do GPT-5 o próprio GPT-5 pontuou, nem se as pontuações autoavaliadas do GPT-5 diferem sistematicamente dos outros dois juízes. Qualquer viés de autoavaliação inflaria o resultado principal para o modelo de melhor desempenho no estudo.

A amostra de 43 empresas também é pequena. A cobertura dos tipos de registros é louvavelmente ampla (10-K, 10-Q, 8-K, 6-K, DEF 14A e várias séries S e SC), mas as mesmas 43 empresas aparecem em todas as tarefas. Modelos que viram as divulgações dessas empresas no pré-treinamento têm uma vantagem não quantificada, e o artigo não inclui nenhuma análise de contaminação.

A descoberta sobre a recuperação é importante, mas incompleta. O artigo identifica que o desempenho do RAG colapsa em cerca de 30 pontos em relação ao contexto de referência porque a recuperação falha. Mas ele avalia apenas uma única configuração de recuperação — tratando a falha de recuperação como um diagnóstico, em vez de algo a ser variado sistematicamente. Um artigo subsequente que explorasse arquiteturas de recuperação no Fin-RATE seria muito mais acionável.

Por que isso importa para a IA nas finanças​

A auditoria do livro razão do Beancount exige exatamente as duas capacidades que o Fin-RATE revela estarem quebradas: rastreamento longitudinal (como esta conta evoluiu ao longo dos anos fiscais?) e comparação entre entidades (o balanço patrimonial desta subsidiária concilia com a demonstração consolidada?). A queda de 18,60% na precisão sob rastreamento temporal é um número concreto que deve calibrar as expectativas para qualquer agente Beancount raciocinando através de múltiplos períodos de relatório. Se os modelos de ponta falham em 43% sob P&R longitudinal da SEC em contexto de referência, um agente Beancount navegando por históricos de livros razão de vários anos deve ser projetado com recuperação explícita, fundamentação temporal e escalonamento humano — não apenas inferência LLM de ponta a ponta.

A descoberta da dominância da recuperação é o que mais importa para a prioridade de design do sistema. Se o desempenho com contexto de referência é quase o dobro do desempenho com RAG, o investimento correto é em melhor fragmentação (chunking), seleção de passagens e recuperação — não em um LLM de base mais capaz. Isso espelha o que o DocFinQA encontrou para registros da SEC de contexto longo: o pipeline em torno do modelo é o gargalo.

O aviso do Fin-R1 também se aplica diretamente ao caso de uso do Beancount. O ajuste fino na sintaxe DSL do Beancount e em padrões de transação pode produzir um modelo que lida bem com a geração de lançamentos simples, mas que falha na conciliação de múltiplas contas e múltiplos períodos que torna a auditoria útil. A especialização sem treinamento de raciocínio multidocumento é frágil exatamente das formas que o Fin-RATE mede.

O que ler a seguir​

• Fin-R1 (arXiv:2503.16252) — para entender qual configuração de treinamento produziu um desempenho multidocumento tão frágil e se o raciocínio multidocumento chegou a estar no escopo.
• FinTrace (arXiv:2604.10015) — avaliação em nível de trajetória de chamadas de ferramentas de LLMs em 34 categorias de tarefas financeiras; complementa a visão estática de P&R do Fin-RATE com um diagnóstico em nível de processo de onde os modelos invocam as ferramentas certas, mas falham em raciocinar sobre os resultados.
• OpenHands (arXiv:2407.16741) — a plataforma de agentes abertos que fundamenta as avaliações da TheAgentCompany; entender sua arquitetura esclarece quais capacidades básicas de agentes estavam disponíveis e quais lacunas são atribuíveis à dificuldade da tarefa em vez de limitações da plataforma.

O artigo​

Chanyeol Choi, Jihoon Kwon e colegas de uma empresa de IA financeira apresentam um conjunto de dados de 5.703 tripletos de consulta-evidência-resposta anotados por especialistas, provenientes de um serviço real de perguntas e respostas de analistas de fundos de hedge. Os documentos são registros do Formulário 10-K de 490 empresas do S&P 500, coletados do SEC EDGAR. O que diferencia o FinDER de benchmarks anteriores é o lado da consulta: 89,86% das consultas contêm três ou mais abreviações ou acrônimos específicos do domínio. Em vez de "Qual é a receita total da Empresa X para o ano fiscal de 2023?", um analista real pode digitar "GOOGL 10-K FY23 revs breakdown by segment." O conjunto de dados foi publicado no Workshop da ICLR 2025 sobre Avanços em IA Financeira e apareceu posteriormente no ICAIF 2025.

Ideias-chave​

• O recall de recuperação é chocantemente baixo em todos os âmbitos: O E5-Mistral (melhor recuperador denso) alcança apenas 25,95% de recall de contexto geral; o BM25 consegue 11,68%. A categoria "Financials" — a mais diretamente relevante para a contabilidade — é a mais difícil: 15,84% e 6,42%, respectivamente.
• A ambiguidade da consulta por si só custa 8,2 pontos de precisão: Testando o E5-Mistral em 500 consultas, os autores comparam paráfrases bem formuladas (33,9 de precisão) com as consultas abreviadas reais (25,7 de precisão). A lacuna é inteiramente atribuível ao tratamento de abreviações/acrônimos, não à complexidade do documento.
• A qualidade da recuperação é o gargalo dominante para a geração: LLMs sem contexto pontuam perto de zero (9–10% de acertos); com os 10 principais trechos recuperados, eles alcançam 29–34%; com contexto oracle perfeito, saltam para 60–68%. Essa lacuna de 35 pontos entre as condições realistas e as condições oracle é maior do que a lacuna entre os modelos de código aberto e os modelos de fronteira.
• A aritmética composicional quebra mesmo com uma boa recuperação: Tarefas de cálculo de várias etapas (consultas composicionais) alcançam apenas ~20% de correção em todos os quatro modelos — Claude-3.7-Sonnet, GPT-o1, DeepSeek-R1-Distill e Qwen-QWQ — mesmo com os 10 principais trechos recuperados. O GPT-o1 lidera as tarefas de multiplicação com 42,90%, mas cai para 27,78% na divisão.
• O reranqueamento por LLM adiciona uma melhoria modesta, mas consistente: Permitindo que os modelos reclassifiquem os 10 principais resultados do E5-Mistral antes de responder, o Claude-3.7-Sonnet alcança um F1 de 63,05 e o GPT-o1 chega a 62,90. O Deepseek-R1-Distill fica atrás com 60,01, apesar do forte desempenho em raciocínio estruturado em outros lugares.
• A dificuldade por categoria é desigual: Consultas sobre riscos são as mais fáceis de recuperar (E5-Mistral: 33,07 de recall); o setor financeiro (Financials) continua sendo o mais difícil (15,84). Isso se correlaciona com a estrutura da consulta — as divulgações de risco usam prosa em linguagem natural, as tabelas financeiras usam notação numérica densa.

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

A contribuição principal é sólida: trata-se de uma distribuição de consultas reais de analistas em atividade, e o problema das abreviações é genuíno. Qualquer benchmark construído a partir da Wikipedia ou de crowdsourcing estilo FinQA perde isso. A estrutura de avaliação em três níveis — sem contexto, recuperação realista, contexto oracle — é o design correto; ela separa claramente a qualidade da recuperação da qualidade do raciocínio e mostra a lacuna de geração residual (ainda ~32–34% de falha, mesmo com contexto perfeito em perguntas qualitativas).

Onde o artigo é mais fraco é na reprodutibilidade. No momento da publicação, o conjunto de dados não estava disponível publicamente — os autores afirmam que "planejam lançá-lo publicamente em um momento posterior". Isso é um problema significativo para um artigo de workshop que se apresenta como um padrão de avaliação. Benchmarks que não são lançados não são benchmarks; são estudos de caso. Desde então, ele apareceu no ICAIF 2025, então o lançamento pode ter ocorrido, mas a versão do arXiv não confirma isso.

A avaliação de recuperação também utiliza apenas quatro modelos de estágio único (BM25, GTE, mE5, E5-Mistral). Não há recuperação híbrida, nem expansão de consulta, nem HyDE, nem etapa de reescrita visando especificamente o problema das abreviações. Dado que os autores caracterizaram precisamente a lacuna de abreviação, é surpreendente que não testem a correção óbvia: expandir a consulta ("GOOGL" → "Alphabet Inc.") antes da recuperação. Esse experimento está ausente.

Os resultados da geração merecem uma leitura atenta. O desempenho de ~9–10% sem contexto não é um limite inferior útil — é essencialmente zero — mas o teto oracle de 60–68% é mais informativo do que parece. Mesmo com o trecho correto em mãos, os melhores modelos falham em cerca de um terço das perguntas qualitativas e em quatro quintos da aritmética composicional. Esse teto é importante: significa que a recuperação sozinha não pode resolver o problema.

Por que isso importa para a IA financeira​

A distribuição de consultas no FinDER mapeia bem a forma como os usuários do Beancount realmente interagem com um agente de livro-razão. Um usuário que mantém suas contas há anos digitará consultas abreviadas e contextuais — "AMZN card Q3 reimb?" em vez de "Quais são os reembolsos do cartão de crédito da Amazon no terceiro trimestre?". Os modelos de embedding padrão falharão ao recuperar as entradas corretas porque foram treinados em texto de linguagem natural limpo. A queda de 8,2 pontos na precisão de consultas limpas para reais é provavelmente conservadora para um domínio de livro-razão pessoal, onde a taquigrafia idiossincrática ("prop mgmt fee" para "taxa de administração de propriedade") está ainda mais distante dos dados de treinamento do que as abreviações padrão da SEC.

O teto de recall de contexto de 25,95% no E5-Mistral é uma função de força: qualquer pipeline de RAG para Beancount precisa prever uma grande fração de evidências perdidas. Uma implicação é que a recuperação de alto recall (múltiplas passagens, formulações de consulta diversificadas) importa mais do que forçar o F1 em uma única passagem. Outra é que a normalização da consulta — mapear a taquigrafia do usuário para nomes de contas canônicos antes da recuperação — deve ser uma etapa de pré-processamento explícita, não deixada para o modelo de embedding.

A precisão de 20% na aritmética composicional, mesmo com contexto oracle, é um sinal separado: para tarefas de cálculo no Beancount, o gargalo da geração é o raciocínio, não a recuperação. O descarregamento no estilo PAL (geração de aritmética em Python em vez de cálculo em texto livre) continua sendo a resposta certa para tarefas numéricas, independentemente de quão boa a recuperação se torne.

O que ler a seguir​

• Fin-RATE (arXiv:2602.07294) — o benchmark complementar para rastreamento multiperíodo em registros da SEC; a precisão cai 18,60% em tarefas temporais, que é o problema do livro-razão plurianual do Beancount declarado diretamente.
• IRCoT (arXiv:2212.10509, ACL 2023) — entrelaçamento de recuperação com raciocínio de cadeia de pensamento (chain-of-thought); a estrutura de recuperação de múltiplas passagens aborda diretamente o baixo recall de passagem única que o FinDER expõe.
• Expansão de consulta com LLMs para recuperação específica de domínio — nenhum artigo de benchmark cobre isso bem ainda, mas a lacuna de abreviação do FinDER torna isso uma prioridade de pesquisa de primeira ordem; pesquisar por "HyDE financial domain" e "query expansion SEC filings 2025" é o ponto de partida correto.

O artigo​

"Lost in the Middle: How Language Models Use Long Contexts" por Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni e Percy Liang realiza dois experimentos direcionados: resposta a perguntas de múltiplos documentos sobre NaturalQuestions-Open (com 10, 20 e 30 documentos recuperados) e recuperação sintética de chave-valor (com 75, 140 e 300 pares). Em cada experimento, eles variam sistematicamente onde o documento relevante ou o par chave-valor se encontra dentro do contexto de entrada — início, meio ou fim — mantendo todo o resto fixo. A descoberta é clara: o desempenho traça uma curva em forma de U com o vale no meio do contexto, e a curva aparece em todos os modelos testados.

Ideias principais​

• O formato em U é real e consistente. Na configuração de QA com 20 documentos, o desempenho na primeira posição era de aproximadamente 75% e degradava para cerca de 55% na posição 10, antes de se recuperar para cerca de 72% na posição 20 — uma diferença de ~20 pontos entre as extremidades e o centro.
• Todos os modelos seguem o mesmo padrão. Os modelos testados abrangem fechados e abertos, pequenos e grandes: GPT-3.5-Turbo (4K e 16K), GPT-4, Claude-1.3 (8K e 100K), MPT-30B-Instruct e LongChat-13B. A curva em U apareceu em cada um deles, incluindo modelos comercializados explicitamente por suas janelas de contexto estendidas.
• Nem mesmo o Claude-1.3-100K está imune. A variante de contexto de 100K comportou-se como as outras. Uma janela de contexto longa não significa que o modelo realmente preste atenção de forma uniforme em toda a sua extensão.
• A linha de base de livro fechado define um piso preocupante. O GPT-3.5-Turbo sem nenhum documento respondeu 56,1% do NaturalQuestions corretamente; com acesso direto (oracle) a apenas o documento relevante, atingiu 88,3%. Mas nas piores posições centrais na configuração de 20 documentos, o desempenho caiu abaixo da linha de base de livro fechado — o que significa que adicionar mais contexto foi ativamente prejudicial.
• Modelos encoder-decoder (Flan-T5-XXL, Flan-UL2) são mais robustos dentro do seu comprimento de treinamento, mas revertem quando os contextos o excedem. A diferença arquitetônica importa, mas ambos ainda degradam em escala.
• A causa raiz é o mascaramento de atenção causal. Cada token só pode prestar atenção aos tokens precedentes, portanto, as posições logo no início acumulam mais peso de atenção total em todo o modelo do que as posições no meio. Efeitos de recência elevam o final do contexto também.

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

O design experimental aqui é admiravelmente limpo: a posição é a única variável manipulada, as tarefas são benchmarks padrão e a descoberta se replica em uma ampla gama de famílias de modelos. Não tenho objeções ao resultado principal.

O que considero menos convincente é o enquadramento da tarefa de recuperação de chave-valor como um proxy significativo para o uso real. Buscas de UUID para UUID testam se um modelo pode repetir uma string memorizada, não se ele pode fazer algo que exija raciocínio. A curva em U também aparece ali, o que fortalece a alegação de viés de posição, mas também significa que o artigo está fundindo dois fenômenos diferentes: precisão de recuperação em tarefas de correspondência exata e qualidade de raciocínio sobre passagens relevantes. Eu gostaria de saber se o formato em U piora ou melhora quando o documento relevante exige inferência em várias etapas antes da resposta final, e não apenas a repetição literal.

Há também uma lacuna que os autores reconhecem em grande parte, mas não fecham: eles nunca testam se o ajuste fino de instruções ou RLHF altera a sensibilidade à posição, apenas se uma janela de contexto maior o faz. Dado que a causa raiz é arquitetônica (mascaramento causal), suspeito que o ajuste de instruções não resolverá isso, mas o artigo não confirma isso.

Por que isso importa para a IA financeira​

Este artigo fornece a explicação mecânica para um padrão empírico que encontro constantemente. O DocFinQA colapsou em relatórios longos da SEC. IRCoT e FLARE recuperam múltiplas passagens e as concatenam antes do raciocínio. Todo pipeline de RAG que analisei em um contexto financeiro despeja passagens recuperadas sequencialmente no prompt e espera que o modelo preste atenção na correta.

A implicação para os agentes Beancount é concreta. Se um agente recupera dez entradas de livro-razão como contexto, as entradas nas posições 3 a 7 correm o maior risco de serem ignoradas ou gerarem alucinações. Isso não é um problema de recuperação — é um problema de apresentação. Duas respostas seguem a partir deste artigo: ou colocar as entradas mais diagnosticamente relevantes primeiro (e por último), ou não concatenar de forma alguma e raciocinar sobre uma passagem de cada vez.

A descoberta também complica a narrativa do LLM de contexto longo. A cada trimestre, um novo modelo anuncia uma janela de contexto maior. Este artigo diz que a janela ser longa não significa o que você pensa se estiver distribuindo as evidências uniformemente nela. Um modelo de contexto de 128K que enterra a transação relevante na posição 60K é pior do que um modelo de contexto de 4K que recupera precisamente a passagem correta.

Para a segurança de gravação (write-back safety), as implicações são desconfortáveis: se o modelo for solicitado a resumir uma sessão de livro-razão e a regra de política relevante "não postar esta transação" aparecer no meio de um prompt de sistema longo, o modelo pode agir como se nunca tivesse lido essa regra.

O que ler a seguir​

• "Found in the Middle: How Language Models Use Long Contexts Better via Plug-and-Play Positional Encoding" (Zhang et al., arXiv:2403.04797) — propõe a Codificação Posicional de Múltiplas Escalas (Ms-PoE) como uma correção sem necessidade de treinamento via escalonamento RoPE; reivindica uma melhoria de até 3,8 pontos no Zero-SCROLLS, abordando diretamente a curva em U.
• "Never Lost in the Middle: Mastering Long-Context Question Answering with Position-Agnostic Decompositional Training" (arXiv:2311.09198) — adota a abordagem oposta e treina o modelo para ser explicitamente agnóstico à posição; a comparação com Ms-PoE esclarece se o ajuste fino ou truques em tempo de inferência são a melhor alavanca.
• "Mitigate Position Bias in Large Language Models via Scaling a Single Dimension" (arXiv:2406.02536) — identifica a dimensão específica dos estados ocultos posicionais responsável pelo viés e a escala sem retreinamento; a correção mais cirúrgica proposta até agora, relevante para a implantação de modelos existentes sem retreinar.

O artigo​

Tiankai Yang, Yi Nian e colegas da USC e Texas A&M apresentam o AD-LLM (arXiv:2412.11142, ACL Findings 2025), o primeiro benchmark para avaliar LLMs sistematicamente em três paradigmas de detecção de anomalias em conjuntos de dados de PLN. O cenário é a classificação de classe única: os dados de treinamento contêm apenas amostras normais, e o modelo deve sinalizar anomalias no momento do teste. Os cinco conjuntos de dados — AG News, BBC News, IMDB Reviews, N24 News e SMS Spam — derivam todos de tarefas de classificação de texto com uma categoria designada como anômala. O artigo coloca duas LLMs, GPT-4o e Llama 3.1 8B Instruct, contra 18 baselines não supervisionados tradicionais que abrangem métodos de ponta a ponta (CVDD, DATE) e combinações de dois passos de embedding mais detector (embeddings da OpenAI + LUNAR, LOF, Isolation Forest, etc.).

Principais ideias​

• A detecção zero-shot funciona bem para texto. O GPT-4o obtém AUROC de 0,9293–0,9919 nos cinco conjuntos de dados na configuração Normal+Anomalia; o Llama 3.1 atinge 0,8612–0,9487. O melhor baseline tradicional, OpenAI + LUNAR, pontua cerca de 0,92 no AG News — o GPT-4o iguala ou supera isso sem qualquer treinamento.
• O aumento sintético ajuda, de forma consistente, mas modesta. Amostras sintéticas geradas por LLM melhoram o pipeline OpenAI + LUNAR em todos os cinco conjuntos de dados. O aumento de descrição de categoria também melhora a maioria dos baselines, embora os ganhos sejam desiguais — o Llama 3.1 melhora o AUROC em +0,07 no IMDB Reviews, mas os resultados em outros lugares são menores.
• A seleção de modelos é o elo fraco. O GPT-o1-preview recomenda modelos que superam o desempenho médio dos baselines na maioria dos conjuntos de dados e, ocasionalmente, se aproxima do melhor método (por exemplo, no IMDB Reviews e SMS Spam). No entanto, ele nunca identifica de forma confiável o melhor executor, e os autores admitem que as recomendações são baseadas em entradas simplistas que carecem de estatísticas específicas do conjunto de dados.
• A lacuna entre código aberto e proprietário é real. A vantagem do AUROC do GPT-4o sobre o Llama 3.1 8B é de 4 a 13 pontos, dependendo do conjunto de dados, uma lacuna consistente com o padrão visto em artigos de detecção de anomalias tabulares zero-shot.
• A detecção de anomalias em PLN ainda carece de um benchmark definitivo. Cinco conjuntos de dados, todos derivados de corpora de classificação, é pouco. O artigo complementar NLP-ADBench (EMNLP Findings 2025) amplia para oito conjuntos de dados e 19 algoritmos, mas ainda usa a mesma construção de categoria-semântica-como-anomalia que torna essas tarefas um tanto artificiais.

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

As descobertas de zero-shot são críveis. Usar LLMs como pontuadores sem ajuste fino em dados de anomalias rotulados é genuinamente útil quando a classe de anomalia é semanticamente coerente — uma mensagem de spam difere de uma mensagem legítima de formas que um modelo de linguagem bem treinado compreende. Os números de AUROC são altos, e a comparação com baselines fortes baseados em embeddings da OpenAI é justa.

O escopo, no entanto, é estreito de formas que o artigo subestima. Todos os cinco conjuntos de dados codificam anomalias como uma categoria de tópico diferente — spam versus SMS legítimo, notícias de uma editora externa versus veículos dentro da distribuição. Isso significa que a LLM está essencialmente fazendo classificação de tópicos, uma tarefa para a qual ela é explicitamente pré-treinada. O benchmark não inclui anomalias semânticas dentro de uma única categoria (por exemplo, transações incomuns dentro do mesmo tipo de conta), que é precisamente o tipo de anomalia que importa para a auditoria financeira.

As tarefas de aumento de dados e seleção de modelos são avaliadas nos mesmos cinco conjuntos de dados, então o artigo acaba testando se as LLMs podem tornar fatias ligeiramente diferentes do mesmo problema estreito marginalmente melhores. Os autores listam livremente seis limitações — incluindo que testam apenas um subconjunto de LLMs, excluem regimes de few-shot e ajuste fino, e dependem de entradas simplistas para a seleção de modelos — o que é intelectualmente honesto, mas também sinaliza o quão preliminar este benchmark é.

Um resultado que vale a pena sinalizar para os céticos: as pontuações AUPRC são substancialmente mais baixas que o AUROC para ambos os modelos. O Llama 3.1 no BBC News atinge AUROC de 0,8612, mas apenas AUPRC de 0,3960, refletindo o desequilíbrio de classes na configuração de classe única. Em contextos de auditoria de alta precisão, o AUPRC é a métrica mais significativa e, aqui, a imagem é menos favorável.

Por que isso importa para a IA financeira​

A agenda da Bean Labs envolve dois casos de uso de detecção de anomalias: capturar entradas incomuns no livro-razão em tempo real (tabulares, estruturadas) e sinalizar textos narrativos suspeitos em faturas, memorandos ou tickets de suporte (PLN não estruturado). O AD-LLM fala diretamente ao segundo caso e nos dá um teto realista: o GPT-4o pode detectar anomalias em nível de tópico em texto via zero-shot com AUROC acima de 0,93 em conjuntos de dados limpos e equilibrados. Esse é um dado útil, mas as anomalias narrativas em livros-razão são mais sutis — um memorando de fatura que descreve um serviço rotineiro, mas pertence a um fornecedor sinalizado por padrões suspeitos, não é um problema de classificação de tópicos. O benchmark fornece um ponto de partida, não uma resposta.

A descoberta da seleção de modelos é interessante separadamente para o design do sistema. O sonho de perguntar a uma LLM "qual detector de anomalias devo usar neste conjunto de dados?" e obter uma resposta confiável ainda não se concretizou. Isso significa que a escolha entre o ajuste fino estilo AnoLLM, o prompting causal estilo CausalTAD ou um método de embedding clássico ainda requer julgamento humano ou avaliação empírica sistemática — não pode ser delegada a um consultor LLM.

O que ler a seguir​

• NLP-ADBench (arXiv:2412.04784, EMNLP Findings 2025) — o benchmark complementar do mesmo grupo, cobrindo oito conjuntos de dados e 19 algoritmos; fornece o contexto de baseline clássico mais amplo que o escopo de cinco conjuntos de dados do AD-LLM não consegue.
• Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey (arXiv:2409.01980, NAACL Findings 2025) — pesquisa o panorama completo das abordagens de AD baseadas em LLM em modalidades de texto, imagem e tabulares; preenche o contexto de onde o AD-LLM se situa em relação ao trabalho anterior.
• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — a contraparte tabular; comparar sua abordagem baseada em verossimilhança com a estratégia zero-shot baseada em prompts do AD-LLM esclarece qual paradigma é mais apropriado para as entradas do livro-razão do Beancount.

O artigo​

Wang et al. propõem o CausalTAD, um método que se baseia em detectores de anomalias LLM no estilo AnoLLM e faz uma mudança direcionada: em vez de serializar linhas tabulares em ordem de coluna aleatória ou arbitrária, ele descobre dependências causais entre as colunas e as reordena para respeitar essas dependências antes que o LLM leia a linha.

O artigo tem duas partes móveis. Primeiro, um módulo de ordenação de colunas orientado por causalidade. Os autores adaptam o framework de extração de fatores COAT: um LLM lê metadados de colunas e amostras para extrair fatores semânticos de alto nível (para transações de cartão de crédito, um fator como "Compensação" pode abranger as colunas de valor e comerciante). A partir desses fatores, três algoritmos de descoberta causal — PC, LiNGAM e FCI — constroem, cada um, um grafo causal direcionado sobre os fatores. O problema de reordenação de colunas torna-se então um Problema de Ordenação Linear: encontrar a permutação π que maximiza a soma dos pesos das arestas direcionadas, para que as colunas de causa apareçam antes das colunas de efeito no texto serializado. Como o PL tem muitas soluções quase ótimas, eles amostram K ≈ 10 ordenações dentro de 90% do ideal e fazem a média delas.

Segundo, um módulo de reponderação consciente da causalidade. Nem todas as colunas são igualmente relevantes. Uma coluna que influencia muitos fatores recebe um peso maior αj = |M⁻¹(cj)|, a contagem de fatores para os quais ela contribui. A pontuação final de anomalia é a média ponderada das log-verossimilhanças negativas por coluna nas K ordenações.

Ideias principais​

• A ordenação de colunas é um viés indutivo não trivial para LLMs autorregressivos: colocar uma coluna de causa antes de sua coluna de efeito permite que o modelo se condicione ao contexto correto ao atribuir verossimilhança ao efeito.
• A descoberta causal no nível do fator (em vez do nível da coluna bruta) permite que o método lide com tabelas de tipos mistos, onde a descoberta causal direta entre colunas heterogêneas é ruidosa.
• Em 6 conjuntos de dados de benchmark de tipos mistos, o CausalTAD com SmolLM-135M atinge uma AUC-ROC média de 0,834 contra 0,803 do AnoLLM — uma melhoria absoluta de 3,1 pontos com o mesmo modelo base.
• Especificamente no conjunto de dados Fake Job Posts, o CausalTAD pontua 0,873 contra 0,800 do AnoLLM — um ganho relativo de 9,1%, o que é grande o suficiente para importar em um sistema de triagem real.
• Em 30 conjuntos de dados de benchmark ODDS numéricos, o CausalTAD alcança a melhor AUC-ROC média, superando consistentemente os baselines clássicos (Isolation Forest, ECOD, KNN) e métodos profundos (DeepSVDD, SLAD).
• Todos os três algoritmos de descoberta causal superam a ordenação aleatória na ablação; o LiNGAM supera ligeiramente o PC e o FCI nos conjuntos de dados mistos.

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

A afirmação central — de que a ordem causal das colunas ajuda — é bem fundamentada. A ablação é clara: trocar a ordenação aleatória por qualquer um dos três métodos de descoberta causal melhora os resultados no benchmark Fake Job Posts (de 0,832 para 0,870–0,873), e a reponderação por contagem de fatores ajuda ainda mais em todas as configurações. Essa é uma história credível.

O que considero menos convincente é a suposição de bootstrapping. O grafo causal é construído usando um LLM para extrair fatores semânticos dos mesmos dados que o sistema deve analisar. Se o LLM interpretar mal o domínio — por exemplo, para um sistema contábil personalizado com nomes de colunas não padronizados — a extração de fatores estará errada, e um grafo causal ruim é possivelmente pior do que uma ordenação aleatória, pois introduz um viés sistemático. Os autores reconhecem esse risco ("depende da capacidade dos LLMs para extração de fatores"), mas não avaliam a precisão da extração de fatores de forma independente.

Há também uma questão de sobrecarga computacional que é mais séria do que o artigo sugere. Executar três algoritmos de descoberta causal, resolver um PL, amostrar K ordenações e depois executar a inferência em K versões serializadas de cada ponto de teste multiplica o custo de inferência por K. Para um livro contábil (ledger) com milhões de entradas, isso importa. O artigo observa que "trabalhos futuros podem se concentrar em melhorar a eficiência", mas não oferece um perfil de desempenho concreto.

Finalmente, os 30 conjuntos de dados ODDS numéricos são bem estudados e possivelmente saturados para métodos como este. O sinal mais significativo está nos 6 conjuntos de dados de tipos mistos — que são os realistas para finanças — e as melhorias neles, embora reais, são um tanto modestas em termos absolutos.

Por que isso importa para a IA nas finanças​

As transações do Beancount possuem uma estrutura causal genuína: o valor do lançamento (amount) impulsiona causalmente a seleção da conta, a conta impulsiona a expectativa da contraparte, e o texto do histórico (memo) está causalmente a jusante de todos os três. A serialização aleatória de colunas ignora isso, o que significa que um modelo no estilo AnoLLM vê "memo: compras | account: Expenses:Food | amount: $4200" tão livremente quanto a versão corretamente ordenada.

O CausalTAD oferece uma maneira fundamentada de codificar que "valor e conta vêm primeiro" sem codificar isso rigidamente como uma regra. Para os agentes de auditoria do Bean Labs, isso sugere uma escolha arquitetônica prática: antes de pontuar um lote de transações em busca de anomalias, faça uma passagem descobrindo o grafo causal sobre o esquema de colunas do ledger e, em seguida, use essa ordenação fixa para todas as inferências subsequentes. A sobrecarga é paga uma vez no nível do esquema, não por transação.

O exemplo de detecção de fraude de cartão de crédito no artigo tem essencialmente a mesma estrutura de tarefa que a detecção de anomalias em livros contábeis: recursos heterogêneos, rótulos raros e uma ordem causal que os especialistas do domínio conhecem intuitivamente, mas que os LLMs ignorariam de outra forma.

O que ler a seguir​

• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) — o benchmark sistemático abrangendo três paradigmas de detecção de anomalias por LLM nos quais o CausalTAD se encaixa; lê-lo oferece a visão completa em vez da comparação isolada entre AnoLLM e CausalTAD.
• COAT: Boosting Large Language Model-Based In-Context Learning for Tabular Data (Liu et al., 2024) — o framework de extração de fatores que o CausalTAD adapta; entender como ele funciona esclarece onde a qualidade do grafo causal pode falhar.
• Causal discovery in heterogeneous data: a survey — para entender os méritos relativos de PC vs LiNGAM vs FCI em dados tabulares de tipos mistos, já que o artigo trata os três como intercambiáveis, mas eles fazem diferentes suposições de independência.

O artigo​

O AnoLLM reformula a detecção de anomalias tabulares como estimativa de densidade de modelo de linguagem, em vez de classificação por prompts. Em vez de pedir à LLM para nomear quais linhas parecem suspeitas, os autores fazem o ajuste fino de um modelo de linguagem pré-treinado em linhas de treinamento serializadas dentro da distribuição (normais) e, em seguida, pontuam cada linha de teste por sua log-verossimilhança negativa (NLL) sob essa distribuição aprendida. Uma linha que não se parece em nada com a distribuição de treinamento recebe um NLL alto — essa é a pontuação de anomalia. Sem formato de índice, sem análise de saída, sem extração frágil por regex.

A serialização converte cada linha da tabela em uma string de linguagem natural com nomes e valores de recursos. Para colunas com valores de texto, a NLL é normalizada por coluna para evitar viés de comprimento, onde descrições mais longas, de outra forma, acumulariam mecanicamente custos de probabilidade mais altos. Para colunas numéricas e categóricas, a NLL bruta ao nível de token é somada em todo o campo. O modelo é ajustado em um cenário semissupervisionado — apenas linhas rotuladas como normais entram no treinamento — por até 2.000 etapas usando treinamento em GPU distribuída.

Ideias principais​

• O problema do formato de saída: abordagens anteriores de previsão de índices exigem que as LLMs gerem de forma confiável os índices das linhas anômalas de um lote. Modelos da família Llama frequentemente associam índices errados a valores, geram índices além do tamanho do lote ou simplesmente listam tudo como anômalo. A NLL contorna isso inteiramente.
• O AnoLLM atinge o melhor desempenho em seis conjuntos de dados de benchmark com tipos de recursos mistos, incluindo detecção de fraude em seguros de veículos e conjuntos de dados de fraude de e-commerce do Kaggle.
• Nos 30 conjuntos de dados do benchmark ODDS, predominantemente numéricos, o AnoLLM tem um desempenho equivalente às melhores referências clássicas — não claramente melhor, apenas competitivo.
• A normalização da NLL por coluna para recursos de texto é uma decisão de engenharia pequena, mas fundamental: sem ela, uma descrição de transação com trinta tokens dominaria a pontuação sobre um valor de dois dígitos, o que é um viés indutivo incorreto.
• O contexto da linha de base de treinamento: a abordagem zero-shot do GPT-4 (arXiv:2406.16308) atinge um AUROC médio de 74,1 no ODDS, comparável ao ECOD (75,5) e KNN (70,7). A vantagem do AnoLLM aparece especificamente em conjuntos de dados onde recursos de texto e categóricos carregam sinais de anomalia significativos.

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

A ideia central da NLL é sólida. Usar um modelo de linguagem com ajuste fino como estimador de densidade sobre linhas serializadas é fundamentado e lida naturalmente com a distribuição conjunta de todas as colunas simultaneamente — algo que detectores não supervisionados clássicos aplicados coluna por coluna não conseguem fazer de forma limpa. A correção para a previsão de índices é genuinamente útil e a comparação com a linha de base zero-shot é justa.

O que me incomoda é a lacuna de custo-benefício que o artigo subnotifica. O AnoLLM requer ajuste fino e a disponibilização de uma LLM para inferência — um compromisso substancial de infraestrutura em comparação com o ajuste de um ECOD ou IsolationForest em uma CPU em segundos. No benchmark ODDS (puramente numérico), o AnoLLM é apenas "equivalente", não melhor. Portanto, o caso de uso do AnoLLM está inteiramente no regime de tipos mistos, onde os seis conjuntos de dados avaliados são de detecção de fraude do Kaggle. Seis conjuntos de dados é uma base empírica rasa para uma recomendação forte, especialmente porque os conjuntos de dados de benchmark do Kaggle tendem a ter esquemas limpos, semântica de coluna fixa e verdades fundamentais conhecidas — todas as coisas que os dados de livros contábeis em produção costumam carecer.

O problema da ordenação das colunas também ficou em aberto. O CausalTAD (arXiv:2602.07798) identificou imediatamente essa lacuna: o AnoLLM serializa colunas em ordem arbitrária, ignorando as relações causais entre os campos. Para dados estruturados com cadeias causais conhecidas — o tipo de conta influencia os intervalos de transação válidos, que por sua vez influenciam a contraparte esperada — isso é uma limitação real. O CausalTAD enquadra a reordenação como um problema de ordenação linear e relata melhorias consistentes sobre o AnoLLM em mais de 30 conjuntos de dados. O fato de essa lacuna existir e ter sido encontrada tão rapidamente sugere que o design de serialização do AnoLLM não foi totalmente pensado.

Há também uma questão de escala que o artigo não aborda: com que volume de exemplos de treinamento normais o ajuste fino de uma LLM passa a valer a pena em relação a, digamos, um modelo de aprendizado profundo tabular treinado diretamente nos recursos numéricos? Para livros contábeis pessoais do Beancount com alguns milhares de lançamentos, o custo de computação pode facilmente ofuscar qualquer ganho de precisão.

Por que isso importa para a IA nas finanças​

Os lançamentos do livro contábil do Beancount são exatamente o tipo de dados mistos que o AnoLLM visa: valores (numéricos), nomes de contas (texto estruturado), favorecido/narração (texto livre), tags (categóricos), datas (estruturadas). Uma única linha como 2024-03-15 * "AWS" "Fatura na nuvem" Assets:Checking -2400.00 codifica informações em todos esses tipos simultaneamente. Os detectores de anomalias clássicos têm dificuldade aqui porque precisam de tratamento separado para cada tipo de coluna e perdem as correlações entre elas — o padrão conjunto de que faturas da "AWS" devem estar em uma determinada faixa e atingir uma conta específica.

A abordagem NLL do AnoLLM aprenderia, em princípio, esses padrões conjuntos a partir de lançamentos históricos normais e sinalizaria desvios em qualquer combinação de colunas. Isso é potencialmente mais útil do que JETs baseados em regras ou testes estatísticos de coluna única.

Dito isso, a restrição da contabilidade de partidas dobradas é um conhecimento estrutural que o AnoLLM não pode aprender apenas com linhas serializadas — os débitos devem ser iguais aos créditos, as hierarquias de contas devem ser respeitadas. Esses invariantes de domínio são restrições rígidas, não regularidades estatísticas, e nenhum ajuste fino de LLM em linhas históricas os aplicará de forma confiável se os dados de treinamento contiverem exceções ou artefatos de arredondamento. A arquitetura correta provavelmente combina a pontuação NLL do AnoLLM para anomalias semânticas com verificações de regras explícitas para as estruturais.

O que ler a seguir​

• CausalTAD (arXiv:2602.07798) — melhora diretamente o AnoLLM injetando ordenação causal de colunas; o acompanhamento mais imediato para avaliar.
• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) — fornece a avaliação sistemática multiparadigma que falta em artigos de métodos individuais.
• "Language Models are Realistic Tabular Data Generators" (Borisov et al., arXiv:2210.06280, ICLR 2023) — o modelo BE-GREAT que o AnoLLM usa como base; entendê-lo esclarece o que o AnoLLM realmente melhora além da previsão de índices.

O artigo​

Figueroa, Grundmann, Freidank, Löser e Nejdl avaliam cinco modelos de pesos abertos de ~7B em um benchmark de duas tarefas que chamam de LLMFinLiteracy. A Tarefa 1 pede aos modelos que gerem cenários textuais que afetariam um determinado índice de liquidez (corrente, seca ou imediata), dado um balanço patrimonial trimestral real de uma das cinco empresas listadas no DAX (Airbus, Bayer, Deutsche Telekom, Mercedes-Benz, SAP). A Tarefa 2 pede aos modelos que traduzam esses cenários em transações Beancount compiláveis. O compilador Beancount serve como o verificador sintático de verdade absoluta (ground-truth); especialistas humanos avaliam a correção semântica. O artigo introduz uma taxonomia de erros de 12 classes nas duas tarefas e utiliza um prompt de cadeia de pensamento de 9 etapas que inclui regras de contabilidade de dupla entrada, um exemplo de entrada/saída e o balanço patrimonial real da empresa no formato Beancount. Os modelos avaliados — Llama-3-8B, Qwen-2-7B, Mistral-7B, CodeLlama-7B e CodeQwen-1.5-7B — foram todos executados localmente (on-premise) devido à sensibilidade dos dados financeiros. O corpus totaliza 1.500 amostras geradas, com 300 entradas estratificadas avaliadas por especialistas humanos.

Ideias principais​

• Apenas 7 dos 300 pares cenário-transação avaliados (2,3%) estavam totalmente corretos de ponta a ponta; mesmo restringindo aos três modelos de uso geral, a taxa sobe apenas para 3,8%.
• Os dois melhores modelos, Qwen-2-7B e Mistral-7B, produzem cenários corretos apenas 21,67% e 20,00% das vezes, e transações compiláveis corretas apenas 16,67% e 10,00% das vezes.
• Modelos especializados em código (CodeLlama, CodeQwen) pontuaram 0% em ambas as tarefas; eles responderam ao template do prompt com uma string literal "Processed — Waiting for next input", ignorando completamente a tarefa.
• A sintaxe não é o gargalo: nenhum modelo produziu um único erro de sintaxe. As falhas estão inteiramente no raciocínio contábil — erros de saldo dominam no Qwen-2 (61,67%) e Llama-3 (38,33%), enquanto o Mistral refere-se principalmente a contas que não existem no balanço patrimonial fornecido (45% de erros de conta desconhecida).
• Uma fração significativa das transações que compilam com sucesso está semanticamente errada — o truque favorito do modelo é chamar a redução de um passivo de "vender sua dívida", o que aumenta o caixa, mas pelo motivo errado.
• O GPT-4o usado como juiz automatizado falhou em sinalizar inconsistências em todos os 10 cenários absurdos que lhe foram mostrados, confirmando que a autoavaliação de LLM não é um filtro de qualidade confiável para saídas contábeis.
• Os modelos copiam amplamente o exemplo de entrada/saída do prompt em vez de generalizar: os 7 pares corretos assemelham-se de perto à estrutura da transação de exemplo fornecida.

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

A contribuição empírica central do artigo é sólida. O compilador Beancount é um critério de correção objetivo e reproduzível, e usar balanços patrimoniais de empresas reais em vez de dados fictícios adiciona validade ecológica. A taxonomia de erros hierárquica é cuidadosamente projetada — interromper a avaliação no primeiro erro evita inflar o "crédito parcial" para saídas inúteis.

Dito isso, existem limitações óbvias que os autores reconhecem em grande parte. Cinco modelos de pesos abertos de ~7B de 2023–2024 são uma fatia estreita do cenário de capacidades; GPT-4o e Claude foram excluídos por razões de privacidade, o que é compreensível, mas significa que o número principal (2,3% correto) subestima a fronteira. As fórmulas dos índices financeiros foram deliberadamente omitidas dos prompts para testar o conhecimento inerente do domínio — uma escolha metodologicamente interessante, mas que torna os resultados incomparáveis a qualquer sistema que razoavelmente incluiria a documentação das fórmulas. E 300 amostras avaliadas por humanos em cinco modelos, três índices e cinco empresas é modesto; as células por modelo por índice são pequenas demais (12 amostras) para tirar conclusões fortes sobre a variância.

A lacuna metodológica mais interessante é a ausência de qualquer protocolo iterativo ou baseado em feedback. Nada de chamada de ferramentas (tool-calling), nada de autocorreção, nada de loop de feedback com o compilador — apenas geração one-shot. Dado que o CRITIC (LOG-012) e trabalhos relacionados mostram que o refinamento interativo com ferramentas melhora substancialmente a precisão em tarefas com saídas verificáveis, um experimento com o compilador Beancount no loop teria sido muito mais informativo sobre a viabilidade de implantação.

Por que isso importa para a IA nas finanças​

Cada decisão de design para o agente de gravação (write-back) do Bean Labs baseia-se em suposições sobre o que os LLMs podem fazer com a DSL do Beancount. Este artigo é a primeira âncora empírica. As descobertas principais são sóbrias, mas também interpretáveis de uma forma útil.

Primeiro, os modos de falha são específicos, não aleatórios. Erros de saldo e contas desconhecidas são os dois problemas dominantes, e ambos são endereçáveis com um loop de feedback do compilador: o compilador Beancount diz exatamente qual conta é desconhecida e se a transação está equilibrada. Uma arquitetura de agente que itera sobre a saída do compilador — em vez de gerar uma vez e parar — deve superar substancialmente os resultados one-shot apresentados aqui. Segundo, a sintaxe é "de graça". Os modelos aprenderam claramente a gramática de superfície do Beancount; eles apenas não conseguem traduzir de forma confiável a intenção financeira em movimentos de conta corretos. Essa distinção importa para saber onde investir em prompting e ajuste fino (fine-tuning). Terceiro, a descoberta de que o GPT-4o não pode avaliar a qualidade contábil automaticamente eleva o nível para qualquer sistema de verificação automatizado: você precisa do compilador, além de verificações pontuais de especialistas no domínio, e não de um LLM crítico.

O artigo também confirma algo que eu suspeitava do trabalho de detecção de anomalias (LOG-049): LLMs operando sobre transações financeiras compilam e enviam com facilidade excessiva. A categoria "Incorreta | Compila" — transações que passam na verificação sintática, mas estão semanticamente erradas — é exatamente o modo de falha que uma barreira de segurança de gravação deve capturar. Uma transação pode estar perfeitamente equilibrada e ainda assim registrar receita como uma diminuição de passivo, o que passaria despercebido por qualquer verificação puramente sintática.

O que ler a seguir​

• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — pontuação de anomalias baseada em probabilidade como alternativa à abordagem de detecção em lote; combina-se naturalmente com um sinal do compilador Beancount para sinalizar entradas estruturalmente válidas, mas estatisticamente anômalas.
• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — encaminha decisões de baixa confiança para um modelo maior ou para um humano; aborda diretamente a questão de quando um agente de gravação Beancount deve delegar à revisão humana em vez de prosseguir após um loop de feedback do compilador.
• CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing (arXiv:2305.11738, ICLR 2024) — o trabalho existente mais relevante para construir um agente de correção com o compilador no loop sobre a arquitetura que este artigo avalia.