LogoIngeniería de Software Estadístico
Buscar

MLflow para la Gestión del Ciclo de Vida de Modelos Estadísticos

MLflow es un componente fundamental en la ingeniería de software estadístico.

1. Rol de MLflow en la Ingeniería de Software Estadístico

La gestión del ciclo de vida de los modelos es un punto crítico en proyectos estadísticos. MLflow proporciona cuatro componentes principales:

  • Tracking: registro de experimentos (parámetros, métricas, artefactos, entorno).

  • Models: formato estándar para empaquetar modelos con sus dependencias.

  • Model Registry: catálogo centralizado para versionar y promover modelos (staging, producción, archivado).

  • Projects: formato para empaquetar código reproducible (menos utilizado, pero relevante para pipelines completos).

La adopción de MLflow aporta trazabilidad, gobernanza y automatización, y actúa como un elemento de unión entre equipos que utilizan diferentes lenguajes (Python, R) y frameworks.

2. Componentes y su Integración en la Arquitectura

2.1 Tracking Server (seguimiento de experimentos)

El Tracking Server almacena los metadatos de cada ejecución: parámetros, métricas, artefactos (modelos, gráficos, logs) y el código fuente.

2.2 Model Registry (registro de modelos)

El Model Registry actúa como un catálogo central que permite gestionar el ciclo de vida de los modelos registrados. Soporta:

  • Versionado semántico de cada modelo.

  • Transición entre estados (por ejemplo, de staging a production) mediante alias, lo que permite una promoción flexible y con trazabilidad.

  • Almacenamiento asociado de la firma de entrada/salida (signature), el entorno de ejecución y las métricas de validación.

  • Registro de quién realizó cada promoción y cuándo.

Este componente es esencial para entornos con requisitos de auditoría, ya que proporciona un historial inmutable de las versiones que han pasado a producción.

2.3 MLflow Models (formato de empaquetado)

MLflow Models define un formato estándar para empaquetar un modelo junto con sus dependencias y su lógica de inferencia. Un modelo empaquetado puede:

  • Servirse mediante una API REST utilizando mlflow models serve.

  • Convertirse en un contenedor Docker autocontenido con mlflow models build-docker.

  • Desplegarse en plataformas como SageMaker, Azure ML o Kubernetes sin cambios en el código de inferencia.

Esta estandarización simplifica el paso de la experimentación a la producción y reduce la fricción entre equipos.

2.4 MLflow Projects (empaquetado de código)

Define un formato para empaquetar código de análisis reproducible, especificando sus dependencias y puntos de entrada. Aunque es el componente menos utilizado en proyectos grandes, es útil para definir pipelines completos de forma reproducible, especialmente cuando se combina con herramientas de orquestación.

3. Integración Técnica con Python y R

MLflow proporciona APIs nativas para Python y R, además de una API REST para cualquier otro lenguaje.

3.1 Ejemplo en Python (PyMC, scikit-learn)

python

3.2 Ejemplo en R (brms)

El paquete mlflow en R requiere que el paquete Python de MLflow esté instalado en el sistema (por ejemplo, dentro del contenedor). Las funciones son análogas.

r

3.3 Model Registry: Gobernanza y Promoción de Modelos

El flujo típico de gestión de versiones es el siguiente:

  • Una ejecución de entrenamiento registra un modelo en el Registry. Se crea una nueva versión (ej. versión 1).

  • Tras validar las métricas (por ejemplo, AUC > 0.88), se promueve la versión al alias staging.

  • En el entorno de pruebas (staging) se ejecutan pruebas de integración y de aceptación. Si superan, se promueve al alias production.

  • La versión anterior en producción se puede cambiar a archived para mantener la trazabilidad.

La promoción puede realizarse manualmente desde la interfaz web de MLflow o mediante scripts automatizados. Para garantizar la calidad, se pueden implementar gates automáticos:

python

3.4 Integración en Pipelines CI/CD (GitHub Actions + Docker)

La automatización es clave para la reproducibilidad. A continuación se describen los flujos típicos.

3.4.1 Entrenamiento y registro automático

Un workflow de CI (por ejemplo, al hacer push a la rama main o mediante una ejecución programada) ejecuta un script que:

Restaura el entorno (dependencias de Python o R).

Ejecuta el entrenamiento, logueando parámetros, métricas y artefactos en el Tracking Server.

Registra el modelo en el Model Registry.

La URI del Tracking Server se pasa como variable de entorno, no se incluye en el código.

3.5 Validación y promoción a staging

