MLOps: la diferencia entre un modelo en un notebook y uno en producción

La frase que más me repito es que un modelo que solo funciona en un notebook no es un modelo en producción, es un experimento. La distancia entre los dos no es técnica — es de ingeniería. Y esa ingeniería tiene nombre: MLOps.

El pipeline tiene que ser el mismo para entrenar y para servir. El error más común en producción: el preprocesado que se hace en el notebook (normalización, encoding de categorías, imputación de valores ausentes) se reimplementa a mano en la API de inferencia. Las dos versiones se desincronizarán. La solución es que el preprocesado viva dentro del pipeline de sklearn, de manera que el mismo objeto serializado que entrena es el que sirve. No hay dos versiones del mismo código.

Registro de versiones: saber qué está en producción. Cada modelo que se entrena debería registrarse con sus métricas de validación, los hiperparámetros usados y el identificador de los datos con los que se entrenó. Si mañana el modelo da resultados extraños, tiene que ser posible saber exactamente qué modelo está sirviendo y con qué datos se entrenó. Un registro de versiones no tiene que ser un sistema complejo: un directorio con archivos de metadatos JSON y un puntero a la versión activa es suficiente para empezar.

Monitorización de drift: el modelo se degrada aunque nadie lo toque. Los datos de producción cambian con el tiempo. Una campaña de marketing cambia el perfil de los clientes que llegan. Un cambio estacional afecta a las features. Una nueva regulación cambia el comportamiento de los usuarios. Si nadie está vigilando la distribución de los datos de entrada, el modelo puede estar dando predicciones muy malas durante semanas sin que nadie lo sepa. PSI (Population Stability Index) sobre las features clave, calculado contra el perfil de referencia del entrenamiento, detecta esto antes de que el negocio lo note.

La API de inferencia como contrato. La API que sirve el modelo tiene que validar la entrada con un esquema (Pydantic, por ejemplo), rechazar requests malformados antes de que lleguen al modelo, versionar la respuesta con el identificador del modelo que respondió y exponer métricas a un sistema de observabilidad. Sin eso, depurar un fallo en producción es adivinar a ciegas.

Cuándo montar infraestructura completa y cuándo no. Un primer MVP puede ser un script de entrenamiento que guarda el modelo en S3 y una API de FastAPI en una instancia pequeña. No necesitas Kubernetes, MLflow y Grafana desde el día uno. La infraestructura crecerá cuando el problema lo justifique: cuando el volumen de predicciones sea alto, cuando varios modelos corran en paralelo, cuando el reentrenamiento sea frecuente. Empieza simple y añade complejidad cuando el dolor sea real.