Workflows MLOps sur Databricks

Cet article décrit comment vous pouvez utiliser les MLOps sur la plateforme Databricks pour optimiser les performances et l'efficacité à long terme de vos systèmes de Machine Learning (ML). Il inclut des recommandations générales pour une architecture MLOps et décrit un workflow généralisé utilisant la plateforme Databricks que vous pouvez utiliser comme modèle pour votre processus ML de développement à la production. Pour les modifications de ce workflow pour les applications LLMOps, voir workflows LLMOps.

Pour plus de détails, voir Le Grand Livre de MLOps.

Qu'est-ce que le MLOps ?

MLOps est un ensemble de processus et d'étapes automatisées pour gérer le code, les données et les modèles afin d'améliorer les performances, la stabilité et l'efficacité à long terme des systèmes ML. Il combine DevOps, DataOps et ModelOps.

Les assets de ML, tels que le code, les données et les modèles, sont développés par étapes, depuis les premières étapes de développement sans limitations d'accès strictes et non rigoureusement testées, en passant par une étape de test intermédiaire, jusqu'à une étape de production finale strictement contrôlée. La plateforme Databricks vous permet de gérer ces assets sur une seule plateforme avec un contrôle d'accès unifié. Vous pouvez développer des applications de données et des applications de ML sur la même plateforme, réduisant ainsi les risques et les retards associés au déplacement des données.

Recommandations générales pour l'MLOps

Cette section contient des recommandations générales concernant l'MLOps sur Databricks, avec des liens pour plus d'informations.

Créer un environnement séparé pour chaque étape

Un environnement d'exécution est l'endroit où les modèles et les données sont créés ou consommés par le code. Chaque environnement d'exécution se compose d'instances de compute, de leurs runtimes et bibliothèques, et de jobs automatisés.

Databricks recommande de créer des environnements distincts pour les différentes étapes du développement de code et de modèles ML, avec des transitions clairement définies entre les étapes. Le processus décrit dans cet article suit cette approche, en utilisant les noms communs pour les étapes :

• Développement
• Pré-production
• Production

D'autres configurations peuvent également être utilisées pour répondre aux besoins spécifiques de votre organisation.

Contrôle d'accès et gestion des versions

Le contrôle d'accès et le versioning sont des composants clés de tout processus d'opérations logicielles. Databricks recommande ce qui suit :

• Utilisez Git pour le contrôle de version. Les pipelines et le code doivent être stockés dans Git pour le contrôle de version. Le déplacement de la logique ML entre les étapes peut alors être interprété comme le déplacement du code de la branch de développement vers la branch de staging, puis vers la branch de publication. Utilisez les dossiers Git de Databricks pour vous intégrer à votre fournisseur Git et synchroniser les Notebooks et le code source avec les Workspaces Databricks. Databricks fournit également des outils supplémentaires pour l'intégration Git et le contrôle de version ; consultez les outils de développement locaux.
• Stockez les données dans une architecture lakehouse à l'aide des tables Delta. Les données doivent être stockées dans une architecture lakehouse dans votre compte cloud. Les données brutes et les tables de fonctionnalités doivent être stockées en tant que tables Delta avec des contrôles d’accès afin de déterminer qui peut les lire et les modifier.
• Gérez le développement de modèles avec MLflow. Vous pouvez utiliser MLflow pour suivre le processus de développement du modèle et enregistrer les instantanés de code, les paramètres du modèle, les métriques et d'autres métadonnées.
• Utilisez les modèles dans Unity Catalog pour gérer le cycle de vie des modèles. Utilisez les modèles dans Unity Catalog pour gérer le versioning, la gouvernance et l'état du déploiement des modèles.

Déployer du code, pas des modèles

