1. Transformar as expectativas do modelo em contrato de dados
Comece pelo objeto que o seu programa espera, antes de escolher um validador. Para uma entrada tabular, nomeie as colunas, os tipos e as unidades. Para uma imagem, especifique dimensões, canais e tratamento das orientações. Para um texto, defina a codificação, os campos obrigatórios e a política sobre entradas vazias. Um dado pode ser legível sem ser adequado ao cálculo.
Separe três decisões: recusar, aceitar como está ou transformar segundo uma regra documentada. Converter uma string em número, substituir um valor ausente e truncar uma entrada alteram o conteúdo processado. Essas operações não devem acontecer simplesmente porque uma ferramenta escolhe um tipo padrão.
O exemplo deste guia é pedagógico e não é executado. Ele trata de objetos contendo um identificador e três valores numéricos compreendidos entre −100 e 100. Esses limites são inventados para ilustrar um contrato, sem unidade física nem vínculo com um conjunto de dados Kernodeck. Eles devem ser substituídos pelas regras do projeto real.
Role a tabela para ler todas as colunas.| Nível | Regra | Falha identificável |
|---|---|---|
| Esquema | Exatamente id e values | Campo ausente ou inesperado. |
| Tipo | id string; values lista de números | Número apresentado como texto, booleano ou valor ausente. |
| Forma | Três valores por objeto | Vetor curto ou longo demais. |
| Valor | Números finitos em [−100, 100] | NaN, infinito ou valor fora do domínio pedagógico. |
| Corpus | Identificadores únicos | Dois objetos têm o mesmo identificador. |
2. Verificar a leitura antes das conversões
Fixe o formato e o seu dialeto. Para um CSV, documente separador, codificação e presença do cabeçalho. O leitor CSV padrão do Python normalmente retorna strings; ele não decide que a sua coluna é um inteiro. Um identificador como 0012 pode perder o sentido se uma conversão o transformar em 12. Portanto, conserve os identificadores no tipo previsto.
Controle o número de campos e os nomes das colunas antes de criar os objetos de negócio. Uma linha deslocada por um separador inesperado não deve passar só porque certos valores continuam conversíveis. Para os arquivos binários ou as imagens, faça também a leitura real: uma extensão correta não garante um conteúdo decodificável.
Um JSON decodificado ainda não é um contrato validado. O módulo Python aceita por padrão certos valores não finitos e nomes repetidos em um objeto. Se o seu formato os proíbe, configure essa rejeição na decodificação e depois aplique suas regras de esquema. Defina também um limite de tamanho adequado antes de carregar um arquivo completo na memória.
3. Isolar um erro por tipo de regra
Construa um pequeno conjunto em que cada entrada inválida viole apenas uma regra importante. Assim você saberá o que a verificação detecta. Se o único exemplo incorreto acumular um identificador inválido, uma dimensão errada e um número infinito, sua rejeição não demonstra que as três regras funcionam.
Na tabela, as notações representam objetos didáticos já lidos. O infinito é um valor numérico não finito, não uma sintaxe JSON a ser adotada. Os veredictos são esperados por raciocínio e não são saídas de um programa executado. Um segundo objeto com a é testado após o objeto a válido para verificar a unicidade.
Mantenha esses casos junto ao seu contrato quando ele evoluir. Se você decidir aceitar strings numéricas, crie uma etapa de conversão explícita e registre essa decisão. Não modifique silenciosamente as verificações para fazer desaparecer a primeira rejeição do corpus.
Role a tabela para ler todas as colunas.| Identificador e valores | Veredicto esperado | Regra exercitada |
|---|---|---|
| a · [1, 2, 3] | Aceito | Referência válida. |
| b · ["4", 5, 6] | Recusado: tipo | Uma string não é um número neste contrato. |
| c · [7, 8] | Recusado: forma | Dois valores em vez de três. |
| d · [0, infinito, 1] | Recusado: valor | Um valor não finito não pode entrar no cálculo. |
| a · [4, 5, 6], após o primeiro a | Recusado: duplicata | Unicidade no corpus. |
4. Manter um validador explícito e mensagens aproveitáveis
O trecho a seguir mostra as verificações sobre um objeto, após a decodificação. Ele para na primeira regra com falha e não trata o arquivo completo nem todos os seus formatos possíveis. O contêiner seen pertence à varredura do corpus: recriá-lo a cada linha tornaria inútil a verificação de duplicatas.
Uma mensagem útil contém a regra, o arquivo lógico e a posição do objeto. Evite copiar todo o seu conteúdo nela. Para uma coleta de vários erros, limite os detalhes mantidos, mantendo os contadores completos. Um relatório de vários gigabytes também não ajuda a localizar a primeira causa.
Em um array NumPy, uma verificação de finitude elemento por elemento pode complementar as verificações de tipo e de forma. Ela não substitui os limites de negócio: um número finito ainda pode ser um comprimento negativo ou um valor expresso na unidade errada.
import math
def valider_objet(item, seen):
if type(item) is not dict or set(item) != {"id", "values"}:
raise ValueError("SCHEMA")
identifiant = item["id"]
if type(identifiant) is not str or not identifiant.strip():
raise ValueError("IDENTIFIANT")
if identifiant in seen:
raise ValueError("DOUBLON")
values = item["values"]
if type(values) is not list or len(values) != 3:
raise ValueError("FORME")
for value in values:
if type(value) not in (int, float):
raise ValueError("TYPE")
if not (-100 <= value <= 100) or not math.isfinite(value):
raise ValueError("VALEUR")
seen.add(identifiant)
return item5. Passar da amostra ao corpus completo
Uma amostra curta permite corrigir rapidamente o leitor e o contrato. Escolha casos comuns e fronteiras: entrada vazia, tamanho máximo, caractere incomum, primeira e última partição. Uma seleção apenas das primeiras linhas pode deixar passar uma anomalia situada em um arquivo mais adiante ou em uma categoria rara.
A validação completa percorre todas as entradas em questão e aplica as regras globais. Para grandes volumes, processe os arquivos progressivamente e registre sua identidade. Um conjunto de todos os identificadores na memória serve para o pequeno exemplo, mas pode se tornar caro demais; escolha então uma estratégia de unicidade adequada ao volume, sem abrir mão da verificação.
O relatório deve indicar seu escopo: amostra de ajuste, totalidade de uma partição ou totalidade do corpus definido. Mantenha o número lido, aceito e recusado, assim como as regras aplicadas. Se os arquivos mudarem depois, o relatório antigo não valida automaticamente a nova entrada.
6. Decidir o que fazer com os dados recusados
Interrompa o trabalho quando os erros invalidarem o sentido do cálculo: coluna essencial ausente, unidades incompatíveis ou correspondência dos identificadores perdida. Se sua tarefa autoriza a exclusão de elementos isolados, defina essa política antes do lançamento, mantenha as recusas e calcule os resultados sobre o escopo realmente aceito.
Uma exclusão não é uma correção. Se você substituir os valores ausentes ou normalizar as entradas, produza uma nova versão identificável e revalide-a. Mantenha a transformação e seus parâmetros junto com o experimento. Caso contrário, dois ensaios com o mesmo nome podem usar dados diferentes.
Antes da GPU, controle ainda o batch realmente construído: ordem das dimensões, tipo numérico, máscara eventual e correspondência com os alvos. A validação do arquivo precede as transformações; ela não prova que o pipeline conserve depois essas propriedades. Um caso representativo permite verificar essa última fronteira.
7. Produzir uma autorização de lançamento compreensível
A saída esperada é um relatório curto que responde a quatro perguntas: qual entrada, quais regras, qual escopo e qual decisão. Um status válido deve remeter a uma identidade de corpus precisa. Um status parcial deve nomear o que resta a controlar. Uma rejeição deve permitir encontrar os objetos afetados sem divulgar seu conteúdo desnecessariamente.
Adicione um controle do próprio validador: um caso correto passa, cada caso incorreto é recusado pelo motivo certo, e os contadores se reconciliam. Em seguida, verifique uma pequena passagem na aplicação. Esse duplo controle evita confundir a conformidade dos dados com a qualidade do modelo ou a disponibilidade da GPU.
Entradas conformes podem permanecer enviesadas, mal rotuladas ou inadequadas à questão estudada. Este guia cobre a conformidade estrutural e regras explícitas; ele não certifica nem a representatividade nem os direitos de uso. Essas decisões complementam o dossiê antes de um processamento longo.