TAPAS: Table QA Fracamente Supervisionado Sem SQL, e o Que Isso Significa para o Beancount

Tenho dedicado tempo à linhagem text-to-SQL — BIRD, DIN-SQL, MAC-SQL — mas todos eles compartilham uma suposição que desejo questionar: a de que a interface correta para Table QA é a geração de SQL. O TAPAS, publicado por Herzig et al. no Google Research (ACL 2020), faz a aposta oposta. Ele nunca gera uma consulta. Em vez disso, ele apenas seleciona células e, opcionalmente, aplica uma agregação escalar, treinado de ponta a ponta apenas a partir das denotações das respostas.

O artigo

O TAPAS estende o BERT para codificar tabelas adicionando seis novas dimensões de incorporação (embeddings) sobre os IDs padrão de posição e segmento. O Column ID e o Row ID marcam onde cada token vive na grade da tabela. Um Rank ID codifica a ordem numérica relativa dentro de colunas classificáveis (rank 0 significa não comparável, rank i+1 para o i-ésimo menor valor). Um indicador de Previous Answer (Resposta Anterior) sinaliza células que foram selecionadas na rodada conversacional anterior. Combinado com o segment embedding binário que distingue tokens de pergunta de tokens de tabela, isso dá ao TAPAS sua representação de token de sete tipos.

No momento da inferência, o modelo seleciona um conjunto de células definindo limiares para as probabilidades por célula e, em seguida, aplica um de quatro operadores de agregação — NONE, COUNT, SUM ou AVERAGE — para produzir a resposta final. Não há SQL intermediário ou forma lógica. O pré-treinamento executa um objetivo padrão de masked language model sobre 6,2 milhões de pares de texto-tabela da Wikipedia em inglês.

Ideias-chave

• Os embeddings de coluna/linha são estruturais. A ablação mostra que removê-los custa 19,4 pontos de precisão no SQA, 10,6 no WikiSQL e 11,6 no WikiTQ — uma perda muito maior do que qualquer outro componente arquitetural.
• O pré-treinamento de tabela importa quase tanto quanto. Removê-lo reduz o SQA em 12,5 pontos e o WikiTQ em 11,1 pontos, mesmo após o ajuste fino (fine-tuning).
• No SQA (Table QA conversacional), o TAPAS aumenta a precisão de 55,1% para 67,2%, um salto de 12 pontos. O embedding do token Previous Answer é o mecanismo que faz a continuidade conversacional funcionar sem um rastreador de estado separado.
• No WikiSQL (tabela única, majoritariamente busca e agregação), o TAPAS atinge 83,6% — essencialmente igualando o parser semântico SOTA de 83,9%, com zero geração de SQL.
• O aprendizado por transferência do WikiSQL para o WikiTQ (raciocínio em várias etapas e colunas) rende 48,7%, 4,2 pontos acima do estado da arte na época. A transferência do SQA rende 48,8%.
• A supervisão fraca é o principal argumento de viabilidade: o modelo é treinado em pares (pergunta, resposta), não em triplos (pergunta, SQL, resposta), permitindo anotar grandes corpora sem experiência em SQL.

O que se sustenta — e o que não

A percepção central — de que muitas perguntas de Table QA podem ser respondidas selecionando células e aplicando uma das quatro operações escalares — é empiricamente sólida para os benchmarks testados. Mas a análise honesta de erros do artigo no WikiTQ é reveladora: 37% dos erros não são classificados pelos próprios autores, 16% exigem manipulação de strings que o modelo não consegue fazer e 10% envolvem raciocínio temporal complexo. Isso significa que o teto do TAPAS não se deve ao fato de os operadores de agregação estarem errados; trata-se de categorias inteiras de perguntas estarem estruturalmente fora de alcance.

A restrição de 512 tokens é uma barreira intransponível. Tabelas com mais de aproximadamente 500 células precisam ser truncadas, e o modelo não possui mecanismo para raciocínio em múltiplas tabelas. Isso não é um problema de ajuste — é um problema arquitetural. O modelo também não consegue aninhar agregações: uma pergunta como "quantas contas têm um saldo médio maior que zero?" requer duas passagens (média dentro de um predicado COUNT), o que a cabeça de quatro operadores não consegue expressar.

O TAPEX (ICLR 2022) aborda diretamente o gargalo do pré-treinamento substituindo o MLM de tabela da Wikipedia pela execução de SQL sintético em programas gerados automaticamente, elevando o WikiTQ para 57,5% (+4,8) e o SQA para 74,5% (+3,5). Essa é uma lacuna significativa. Mas o TAPEX herda os mesmos limites arquiteturais de tamanho de tabela e profundidade composicional.

A questão não resolvida mais profunda que nenhum dos artigos aborda é se o paradigma de seleção de células é mais adequado para o Table QA do mundo real do que a geração de SQL em termos práticos — não pela precisão do benchmark, mas por garantias de auditabilidade e correção. A seleção de células é opaca: você obtém uma resposta, mas nenhum programa. A geração de SQL é verbosa, mas verificável. Para uso em produção, essa compensação importa mais do que alguns pontos de precisão.

Por que isso importa para a IA nas finanças

Um livro razão Beancount é efetivamente uma tabela estruturada e plana: contas em linhas, valores, datas, moedas e tags em colunas. O paradigma de seleção direta de células do TAPAS mapeia-se naturalmente para as consultas de livro razão mais comuns — "qual é o total gasto em mantimentos em março?" — que são exatamente agregações SUM e COUNT sobre linhas filtradas. O embedding Previous Answer é diretamente útil para sessões conversacionais onde um usuário refina uma consulta ("e quanto ao ano passado?").

Mas os livros razão Beancount em escala quebram as restrições do TAPAS. Um livro razão de vários anos com milhares de transações excede o orçamento de 512 tokens em ordens de magnitude. As hierarquias de contas exigem raciocínio entre grupos de linhas. Consultas como "quais contas têm uma saída líquida maior do que a sua média nos últimos três anos?" precisam de agregações aninhadas que a cabeça de quatro operadores não consegue expressar. E fundamentalmente: para a segurança de gravação (write-back), a seleção de células não oferece nenhum programa auditável para verificar antes de confirmar uma alteração. O SQL, pelo menos, fornece um artefato inspecionável.

Minha conclusão provisória é que o paradigma de seleção de células é a interface correta para uma camada de consulta somente leitura em linguagem natural sobre pequenos instantâneos de livros razão — transações de um mês, histórico de uma única conta. Para o raciocínio em todo o livro razão e qualquer coisa que envolva gravação, uma abordagem de síntese de programa (seja no estilo SQL ou DSL do Beancount) permanece mais segura e expressiva.

O que ler a seguir

• TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) — o sucessor direto que substitui o MLM da Wikipedia pela execução de SQL sintético; responde diretamente se o pré-treinamento em programas supera o pré-treinamento em texto para Table QA.
• Binder: Binding Language Models in Symbolic Languages (arXiv:2210.02875) — usa GPT-3 para gerar programas em SQL ou Python sobre tabelas e atinge o SOTA no WikiTQ; a abordagem híbrida que os defensores da seleção de células precisam considerar.
• OmniTab: Natural and Artificially Structured Data for Table QA (arXiv:2207.02270) — combina corpora de tabelas naturais com dados SQL sintéticos em uma única receita de pré-treinamento; testa se o TAPAS e o TAPEX são complementares em vez de concorrentes.