Surveillance des modèles Azure Machine Learning

La supervision des modèles est la dernière étape du cycle de vie de bout en bout du Machine Learning. Cette étape suit le niveau de performance de modèles en production et analyse le niveau de performance du point de vue de la science des données et des opérations. Dans cet article, vous allez découvrir la surveillance des modèles dans Azure Machine Learning, les signaux et les métriques que vous pouvez surveiller, ainsi que les pratiques recommandées pour la surveillance des modèles.

Contrairement aux systèmes logiciels traditionnels, le comportement d’un système Machine Learning ne dépend pas seulement de règles spécifiées dans le code. En effet, il est également appris à partir de données. Les modifications de distribution des données, l’asymétrie d’entraînement/de service, les problèmes de qualité des données, les changements dans les environnements et les évolutions de comportement des consommateurs peuvent tous entraîner l’obsolescence d’un modèle.

Lorsqu’un modèle devient obsolète, ses performances peuvent se dégrader au point qu’il n’apporte plus de valeur à l’entreprise ou qu’il commence à poser de sérieux problèmes de conformité dans les environnements hautement réglementés. Par conséquent, il est important de surveiller le niveau de performance des modèles.

Fonctionnement de la surveillance des modèles Azure Machine Learning

Pour implémenter la surveillance, Azure Machine Learning acquiert des signaux de surveillance en effectuant des calculs statistiques sur les données d’inférence de production diffusées en continu et les données de référence. Les données d’inférence de production font référence aux données d’entrée et de sortie du modèle collectées en production. Les données de référence peuvent être des données d’entraînement historiques, de validation ou de vérité de terrain.

Chaque signal de supervision a une ou plusieurs métriques. Vous pouvez définir des seuils pour ces métriques afin de déclencher des alertes concernant des anomalies de modèle ou de données via Azure Machine Learning ou Azure Event Grid. Lorsque vous recevez des alertes, vous pouvez utiliser Azure Machine Learning studio pour analyser ou dépanner les signaux de surveillance afin d’améliorer en continu la qualité du modèle.

Azure Machine Learning utilise le processus suivant pour gérer un signal de surveillance intégré, par exemple la dérive de données, pour un modèle en production :

• Tout d’abord, Azure Machine Learning calcule la distribution statistique de la valeur de la caractéristique dans les données d’entraînement. Cette distribution est la distribution de base de la caractéristique.

• Puis, Azure Machine Learning calcule la distribution statistique des dernières valeurs de la caractéristique enregistrées en production.

• Azure Machine Learning effectue ensuite un test statistique ou calcule un score de distance pour comparer la distribution des dernières valeurs de la caractéristique en production avec la distribution de référence. Si la statistique de test ou le score de distance entre les deux distributions dépasse un seuil spécifié par l’utilisateur, Azure Machine Learning identifie l’anomalie et avertit l’utilisateur.

Configurer et utiliser la surveillance des modèles

Pour utiliser la surveillance des modèles dans Azure Machine Learning :

Tout d’abord, activez la collecte de données d’inférence de production.

• Si vous déployez un modèle sur un point de terminaison en ligne Azure Machine Learning, vous pouvez activer la collecte de données d’inférence de production à l’aide de la collecte de données de modèle Azure Machine Learning.
• Si vous déployez un modèle en dehors d’Azure Machine Learning ou sur un point de terminaison de traitement par lots Azure Machine Learning, vous êtes responsable de la collecte des données d’inférence de production que vous pouvez ensuite utiliser pour la surveillance des modèles Azure Machine Learning.

Ensuite, configurez la surveillance des modèles. Vous pouvez utiliser le Kit de développement logiciel (SDK)/l’interface CLI 2.0 Azure Machine Learning ou l’interface utilisateur studio pour configurer facilement la surveillance des modèles. Pendant la configuration, vous pouvez spécifier vos signaux de surveillance préférés et personnaliser les métriques et les seuils pour chaque signal.

Enfin, affichez et analysez les résultats de la surveillance des modèles. Une fois la surveillance des modèles configurée, Azure Machine Learning exécute un travail de surveillance selon la planification spécifiée. Chaque exécution calcule et évalue les métriques pour tous les signaux de supervision sélectionnés et déclenche des notifications d’alerte quand un seuil spécifié est dépassé. Vous pouvez suivre le lien dans la notification d’alerte pour afficher et analyser les résultats de la surveillance dans votre espace de travail Azure Machine Learning.

Fonctionnalités de supervision des modèles

Azure Machine Learning fournit les fonctionnalités suivantes pour la supervision continue des modèles :

