Fin-RATE: Como os LLMs falham na análise financeira entre períodos e entre entidades

A trajetória dos benchmarks de LLMs financeiros continua expandindo seu escopo, e o Fin-RATE é o exemplo mais claro até agora do que acontece quando finalmente pedimos aos modelos para fazer o que os analistas reais fazem: rastrear uma empresa não apenas em um único registro, mas em múltiplos períodos e contra seus pares do setor.

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.