TableLlama: Pode um Modelo Aberto de 7B Igualar o GPT-4 na Compreensão de Tabelas?

O log do MAC-SQL na semana passada me deixou pensando sobre o elo mais fraco em agentes baseados em tabelas: a capacidade do modelo subjacente de entender a estrutura e a semântica da tabela antes mesmo de gerar uma consulta. O TableLlama (NAACL 2024) ataca essa camada diretamente — não melhorando a interface de consulta, mas construindo um modelo de código aberto generalista que pode lidar com uma ampla gama de tarefas de tabela sem engenharia específica para a tarefa. Estou lendo-o agora porque é a resposta mais direta à pergunta se um modelo aberto de 7B pode realmente se igualar ao GPT-4 nos problemas de compreensão de tabelas que um agente Beancount enfrentaria.

O artigo

O TableLlama, de Tianshu Zhang, Xiang Yue, Yifei Li e Huan Sun da Ohio State University, faz o ajuste fino (fine-tuning) do Llama 2 (7B) em um novo conjunto de dados de ajuste de instrução que eles chamam de TableInstruct — 2,6 milhões de exemplos abrangendo 11 tarefas de tabela. Para lidar com o longo contexto que as tabelas impõem, eles adotam o LongLoRA, uma abordagem de extensão eficiente em parâmetros que alonga a janela de contexto para 8K tokens sem a necessidade de um re-treinamento completo. A avaliação cobre oito tarefas dentro do domínio (anotação de tipo de coluna, extração de relação, vinculação de entidades, aumento de esquema, preenchimento de linhas, QA de tabela hierárquica, QA de células destacadas e verificação de fatos), além de seis conjuntos de dados fora do domínio nos quais o modelo nunca foi treinado.

A afirmação principal: um único modelo aberto com ajuste fino pode igualar ou superar o SOTA (estado da arte) específico de cada tarefa na maioria dos benchmarks dentro do domínio e superar o modelo base Llama 2 de 5 a 44 pontos absolutos fora do domínio — inclusive reduzindo a lacuna em relação ao GPT-4 em várias tarefas.

Ideias-chave

• Em tarefas dentro do domínio, o TableLlama vence decisivamente o GPT-4 em tarefas de reconhecimento estrutural: Anotação de Tipo de Coluna (F1 94,39 vs 31,75), Extração de Relação (F1 91,95 vs 52,95), FeTaQA BLEU (39,05 vs 21,70) e precisão de execução HiTab (64,71 vs 48,40).
• Em conjuntos de dados fora do domínio, o cenário se inverte. O GPT-4 lidera na precisão do WikiTQ (68,40 vs 35,01) e HybridQA (58,60 vs 39,38) — ambas tarefas que exigem raciocínio composicional de múltiplos saltos (multi-hop) sobre tabelas, em vez de correspondência de padrões estruturais.
• O WikiSQL expõe a lacuna de geração de consultas de forma nítida: o TableLlama pontua 50,48% contra um SOTA de 92,70%. Essa lacuna de 42 pontos é o número mais relevante na prática para quem está construindo interfaces de linguagem natural para consulta (NL-to-query).
• O LongLoRA é fundamental aqui. Tabelas financeiras são longas. Sem a janela de contexto estendida, toda essa classe de tarefas estaria fora do alcance de um modelo de 7B.
• Os autores reconhecem que as restrições computacionais os limitaram ao tamanho de 7B, deixando as variantes de 13B e 70B sem avaliação.

O que se sustenta — e o que não

A configuração do benchmark mistura "alhos com bugalhos" de uma forma que merece escrutínio. A comparação dentro do domínio coloca um TableLlama ajustado contra o GPT-4 em modo zero-shot. Em tarefas baseadas em TURL, como Anotação de Tipo de Coluna, a pontuação de 31,75 F1 do GPT-4 não significa que o GPT-4 fundamentalmente não consegue entender tipos de coluna — significa que um prompt zero-shot sem ajuste específico de formato falha em um conjunto de dados que espera um formato de saída muito particular. A comparação honesta ocorre em tarefas fora do domínio, onde ambos os modelos não viram dados de treinamento, e lá a lacuna é desanimadora: precisão WikiTQ de 35,01 vs 68,40.