Dans la plupart des situations, Databricks recommande que, pendant le processus de développement ML, vous promouviez le code , plutôt que les modèles , d'un environnement à l'autre. Le déplacement des assets du projet de cette manière garantit que tout le code du processus de développement ML passe par les mêmes processus d'examen du code et de tests d'intégration. Cela garantit également que la version de production du modèle est entraînée sur le code de production. Pour une discussion plus détaillée des options et des compromis, consultez Modèles de déploiement de modèles.

Workflow MLOps recommandé

Les sections suivantes décrivent un workflow MLOps typique, couvrant chacune des trois étapes : développement, pré-production et production.

Cette section utilise les termes « data scientist » et « ingénieur ML » comme personas archétypales ; les rôles et responsabilités spécifiques dans le workflow MLOps varieront entre les équipes et les organisations.

Phase de développement

L'objectif de l'étape de développement est l'expérimentation. Les data scientists développent des fonctionnalités et des modèles, et exécutent des expérimentations pour optimiser les performances des modèles. Le résultat du processus de développement est le code des Pipelines de ML qui peut inclure le calcul de fonctionnalités, l'entraînement de modèles, l'inférence et le monitoring.

Les étapes numérotées correspondent aux numéros indiqués dans le diagramme.

1. Sources de données

L'environnement de développement est représenté par le catalogue de développement dans Unity Catalog. Les data scientists ont un accès en lecture-écriture au catalogue de développement car ils créent des tables de données et de fonctionnalités temporaires dans le Workspace de développement. Les modèles créés en phase de développement sont enregistrés dans le catalogue de développement.

Idéalement, les data scientists travaillant dans le workspace de développement ont également un accès en lecture seule aux données de production dans le catalogue de production. Le fait d'accorder aux data scientists un accès en lecture aux données de production, aux tables d'inférence et aux tables de métriques dans le catalogue de production leur permet d'analyser les prévisions et les performances actuelles des modèles de production. Les data scientists devraient également pouvoir charger des modèles de production pour l'expérimentation et l'analyse.

S'il n'est pas possible d'accorder un accès en lecture seule au catalogue de production, un instantané des données de production peut être écrit dans le catalogue de développement pour permettre aux data scientists de développer et d'évaluer le code de projet.

2. Analyse exploratoire des données (EDA)

Les data scientists explorent et analysent les données selon un processus interactif et itératif à l'aide de notebooks. L'objectif est d'évaluer si les données disponibles ont le potentiel de résoudre la problématique métier. À cette étape, le data scientist commence à identifier les étapes de préparation et de caractérisation des données pour l'entraînement du modèle. Ce processus ad hoc ne fait généralement pas partie d'un pipeline qui sera déployé dans d'autres environnements d'exécution.

AutoML accélère ce processus en générant des modèles de base pour un dataset. AutoML exécute et enregistre un ensemble d'essais et fournit un notebook Python avec le code source pour chaque exécution d'essai, afin que vous puissiez examiner, reproduire et modifier le code. AutoML calcule également des statistiques récapitulatives sur votre dataset et enregistre cette information dans un Notebook que vous pouvez consulter.

3. Code

Le repository de code contient tous les pipelines, modules et autres fichiers de projet pour un projet ML. Les data scientists créent des pipelines nouveaux ou mis à jour dans une Branch de développement (« dev ») du repository du projet. À partir de l'EDA et des phases initiales d'un projet, les data scientists devraient travailler dans un repository pour partager du code et suivre les modifications.

4. Entraîner le modèle (développement)

Les data scientists développent le pipeline d'entraînement de modèles dans l'environnement de développement en utilisant des tables des catalogues dev ou prod.

Ce pipeline comprend 2 tâches :

• Entraînement et ajustement. Le processus d'entraînement logs les paramètres du modèle, les métriques et les artefacts sur le serveur MLflow Tracking. Après l'entraînement et l'ajustement des hyperparamètres, l'artefact du modèle final est enregistré sur le serveur de suivi pour enregistrer un Link entre le modèle, les données d'entrée sur lesquelles il a été entraîné et le code utilisé pour le générer.

