TableMaster: Raciocínio Adaptativo para Compreensão de Tabelas com LLMs

O livro razão do Beancount é, em sua essência, uma tabela estruturada: contas como colunas, tempo como um eixo, valores e moedas como dados. Qualquer agente que raciocine sobre ele deve fazer o que o TableMaster faz — encontrar as linhas e colunas certas, entender o que os números significam e escolher se deve computar simbolicamente ou raciocinar em linguagem natural. O TableMaster de Lang Cao e Hanbing Liu (arXiv:2501.19378) é o pipeline de compreensão de tabelas mais capaz que vi até hoje sem ajuste fino (fine-tuning), e eu queria entender se ele realmente avança o estado da arte de forma fundamentada ou se apenas empilha heurísticas de prompting até que o benchmark se mova.

O artigo

O TableMaster é um framework baseado em prompts que aborda quatro modos de falha específicos que os LLMs exibem em perguntas e respostas (QA) tabulares: eles têm dificuldade em localizar a célula relevante em uma tabela grande, perdem o contexto semântico codificado nos cabeçalhos das colunas, alucinam na aritmética ao raciocinar em texto simples e falham quando o raciocínio simbólico (SQL, Python) encontra dados ruidosos ou de tipos mistos. Os autores respondem a cada falha com um módulo dedicado, reunidos em um pipeline de três estágios. O estágio um constrói uma "tabela de foco" (table-of-focus) — uma subtabela podada contendo apenas as linhas e colunas relevantes para a consulta — usando busca de colunas classificada por LLM e filtragem de linhas baseada em SQL. O estágio dois verbaliza essa subtabela em linguagem natural e verifica se a fatia extraída é realmente suficiente para responder à pergunta, expandindo-a iterativamente se necessário. O estágio três aplica raciocínio adaptativo: um LLM decide por consulta se deve executar uma cadeia de pensamento (chain-of-thought) sobre a descrição verbalizada ou gerar e executar Python ou SQL, com o caminho simbólico guiado pela descrição em linguagem natural para lidar com casos em que os valores da tabela são strings confusas em vez de números limpos.

Nenhum modelo novo é treinado. Tudo funciona em LLMs de propósito geral (GPT-3.5-turbo, GPT-4o-mini, Llama-3.1-70B) via prompts.

Ideias principais

• No WikiTQ com GPT-4o-mini, o TableMaster atinge 78,13%, em comparação com 55,60% do Chain-of-Table e 64,73% do PoTable no mesmo modelo — uma melhoria de 13,40 pontos em relação à próxima melhor linha de base.
• O mesmo padrão se mantém com o GPT-3.5-turbo (68,21% vs. melhor anterior ~58%) e Llama-3.1-70B (77,95%), mostrando que os ganhos não são específicos de um modelo.
• No TabFact (verificação de fatos), o TableMaster atinge 90,12% com GPT-4o-mini vs. 84,24% para Chain-of-Table — uma melhoria menor, mas consistente.
• A ablação revela que a remoção do raciocínio textual é o que mais prejudica (–4,28%), seguida pela remoção da extração de estrutura (–3,38%). A alternância adaptativa entre os modos é genuinamente fundamental.
• O tamanho da tabela é o preditor dominante de falha: o desempenho degrada monotonicamente à medida que a contagem de linhas, colunas e tokens aumenta, independentemente do modelo.
• O raciocínio simbólico degrada 31,8% em tabelas ruidosas vs. 20,5% para o raciocínio textual — o caminho simbólico guiado por texto existe precisamente para suavizar esse modo de falha.
• O raciocínio textual sozinho degrada 20,1% em consultas com muitos cálculos vs. 72,4% em tarefas sem cálculos — ilustrando exatamente por que a alternância híbrida importa.

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

O diagnóstico dos quatro desafios é bem fundamentado e mapeia claramente casos de falha reais. A ablação é honesta: a remoção de qualquer componente prejudica, com a magnitude proporcional ao quanto esse componente estava sendo realmente usado. Isso é mais forte do que a ablação usual, onde a remoção de componentes não muda nada porque o modelo aprendeu a contorná-los.

