El día en que perdí el pickle bueno en el data lake de Microsoft Fabric

 Voy a empezar con un caso que lo más seguro a más de uno le suena.

Tiene un modelo entrenado. Funciona. Lo guarda como .pkl en el lago de datos con un nombre tipo modelo_v2_final_BUENO.pkl, y sigue con su vida.

Dos semanas después alguien pregunta: ¿con qué datos lo entrenó?, ¿qué hiperparámetros usó?, ¿esta es la versión que está en producción o la que estaba probando? Y ahí se da cuenta de que no tiene ni idea. El pickle está, sí, pero todo lo que lo rodea —los parámetros, las métricas, la fecha, el porqué de esa decisión— vive en su cabeza o, peor, en un notebook que ya editó tres veces.

Ese es exactamente el dolor que MLflow viene a resolver, y por eso le dedico esta serie de blog post.

Cuando monta un proyecto de machine learning en Fabric "a la antigua", el flujo es manual de principio a fin: crea un notebook, entrena, guarda el modelo en el lago, y cuando lo quiere reusar tiene que volver a leer el archivo y rezar para acordarse del contexto. Si quiere reentrenar y comparar contra lo anterior, le toca llevar el tracking a mano. Tablas, hojas de cálculo, nombres de archivo cada vez más absurdos. Es insostenible en cuanto el proyecto pasa de un par de modelos.

MLflow es un framework open source que le controla el ciclo de vida completo del modelo, y la mejor noticia para quien trabaja en Fabric es que ya viene instalado. No tiene que añadir nada ni configurar infraestructura. Está ahí, integrado con One Lake, con Entra ID, con los experimentos que aparecen en el propio portal de Fabric. Solo tiene que empezar a usarlo.

La idea de fondo es simple pero potente: en lugar de que cada entrenamiento sea un evento aislado que termina en un archivo huérfano, MLflow registra todo. Cada vez que ejecuta un entrenamiento se crea una run con su identificador, asociada a un experimento, y dentro de esa run quedan guardados el dataset, el algoritmo, los parámetros y las métricas. Trazabilidad completa, sin que usted lleve la contabilidad manualmente.

Y por encima de eso tiene dos cosas más que vamos a ir desgranando en los siguientes posts: el Model Registry (un registro de modelos versionados) y el monitoreo. Cuando un modelo está listo, lo registra, lo promueve, lo despliega como REST endpoint o como función de Spark, y lo consume desde donde quiera: Power BI, una API, un batch scoring.

Antes de cerrar, recordemos que en Fabric lo normal es trabajar con la típica medallion architecture: bronce (datos brutos), plata (datos limpios), oro (datos curados). El machine learning casi siempre vive de plata hacia arriba: lee de plata, donde los datos ya vienen limpios, y de ahí construye sus modelos. Dónde exactamente se integra el ML depende de su negocio, pero la regla práctica es que no entrene sobre datos 100% crudos.

En el siguiente post entro en el corazón del asunto: experimentos, runs y cómo MLflow le ordena el caos del entrenamiento.