• Évaluation. Évaluez la qualité du modèle en le testant sur des données réservées. Les résultats de ces tests sont enregistrés sur le serveur MLflow Tracking. L'objectif de l'évaluation est de déterminer si le modèle nouvellement développé est plus performant que le modèle de production actuel. Compte tenu d'autorisations suffisantes, tout modèle de production enregistré dans le catalogue de production peut être chargé dans le Workspace de développement et comparé à un modèle nouvellement entraîné.

  Si les exigences de gouvernance de votre organisation incluent des informations supplémentaires sur le modèle, vous pouvez les enregistrer à l'aide du suivi MLflow. Les artefacts typiques sont des descriptions en texte brut et des interprétations de modèle telles que des graphiques produits par SHAP. Des exigences de gouvernance spécifiques peuvent provenir d'un responsable de la gouvernance des données ou des parties prenantes commerciales.

La sortie du pipeline d'entraînement de modèle est un artefact de modèle ML stocké dans le serveur MLflow Tracking pour l'environnement de développement. Si le pipeline est exécuté dans le Workspace de préproduction ou de production, l'artefact de modèle est stocké dans le serveur MLflow Tracking de ce Workspace.

Une fois l'entraînement du modèle terminé, enregistrez le modèle dans Unity Catalog. Configurez votre code de pipeline pour enregistrer le modèle dans le catalogue correspondant à l'environnement dans lequel le pipeline du modèle a été exécuté ; dans cet exemple, le catalogue de développement.

Avec l'architecture recommandée, vous déployez un workflow Databricks multitâche dans lequel la première tâche est le pipeline d'entraînement du modèle, suivi des tâches de validation et de déploiement du modèle. La tâche d'entraînement du modèle produit un URI de modèle que la tâche de validation du modèle peut utiliser. Vous pouvez utiliser des valeurs de tâche pour transmettre cet URI au modèle.

5. Valider et déployer le modèle (développement)

En plus du pipeline de formation de modèles, d'autres pipelines, tels que les pipelines de validation de modèles et de déploiement de modèles, sont développés dans l'environnement de développement.

• Validation de modèle. Le pipeline de validation du modèle prend l'URI du modèle à partir du pipeline d'entraînement du modèle, charge le modèle depuis Unity Catalog et exécute les vérifications de validation.

  Les contrôles de validation dépendent du contexte. Ils peuvent inclure des vérifications fondamentales telles que la confirmation du format et des métadonnées requises, et des vérifications plus complexes qui pourraient être requises pour les secteurs d'activité hautement réglementés, telles que des vérifications de conformité prédéfinies et la confirmation des performances du modèle sur des tranches de données sélectionnées.

  La fonction principale du pipeline de validation de modèle est de déterminer si un modèle doit passer à l'étape de déploiement. Si le modèle réussit les vérifications avant le déploiement, il peut se voir attribuer l’alias « Challenger » dans Unity Catalog. Si les vérifications échouent, le processus se termine. Vous pouvez configurer votre workflow pour avertir les utilisateurs en cas d’échec de validation. Voir Ajouter des notifications sur un Job.

• Déploiement de modèles. Le pipeline de déploiement de modèles promeut généralement directement le modèle « Challenger » nouvellement formé au statut de « Champion » à l'aide d'une mise à jour d'alias, ou facilite une comparaison entre le modèle « Champion » existant et le nouveau modèle « Challenger ». Ce pipeline peut également configurer toute infrastructure d'inférence requise, telle que les endpoints de Model Serving. Pour une discussion détaillée des étapes impliquées dans le pipeline de déploiement de modèle, consultez Production.

6. Commit de code

Après avoir développé le code pour l'entraînement, la validation, le déploiement et d'autres pipelines, le data scientist ou l'ingénieur ML commit les modifications de la dev Branch dans le système de gestion de versions.

Étape de préproduction

