1. Transformar las expectativas del modelo en un contrato de datos
Empieza por el objeto que espera tu programa, antes de elegir un validador. Para una entrada tabular, nombra las columnas, los tipos y las unidades. Para una imagen, precisa las dimensiones, los canales y el tratamiento de las orientaciones. Para un texto, define la codificación, los campos obligatorios y la política sobre las entradas vacías. Un dato puede ser legible sin ser adecuado para el cálculo.
Separa tres decisiones: rechazar, aceptar tal cual o transformar según una regla documentada. Convertir una cadena en número, reemplazar un valor ausente y truncar una entrada cambian el contenido procesado. Estas operaciones no deben producirse simplemente porque una herramienta elija un tipo por defecto.
El ejemplo de esta guía es pedagógico y no se ejecuta. Trata sobre objetos que contienen un identificador y tres valores numéricos comprendidos entre −100 y 100. Estos límites son inventados para ilustrar un contrato, sin unidad física ni relación con un conjunto de datos de Kernodeck. Deben sustituirse por las reglas del proyecto real.
Desplaza la tabla para leer todas las columnas.| Nivel | Regla | Fallo detectable |
|---|---|---|
| Esquema | Exactamente id y values | Campo ausente o inesperado. |
| Tipo | id cadena; values lista de números | Número presentado como texto, booleano o valor ausente. |
| Forma | Tres valores por objeto | Vector demasiado corto o demasiado largo. |
| Valor | Números finitos en [−100, 100] | NaN, infinito o valor fuera del dominio pedagógico. |
| Corpus | Identificadores únicos | Dos objetos llevan el mismo identificador. |
2. Verificar la lectura antes de las conversiones
Fija el formato y su dialecto. Para un CSV, documenta el separador, la codificación y la presencia del encabezado. El lector CSV estándar de Python devuelve normalmente cadenas; no decide que tu columna sea un entero. Un identificador como 0012 puede perder su significado si una conversión lo transforma en 12. Conserva, por tanto, los identificadores en su tipo previsto.
Controla el número de campos y los nombres de las columnas antes de crear los objetos de negocio. Una línea desfasada por un separador inesperado no debe pasar solo porque algunos valores sigan siendo convertibles. Para los archivos binarios o las imágenes, haz también la lectura real: una extensión correcta no garantiza un contenido decodificable.
Un JSON decodificado todavía no es un contrato validado. El módulo Python acepta de forma predeterminada ciertos valores no finitos y nombres repetidos en un objeto. Si tu formato los prohíbe, configura ese rechazo al decodificar y luego aplica tus reglas de esquema. Define también un límite de tamaño adecuado antes de cargar un archivo completo en memoria.
3. Aislar un error por tipo de regla
Construye un conjunto pequeño donde cada entrada inválida viole solo una regla importante. Así sabrás qué detecta el control. Si el único ejemplo incorrecto acumula un identificador erróneo, una dimensión equivocada y un número infinito, su rechazo no demuestra que las tres reglas funcionen.
En la tabla, las notaciones representan objetos pedagógicos ya leídos. El infinito es un valor numérico no finito, no una sintaxis JSON que debas adoptar. Los veredictos son esperados por razonamiento y no son salidas de un programa ejecutado. Un segundo objeto con a se prueba después del objeto a válido para verificar la unicidad.
Conserva estos casos junto con tu contrato cuando este evolucione. Si decides aceptar cadenas numéricas, crea un paso de conversión explícito y deja constancia de esa decisión. No modifiques silenciosamente los controles para hacer desaparecer el primer rechazo del corpus.
Desplaza la tabla para leer todas las columnas.| Identificador y valores | Veredicto esperado | Regla ejercitada |
|---|---|---|
| a · [1, 2, 3] | Aceptado | Referencia válida. |
| b · ["4", 5, 6] | Rechazado: tipo | Una cadena no es un número en este contrato. |
| c · [7, 8] | Rechazado: forma | Dos valores en lugar de tres. |
| d · [0, infinito, 1] | Rechazado: valor | Un valor no finito no puede entrar en el cálculo. |
| a · [4, 5, 6], después del primer a | Rechazado: duplicado | Unicidad sobre el corpus. |
4. Mantener un validador explícito y mensajes aprovechables
El siguiente fragmento muestra los controles sobre un objeto, después de decodificar. Se detiene en la primera regla que falla y no procesa ni el archivo completo ni todos sus formatos posibles. El contenedor seen pertenece al recorrido del corpus: recrearlo en cada línea haría inútil el control de duplicados.
Un mensaje útil contiene la regla, el archivo lógico y la posición del objeto. Evita copiar en él todo su contenido. Para recopilar varios errores, limita los detalles conservados manteniendo contadores completos. Un informe de varios gigabytes tampoco ayuda a localizar la primera causa.
Sobre un arreglo NumPy, un control de finitud elemento por elemento puede complementar los controles de tipo y de forma. No reemplaza los límites de negocio: un número finito todavía puede ser una longitud negativa o un valor expresado en la unidad equivocada.
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. Pasar de la muestra al corpus completo
Una muestra corta permite corregir rápido el lector y el contrato. Elige casos ordinarios y fronteras: entrada vacía, tamaño máximo, carácter inusual, primera y última partición. Una selección solo de las primeras líneas puede pasar por alto una anomalía situada en un archivo posterior o en una categoría poco común.
La validación completa recorre todas las entradas afectadas y aplica las reglas globales. Para grandes volúmenes, procesa los archivos progresivamente y registra su identidad. Un conjunto de todos los identificadores en memoria sirve para el ejemplo pequeño, pero puede volverse demasiado costoso; elige entonces una estrategia de unicidad adaptada al volumen, sin renunciar al control.
El informe debe indicar su alcance: muestra de puesta a punto, totalidad de una partición o totalidad del corpus definido. Conserve el número leído, aceptado y rechazado, así como las reglas aplicadas. Si los archivos cambian después, el informe antiguo no valida automáticamente la nueva entrada.
6. Decidir qué hacer con los datos rechazados
Detenga el trabajo cuando los errores invaliden el sentido del cálculo: columna esencial ausente, unidades incompatibles o correspondencia de identificadores perdida. Si su tarea permite excluir elementos aislados, defina esa política antes del lanzamiento, conserve los rechazos y calcule los resultados sobre el alcance realmente aceptado.
Una puesta a un lado no es una corrección. Si reemplaza los valores faltantes o normaliza las entradas, produzca una nueva versión identificable y revalídela. Guarde la transformación y sus parámetros junto con el experimento. De lo contrario, dos intentos con el mismo nombre pueden usar datos diferentes.
Antes de la GPU, compruebe de nuevo el batch realmente construido: orden de las dimensiones, tipo numérico, máscara eventual y correspondencia con los objetivos. La validación del archivo precede a las transformaciones; no prueba que el pipeline conserve después esas propiedades. Un caso representativo permite verificar esta última frontera.
7. Producir una autorización de lanzamiento comprensible
La salida esperada es un informe breve que responda a cuatro preguntas: qué entrada, qué reglas, qué alcance y qué decisión. Un estado válido debe remitir a una identidad de corpus precisa. Un estado parcial debe nombrar lo que queda por controlar. Un rechazo debe permitir encontrar los objetos afectados sin difundir su contenido innecesariamente.
Añada un control del propio validador: un caso correcto pasa, cada caso incorrecto se rechaza por la razón correcta y los contadores cuadran. Después verifique un pequeño pasaje en la aplicación. Este doble control evita confundir la conformidad de los datos con la calidad del modelo o la disponibilidad de la GPU.
Las entradas conformes pueden seguir siendo sesgadas, estar mal etiquetadas o ser inadecuadas para la cuestión estudiada. Esta guía cubre la conformidad estructural y reglas explícitas; no certifica ni la representatividad ni los derechos de uso. Estas decisiones completan el expediente antes de un procesamiento largo.