Para testar se uma extração por IA preserva zeros à esquerda, trate cada código como texto e compare a sequência extraída com a sequência do documento. A verificação deve continuar até o destino final: um identificador correto na resposta pode perder zeros durante a conversão para JSON, a importação de CSV ou a gravação no sistema.
Crie casos com códigos parecidos, comprimentos distintos e campos ausentes. Valide o tipo recebido, a igualdade textual e o vínculo com o registro de origem. Não complete zeros automaticamente para esconder uma divergência: sem uma regra comprovada de tamanho, esse preenchimento pode fabricar outro identificador.
Resumo rápido
- Código identifica; número pode representar uma quantidade calculável.
- Declare campos de identificação como texto em cada etapa.
- Compare valores literalmente e verifique também o tipo.
- Teste resposta da IA, exportação, importação e consulta final.
- Separe campo ausente, ilegível e código realmente composto por zeros.
Por que o teste começa pela definição do campo
O valor “000417” pode ser um código interno de produto. Nesse caso, “417” não é uma representação equivalente aceita apenas porque as duas formas têm o mesmo valor numérico. A identidade depende do contrato do cadastro. Já uma quantidade de 417 unidades pode ser armazenada como número, conforme as regras do sistema.
Documente para cada campo: nome, finalidade, caracteres permitidos, tamanho quando conhecido e tratamento de ausência. Não presuma que todo identificador tem tamanho fixo. Uma empresa pode aceitar “0417” e “00417” como códigos distintos. Retirar zeros e depois completar até um tamanho padrão destruiria essa diferença.
O RFC 8259, que define JSON, distingue strings de números e não permite zeros iniciais na sintaxe de números como 00417. Para carregar essa sequência em JSON, use uma string como "00417". Isso resolve a representação do formato; ainda é necessário impedir conversões posteriores.
A recomendação prática é descrever o campo pela função, não pela aparência. “Código do item como aparece na coluna Código” é mais preciso do que “número do item”. O segundo nome pode sugerir uma transformação desnecessária. Preserve também a referência ao documento e à linha para investigar qualquer divergência.
Monte uma matriz com códigos que exponham a perda
Uma amostra só com códigos iniciados por dígitos diferentes de zero não detecta esse problema. Inclua zeros iniciais simples e repetidos, códigos longos, valores compostos só por zeros e identificadores com letras. Use dados sintéticos que não representem pessoas ou operações reais.
| Entrada ilustrativa | Saída esperada | O que o caso testa | Resultado que deve falhar |
|---|---|---|---|
| 000417 | String “000417” | Preservação de três zeros iniciais. | Número 417 ou string “417”. |
| 0417 e 00417 | Duas strings distintas. | Ausência de colisão entre códigos. | Um único identificador 417. |
| 000000 | String “000000”, se válida no contrato. | Diferença entre zero e ausência. | Campo vazio ou nulo. |
| A0017 | String “A0017” | Preservação de prefixo e zeros. | String “A17”. |
| Célula ausente | Estado ausente previsto no contrato. | Não inventar um código. | Preenchimento “000000”. |
| 0O017 | Revisão, quando a imagem não permite distinguir. | Ambiguidade entre letra e dígito. | Correção silenciosa para “00017”. |
Adicione documentos com duas colunas próximas: código e quantidade. Assim você verifica se a extração associa cada valor ao campo correto. Um teste de igualdade isolado pode aprovar “000417” no campo errado, enquanto o código do item fica vazio. A avaliação precisa acompanhar a estrutura do registro.
Crie também pares de arquivos que mudam somente um zero. O sistema deve produzir identificadores diferentes quando a origem muda e conservar o mesmo identificador quando muda apenas o layout. Teste texto selecionável e imagem separadamente, pois a etapa de reconhecimento de caracteres introduz outro ponto de falha.
Para arquivos de demonstração, marque claramente que os dados são fictícios. O roteiro de documentos sintéticos em ambientes de demonstração ajuda a organizar essa separação. O conjunto de avaliação deve manter o original intacto para permitir conferência visual posterior.
Declare tipos e regras sem confundir formato com fidelidade
Defina um esquema de saída em que o código seja uma string. Se o cadastro exigir exatamente seis dígitos, uma regra pode combinar tipo textual com o padrão ^[0-9]{6}$. Esse padrão é apenas ilustrativo: aplique-o somente quando o contrato real do campo confirmar o tamanho e o alfabeto.
A documentação de strings do JSON Schema descreve restrições por tamanho e expressão regular. Elas ajudam a rejeitar um tipo errado ou formato incompatível. Entretanto, “000418” satisfaz o mesmo padrão de “000417”. Por isso, aprovação no esquema não demonstra igualdade com o documento.
Mantenha verificações separadas: tipo, formato, fidelidade e associação. A primeira exige texto; a segunda aplica as regras conhecidas; a terceira compara o conteúdo; a quarta confirma que o código pertence à linha certa. Não reúna tudo em uma mensagem genérica de “JSON válido”, que dificulta localizar a causa.
Campos ausentes também precisam de um contrato. Uma opção é devolver um estado explícito e deixar o código nulo apenas quando não foi encontrado. Outra é manter uma lista de pendências fora dos registros extraídos. Escolha uma abordagem consistente e teste para que o código “000000” não seja confundido com falta de informação.
Se houver uma etapa de normalização, preserve o valor bruto e registre a transformação. Remover espaços externos pode ser permitido para um campo e indevido para outro. A discussão sobre normalização Unicode reforça a necessidade de distinguir equivalência visual, transformação textual e identidade do dado. Não aplique limpeza universal a identificadores.
Verifique cada fronteira até a leitura no destino
Execute a avaliação com pontos de captura: arquivo original, saída bruta da extração, objeto interpretado, arquivo exportado e valor lido do sistema de destino. Cada ponto deve carregar um identificador de caso. Quando houver uma falha, a comparação entre etapas mostra onde a sequência foi alterada.
Se a resposta já traz “417”, investigue extração e instruções. Se ela traz “000417”, mas o objeto interpretado contém um número, procure a conversão no código de integração. Se o arquivo mantém os zeros e a tela perde, confira importação, tipo da coluna e leitura posterior. Não atribua automaticamente todas essas falhas ao modelo.
Em CSV, teste a ferramenta que realmente vai consumir o arquivo. A documentação do módulo csv do Python informa que o leitor retorna strings por padrão, com exceções associadas a opções específicas. Esse comportamento não deve ser generalizado para todo importador ou planilha. Aspas no arquivo não garantem, sozinhas, que o consumidor preserve o tipo.
O modelo de dados tabulares do W3C distingue a representação textual da célula do seu valor interpretado. Essa separação ajuda a desenhar a inspeção: registre o texto presente no arquivo e o valor que a próxima etapa construiu. Eles podem divergir mesmo sem alteração visível no arquivo exportado.
Faça uma rodada completa de ida e volta: extraia, grave, consulte e exporte novamente. Compare os códigos recuperados com o gabarito, sem converter nenhum dos lados para inteiro. Testar apenas a aparência da tela não basta; uma máscara pode exibir zeros que não existem no valor armazenado.
Relate falhas por etapa e por classe de entrada. Registre quantos casos foram avaliados em cada grupo, sem misturar campos ausentes com códigos válidos. Se uma etapa não puder ser observada, declare essa lacuna. Aprovação parcial não comprova preservação até o destino.
Exemplo: loja de peças em Joinville importando pedidos
Considere uma loja fictícia de peças industriais em Joinville. Os fornecedores enviam pedidos em documentos com códigos internos diferentes dos usados pela loja. O assistente extrai o código do fornecedor, a descrição e a quantidade, e uma integração prepara o arquivo de importação para conferência humana.
A equipe cria um pedido sintético com os códigos “000417” e “0417”, tratados como itens distintos nesse exemplo. As descrições são parecidas para impedir que uma comparação superficial por texto esconda a troca. A quantidade aparece como número, enquanto o código permanece textual.
Na execução, a saída da extração contém os dois códigos corretos. O arquivo intermediário também os mantém. A importação de teste transforma ambos em 417. O relatório registra uma colisão introduzida nessa fronteira e bloqueia o lote antes de qualquer atualização no cadastro real. A correção deve ocorrer na configuração ou implementação da importação.
Depois do ajuste, a equipe consulta os dois registros no ambiente de teste e exporta os valores novamente. O gabarito exige a distinção entre as sequências e o vínculo com as linhas originais. Não basta acrescentar zeros à exibição, pois isso poderia mostrar “000417” para ambos os itens.
Esse cenário é ilustrativo e não demonstra resultados comerciais. Ele mostra por que a aceitação precisa incluir a integração inteira. Para registrar qual documento sustentou cada comparação, use também o procedimento de versionamento de documentos citados, guardando somente os dados necessários à auditoria.
Erros comuns
Comparar depois de converter para inteiro. Essa verificação transforma “000417” e “417” no mesmo valor e elimina justamente o defeito que deveria detectar. Compare strings e recuse tipos inesperados antes da igualdade.
Completar zeros por um tamanho presumido. Isso pode gerar um código inexistente ou fundir identificadores distintos. A correção só é defensável quando existe uma regra externa comprovada, e mesmo assim deve ficar registrada como transformação.
Confiar apenas no esquema. Formato correto não significa transcrição correta. Um dígito trocado pode passar em todas as regras de comprimento. Mantenha uma comparação com a origem e verificações de associação entre colunas.
Testar somente a resposta da IA. A perda pode acontecer depois, em uma planilha ou banco. Inclua a leitura do destino no critério de aprovação e preserve evidência intermediária suficiente para localizar a primeira divergência.
Tratar ilegível como vazio. Uma imagem ruim exige revisão, enquanto uma célula vazia pode representar ausência legítima. Dê estados diferentes a essas situações e evite que o fluxo avance com um código inventado.
Perguntas frequentes
Todo campo com dígitos deve ser texto?
Não. Quantidades e medidas podem exigir tipos numéricos. Identificadores devem seguir o contrato do cadastro. A decisão depende da função do campo e das operações permitidas, incluindo a necessidade de preservar a sequência original.
Colocar o código entre aspas no JSON resolve?
Resolve a representação textual naquele ponto. Uma etapa posterior ainda pode convertê-lo para número. O teste deve confirmar o tipo após a interpretação e repetir a comparação depois da gravação e da consulta no destino.
Posso corrigir o valor com preenchimento automático?
Somente quando uma regra comprovada autoriza a transformação e permite identificar o valor correto sem dúvida. Para avaliação de fidelidade, registre primeiro a divergência original. Uma correção não deve apagar a evidência da falha.
Como testar códigos em imagens?
Inclua imagens legíveis e casos com dificuldade controlada, mantendo o gabarito revisado por uma pessoa. Separe perda de zeros de confusão entre caracteres. Quando o original não permite decidir, o comportamento esperado deve ser revisão.
Qual é o critério para liberar a integração?
Defina previamente quais campos são críticos e quais divergências bloqueiam o lote. Para identificadores usados para localizar ou alterar registros, exija conferência em todas as fronteiras observáveis e encaminhe casos indefinidos para revisão antes da escrita.
