Como criar um modelo de extração de documentos sem código

A palavra "modelo" carrega muito peso no mundo do OCR. Durante vinte anos significou um mapa de coordenadas: desenhava-se um retângulo sobre o número da fatura, outro sobre o total, e o software lia os pixels que caíam ali dentro. Funciona até um fornecedor mudar o logótipo de sítio: o OCR por modelos prende cada campo a uma posição fixa, por isso um bloco de linhas reordenado ou uma nova caixa de dados bancários parte a extração e obriga a refazer o modelo à mão (ADVISORI). Com duzentos fornecedores, manter essa biblioteca vira trabalho permanente, uma falha tão conhecida que tem nome: template decay (Datamondial).

Um modelo de extração moderno é outra coisa por completo. É um esquema: a lista dos campos que quer, cada um com nome, tipo e uma descrição curta. Sem coordenadas, sem desenhar, sem código. A IA lê o documento como uma pessoa leria e preenche a sua lista, mesmo em layouts que nunca viu — aquilo a que o setor chama extração zero-shot (LlamaIndex).

Este guia constrói um, campo a campo.

Comece pela saída, não pelo documento

O erro clássico é abrir o PDF e apontar tudo o que está impresso. Acaba com 40 campos, 12 dos quais ninguém consulta, e cada campo a mais é mais uma coisa que pode vir errada.

Abra antes o destino: os cabeçalhos da folha de Excel, o ficheiro de importação do ERP, o formulário que hoje alguém preenche à mão. Essas colunas são os seus campos. Se um dado não tem casa a jusante, fica de fora. Pode sempre acrescentá-lo depois: um modelo é uma lista de texto, não um desenvolvimento.

Bom exercício de arranque: pegue no último documento processado à mão e pergunte o que foi de facto digitado. Em faturas costuma ser NIF do fornecedor, número, data, base tributável, IVA, total e as linhas. Pouco mais.

Passo 1: dê aos campos o nome que o seu sistema usa

Use os mesmos nomes do destino, em snake_case ou no formato que a importação espera: `nif_fornecedor`, `numero_fatura`, `data_emissao`, `valor_total`. Por duas razões:

O mapeamento para o ERP ou o Excel passa a ser correspondência direta de colunas, não uma camada de tradução.
O nome do campo já é uma pista para o modelo. `data_emissao` extrai melhor do que `data` num documento que também traz data de vencimento e data de entrega.

Evite nomes ambíguos dentro do próprio documento. `data`, `numero`, `valor` e `nome` são os quatro piores.

Passo 2: atribua um tipo a cada campo

Os tipos trabalham mais do que parece. Um esquema com nomes, tipos e restrições transforma a extração de um exercício de preencher espaços num problema de satisfação de restrições, e as descrições dão ao modelo uma orientação semântica fina campo a campo (Sandgarden).

Na prática precisa de quatro:

texto — nomes, moradas, códigos de referência. Atenção: um código como `0044` é texto, não número, ou perde o zero à esquerda.
número — tudo com que vai fazer aritmética: valores, quantidades, percentagens. Decida de uma vez se quer `1234.56` ou o formato local, e diga-o na descrição.
data — especifique sempre o formato de saída (`YYYY-MM-DD` é o único que ordena bem numa folha de cálculo).
tabela — linhas que se repetem. Já a seguir.

Passo 3: escreva as descrições como se estivesse a formar alguém novo

É aqui que um modelo passa de 80% para 97% de acerto, e é a parte que quase toda a gente salta.

Descrição fraca: *"O total da fatura."*

Descrição boa: *"Valor final a pagar com IVA incluído, impresso em baixo à direita do bloco de totais. Se o documento mostrar subtotal e total, use o valor maior que inclui impostos. Se houver linha de desconto de pronto pagamento, use o valor efetivamente devido."*

Três regras que compensam sempre:

Diga onde está e ao lado de quê. Os documentos são ambíguos; "o número a seguir à etiqueta *N.º Fatura* ou *Fatura n.º*" elimina a adivinha.
Diga o que fazer no caso esquisito. Dois candidatos, campo em falta, correção à mão. O caso esquisito é o que produz o erro que depois custa uma hora a encontrar.
Nunca use como exemplo um valor real de um documento real. Use uma amostra fictícia que só mostre o formato (`AB-0000/00`). Se escrever o número de fatura de um fornecedor verdadeiro, o modelo copia-o alegremente para documentos onde não tem nada que fazer. Este erro custa dias.

Passo 4: as linhas como campo do tipo tabela

Tudo o que se repete — linhas de fatura, leituras de contador, hóspedes, linhas de produto — é um único campo do tipo tabela, com os seus próprios subcampos.

Defina os subcampos como escalares: `descricao`, `quantidade`, `preco_unitario`, `taxa_iva_linha`, `total_linha`. Duas coisas a acertar:

Um conceito por coluna. Se um fornecedor imprime duas colunas de código (a referência interna e o modelo do fabricante), faça dois subcampos e não uma cadeia fundida. Juntar a jusante é trivial; separar é adivinhar.
Decida o que fazer às linhas que não são produto: subtotais, transportes de página, portes. Escreva na descrição se se extraem ou se ignoram; caso contrário terá uma resposta diferente por documento.

