Partager via


Mettre à niveau les workflows ML vers les modèles cibles dans Unity Catalog

Cet article explique comment migrer et mettre à niveau des workflows ML vers des modèles cibles dans Unity Catalog.

Spécifications

Avant de commencer, assurez-vous de répondre aux exigences de la section Exigences. En particulier, assurez-vous que les utilisateurs ou les mandataires utilisés pour exécuter vos workflows de formation, de déploiement et d'inférence de modèles disposent des privilèges nécessaires sur un modèle enregistré dans Unity Catalog :

  • Formation : Propriété du modèle déposé (nécessaire pour créer de nouvelles versions du modèle), plus des privilèges USE CATALOG et USE SCHEMA sur le catalogue et le schéma ci-joints.
  • Déploiement : propriété du modèle enregistré (obligatoire pour définir des alias sur le modèle), ainsi que des privilèges USE CATALOG et USE SCHEMA sur le catalogue et le schéma ci-joints.
  • Inférence : privilège EXECUTE sur le modèle enregistré (obligatoire pour lire et effectuer une inférence avec les versions du modèle), plus les privilèges USE CATALOG et `USE SCHEMA sur le catalogue et le schéma englobants.

Création de formations, de déploiements et de flux de travail parallèles

Pour mettre à niveau les workflows d’entraînement et d’inférence de modèle vers Unity Catalog, Databricks recommande une approche incrémentielle dans laquelle vous créez des pipelines d’entraînement, de déploiement et d’inférence parallèles qui tirent parti des modèles dans Unity Catalog. Lorsque vous êtes satisfait des résultats de votre travail avec Unity Catalog, vous pouvez modifier les consommateurs en aval pour qu’ils lisent la sortie d’inférence par lots, ou augmenter le trafic routé vers les modèles dans Unity Catalog dans le service des points de terminaison.

Flux de travail d’apprentissage du modèle

Clonez votre workflow d’apprentissage du modèle. Ensuite, assurez-vous que :

  1. Le cluster de workflow a accès à Unity Catalog et répond aux exigences décrites dans Exigences.
  2. Le principal exécutant le flux de travail dispose des autorisations nécessaires sur un modèle enregistré dans Unity Catalog.

Ensuite, modifiez le code de formation du modèle dans le flux de travail cloné. Vous devrez peut-être cloner le notebook exécuté par le workflow, ou créer et cibler une nouvelle branche git dans le workflow cloné. Suivez ces étapes pour installer la version nécessaire de MLflow, configurer le client pour cibler Unity Catalog dans votre code de formation et mettre à jour le code d’apprentissage du modèle pour enregistrer les modèles dans Unity Catalog.

Workflow de modèle de déploiement

Clonez votre workflow de modèle de déploiement en suivant des étapes similaires à celles du workflow de formation du modèle pour mettre à jour sa configuration de calcul afin d'activer l'accès à Unity Catalog.

Assurez-vous que le principal propriétaire du workflow cloné dispose des autorisations nécessaires. Si vous disposez d’une logique de validation de modèle dans votre flux de travail de déploiement, mettez-la à jour pour charger les versions de modèle à partir d’UC. Utilisez des alias pour gérer les déploiements de modèles de production.

Flux de travail d’inférence de modèle

Flux de travail d'inférence par lots

Suivez des étapes similaires à celles décrites dans le workflow de formation Modèle pour cloner le workflow d'inférence par lots et mettre à jour sa configuration de calcul pour activer l'accès à Unity Catalog. Assurez-vous que le principal exécutant la tâche d'inférence par lots clonée dispose des autorisations nécessaires pour charger le modèle à des fins d'inférence.

Flux de travail de diffusion de modèles

Si vous utilisez le service de modèles Mosaic AI, vous n’avez pas besoin de cloner votre point de terminaison existant. Au lieu de cela, vous pouvez tirer parti de la fonctionnalité de répartition du trafic pour acheminer une petite fraction du trafic vers les modèles dans Unity Catalog.

Tout d’abord, assurez-vous que le principal propriétaire du point de terminaison de diffusion du modèle dispose des autorisations nécessaires pour charger le modèle à des fins d’inférence. Ensuite, mettez à jour votre workflow de déploiement du modèle cloné pour attribuer un petit pourcentage du trafic aux versions de modèle dans Unity Catalog.

Promouvoir un modèle dans plusieurs environnements

Databricks vous recommande de déployer les pipelines ML sous forme de code. Cela vous évite ainsi de promouvoir les modèles dans tous les environnements, car tous les modèles de production peuvent être produits par le biais de workflows de formation automatisés dans un environnement de production.

Toutefois, dans certains cas, il peut être trop coûteux de réentraîner des modèles dans différents environnements. Au lieu de cela, vous pouvez copier des versions de modèle sur des modèles inscrits dans Unity Catalog pour les promouvoir dans les environnements.

Vous avez besoin des privilèges suivants pour exécuter l’exemple de code ci-dessous :

  • USE CATALOG sur les catalogues staging et prod.
  • USE SCHEMA sur les schémas staging.ml_team et prod.ml_team.
  • EXECUTE sur staging.ml_team.fraud_detection.

En outre, vous devez être le propriétaire du modèle inscrit prod.ml_team.fraud_detection.

L’extrait de code suivant utilise l’ copy_model_versionAPI Client MLflow, disponible dans MLflow version 2.8.0 et ultérieure.

import mlflow
mlflow.set_registry_uri("databricks-uc")

client = mlflow.tracking.MlflowClient()
src_model_name = "staging.ml_team.fraud_detection"
src_model_version = "1"
src_model_uri = f"models:/{src_model_name}/{src_model_version}"
dst_model_name = "prod.ml_team.fraud_detection"
copied_model_version = client.copy_model_version(src_model_uri, dst_model_name)

Une fois la version du modèle dans l’environnement de production, vous pouvez effectuer toute validation préalable au déploiement nécessaire. Ensuite, vous pouvez marquer la version du modèle pour le déploiement à l’aide d’alias.

client = mlflow.tracking.MlflowClient()
client.set_registered_model_alias(name="prod.ml_team.fraud_detection", alias="Champion", version=copied_model_version.version)

Dans l’exemple ci-dessus, seuls les utilisateurs qui peuvent lire à partir du modèle inscrit staging.ml_team.fraud_detection et écrire dans le modèle inscrit prod.ml_team.fraud_detection peuvent promouvoir des modèles intermédiaires dans l’environnement de production. Les mêmes utilisateurs peuvent également utiliser des alias pour gérer les versions de modèle déployées dans l’environnement de production. Vous n’avez pas besoin de configurer d’autres règles ou stratégies pour régir la promotion et le déploiement des modèles.

Vous pouvez personnaliser ce flux pour promouvoir la version du modèle dans plusieurs environnements qui correspondent à votre configuration, tels que dev, qa et prod. Le contrôle d’accès est appliqué comme configuré dans chaque environnement.

Utiliser des webhooks de travail pour approuver manuellement le déploiement de modèles

Databricks vous recommande si possible d’automatiser le déploiement de modèles, en utilisant des vérifications et des tests appropriés pendant le processus de déploiement de modèles. Toutefois, si vous devez effectuer des approbations manuelles pour déployer des modèles de production, vous pouvez utiliser des webhooks de travail pour appeler des systèmes CI/CD externes afin de demander une approbation manuelle pour le déploiement d’un modèle, une fois le travail d’apprentissage de votre modèle terminé. Une fois l’approbation manuelle fournie, votre système CI/CD peut ensuite déployer la version du modèle pour traiter le trafic, par exemple en définissant l’alias « Champion » sur celui-ci.