MLOps en empresa: de prototipo a producción

¿Por qué fallan los proyectos de ML en producción?

Un estudio de Google sobre ML en producción halló que la mayoría del esfuerzo de un proyecto no está en el modelo, sino en la infraestructura que lo rodea. Los motivos más comunes de fallo en producción son:

• Data drift: la distribución de los datos en producción cambia y el modelo ya no es preciso
• Environment mismatch: el modelo funcionaba en el portátil del científico de datos pero no en producción
• Sin versionado: nadie sabe qué versión del modelo está en producción ni con qué datos fue entrenada
• Despliegue manual: cada actualización requiere intervención manual con riesgo de error
• Sin monitorización: el modelo se degrada durante semanas antes de que alguien lo note

¿Cuáles son las cinco dimensiones de MLOps?

1. 1Versionado de datos y modelos: saber exactamente con qué datos se entrenó cada versión del modelo
2. 2Registro de experimentos: comparar métricas entre experimentos para elegir el mejor modelo
3. 3CI/CD para ML: automatizar validación, testing y despliegue de nuevas versiones del modelo
4. 4Model serving: servir predicciones de forma eficiente y escalable (API REST, batch, streaming)
5. 5Monitorización en producción: detectar degradación del modelo antes de que impacte al negocio

Stack típico de MLOps en empresa mediana

¿Cómo empezar con MLOps desde cero?

1. 1Añade MLflow Tracking a tu proyecto actual: registra parámetros, métricas y artefactos de cada experimento
2. 2Versiona tus datasets con DVC o simplemente con convenciones de naming y Git
3. 3Crea un pipeline reproducible (script Python o notebook que no depende de estado local)
4. 4Dockeriza el modelo para eliminar 'funciona en mi máquina'
5. 5Añade tests automatizados: al menos una prueba de que el modelo predice correctamente en un conjunto de validación
6. 6Configura monitorización básica: log de predicciones y alerta si la distribución de entradas cambia

¿Cuándo necesitas MLOps formal (y cuándo no)?

¿Por qué el model monitoring es la pieza más ignorada?

El model drift es el fenómeno por el que un modelo que funcionaba bien empieza a perder precisión porque el mundo ha cambiado. Hay dos tipos: data drift (la distribución de los datos de entrada cambia) y concept drift (la relación entre inputs y outputs cambia). Sin monitorización, puede pasar semanas antes de que alguien lo note.

• Monitoriza la distribución estadística de las variables de entrada (PSI, KL divergence)
• Monitoriza las predicciones del modelo: si la distribución de outputs cambia, hay una señal
• Cuando tengas etiquetas reales, monitoriza métricas de negocio (precision, recall, AUC)
• Configura alertas cuando cualquier métrica supere un umbral definido

Preguntas frecuentes

¿Qué es el model decay y cómo detectarlo?

Un modelo que funcionaba bien en producción hace seis meses puede estar generando predicciones erróneas hoy sin que nadie en el equipo lo haya notado. Esta degradación silenciosa es el principal riesgo operativo en proyectos de ML a largo plazo. Hay dos mecanismos distintos que la causan, y confundirlos lleva a soluciones incorrectas.

Data drift: cuando cambian los datos de entrada

El data drift ocurre cuando la distribución estadística de las variables de entrada al modelo en producción diverge de la distribución con la que fue entrenado. El modelo no ha cambiado, pero el mundo que describe sí. Un ejemplo concreto: un modelo de predicción de churn en retail entrenado con historial de compras de 2019-2022 usaba la frecuencia de visita a tienda física como señal fuerte. Después de 2020, esa variable perdió toda su relevancia como predictor porque el comportamiento de compra cambió estructuralmente. El modelo seguía produciendo scores, pero su precisión había caído de forma severa.

Concept drift: cuando cambia la relación entre entrada y salida

El concept drift es más sutil: los datos de entrada tienen la misma distribución que antes, pero la relación entre esos datos y el resultado que queremos predecir ha cambiado. Un modelo de scoring de crédito entrenado antes de una recesión económica es el caso típico: las mismas características de un cliente (empleo estable, historial de pagos correcto) ya no predicen el mismo nivel de riesgo de impago cuando el contexto macroeconómico cambia. Reentrenar con los mismos features no resuelve el problema si el concepto subyacente ha cambiado.

Las métricas estándar para detectar degradación son el PSI (Population Stability Index), que mide cuánto ha cambiado la distribución de las variables de entrada entre el periodo de entrenamiento y el periodo actual; el KS-test (Kolmogorov-Smirnov), que compara distribuciones de una variable concreta; y el monitoring de accuracy en producción con etiquetas retrasadas, que es la métrica más directa pero requiere disponer de las etiquetas reales con cierto retardo temporal.

La herramienta Evidently (open source) permite calcular PSI, KS-test y otras métricas de drift de forma automática y generar informes HTML o JSON que se pueden integrar en cualquier pipeline de MLOps. WhyLabs y Fiddler son alternativas managed con mayor nivel de automatización y alertas integradas.

Herramientas de MLOps por nivel de madurez

No existe un stack de MLOps universal. La elección de herramientas debe estar calibrada al nivel de madurez del equipo, al número de modelos en producción y al presupuesto disponible. Adoptar una plataforma MLOps enterprise antes de tener los procesos básicos definidos es uno de los errores más frecuentes en equipos que empiezan.

La decisión más importante no es qué herramientas usar sino qué nivel es el adecuado ahora. Muchos equipos saltan al Nivel 3 antes de tener los procesos del Nivel 1 bien definidos. El resultado es infraestructura compleja que nadie mantiene bien y que no aporta más valor que un script documentado.