Extração de documentos com campos faltantes sob controle

Comece pelo contrato de saída, não pelo prompt

A primeira decisão é definir exatamente o que o sistema precisa devolver. Um pedido como “extraia os dados do fornecedor” deixa ambiguidades sobre nomes, formatos, campos obrigatórios e tratamento de informação ausente. O contrato deve ser escrito antes da escolha do modelo, porque ele transforma uma tarefa aberta em uma operação verificável.

Para um cadastro hipotético de fornecedores, o contrato pode exigir razão social, nome fantasia, CNPJ, endereço, cidade, estado, e-mail, telefone, dados bancários e categoria de fornecimento. Cada campo precisa de tipo, formato esperado, obrigatoriedade e regra de ausência. Por exemplo, CNPJ deve ser uma string normalizada, enquanto data de validade deve seguir um padrão definido pela empresa.

Também vale separar valor extraído, status do campo e evidência. Um objeto conceitual pode conter valor, presente, confianca_operacional e trecho_origem. A confiança não deve ser tratada como verdade automática. Ela serve para priorizar validações, enquanto o trecho de origem permite investigar por que um dado foi preenchido ou deixado vazio.

• Defina campos obrigatórios, opcionais e proibidos para cada tipo de documento.
• Escolha formatos canônicos para datas, números, identificadores e telefones.
• Use valores nulos ou status explícito para ausência, em vez de texto inventado.
• Registre a página ou o trecho que sustenta cada valor quando isso for possível.

Modele a ausência como resultado válido

Campo faltante não é o mesmo que campo ilegível, campo contraditório ou campo que não se aplica. Essa distinção muda o fluxo operacional. Se o contrato aceita apenas um valor ou nulo, a equipe perde informação importante. Uma estrutura mais útil usa estados como encontrado, ausente, ilegível, conflitante e não aplicável, acompanhados de uma observação curta.

Considere um fornecedor que envia contrato social sem dados bancários. O sistema deve devolver dados_bancarios com status ausente, e não tentar completar a informação a partir de padrões ou de outro fornecedor. Se houver dois CNPJs em páginas diferentes, o status deve ser conflitante, com os valores candidatos preservados para decisão posterior. Essa regra reduz o risco de transformar um documento incompleto em um cadastro aparentemente completo.

A saída também deve distinguir “não localizado” de “não informado”. O primeiro descreve uma falha de localização ou leitura. O segundo indica que o documento foi examinado, mas não contém o campo. Essa diferença ajuda a escolher entre melhorar OCR, solicitar uma página adicional ou pedir um documento complementar. O comportamento recomendado aqui é uma decisão de arquitetura, não uma garantia oferecida pelo modelo.

• Crie uma enumeração de status antes de escrever instruções para o modelo.
• Não permita que o sistema preencha lacunas com inferências sem uma regra explícita.
• Guarde múltiplos candidatos quando o documento apresentar valores conflitantes.
• Defina quais status bloqueiam o cadastro e quais apenas geram pendência.

Fontes e referências: [2]

Valide o cadastro em camadas independentes

A validação deve ocorrer depois da extração e não depender apenas do texto gerado. Primeiro, valide o esquema: tipos, campos permitidos, valores nulos e enumerações. Depois, aplique regras de domínio, como quantidade de dígitos, máscara do CNPJ, sigla de estado, formato de e-mail e coerência entre município e unidade federativa. Por fim, confronte o resultado com dados internos autorizados, quando essa comparação fizer parte do processo.

No exemplo hipotético, um CNPJ com caracteres extras pode ser normalizado sem alterar seus dígitos, mas um CNPJ com quantidade incorreta de dígitos deve receber erro de validação. Um telefone sem código de área pode ser aceito como incompleto, se essa for uma regra do negócio. Já uma conta bancária extraída de uma imagem borrada deve ser marcada como ilegível, não corrigida por aproximação.