L'objectif de cette étape est de tester le code du pipeline de ML pour s'assurer qu'il est prêt pour la production. Tout le code du pipeline de ML est testé à ce stade, y compris le code pour l'entraînement de modèles ainsi que les pipelines d'ingénierie des fonctionnalités, le code d'inférence, et ainsi de suite.

Les ingénieurs ML créent un pipeline CI pour implémenter les tests unitaires et d'intégration exécutés à cette étape. Le résultat du processus de staging est une Branch de publication qui Trigger le système CI/CD pour start la phase de production.

1. Données

L'environnement de préproduction doit avoir son propre catalogue dans Unity Catalog pour tester les Pipelines de ML et enregistrer des modèles dans Unity Catalog. Ce catalogue est présenté comme le catalogue « de préproduction » dans le diagramme. Les ressources écrites dans ce catalogue sont généralement temporaires et ne sont conservées que jusqu'à la fin des tests. L'environnement de développement peut également nécessiter un accès au catalogue de préproduction à des fins de debugging.

2. Merge code

Les data scientists développent le pipeline d'entraînement de modèles dans l'environnement de développement à l'aide de tables issues des catalogues de développement ou de production.

• Requête Pull. Le processus de déploiement commence lorsqu'une requête d'extraction est créée contre la Branch principale du projet dans le contrôle de code source.

• Tests unitaires (CI). La requête pull compile automatiquement le code source et Trigger les tests unitaires. Si les tests unitaires échouent, la requête pull est rejetée.

  Les tests unitaires font partie du processus de développement logiciel et sont exécutés en continu et ajoutés à la base de code lors du développement de tout code. L'exécution de tests unitaires dans le cadre d'un pipeline CI garantit que les modifications apportées dans une branch de développement n'interrompent pas les fonctionnalités existantes.

3. Tests d’intégration (CI)

Le processus CI exécute ensuite les tests d'intégration. Les tests d’intégration exécutent tous les pipelines (y compris l’ingénierie des fonctionnalités, l’entraînement de modèles, l’inférence et le monitoring) pour s’assurer qu’ils fonctionnent correctement ensemble. L'environnement de préproduction doit correspondre à l'environnement de production aussi fidèlement que possible.

Si vous déployez une application ML avec inférence en temps réel, vous devriez créer et tester l'infrastructure de diffusion dans l'environnement de pré-production. Cela implique de déclencher le pipeline de déploiement de modèles, qui crée un Endpoint de service dans l'environnement de staging et charge un modèle.

Pour réduire le temps nécessaire à l'exécution des tests d'intégration, certaines étapes peuvent faire un compromis entre la fidélité des tests, la vitesse ou le coût. Par exemple, si les modèles sont coûteux ou chronophages à entraîner, vous pourriez utiliser de petits sous-ensembles de données ou exécuter moins d'itérations d'entraînement. Pour la mise à disposition de modèles, selon les exigences de production, vous pouvez effectuer des tests de charge à grande échelle dans des tests d'intégration, ou vous pouvez simplement tester de petits jobs batch ou des requêtes vers un endpoint temporaire.

4. Merge vers la Branch de staging

Si tous les tests sont réussis, le nouveau code est Merge dans la Branch principale du projet. Si les tests échouent, le système CI/CD doit avertir les utilisateurs et publier les résultats sur la pull request.

Vous pouvez programmer des tests d'intégration périodiques sur la branch principale. C'est une bonne idée si la branch est fréquemment mise à jour avec des demandes de tirage simultanées de plusieurs utilisateurs.

5. Créez une Branch de version

Une fois que les tests CI sont passés et que la dev Branch est Merge dans la main Branch, l'ingénieur ML crée une release Branch, ce qui Trigger le système CI/CD pour mettre à jour les production Job.

Phase de production

Les ingénieurs ML sont responsables de l'environnement de production où les pipelines de ML sont déployés et exécutés. Ces pipelines Trigger l'entraînement de modèles, valident et déploient de nouvelles versions de modèles, publient des prédictions dans des tables ou applications en aval, et surveillent l'ensemble du processus afin d'éviter la dégradation des performances et l'instabilité.

