Partager via

Superviser les performances des modèles déployés en production

  • Article

S’APPLIQUE À :Extension Azure CLI v2 (actuelle)Kit de développement logiciel (SDK) Python azure-ai-ml v2 (version actuelle)

Apprenez à utiliser le monitoring des modèles d’Azure Machine Learning pour suivre en continu les performances des modèles Machine Learning en production. Le monitoring des modèles vous offre une vue approfondie des signaux de monitoring et vous alerte sur les problèmes potentiels. Quand vous suivez les signaux et les métriques de performances des modèles en production, vous pouvez évaluer de manière critique les risques inhérents qui leur sont associés et identifier les points aveugles qui pourraient nuire à votre entreprise.

Cet article vous montre comment effectuer les tâches suivantes :

  • Configurer le monitoring prêt à l’emploi et avancé pour les modèles déployés sur des points de terminaison en ligne Azure Machine Learning
  • Analyser les métriques des performances pour les modèles en production
  • Surveiller les modèles déployés en dehors d’Azure Machine Learning ou sur des points de terminaison en lots Azure Machine Learning
  • Configurer la surveillance du modèle avec des signaux et des indicateurs de performance personnalisés
  • Interpréter les résultats de la surveillance
  • Intégrer la surveillance des modèles Azure Machine Learning à Azure Event Grid

Prérequis

