Surveiller le modèle déployé
Déployer le modèle de no-show en toute sécurité permet de le mettre en production, mais c’est en production que le comportement réel d’un modèle, ainsi que les données qu’il voit, peuvent commencer à s’écarter de ce que l’équipe de science des données avait prévu. La surveillance est la façon dont vous interceptez cela.
Surveiller l’état de fonctionnement du terminal
Les points de terminaison en ligne d’Azure Machine Learning envoient des métriques vers Azure Monitor, notamment la latence des requêtes, le nombre de requêtes, le taux d’erreur, ainsi que l’utilisation du processeur et de la mémoire des ressources de calcul du déploiement. Vous les affichez dans Azure Machine Learning studio, ou créez des alertes et des tableaux de bord directement dans Azure Monitor. Si le taux d’erreur de l’endpoint grimpe ou si la latence augmente, cela indique un problème d’infrastructure ou de scoring à examiner, indépendamment du fait que les prédictions du modèle soient toujours exactes.
Tip
En savoir plus sur la surveillance des points de terminaison en ligne.
Si un déploiement ne parvient pas à provisionner ou à noter des demandes, commencez par séparer les problèmes de configuration des problèmes d’exécution. Testez le modèle localement si possible, passez en revue l’état du déploiement et les détails de l’erreur, puis inspectez ses journaux de conteneur. Les journaux d’activité peuvent révéler des dépendances manquantes, un comportement de scoring non valide, des échecs d’image ou des contraintes de ressources et de quota.
Tip
En savoir plus sur Résolution des problèmes de déploiement et de scoring de points de terminaison en ligne.
Configurer la surveillance des prédictions du modèle
Les métriques vous indiquent que le point de terminaison répond, mais elles ne vous disent pas si ses prédictions restent valables à mesure que les données du monde réel évoluent. Azure Machine Learning fournit une surveillance de modèle pour cela, mais il s'agit d'une fonctionnalité que vous configurez. Un déploiement n’est pas surveillé par défaut pour la qualité de prédiction. Pour l’utiliser, vous activez d’abord la collecte de données sur le déploiement en ligne afin que les demandes et réponses entrantes soient journalisées, puis créez un moniteur qui compare ces données de production à un jeu de données de référence, généralement les données sur lesquelles le modèle a été formé ou validé.
Un moniteur de modèle calcule des signaux comme ceux-ci selon une planification que vous définissez :
| Signal | Ce qu’il détecte |
|---|---|
| Dérive de données | La distribution des caractéristiques en entrée s’écarte des données de référence. |
| Dérive de prédiction | La distribution des sorties du modèle change au fil du temps. |
| Qualité des données | Les valeurs manquantes, les nouvelles catégories ou les valeurs hors plage apparaissent dans les données de production. |
| Dérive de l’attribution des caractéristiques | L’importance relative des fonctionnalités change par rapport à la formation. |
Tip
En savoir plus sur la surveillance des performances des modèles déployés en production.
Déterminer quand enquêter ou réentraîner
Un signal de surveillance qui dépasse son seuil configuré est une invite à examiner, et non à un correctif automatique. Pour le modèle de non-présentation de Proseware, une alerte de dérive des données concernant le délai avant le rendez-vous peut signifier que la clinique a modifié sa politique de planification, ce qui mérite un examen plus approfondi avant de décider si un réentraînement est nécessaire. Un signal de dérive de prédiction soutenu, associé à des commentaires du personnel clinique indiquant que les rendez-vous marqués ne sont pas réellement plus risqués, est un cas plus fort pour réentraîner le modèle sur des données plus récentes et le redéployer via le même pipeline que celui que vous avez automatisé précédemment dans ce module.
Choisir entre retour en arrière et réentraînement
Le retour à la version précédente est indiqué lorsqu’un problème survient après un nouveau déploiement et que le modèle précédent fonctionne toujours correctement. Déplacez d’abord le trafic vers le déploiement conservé, puis examinez la nouvelle version. La réentraînation est plus appropriée lorsque les données de production ou le comportement réel ont changé suffisamment que le modèle précédent aurait la même limitation. La surveillance fournit des preuves pour la décision ; elle ne doit déclencher aucune réponse sans évaluation.