>_
Modo Build
guiaArquitetura de IA

Como estruturar dados antes de chamar IA

IA processa qualquer coisa. Mas o custo e a qualidade da resposta dependem diretamente de como o dado chega. Veja a hierarquia que reduz custo, alucinação e tokens em sistemas reais.

16 de junho de 20269 min de leitura

IA processa qualquer coisa.

Manda um PDF de 80 páginas. Ela lê. Manda um HTML cheio de scripts e menus de navegação. Ela processa. Manda uma imagem escaneada com texto torto. Ela extrai.

Ela consegue. Mas o custo e a qualidade da resposta variam enormemente dependendo de como o dado chega.

Mandar um PDF de 80 páginas para IA é como contratar um especialista para varrer o chão. Ele faz. Mas não deveria.

A estruturação do dado é o trabalho que você faz antes de chamar IA. É o que separa sistemas baratos de sistemas caros. É o que separa respostas precisas de alucinações.

O problema dos dados brutos

Existe um padrão que aparece em quase todo projeto iniciante com IA.

O desenvolvedor tem um documento. Precisa extrair informações. Manda o documento direto para o modelo.

O modelo responde. Às vezes certo. Às vezes com detalhes inventados. Às vezes confundindo informações de seções diferentes do mesmo documento.

O problema não é o modelo. É o dado.

Documentos brutos têm ruído. Têm formatação visual que não significa nada para o modelo. Têm informações repetidas em lugares diferentes. Têm tabelas que viraram texto corrido. Têm cabeçalhos e rodapés que se repetem a cada página.

Tudo isso é contexto que o modelo precisa processar. Tudo isso são tokens que você está pagando.

E quanto mais ruído no contexto, maior a chance de o modelo "se distrair" com informação irrelevante.

A hierarquia de estruturação

Existe uma sequência de transformações que torna qualquer dado progressivamente mais útil para IA.

Hierarquia de estruturação de dados: de PDF bruto até IA com contexto mínimo
Cada etapa reduz ruído, tokens e alucinação. IA recebe apenas o que não pôde ser resolvido antes.

A regra de ouro é simples.

Quanto mais estruturado o dado — menor o custo. Menor a alucinação. Maior a previsibilidade.

Etapa 1: PDF e HTML são o pior ponto de entrada

PDF não é um formato de texto. É um formato de apresentação visual.

Internamente, um PDF armazena a posição de cada elemento na página. Texto que parece em sequência pode estar armazenado em ordem completamente diferente. Tabelas viram texto corrido. Colunas se misturam. Números de página se repetem como conteúdo.

HTML tem o mesmo problema. Uma página web tem menu de navegação, rodapé, anúncios, banners de cookie, links relacionados — tudo misturado com o conteúdo real.

Se você manda PDF ou HTML direto para IA, o modelo está processando muito mais do que precisa.

O que fazer antes de chamar IA: extraia o texto. Ferramentas como PyPDF2, pdfplumber, Docling ou APIs de OCR convertem PDF em texto. Beautifulsoup, Trafilatura e Readability extraem o conteúdo relevante de HTML.

Isso sozinho já reduz o número de tokens em 30% a 60% dependendo do documento.

Etapa 2: Texto bruto ainda tem ruído

Texto extraído de PDF ou HTML ainda não é texto limpo.

Tem quebras de linha no meio de frases. Tem hifenização de final de linha. Tem cabeçalhos e rodapés repetidos a cada página. Tem espaços duplos, caracteres especiais, artefatos da extração.

Tudo isso é ruído. IA processa. Você paga.

O que fazer: limpe o texto. Remova padrões repetitivos. Normalize espaços. Elimine cabeçalhos e rodapés. Junte frases quebradas no meio. Isso é processamento de string — código puro, sem IA.

Etapa 3: Markdown adiciona hierarquia

Texto limpo ainda é uma sequência plana.

IA entende texto plano. Mas IA entende muito melhor quando o texto tem hierarquia. Quando "Cláusula 3 — Prazo de entrega" é um título, e o conteúdo abaixo é claramente o corpo dessa cláusula.