• Signaux de surveillance intégrés pour les données tabulaires, notamment la dérive de données, la dérive de prédiction, la qualité des données, la dérive d’attribution des caractéristiques et le niveau de performance du modèle.
• Surveillance des modèles prête à l’emploi pour les points de terminaison en ligne. Si vous déployez votre modèle en production dans un point de terminaison en ligne, Azure Machine Learning collecte automatiquement les données d’inférence de production et les utilise pour la surveillance en continu.
• Plusieurs signaux de surveillance dans une seule configuration de surveillance. Pour chaque signal de surveillance, vous pouvez sélectionner vos métriques et un seuil d’alerte préférés.
• Choix des données de référence à des fins de comparaison. Pour les signaux de surveillance, vous pouvez définir des données de référence à l’aide de données d’entraînement ou de données de production passées récentes.
• N principales caractéristiques pour la surveillance de la dérive de données ou de la qualité des données. Si vous utilisez des données d’apprentissage comme données de référence, vous pouvez définir des signaux de dérive ou de qualité des données superposés à l’importance d’une caractéristique.
• Possibilité de définir des signaux de surveillance personnalisés. Si les signaux de supervision intégrés ne conviennent pas à votre scénario d’entreprise, vous pouvez définir votre propre signal de supervision avec un composant de signal de supervision personnalisé.
• Possibilité d’utiliser des données d’inférence de production à partir de n’importe quelle source. Si vous déployez des modèles en dehors d’Azure Machine Learning ou sur des points de terminaison de traitement par lots, vous pouvez toujours collecter vous-même les données d’inférence de production à utiliser dans la surveillance des modèles Azure Machine Learning.

Bonnes pratiques relatives à la surveillance des modèles

Chaque modèle Machine Learning et ses cas d’usage sont uniques. Par conséquent, la supervision de modèle est unique pour chaque situation. La liste suivante décrit les bonnes pratiques recommandées pour la surveillance des modèles.

• Démarrez la surveillance des modèles immédiatement après le déploiement d’un modèle en production.
• Collaborez avec des scientifiques des données qui connaissent le modèle pour configurer la surveillance. Les scientifiques des données qui disposent d’insights sur le modèle et ses cas d’utilisation peuvent non seulement recommander des signaux et des métriques de surveillance, mais aussi définir les seuils d’alerte appropriés pour chaque métrique afin d’éviter la fatigue liée aux alertes.
• Incluez plusieurs signaux de surveillance dans votre configuration. Avec plusieurs signaux de surveillance, vous obtenez à la fois une vue d’ensemble et une vue granulaire de la surveillance. Par exemple, vous pouvez combiner des signaux de dérive de données et de dérive d’attribution de caractéristiques pour obtenir des avertissements précoces concernant les problèmes de performances de votre modèle.
• Utilisez des données de référence appropriées comme base de référence de comparaison. S’agissant des données de référence utilisées comme base de référence de comparaison, vous pouvez utiliser des données de production passées récentes ou des données historiques, notamment des données d’entraînement ou de validation. Pour obtenir une comparaison plus significative, utilisez des données d’entraînement comme base de référence de comparaison pour la dérive de données et la qualité des données. Utilisez les données de validation comme base de référence de comparaison pour la dérive de prédiction.
• Spécifiez la fréquence de surveillance en fonction de la croissance des données de production au fil du temps. Par exemple, si votre modèle de production a un trafic quotidien important et que l’accumulation quotidienne de données est suffisante, définissez une fréquence de surveillance quotidienne. Sinon, envisagez une fréquence de surveillance hebdomadaire ou mensuelle en fonction de la croissance de vos données de production au fil du temps.
• Surveillez les N principales caractéristiques ou un sous-ensemble de caractéristiques. Si vous utilisez des données d’entraînement comme base de référence de comparaison, vous pouvez facilement configurer la surveillance de la dérive de données ou la surveillance de la qualité des données pour les N caractéristiques les plus importantes. Pour les modèles qui ont un grand nombre de caractéristiques, envisagez de superviser un sous-ensemble de ces caractéristiques pour réduire les coûts de calcul et le bruit de supervision.
• Utilisez le signal de performances du modèle lorsque vous avez accès à des données de vérité de terrain. Si vous avez accès aux données de vérité de terrain, également appelées données réelles, en fonction de votre application Machine Learning, utilisez le signal de performances du modèle pour comparer les données de vérité de terrain à la sortie du modèle. Cette comparaison fournit une vue objective du niveau de performance du modèle en production.

Taille et décalage de la fenêtre de recherche arrière

La taille de la fenêtre de recherche arrière est la durée au format ISO 8601 de votre fenêtre de données de production ou de référence. Le décalage de la fenêtre de recherche arrière est la durée nécessaire pour décaler la fin de votre fenêtre de données par rapport à la date de l’exécution de la surveillance.

