8.629 documentos entraram, 2.944 saíram pesquisáveis

8.629 documentos presidenciais brasileiros entraram no processo. 2.944 saíram do outro lado como texto estruturado, pesquisável por tema. Montei o PublicPolicyDB para testar um padrão bem simples — raspar, classificar, pesquisar — fora do território em que ele costuma ser demonstrado, e a distância entre esses dois números é a lição inteira.

A pergunta era essa: dá para transformar uma pilha dispersa de documento público numa base que alguém consulta por tema, sem meses de leitura e categorização à mão? Dá. Só que o preço fica numa etapa que quase ninguém desenha.

A etapa difícil vem antes da IA

Documento presidencial é publicado, fica disponível e continua inconsultável por tema. Quem precisa saber o que foi editado sobre uma área específica de política pública abre um PDF de cada vez, no Diário Oficial da União ou no site do órgão. O arquivo existe; o acervo, não.

A tentação é resolver isso com um chatbot que lê PDF. Só que a dificuldade está antes: coletar em escala e limpar. São quatro etapas em fila — raspar, extrair o texto do PDF, classificar, servir a busca — e cada uma perde documento se for malfeita. A classificação por IA, que parece a parte sofisticada, só se comporta bem sobre texto que chegou limpo.

Seis peças no pipeline, e a IA só entra na quarta

Selenium navega e coleta os documentos do Diário Oficial da União e das fontes governamentais. É scraping determinístico: abre página, encontra link, baixa arquivo. Nenhum modelo envolvido, nenhum custo por chamada.

PyMuPDF extrai o texto dos PDFs e das páginas. Um pipeline em Python normaliza e limpa o que saiu — cabeçalho repetido em toda página, quebra de linha no meio da frase, numeração colada no parágrafo.

Só então a OpenAI entra, classificando cada documento por tema, tipo de ato e área de política pública. Postgres guarda tudo com índice full-text, e o Flask serve a interface de pesquisa, com filtro por categoria, data e palavra-chave. Essa divisão tem um preço: a classificação fica barata e previsível porque recebe texto limpo, e em troca todo o risco do sistema se acumula nas duas etapas anteriores, onde a perda acontece em silêncio.

Quase metade dos PDFs extraídos não chegou a texto estruturado

Os três números do funil, na ordem: 8.629 documentos coletados, 5.685 PDFs com texto extraído, 2.944 textos estruturados. Pouco mais de um terço do que entrou saiu pesquisável. Entre a segunda e a terceira etapa, quase metade ficou pelo caminho.

Essa foi a surpresa. Eu contava com a classificação como ponto frágil — modelo trocando tema, confundindo tipo de ato, exigindo revisão humana em cima. Não foi ali. O que trava é antes: documento público brasileiro chega em formatos que resistem à extração.

As causas prováveis são conhecidas de quem já mexeu com esse tipo de arquivo — PDF que é imagem escaneada, sem camada de texto; diagramação em coluna que embaralha a ordem de leitura; tabela que sai como sopa de caractere. Prováveis, e não apuradas. Eu tenho o tamanho da perda, não a causa de cada uma delas, e essa é a fronteira do que posso afirmar sobre o acervo.

A conta de cada documento nasce na chamada de classificação

A coleta com Selenium não tem custo de modelo. Roda em máquina, gasta tempo e banda, e o preço por documento não muda quando o volume cresce. A extração com PyMuPDF é a mesma história: processamento local, sem chamada externa.

O custo variável aparece na classificação, sobre o texto já limpo. É por isso que a ordem das etapas importa em dinheiro, não só em engenharia — mandar para o modelo um PDF cru, ou um texto sujo com cabeçalho repetido em toda página, é pagar por token que não classifica nada.

Postgres com índice full-text é o custo do outro lado, o permanente. Depois que a coleta termina, é ele que sustenta a busca, e continua ligado mesmo em mês sem documento novo entrando.

Se eu recomeçasse, mediria a perda por etapa desde o primeiro lote

O funil só ficou visível quando os três números foram colocados lado a lado, no fim. Com a contagem por etapa instrumentada desde o primeiro lote, a perda entre extração e estruturação teria aparecido como problema na primeira semana, e não como saldo no fechamento.

A diferença é prática. Uma taxa de perda medida por lote e por origem aponta onde investir: se ela se concentra em documentos de um período ou de uma fonte, o conserto é específico — OCR só para os escaneados, por exemplo — em vez de um esforço genérico de melhorar a extração para tudo. Sem essa medição, a falha só aparece quando alguém procura um documento que devia estar ali e não está. E nesse momento você ainda não sabe se são dez ou dois mil.

O tema não é o ponto. Documento presidencial foi o acervo que eu tinha à mão; o padrão — raspar, classificar, pesquisar — serve para qualquer pilha de contrato, relatório ou comunicado que hoje ninguém consegue consultar. O que decide se ele rende não é a qualidade do modelo de classificação. É alguém contar quantos documentos sobrevivem a cada etapa, e não só quantos entraram.