ML Observability : suivi du comportement du modèle dans le temps¶

Le comportement du modèle peut changer au fil du temps en raison de la migration des entrées, des hypothèses de formation obsolètes et des problèmes de pipeline de données, ainsi que les facteurs habituels, avec des modifications du matériel et des logiciels sous-jacents et de la nature fluide du trafic. ML Observability vous permet de suivre la qualité des modèles de production que vous avez déployés via le Snowflake Model Registry à travers plusieurs dimensions, comme la performance, la migration et le volume.

Actuellement, le moniteur de modèles prend en charge les modèles de régression et de classification binaire.

Note

Pour vous plonger dans l’utilisation de ML Observability, consultez le démarrage rapide.

Flux de travail de ML Observability¶

Lorsque vous utilisez un modèle qui a été connecté au Snowflake Model Registry pour l’inférence, vous recevez les résultats sous la forme d’un DataFrame Snowpark ou pandas, en fonction du DataFrame de type d’entrée transmis à la méthode d’inférence. Ces données proviennent généralement de Snowflake. Même dans les cas où l’inférence est exécutée en dehors de Snowflake, il est courant de stocker les résultats dans Snowflake. ML Observability vous permet de contrôler la performance de votre modèle dans ces deux scénarios en travaillant sur les données d’inférence stockées. Le flux de travail typique est illustré ci-dessous.

Les journaux de surveillance stockent les données d’inférence et les prédictions de sorte que la fonction de ML Observability puisse observer les changements dans les prédictions au fil du temps. Les journaux de surveillance sont stockés dans une table qui contient un ID, un horodatage, des fonctions, des prédictions et de la réalité de terrain, qui indique si une ligne donnée est une prédiction ou des données observées. La structure de base est présentée ci-dessous.

Vous devez créer explicitement un objet moniteur de modèle pour chaque version de modèle que vous souhaitez contrôler. Chaque version de modèle peut avoir exactement un moniteur, et chaque moniteur peut surveiller exactement une version de modèle ; ils ne peuvent pas être partagés. L’objet moniteur actualise automatiquement les journaux de surveillance en interrogeant les données sources et met à jour les rapports de surveillance sur la base des journaux.

Chaque moniteur contient les informations suivantes :

La version du modèle à surveiller.
La table dans laquelle sont connectés les journaux du moniteur.
La granularité temporelle minimale à laquelle les données sont stockées (fenêtre d’agrégation), actuellement 1 jour minimum.
Une table de référence facultative pour les opérations métriques comparatives telles que la migration.

Conditions préalables¶

Avant de commencer, assurez-vous de disposer des éléments suivants :

Un compte Snowflake.
La version 1.7.1 ou ultérieure du paquet Python snowflake-ml-python.
Connaissances de Snowflake Model Registry.

Création d’un moniteur de modèle¶

Créez un moniteur de modèle à l’aide de la commande CREATE MODEL MONITOR. Le moniteur de modèle doit être créé dans le même schéma que la version du modèle à surveiller. Vous devez disposer du privilège CREATE MODEL MONITOR sur le schéma où le moniteur est créé. Vous pouvez créer un maximum de 250 moniteurs de modèles par compte.

Voir CREATE MODEL MONITOR pour plus de détails sur la commande CREATE MODEL MONITOR.

Astuce

Pour plus de détails sur les autres commandes SQL que vous pouvez utiliser avec les moniteurs de modèle, voir Commandes du moniteur de modèles.

Arrêt temporaire et reprise de la surveillance¶

Vous pouvez suspendre (arrêter temporairement) un moniteur de modèle en utilisant ALTER MODEL MONITOR … SUSPEND. Pour reprendre la surveillance, émettez ALTER MODEL MONITOR … RESUME.

Suspension automatique en cas de défaut d’actualisation¶

Les moniteurs de modèles suspendent automatiquement les actualisations lorsqu’ils rencontrent cinq échecs consécutifs d’actualisation liés aux tables sources. Vous pouvez voir le statut et la cause de la suspension de l’actualisation avec la commande DESCRIBE MODEL MONITOR. La sortie comprend notamment les colonnes suivantes :

aggregation_status : la valeur de cette colonne est un objet JSON. Une ou plusieurs valeurs de cet objet seront SUSPENDED si le moniteur de modèle est suspendu.
aggregation_last_error : la valeur de cette colonne est un objet JSON qui contient l’erreur SQL spécifique à l’origine de la suspension.

Après avoir résolu la cause racine de l’échec de l’actualisation, reprenez le moniteur en émettant ALTER MODEL MONITOR … RESUME.

Vue des rapports de suivi¶

