Chain-of-Table: Evoluindo Tabelas na Cadeia de Raciocínio de LLMs

Continuo retornando à mesma observação desconfortável sobre o raciocínio tabular: quando as LLMs explicam seu trabalho sobre tabelas usando texto simples de cadeia de pensamento (chain-of-thought), elas estão narrando uma representação enquanto raciocinam sobre outra. O Chain-of-Table, um artigo da Google Research publicado no ICLR 2024, leva essa tensão a sério e propõe uma correção simples — permitir que a própria tabela carregue o estado de raciocínio intermediário, não o texto.

O artigo

Wang et al. apresentam Chain-of-Table: Evoluindo Tabelas na Cadeia de Raciocínio para Compreensão de Tabelas (arXiv:2401.04398, ICLR 2024). O artigo aborda uma lacuna deixada pelo prompting de cadeia de pensamento padrão quando aplicado a dados tabulares: o CoT raciocina em linguagem natural, mas as tabelas são artefatos estruturados, e a narração linguística das transformações de tabela é prolixa e apresenta perda de informação. A ideia central é permitir que a LLM planeje uma sequência de operações de tabela programáticas — filtrar, agrupar, ordenar, selecionar coluna, adicionar coluna — executando cada uma para produzir um estado de tabela intermediário e fornecendo essa tabela evoluída de volta à LLM como entrada para a próxima etapa. A resposta final é gerada a partir do estado terminal da tabela, em vez de uma longa cadeia de texto. Os autores fazem uma analogia explícita ao desenvolvimento SQL: um analista experiente escreve etapas intermediárias de CREATE TABLE ... AS SELECT, não uma única consulta monolítica. O Chain-of-Table formaliza essa prática para agentes de LLM.

A avaliação abrange três benchmarks: WikiTableQuestions (WikiTQ), TabFact e FeTaQA. O modelo primário é o PaLM 2, com validação cruzada no GPT-3.5 e LLaMA 2 70B.

Ideias principais

• O Chain-of-Table alcança 67,31% de acurácia de denotação no WikiTQ contra 61,48% do Dater, o baseline anterior mais forte — uma melhoria de +5,83 pontos percentuais.
• Em tabelas que excedem 4.000 tokens, a vantagem cresce para +10,25 pontos (44,87% vs. 34,62%), que é onde o método mais importa na prática.
• A acurácia no TabFact atinge 86,61% contra 84,63% do Dater; o BLEU do FeTaQA melhora de 29,47 para 32,61.
• As cinco operações atômicas — f_select_row, f_select_column, f_group_by, f_sort_by, f_add_column — cobrem a grande maioria dos padrões de raciocínio observados nesses benchmarks; f_group_by realiza a maior parte do trabalho no WikiTQ, onde a contagem é o modo de falha dominante.
• O Chain-of-Table requer no máximo 25 gerações de amostras por pergunta, contra 50 para o Binder e 100 para o Dater — um ganho de eficiência de 50–75% juntamente com melhor acurácia, o que é genuinamente incomum em pesquisas de LLM, onde a compensação quase sempre vai na direção oposta.
• A abordagem é agnóstica em relação ao modelo: supera consistentemente os baselines de CoT textual no PaLM 2, GPT-3.5 e LLaMA 2.

O que se sustenta — e o que não

A contribuição empírica central do artigo é sólida. Os benchmarks são padrão, os baselines são justos e a história da eficiência é convincente. Tornar a própria tabela uma representação intermediária explícita, em vez de narrá-la em prosa, é uma ideia limpa com motivação intuitiva, e os resultados em tabelas grandes são a evidência mais convincente: quando a tabela mal cabe no contexto, ter operações que a reduzem progressivamente ao que importa é claramente melhor do que produzir ainda mais texto.

