📈 MLflow – Lifecycle, Tracking, Registry & MLOps

L'architecture de MLflow Tracking (le cœur) sépare les Métadonnées (Backend) des Fichiers (Artifacts).

(Data Scientist 1)
 (mlflow.log_param(...))
       │
       │ (API REST)
       ▼
[ MLFLOW TRACKING SERVER (Serveur) ]
 (ex: mlflow server --host 0.0.0.0)
       │
       │
 (Écrit Métadonnées : Param/Metrics)
       │
       ▼
[ 1. BACKEND STORE ]
 (ex: BDD (Postgres, MySQL)
  ou 'file:/path/mlruns')
       │
       │
 (Écrit Fichiers : Modèles/Images)
       │
       ▼
[ 2. ARTIFACT STORE ]
 (ex: S3, ADLS, GCS, HDFS
  ou '/path/mlartifacts')

• Tracking Server : Le serveur (service) qui expose l'API REST et l'UI Web.
• Backend Store : (La "BDD") Stocke les Métadonnées (Params, Metrics, Tags, Runs). (Peut être file: (local) ou postgresql://... (Prod)).
• Artifact Store : (Le "Disque Dur") Stocke les Artefacts (gros fichiers) (ex: le model.pkl, graph.png). (Peut être file: (local) ou s3://... (Prod)).

MLflow Tracking organise le travail (similaire à un "commit Git").

Exemple de "logging" (enregistrement) manuel d'un Run (exécution) depuis un script Python.

import mlflow

# 1. (Optionnel) Définir le serveur de suivi
# (Si omis, logge localement dans ./mlruns)
mlflow.set_tracking_uri("http://mon-serveur-mlflow:5000")

# 2. Définir l'Expérience (Projet)
mlflow.set_experiment("Prediction_Ventes_Decembre")

# 3. Démarrer un nouveau Run (Exécution)
# (Utiliser 'with' est la bonne pratique)
with mlflow.start_run(run_name="Run_RandomForest_v1") as run:

    # (Logguer le 'run_id')
    print(f"Run ID: {run.info.run_id}")

    # 4. Logger les Inputs (Hyperparamètres)
    learning_rate = 0.01
    n_estimators = 100
    mlflow.log_param("learning_rate", learning_rate)
    mlflow.log_param("n_estimators", n_estimators)

    # (... (Code d'entraînement du modèle) ...)
    # model = ...

    # 5. Logger les Outputs (Métriques/Scores)
    accuracy = 0.92
    loss = 0.15
    mlflow.log_metric("accuracy", accuracy)
    mlflow.log_metric("loss", loss)

    # (Logger une métrique sur la durée (ex: epochs))
    for epoch in range(10):
        mlflow.log_metric("epoch_loss", loss_par_epoch, step=epoch)

    # 6. Logger les Fichiers (Artefacts)
    # (Sauvegarder un fichier texte)
    mlflow.log_text("feature_list.txt", "feature1, feature2")
    
    # (Sauvegarder une image (ex: matplotlib))
    mlflow.log_figure(fig, "confusion_matrix.png")
    
    # (Sauvegarder le Modèle (voir 5.3))
    mlflow.sklearn.log_model(model, "model_sklearn")
    
# (Le Run est 'Terminé' (FINISHED) à la fin du 'with')

Le "logging" manuel (2.2) (log_param, log_metric) est verbeux.

Autologging (mlflow.autolog()) est une fonctionnalité "magique" qui s'accroche (hooks) aux librairies ML populaires (Scikit-learn, TensorFlow, PyTorch...) et enregistre automatiquement tout (Params, Metrics, Modèle).

import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import accuracy_score

# (Données X_train, y_train...)

# 1. Activer l'Autolog (AVANT 'fit')
mlflow.sklearn.autolog()

with mlflow.start_run() as run:
    # 2. Définir le modèle
    rf = RandomForestClassifier(
        n_estimators=100,
        max_depth=5
    )
    
    # 3. Entraîner
    rf.fit(X_train, y_train) # <--- Magie ici
    
    # 4. Prédire
    preds = rf.predict(X_test)
    accuracy = accuracy_score(y_test, preds)
    
    # 5. (Logguer la métrique finale)
    mlflow.log_metric("accuracy", accuracy)

# --- RÉSULTAT (Automatique) ---
# MLflow a AUTOMATIQUEMENT loggué :
#  Params: { n_estimators: 100, max_depth: 5, ... }
#  Metrics: { training_accuracy: 0.95, ... }
#  Artifacts: { model: (le model.pkl), ... }

mlflow ui est l'interface web (locale) pour visualiser les résultats (Runs) loggés par MLflow Tracking.

Usage (Mode Local)

Si vous avez loggé localement (Mode 1 - ./mlruns), vous pouvez lancer l'UI :

# (Lance l'UI Web sur http://127.0.0.1:5000)
$ mlflow ui
# (ou, si le backend/artifact est distant)
$ mlflow ui --backend-store-uri ... --default-artifact-root ...

Fonctionnalités (UI)

• Vue (Experiment) : Liste tous les "Runs" (lignes) avec les "Params" et "Metrics" (colonnes).
• Tri & Filtre : "Trier par accuracy (DESC)", "Filtrer n_estimators = 100".
• Comparaison (Compare) : (Le plus puissant) Sélectionner 2 (ou N) "Runs" pour les comparer (visualiser les différences de Params/Metrics, Graphes...).
• Vue (Run) : Voir les détails (Artefacts (model.pkl), Tags...).

Il y a deux façons de gérer un "Run" (Exécution) :

# (Approche "Legacy" / Manuelle)
try:
    mlflow.start_run()
    
    mlflow.log_param("p1", 1)
    
    # (Si le code crashe ici...)
    if (error):
        raise Exception("Oups")
        
    mlflow.log_metric("m1", 0.9)
    
    mlflow.end_run(status="FINISHED")
    
except Exception as e:
    # (Le run reste 'RUNNING' (Actif)
    #  si on ne le ferme pas manuellement)
    mlflow.end_run(status="FAILED")

# (Le 'with' gère le try/except/finally)
try:
    with mlflow.start_run(run_name="Mon Run") as run:
        
        mlflow.log_param("p1", 1)
        
        if (error):
            raise Exception("Oups") # (Déclenche une exception)
            
        mlflow.log_metric("m1", 0.9)
        
        # (Si le 'with' se termine SANS exception,
        #  MLflow met le statut à 'FINISHED')
        
except Exception as e:
    # (Si le 'with' se termine AVEC une exception,
    #  MLflow met le statut à 'FAILED')
    print("Run a échoué.")

MLflow Projects est une convention (un standard) pour empaqueter (packager) du code (Data Science) afin de le rendre reproductible.

Le Problème

Un Data Scientist (Alice) vous envoie son script train.py (et un Run ID MLflow). Vous (Bob) essayez de le lancer (python train.py).

Échec : "ModuleNotFoundError: No module named 'tensorflow'".

(Bob n'a pas le bon conda env, les bonnes versions de libs, ou les bons paramètres qu'Alice a utilisés).

Solution (MLproject)

Un "MLflow Project" est un dossier (ou un dépôt Git) qui contient :

1. Le Code (ex: train.py).
2. Un Fichier MLproject (4.2) : (Le "manifeste") Définit les "points d'entrée" (main) et les commandes.
3. Un Fichier d'Environnement (ex: conda.yaml) : (Le "lockfile") Définit les dépendances (tensorflow==2.10, scikit-learn==1.2).

(Voir 4.3) Bob n'exécute plus python train.py. Il exécute mlflow run .... MLflow lit conda.yaml, crée l'environnement (isolé), puis exécute le code (reproductible).

La commande mlflow run est l'exécuteur de "MLflow Projects" (4.1).

Flux d'Exécution (mlflow run ...)

1. mlflow run . -e main -P learning_rate=0.05
2. MLflow lit MLproject (4.2).
3. Il lit conda.yaml (défini dans MLproject).
4. Il crée un environnement conda (isolé) (ex: ./mlflow-env/) et installe les dépendances (tensorflow...).
5. Il active l'environnement conda.
6. Il exécute la command: du point d'entrée "main" (en passant les -P).
   python train.py --data data.csv --lr 0.05

Exécution (Dépôt Git)

mlflow run peut exécuter un projet directement depuis Git (pour la reprod.) :

# (Clone le dépôt, crée l'env, exécute)
$ mlflow run https://github.com/mon-repo/mon-projet-ml \
    --version main \
    -P alpha=0.5

MLflow Models est une convention (un format standard) pour empaqueter (packager) un modèle ML (issu de n'importe quel framework) afin qu'il puisse être réutilisé (ex: servi en API REST, chargé dans Spark).

Le Dossier "Modèle"

Un "Modèle MLflow" n'est pas 1 fichier. C'est un dossier qui contient :

1. MLmodel (Le Manifeste) : Un fichier YAML (crucial) qui définit le modèle, ses "Flavors" (5.2), et ses dépendances (conda.yaml).
2. Les Fichiers du Modèle : (ex: model.pkl (Scikit), saved_model.pb (TensorFlow)).
3. conda.yaml : L'environnement exact (dépendances) requis pour *exécuter* ce modèle.

Les "Flavors" (Saveurs) sont la clé du format MLmodel (5.1). Elles décrivent les différentes façons dont ce modèle peut être compris (chargé).

Exemple (Fichier MLmodel d'un modèle Scikit-learn)

# Fichier: /.../mon-modele/MLmodel (YAML)

artifact_path: model_sklearn
flavors:
  
  # Flavor 1 : "scikit-learn" (Natif)
  # (Sait qu'il faut utiliser 'pickle.load()')
  sklearn:
    pickled_model: model.pkl
    sklearn_version: 1.2.0
    
  # Flavor 2 : "python_function" (pyfunc) (Générique)
  # (Le "wrapper" universel)
  python_function:
    loader_module: mlflow.sklearn
    python_version: 3.9
    env: conda.yaml
    
# Dépendances requises pour exécuter ce modèle
conda_env: conda.yaml 

Le "Flavor" pyfunc (Le plus important)

python_function (pyfunc) est le "format universel". Il garantit que *n'importe quel* modèle (Scikit, TF, PyTorch) expose la même API (signature) : une fonction .predict(dataframe).

Usage : Permet au MLflow Model Server (7.1) de servir (API REST) n'importe quel type de modèle, sans connaître sa technologie sous-jacente.

L'API log_model() (ex: mlflow.sklearn.log_model) est la fonction (utilisée dans un "Run" (2.2)) qui crée le Dossier Modèle (5.1) (MLmodel, conda.yaml, model.pkl) et l'enregistre (upload) dans l'Artifact Store (1.3).

import mlflow.sklearn
from sklearn.ensemble import RandomForestClassifier

# (Entraîner le modèle)
model = RandomForestClassifier()
model.fit(X_train, y_train)

# (Commencer un Run)
with mlflow.start_run() as run:
    
    # ... (log_param, log_metric) ...
    
    # 1. Sauvegarder (Logguer) le Modèle
    mlflow.sklearn.log_model(
        sk_model = model,
        # (Nom du dossier dans les "Artifacts")
        artifact_path = "model_rf", 
        
        # (Optionnel) (Enregistre aussi
        #  le 'conda.yaml' actuel)
        conda_env = "conda.yaml"
    )
    
    run_id = run.info.run_id

# (Résultat : Le modèle est dans
#  s3://.../[exp_id]/[run_id]/artifacts/model_rf/)

Problème : MLflow Tracking (2.1) est un "chaos" (des milliers de "Runs" expérimentaux). Comment savoir quel "Run" (ex: run_id=abc123) est le meilleur, et lequel est actuellement utilisé en Production ?

Solution : MLflow Model Registry (Registre)

Le Model Registry (Registre de Modèles) est le système de gouvernance (Dev -> Staging -> Prod) de MLflow. C'est le "catalogue" centralisé des modèles "promus" (approuvés).

Il nécessite un Tracking Server (2.3) distant (ex: Postgres + S3). (Ne fonctionne pas avec file://).

Workflow (Conceptuel)

1. (Data Scientist) Exécute 100 "Runs" (Tracking).
2. (DS) (UI) Trouve le "Run" (abc123) (Meilleur score).
3. (DS) (UI) Clique "Register Model" (Enregistrer). (Crée Modele_A, Version 1).
4. (Manager) (UI) Reçoit une demande, valide, et passe Version 1 au "Stage" (Étape) "Staging".
5. (CI/CD) Le système (ex: Jenkins) déploie automatiquement la Version 1 (Staging).
6. (Manager) (UI) Valide les tests, et passe Version 1 au "Stage" "Production".

Le Registre (Registry) utilise 3 objets :

[ 1. Registered Model ] (ex: "Prediction_Churn")
  (Le "Nom" du modèle)
  │
  ├─ [ 2. Version 1 ] (ex: 'run_id=abc123')
  │    (Stage: "Archived")
  │
  ├─ [ 2. Version 2 ] (ex: 'run_id=def456')
  │    (Stage: "Staging")
  │
  └─ [ 2. Version 3 ] (ex: 'run_id=ghi789')
       (Stage: "Production")

• 1. Registered Model (Modèle Enregistré) : Le "nom" unique (global) du modèle (ex: "Prediction_Churn").
• 2. Version : Un "snapshot" (pointeur) vers un Run ID (2.1) (Tracking) spécifique. (ex: "Version 1", "Version 2"...).
• 3. Stage (Étape) : (Legacy) Une "étiquette" (Tag) assignée à une Version (Staging, Production, Archived).
  Note : Les "Stages" (Production/Staging) sont obsolètes (deprecated) au profit des "Tags" (key=value) et des "Aliases" (Pointeurs) (plus flexibles).

1. Enregistrer un Modèle (Tracking -> Registry)

Lier un "Run" (Tracking) à un "Nom" (Registry).

(Python)
# (Option A : En 1 fois, pendant le 'log_model')
with mlflow.start_run() as run:
    mlflow.sklearn.log_model(
        model,
        "model",
        # (Crée "Version 1" de "MonModele")
        registered_model_name="MonModele" 
    )

# (Option B : Après le Run)
run_id = "abc123..."
model_uri = f"runs:/{run_id}/model"
mlflow.register_model(model_uri, "MonModele")

2. Promouvoir un Modèle (Staging/Prod)

(Python)
client = mlflow.tracking.MlflowClient()

# (Passer la "Version 5" du modèle en "Production")
client.transition_model_version_stage(
    name="MonModele",
    version=5,
    stage="Production"
)

MLflow inclut un serveur web (REST API) (basé sur Flask) intégré, pour le prototypage rapide (non-recommandé pour la haute performance en production).

Il sert (sert) n'importe quel modèle (loggé) qui a un "Flavor" pyfunc (5.2).

# (Syntaxe)
mlflow models serve -m [URI_MODELE] -p [PORT]

# 1. Servir un modèle depuis un "Run"
$ mlflow models serve \
    -m "runs:/[run_id]/model_rf" \
    -p 5001

# 2. Servir un modèle depuis le "Registry" (Prod)
$ mlflow models serve \
    -m "models:/MonModele/Production" \
    -p 5001
    
# (Le serveur démarre sur http://127.0.0.1:5001)

# 3. Requêter (POST /invocations)
$ curl http://127.0.0.1:5001/invocations \
    -H 'Content-Type: application/json' \
    -d '{"dataframe_split": {"columns": ["col1"], "data": [[1.0]]}}'

Pour la production (haute performance), au lieu d'utiliser mlflow models serve, on utilise mlflow.pyfunc.load_model à l'intérieur de notre propre serveur web (ex: FastAPI, Flask + Gunicorn).

Exemple (API FastAPI + MLflow)

import mlflow
import pandas as pd
from fastapi import FastAPI

# 1. Définir l'URI du modèle (Production)
model_uri = "models:/MonModele/Production"

# 2. Charger le modèle (pyfunc) au démarrage
# (MLflow gère (conda) l'environnement)
model = mlflow.pyfunc.load_model(model_uri)

app = FastAPI()

@app.post("/predict")
def predict(data: dict):
    # (data = {"col1": [1.0], "col2": [0.5]})
    
    # 3. Convertir en DataFrame
    df = pd.DataFrame(data)
    
    # 4. Prédire
    predictions = model.predict(df)
    
    return {"predictions": predictions.tolist()}

Databricks (fondateur de MLflow) est la plateforme managée (SaaS) pour MLflow. Elle fournit une version "Hôte" (Hosted) et intégrée de MLflow.