Avant de suivre les étapes décrites dans cet article, vérifiez que vous disposez des composants requis suivants :

  • Les contrôles d’accès en fonction du rôle Azure (Azure RBAC) sont utilisés pour accorder l’accès aux opérations dans Azure Machine Learning. Pour effectuer les étapes décrites dans cet article, votre compte d’utilisateur doit avoir le rôle Propriétaire ou Contributeur sur l’espace de travail Azure Machine Learning, ou un rôle personnalisé autorisant Microsoft.MachineLearningServices/workspaces/onlineEndpoints/*. Pour plus d’informations, consultez Gérer l’accès à un espace de travail Azure Machine Learning.

  • Pour la surveillance d’un modèle déployé sur un point de terminaison en ligne Azure Machine Learning (point de terminaison en ligne managé ou point de terminaison en ligne Kubernetes), veillez à :

  • Pour surveiller un modèle déployé sur un point de terminaison en lot Azure Machine Learning ou en dehors d’Azure Machine Learning, veillez à :

    • Avoir un moyen de collecter des données de production et de les inscrire en tant que ressource de données Azure Machine Learning.
    • Mettre à jour la ressource de données inscrite en continu pour la surveillance des modèles.
    • (Recommandé) Inscrire le modèle dans un espace de travail Azure Machine Learning pour le suivi de la traçabilité.

Important

Les travaux de surveillance des modèles sont planifiés pour s’exécuter sur des pools de calcul Spark serverless avec prise en charge des types d’instance de machine virtuelle suivants : Standard_E4s_v3, Standard_E8s_v3, Standard_E16s_v3, Standard_E32s_v3 et Standard_E64s_v3. Vous pouvez sélectionner le type d’instance de machine virtuelle avec la propriété create_monitor.compute.instance_type dans votre configuration YAML ou dans la liste déroulante dans Azure Machine Learning studio.

Configurer la supervision des modèles prêtes à l’emploi

Supposons que vous déployez votre modèle en production dans un point de terminaison en ligne Azure Machine Learning et que vous activez la collecte de données au moment du déploiement. Dans ce scénario, Azure Machine Learning collecte les données d’inférence de production et les stocke automatiquement dans le Stockage Blob Microsoft Azure. Vous pouvez ensuite utiliser la surveillance des modèles Azure Machine Learning pour surveiller en continu ces données d’inférence de production.

Vous pouvez utiliser l’interface Azure CLI, le SDK Python ou le studio pour une configuration prête à l’emploi de la surveillance des modèles. La configuration de la surveillance des modèles prête à l’emploi fournit les fonctionnalités de surveillance suivantes :

  • Azure Machine Learning détecte automatiquement le jeu de données d’inférence de production associé à un déploiement en ligne Azure Machine Learning et utilise le jeu de données pour la surveillance des modèles.
  • Le jeu de données de référence de comparaison est défini comme jeu de données d’inférence de production récent.
  • La configuration de la supervision inclut et suit automatiquement les signaux de supervision intégrés : dérive de données, dérive de prédiction et qualité des données. Pour chaque signal de supervision, Azure Machine Learning utilise :
    • le jeu de données d’inférence de production récent en tant que jeu de données de référence de comparaison.
    • des valeurs par défaut intelligentes pour les métriques et les seuils.
  • Un travail de supervision est planifié pour s’exécuter quotidiennement à 3h15 (pour cet exemple) afin d’acquérir des signaux de supervision et d’évaluer chaque résultat de métrique par rapport à son seuil correspondant. Par défaut, quand un seuil est dépassé, Azure Machine Learning envoie un e-mail d’alerte à l’utilisateur qui a configuré le moniteur.

La surveillance des modèles Azure Machine Learning utilise az ml schedule pour planifier un travail de surveillance. Vous pouvez créer le moniteur de surveillance de modèle prêt à l’emploi avec la commande CLI et la définition YAML suivantes :

az ml schedule create -f ./out-of-box-monitoring.yaml

Le code YAML suivant contient la définition de la surveillance des modèles prête à l’emploi.

# out-of-box-monitoring.yaml
$schema:  http://azureml/sdk-2-0/Schedule.json
name: credit_default_model_monitoring
display_name: Credit default model monitoring
description: Credit default model monitoring setup with minimal configurations

trigger:
  # perform model monitoring activity daily at 3:15am
  type: recurrence
  frequency: day #can be minute, hour, day, week, month
  interval: 1 # #every day
  schedule: 
    hours: 3 # at 3am
    minutes: 15 # at 15 mins after 3am

create_monitor:

  compute: # specify a spark compute for monitoring job
    instance_type: standard_e4s_v3
    runtime_version: "3.3"

  monitoring_target: 
    ml_task: classification # model task type: [classification, regression, question_answering]
    endpoint_deployment_id: azureml:credit-default:main # azureml endpoint deployment id

  alert_notification: # emails to get alerts
    emails:
      - abc@example.com
      - def@example.com

Configurer la supervision de modèle avancée

Azure Machine Learning fournit de nombreuses fonctionnalités pour la supervision continue des modèles. Pour obtenir la liste complète de ces fonctionnalités, consultez Fonctionnalités de surveillance des modèles. Dans de nombreux cas, vous devez configurer la surveillance des modèles avec des fonctionnalités de supervision avancées. Dans les sections suivantes, vous allez configurer la surveillance des modèles avec ces fonctionnalités :

  • Utilisation de plusieurs signaux de supervision pour une vue d’ensemble.
  • Utilisation des données d’entraînement du modèle historique ou des données de validation comme jeu de données de référence de comparaison.
  • Surveillance des N premières caractéristiques les plus importantes et des caractéristiques individuelles.

Configurer l’importance d’une caractéristique

L’importance des caractéristiques représente l’importance relative de chaque caractéristique entrée dans la sortie d’un modèle. Par exemple, temperature est susceptible d’être plus important pour la prédiction d’un modèle que elevation. L’activation de l’importance des caractéristiques peut vous donner une visibilité sur les caractéristiques que vous ne voulez pas voir dériver ou avoir des problèmes de qualité de données en production.

Pour activer l’importance des caractéristiques avec l’un de vos signaux (tels que la dérive de données ou la qualité de données), vous devez fournir :

  • Votre jeu de données d’entraînement en tant que jeu de données reference_data.
  • La propriété reference_data.data_column_names.target_column, qui est le nom de la sortie/colonne de prédiction de votre modèle.

Après avoir activé l’importance des caractéristiques, vous verrez une importance de caractéristique pour chaque caractéristique que vous surveillez dans l’interface utilisateur du studio de surveillance des modèles Azure Machine Learning.

Vous pouvez utiliser Azure CLI, le SDK Python ou le studio pour la configuration avancée de la surveillance des modèles.

Créez la configuration avancée de la surveillance des modèles avec la commande CLI et la définition YAML suivantes :

az ml schedule create -f ./advanced-model-monitoring.yaml

Le YAML suivant contient la définition pour la supervision avancée des modèles.

# advanced-model-monitoring.yaml
$schema:  http://azureml/sdk-2-0/Schedule.json
name: fraud_detection_model_monitoring
display_name: Fraud detection model monitoring
description: Fraud detection model monitoring with advanced configurations

trigger:
  # perform model monitoring activity daily at 3:15am
  type: recurrence
  frequency: day #can be minute, hour, day, week, month
  interval: 1 # #every day
  schedule: 
    hours: 3 # at 3am
    minutes: 15 # at 15 mins after 3am

create_monitor:

  compute: 
    instance_type: standard_e4s_v3
    runtime_version: "3.3"

  monitoring_target:
    ml_task: classification
    endpoint_deployment_id: azureml:credit-default:main
  
  monitoring_signals:
    advanced_data_drift: # monitoring signal name, any user defined name works
      type: data_drift
      # reference_dataset is optional. By default referece_dataset is the production inference data associated with Azure Machine Learning online endpoint
      reference_data:
        input_data:
          path: azureml:credit-reference:1 # use training data as comparison reference dataset
          type: mltable
        data_context: training
        data_column_names:
          target_column: DEFAULT_NEXT_MONTH
      features: 
        top_n_feature_importance: 10 # monitor drift for top 10 features
      metric_thresholds:
        numerical:
          jensen_shannon_distance: 0.01
        categorical:
          pearsons_chi_squared_test: 0.02
    advanced_data_quality:
      type: data_quality
      # reference_dataset is optional. By default reference_dataset is the production inference data associated with Azure Machine Learning online endpoint
      reference_data:
        input_data:
          path: azureml:credit-reference:1
          type: mltable
        data_context: training
      features: # monitor data quality for 3 individual features only
        - SEX
        - EDUCATION
      metric_thresholds:
        numerical:
          null_value_rate: 0.05
        categorical:
          out_of_bounds_rate: 0.03

    feature_attribution_drift_signal:
      type: feature_attribution_drift
      # production_data: is not required input here
      # Please ensure Azure Machine Learning online endpoint is enabled to collected both model_inputs and model_outputs data
      # Azure Machine Learning model monitoring will automatically join both model_inputs and model_outputs data and used it for computation
      reference_data:
        input_data:
          path: azureml:credit-reference:1
          type: mltable
        data_context: training
        data_column_names:
          target_column: DEFAULT_NEXT_MONTH
      metric_thresholds:
        normalized_discounted_cumulative_gain: 0.9
  
  alert_notification:
    emails:
      - abc@example.com
      - def@example.com

Configurer le monitoring des performances

Le monitoring des modèles Azure Machine Learning vous permet de suivre les performances de vos modèles en production en calculant les métriques relatives à leurs performances. Les métriques de performances des modèles suivantes sont actuellement prises en charge :

Pour les modèles de classification :

  • Precision
  • Exactitude
  • Rappel

Pour les modèles de régression :

  • Erreur absolue moyenne (MAE)
  • Erreur carrée moyenne (MSE)
  • Erreur quadratique moyenne (RMSE)

Autres prérequis relatifs au monitoring des performances des modèles

Vous devez répondre aux exigences suivantes pour pouvoir configurer votre signal de performances des modèles :

  • Disposer de données de sortie pour le modèle de production (prédictions du modèle), avec un ID unique pour chaque ligne. Si vous collectez des données de production avec le collecteur de données Azure Machine Learning, un correlation_id est vous est fourni pour chaque requête d’inférence. Avec le collecteur de données, vous avez également la possibilité de consigner votre propre ID unique à partir de votre application.

    Remarque

    Pour le monitoring des performances des modèles Azure Machine Learning, nous vous recommandons de consigner votre ID unique dans sa propre colonne, à l’aide du collecteur de données Azure Machine Learning.

  • Disposer de données correspondant à la réalité du terrain (données réelles), avec un ID unique pour chaque ligne. L’ID unique d’une ligne donnée doit correspondre à l’ID unique des sorties de modèle pour cette requête d’inférence particulière. Cet ID unique est utilisé pour joindre votre jeu de données réelles aux sorties du modèle.

    Sans données réelles, vous ne pouvez pas procéder au monitoring des performances des modèles. Étant donné que les données réelles sont disponibles au niveau de l’application, vous devez veiller à les collecter au fur et à mesure de leur disponibilité. Il est également recommandé de conserver une ressource de données dans Azure Machine Learning contenant ces données réelles.

  • (Facultatif) Disposer d’un jeu de données tabulaire pré-joint avec des sorties de modèle et des données réelles déjà jointes.

Surveiller les exigences en matière de performances des modèles lors de l’utilisation du collecteur de données

Si vous utilisez le collecteur de données Azure Machine Learning pour collecter des données d’inférence de production, mais que vous n’avez pas fourni votre propre ID unique pour chaque ligne sous la forme d’une colonne distincte, un correlationid sera généré automatiquement et inclus dans l’objet JSON journalisé. Toutefois, le collecteur de données regroupera par lots les lignes envoyées dans des intervalles de temps courts. Les lignes regroupées par lots se trouvent dans le même objet JSON et partagerons donc le même correlationid.

Pour différencier les lignes d’un même objet JSON, le monitoring des performances du modèle Azure Machine Learning utilise l’indexation afin de déterminer l’ordre des lignes de l’objet JSON. Par exemple, si trois lignes sont regroupées par lots et que le correlationid est test, la ligne 1 aura un ID de test_0, la ligne 2 aura un ID de test_1et la ligne 3 aura un ID de test_2. Pour vous assurer que votre jeu de données réelles contient des ID uniques qui correspondent aux sorties du modèle d’inférence de production collectées, veillez à indexer chaque correlationid correctement. Si votre objet JSON journalisé n’a qu’une seule ligne, le correlationid est correlationid_0.

Pour éviter d’utiliser cette indexation, nous vous recommandons de consigner votre ID unique dans sa propre colonne au sein du DataFrame pandas que vous journalisez avec le collecteur de données Azure Machine Learning. Ensuite, dans la configuration du monitoring des modèles, vous allez spécifier le nom de cette colonne pour joindre vos données de sortie de modèle à vos données réelles. Tant que les ID de chaque ligne des deux jeux de données sont identiques, le monitoring des modèles Azure Machine Learning peut procéder au monitoring des performances des modèles.

Exemple de workflow pour le monitoring des performances des modèles

Pour comprendre les concepts associés au monitoring des performances des modèles, examinez cet exemple de workflow. Supposons que vous déployez un modèle pour prédire si des transactions effectuées par carte de crédit sont frauduleuses ou non. Vous pouvez suivre ces étapes pour surveiller les performances du modèle :

  1. Configurez votre déploiement pour collecter les données d’inférence de production du modèle (données d’entrée et de sortie) à l’aide du collecteur de données. Supposons que les données de sortie sont stockées dans une colonne is_fraud.
  2. Pour chaque ligne des données d’inférence collectées, journalisez un ID unique. L’ID unique peut provenir de votre application, ou vous pouvez utiliser le correlationid généré de manière unique par Azure Machine Learning pour chaque objet JSON journalisé.
  3. Ultérieurement, lorsque les données correspondant à la réalité du terrain (ou données réelles) is_fraud deviennent disponibles, elles sont également journalisée et mappées au même ID unique qui avait été journalisé avec les sorties du modèle.
  4. Ces données réelles is_fraud sont également collectées, conservées et enregistrées auprès d’Azure Machine Learning en tant que ressource de données.
  5. Créez un signal de monitoring des performances du modèle qui joint les ressources d’inférence de production et de données réelles du modèle à l’aide des colonnes d’ID uniques.
  6. Enfin, calculez les métriques de performances des modèles.

Une fois que vous avez satisfait aux exigences de monitoring des performances des modèles, vous pouvez configurer la supervision des modèles avec la commande CLI et la définition YAML suivantes :

az ml schedule create -f ./model-performance-monitoring.yaml

Le code YAML suivant contient la définition de la supervision des modèles avec les données d’inférence de production que vous avez collectées.

$schema:  http://azureml/sdk-2-0/Schedule.json
name: model_performance_monitoring
display_name: Credit card fraud model performance
description: Credit card fraud model performance

trigger:
  type: recurrence
  frequency: day
  interval: 7 
  schedule: 
    hours: 10
    minutes: 15
  
create_monitor:
  compute: 
    instance_type: standard_e8s_v3
    runtime_version: "3.3"
  monitoring_target:
    ml_task: classification
    endpoint_deployment_id: azureml:loan-approval-endpoint:loan-approval-deployment

  monitoring_signals:
    fraud_detection_model_performance: 
      type: model_performance 
      production_data:
        data_column_names:
          prediction: is_fraud
          correlation_id: correlation_id
      reference_data:
        input_data:
          path: azureml:my_model_ground_truth_data:1
          type: mltable
        data_column_names:
          actual: is_fraud
          correlation_id: correlation_id
        data_context: actuals
      alert_enabled: true
      metric_thresholds: 
        tabular_classification:
          accuracy: 0.95
          precision: 0.8
  alert_notification: 
      emails: 
        - abc@example.com

Configurer le monitoring des modèles en apportant vos données de production à Azure Machine Learning

Vous pouvez également configurer la supervision des modèles pour les modèles déployés sur des points de terminaison de lot Azure Machine Learning ou déployés en dehors d’Azure Machine Learning. Si vous n’avez pas de déploiement, mais que vous avez des données de production, vous pouvez utiliser les données pour effectuer une surveillance des modèles en continu. Pour surveiller ces modèles, vous devez pouvoir :

  • Collecter les données d’inférence de production des modèles déployés en production.
  • Inscrire les données d’inférence de production en tant que ressource de données Azure Machine Learning et garantir des mises à jour continues des données.
  • Fournir un composant de prétraitement des données personnalisé et l’inscrire en tant que composant Azure Machine Learning.

Vous devez fournir un composant de prétraitement des données personnalisé si vos données ne sont pas collectées avec le collecteur de données. Sans ce composant de prétraitement des données personnalisé, le système de surveillance des modèles Azure Machine Learning ne sait pas comment traiter vos données sous forme tabulaire avec prise en charge du fenêtrage temporel.

Votre composant de prétraitement personnalisé doit avoir les signatures d’entrée et de sortie suivantes :

Entrée/sortie Nom de la signature Type Description Exemple de valeur
input data_window_start littéral, chaîne heure de début de la fenêtre de données au format ISO8601. 2023-05-01T04:31:57.012Z
input data_window_end littéral, chaîne heure de fin de la fenêtre de données au format ISO8601. 2023-05-01T04:31:57.012Z
input input_data uri_folder Données d’inférence de production collectées, qui sont inscrites en tant que ressource de données Azure Machine Learning. azureml:myproduction_inference_data:1
output preprocessed_data mltable Jeu de données tabulaire qui correspond à une partie du schéma de données de référence.

Pour obtenir un exemple de composant de prétraitement de données personnalisé, consultez custom_preprocessing dans le dépôt GitHub azuremml-examples.

Une fois que vous avez satisfait aux exigences précédentes, vous pouvez configurer la supervision des modèles avec la commande CLI et la définition YAML suivantes :

az ml schedule create -f ./model-monitoring-with-collected-data.yaml

Le code YAML suivant contient la définition de la supervision des modèles avec les données d’inférence de production que vous avez collectées.

# model-monitoring-with-collected-data.yaml
$schema:  http://azureml/sdk-2-0/Schedule.json
name: fraud_detection_model_monitoring
display_name: Fraud detection model monitoring
description: Fraud detection model monitoring with your own production data

trigger:
  # perform model monitoring activity daily at 3:15am
  type: recurrence
  frequency: day #can be minute, hour, day, week, month
  interval: 1 # #every day
  schedule: 
    hours: 3 # at 3am
    minutes: 15 # at 15 mins after 3am

create_monitor:
  compute: 
    instance_type: standard_e4s_v3
    runtime_version: "3.3"
  monitoring_target:
    ml_task: classification
    endpoint_deployment_id: azureml:fraud-detection-endpoint:fraud-detection-deployment
  
  monitoring_signals:

    advanced_data_drift: # monitoring signal name, any user defined name works
      type: data_drift
      # define production dataset with your collected data
      production_data:
        input_data:
          path: azureml:my_production_inference_data_model_inputs:1  # your collected data is registered as Azure Machine Learning asset
          type: uri_folder
        data_context: model_inputs
        pre_processing_component: azureml:production_data_preprocessing:1
      reference_data:
        input_data:
          path: azureml:my_model_training_data:1 # use training data as comparison baseline
          type: mltable
        data_context: training
        data_column_names:
          target_column: is_fraud
      features: 
        top_n_feature_importance: 20 # monitor drift for top 20 features
      metric_thresholds:
        numberical:
          jensen_shannon_distance: 0.01
        categorical:
          pearsons_chi_squared_test: 0.02

    advanced_prediction_drift: # monitoring signal name, any user defined name works
      type: prediction_drift
      # define production dataset with your collected data
      production_data:
        input_data:
          path: azureml:my_production_inference_data_model_outputs:1  # your collected data is registered as Azure Machine Learning asset
          type: uri_folder
        data_context: model_outputs
        pre_processing_component: azureml:production_data_preprocessing:1
      reference_data:
        input_data:
          path: azureml:my_model_validation_data:1 # use training data as comparison reference dataset
          type: mltable
        data_context: validation
      metric_thresholds:
        categorical:
          pearsons_chi_squared_test: 0.02
  
  alert_notification:
    emails:
      - abc@example.com
      - def@example.com

Configurer la surveillance du modèle avec des signaux et des indicateurs de performance personnalisés

Avec le monitoring des modèles Azure Machine Learning, vous pouvez définir un signal personnalisé et implémenter les métriques de votre choix pour surveiller votre modèle. Vous pouvez inscrire ce signal personnalisé en tant que composant Azure Machine Learning. Lorsque votre travail de surveillance des modèles Azure Machine Learning s’exécute selon la planification spécifiée, il calcule la ou les métriques que vous avez définies dans votre signal personnalisé, tout comme il le fait pour les signaux prédéfinis (dérive de données, dérive de prédictions et qualité de données).

Pour configurer un signal personnalisé à utiliser pour la surveillance des modèles, vous devez d’abord définir le signal personnalisé et l’inscrire en tant que composant Azure Machine Learning. Le composant Azure Machine Learning doit avoir les signatures d’entrée et de sortie suivantes :

Signature d'entrée de composant

Le DataFrame d’entrée du composant doit contenir les éléments suivants :

  • Un mltable avec les données traitées du composant de prétraitement
  • Des littéraux, chacun représentant une métrique implémentée dans le cadre du composant de signal personnalisé. Par exemple, si vous avez implémenté la métrique, std_deviation, vous aurez besoin d’une entrée pour std_deviation_threshold. Normalement, il devrait y avoir une entrée par métrique avec le nom <metric_name>_threshold.
Nom de la signature Type Description Exemple de valeur
production_data mltable Jeu de données tabulaire qui correspond à une partie du schéma de données de référence.
std_deviation_threshold littéral, chaîne Seuil respectif pour l’indicateur de performance mise en œuvre. 2

Signature de sortie du composant

Le port de sortie du composant doit avoir la signature suivante.

Nom de la signature Type Description
signal_metrics mltable Mltable qui contient les métriques calculées. Le schéma est défini dans la prochaine section, Schéma signal_metrics.

schéma signal_metrics

Le DataFrame de sortie du composant doit contenir quatre colonnes : group, metric_name, metric_value et threshold_value.

Nom de la signature Type Description Exemple de valeur
groupe littéral, chaîne Regroupement logique de niveau supérieur à appliquer à cette métrique personnalisée. TRANSACTIONAMOUNT
metric_name littéral, chaîne Nom de l’indicateur de performance personnalisé. std_deviation
metric_value numérique La valeur de l’indicateur de performance personnalisé. 44 896,082
threshold_value numérique Le seuil de l’indicateur de performance personnalisé. 2

Le tableau suivant présente un exemple de sortie d’un composant de signal personnalisé qui calcule la métrique std_deviation :

group metric_value metric_name threshold_value
TRANSACTIONAMOUNT 44 896,082 std_deviation 2
LOCALHOUR 3.983 std_deviation 2
TRANSACTIONAMOUNTUSD 54 004,902 std_deviation 2
DIGITALITEMCOUNT 7.238 std_deviation 2
PHYSICALITEMCOUNT 5.509 std_deviation 2

Pour voir un exemple de définition de composant de signal personnalisé et de code de calcul de métrique, consultez custom_signal dans le dépôt azureml-examples.

Une fois que vous avez répondu aux conditions d’utilisation des signaux et métriques personnalisés, vous pouvez configurer la surveillance des modèles avec la commande CLI et la définition YAML suivantes :

az ml schedule create -f ./custom-monitoring.yaml

Le YAML suivant contient la définition de la surveillance du modèle avec un signal personnalisé. Voici quelques points à noter concernant le code :

  • Nous partons du principe que vous avez déjà créé et inscrit votre composant avec la définition des signaux personnalisés dans Azure Machine Learning.
  • Le component_id du composant de signal personnalisé inscrit est azureml:my_custom_signal:1.0.0.
  • Si vous avez collecté vos données avec le collecteur de données, vous pouvez omettre la propriété pre_processing_component. Si vous souhaitez utiliser un composant de prétraitement pour prétraiter les données de production non collectées par le collecteur de données, vous pouvez le spécifier.
# custom-monitoring.yaml
$schema:  http://azureml/sdk-2-0/Schedule.json
name: my-custom-signal
trigger:
  type: recurrence
  frequency: day # can be minute, hour, day, week, month
  interval: 7 # #every day
create_monitor:
  compute:
    instance_type: "standard_e4s_v3"
    runtime_version: "3.3"
  monitoring_signals:
    customSignal:
      type: custom
      component_id: azureml:my_custom_signal:1.0.0
      input_data:
        production_data:
          input_data:
            type: uri_folder
            path: azureml:my_production_data:1
          data_context: test
          data_window:
            lookback_window_size: P30D
            lookback_window_offset: P7D
          pre_processing_component: azureml:custom_preprocessor:1.0.0
      metric_thresholds:
        - metric_name: std_deviation
          threshold: 2
  alert_notification:
    emails:
      - abc@example.com

Interpréter les résultats de la surveillance

Une fois que vous avez configuré votre moniteur de modèle et que la première exécution est terminée, vous pouvez revenir à l’onglet Surveillance dans Azure Machine Learning studio pour voir les résultats.

  • Dans la vue Surveillance principale, sélectionnez le nom de votre moniteur de modèle pour voir la page de vue d’ensemble du moniteur. Cette page montre le modèle, le point de terminaison et le déploiement correspondants, ainsi que des détails sur les signaux que vous avez configurés. L’image suivante montre un tableau de bord de surveillance qui englobe les signaux de dérive de données et de qualité de données. Selon les signaux de surveillance que vous avez configurés, votre tableau de bord peut être différent.

    Capture d’écran de la vue du tableau de bord de monitoring.

  • Regardez la section Notifications du tableau de bord pour voir, pour chaque signal, quelles caractéristiques ont dépassé le seuil configuré pour leurs métriques respectives :

  • Sélectionnez data_drift pour accéder à la page des détails de la dérive de données. Dans la page des détails, vous pouvez voir la valeur de métrique de la dérive de données pour chaque caractéristique numérique et catégorielle que vous avez incluse dans votre configuration de surveillance. Lorsque votre moniteur a plusieurs exécutions, vous verrez une courbe de tendance pour chaque caractéristique.

    Capture d’écran de la page d’informations sur le signal de dérive des données.

  • Pour voir en détail une caractéristique individuelle, sélectionnez le nom de la caractéristique pour voir la distribution de production par rapport à la distribution de référence. Cette vue vous permet également de suivre la dérive au fil du temps pour cette caractéristique en particulier.

    Capture d’écran des informations sur la dérive des données d’une caractéristique individuelle.

  • Revenez au tableau de bord de surveillance et sélectionnez data_quality pour voir la page du signal de qualité de données. Dans cette page, vous pouvez voir les taux de valeur nulle, les taux hors limites et les taux d’erreur de type de données pour chaque caractéristique que vous surveillez.

    Capture d’écran de la page d’informations sur le signal de qualité des données.

La surveillance des modèles est un processus continu. Avec la surveillance des modèles Azure Machine Learning, vous pouvez configurer plusieurs signaux de surveillance pour obtenir une vue générale des performances de vos modèles en production.

Intégrer la surveillance des modèles Azure Machine Learning à Azure Event Grid

Vous pouvez utiliser des événements générés par la surveillance des modèles Azure Machine Learning pour configurer des applications, des processus ou des workflows CI/CD pilotés par des événements avec Azure Event Grid. Vous pouvez consommer des événements via divers gestionnaires d’événements comme Azure Event Hubs, des fonctions Azure et des applications logiques. En fonction de la dérive détectée par vos moniteurs, vous pouvez prendre des mesures programmatiquement, par exemple en configurant un pipeline de machine learning pour réentraîner un modèle et le redéployer.

Pour commencer à intégrer la surveillance des modèles Azure Machine Learning à Event Grid :

  1. Suivez les étapes décrites dans Configurer dans le portail Azure. Attribuez un nom à votre abonnement aux événements, tel que MonitoringEvent, puis sélectionnez uniquement la zone État d’exécution modifié sous Types d’événements.

    Avertissement

    Veillez à sélectionner État d’exécution modifié pour le type d’événement. Ne sélectionnez pas Dérive de jeu de données détectée, car elle s’applique à la dérive de données v1 plutôt qu’à la surveillance des modèles Azure Machine Learning.

  2. Suivez les étapes dans Filtrer les événements et s’y abonner afin de configurer le filtrage des événements pour votre scénario. Accédez à l’onglet Filtres et ajoutez la Clé, l’Opérateur et la Valeur suivants sous Filtres avancés :

    • Clé : data.RunTags.azureml_modelmonitor_threshold_breached
    • Valeur : a échoué en raison d’une ou de plusieurs caractéristiques qui dépassent les seuils des métriques
    • Opérateur : chaîne contains

    Avec ce filtre, les événements sont générés lorsque l’état d’exécution change (de Terminé à Échec ou d’Échec à Terminé) pour tous les moniteurs de votre espace de travail Azure Machine Learning.

  3. Pour filtrer au niveau de la surveillance, utilisez la Clé, l’Opérateur et la Valeur suivants sous Filtres avancés :

    • Clé : data.RunTags.azureml_modelmonitor_threshold_breached
    • Valeur : your_monitor_name_signal_name
    • Opérateur : chaîne contains

    Vérifiez que your_monitor_name_signal_name est le nom d’un signal dans le moniteur spécifique pour lequel vous souhaitez filtrer les événements. Par exemple : credit_card_fraud_monitor_data_drift. Pour que ce filtre fonctionne, cette chaîne doit correspondre au nom de votre signal de surveillance. Nommez votre signal avec le nom du moniteur et le nom du signal pour le cas présent.

  4. Une fois que vous avez terminé la configuration de votre abonnement aux événements, sélectionnez le point de terminaison souhaité pour servir de gestionnaire d’événements tel qu’Azure Event Hubs.

  5. Une fois les événements capturés, vous pouvez les voir dans la page de point de terminaison :

    Capture d’écran des événements affichés à partir de la page du point de terminaison.

Vous pouvez également voir les événements sous l’onglet Métriques dans Azure Monitor :

Capture d’écran des événements affichés à partir de l’onglet des métriques du moniteur Azure.

Contenu connexe