ADR-0008 — Seguimiento de experimentos y registro de modelos: MLflow¶

Contexto¶

La plataforma produce varios artefactos de ML (detección de anomalías, predicción) que requieren gobernanza. Cada entrenamiento genera hiperparámetros, métricas, artefactos (el modelo serializado, gráficas) y la versión exacta del código. Cada modelo entrenado se promociona por etapas hasta producción, por tipo de sensor. Y todo debe ser reproducible: dado un modelo concreto, hay que poder reconstruir el experimento que lo produjo.

Además, las decisiones sobre anomalías y predicción exigen explícitamente comparar variantes lado a lado, el servicio debe cargar los modelos de producción desde un registro central y conviene conservar la trazabilidad para saber qué modelo predijo qué en cada momento.

Las restricciones de fondo: autohospedable, open source, nativo en Python, con almacén persistente y registro de modelos con etapas, compatible con los distintos marcos de ML del proyecto y de coste prácticamente nulo.

Decisión¶

Se adopta MLflow autohospedado como plataforma única de seguimiento de experimentos, registro de modelos e integración con el servicio, cubriendo todo el ciclo de vida del ML. El almacén de metadatos se apoya en la base de datos relacional del proyecto y los artefactos se guardan en un almacén de objetos compatible con S3. Cada entrenamiento envuelve su lógica de forma que registra parámetros, métricas, el modelo y sus etiquetas. La promoción a producción es manual al principio y automática tras la evaluación cuando la detección de deriva está en marcha. El servicio carga el modelo en producción desde el registro y se entera de las nuevas promociones mediante notificaciones, sin necesidad de sondear.

Consecuencias¶

Positivas:

Centralización del ML: experimentos, modelos, linaje y artefactos en un único lugar consultable.
Demo reproducible sin conexión: la interfaz de MLflow queda accesible nada más levantar el sistema, sin cuentas en la nube. Es un punto clave para una pieza de portafolio.
Sin dependencia de proveedor: los datos viven en la infraestructura propia.
Estándar de la industria, con habilidad transferible.
El servicio se actualiza por notificación de promoción, sin acoplarse al entrenamiento.

Negativas o costes aceptados:

Interfaz menos pulida que las alternativas de pago; suficiente para uso interno y demostración.
La autenticación robusta requiere un proxy inverso por delante.
El autohospedaje implica responsabilidad operacional (copias de seguridad, actualizaciones, vigilancia del disco).
El servidor de seguimiento es un punto único de fallo mientras no se replica; asumible a esta escala.

Alternativas descartadas¶

Weights & Biases: probablemente la mejor interfaz del mercado y búsqueda de hiperparámetros integrada, pero es un servicio en la nube que ata los datos a sus servidores, con coste a escala. Choca con la filosofía de demo autohospedada y reproducible.
Neptune.ai: mismas objeciones de servicio en la nube, con menor adopción.
SageMaker Studio: dependencia total del proveedor de nube y coste operacional desde el primer día; imposible autohospedar.
DVC más Git: resuelve el versionado de datos y modelos, pero ofrece una experiencia pobre para el seguimiento de experimentos y carece de registro con etapas e interfaz. Resuelve un problema distinto; puede coexistir.
ClearML: técnicamente capaz y open source, pero con menor adopción y una instalación más pesada; MLflow cubre lo necesario con menos fricción y mayor reconocimiento.