Les data scientists n'ont généralement pas d'accès en écriture ou compute dans l'environnement de production. Cependant, il est important qu'ils aient une visibilité sur les résultats des tests, les Logs, les artefacts de modèle, le statut des pipelines de production et les tables de monitoring. Cette visibilité leur permet d'identifier et de diagnostiquer les problèmes en production et de comparer les performances des nouveaux modèles aux modèles actuellement en production. Vous pouvez accorder aux data scientists un accès en lecture seule aux assets dans le catalogue de production à ces fins.

Les étapes numérotées correspondent aux numéros indiqués dans le diagramme.

1. Entraîner le modèle

Ce pipeline peut être Trigger par des modifications de code ou par des Jobs de réentraînement automatisé. Dans cette étape, les tables du catalogue de production sont utilisées pour les étapes suivantes.

• Entraînement et ajustement. Pendant le processus d’entraînement, les logs sont enregistrés sur le serveur MLflow Tracking de l’environnement de production. Ces Logs incluent les métriques du modèle, les parameters, les tags et le modèle lui-même. Si vous utilisez des tables de fonctionnalités, le modèle est enregistré dans MLflow à l’aide du client du Magasin de fonctionnalités Databricks, qui package le modèle avec les informations de recherche de fonctionnalités utilisées au moment de l’inférence.

  Pendant le développement, les data scientists peuvent tester de nombreux algorithmes et hyperparamètres. Dans le code d'entraînement de production, il est courant de ne prendre en compte que les options les plus performantes. Limiter l'ajustement de cette manière permet de gagner du temps et peut réduire la variance due à l'ajustement lors du réentraînement automatisé.

  Si les data scientists ont un accès en lecture seule au catalogue de production, ils pourraient être en mesure de déterminer l'ensemble optimal d'hyperparamètres pour un modèle. Dans ce cas, le pipeline d'entraînement de modèle déployé en production peut être exécuté en utilisant l'ensemble sélectionné d'hyperparamètres, généralement inclus dans le pipeline sous forme de fichier de configuration.

• Évaluation. La qualité des modèles est évaluée par des tests sur des données de production indépendantes. Les résultats de ces tests sont enregistrés dans le serveur de suivi MLflow. Cette étape utilise les métriques d'évaluation spécifiées par les data scientists au stade du développement. Ces métriques peuvent inclure du code personnalisé.

• Enregistrer le modèle. Une fois l'entraînement du modèle terminé, l'artefact du modèle est enregistré en tant que version de modèle enregistrée au chemin de modèle spécifié dans le catalogue de production dans Unity Catalog. La tâche d'entraînement du modèle produit un URI de modèle que la tâche de validation du modèle peut utiliser. Vous pouvez utiliser les valeurs de tâche pour transmettre cet URI au modèle.

2⁾. Valider le modèle

Ce pipeline utilise l'URI du modèle de l'étape 1 et charge le modèle depuis Unity Catalog. Il exécute ensuite une série de contrôles de validation. Ces vérifications dépendent de votre organisation et de votre cas d'utilisation, et peuvent inclure des éléments tels que des validations de format de base et de métadonnées, des évaluations de performances sur des tranches de données sélectionnées et la conformité aux exigences organisationnelles telles que les contrôles de conformité pour les tags ou la documentation.

Si le modèle réussit toutes les vérifications de validation, vous pouvez attribuer l'alias « Challenger » à la version du modèle dans Unity Catalog. Si le modèle ne passe pas tous les contrôles de validation, le processus se termine et les utilisateurs peuvent être automatiquement notifiés. Vous pouvez utiliser des tags pour ajouter des attributs clé-valeur en fonction du résultat de ces contrôles de validation. Par exemple, vous pourriez créer un tag « model_validation_status » et définir sa valeur sur « PENDING » pendant l'exécution des tests, puis la mettre à jour sur « PASSED » ou « FAILED » une fois le pipeline terminé.

