Capítulo 2 — Parsing Inteligente de Documentos

Segundo post do passeio capítulo a capítulo pelo LLM Primer III: Aprimorando a IA Empresarial com RAG. Um sistema de recuperação herda a qualidade de suas entradas — e a camada de entrada é onde mora, em silêncio, a causa mais comum de qualidade decepcionante em RAG.

Por que este capítulo existe

A primeira versão de um pipeline RAG quase sempre usa o utilitário de PDF-para-texto que estava à mão. Sai texto de aparência plausível, o índice é populado, o modelo produz respostas de aparência plausível. Meses depois o time descobre que tabelas foram achatadas em silêncio em prosa, papers em múltiplas colunas foram intercalados linha a linha, notas de rodapé foram emendadas dentro de parágrafos, e legendas de figuras foram perdidas por completo. O teto de qualidade da recuperação foi fixado por essas decisões antes mesmo de a recuperação ser configurada. O capítulo é sobre levar a camada de entrada a sério, porque nada a jusante recupera o que o parser jogou fora.

2.1 Por que achatar um PDF perde o que importa

Um PDF é uma lista de glifos com coordenadas, desenhados sobre páginas de dimensão declarada. A estrutura visual que um humano vê — colunas, tabelas, legendas, barras laterais — não está armazenada em nenhum lugar de forma semântica. Ela existe na imagem renderizada. Então "extrair texto do PDF" é mais difícil do que parece: o extrator ingênuo lê o fluxo de glifos na ordem em que as marcas foram escritas, o que numa página de duas colunas intercala as colunas linha por linha. O que sai é texto gramaticalmente esquisito e semanticamente quebrado, composto por palavras reais do documento real — o tipo de falha difícil de pegar numa amostragem leve.

Tabelas são piores. O significado de 1.427 na linha 3, coluna 4 é a interseção de Q3 2024 e região Nordeste. Para um extrator ingênuo é um número sem relação com nenhuma das strings, porque as strings foram desenhadas em outro lugar da página. A tabela se dissolve numa lista de números separados por espaços, e queries sobre "receita do Nordeste no Q3" não acham nada — o chunk que contém 1.427 não contém Nordeste perto o suficiente para associá-los no embedding. Formulários têm o modo de falha análogo: rótulos e valores saem como strings desconectadas, e o índice agora tem valores sem o nome do campo. OCR em documentos escaneados adiciona erros em nível de caractere justamente em termos técnicos e nomes próprios — onde a recuperação é mais sensível à grafia.

2.2 Parsing consciente de layout: recolocando os sinais

A resposta é uma classe de ferramentas que trata o documento como um artefato bidimensional em vez de um fluxo de glifos. A página é renderizada como imagem, um modelo de detecção de layout a segmenta em regiões (parágrafos, tabelas, figuras, cabeçalhos), a ordem de leitura é reconstruída por heurísticas de layout, e tabelas passam por modelos especializados que recuperam estrutura de linha e coluna em HTML, Markdown ou JSON. A saída deixa de ser uma string achatada — é uma representação estruturada que preserva a hierarquia, amarra legendas a suas figuras e expõe metadados em que o chunker a jusante pode dividir.

O custo é computacional — um a vários segundos por página versus milissegundos para extração ingênua, o que importa em corpora de milhões de páginas. E o modo de falha muda: um extrator ingênuo que estraga uma tabela ao menos produz texto. Um parser consciente de layout que classifica errado uma região produz saída estruturada que pode estar confiantemente errada — uma figura tomada por tabela, um cabeçalho detectado como corpo. O time precisa amostrar páginas complexas representativas antes de confiar no pipeline em escala.

2.3 O panorama atual de ferramentas

O espaço consolidou em meia dúzia de ferramentas que vale conhecer. LlamaParse é o parser hospedado da LlamaIndex — forte em tabelas e formulários, o default certo se você já está dentro do ecossistema LlamaIndex e serviços gerenciados são aceitáveis. Docling é o parser open-source da IBM consciente de layout, com o modelo TableFormer cuidando de estruturas de tabela complexas, e é a escolha natural para implantações on-premises onde os dados não podem sair da sua infraestrutura. Unstructured otimiza por abrangência — muitos formatos de entrada, um modelo de particionamento por elementos tipados, interface a jusante consistente — e é a primeira escolha mais segura para corpora empresariais heterogêneos. Marker-PDF faz uma coisa muito bem: PDF para Markdown limpo, com atenção particular a títulos, listas e blocos de código. Firecrawl resolve o problema do lado web — URL entra, Markdown limpo sai, com boilerplate removido. DeepSeek-OCR, lançado no fim de 2025, codifica páginas em pouquíssimos tokens de visão para memória e compute dramaticamente menores, e é o concorrente sério quando throughput domina o orçamento.

A avaliação prática é assim: pegue cinquenta documentos representativos que cubram o espectro de dificuldade do corpus, rode cada ferramenta sobre eles, compare manualmente nas dimensões que importam para o seu corpus — fidelidade de tabela, ordem de leitura em múltiplas colunas, acurácia de OCR em escaneados, tratamento de figura, throughput. O vencedor raramente é o melhor em todas. É o melhor nas dimensões que mais importam para o seu corpus, a um custo que o seu orçamento absorve.

2.4 A alternativa multimodal

Uma trilha paralela rejeita o enquadramento por inteiro. Se um modelo visão-linguagem consegue ler uma página bem o bastante para responder perguntas sobre ela, por que converter para texto? Retrievers multimodais de interação tardia como ColPali e ColQwen2 estendem a ideia do ColBERT para imagens — um embedding por patch da página, pontuado contra os tokens da query via agregação por similaridade máxima. O retriever traz à tona páginas cujo conteúdo textual sozinho não casaria, porque a informação relevante estava numa tabela, numa figura ou num layout que a extração de texto distorceria. O modelo visão-linguagem lê a página direto.

O custo é substancial e vale ser concreto. Um chunk de texto padrão produz um embedding de ~1.024 dimensões — alguns kilobytes. Uma página codificada com ColPali produz cerca de mil embeddings de patch de ~128 dimensões — meio megabyte por página. O tamanho de índice para um milhão de páginas cresce de gigabytes para centenas de gigabytes, a pontuação fica mais cara, e a geração exige um modelo visão-linguagem. Para corpora densos em tabelas e figuras o upgrade é real. Para corpora dominados por prosa com orçamento apertado, recuperação de texto bem parseado continua o default custo-eficaz. Configurações híbridas — ColPali para recuperação, texto convertido para geração, ou o contrário — são onde a maior parte do RAG multimodal de produção vai aterrissar no próximo ano.

O que o Capítulo 2 prepara

Um parse limpo, consciente de layout, é necessário para RAG de qualidade e suficiente para nada. Um documento parseado ainda é um documento — precisa ser quebrado em pedaços pequenos o bastante para embedar e grandes o bastante para significar algo. O chunker que ignora as dicas estruturais do parser joga fora o que o parser se esforçou para preservar. As duas camadas têm que ser desenhadas juntas, e o Capítulo 3 percorre o espectro de chunking e as técnicas de fronteira que o reformularam.

Próximo — Capítulo 3: Frameworks Avançados de Chunking. O espectro de chunking de tamanho fixo a consciente de estrutura, o mito do overlap, o penhasco de contexto, e as técnicas de recuperação contextual e late chunking que mudaram a conta.