El pipeline ya corre solo (módulo 6); este módulo se encarga de que corra bien — porque el fallo más caro de un pipeline no es el que lo detiene, sino el que lo deja correr con basura adentro. Y en IA la factura se multiplica: la basura que en un dashboard es un número raro que alguien cuestiona, en un dataset de entrenamiento es un modelo peor que nadie sabe explicar, y en un corpus de RAG es una respuesta incorrecta con tono seguro. La calidad de datos es la eval de tu pipeline — el pariente exacto de lo que el curso de Evals hace con los modelos.

La tesis del módulo

La calidad se vigila en cuatro capas — esquema (¿tiene la forma?), reglas (¿cumple el negocio?), distribuciones (¿se parece a ayer?) y frescura (¿llegó a tiempo?) — con una decisión por chequeo: frenar el pipeline o avisar y seguir, según lo que cueste propagar el error. Y aguas arriba, el contrato de datos convierte la dependencia implícita de tus fuentes en un acuerdo con esquema, garantías y responsable — porque buena parte de los incidentes de calidad no nace en tu pipeline: nacen en un cambio que nadie te avisó.

Las cuatro capas de la vigilancia

Capa	Pregunta	Ejemplo del caso (correos)	Herramienta típica
Esquema	¿Columnas, tipos, nulos donde no van?	`id_correo` único y no nulo	dbt tests / contrato
Reglas de negocio	¿Los valores son posibles?	categoría ∈ las 4 válidas; fecha no futura	dbt tests / GX
Distribuciones	¿Se parece a lo histórico?	40% “facturación” hoy vs. 15% histórico	GX / monitoreo
Frescura y volumen	¿Llegó, y llegó completo?	~400 correos/día ±30% (los 12.000/mes del caso); partición de hoy existe	Orquestador / assets

Las dos primeras capas son determinísticas — verdadero o falso, baratas, van en cada build. Las dos últimas son estadísticas — comparan contra lo esperado, admiten umbral y criterio. La trampa clásica es quedarse en las determinísticas: el esquema perfecto no detecta que el 40% de las categorías de hoy son “facturación” cuando el histórico dice 15% — y esa anomalía es exactamente la que precede al “el modelo empeoró” (la deriva que MLOps monitorea aguas abajo, detectable aguas arriba, donde arreglar es más barato).

   LAS CUATRO CAPAS — Y QUÉ HACE CADA FALLO

  dato ──► ┌──────────────────┐
           │ 1. esquema       │ ──► falla: FRENA
           │    ¿tiene forma? │
           ├──────────────────┤
           │ 2. reglas        │ ──► falla: FRENA
           │    ¿es posible?  │
           ├──────────────────┤
           │ 3. distribución  │ ──► se corre: AVISA
           │    ¿como ayer?   │     (frena si es grave)
           ├──────────────────┤
           │ 4. frescura      │ ──► tarde: AVISA
           │    ¿llegó todo?  │     (a cero: FRENA)
           └────────┬─────────┘
                    │ pasa
                    ▼
           oro · dataset · índice RAG

Las herramientas en sus roles

Los tests de dbt (módulo 5) cubren las capas 1-2 sobre tus transformaciones: unicidad, no-nulos, valores aceptados, relaciones — declarativos, en cada build, frenando lo que falla. Son el mínimo vital y ya los tienes.

Great Expectations (GX) es el framework dedicado: un catálogo amplio de expectations (expectativas declarativas sobre los datos) que llega donde los tests de dbt no — distribuciones, rangos estadísticos, comparaciones entre lotes — y valida también fuera de dbt (el crudo recién ingerido, el dataset final antes de entrenar). El sabor de la API (esquemática, verificable contra su documentación):

import great_expectations as gx

context = gx.get_context()
batch = (          # el lote a validar: la partición de hoy
    context.data_sources
    .add_pandas("correos").add_dataframe_asset("hoy")
    .add_batch_definition_whole_dataframe("lote")
    .get_batch(batch_parameters={"dataframe": df_hoy})
)

# Capa 2: regla de negocio, determinística
resultado = batch.validate(
    gx.expectations.ExpectColumnValuesToBeInSet(
        column="categoria", value_set=["facturacion", "soporte",
                                       "ventas", "otro"])
)

# Capa 3: distribución — la que dbt no cubre
resultado_dist = batch.validate(
    gx.expectations.ExpectColumnProportionOfUniqueValuesToBeBetween(
        column="remitente", min_value=0.3, max_value=0.9)
)

El reparto sano: dbt tests para lo que dbt construye; GX para las fronteras — la entrada (validar el crudo apenas llega: el problema se atribuye a la fuente, no se descubre tres transformaciones después) y la salida crítica (el dataset de entrenamiento y el corpus RAG validados antes de servirse: la última aduana de los módulos 8-10).