Étant donné que le modèle est enregistré dans Unity Catalog, les data scientists travaillant dans l'environnement de développement peuvent charger cette version du modèle depuis le catalogue de production pour déterminer si le modèle échoue la validation. Quel que soit le résultat, les résultats sont enregistrés dans le modèle enregistré dans le catalogue de production à l'aide d'annotations à la version du modèle.

3. Déployer le modèle

Comme le pipeline de validation, le pipeline de déploiement de modèles dépend de votre organisation et de votre cas d'utilisation. Cette section suppose que vous avez attribué l'alias « Challenger » au modèle nouvellement validé et que l'alias « Champion » a été attribué au modèle de production existant. La première étape avant de déployer le nouveau modèle est de confirmer qu'il fonctionne au moins aussi bien que le modèle de production actuel.

• Comparez le modèle « CHALLENGER » au modèle « CHAMPION ». Vous pouvez effectuer cette comparaison hors ligne ou en ligne. Une comparaison hors ligne évalue les deux modèles par rapport à un ensemble de données retenu et suit les résultats à l'aide du serveur MLflow Tracking. Pour le service de modèle en temps réel, vous souhaiterez peut-être effectuer des comparaisons en ligne plus longues, telles que des tests A/B ou un déploiement progressif du nouveau modèle. Si la version du modèle « Challenger » est plus performante lors de la comparaison, elle remplace l'alias « Champion » actuel.

  Model Serving et le profilage des données vous permettent de collecter et de surveiller automatiquement les tables d'inférence qui contiennent les données de requête et de réponse pour un Endpoint.

  S’il n’existe pas de modèle « Champion », vous pouvez comparer le modèle « Challenger » à une heuristique métier ou à un autre threshold comme référence.

  Le processus décrit ici est entièrement automatisé. Si des étapes d’approbation manuelle sont nécessaires, vous pouvez les configurer à l’aide des notifications de workflow ou des rappels CI/CD du pipeline de déploiement de modèles.

• Déployer le modèle. Les pipelines d'inférence batch ou streaming peuvent être configurés pour utiliser le modèle avec l'alias « Champion ». Pour les cas d'utilisation en temps réel, vous devez configurer l'infrastructure pour déployer le modèle en tant qu'Endpoint d'API REST. Vous pouvez créer et gérer cet Endpoint à l'aide de Model Serving. Si un Endpoint est déjà utilisé pour le modèle actuel, vous pouvez mettre à jour l'Endpoint avec le nouveau modèle. Model Serving exécute une mise à jour sans interruption en maintenant la configuration existante en fonctionnement jusqu'à ce que la nouvelle soit prête.

4. Model Serving

Lorsque vous configurez un Endpoint de Model Serving, vous spécifiez le nom du modèle dans Unity Catalog et la version à servir. Si la version du modèle a été entraînée à l'aide de fonctionnalités de tables dans Unity Catalog, le modèle stocke les dépendances pour les fonctionnalités et les fonctions. Model Serving utilise automatiquement ce graphe de dépendances pour rechercher les fonctionnalités dans les magasins en ligne appropriés au moment de l’inférence. Cette approche peut également être utilisée pour appliquer des fonctions de prétraitement des données ou pour calculer des fonctionnalités à la demande lors de l'évaluation du modèle.

Vous pouvez créer un seul Endpoint avec plusieurs modèles et spécifier la répartition du trafic de l’Endpoint entre ces modèles, ce qui vous permet d’effectuer des comparaisons en ligne « Champion » contre « Challenger ».

5. Inférence : batch ou streaming

Le pipeline d’inférence lit les données les plus récentes du catalogue de production, exécute des fonctions pour compute des fonctionnalités à la demande, charge le modèle « Champion », évalue les données et renvoie les prédictions. L’inférence batch ou streaming est généralement l’option la plus rentable pour les cas d’utilisation à throughput élevé et à latence plus élevée. Pour les scénarios où des prédictions à faible latence sont requises, mais où les prédictions peuvent être calculées hors ligne, ces prédictions batch peuvent être publiées dans un magasin de clés-valeurs en ligne tel que DynamoDB ou Cosmos DB.