Par exemple, votre modèle en production dispose d’un moniteur défini pour s’exécuter le 31 janvier à 15 h 15 UTC. Ainsi, pour une taille de fenêtre de recherche arrière des données de production de P7D ou sept jours et un décalage de la fenêtre de recherche arrière des données de P0D ou zéro jour, le moniteur utilise les données de production du 24 janvier à 15 h 15 UTC jusqu’au 31 janvier à 15 h 15 UTC, heure de l’exécution de votre moniteur.

Pour les données de référence, si vous définissez le décalage de la fenêtre de recherche arrière sur P7D ou sept jours, la fenêtre des données de référence se termine juste avant le démarrage de la fenêtre des données de production, de sorte qu’il n’y a pas de chevauchement. Vous pouvez ensuite définir la taille de la fenêtre de recherche arrière de données de référence comme vous le souhaitez.

Par exemple, si vous définissez la taille de la fenêtre de recherche arrière des données de référence sur P24D ou 24 jours, la fenêtre des données de référence inclut les données du 1er janvier à 15 h 15 UTC jusqu’au 24 janvier à 15 h 15 UTC. Le diagramme suivant illustre cet exemple.

Dans certains cas, il peut être utile de définir le décalage de la fenêtre de recherche arrière pour vos données de production sur un nombre supérieur à zéro jour. Par exemple, si votre moniteur est planifié pour s’exécuter tous les lundis à 15 h 15 UTC, mais que vous ne souhaitez pas utiliser les données du week-end dans l’exécution de la surveillance, vous pouvez utiliser une taille de fenêtre de recherche arrière de P5D ou cinq jours et un décalage de fenêtre de recherche arrière de P2D ou deux jours. Votre fenêtre de données démarre alors le lundi précédent à 15 h 15 UTC et se termine le vendredi à 15 h 15 UTC.

Dans la pratique, vous devez vous assurer que la fenêtre de données de référence et la fenêtre de données de production ne se chevauchent pas. Comme le montre la figure suivante, vous pouvez vous assurer que les fenêtres ne se chevauchent pas en veillant à ce que le décalage de la fenêtre de recherche arrière des données de référence, P10D ou 10 jours dans cet exemple, soit supérieur ou égal à la somme de la taille de la fenêtre de recherche arrière des données de production et de son décalage (sept jours au total dans cet exemple).

Avec la surveillance des modèles Azure Machine Learning, vous pouvez utiliser des valeurs par défaut intelligentes pour la taille et le décalage de la fenêtre de recherche arrière, ou vous pouvez les personnaliser pour répondre à vos besoins. Les fenêtres mobiles et les fenêtres fixes sont prises en charge.

Personnaliser la taille de la fenêtre de recherche arrière

Vous avez la possibilité de sélectionner une taille de fenêtre de recherche arrière pour les données de production et les données de référence.

• Par défaut, la taille de la fenêtre de recherche arrière pour les données de production est votre fréquence de surveillance. Toutes les données collectées au cours de la période de surveillance précédant l’exécution du travail de surveillance sont incluses dans la fenêtre de recherche arrière. Vous pouvez utiliser la propriété production_data.data_window.lookback_window_size pour ajuster la fenêtre de données mobile aux données de production.

• Par défaut, la fenêtre de recherche arrière pour les données de référence est le jeu de données complet. Vous pouvez utiliser la propriété reference_data.data_window.lookback_window_size pour ajuster la taille de la fenêtre de recherche arrière de référence.

Pour spécifier une fenêtre de données fixe pour les données de référence, utilisez les propriétés reference_data.data_window.window_start_date et reference_data.data_window.window_end_date.

Personnaliser le décalage de la fenêtre de recherche arrière

Vous avez la possibilité de sélectionner un décalage de fenêtre de recherche arrière pour votre fenêtre de données pour les données de production et de référence. Vous pouvez utiliser le décalage pour un contrôle granulaire sur les données utilisées par votre analyse. Le décalage s’applique uniquement aux fenêtres de données mobiles.

• Par défaut, le décalage pour les données de production est P0D ou zéro jour. Vous pouvez modifier ce décalage avec la propriété production_data.data_window.lookback_window_offset.

• Par défaut, le décalage pour les données de référence est égal à deux fois production_data.data_window.lookback_window_size. Ce paramètre garantit qu’il existe suffisamment de données de référence pour obtenir des résultats de surveillance statistiquement significatifs. Vous pouvez modifier ce décalage avec la propriété reference_data.data_window.lookback_window_offset.

