Para validar valores decimais extraídos por IA, preserve o texto original, identifique o formato esperado e converta o resultado com regras determinísticas. Vírgula, ponto, símbolo de moeda e arredondamento precisam de verificações próprias. Uma resposta escrita como “R$ 1.250,30” pode parecer correta e ainda representar o campo errado do documento.
Organize o processo em quatro etapas: extração, interpretação do formato, cálculo e apresentação. A IA pode ajudar na primeira e apontar o contexto; as demais devem seguir um contrato verificável. Este guia trata da integridade técnica dos dados, com valores fictícios, sem definir regras contábeis para uma operação.
Resumo rápido
- Guarde o valor original junto da versão normalizada.
- Defina localidade, moeda, escala e unidade por campo.
- Recuse interpretações ambíguas em vez de escolher silenciosamente.
- Use representação decimal e uma regra explícita de arredondamento.
- Teste conversão, cálculos e exibição como etapas separadas.
1. Separe o número da forma de escrever
O texto “1.234,50” combina uma representação numérica com convenções de apresentação. Antes de convertê-lo, o sistema precisa saber qual convenção vale para aquela entrada. Não basta reconhecer que existem dígitos. Um arquivo importado pode seguir um padrão diferente daquele usado na interface brasileira.
Crie um contrato para cada campo: nome, descrição, localidade esperada, unidade, possibilidade de sinal negativo, quantidade máxima de casas e tratamento de ausência. Inclua também de onde vem essa definição. A configuração do fornecedor ou do formulário costuma ser uma evidência mais forte que uma suposição produzida pelo modelo.
Por exemplo, o campo quantidade pode aceitar três casas, enquanto um valor exibido no catálogo usa duas. Aplicar a mesma máscara aos dois remove informação. Da mesma forma, a palavra “total” não basta para distinguir subtotal, total de itens e total apresentado ao cliente.
Preserve identificadores como texto. Um código de produto “00125” não deve virar o número 125 só porque contém dígitos. Essa decisão pertence ao esquema do documento. Para relacionar cada campo à origem, aproveite a organização descrita em registro de versões de documentos usados por IA.
2. Valide vírgulas, pontos e símbolos antes de converter
Comece pelo texto bruto, sem substituições destrutivas. Depois aplique apenas as transformações autorizadas pelo contrato: retirar espaços externos, separar um símbolo monetário reconhecido e interpretar os separadores na localidade definida. Guarde uma lista dessas transformações para explicar qualquer diferença posterior.
A documentação do Babel oferece parse_decimal com localidade explícita e opção estrita, além de formatação monetária. Esse recurso ajuda a detectar entradas irregulares. Ele não comprova que o valor veio do campo certo nem substitui a validação da unidade e da moeda.
| Entrada ilustrativa | Contexto necessário | Tratamento proposto |
|---|---|---|
| 1.234,50 | Campo declarado pt_BR | Interpretar conforme o contrato e conservar o original |
| 1,234.50 | Origem com outra convenção | Usar o perfil daquela origem, sem troca global |
| 1.234 | Localidade desconhecida | Pedir confirmação ou revisão |
| R$ 42,90 | Campo de valor em BRL | Separar símbolo e validar número |
| 42,90 kg | Campo de massa | Conservar unidade e rejeitar leitura monetária |
| vazio | Campo opcional | Registrar ausência, sem preencher zero |
Uma política útil é permitir uma interpretação automática apenas quando o perfil da origem estiver identificado. Se o documento mistura formatos, registre o conflito. Não transforme “1.234” em um valor definitivo com base apenas no fato de a empresa estar no Brasil.
Teste também espaços internos inesperados, sinais repetidos e caracteres visualmente parecidos. Um reconhecimento de imagem pode confundir uma letra com um algarismo. Qualquer correção desse tipo deve aparecer como sugestão pendente de confirmação, com o recorte ou trecho de origem disponível ao revisor.
3. Defina representação interna e arredondamento
A documentação oficial de ponto flutuante do Python explica que diversas frações decimais não têm representação binária exata. Portanto, diferenças pequenas podem aparecer em operações com float. Isso não demonstra erro da extração por IA; pode ser uma propriedade do tipo numérico escolhido depois dela.
Para campos que exigem aritmética decimal, considere um tipo decimal alimentado por texto normalizado. Não passe primeiro pelo tipo binário e espere recuperar a entrada original. Em Decimal, construir a partir de um float preserva o valor binário recebido; quantize permite ajustar o expoente com modo de arredondamento explícito.
Registre a política como dado de configuração: escala de entrada, precisão de cálculo, momento do arredondamento e escala de saída. Para um teste fictício, a equipe pode escolher duas casas e comparar o comportamento de empate para o par entre 2,345 e 2,355. O objetivo é tornar a regra observável, não recomendar uma política universal.
Não confunda precisão com casas decimais. Uma operação intermediária pode exigir mais informação que a tela final apresenta. Documente se o sistema calcula primeiro o agregado ou arredonda cada item antes da soma. Use exemplos aprovados pelo responsável pelo processo para impedir que uma mudança de biblioteca altere esse comportamento sem revisão.
Inclua verificações de finitude, limites de magnitude e quantidade de dígitos. O fato de uma biblioteca aceitar um valor não significa que ele pertença ao domínio do campo. Uma quantidade negativa ou um expoente enorme pode ser sintaticamente interpretável e, mesmo assim, precisar de rejeição.
4. Transporte dados sem perder moeda e significado
Uma proposta de estrutura interna é armazenar texto_original, valor_decimal, moeda, unidade, localidade, origem e status. O status distingue aceito, ausente, ambíguo e inválido. Assim, a interface não precisa deduzir uma falha a partir de um campo vazio.
Se a integração usa JSON, combine o formato com o consumidor. A RFC 8259 define ponto na parte fracionária da sintaxe numérica e reconhece limites de interoperabilidade relacionados à precisão. “1,50” entre aspas é uma string; sem aspas, não funciona como um único número JSON decimal.
Uma string decimal canônica pode fazer parte de um contrato, desde que o consumidor saiba validá-la e convertê-la. Outra arquitetura pode usar inteiros em uma unidade explicitamente definida. Em ambos os casos, mantenha a regra de escala junto do contrato. Não use um inteiro cujo significado dependa de uma convenção escondida.
Moeda precisa de campo próprio. O símbolo apresentado ao usuário não deve ser a única indicação disponível para integrações. Também não deduza BRL de qualquer ocorrência de cifrão. Quando a fonte não permite identificar a moeda, registre essa incerteza em vez de completá-la automaticamente.
Na saída, formate para a pessoa que vai ler, sem sobrescrever a representação de cálculo. Um teste de ida e volta deve confirmar que formatar e interpretar, dentro do mesmo contrato, preserva o valor esperado. Para a etapa de extração, veja também o pipeline de extração e validação de documentos em Python.
Exemplo: catálogo de uma papelaria em Campinas
Considere uma papelaria fictícia de Campinas que recebe listas de produtos em planilhas e imagens. A IA propõe nome, código, quantidade e valor unitário. Uma linha contém código “00125”, quantidade “2,500” e valor “R$ 12,40”. Todos os dados deste exemplo são inventados para demonstrar validação.
A equipe configura o perfil da planilha como pt_BR e define quantidade com até três casas. O código permanece texto. O valor monetário é separado do símbolo, convertido segundo o perfil e associado ao campo BRL. A quantidade não recebe a máscara de duas casas destinada à apresentação dos valores monetários.
Uma imagem de outra origem mostra “1.234”, sem contexto suficiente. O fluxo marca ambiguidade e mantém o trecho original. O revisor informa qual convenção a origem utiliza. Essa confirmação atualiza o perfil aprovado daquela entrada; não autoriza a IA a aplicar a mesma interpretação a todos os documentos futuros.
Antes de exportar o catálogo, o sistema confere que cada linha aceita tem campos obrigatórios preenchidos, unidade conhecida e conversão rastreável. Uma linha em revisão permanece separada da exportação. O usuário vê o motivo específico, como “localidade não identificada”, sem precisar interpretar uma mensagem genérica de erro.
Para homologação, a papelaria usa cópias sintéticas das linhas e resultados esperados escritos manualmente. Nenhum ganho de precisão ou economia é presumido. A aceitação depende de reproduzir os resultados do conjunto de testes e mostrar as ambiguidades ao responsável.
Inclua no relatório o identificador de cada caso, a saída proposta e o motivo de aprovação ou bloqueio. Dessa forma, uma alteração futura no perfil de importação pode ser comparada com a referência anterior. Mantenha casos de regressão para qualquer erro encontrado durante a homologação, especialmente quando uma correção aceita em um documento produz efeito diferente em outra origem.
Erros comuns
Trocar todos os pontos por vazio e todas as vírgulas por ponto. Essa receita pressupõe uma convenção única. A correção é identificar o perfil antes da conversão e recusar entradas fora dele. Preserve o original para investigar cada transformação.
Pedir que a IA “corrija qualquer valor estranho”. A instrução mistura leitura e alteração. Peça extração literal e uma sugestão separada quando houver dúvida. Só uma regra autorizada ou uma revisão deve mudar o valor usado pelo sistema.
Usar zero para ausência. Isso torna indistinguíveis uma informação não encontrada e um valor explicitamente igual a zero. Dê estados diferentes a esses casos e teste o comportamento da exportação para cada um.
Arredondar durante todas as etapas. Sem uma política documentada, a repetição pode modificar o resultado final. Defina pontos de arredondamento e compare a execução com exemplos de referência, inclusive valores exatamente próximos dos limites escolhidos.
Validar apenas o total. Dois erros em linhas diferentes podem se compensar. Confira campos individualmente e use relações entre campos como verificação adicional. Não aceite uma linha errada só porque o agregado parece coerente.
Testar somente entradas limpas. Monte casos com negativo, ausência, zero, separadores mistos, moeda desconhecida, texto junto do número e excesso de casas. Separe erro de leitura, erro de interpretação e erro de cálculo no relatório. Essa distinção indica qual etapa precisa de ajuste.
Perguntas frequentes
Um prompt resolve o problema da vírgula decimal?
O prompt pode pedir extração literal e campos separados. A aprovação precisa de validação posterior, com localidade, tipo e limites explícitos. Uma resposta bem formatada continua sujeita a ter sido extraída da coluna errada.
Devo guardar o símbolo R$ dentro do número?
Guarde o texto original completo, mas separe valor e moeda na estrutura usada para processamento. Essa organização permite formatar a apresentação sem misturar cálculo e identificação monetária.
Todos os campos devem ter duas casas?
Não. A escala depende do significado do campo e do contrato da aplicação. Quantidades, medidas e valores apresentados podem seguir regras diferentes. Defina exemplos esperados antes de implementar a conversão.
Como lidar com um número que aceita duas interpretações?
Registre ambiguidade, apresente a origem e solicite confirmação. Se houver um perfil previamente aprovado para aquela fonte, aplique-o e registre sua versão. Evite escolher por aparência ou pela preferência do modelo.
O que revisar quando trocar o modelo de IA?
Execute novamente os casos de extração e acompanhe alterações no texto bruto, nas unidades e na localização dos campos. Mantenha os validadores determinísticos e compare quantas entradas foram aceitas, rejeitadas ou enviadas à revisão, sem presumir melhoria.