Le modèle enregistré dans Unity Catalog est référencé par son alias. Le pipeline d'inférence est configuré pour charger et appliquer la version du modèle « Champion ». Si la version « Champion » est mise à jour vers une nouvelle version du modèle, le pipeline d'inférence utilise automatiquement la nouvelle version pour sa prochaine exécution. De cette façon, l'étape de déploiement du modèle est découplée des pipelines d'inférence.

Les jobs batch publient généralement les prédictions dans des tables du catalogue de production, dans des fichiers plats ou via une connexion JDBC. Les jobs de streaming publient généralement des prédictions soit dans les tables Unity Catalog, soit dans des files d’attente de messages comme Apache Kafka.

6. Profilage des données

Le profilage des données effectue le monitoring des propriétés statistiques, telles que le drift des données et les performances du modèle, des données d’entrée et des prédictions du modèle. Vous pouvez créer des alertes basées sur ces métriques ou les publier dans des tableaux de bord.

• Ingestion des données. Ce pipeline lit les logs de l'inférence par batch, en streaming ou en ligne.
• Vérifier la précision et la drift des données. Le pipeline calcule les métriques sur les données d'entrée, les prédictions du modèle et les performances de l'infrastructure. Les data scientists spécifient les métriques de données et de modèle pendant le développement, et les ingénieurs ML spécifient les métriques d'infrastructure. Vous pouvez également définir des métriques personnalisées.
• **Publiez des métriques et configurez des alertes.** Le pipeline écrit dans des tables du catalogue de production pour l'analyse et le reporting. Vous devez configurer ces tables pour qu'elles soient lisibles à partir de l'environnement de développement afin que les data scientists y aient accès pour l'analyse. Vous pouvez utiliser Databricks SQL pour créer des tableaux de bord de monitoring afin de suivre les performances du modèle, et configurer le Job de monitoring ou l'outil de tableau de bord pour émettre une notification lorsqu'une métrique dépasse un threshold spécifié.
• Trigger model retraining. Lorsque les mesures de monitoring indiquent des problèmes de performance ou des changements dans les données d'entrée, le data scientist peut avoir besoin de développer une nouvelle version de modèle. Vous pouvez configurer des alertes SQL pour notifier les data scientists lorsque cela se produit.

7ᵉ. Réentrainement

Cette architecture prend en charge le réentraînement automatique en utilisant le même pipeline d'entraînement de modèles ci-dessus. Databricks recommande de commencer par un réentraînement périodique planifié et de passer à un réentraînement déclenché si nécessaire.

• Planifié. Si de nouvelles données sont disponibles régulièrement, vous pouvez créer un Job planifié pour exécuter le code d'entraînement du modèle sur les dernières données disponibles. Voir Automatiser les Job avec des planifications et des Trigger
• Trigger. Si le pipeline de monitoring peut identifier les problèmes de performance du modèle et envoyer des alertes, il peut également Trigger un réentraînement. Par exemple, si la distribution des données entrantes change de manière significative ou si la performance du modèle se dégrade, un réentraînement et un redéploiement automatiques peuvent améliorer les performances du modèle avec une intervention humaine minimale. Ceci peut être réalisé au moyen d'une alerte SQL pour vérifier si une métrique est anormale (par exemple, vérifier le drift ou la qualité du modèle par rapport à un threshold). L'alerte peut être configurée pour utiliser une destination de webhook, ce qui peut ensuite Trigger le workflow de formation.

Si le pipeline de réentraînement ou d'autres pipelines présentent des problèmes de performance, le data scientist pourrait avoir besoin de retourner à l'environnement de développement pour une expérimentation supplémentaire afin de résoudre les problèmes.