O WikiTQ é o teste de estresse correto porque exige perguntas como "Qual país ganhou mais medalhas em eventos onde o recorde anterior foi estabelecido antes de 1990?" — raciocínio composicional genuíno através das células da tabela. O déficit de 33 pontos do TableLlama no WikiTQ em comparação ao GPT-4 é o sinal mais claro de que o ajuste de instrução em tarefas estruturais não se transfere automaticamente para o raciocínio relacional.

As vitórias em aumento de esquema e vinculação de entidades são reais e significativas — essas tarefas genuinamente exigem a compreensão da estrutura da tabela de maneiras que um prompt zero-shot do GPT-4 tem dificuldade em processar. No entanto, elas também estão mais próximas da recuperação (retrieval) do que do raciocínio, o que limita o quanto esses resultados podem ser generalizados.

Uma preocupação separada: o conjunto de dados TableInstruct de 2,6 milhões de exemplos é um esforço de engenharia significativo, mas ele colapsa tipos de tarefas muito diferentes em um único formato de instrução. Não há uma ablação mostrando quais tipos de tarefas interferem entre si ou quais são fundamentais para os ganhos fora do domínio. O benchmark de acompanhamento do próprio grupo da OSU (TableBench, AAAI 2025) descobriu que modelos ajustados no TableInstruct alcançam um desempenho comparável ao GPT-3.5, mas ainda ficam aquém do GPT-4 — o que modera consideravelmente o otimismo do artigo original.

Por que isso importa para a IA financeira

Os livros contábeis do Beancount são tabelas estruturadas: cada entrada possui uma data, conta, valor e metadados opcionais. As tarefas de tabela neste artigo mapeiam-se diretamente nas operações que um agente Beancount precisa realizar. A anotação de tipo de coluna mapeia-se para entender quais contas pertencem a qual tipo de conta (Ativos, Passivos, Despesas). A vinculação de entidades mapeia-se para resolver nomes de favorecidos em descrições de transações inconsistentes. E a lacuna do WikiSQL mapeia-se precisamente para o problema da interface de linguagem natural do beanquery.

Os resultados aqui me dão uma visão calibrada: um modelo de 7B com ajuste fino pode lidar com o reconhecimento da estrutura do livro contábil de forma confiável o suficiente para ser útil, mas ainda não se pode confiar nele para traduzir perguntas de formato livre em expressões beanquery corretas sem um modelo de maior capacidade no loop. A precisão de 50% no WikiSQL (contra 93% do SOTA) significa que uma interface beanquery baseada apenas em modelos abertos geraria consultas erradas aproximadamente metade das vezes em formulações de perguntas desconhecidas. Para um agente de gravação direta (write-back), essa taxa de falha é alta demais. Para uma interface de consulta de apenas leitura com revisão humana, pode ser aceitável como um primeiro rascunho.

A contribuição do LongLoRA é diretamente aplicável: livros contábeis Beancount de vários anos podem facilmente exceder 8K tokens, e a abordagem aqui mostra como fazer o ajuste fino para tabelas longas sem um custo computacional proibitivo.

O que ler a seguir

• TableBench: A Comprehensive and Complex Benchmark for Table Question Answering (arXiv:2408.09174, AAAI 2025) — o acompanhamento do próprio grupo da OSU que avalia mais de 30 LLMs em QA de tabelas mais complexas e descobre que a lacuna entre modelos abertos e GPT-4 persiste mesmo após o ajuste fino com TableInstruct.
• TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) — pré-treinamento em execução SQL sintética como contraste ao ajuste de instrução; benchmark importante para o debate entre pré-treinamento vs ajuste fino na compreensão de tabelas.
• Rethinking Table Instruction Tuning (arXiv:2501.14693) — trabalho recente questionando se a receita padrão do TableInstruct realmente se generaliza e quais escolhas de composição de dados são mais importantes.