Pour voir les rapports des moniteurs, rendez-vous sur le tableau de bord ML Monitoring dans Snowsight. Dans le volet de navigation Snowsight, sélectionnez AI & ML puis Models. La liste obtenue contient tous les modèles du Snowflake Model Registry dans toutes les bases de données et tous les schémas auxquels votre rôle actuel a accès.

Ouvrez la page de détails d’un modèle en sélectionnant la ligne correspondante dans la liste Models. La page de détails affiche des informations clés sur le modèle, notamment sa description, ses balises, ses versions et ses moniteurs.

La liste Monitors de la page de détails affiche la liste des moniteurs de modèle, les versions de modèle auxquelles ils sont rattachés, leur statut et la date de leur création.

Ouvrez la page du tableau de bord d’un moniteur de modèle en sélectionnant la ligne correspondante dans la liste des moniteurs. Le tableau de bord est alimenté par des graphiques affichant les mesures clés du modèle au fil du temps. Les graphiques exacts affichés dépendent du type de modèle sur lequel repose le moniteur (c’est-à-dire la classification binaire ou la régression).

Dans le tableau de bord, vous pouvez effectuer les actions suivantes :

Modifiez l’étendue des graphiques en cliquant sur le sélecteur d’étendue temporelle.
Modifiez les graphiques affichés en cliquant sur le bouton Settings. (Passez la souris sur le nom d’une métrique pour obtenir plus d’informations à son sujet)
Comparez les modèles de moniteurs en cliquant sur le menu déroulant du sélecteur de modèles Compare.
Affichez plus d’informations sur le modèle de moniteur en sélectionnant Display monitor details.

Exigences en matière de contrôle d’accès¶

Les privilèges suivants sont requis pour travailler avec les objets du moniteur de modèle.

Commande	Privilèges requis
CREATE MODEL MONITOR	Le privilège CREATE MODEL MONITOR sur le schéma dans lequel vous souhaitez créer le modèle. SELECT sur la source de données (table ou vue) USAGE sur la base de données, le schéma, l’entrepôt et le modèle
SHOW MODEL MONITORS	Tout privilège sur le modèle de moniteur
DESCRIBE MODEL MONITOR	Tout privilège sur le modèle de moniteur
ALTER MODEL MONITOR	MODIFY sur le moniteur du modèle
DROP MODEL MONITOR	OWNERSHIP sur le moniteur du modèle
Tableau de bord du modèle	USAGE sur le modèle et le moniteur du modèle

Limitations connues¶

Les limites suivantes s’appliquent aux modèles de moniteurs :

Les moniteurs doivent être créés dans la même base de données et le même schéma que la version du modèle à surveiller.
Actuellement, seuls les modèles de régression à sortie unique et de classification binaire sont pris en charge.
Au moins une colonne de prédiction (classe ou score) est exigée. Les colonnes réelles sont facultatives, mais elles sont nécessaires pour calculer des mesures de précision.
Si les données de référence ne sont pas fournies, la migration ne peut pas être calculée. Vous devrez abandonner le moniteur et le créer à nouveau pour ajouter des données de base.
Une colonne donnée ne peut être utilisée qu’une seule fois dans le moniteur. Par exemple, vous ne pouvez pas utiliser la même colonne comme ID et comme prédiction.
Les moniteurs de modèles s’attendent à ce que vos données ne contiennent pas de valeurs non valides telles que des valeurs nulles, NaNs, +/-Inf, des scores de probabilité en dehors de l’intervalle 0-1, des classes qui ne sont pas exactement 0 ou 1, ou plus de deux classes dans une colonne PREDICTION_CLASS_COLUMNS. Ces problèmes peuvent entraîner une défaillance du moniteur et sa suspension.
Les colonnes d’horodatage doivent être du type TIMESTAMP_NTZ ou DATE. Les colonnes de prédiction et de réalité doivent être du type NUMBER.
Les fenêtres d’agrégation doivent être spécifiées en jours.
Le nombre de fonctions surveillées peut être de 500 au maximum.
Vous pouvez créer au maximum 250 moniteurs.

Considérations relatives aux clients¶

Calcul de l’entrepôt virtuel: Les moniteurs de modèles fonctionnent dans un entrepôt virtuel. Cet entrepôt génère des coûts lorsque l’utilisateur crée le service et à chaque fois que le moniteur est actualisé. Un entrepôt virtuel est également utilisé pour charger le tableau de bord Snowsight associé, ce qui entraîne des frais.
Stockage: Les moniteurs de modèles matérialisent les données sources dans une table stockée dans votre compte.
Calcul des services Cloud: Les moniteurs de modèle utilisent le calcul des services cloud pour déclencher des actualisations lorsqu’un objet de base sous-jacent a changé. Le coût de calcul des services Cloud n’est facturé que si le coût quotidien des services cloud est supérieur à 10 % du coût quotidien de l’entrepôt pour le compte.