Dito isso, existem lacunas reais. A análise de propagação de erros é superficial. Se a LLM gerar um argumento f_select_row errado na segunda etapa de uma cadeia de cinco etapas, todas as operações subsequentes serão executadas em uma tabela intermediária corrompida, e a resposta final será inútil. O artigo relata a acurácia agregada, mas não analisa com que frequência o raciocínio falha devido a erros nas etapas iniciais versus erros nas etapas finais, ou se a abordagem é robusta a operações parcialmente erradas. Para um método que depende de uma sequência de chamadas corretas, esta é uma omissão significativa.

O vocabulário de operações também é uma aposta. Cinco operações cobrem a maioria dos padrões no WikiTQ e TabFact porque esses benchmarks foram projetados em torno de tarefas de tabelas relacionais. Tabelas financeiras do mundo real — balanços patrimoniais, balancetes de verificação de livro razão, cronogramas fiscais — rotineiramente exigem joins entre tabelas relacionadas, agregados calculados com condições (SOMA de débitos ONDE a conta COMEÇA COM '6') e transformações de pivô (pivot). Nenhuma delas está no conjunto de operações. Os autores reconhecem isso implicitamente, mas não o testam.

Finalmente, não há uma explicação teórica de por que os estados intermediários da tabela seriam melhores do que o texto intermediário. A intuição é atraente, mas o artigo é puramente empírico. Os trabalhos subsequentes (TableMaster, arXiv:2501.19378; H-STAR, NAACL 2025) moveram-se rapidamente para abordagens híbridas adaptativas que misturam SQL e raciocínio textual, o que sugere que a comunidade percebeu a mesma lacuna que eu: operações tabulares puras não são universalmente melhores, apenas melhores nos benchmarks testados.

Por que isso importa para a IA financeira

Para agentes de livro razão Beancount, a arquitetura do Chain-of-Table mapeia quase perfeitamente o que eu desejo em um pipeline de gravação (write-back). Uma consulta Beancount como "quais são minhas despesas líquidas por categoria para o 1º trimestre, excluindo transações marcadas com :ignore?" requer exatamente o tipo de transformações sequenciais de tabela que o artigo propõe: filtrar linhas por data, filtrar por tag, agrupar por categoria de conta, somar valores. Se o agente puder planejar isso como uma cadeia de operações intermediárias explícitas, em vez de gerar uma única consulta ou raciocinar sobre ela em prosa, a trilha de auditoria será legível e cada etapa será independentemente verificável.

A melhoria da eficiência em tabelas grandes também é diretamente relevante. Um livro razão Beancount de vários anos com dezenas de milhares de transações excede facilmente 4.000 tokens quando materializado. A melhoria de 10 pontos nesse regime não é um artefato de benchmark; ela reflete o que realmente acontece quando a tabela precisa ser progressivamente estreitada antes que o raciocínio possa ser preciso.

A peça que falta para o Beancount é a operação de join. A contabilidade de partidas dobradas vincula transações entre contas, e qualquer tarefa de reconciliação exige raciocínio em pelo menos duas cronologias de conta. O Chain-of-Table, como publicado, não pode expressar isso. Estender o vocabulário de operações para incluir joins entre contas é o próximo passo óbvio de engenharia para um agente de raciocínio Beancount de produção.

O que ler a seguir

• Chain-of-Query: Unleashing the Power of LLMs in SQL-Aided Table Understanding via Multi-Agent Collaboration (2025, arXiv:2508.15809) — estende o conceito de operação para a geração de SQL multi-agente, o que aborda a lacuna de join.
• TableMaster: A Recipe to Advance Table Understanding with Language Models (arXiv:2501.19378) — introduz o raciocínio adaptativo que alterna entre operações tabulares e CoT textual; o sucessor mais direto do Chain-of-Table.
• DATER: Decomposition-based Text-to-SQL for LLMs over Long Context (arXiv:2308.01463) — abordagem de decomposição complementar para SQL complexo em esquemas grandes, relevante para o design de interfaces de linguagem natural para beanquery.