Com as linhas limpas, exportá-las é a parte fácil: veja como converter um PDF em Excel automaticamente.

Passo 5: defina o que significa "não existe"

Todo o modelo precisa de uma regra explícita para dados em falta. Por omissão: se o campo não está no documento, devolve null e não o deduzas.

Sem essa instrução, um modelo a quem peça a data de vencimento numa fatura que não a tem às vezes calcula-a somando 30 dias à data de emissão. É um palpite plausível e um erro silencioso, a pior combinação possível. Uma célula vazia é um problema que se vê; um valor inventado é um problema que se descobre três meses depois, numa reconciliação.

Passo 6: acrescente verificações que possa correr você mesmo

Cumprir o esquema não é o mesmo que acertar no conteúdo: a saída estruturada garante um JSON válido com a forma certa, não que os números lá dentro estejam corretos (Sandgarden), e os modelos não fornecem nativamente uma confiança fiável por campo (Docupipe). Portanto monte a aritmética você, fora do modelo:

Base + IVA − retenção = total.
A soma dos totais de linha bate certo com a base.
Os NIF cumprem formato e dígito de controlo.
As datas caem numa janela plausível.

O documento que falhe uma verificação vai para revisão humana; o resto passa direto. É toda a base de uma política de revisão sensata: onde pôr a fasquia foi tratado em quanta precisão precisa realmente.

Passo 7: teste primeiro com os documentos mais feios

Não valide um modelo com o PDF nativo e limpo do seu melhor fornecedor. Escolha dez documentos que incluam:

Uma fotografia torta e com má luz.
Uma digitalização de um fax de uma cópia.
Um documento de duas páginas em que a tabela continua na segunda.
O do fornecedor com o layout genuinamente estranho.
Um documento ao contrário: uma nota de crédito.

Passe-os, compare com o que uma pessoa teria digitado e corrija a descrição apenas dos campos que falharam. Duas ou três voltas costumam chegar. Resista à tentação de reescrever tudo depois de um mau resultado.

Modelos por onde vale a pena começar

Quase todos os casos são variações de cinco esquemas:

Fatura de fornecedor — nome e NIF, número, data, base, taxa e valor de IVA, retenção, total, tabela de linhas.
Documento de identificação / KYC — nome completo, número, data de nascimento, validade, nacionalidade, tipo de documento.
Fatura de serviços — morada de fornecimento, referência do contador ou ponto de entrega, titular, período, consumo, total.
Guia de remessa — fornecedor, número, data, referência à encomenda, linhas.
Cartão de visita — nome, cargo, empresa, email, telefone, site.

Cada um é um quarto de hora a escrever, não um projeto. É essa a mudança real: o custo de um novo tipo de documento passou de uma integração para uma tarde. Para calibrar o dinheiro em jogo, os benchmarks de 2025 da Ardent Partners situam o custo médio de processar uma fatura à mão em 10,89 $, contra 2,78 $ nas equipas automatizadas de referência (Ascend Software, Truvio).

Quando um modelo não chega

Um esquema por resultado, não por fornecedor. Todas as suas faturas de compra partilham modelo mesmo vindo de 200 empresas diferentes: é exatamente esse o sentido de ter deitado fora as coordenadas, e a razão pela qual os modelos de OCR por fornecedor se partem.

Precisa de um segundo modelo quando a *saída* é diferente: faturas e documentos de identificação alimentam tabelas diferentes, logo levam esquemas diferentes. Se um fornecedor concreto exigir tratamento especial — um código que tem de ser recomposto de determinada maneira — resolva-o como regra de mapeamento no seu sistema, não como bifurcação do modelo. Manter essa lógica a jusante é o que lhe permite enviar os dados limpos para o Excel ou para o ERP via API sem voltar a mexer na extração.

Perguntas frequentes

Tenho de treinar a IA com os meus documentos? Não. A extração zero-shot parte de um esquema e de um prompt e funciona em layouts nunca vistos, sem amostras de treino (LlamaIndex). O que se afina é o texto das descrições, não um modelo.

Quantos campos são demasiados? Não há limite rígido, mas cada campo cujo uso não sabe apontar é só risco. Comece pelas colunas que o destino tem mesmo e acrescente a pedido.

E se um fornecedor mudar o layout? Não acontece nada. Um esquema descreve significado, não posição, por isso um bloco deslocado ou um cabeçalho novo não o partem — ao contrário dos modelos por coordenadas, onde uma mudança de layout obriga a reconstrução manual (ADVISORI).

Posso extrair campos manuscritos? Números e verificações do tipo "existe assinatura", muitas vezes sim; escrita livre, com menos fiabilidade. Trate os campos manuscritos como sempre sujeitos a revisão, não de passagem direta.

Como sei que a extração está certa? Com verificações aritméticas e de formato que define você, não com a confiança autodeclarada do modelo: os modelos não fornecem de forma fiável uma pontuação de confiança por campo (Docupipe).

---

Experimente já o seu primeiro esquema com um documento real: extraia os dados do seu documento grátis, sem conta.