Supervision des signaux et des métriques

La surveillance des modèles Azure Machine Learning prend en charge les signaux et métriques de surveillance suivants.

Métriques de qualité des données

Le signal de surveillance de la qualité des données suit l’intégrité des données d’entrée d’un modèle en calculant les trois métriques suivantes :

• Taux de valeur nulle
• Taux d’erreur de type de données
• Taux hors limites

La surveillance des modèles Azure Machine Learning prend en charge une précision allant jusqu’à 0,00001 pour les calculs du taux de valeurs nulles, du taux d’erreurs de type de données et du taux d’erreurs hors limites.

Taux de valeur nulle

Le taux de valeur nulle est le taux de valeurs nulles dans l’entrée du modèle pour chaque caractéristique. Par exemple, si la fenêtre de données de production de surveillance contient 100 lignes et que la valeur de la caractéristique temperature est nulle pour 10 de ces lignes, le taux de valeur nulle pour temperature est de 10 %.

Azure Machine Learning prend en charge le calcul du taux de valeur nulle pour tous les types de données de caractéristiques.

Taux d’erreur de type de données

Pendant chaque exécution de surveillance, la surveillance des modèles Azure Machine Learning déduit le type de données de chaque caractéristique à partir des données de référence. Le taux d’erreur de type de données est le taux de différences de type de données entre la fenêtre de données de production actuelle et les données de référence.

Par exemple, si le type de données de la caractéristique temperature est déduit comme étant IntegerType d’après les données de référence et que, dans la fenêtre des données de production, 10 valeurs sur 100 pour temperature ne sont pas de type IntegerType mais des chaînes, le taux d’erreur de type de données pour temperature est de 10 %.

Azure Machine Learning prend en charge le calcul du taux d’erreur de type de données pour les types de données disponibles dans PySpark suivants : ShortType, BooleanType, BinaryType, DoubleType, TimestampType, StringType, IntegerType, FloatType, ByteType, LongType, et DateType. Si le type de données d’une caractéristique ne figure pas dans cette liste, la surveillance des modèles Azure Machine Learning s’exécute toujours, mais le taux d’erreur de type de données n’est pas calculé pour cette caractéristique.

Taux hors limites

Pendant chaque exécution de surveillance, la surveillance des modèles Azure Machine Learning détermine la plage ou l’ensemble acceptable pour chaque caractéristique à partir des données de référence. Le taux hors limites est le taux de valeurs de chaque caractéristique se situant en dehors de la plage appropriée ou de l’ensemble déterminé par les données de référence.

• Pour des caractéristiques numériques, la plage appropriée est l’intervalle numérique entre la valeur minimale et la valeur maximale dans le jeu de données de référence, par exemple [0, 100].
• Pour des caractéristiques catégorielles telles que color, la plage appropriée est un ensemble de toutes les valeurs contenues dans le jeu de données de référence, par exemple [red, yellow, green].

Ainsi, si vous disposez d’une caractéristique numérique temperature pour laquelle toutes les valeurs du jeu de données de référence se situent dans la plage [37, 77], mais que 10 valeurs sur 100 pour temperature dans la fenêtre de données de production se situent en dehors de la plage [37, 77], le taux hors limites pour temperature est de 10 %.

Azure Machine Learning prend en charge le calcul du taux hors limites pour les types de données suivants qui sont disponibles dans PySpark : StringType, IntegerType, DoubleType, ByteType, LongType et FloatType. Si le type de données d’une caractéristique ne figure pas dans cette liste, la surveillance des modèles Azure Machine Learning s’exécute toujours, mais le taux hors limites n’est pas calculé pour cette caractéristique.

Intégration de la surveillance des modèles à Azure Event Grid

Vous pouvez utiliser des événements générés par les exécutions de surveillance des modèles Azure Machine Learning pour configurer des applications, des processus ou des workflows CI/CD (intégration continue et livraison continue) pilotés par les événements avec Azure Event Grid. Lorsque votre analyse de modèle détecte une dérive, des problèmes de qualité des données ou une dégradation des performances du modèle, vous pouvez suivre ces événements à l’aide d’Event Grid et prendre des mesures programmatiquement.

Par exemple, si l’exactitude de votre modèle de classification en production passe en dessous d’un certain seuil, vous pouvez utiliser Event Grid pour lancer un travail de réentraînement qui utilise les données de vérité de terrain collectées. Pour savoir comment intégrer Azure Machine Learning à Event Grid, consultez Surveiller les performances des modèles déployés en production.

Contenu connexe

• Collection de données de modèle
• Collecter des données d’inférence de production
• Supervision des modèles pour les applications d’IA génératives