Tabelas em PDFs para RAG: por que achatar a grade destrói as respostas

O número que você precisa está em uma tabela, na interseção de uma linha e uma coluna. Achate o PDF para texto e essa interseção desaparece: o rótulo fica em um lugar, o valor em outro, e o modelo fica adivinhando qual número pertence a qual linha. É exatamente aí que o parsing ingênuo de tabelas derruba silenciosamente um sistema de RAG corporativo.

Por que tabelas quebram o pipeline

Uma tabela em PDF não é uma tabela no sentido de dados: é um conjunto de retângulos desenhados na página, com texto posicionado em células, muitas vezes sem marcadores explícitos de linha ou coluna. O parser precisa reconstruir a grade a partir da geometria espacial. Quando falha, três coisas dão errado ao mesmo tempo: a estrutura de linha/coluna se perde; o cabeçalho (que só aparece na primeira página de uma tabela de várias páginas) some das continuações; e a citação linha-a-linha se torna impossível, porque “linha 47” nunca foi reconstruída como linha.

A causa raiz é única: uma tabela é dado que alguém colocou em formato de layout porque o formato de distribuição exigia. O movimento certo não é tratar tabelas melhor como texto — é restaurá-las à sua forma estruturada nativa o quanto antes.

Quatro níveis de representação

• A. Linha-como-texto (line_df): cada linha vira uma linha Markdown (| col1 | col2 |). Funciona para perguntas simples que leem a tabela como prosa. A maioria das tabelas para aqui.
• B. table_df separado: a tabela vira um DataFrame com colunas nomeadas, para operações 2D como concatenar continuações ou projetar colunas.
• C. Extração colunar tipada: tabelas recorrentes viram dados (Parquet, DuckDB, Postgres) com colunas nomeadas e tipadas, consultáveis via SQL.
• D. Colunar heterogêneo: o fallback honesto quando os esquemas não normalizam.

O diagnóstico: table_df_meta

Para cada tabela detectada, registre cinco propriedades ortogonais: qualidade do parse (perfeito, parcial, falhou), tamanho (n_linhas × n_colunas), status do cabeçalho (presente, ausente, continuação), continuidade multipágina (autônoma, continua-de, continua-para) e contexto do documento (razão entre área de tabelas e área de texto). Esse pequeno DataFrame orienta a escolha do nível e das operações.

Cinco operações componíveis

1. O1 — Reconstrução estrutural por posições: reconstrói a grade agrupando posições de palavras em bandas de coluna e linha (histograma de coordenadas).
2. O2 — Concatenação multipágina com propagação de cabeçalho: propaga o cabeçalho da primeira página para as continuações e emite uma única tabela.
3. O3 — Projeção guiada pela pergunta: filtra colunas e linhas antes de enviar ao LLM, reduzindo uma tabela de 200 linhas a 4 linhas relevantes.
4. O4 — Extração colunar (B→C): promove tabelas recorrentes a um store colunar e despacha perguntas a um agente SQL.
5. O5 — Fallback com LLM de visão: renderiza a região da página como imagem e pede uma representação JSON — uma ordem de magnitude mais caro, por isso é sempre o último recurso.

O tipo de pergunta modula a resposta

Com o table_df pronto, o formato da pergunta decide a saída: busca de célula (“qual é o prêmio da cobertura de propriedade na Califórnia?”), intervalo/coluna (“quais as franquias de todas as coberturas?”) ou agregação (“qual o prêmio total em todos os estados?”). Neste último caso, a recuperação nem deveria acontecer: a pergunta vai direto para um agente SQL. A lição central é que o especialista que criou a tabela sabia que aquilo era dado — o trabalho do sistema é restaurá-la à forma estruturada para que a pergunta caia na célula certa.