6. Surveillance continue

Dans le cadre de la surveillance continue, les processus automatisés observent et détectent les problèmes de performance et de modélisation. Les propriétaires peuvent ensuite identifier les problèmes et les menaces potentiels en temps réel pour y remédier rapidement.

La surveillance continue permet de détecter d'éventuels problèmes de modèle tels que la qualité des données, le changement de distribution, le changement de concept du modèle et la dégradation de la qualité du modèle. La surveillance continue inclut également une journalisation complète des mesures du système traditionnelles telles que la saturation, la latence, le trafic et les erreurs. Une stratégie pratique de notification et d'alerte est mise en place pour informer les propriétaires en cas de problème.

6.1 Surveillance du modèle : détection de la qualité des données	Une surveillance basée sur des règles est en place pour savoir quand les données entrantes s'écartent des données d'entraînement du modèle. Ce type de surveillance crée un schéma à partir des données d'entraînement, définit des contraintes en fonction de ce schéma, puis exécute des exceptions en cas de violation.
6.2 Surveillance du modèle : changement de distribution	La surveillance est configurée pour examiner la distribution des données entrantes et vérifier qu'elle ne s'écarte pas de la distribution des données d'entraînement du modèle. Par exemple, les données entrantes sont échantillonnées sous forme de fenêtre mobile sur les données d'inférence. Une tâche est ensuite exécutée pour tester la distribution échantillonnée et la distribution de formation afin de vérifier si elles sont identiques.
6.3 Surveillance du modèle : dérive du concept du modèle	Une vérification de la dérive conceptuelle permet de vérifier que la relation entre les entrées d'un modèle et la variable cible reste inchangée par rapport aux données d'entraînement. Une vérification supplémentaire consiste à confirmer que les caractéristiques relatives et leur importance ne changent pas.
6.4 Surveillance du modèle : vérification de l'évaluation du modèle	Il s'agit d'un contrôle de surveillance qui permet d'évaluer si la qualité du modèle s'est dégradée. Le contrôle d'évaluation du modèle compare les mesures d'évaluation de base établies au moment de l'entraînement avec les résultats entrants afin de déterminer si le niveau de précision du modèle a diminué avec les nouvelles données. Comme elle calcule des mesures de précision, cette vérification nécessite que la vérité de base des nouvelles données soit disponible après inférence.
6.5 Captures du système : schémas de saisie	Le système ML capture le schéma des données d'entraînement, de test et de validation. En plus de fournir des informations sur les entrées, les schémas fournissent des statistiques concernant leur asymétrie et leur exhaustivité.  Les schémas sont utilisés pour les tests immédiats et les contrôles de surveillance de la qualité des données en production.
6.6 Captures du système : résultats d'évaluation et statistiques	Le système ML produit des informations de précision sur les données de validation et d'entraînement. Il peut générer les prédictions et les véritables étiquettes issues des cycles de validation et d'entraînement. Elles sont utilisées comme contraintes de surveillance pour le modèle de production en direct.
6.7 Captures du système : anomalies	Un mécanisme de suivi est en place pour signaler les anomalies dans les flux de données entrants. Si des valeurs aberrantes apparaissent dans les données entrantes ou si, au cours d'une période spécifiée, la distribution des principales fonctionnalités change, le système reconnaît qu'il s'agit d'une anomalie et la signale.
6.8 Journalisation : saturation et ressources	Une connexion est en place pour savoir si le système est plein. Les mesures de ressources et de saturation doivent se concentrer sur l'utilisation du processeur, de l'unité de traitement graphique (GPU), de la mémoire et du disque. Ces mesures doivent être disponibles sous forme de séries chronologiques avec la possibilité de les mesurer en percentiles. Pour les tâches par lots, cela fournit des informations sur le débit, qui indiquent le nombre d'unités d'information que le système peut traiter dans chaque intervalle de temps.
6.9 Journalisation : latence	La journalisation doit être mise en place pour mesurer le délai de communication réseau ou le temps nécessaire pour répondre à une demande. Un ingénieur doit être en mesure d'évaluer le temps nécessaire aux modèles d'inférence pour établir les prévisions et le temps nécessaire au chargement du modèle.
6.10 Journalisation : trafic	La configuration de journalisation du trafic mesure le volume de trafic sur chaque instance. Le trafic est mesuré par le nombre de requêtes HTTP et d'octets ou de paquets envoyés ou reçus pendant un certain laps de temps. La journalisation du trafic fournit des informations sur la charge de travail totale placée sur un système.
6.11 Journalisation : erreurs	La configuration de journalisation des erreurs capture le nombre de demandes qui échouent. Les défaillances sont des types suivants : Explicite (par exemple, erreurs HTTP 500) Implicite (par exemple, une réponse de réussite HTTP 200 associée à un contenu incorrect) Politique (par exemple, si vous vous engagez à respecter des délais de réponse d'une seconde, toute demande supérieure à une seconde est une erreur) Lorsque les codes de réponse du protocole sont insuffisants pour exprimer toutes les conditions de défaillance, des protocoles secondaires (internes) peuvent être nécessaires pour suivre les modes de défaillance partielle.
6.12 Notifications et alertes	Les notifications et les alertes sont configurées à partir de la surveillance. Les notifications incluent la possibilité de recevoir Slack, des notifications par e-mail, des pages et des messages SMS (Short Message Service). L'alerte ne signifie pas l'envoi de notifications pour toutes les violations possibles. Cela signifie plutôt définir des alertes pour des exceptions spécifiques qui sont significatives et importantes pour l'équipe de développement. De cette façon, la fatigue liée aux alertes est évitée.