LLMs Conseguem Raciocinar Sobre Dados Tabulares? O Que Quatro Benchmarks Nos Dizem Sobre IA nas Finanças

Tabelas são como os contadores pensam. Um livro razão do Beancount é essencialmente uma tabela — contas como linhas, datas e valores como colunas, asserções como restrições entre as células. Então, quando comecei a perguntar se as LLMs podem alimentar agentes financeiros autônomos, continuei me deparando com a mesma pergunta prévia: elas conseguem sequer ler uma tabela de forma confiável? A literatura sobre isso é mais condenatória do que eu esperava.

O artigo

Fang et al. publicaram "Large Language Models(LLMs) on Tabular Data: Prediction, Generation, and Understanding — A Survey" na TMLR 2024 (arXiv:2402.17944). É uma taxonomia de 41 páginas cobrindo três domínios: previsão de resultados estruturados a partir de características tabulares, geração de dados tabulares sintéticos e compreensão de tabelas o suficiente para responder a perguntas sobre elas. A trilha de compreensão — perguntas e respostas sobre tabelas (TableQA), verificação de fatos e raciocínio estrutural — é onde reside o trabalho mais relevante para a IA financeira.

O artigo que li paralelamente, "Table Meets LLM: Can Large Language Models Understand Structured Table Data?" de Sui et al. (WSDM 2024, arXiv:2305.13062), adota uma abordagem mais controlada: eles definem um benchmark de Capacidade de Compreensão Estrutural (SUC) com sete tarefas restritas — partição de tabela, detecção de tamanho, detecção de células mescladas, busca de célula, busca reversa, recuperação de coluna e recuperação de linha — e testam o GPT-3.5 e o GPT-4 diretamente. Sem cadeias de raciocínio, sem truques de recuperação. Apenas: o modelo consegue fazer o que pedimos?

Ideias-chave

• A lacuna de formato é real e surpreendentemente grande. No benchmark SUC, a serialização em HTML supera o formato de linguagem natural com separadores em cerca de 6,76% no geral. O ranking — HTML > XML > JSON > Markdown > LN+Sep — mantém-se consistente entre as tarefas. Os arquivos Beancount estão mais próximos da extremidade de linguagem natural deste espectro, o que é um sinal de alerta.
• A busca em células é surpreendentemente difícil. O GPT-3.5 atinge apenas 44% de precisão na busca direta de células (encontrar o valor na linha X, coluna Y). O GPT-4 atinge 73,34% na mesma tarefa. Para uma operação determinística que uma fórmula de planilha resolve em microssegundos, uma lacuna de 26 pontos percentuais entre os modelos é alarmante.
• Exemplos de poucas tentativas (few-shot) são fundamentais. A remoção de exemplos de 1 tentativa (1-shot) dos prompts SUC causou uma queda de 30,38% na precisão geral em todas as tarefas. A compreensão estrutural do modelo é fortemente escorada por demonstrações, não genuinamente internalizada.
• A lacuna entre humanos e LLMs em P&R de tabelas reais é enorme. O TableBench (arXiv:2408.09174, AAAI 2025) avalia 886 perguntas entre verificação de fatos, raciocínio numérico, análise de dados e visualização. A precisão humana é de 85,91%. O GPT-4-Turbo marca 40,38%, o GPT-4o marca 42,73%. Os melhores modelos atuais estão operando em aproximadamente metade do nível humano em um benchmark projetado para refletir a complexidade de tabelas do mundo real.
• O colapso da complexidade em planilhas financeiras é severo. O FinSheet-Bench (arXiv:2603.07316) testa LLMs em modelos de fundos de private equity com complexidade estrutural variável. Buscas simples atingem 89,1% de precisão. Agregações complexas caem para 19,6%. O maior arquivo de teste (152 empresas, 8 fundos) resulta em 48,6% de precisão média em todos os modelos, caindo de 86,2% no arquivo mais simples.
• Tabelas longas quebram os modelos categoricamente. O levantamento da TMLR relata que, além de 1000 tokens, o desempenho do GPT-3 degrada para algo próximo ao aleatório. Mesmo modelos com janelas de contexto de 200K enfrentam dificuldades com conjuntos de dados massivos devido ao custo quadrático da autoatenção sobre sequências longas.

