MLOps Pipeline Design: de notebooks a producción continua

El notebook no es un pipeline

El 87% de los modelos de ML nunca llegan a producción. La razón principal no es la calidad del modelo, sino la ausencia de una ingeniería de pipelines que permita entrenamiento reproducible, deployment automatizado y rollback seguro. Un pipeline de MLOps separa concerns: ingesta de datos, feature engineering, training, evaluation, registry, deployment y monitoring operan como stages independientes con contratos bien definidos.

Training pipeline vs Serving pipeline

Un error frecuente es mezclar training y serving en el mismo pipeline. El training pipeline es batch, tolerante a latencia, optimizado para throughput. El serving pipeline es online, sensible a latencia, optimizado para p99. La separación permite escalar, versionar y monitorear cada uno independientemente. El punto de conexión es el Model Registry: el training pipeline escribe artefactos versionados, el serving pipeline lee el artefacto promovido a producción.

Estrategia de release controlado

Un cambio directo en un sistema de decisión es un riesgo. La versión nueva debe compararse contra criterios de negocio, evidencia, límites de autonomía y señales de impacto antes de ampliar su uso. Si el criterio de assurance se rompe, la decisión correcta es bloquear, revertir o escalar a revisión.

Release para decisiones: más allá del código

La disciplina de release no valida solo software: valida evidencia, consistencia de señales, regresiones contra decisiones conocidas, límites operacionales, trazabilidad y capacidad de reversión. La pila exacta cambia por cliente; la promesa pública es que ninguna decisión crítica avanza sin criterios verificables.