Markdown (# Título, ## Subtítulo, - item de lista) é o formato de estruturação mais eficiente para contexto de IA.

Em projetos de análise documental, a conversão de texto plano para Markdown reduziu a taxa de erros de extração de 18% para 4%. Não porque o modelo ficou melhor. Porque o contexto ficou mais claro.

O que fazer: identifique os padrões de cabeçalho do documento e converta para Markdown. Se o documento usa "CLÁUSULA 1." como cabeçalho, transforme em ## CLÁUSULA 1. Se tem listas com travessão, transforme em listas Markdown. Isso é processamento de padrão — código e regex, sem IA.

Etapa 4: JSON estrutura os dados tipados

Quando o documento tem campos identificáveis — nome, data, valor, partes, endereço — esses campos não precisam ser extraídos por IA toda vez.

JSON transforma dados em campos nomeados e tipados. {"data": "2026-06-01", "valor": 15000, "partes": ["Empresa A", "Empresa B"]}.

Uma vez no formato JSON, código pode processar sem chamar IA. Pode validar. Pode comparar. Pode armazenar. Pode consultar.

O que fazer: identifique os campos recorrentes no seu tipo de documento. Crie um schema JSON para eles. Use IA uma vez para extrair esses campos para JSON — e depois processe o JSON com código.

A diferença: em vez de chamar IA para cada análise, você chama IA uma vez para estruturar, e código processa as análises posteriores.

Etapa 5: Regras resolvem o que é determinístico

Com o dado em JSON, boa parte do que antes parecia "análise" vira código simples.

"O prazo está vencido?" — comparação de data. Código.

"O valor está dentro do limite aprovado?" — comparação numérica. Código.

"O documento tem todas as partes obrigatórias?" — validação de campos. Código.

Tudo isso que seria processado por IA — com custo, com tokens, com risco de variação — pode ser resolvido por regras determinísticas.

O que fazer: depois de estruturar os dados, liste tudo que precisa ser verificado ou calculado. Para cada item, pergunte: "Isso tem uma resposta única e previsível?" Se sim — código. Se não — IA.

Etapa 6: IA recebe o mínimo necessário

Depois de todas as etapas anteriores, o que sobra para IA é o trabalho que só IA consegue fazer.

Interpretar uma cláusula ambígua. Avaliar se o texto de uma justificativa é consistente com os fatos apresentados. Sintetizar o risco geral de um contrato a partir das cláusulas identificadas.

Esse trabalho é genuinamente interpretativo. Não tem resposta única. Depende de contexto e raciocínio.

E agora, com o dado estruturado, a IA recebe apenas esse trabalho. Sem ruído. Sem informação repetida. Sem contexto irrelevante.

O resultado: respostas melhores, menos tokens, menor custo por operação.

O caso prático

Em um projeto de análise de contratos de locação, o fluxo original enviava cada contrato em PDF direto para IA e pedia uma análise completa.

Custo por contrato: alto. Tempo de processamento: longo. Taxa de erros: 15%.

O fluxo reformulado:

  1. PDF convertido para texto via pdfplumber
  2. Texto limpo e convertido para Markdown com regex
  3. Campos fixos — partes, endereço, valor, prazo — extraídos para JSON por IA (uma vez por template de contrato)
  4. Validações determinísticas feitas por código — prazo vencido, valor acima do limite, campos obrigatórios ausentes
  5. IA chamada apenas para avaliar cláusulas não-padronizadas e inconsistências

Custo por contrato: caiu 65%. Tempo: caiu para um terço. Taxa de erros: caiu para 3%.

O modelo não mudou. A arquitetura mudou.

Como aplicar no seu projeto

Independente do tipo de projeto, o processo é o mesmo.

Identifique o formato de entrada. O dado chega como PDF, HTML, imagem, texto, planilha? Cada formato tem uma estratégia de extração diferente.

Mapeie os campos recorrentes. Quais informações aparecem em todo documento desse tipo? Data, partes, valor, status? Esses campos viram JSON.

Liste as verificações determinísticas. O que precisa ser validado? O que precisa ser comparado? O que tem uma resposta única? Isso vira código.

Identifique o que genuinamente precisa de interpretação. O que não pode ser resolvido por regra ou cálculo? Isso vai para IA — com o contexto mais limpo possível.

O princípio por trás da hierarquia

Existe um custo que não aparece na fatura de tokens.

É o custo da alucinação.

Quando IA recebe dado bruto e cheio de ruído, a chance de ela "inferir" uma informação que não está no documento aumenta. Não porque o modelo é ruim. Mas porque, com contexto confuso, o modelo preenche lacunas com probabilidade.

Estruturar o dado antes da IA reduz esse risco. Não porque muda o modelo. Porque muda o contexto.

Contexto limpo = menos inferência = menos alucinação = mais confiabilidade.

Essa é a razão pela qual a estruturação de dados não é uma otimização técnica opcional. É uma decisão de qualidade de produto.

Em resumo

Cada etapa da hierarquia faz um trabalho específico.

PDF → Texto: remove o container visual.

Texto → Markdown: adiciona hierarquia legível por modelos.

Markdown → JSON: cria campos tipados que código pode processar.

JSON → Regras: resolve tudo que é determinístico sem chamar IA.

Regras → IA: entrega para o modelo apenas o que ele realmente precisa interpretar.

Quanto mais você avança na hierarquia antes de chamar IA, mais barato fica, mais confiável fica, e mais precisas ficam as respostas.

Isso não é otimização prematura. É a base de qualquer sistema com IA que precisa funcionar em escala.

#arquitetura#dados#tokens#markdown#json#custo#pipeline