O que se sustenta — e o que não

O benchmark de Sui et al. é cuidadosamente projetado e os números são verossímeis. A descoberta de que o HTML supera o markdown para tarefas estruturais é contraintuitiva — o markdown é mais compacto e as LLMs o veem mais no treinamento — mas alinha-se com o esperado: a marcação explícita do HTML oferece ao modelo mais âncoras para navegar na estrutura sem precisar inferi-la.

O que vejo com ceticismo: a técnica de autoaumento (prompting em dois estágios, onde o primeiro prompt pede ao modelo para identificar valores críticos antes de responder) produz melhorias de 0,84–5,68% em benchmarks derivados como TabFact e ToTTo. Estes são números reais de experimentos reais, mas são marginais. A técnica não aborda o problema fundamental — é um remendo de engenharia de prompt sobre uma compreensão estrutural genuinamente fraca.

O levantamento da TMLR tem o problema de escopo comum a todas as revisões: cobre tudo, desde previsão tabular (território do XGBoost) até síntese generativa de tabelas e P&R, o que dilui a análise. A seção mais acionável para meus propósitos é a de P&R estruturado, e mesmo ali o levantamento cataloga métodos em vez de sintetizar quais são realmente confiáveis.

A descoberta do FinSheet-Bench de que agregações complexas pontuam 19,6% é o sinal de alerta mais específico para finanças aqui. Agregação de portfólio, consolidações em nível de fundo e comparações de múltiplos períodos são exatamente as operações que tornam os relatórios financeiros não triviais — e é exatamente onde as LLMs desmoronam.

Por que isso importa para a IA nas finanças

Livros razão do Beancount são tabelas. Quando um agente autônomo lê um ledger para detectar anomalias, gerar relatórios ou decidir sobre uma gravação de volta, ele está realizando raciocínio tabular. As evidências sugerem que as LLMs atuais lidam razoavelmente bem com buscas simples (recuperação de células em 73% para o GPT-4), mas colapsam nas operações que mais importam: agregação em várias etapas, estimativa de tamanho para grandes ledgers e raciocínio sobre variações estruturais.

A descoberta sobre serialização tem implicações práticas imediatas. Se estou enviando arquivos Beancount para uma LLM, o formato que escolho afeta a precisão em vários pontos percentuais antes mesmo de eu escrever uma única linha de lógica de agente. A sintaxe nativa do Beancount está próxima da extremidade "LN+Sep" da hierarquia de formatos — legível para humanos, subótima para LLMs. Converter para um intermediário mais estruturado (uma tabela JSON ou HTML de transações) antes de alimentar um modelo pode valer o custo de pré-processamento.

O colapso da complexidade em escala é a descoberta mais preocupante. Um livro razão real do Beancount para uma pequena empresa pode ter milhares de transações, dezenas de contas e um histórico de vários anos. Os resultados do FinSheet-Bench sugerem que, uma vez que uma tabela cresce até o tamanho em que realmente importa, a precisão da LLM degrada para um território que não é seguro para gravação autônoma de dados.

O que ler a seguir

• TableLLM (arXiv:2311.09206) — modelo ajustado (fine-tuned) treinado em 169 tabelas Kaggle (UniPredict); relatado como superando substancialmente o GPT-4 em zero-shot na previsão tabular, o que sugere que o ajuste específico de domínio ainda é a abordagem correta para tarefas de tabela específicas de finanças.
• TAT-QA (arXiv:2105.07624) — um conjunto de dados especificamente para raciocínio discreto sobre documentos financeiros híbridos (tabelas + texto, como relatórios de lucros); o modelo TAT-LLM que o acompanha é o precedente mais direto para a aplicação de modelos especializados ao raciocínio de tabelas financeiras.
• ToRR: A Benchmark for Table Reasoning and Robustness (arXiv:2502.19412) — foca em perturbações adversárias como embaralhamento de linhas e reordenação de colunas; se um agente Beancount for robusto à reordenação, é um sinal de que ele compreende a estrutura em vez da posição.