Frenar o avisar: la decisión por chequeo

Cada chequeo declara su severidad, y la vara es una sola: ¿cuánto cuesta propagar este error a los consumidores?

Frenar (el chequeo falla → el pipeline se detiene y alerta): claves duplicadas, categorías inválidas, volumen a cero, PII donde no debe. Todo lo que corrompería el oro o entrenaría un modelo con basura. En el diagrama del módulo 6, la caja de calidad frena antes del dataset y del índice — esa posición es la decisión.
Avisar (registrar, alertar si persiste, seguir): la distribución levemente corrida, el volumen 20% bajo, los nulos subiendo en una columna secundaria. Señales de investigación, no de bloqueo — frenar el pipeline entero por ellas fabrica la fatiga de alertas que entrena a ignorar la que importaba.

La versión operativa del criterio de siempre: la alarma exige acción o es dashboard — aquí, el freno exige daño o es aviso.

El contrato de datos: la calidad aguas arriba

Todo lo anterior vigila tu territorio; buena parte de los incidentes nace en el ajeno: la fuente renombró un campo, cambió un enum, dejó de mandar los sábados. El contrato de datos (data contract) es el acuerdo explícito entre el equipo productor y el consumidor: esquema versionado (columnas, tipos, semántica), garantías (frescura, volumen esperado, unicidad de claves), canal y plazo de aviso de cambios, y responsables con nombre. Puede vivir en un YAML validable (el esquema del contrato es un chequeo de capa 1 en tu frontera de entrada) o empezar como un documento acordado — el valor está en que existe y tiene dueño:

# contrato: crm.clientes → pipeline de datos
version: 1.2
propietario: [email protected]
consumidores: [pipeline-datos, triaje-correos]
esquema:
  id_cliente: {tipo: string, unico: true, nulo: false}
  segmento:   {tipo: string, valores: [grande, mediano, chico]}
garantias:
  frescura_maxima: 24h
  volumen_diario: {min: 800, max: 1500}
cambios: aviso 10 dias habiles antes, canal #datos-contratos

La honestidad cultural: el contrato vale lo que el compromiso del productor. En organizaciones sin esa madurez, tu defensa es unilateral — validar la frontera de entrada contra el esquema esperado (GX en la ingesta) para que el cambio sorpresivo sea tu alerta en minutos y no el bug del modelo en tres semanas. El contrato formal llega cuando el incidente número tres le pone presupuesto.

Errores comunes

Calidad = “el pipeline no falló”. El fallo silencioso — corrió perfecto, procesó basura — es el caro. La calidad es una etapa con chequeos propios, no una ausencia de excepciones.
Solo capas determinísticas. Esquema impecable y distribución rota: el 40% de “facturación” pasa todos los not_null del mundo. Las capas estadísticas existen porque la deriva no viola tipos.
Todo frena (o nada frena). Cien frenos son un pipeline que nunca corre; cero frenos, basura en el oro. La severidad se decide chequeo a chequeo por el costo de propagar.
Validar solo al final. El error detectado en oro exige arqueología hacia atrás; el detectado en la frontera de entrada se atribuye solo. Las fronteras primero: entrada del crudo, salida de los datasets críticos.
Confiar en la fuente sin contrato ni frontera. “Siempre ha mandado esos campos” es la garantía que expira sin aviso. Contrato si hay cultura; validación de frontera unilateral siempre.
Datasets de IA sin aduana final. Entrenar o indexar directo desde plata “porque ya se validó antes” — la última milla (labels válidos, sin duplicados, sin PII) es exactamente donde el error cuesta un modelo. La aduana de salida no se delega.

La frase para llevarse

“Vigila en cuatro capas — forma, reglas, distribución, frescura —, decide por chequeo si frena o avisa según lo que cueste propagar, y no confíes en fronteras implícitas: contrato con la fuente cuando se pueda, validación unilateral de entrada siempre. El fallo que detiene el pipeline es barato; el que lo deja correr con basura te lo cobra el modelo.”

Qué viene

Módulo 8: etiquetado y datos de entrenamiento. Empieza el bloque IA del curso: cómo se fabrica el activo más caro del stack — los ejemplos etiquetados. Las fuentes de labels (el subproducto operativo, la anotación humana, el modelo como etiquetador), las guías de anotación y el acuerdo entre anotadores, active learning para etiquetar lo que más enseña, y el dataset de entrenamiento como mart con linaje — cerrando el círculo con ft-02: el dataset es el modelo, y ahora sabes construirlo.

Data Engineering — Módulo 7: calidad y contratos de datos