Gestion de cycle de vie Machine Learning en utilisant MLflow

Cet article présente comment MLflow est utilisé dans Databricks pour la gestion de cycle de vie Machine Learning. Il inclut également des exemples qui présentent chaque composants de MLflow et des liens vers le contenu qui expliquent de quelle façon ces composants sont hébergés dans Azure Databricks.

La gestion de cycle de vie Machine Learning dans Databricks est fournie par MLflow managé. Azure Databricks fournit une version complètement managée et hébergée de MLflow, qui intègre des fonctionnalités de sécurité d’entreprise, une haute disponibilité et d’autres fonctionnalités d’espace de travail Azure Databricks telles que la gestion des expérimentations et des exécutions ainsi que la capture des révisions de notebook.

Les nouveaux utilisateurs devraient commencer par Bien démarrer avec les expériences MLflow, qui illustre les API de suivi MLflow de base.

Qu’est-ce que MLflow ?

MLflow est une plateforme open source qui permet de gérer le cycle de vie du machine learning de bout en bout. Ses principaux composants sont les suivants :

• Suivi : vous permet d’effectuer le suivi des expériences pour enregistrer et comparer les paramètres et les résultats.
• Modèles : vous permettent de gérer et déployer des modèles de diverses bibliothèques ML sur de nombreuses plateformes d’inférence et d’utilisation de modèles.
• Projets : vous permettent de créer un package de code ML dans un format réutilisable et reproductible en vue de le partager avec d’autres scientifiques des données ou de le passer en production.
• Registre de modèle : Permet de centraliser un magasin de modèles pour la gestion des transitions d’étapes du cycle de vie complet des modèles : de l’environnement intermédiaire à la production, avec des fonctionnalités de contrôle de version et d’annotation. Databricks fournit une version gérée du registre de modèles dans Unity Catalog.
• Service de modèles : vous permet d’héberger des modèles MLflow en tant que points de terminaison REST. Databricks fournit une interface unifiée pour déployer, régir et interroger vos modèles IA servis.

MLflow prend en charge les API Java, Python, R et REST.

Les données MLflow sont chiffrées par Azure Databricks à l’aide d’une clé gérée par la plateforme. Le chiffrement à l'aide de clés gérées par le client pour les services gérés n'est pas pris en charge.

Suivi MLflow

MLflow sur Azure Databricks offre une expérience intégrée de suivi et de sécurisation des exécutions d’entraînement pour les modèles de Machine Learning et de Deep Learning.

• Suivre le développement de modèles en utilisant MLflow
• Databricks Autologging

Gestion de cycle de vie de modèles

Le registre de modèles MLflow comprend un référentiel de modèles centralisé, une interface utilisateur et un ensemble d’API qui vous permettent de gérer le cycle de vie complet des modèles MLflow. Azure Databricks fournit une version hébergée du registre de modèles MLflow dans Unity Catalog. Unity Catalog fournit une gouvernance centralisée des modèles, un accès à travers les espaces de travail, une traçabilité et un déploiement. Pour plus d’informations sur la gestion du cycle de vie du modèle dans Unity Catalog, consultez Gérer le cycle de vie de modèles dans Unity Catalog.

Si votre espace de travail n’est pas activé pour Unity Catalog, vous pouvez utiliser le registre du modèle d’espace de travail.

Concepts du registre des modèles

• Modèle : modèle MLflow journalisé à partir d’une expérience ou d’une exécution journalisée avec l’une des méthodes mlflow.<model-flavor>.log_model de la saveur du modèle. Une fois le modèle journalisé, vous pouvez l’inscrire auprès du registre des modèles.
• Modèle inscrit : modèle MLflow qui a été inscrit auprès du registre des modèles. Le modèle inscrit a un nom, des versions, une traçabilité de modèle et d’autres métadonnées uniques.
• Version de modèle : version d’un modèle inscrit. Quand un nouveau modèle est ajouté au registre des modèles, il est ajouté en tant que version 1. Chaque modèle inscrit sous le même nom de modèle incrémente le numéro de version.
• Alias de modèle : un alias est une référence mutable nommée à une version particulière d’un modèle inscrit. Les alias servent couramment à spécifier les versions de modèle déployées dans un environnement donné dans vos workflows d’entraînement de modèle ou à écrire des charges de travail d’inférence qui ciblent un alias spécifique. Par exemple, vous pouvez affecter l’alias « Champion » de votre modèle inscrit « Détection des fraudes » à la version du modèle qui doit servir la majorité du trafic de production, puis écrire des charges de travail d’inférence qui ciblent cet alias (autrement dit, effectuer des prédictions à l’aide de la version « Champion »).
• Phase du modèle (registre du modèle d’espace de travail uniquement) : une version de modèle peut se voir assigner une ou plusieurs phases. MLflow fournit des phases prédéfinies pour les cas d’usage courants Aucun, Préproduction , Production et Archivé. Avec l’autorisation appropriée, vous pouvez effectuer la transition d’une version de modèle entre les phases ou vous pouvez demander une transition de phase de modèle. Les phases de la version de modèle ne sont pas utilisées dans Unity Catalog.
• Description : vous pouvez annoter l’intention d’un modèle, y compris une description et toutes les informations pertinentes et utiles pour l’équipe, telles que la description de l’algorithme, le jeu de données employé ou la méthodologie.

Exemples de notebooks

Pour obtenir un exemple illustrant l’utilisation du registre des modèles afin de créer une application Machine Learning qui prévoit la puissance de sortie quotidienne d’un parc éolien, consultez :

• Modèles dans Unity Catalog, exemple
• Exemple de registre de modèles d’espaces de travail

Déploiement de modèle

Le Service de modèles Mosaic AI permet de déployer, de gérer et d’interroger des modèles d’IA à partir d’une interface unifiée. Chaque modèle servi est disponible en tant qu’API REST que vous pouvez intégrer à votre application web ou cliente.

Le service de modèles prend en charge les modèles suivants :

• Modèles personnalisés. Il s’agit de modèles Python empaquetés au format MLflow. Ils peuvent être inscrits dans Unity Catalog ou dans le registre de modèle de l’espace de travail. Il peut s’agir notamment de modèles scikit-learn, XGBoost, PyTorch et Hugging Face Transformer.
• Modèles ouverts de pointe mis à la disposition par les API Foundation Model. Ces modèles sont des architectures de modèle de base curées qui prennent en charge l’inférence optimisée. Les modèles de base, tels que Meta-Llama-3.1-70B-Instruct, BGE-Large et Mistral-7B, sont disponibles pour une utilisation immédiate avec la tarification de paiement par jeton , et les charges de travail qui nécessitent des garanties de performances et des variantes de modèle affinées peuvent être déployées avec un débit approvisionné.
• Modèles externes. Il s’agit de modèles hébergés en dehors de Databricks. Des exemples incluent des modèles d’IA générative comme GPT-4 d’OpenAI, Claude d’Anthropic et d’autres. Les points de terminaison servant des modèles externes peuvent être régis de manière centralisée et les clients peuvent établir des limites de débit et des contrôles d’accès les concernant.

Vous pouvez également déployer des modèles MLflow pour l’inférence hors connexion, consultez Déployer des modèles à des fins d’inférence par lots.