Suite à la partie précédente, il est temps de tirer parti de l'instruction de VALIDATION DU MODÈLE IntegratedML, qui fournit des informations permettant de surveiller vos modèles ML. Vous pouvez la voir en action ici
Le code présenté ici est dérivé d'exemples fournis par le modèle InterSystems IntegratedML ou la documentation IRIS, documentation
Remarque: Le code présenté ici n'a qu'une valeur explicative. Si vous souhaitez l'essayer, j'ai développé une application modèle - iris-integratedml-monitor-example, qui participe au concours IA d'InterSystems IRIS (InterSystems IRIS AI Contest). S'il vous plaît, après avoir lu cet article, vous pouvez le consulter et, si vous l'aimez, votez pour moi! :)
Contenu
Partie I:
Partie II:
Surveillance des performances du ML
Pour surveiller votre modèle ML, vous aurez besoin d'au moins deux fonctions :
- Fournisseur de mesures de performance
- Service de surveillance et de notification
Heureusement, IRIS nous fournit ces deux caractéristiques nécessaires.
Obtenir des mesures de performance des modèles ML
Comme nous l'avons vu dans la partie précédente, IntegratedML fournit l'instruction VALIDER LE MODÈLE pour calculer les paramètres de performance suivants :
- Exactitude : la qualité de votre modèle (des valeurs proches de 1 signifient des taux élevés de réponses correctes).
- Précision : dans quelle mesure votre modèle traite les faux positifs (des valeurs proches de 1 signifient un taux élevé de non faux positifs).
- Rappel : dans quelle mesure votre modèle traite les faux négatifs (des valeurs proches de 1 signifient un taux élevé de non faux négatifs).
- Mesure F : une autre façon de mesurer la précision, utilisée lorsque la précision n'est pas satisfaisante (des valeurs proches de 1 signifient un taux élevé de réponses correctes).
Remarque: ces définitions ne sont pas formelles, elles sont même assez superficielles ! Je vous encourage à prendre le temps de les interpréter.
Ce qui est intéressant, c'est qu'à chaque fois que vous appelez VALIDER LE MODÈLE (VALIDATE MODEL), IntegrateML enregistre sa mesure de performance, et nous pouvons tirer parti de cette fonctionnalité pour la surveiller.
Moteur de surveillance
InterSystems IRIS fournit le framework du Moniteur de Système pour traiter les tâches de surveillance. Il vous permet également de définir des règles personnalisées afin de déclencher des notifications basées sur des prédicats appliqués à ces mesures.
Par défaut, un ensemble de mesures est fourni pour le disque, la mémoire, les processus, le réseau, etc. En outre, le Moniteur de Système vous permet également d'étendre les moniteurs pour couvrir une infinité de possibilités. De tels moniteurs personnalisés sont appelés une application de moniteur (Application Monitor) dans la terminologie de moniteur de système (System Monitor).
Vous pouvez obtenir plus d'informations sur le Moniteur de Système ici.
La mise en place de l'ensemble
Jusqu'à présent, nous avons un moyen d'obtenir les valeurs des métriques de performance de chaque validation du modèle et, un outil qui pourrait déclencher des alertes basées sur des règles personnalisées appliquées à des sources de métriques personnalisées... Bien, il est temps de les combiner.
Tout d'abord, nous devons créer une classe de moniteur d'application personnalisée, en étendant la classe %Monitor.Abstract et en implémentant les méthodes Initialize et GetSample.
Class MyMetric.IntegratedMLModelsValidation Extends %Monitor.Adaptor
{
/// Initialiser la liste des métriques de validation des modèles.
Method Initialize() As %Status
{
Return $$$OK
}
/// Obtenir un échantillon métrique de routine.
/// Un code de retour de $$$OK indique qu'il y a une nouvelle instance d'échantillon.
/// Tout autre code de retour indique qu'il n'y a pas d'échantillon.
Method GetSample() As %Status
{
Return $$$OK
}
}
Les moniteurs système émettent des appels réguliers aux classes de moniteurs afin d'obtenir un ensemble de mesures appelées échantillons. Ces échantillons peuvent être simplement surveillés ou utilisés pour vérifier si des règles d'alerte doivent être levées. Vous définissez la structure de ces échantillons en définissant des propriétés standard non internes dans la classe monitior. Il est important de souligner ici que vous devez spécifier, dans le paramètre INDEX, l'une de ces propriétés comme clé primaire de chaque échantillon - sinon une erreur de clé dupliquée sera générée.
Class MyMetric.IntegratedMLModelsValidation1 Extends %Monitor.Adaptor
{
Parameter INDEX = "ModelTrainedName";
/// Nom de la définition du modèle
Property ModelName As %Monitor.String;
/// Nom du modèle formé en cours de validation
Property ModelTrainedName As %Monitor.String;
/// Erreur de validation (le cas échéant)
Property StatusCode As %Monitor.String;
/// Précision
Property ModelMetricPrecision As %Monitor.Numeric;
/// Rappel
Property ModelMetricRecall As %Monitor.Numeric;
/// Mesure F
Property ModelMetricFMeasure As %Monitor.Numeric;
/// Exactitude
Property ModelMetricAccuracy As %Monitor.Numeric;
...
}
La méthode Initialize est appelée une fois pour chaque appel de moniteur et la méthode GetSample est appelée jusqu'à ce qu'elle renvoie 0.
Ainsi, nous pourrions mettre en place un SQL sur l'historique de validation d'IntegrateML pour fournir des informations de métriques au moniteur, en implémentant les méthodes Initialize et GetSample :
/// Initialiser la liste des métriques de validation des modèles.
Method Initialize() As %Status
{
// Obtenir la dernière validation pour chaque modèle validé par l'instruction VALIDATION DU MODÈLE
Set sql =
"SELECT MODEL_NAME, TRAINED_MODEL_NAME, STATUS_CODE, %DLIST(pair) AS METRICS_LIST FROM ("_
"SELECT m.*, $LISTBUILD(m.METRIC_NAME, m.METRIC_VALUE) pair, r.STATUS_CODE "_
"FROM INFORMATION_SCHEMA.ML_VALIDATION_RUNS r "_
"JOIN INFORMATION_SCHEMA.ML_VALIDATION_METRICS m "_
"ON m.MODEL_NAME = r.MODEL_NAME "_
"AND m.TRAINED_MODEL_NAME = r.TRAINED_MODEL_NAME "_
"AND m.VALIDATION_RUN_NAME = r.VALIDATION_RUN_NAME "_
"GROUP BY m.MODEL_NAME, m.METRIC_NAME "_
"HAVING r.COMPLETED_TIMESTAMP = MAX(r.COMPLETED_TIMESTAMP)"_
") "_
"GROUP BY MODEL_NAME"
Set stmt = ##class(%SQL.Statement).%New()
$$$THROWONERROR(status, stmt.%Prepare(sql))
Set ..Rspec = stmt.%Execute()
Return $$$OK
}
/// Obtenir un échantillon métrique de routine.
/// Un code de retour de $$$OK indique qu'il y a une nouvelle instance d'échantillon.
/// Tout autre code de retour indique qu'il n'y a pas d'échantillon.
Method GetSample() As %Status
{
Set stat = ..Rspec.%Next(.sc)
$$$THROWONERROR(sc, sc)
// Quitter si nous avons fait tous les jeux de données
If 'stat {
Quit 0
}
// remplir cette instance
Set ..ModelName = ..Rspec.%Get("MODEL_NAME")
Set ..ModelTrainedName = ..Rspec.%Get("TRAINED_MODEL_NAME")_" ["_$zdt($zts,3)_"]"
Set ..StatusCode = ..Rspec.%Get("STATUS_CODE")
Set metricsList = ..Rspec.%Get("METRICS_LIST")
Set len = $LL(metricsList)
For iMetric = 1:1:len {
Set metric = $LG(metricsList, iMetric)
Set metricName = $LG(metric, 1)
Set metricValue = $LG(metric, 2)
Set:(metricName = "PRECISION") ..ModelMetricPrecision = metricValue
Set:(metricName = "RECALL") ..ModelMetricRecall = metricValue
Set:(metricName = "F-MEASURE") ..ModelMetricFMeasure = metricValue
Set:(metricName = "ACCURACY") ..ModelMetricAccuracy = metricValue
}
// quitter avec une valeur de retour indiquant que les données de l'échantillon sont prêtes
Return $$$OK
}
Après avoir compilé la classe de moniteur, vous devez redémarrer le moniteur de système System Monitor afin que le système comprenne qu'un nouveau moniteur a été créé et qu'il est prêt à être utilisé. Pour ce faire, vous pouvez utiliser la routine ^%SYSMONMGR ou la classe %SYS.Monitor.
Un cas d'utilisation simple
Jusqu'à présent, nous disposons des outils nécessaires pour collecter, surveiller et émettre des alertes sur les mesures de performance du ML. Il est maintenant temps de définir une règle d'alerte personnalisée et de simuler un scénario dans lequel un modèle ML déployé commence à affecter négativement vos performances.
Tout d'abord, nous devons configurer une alerte par courriel et sa règle de déclenchement. Cela peut être fait à l'aide de la routine ^%SYSMONMGR. Cependant, afin de rendre les choses plus faciles, j'ai créé une méthode d'installation qui définit toute la configuration de l'e-mail et de la règle d'alerte. Vous devez remplacer les valeurs entre <> ; par les paramètres de votre serveur de messagerie et de votre compte.
ClassMethod NotificationSetup()
{
// Régler les paramètres de l'e-mail
Set sender = "<your e-mail address>"
Set password = "<your e-mail password>"
Set server = "<SMTP server>"
Set port = "<SMTP server port>"
Set sslConfig = "default"
Set useTLS = 1
Set recipients = $LB("<comma-separated receivers for alerts>")
Do ##class(%Monitor.Manager).AppEmailSender(sender)
Do ##class(%Monitor.Manager).AppSmtpServer(server, port, sslConfig, useTLS)
Do ##class(%Monitor.Manager).AppSmtpUserName(sender)
Do ##class(%Monitor.Manager).AppSmtpPassword(password)
Do ##class(%Monitor.Manager).AppRecipients(recipients)
// La messagerie électronique comme méthode de notification par défaut
Do ##class(%Monitor.Manager).AppNotify(1)
// Activer les notifications par messagerie électronique
Do ##class(%Monitor.Manager).AppEnableEmail(1)
Set name = "perf-model-appointments-prediction"
Set appname = $namespace
Set action = 1
Set nmethod = ""
Set nclass = ""
Set mclass = "MyMetric.IntegratedMLModelsValidation"
Set prop = "ModelMetricAccuracy"
Set expr = "%1 < .8"
Set once = 0
Set evalmethod = ""
// Créer une alerte
Set st = ##class(%Monitor.Alert).Create(name, appname, action, nmethod, nclass, mclass, prop, expr, once, evalmethod)
$$$THROWONERROR(st, st)
// Relancer le moniteur
Do ##class(MyMetric.Install).RestartMonitor()
}
Dans la méthode précédente, une alerte sera émise si le moniteur obtient des valeurs de précision inférieures à 90 %.
Maintenant que notre règle d'alerte est configurée, créons, formons et validons un modèle de prédiction show/no-show avec les 500 premiers enregistrements et validons-le avec les 600 premiers enregistrements.
Remarque : Le paramètre seed sert uniquement à garantir la reproductibilité (c.-à-d. pas de valeurs aléatoires) et doit normalement être évité en production.
-- Création du modèle
CREATE MODEL AppointmentsPredection PREDICTING (Show) FROM MedicalAppointments USING {\"seed\": 3}
-- Formation à l'aide des 500 premiers enregistrements du jeu de données
TRAIN MODEL AppointmentsPredection FROM MedicalAppointments WHERE ID <= 500 USING {\"seed\": 3}
-- Affichage des informations sur le modèle
SELECT * FROM INFORMATION_SCHEMA.ML_TRAINED_MODELS
| | NOM_DU_MODÈLE | NOM_DU_MODÈLE_FORMÉ | FOURNISSEUR | HORODATAGE_FORMÉ | TYPE_DU_MODÈLE | INFOS_MODÈLE |
|---|------------------------|-------------------------|----------|-------------------------|----------------|---------------------------------------------------|
| 0 | AppointmentsPredection | AppointmentsPredection2 | AutoML | 2020-07-12 04:46:00.615 | classification | ModelType:Logistic Regression, Package:sklearn... |
Notez que IntegrateML, en utilisant AutoML comme fournisseur (colonne FOURNISSEUR), déduit du jeu de données fourni, un modèle de classification (colonne TYPE_DU_MODÈLE), avec l'algorithme de régression logistique, à partir de la bibliothèque scikit-learn (colonne INFOS_MODÈLE). Il est important de souligner ici la règle "Garbage In, Garbage Out" ("à données inexactes, résultats erronés") - c'est-à-dire que la qualité du modèle est directement liée à la qualité des données.
Poursuivons maintenant avec la validation du modèle.
-- CCalculer les performances du modèle en utilisant les 600 premiers enregistrements (500 de l'ensemble formé + 100 pour le test).
VALIDATE MODEL AppointmentsPredection FROM MedicalAppointments WHERE ID < 600 USING {\"seed\": 3}
-- Afficher les mesures de validation
SELECT * FROM INFORMATION_SCHEMA.ML_VALIDATION_METRICS WHERE MODEL_NAME = '%s'
| NOM_MÉTRIQUE | Exactitude | Mesure F | Précision | Rappel |
|--------------------------|----------|-------------|-----------|--------|
| AppointmentsPredection21 | 0.9 | 0.94 | 0.98 | 0.91 |
Le modèle peut être utilisé pour effectuer des prédictions à l'aide de l'instruction PREDICT :
SELECT PREDICT(AppointmentsPredection) As Predicted, Show FROM MedicalAppointments WHERE ID <= 500
| | Prédit | Affiché|
|-----|-----------|-------|
| 0 | 0 | Faux |
| 1 | 0 | Faux |
| 2 | 0 | Faux |
| 3 | 0 | Faux |
| 4 | 0 | Faux |
| ... | ... | ... |
| 495 | 1 | Vrai |
| 496 | 0 | Vrai |
| 497 | 1 | Vrai |
| 498 | 1 | Vrai |
| 499 | 1 | Vrai |
Ensuite, simulons l'ajout de 200 nouveaux enregistrements (pour un total de 800 enregistrements) au modèle de manière à ce que sa précision soit ramenée à 87 %.
-- Calculer les performances du modèle en utilisant les 800 premiers enregistrements.
VALIDATE MODEL AppointmentsPredection FROM MedicalAppointments WHERE ID < **800** USING {\"seed\": 3}
-- Afficher les mesures de validation
SELECT * FROM INFORMATION_SCHEMA.ML_VALIDATION_METRICS WHERE MODEL_NAME = '%s'
| NOM_MÉTRIQUE | Exactitude | Mesure F | Précision | Rappel |
|--------------------------|----------|-----------|-----------|--------|
| AppointmentsPredection21 | 0.9 | 0.94 | 0.98 | 0.91 |
| AppointmentsPredection22 | 0.87 | 0.93 | 0.98 | 0.88 |
Comme nous avons mis en place une règle pour envoyer une notification par messagerie électronique si la précision est inférieure à 90%, le moniteur de système System Monitor comprend qu'il est temps de déclencher une telle alerte vers le(s) compte(s) de messagerie électronique concerné(s).
Dans le corps du message, vous pouvez trouver des informations sur l'alerte, telles que son nom, le moniteur d'application et ses valeurs métriques qui ont déclenché l'alerte.
Ainsi, une telle situation sera notifiée aux personnes qui pourront prendre des mesures pour y remédier. Par exemple, une action pourrait consister simplement à réentraîner le modèle, mais dans certains cas, une approche plus élaborée peut s'avérer nécessaire.
Il est certainement possible d'approfondir les mesures de surveillance et de créer de meilleures alertes. Par exemple, imaginez que vous ayez plusieurs modèles ML en cours d'exécution et que différentes personnes soient responsables de chacun d'entre eux. Vous pourriez utiliser la métrique du nom du modèle et définir des règles d'alerte spécifiques, pour des destinataires d'e-mails spécifiques.
Le moniteur System Monitor vous permet également de déclencher une ClassMethod au lieu d'envoyer un courriel. Ainsi, vous pouvez exécuter une logique complexe lorsqu'une alerte est déclenchée, comme entraîner automatiquement le modèle, par exemple.
Notez que, comme System Monitor exécutera régulièrement les méthodes "Initialize" et "GetSample", ces méthodes doivent être soigneusement conçues afin de ne pas demander trop de ressources au système.
Travaux futurs
Comme le souligne Benjamin De BoeIRIS introduit une nouvelle façon de personnaliser votre tâche de surveillance - l' outil SAM. Ma première impression a été très positive, SAM est intégré avec les technologies de surveillance des standards du marché comme Grafana et Prometheus. Alors, pourquoi ne pas aller de l'avant et tester comment améliorer ce travail avec de telles nouvelles fonctionnalités ? Mais il s'agit là d'une matière pour un futur travail.... :)
Voilà, c'est fait ! J'espère que cela pourra vous être utile d'une manière ou d'une autre.
A bientôt !
%20(3)(1).jpg)
.png)
(1).jpg)
.png)
%20(3).png)
.png)