Aller au contenu principal

Module 5 — Registre de modèles et étapes de promotion

Le suivi de MLflow (module 3) donne une vue à plat des exécutions. Le registre y ajoute une dimension : le cycle de vie d'un modèle. Un même artefact passe par plusieurs états au cours de sa vie utile, et chacun de ces états impose des règles.

Un modèle enregistré et ses versions​

Une exécution MLflow produit un artefact ; enregistrer cet artefact dans le registre lui donne un nom stable et un numéro de version.

result = mlflow.register_model(
    model_uri=f"runs:/{run_id}/modele",
    name="churn-telecom",
)
print(result.name, result.version)
# churn-telecom 7

À partir de ce moment, churn-telecom version 7 est un objet nommé, retrouvable, référençable. La version 8 sera la suivante, produite par une autre exécution. Le service en production ne pointe jamais sur un run_id (qui reste un identifiant d'exécution technique) : il pointe sur un nom et une version, qui traduisent une décision.

Étapes et alias : la promotion contrôlée​

Le registre attache à chaque version des étiquettes appelées alias dans les versions récentes de MLflow (elles remplacent les anciennes « stages » Staging / Production / Archived, plus rigides).

from mlflow import MlflowClient

client = MlflowClient()
client.set_registered_model_alias(
    name="churn-telecom",
    alias="champion",
    version="7",
)

Trois alias sont couramment utilisés :

  • candidat : version qui vient d'être enregistrée, en revalidation.
  • champion : version actuellement servie en production.
  • retiree : version qu'on ne veut plus servir mais qu'on garde pour audit ou pour retour arrière.

Le service en production charge le modèle par alias, pas par version : mlflow.pyfunc.load_model("models:/churn-telecom@champion"). Promouvoir une nouvelle version consiste alors à déplacer l'alias champion de la version 7 à la version 8. Le service redémarre, ou recharge à chaud, sans que son code ait changé d'une ligne.

Métadonnées obligatoires​

Une version qui vient d'être enregistrée est nue. Sans métadonnées, on ne peut ni décider de la promouvoir, ni la juger six mois plus tard. Six champs suffisent :

  • Métrique de référence (AUC sur le jeu de validation figé)
  • Métrique métier (taux_faux_positifs_a_5_pourcent_rappel)
  • Empreinte du snapshot données (lien vers DVC)
  • Commit du code d'entraînement
  • Signature du modèle (types et formes des entrées et sorties)
  • Auteur de l'enregistrement
client.update_model_version(
    name="churn-telecom",
    version="7",
    description=(
        "AUC=0.842 sur validation figee; TFP@Rappel95=0.089; "
        "donnees_md5=a5c0...; commit=e2f9...; auteur=alice"
    ),
)
client.set_model_version_tag("churn-telecom", "7", "donnees_md5", "a5c0...")

Ces métadonnées deviennent la fiche d'identité de la version : elles sont la première chose que le comité de mise en production lit, la seule chose qu'un auditeur demande, et le seul moyen honnête de comparer la version 7 à la version 8.

Promotion sans validation : le piège majeur​

Une équipe qui promeut la version 8 parce qu'elle a la meilleure AUC sur le jeu de validation prend un risque considérable. Le jeu de validation peut avoir été surajusté par les 37 essais du mercredi (module 3) ; la version 8 peut être meilleure sur la moyenne mais nettement pire sur un segment sensible ; la métrique métier peut ne pas suivre la métrique technique.

Le module rappelle trois barrières qui doivent séparer l'enregistrement de la promotion.

Un jeu de test figé, non touché pendant l'expérimentation. Il ne sert qu'à mesurer la performance de la version candidate. S'il est utilisé plusieurs fois, il devient un jeu de validation : il est brûlé et il en faut un nouveau.

Une comparaison par tranches (slices). La version 8 doit être aussi bonne que la version 7 sur chaque segment qui compte : abonnés professionnels, forfaits d'entrée de gamme, nouveaux venus. Une moyenne qui monte tandis qu'un segment sensible s'effondre est un mauvais échange.

Une approbation humaine. Le code peut appliquer les deux tests précédents automatiquement (module 7), mais la décision finale de basculer l'alias champion demande une signature. Cette exigence est réglementaire dans plusieurs secteurs (crédit, santé) et sage partout ailleurs.

Le retour arrière, en une ligne​

Le corollaire de la promotion par alias est le retour arrière :

client.set_registered_model_alias(
    name="churn-telecom",
    alias="champion",
    version="7",
)

Une seule ligne, exécutée par n'importe quel opérateur avec les droits, ramène le service à la version précédente. Le service redémarre, ou recharge, et le trafic reçoit à nouveau la version stable. Le module 10 détaille comment automatiser ce déclenchement sur alerte.

L'alias champion n'existe pas par magie

Une version qu'on enregistre sans lui attacher d'alias n'est jamais servie ; le service continue de charger la version portée par l'alias courant. Cette rigueur évite qu'un register_model maladroit ne bascule la production sans le savoir. Elle exige en contrepartie que la promotion soit explicite et journalisée.

En résumé​

  • Le registre nomme et numérote les versions ; le service en charge par alias (@champion), jamais par run_id.
  • Six métadonnées obligatoires font la fiche d'identité de la version : métriques, snapshot, commit, signature, auteur.
  • Trois barrières séparent enregistrement et promotion : jeu de test figé, comparaison par tranches, approbation humaine.
  • Le retour arrière est le déplacement inverse de l'alias, en une seule ligne exécutable en urgence.

Le module 6 emballe le modèle dans une image Docker prête à être servie.