Model Registry
Un registre de modèles est un catalogue versionné de modèles entraînés et de leurs métadonnées, qui indique quelle version est approuvée et laquelle est utilisée en production.
Un registre de modèles est un catalogue versionné de modèles d’apprentissage automatique entraînés. Chaque entrée stocke un artefact de modèle, comme un fichier contenant les poids du modèle, ainsi que les métadonnées nécessaires pour faire confiance au modèle : l’exécution d’entraînement qui l’a produit, la version des données, des métriques d’évaluation telles que la moyenne des précisions moyennes (mAP), le schéma d’entrée et de sortie, le propriétaire et le statut d’approbation. Les pipelines de déploiement et les applications demandent au registre une version nommée, ou la version qui porte actuellement l’étiquette de production, au lieu de faire circuler des fichiers de poids ; ainsi, chaque mise en production et chaque retour arrière font référence à un modèle précis et consigné. Dans les opérations d’apprentissage automatique (MLOps), le registre se situe entre le suivi des expériences et le déploiement de modèles. Parmi les registres couramment utilisés figurent le registre de modèles MLflow, le registre de modèles Amazon SageMaker, le registre de modèles Vertex AI et le registre Weights & Biases.
Fonctionnement d’un registre de modèles#
Un modèle enregistré porte un nom, comme defect-detector, auquel est associée une séquence de versions. Une fois enregistrée, chaque version est immuable : les nouveaux poids deviennent toujours une nouvelle version, et la version 7 désigne toujours les mêmes octets. Une version consigne généralement :
- Traçabilité : l’identifiant d’exécution, le commit de code, la version du jeu de données et le modèle parent qui l’ont produite.
- Résultats d’évaluation : les métriques de validation, ainsi que la latence et la mémoire mesurées sur chaque appareil cible.
- Signature : le schéma d’entrée et de sortie attendu, afin qu’un appelant qui envoie une forme incorrecte obtienne rapidement une erreur.
- Fiche de modèle : documentation de l’utilisation prévue, des données d’entraînement et des limites connues.
- Statut : étiquettes et alias qui indiquent la situation de la version.
Ultralytics Platform conserve ce type d’enregistrement pour chaque exécution d’entraînement YOLO qu’elle héberge : la page du modèle répertorie le modèle parent, la version épinglée du jeu de données, le commit Git, la version ultralytics, les hyperparamètres, les métriques finales et une commande yolo train reproductible. Un champ de métadonnées personnalisées accepte un objet JSON pour le suivi des mises en production ou la gouvernance.
Les anciens registres faisaient passer chaque version par des étapes fixes telles que Staging, Production et Archived. MLflow a rendu les étapes obsolètes dans sa version 2.9.0 au profit des alias, des pointeurs nommés modifiables, comme @champion, qu’une équipe déplace d’une version à l’autre. Amazon SageMaker suit pour chaque version un statut d’approbation : PendingManualApproval, Approved ou Rejected. Promouvoir un modèle consiste à déplacer son alias ; revenir à une version antérieure consiste à déplacer l’alias en arrière :
Les registres contrôlent également qui peut modifier quoi. Les spécialistes des données peuvent enregistrer des versions, les réviseurs désignés déplacent l’alias de production, et chaque modification est consignée dans un journal d’audit. Les équipes relient souvent ces événements à des processus automatisés : l’approbation d’une version démarre le pipeline de déploiement, et une alerte de surveillance des modèles concernant la dérive des données lance le réentraînement qui enregistre le prochain modèle candidat.
Le registre de MLflow illustre le principe en quelques lignes. Ce script entraîne un petit classificateur scikit-learn, l’enregistre, associe l’alias champion à la nouvelle version, puis charge le modèle par l’intermédiaire de l’alias, comme le ferait du code de service de modèles pour trouver le modèle actuellement en production :
import mlflow
from mlflow import MlflowClient
from sklearn.datasets import load_iris
from sklearn.linear_model import LogisticRegression
# Keep runs and registered model versions in a local SQLite file
mlflow.set_tracking_uri("sqlite:///mlflow.db")
X, y = load_iris(return_X_y=True)
# Log a trained model inside a run, then register it as a new version
with mlflow.start_run():
model = LogisticRegression(max_iter=200).fit(X, y)
info = mlflow.sklearn.log_model(model, name="model")
version = mlflow.register_model(info.model_uri, "iris-classifier")
# Point the "champion" alias at this version; applications load the alias
MlflowClient().set_registered_model_alias("iris-classifier", "champion", version.version)
champion = mlflow.pyfunc.load_model("models:/iris-classifier@champion")
print(f"version {version.version}:", champion.predict(X[:3]))Sur une nouvelle base de données, le script affiche version 1: [0 0 0], la version enregistrée et ses classes prédites pour les trois premières fleurs. Une nouvelle exécution enregistre la version 2, et le même URI models:/iris-classifier@champion suit l’alias jusqu’à celle-ci, sans modifier le code de chargement.
Registre de modèles et outils apparentés#
- Suivi des expériences : consigne chaque exécution d’entraînement, y compris celles qui ne sont jamais utilisées. Le registre conserve les quelques modèles candidats qui méritent d’être déployés et relie chaque version à son exécution.
- Stockage d’objets : des compartiments comme Amazon S3 hébergent les fichiers. Un registre ajoute les versions, les métadonnées et le contrôle d’accès, et ne stocke souvent qu’un pointeur vers le fichier dans le compartiment.
- Magasin de caractéristiques : versionne et fournit les caractéristiques d’entrée consommées par les modèles, tandis que les modèles eux-mêmes sont conservés dans le registre.
- Registre de conteneurs : stocke les images Docker qui exécutent les modèles ; un déploiement désigne donc généralement une étiquette d’image et une version de modèle.
- Hugging Face Hub : héberge des modèles publics et privés dans des dépôts Git avec un historique des commits et une fiche de modèle sur la page d’accueil de chaque dépôt, ce qui en fait un registre pour les modèles à poids ouverts.










