Aller au contenu principal

Module 6 — Registre de modèles et versions

Un modèle qui vit dans un bucket est un fichier. Un modèle inscrit au Model Registry de Vertex est une entité tracée : ses versions, son évaluation, la tâche qui l'a produit, les jeux de données utilisés, et les points de terminaison qui le servent — tout est relié dans un même objet. C'est cette continuité qui rend l'audit possible et le retour arrière trivial.

Une entrée, plusieurs versions​

Un Model Vertex n'est pas une version : c'est une famille. Notre modèle fraude s'appelle fraude-xgb-europe — un seul nom. Chaque nouvel entraînement produit une nouvelle version numérotée (1, 2, 3…). Les points de terminaison du module 7 pointeront vers une version précise, ou vers un alias qui suit une version.

Deux alias sont posés d'office par la plateforme : default, la version considérée comme référence, et latest, la dernière chronologique. On peut en créer d'autres : champion, challenger, stable-2026-q3. Un alias est plus stable qu'un numéro dans le code d'un service qui appelle le modèle.

Charger le modèle depuis un entraînement​

Le module 4 a déjà déposé le fichier dans AIP_MODEL_DIR. Le CustomContainerTrainingJob a par ailleurs renvoyé un objet modele prêt à être enregistré :

from google.cloud import aiplatform

modele = aiplatform.Model.upload(
    display_name="fraude-xgb-europe",
    artifact_uri="gs://paiement-fraude-modeles/entrainements/2026-09-06/model/",
    serving_container_image_uri="europe-docker.pkg.dev/vertex-ai/prediction/sklearn-cpu.1-3:latest",
    serving_container_predict_route="/predict",
    serving_container_health_route="/health",
    description="XGBoost fraude, entraîné sur 2026-Q3 avec Vizier.",
    labels={"equipe": "fraude", "cadre": "xgboost", "trimestre": "2026q3"},
)
print(f"Version {modele.version_id} de {modele.resource_name}")

L'artifact_uri pointe vers le dossier qui contient model.joblib — pas vers le fichier lui-même. Le serving_container_image_uri est celui que Vertex utilisera au module 7 pour servir les prédictions : image sklearn-cpu.1-3 prédéfinie ici, une image personnalisée si le modèle a des prétraitements maison.

Enregistrer une nouvelle version​

L'entraînement de septembre est meilleur que celui d'août : on l'inscrit comme nouvelle version du même modèle, pas comme un modèle distinct.

modele_v2 = aiplatform.Model.upload(
    display_name="fraude-xgb-europe",   # meme nom -> meme famille
    parent_model="projects/paiement-fraude-prod/locations/europe-west1/models/1234567890",
    artifact_uri="gs://paiement-fraude-modeles/entrainements/2026-09-06/model/",
    serving_container_image_uri="europe-docker.pkg.dev/vertex-ai/prediction/sklearn-cpu.1-3:latest",
    is_default_version=False,   # on ne bascule pas encore l'alias default
    version_aliases=["challenger", "reglage-vizier-2026-09"],
)

Deux points d'attention. Sans parent_model, Vertex crée une famille distincte : c'est la première erreur classique — se retrouver avec cinq entrées fraude-xgb-europe, fraude-xgb-europe-1, etc., qui rompent tout suivi. Ensuite, is_default_version=False laisse volontairement l'alias default sur la version 1 : le module 7 déploiera d'abord la nouvelle version en trafic minoritaire, puis basculera default seulement si elle prouve sa valeur.

Attacher une évaluation​

Une version sans évaluation est un fichier avec un identifiant. Vertex propose un objet ModelEvaluation qui fixe, dans le registre, les métriques calculées sur le jeu de test :

from google.cloud.aiplatform_v1.types import (
    ModelEvaluation, ModelEvaluationSlice,
)
import json

metriques = {
    "auRoc": 0.987,
    "auPrc": 0.712,
    "precisionAt99Recall": 0.184,
    "confusionMatrix": {
        "annotationSpecs": [{"displayName": "legitime"}, {"displayName": "fraude"}],
        "rows": [[184521, 47], [312, 1408]],
    },
}

evaluation = ModelEvaluation(
    display_name="test-2026-08-24-au-31",
    metrics_schema_uri="gs://google-cloud-aiplatform/schema/modelevaluation/classification_metrics_1.0.0.yaml",
    metrics=metriques,
)

# via l'API bas niveau car le SDK haut niveau ne l'expose que partiellement

L'évaluation est visible dans la console à côté de la version. Elle sert deux publics distincts : l'ingénieur qui hésite entre v1 et v2, et l'auditeur qui doit prouver un an plus tard que la version alors en production avait bien été évaluée sur un jeu de test représentatif.

Le lignage, gratuit et précieux​

Le Model.upload posé depuis un CustomContainerTrainingJob inscrit automatiquement le lignage : depuis la version du modèle, Vertex remonte jusqu'à la tâche d'entraînement, jusqu'aux données utilisées (si un Dataset a été rattaché), jusqu'à l'image Docker. On ouvre le graphe dans la console (« Lineage ») ou par l'API :

from google.cloud import aiplatform_v1beta1 as metadata_v1

client = metadata_v1.MetadataServiceClient()
ascendance = client.query_context_lineage_subgraph(context=modele_v2.resource_name)

En audit, la question typique est « quelles données ont servi à entraîner la version en production le 12 février dernier ? ». Sans lignage, la réponse demande de reconstituer à la main. Avec lignage, elle prend dix secondes.

Basculer l'alias default​

Après une semaine où challenger a prouvé sa supériorité en trafic minoritaire (module 7), on bascule :

modele_v2.add_version_aliases(new_aliases=["default"])

L'ancienne version perd automatiquement l'alias : un alias ne peut être posé que sur une seule version à la fois. Le service qui appelait /models/fraude-xgb-europe@default bascule sans changement de code, à la milliseconde près.

Étiquettes, description, propriétaire​

Le trio d'accompagnement se remplit à la création, jamais après coup — parce que « après coup » signifie « jamais » :

  • description : ce que fait le modèle, en une phrase compréhensible par un non-expert. « XGBoost qui prédit la probabilité de fraude d'une transaction carte à partir de 42 variables enrichies ».
  • labels : equipe, cadre, env, trimestre. C'est ce qui alimente le rapport de coût du module 1.
  • Model.metadata : le tag Git de la version du code, l'ID du job d'entraînement — utiles pour reproduire à l'identique.
La suppression d'une version est permanente

Vertex ne conserve pas de corbeille pour les versions supprimées. model.delete_version() efface la métadonnée, mais surtout laisse en état orphelin les points de terminaison qui la déployaient — les requêtes commencent à renvoyer 503. La règle : jamais de suppression tant que la version est référencée par un point de terminaison, et une période de rétention de 90 jours minimum avant toute suppression, le temps qu'un incident de production remonte la chaîne du lignage.

En résumé​

  • Un Model est une famille ; chaque entraînement produit une version numérotée dans cette famille.
  • Les alias (default, latest, champion) stabilisent les appels de service face aux montées de version.
  • parent_model est indispensable pour rattacher une nouvelle version — sans lui, on crée une famille orpheline.
  • Une évaluation attachée est ce qui distingue un modèle du fichier qui le compose, pour l'ingénieur et pour l'auditeur.
  • Le lignage est posé automatiquement par Model.upload depuis un job : conserver la relation, ne pas la couper par un upload à la main.

Module suivant : nous déployons deux versions derrière un point de terminaison, avec trafic partagé 90/10 et mise à l'échelle automatique.