Tras el entrenamiento, un job independiente evalúa el modelo recién registrado. Si cumple los umbrales de calidad, se promueve automáticamente a staging. Esta promoción queda registrada en los logs del pipeline.

4. Despliegue a producción

La promoción a production puede ser manual (por ejemplo, desde la interfaz web de MLflow) o automática si el pipeline de staging tiene éxito. Una vez promocionado, otro pipeline (CD) puede:

Obtener la última versión con alias production.

Construir una imagen Docker del modelo usando mlflow models build-docker.

Etiquetar la imagen con el número de versión y subirla a un registro de contenedores (GitHub Container Registry, ECR).

Desplegar la imagen en el orquestador (Kubernetes, ECS).

Segmento conceptual de GitHub Actions

yaml

5. Integración con Versionado de Datos (DVC)

MLflow no está diseñado para versionar datasets grandes. Para ello se utiliza DVC (Data Version Control) o Git LFS. La combinación proporciona trazabilidad completa:

DVC versiona los datos y mantiene los metadatos en el repositorio Git.

En cada ejecución de MLflow, se registra como parámetro el hash del commit de DVC (o el tag del dataset) que se utilizó.

De esta forma, dado un modelo registrado en MLflow, se puede recuperar la versión exacta de los datos que lo generaron y reproducir el experimento.

Consideraciones para Entornos Profesionales Seguridad: El Tracking Server debe configurarse con autenticación (basic auth, OAuth mediante proxy inverso) y cifrado TLS. No debe exponerse directamente a internet sin estas medidas. Las credenciales se manejan mediante variables de entorno.

Escalabilidad: Para equipos grandes, el Tracking Server debe desplegarse con una base de datos gestionada (PostgreSQL) y un almacenamiento de artefactos escalable (S3, MinIO). El servidor MLflow puede ejecutarse en un orquestador con múltiples réplicas y balanceador de carga.

Retención y limpieza: Los artefactos de ejecuciones antiguas deben archivarse o eliminarse según políticas de retención. MLflow no incluye limpieza automática; debe implementarse un proceso externo (ej. un script que elimine ejecuciones anteriores a una fecha).

Auditoría: MLflow por sí mismo no es un sistema de auditoría inmutable (los registros pueden modificarse si se tiene acceso a la base de datos). Para proyectos altamente regulados, se debe complementar con logs firmados o con la captura de eventos de promoción mediante webhooks hacia un sistema de auditoría externo.

5.1 Relación con Otros Componentes del Sistema

Contratos de datos y trazabilidad de ingesta: MLflow añade la trazabilidad de modelos, cerrando el ciclo desde los datos hasta el artefacto desplegado.

APIs y despliegue: El formato estándar de MLflow Models permite generar contenedores listos para producción sin código adicional de inferencia.

CI/CD con GitHub Actions y Docker: MLflow proporciona los metadatos necesarios para decidir si una nueva versión debe ser promocionada y desplegada.

Checklist profesional: Se añaden verificaciones como "experiment tracking configurado", "model registry en uso" y "promoción automatizada con gates de calidad".

Pipeline Integrado: DVC + Contratos de Calidad + MLflow Esta sección muestra el ejemplo concreto de integración que cierra la trazabilidad completa desde los datos hasta el modelo en producción. Es el flujo de referencia para cualquier entrenamiento en el sistema.

5.2 El problema que resuelve

Sin esta integración, es imposible responder con certeza:

  • ¿Con qué versión exacta de los datos fue entrenado el modelo en producción?

  • ¿Pasaron esos datos el contrato de calidad antes del entrenamiento?

  • ¿Puedo reproducir exactamente ese entrenamiento?

Con la integración DVC + Great Expectations + MLflow, la respuesta es sí a las tres preguntas.

6. Flujo completo

text

7. Implementación

python

8. Recuperar el dataset exacto de un modelo en producción

python

9. Diferencia entre Data Contract y validación de calidad

  • Concepto Herramienta Qué verifica
  • Esquema y tipos Pydantic, JSONSchema Estructura del dato (columnas, tipos, nulidad)
  • Calidad de datos Great Expectations Distribuciones, rangos, unicidad, frescura
  • Contrato completo YAML + GE + Soda Ambos: esquema + calidad estadística
  • El contrato de datos es más amplio que la validación de esquema. La validación de esquema confirma que el dato tiene la forma correcta; la validación de calidad confirma que el contenido es estadísticamente plausible y cumple expectativas de negocio.

GitHub Actions: pipeline completo

yaml

Documentos relacionados