Essas camadas devem produzir motivos compreensíveis para cada pendência. “Campo inválido” é menos útil do que “CNPJ contém quantidade incorreta de dígitos” ou “estado não corresponde à lista permitida”. Mensagens específicas facilitam a correção do documento de entrada e permitem medir quais campos geram mais problemas. A aplicação pode então encaminhar somente exceções, sem tratar toda extração como um caso manual.

• Faça validação estrutural antes de qualquer regra de negócio.
• Mantenha normalização separada da correção, para preservar o valor original.
• Associe cada falha a um código e a uma mensagem acionável.
• Bloqueie gravações quando faltar um campo essencial ou houver conflito crítico.

Teste casos reais, incompletos e adversariais

Uma demonstração com documentos limpos não testa o risco principal. Monte uma coleção de avaliação com contratos completos, páginas ausentes, fotos inclinadas, tabelas, carimbos, abreviações, documentos em formatos variados e campos deliberadamente conflitantes. Para cada arquivo, escreva a saída esperada e as condições de aprovação. O conjunto deve representar a distribuição que o processo realmente recebe, não apenas os exemplos mais fáceis.

Avalie cada campo separadamente e também o registro completo. Métricas como presença correta, valor exato, formato válido, status de ausência e detecção de conflito revelam falhas diferentes. Uma saída pode acertar a razão social e ainda ser inadequada porque inventou dados bancários. Em tarefas estruturadas, testes de classificação, comparação e aprovação ou reprovação costumam ser mais úteis do que uma avaliação subjetiva do texto inteiro.

A avaliação precisa continuar depois da implantação, porque mudanças no prompt, no parser, no OCR ou no modelo podem alterar o comportamento. Registre entradas, saídas, validações e motivos de pendência conforme as regras de governança da empresa. A documentação de avaliação recomenda testes específicos para a tarefa, casos de borda, registro sistemático e acompanhamento contínuo, em vez de confiar na impressão de que o sistema parece funcionar.

• Separe conjuntos de desenvolvimento, validação e teste para evitar conclusões frágeis.
• Inclua documentos sem campos obrigatórios e documentos com valores contraditórios.
• Meça falsos preenchimentos, não apenas campos corretamente extraídos.
• Repita a avaliação a cada mudança relevante no pipeline.
• Use exemplos de falha para aprimorar o contrato e as regras, não somente o prompt.

Fontes e referências: [1]

Escolha um fluxo operacional que preserve o contexto

A extração não precisa terminar em um cadastro aprovado. Um fluxo mais seguro grava o resultado estruturado, a origem de cada campo, os erros de validação e o estado do registro. Quando um campo obrigatório está ausente, o sistema pode criar uma pendência com uma solicitação específica, como “envie a página que contém os dados bancários”. Quando há conflito, deve pedir esclarecimento sobre o valor, sem escolher silenciosamente um candidato.

Documentos podem conter instruções textuais que não fazem parte dos dados, inclusive conteúdo criado para influenciar o comportamento do sistema. Por isso, o texto extraído deve ser tratado como dado não confiável, não como instrução de execução. Saídas estruturadas com nomes de campos fixos, listas fechadas e limites de tamanho ajudam a impedir que conteúdo do documento escape para etapas posteriores como consultas, notificações ou alterações cadastrais.

Como exemplo hipotético, uma empresa poderia começar com apenas razão social, CNPJ, endereço e e-mail, deixando dados bancários fora da primeira versão. O fluxo teria três resultados: cadastro pronto, pendência de informação e conflito para análise. Essa redução de escopo torna o contrato mais testável e permite adicionar campos somente quando houver regras claras para extração, validação, ausência e atualização.

• Defina estados do processo além de aprovado e rejeitado.
• Isole o texto do documento de instruções destinadas ao sistema.
• Limite os campos que podem alimentar integrações ou alterações automáticas.
• Mantenha uma trilha técnica suficiente para reproduzir a decisão do pipeline.

Fontes e referências: [2][1]