O que considero mais difícil de avaliar é o próprio classificador de raciocínio adaptativo. A decisão sobre rotear uma consulta para texto ou código é feita pelo LLM sob indução de prompt — o artigo não relata com que frequência esse roteamento é correto, o que acontece quando ele falha (por exemplo, roteia um cálculo para texto) ou se uma regra simples (a consulta contém operadores aritméticos?) teria um desempenho comparável. Dado que o raciocínio textual é o maior contribuidor na ablação, suspeito que a maioria das consultas siga o caminho do texto por padrão e o ramo simbólico carregue uma fração menor do que a formulação sugere.

A comparação com o Chain-of-Table também está um pouco inflada pelo contexto. A avaliação original do Chain-of-Table usou PaLM 2 e GPT-3.5 — o número de 55,60% do Chain-of-Table mostrado para o GPT-4o-mini pode refletir uma sub-otimização dos prompts do Chain-of-Table para esse modelo, em vez de uma vantagem arquitetônica genuína. Isso não invalida o resultado, mas significa que a diferença principal deve ser lida como um limite superior para a melhoria real.

O artigo passou por seis revisões desde janeiro de 2025, o que é incomum. O escopo é restrito a conjuntos de dados em inglês e tabelas de até algumas centenas de linhas. Nenhuma análise sobre o custo operacional é apresentada — cada consulta agora requer várias chamadas de LLM (classificação de colunas, SQL de linha, verificação de suficiência, verbalização, roteamento, raciocínio) e, aos preços dos modelos de ponta, isso se acumula rapidamente.

Por que isso importa para a IA financeira

Os modos de falha que o TableMaster aborda são exatamente os modos de falha que espero que os agentes de livros razão Beancount encontrem. Um livro razão com três anos de transações em 40 contas é uma tabela grande e semanticamente rica — "qual foi meu lucro líquido do trabalho freelancer no terceiro trimestre de 2023?" requer encontrar as contas certas (busca de coluna), filtrar por data (busca de linha), entender que "freelancer" mapeia para vários nomes de contas (enriquecimento semântico) e somar valores com precisão (aritmética simbólica). O pipeline do TableMaster, aplicado a uma interface beanquery, atacaria precisamente essas etapas.

A limitação que mais importa para livros razão é a escala. As tabelas do WikiTQ têm, no máximo, algumas dezenas de linhas e um punhado de colunas; um livro razão Beancount real de vários anos tem milhares de lançamentos. O artigo mostra que o desempenho degrada monotonicamente com o tamanho da tabela e não testa além de algumas centenas de linhas. A extração da tabela de foco pretende resolver isso, mas o filtro de linha baseado em SQL é, por si só, uma consulta gerada por LLM sobre a tabela completa — movendo o problema difícil em vez de resolvê-lo. A interação com memória hierárquica no estilo MemGPT ou com uma camada de beanquery pré-indexada é o próximo passo natural.

O caminho simbólico guiado por texto é diretamente aplicável ao Beancount. Os valores do livro razão são frequentemente cercados por metadados (códigos de moeda, anotações de lote, marcadores de base de custo) que fariam um interpretador Python float ingênuo falhar. Basear a geração de código em uma descrição em linguagem natural do que o código deve computar é uma mitigação sensata, embora precise de uma avaliação sistemática em formatos de exportação reais do Beancount.

O que ler a seguir

• H-STAR: LLM-driven Hybrid SQL-Text Adaptive Reasoning on Tables (arXiv:2407.05952) — o precursor mais direto do roteamento adaptativo do TableMaster, com uma estratégia de extração de coluna e depois linha em dois estágios; vale a pena comparar as arquiteturas diretamente para entender o que o TableMaster adiciona.
• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — embora o TableMaster foque em QA, o pipeline de representação e normalização de tabelas é igualmente relevante para a detecção de anomalias; a pontuação baseada em probabilidade do AnoLLM precisa de um estágio de pré-processamento semelhante.
• CFMS: A Coarse-to-Fine Multimodal Synthesis Framework for Enhanced Tabular Reasoning (arXiv:2604.10973) — parece estender a ideia de extração de granularidade grossa para fina para tabelas multimodais; relevante se as visualizações do livro razão Beancount (gráficos, extratos em PDF) precisarem ser reconciliadas com entradas de texto estruturadas.