Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Dérive d’attribution de caractéristiques pour les modèles en production Une dérive dans la distribution de données actives pour les modèles en production peut entraîner une dérive correspondante dans les valeurs d’attribution de caractéristiques, comme elle pourrait provoquer une dérive de biais lors de la surveillance des indicateurs de biais. La surveillance de l'attribution des fonctionnalités Amazon SageMaker Clarify aide les spécialistes des données et les ingénieurs du ML à surveiller régulièrement les prévisions relatives à la dérive de l'attribution des fonctionnalités. Lorsque le modèle est surveillé, les clients peuvent consulter des rapports et des graphiques exportables détaillant les attributions des fonctionnalités dans SageMaker Studio et configurer des alertes sur Amazon CloudWatch pour recevoir des notifications s'il est détecté que les valeurs d'attribution dépassent un certain seuil. Pour illustrer cela par une situation particulière, prenons le cas des admissions à l'université. Supposons que nous observons les valeurs d'attribution de fonctions (agrégées) suivantes dans les données d'entraînement et les données actives : Scénario hypothétique d'admission à l'université | Fonctionnalité | Attribution des données d'entraînement | Attribution des données actives | | --- | --- | --- | | Score SAT | 0,70 | 0.10 | | GPA | 0.50 | 0.20 | | Classement de classe | 0,05 | 0,70 | Le passage des données d'entraînement aux données actives semble significatif. Le classement des fonctions est complètement inversé. À l'instar de la dérive de biais, les dérives d'attribution de fonctions peuvent être causées par un changement dans la distribution des données actives et justifient un examen plus approfondi du comportement du modèle sur les données actives. Là encore, la première étape de ces scénarios consiste à signaler par une alarme qu'une dérive s'est produite. Nous pouvons détecter la dérive en comparant la façon dont le classement des fonctions individuelles est passé des données d'entraînement aux données actives. En plus de tenir compte des changements dans l'ordre de classement, nous devons également tenir compte du score d'attribution brut des fonctions. Par exemple, si deux fonctions entrent dans le classement par le même nombre de positions passant des données d'entraînement aux données actives, nous devons tenir compte de la fonction dont le score d'attribution était le plus élevé dans les données d'entraînement. En nous basant sur ces propriétés, nous utilisons le score NDCG (Normalized Discount Cumulative Gain) pour comparer le classement des attributions de fonctions des données d'entraînement et des données actives. Plus précisément, supposons le scénario suivant : + *F=[f1,...,fm]* est la liste des fonctions triées en fonction de leurs scores d'attribution dans les données d'entraînement, *m* représentant le nombre total de fonctions. Par exemple, dans notre cas, *F*=[Score SAT, GPA, Classement de classe]. + *a(f)* est une fonction qui renvoie le score d'attribution de fonction sur les données d'entraînement dans le cas d'une fonction *f*. Par exemple, *a*(Score SAT) = 0.70. + *F′=[f′1,...,f′m]* est la liste des fonctions triées en fonction de leurs scores d'attribution dans les données actives. Par exemple, *F*′=[Classement de classe, GPA, Score SAT]. Nous pouvons ensuite calculer le NDCG comme suit :         NDCG = DCG/IDCG avec + DCG = ∑1m*a*(*f'i*)/log2​(*i*\$11) + iDCG = ∑1m*a*(*fi*)/log2​(*i*\$11) La quantité DCG mesure si les fonctions ayant une attribution élevée dans les données d'entraînement occupent un rang également plus élevé dans l'attribution de fonctions calculée sur les données actives. La quantité iDCG mesure le *score idéal*. Il s'agit simplement d'un facteur de normalisation pour s'assurer que la quantité finale se situe dans la plage [0, 1], 1 désignant la meilleure valeur possible. Une valeur NDCG de 1 signifie que le classement d'attribution de fonctions dans les données actives est identique à celui des données d'entraînement. Dans cet exemple particulier, comme le classement a sensiblement changé, la valeur NDCG est de 0.69. Dans SageMaker Clarify, si la valeur NDCG est inférieure à 0,90, nous déclenchons automatiquement une alerte. ## Exemple de blocs-notes Model Monitor SageMaker Clarify fournit l'exemple de bloc-notes suivant qui montre comment capturer des données d'inférence pour un point de terminaison en temps réel, créer une base de référence pour surveiller l'évolution des biais et inspecter les résultats : + [Surveillance de la dérive des biais et de la dérive d'attribution des fonctionnalités Amazon SageMaker Clarify](https://sagemaker-examples.readthedocs.io/en/latest/sagemaker_model_monitor/fairness_and_explainability/SageMaker-Model-Monitor-Fairness-and-Explainability.html) — Utilisez Amazon SageMaker Model Monitor pour surveiller la dérive des biais et la dérive de l'attribution des fonctionnalités au fil du temps. Il a été vérifié que ce bloc-notes fonctionne uniquement dans SageMaker Studio. Si vous avez besoin d'instructions pour ouvrir un bloc-notes dans SageMaker Studio, consultez[Création ou ouverture d'un bloc-notes Amazon SageMaker Studio Classic](notebooks-create-open.md). Si vous êtes invité à choisir un noyau, choisissez **Python 3 (Science des données)**. Les rubriques suivantes contiennent les éléments principaux des deux dernières étapes, ainsi que des exemples de code tirés de l'exemple de bloc-notes. **Topics** + [Exemple de blocs-notes Model Monitor](#clarify-model-monitor-sample-notebooks-feature-drift) + [Créer une référence SHAP pour les modèles en production](clarify-model-monitor-shap-baseline.md) + [Violations de la dérive d'attribution de caractéristiques de modèle](clarify-model-monitor-model-attribution-drift-violations.md) + [Paramètres pour surveiller la dérive d’attribution](clarify-config-json-monitor-model-explainability-parameters.md) + [Programmer les tâches de surveillance de la dérive d’attribution des fonctions](clarify-model-monitor-feature-attribute-drift-schedule.md) + [Inspecter les rapports de dérive d’attribution des fonctions dans les modèles de production](clarify-feature-attribute-drift-report.md) + [CloudWatch Mesures pour l'analyse de la dérive des fonctionnalités](clarify-feature-attribute-drift-cw.md) # Créer une référence SHAP pour les modèles en production Les explications sont généralement contrastives. Autrement dit, elles tiennent compte des écarts par rapport à une référence. Pour plus d’informations sur les références d’explicabilité, consultez [Bases de référence SHAP pour l’explicabilité](clarify-feature-attribute-shap-baselines.md). En plus de fournir des explications pour les inférences par instance, SageMaker Clarify propose également une explication globale des modèles ML qui vous aide à comprendre le comportement d'un modèle dans son ensemble en termes de fonctionnalités. SageMaker Clarify génère une explication globale d'un modèle de machine learning en agrégeant les valeurs Shapley sur plusieurs instances. SageMaker Clarify prend en charge les différentes méthodes d'agrégation suivantes, que vous pouvez utiliser pour définir des lignes de base : + `mean_abs` - Moyenne des valeurs SHAP absolues pour toutes les instances. + `median` - Médiane des valeurs SHAP pour toutes les instances. + `mean_sq` : moyenne des valeurs SHAP au carré pour toutes les instances. Après avoir configuré votre application pour capturer des données d'inférence en temps réel ou de transformation par lots, la première tâche de surveillance de la dérive dans l'attribution de fonctions consiste à créer une référence qui servira de comparaison. Cela implique de configurer les entrées de données, les groupes sensibles, la capture des prédictions, ainsi que le modèle et ses métriques de biais post-entraînement. Ensuite, vous devez démarrer la tâche de baselining. Le moniteur d'explicabilité de modèle peut expliquer les prédictions d'un modèle déployé qui produit des inférences et détecter régulièrement la dérive d'attribution de fonctions. ``` model_explainability_monitor = ModelExplainabilityMonitor( role=role, sagemaker_session=sagemaker_session, max_runtime_in_seconds=1800, ) ``` Dans cet exemple, la tâche de baselining d'explicabilité partage le jeu de données de test avec la tâche de baselining de biais, il utilise donc la même `DataConfig`, la seule différence étant l'URI de sortie de la tâche. ``` model_explainability_baselining_job_result_uri = f"{baseline_results_uri}/model_explainability" model_explainability_data_config = DataConfig( s3_data_input_path=validation_dataset, s3_output_path=model_explainability_baselining_job_result_uri, label=label_header, headers=all_headers, dataset_type=dataset_type, ) ``` Actuellement, l' SageMaker explicateur Clarify propose une implémentation évolutive et efficace de SHAP. La configuration d'explicabilité est SHAPConfig donc la suivante : + `baseline` - Liste de lignes (au moins une) ou URI d'objet S3 à utiliser comme jeu de données de référence dans l'algorithme SHAP du noyau. Le format doit être identique au format du jeu de données. Chaque ligne doit contenir uniquement la fonctionnalité columns/values et omettre la colonne/les valeurs de l'étiquette. + `num_samples` : nombre d’échantillons à utiliser dans l’algorithme SHAP du noyau. Ce nombre détermine la taille du jeu de données synthétique généré pour calculer les valeurs SHAP. + agg\$1method - Méthode d'agrégation pour les valeurs SHAP globales. Voici les valeurs valides : + `mean_abs` - Moyenne des valeurs SHAP absolues pour toutes les instances. + `median` - Médiane des valeurs SHAP pour toutes les instances. + `mean_sq` - Moyenne des valeurs SHAP au carré pour toutes les instances. + `use_logit` - Indicateur signifiant si la fonction logit doit être appliquée aux prédictions du modèle. La valeur par défaut est `False`. Si `use_logit` est `True`, les valeurs SHAP auront des unités log-odds. + `save_local_shap_values` (bool) - Indicateur signifiant s'il faut enregistrer les valeurs SHAP locales à l'emplacement en sortie. La valeur par défaut est `False`. ``` # Here use the mean value of test dataset as SHAP baseline test_dataframe = pd.read_csv(test_dataset, header=None) shap_baseline = [list(test_dataframe.mean())] shap_config = SHAPConfig( baseline=shap_baseline, num_samples=100, agg_method="mean_abs", save_local_shap_values=False, ) ``` Démarrez une tâche de baselining. La `model_config` doit être la même, car la tâche de baselining d’explicabilité doit créer un point de terminaison fantôme pour obtenir des prédictions pour le jeu de données synthétiques généré. ``` model_explainability_monitor.suggest_baseline( data_config=model_explainability_data_config, model_config=model_config, explainability_config=shap_config, ) print(f"ModelExplainabilityMonitor baselining job: {model_explainability_monitor.latest_baselining_job_name}") ``` # Violations de la dérive d'attribution de caractéristiques de modèle Les tâches de dérive d'attribution de caractéristiques évaluent les contraintes de base fournies par la [configuration de base](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateModelExplainabilityJobDefinition.html#sagemaker-CreateModelExplainabilityJobDefinition-request-ModelExplainabilityBaselineConfig) par rapport aux résultats d'analyse du code `MonitoringExecution` actuel. Si des violations sont détectées, la tâche les répertorie dans le fichier *contraint\$1violations.json* à l'emplacement de la sortie d'exécution, et affecte le statut d'exécution [Interprétation des résultats](model-monitor-interpreting-results.md). Voici le schéma du fichier de violations de dérive d'attribution de caractéristiques. + `label` – Nom de l'étiquette, `label_headers` de configuration de l'analyse des tâches ou espace réservé tel que `"label0"`. + `metric_name` – Nom de la méthode d'analyse d'explicabilité. Actuellement, seul `shap` est pris en charge. + `constraint_check_type` : type de violation surveillée. Actuellement, seul `feature_attribution_drift_check` est pris en charge. + `description` : message descriptif visant à expliquer la violation. ``` { "version": "1.0", "violations": [{ "label": "string", "metric_name": "string", "constraint_check_type": "string", "description": "string" }] } ``` Pour chaque étiquette dans la section `explanations`, les tâches de surveillance calculent le [score NDCG](https://scikit-learn.org/stable/modules/generated/sklearn.metrics.ndcg_score.html) de ses valeurs SHAP globales dans le fichier de contraintes de base et dans le fichier des résultats d'analyse des tâches (*analysis.json*). Si le score est inférieur à 0,9, une violation est consignée. La valeur SHAP globale combinée est évaluée, si bien qu'il n'y a aucun champ `“feature”` dans l'entrée de violation. La sortie suivante fournit un exemple de plusieurs violations consignées. ``` { "version": "1.0", "violations": [{ "label": "label0", "metric_name": "shap", "constraint_check_type": "feature_attribution_drift_check", "description": "Feature attribution drift 0.7639720923277322 exceeds threshold 0.9" }, { "label": "label1", "metric_name": "shap", "constraint_check_type": "feature_attribution_drift_check", "description": "Feature attribution drift 0.7323763972092327 exceeds threshold 0.9" }] } ``` # Paramètres pour surveiller la dérive d’attribution Le moniteur d' SageMaker explicabilité Amazon Clarify réutilise un sous-ensemble des paramètres utilisés dans la configuration d'analyse de. [Fichiers de configuration d’analyse](clarify-processing-job-configure-analysis.md) Les paramètres suivants doivent être fournis dans un fichier JSON et le chemin d'accès doit être fourni dans le paramètre `ConfigUri` de [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ModelExplainabilityAppSpecification](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ModelExplainabilityAppSpecification). + `"version"` : (facultatif) version de schéma du fichier de configuration. Si elle n’est pas fournie, la dernière version prise en charge est utilisée. + `"headers"` – (Facultatif) Liste des noms de caractéristiques dans le jeu de données. L'analyse de l'explicabilité ne nécessite pas d'étiquettes. + `"methods"` – Liste des méthodes et de leurs paramètres pour les analyses et les rapports. Si une section est omise, elle n’est pas calculée. + `"shap"` – (Facultatif) Section sur le calcul de la valeur SHAP. + `"baseline"` – (Facultatif) Liste de lignes (au moins une) ou URI d'objet Amazon Simple Storage Service (Amazon S3). À utiliser comme jeu de données de référence (également appelé jeu de données d’arrière-plan) dans l’algorithme SHAP du noyau. Le format doit être identique au format du jeu de données. Chaque ligne doit contenir uniquement les colonnes (ou valeurs) de caractéristiques. Avant d'envoyer chaque ligne au modèle, omettez toute colonne qui doit être exclue. + `"num_samples"` : nombre d’échantillons à utiliser dans l’algorithme SHAP du noyau. Ce nombre détermine la taille du jeu de données synthétique généré pour calculer les valeurs SHAP. Si ce n'est pas le cas, une tâche SageMaker Clarify choisit la valeur en fonction du nombre de fonctionnalités. + `"agg_method"` : méthode d’agrégation pour les valeurs SHAP globales. Les valeurs valides sont les suivantes : + `"mean_abs"` - Moyenne des valeurs SHAP absolues pour toutes les instances. + `"median"` - Médiane des valeurs SHAP pour toutes les instances. + `"mean_sq"` : moyenne des valeurs SHAP au carré pour toutes les instances. + `"use_logit"` – (Facultatif) Valeur booléenne pour indiquer si la fonction logit doit être appliquée aux prédictions du modèle. Si `"use_logit"` est `true`, alors les valeurs SHAP ont des unités log-odds. La valeur par défaut est `false`. + `"save_local_shap_values"` : (facultatif) valeur booléenne pour indiquer si les valeurs SHAP locales doivent être enregistrées à l’emplacement en sortie. Utilisez `true` pour les enregistrer. Utilisez `false` pour ne pas les enregistrer. La valeur par défaut est `false`. + `"predictor"` : (Facultatif pour le point de terminaison en temps réel, obligatoire pour la transformation par lots) Section sur les paramètres du modèle, requise si les sections `"shap"` et `"post_training_bias"` sont présentes. + `"model_name"` : nom de modèle (tel que créé par l’API `CreateModel` avec le mode conteneur en tant que `SingleModel`). + `"instance_type"` – Type d'instance pour le point de terminaison fantôme. + `"initial_instance_count"` - Nombre d'instances pour le point de terminaison fantôme. + `"content_type"` – (Facultatif) Format d'entrée de modèle à utiliser pour obtenir des inférences avec le point de terminaison fantôme. Les valeurs valides sont `"text/csv"` pour CSV, `"application/jsonlines"` pour JSON Lines, `application/x-parquet` pour Apache Parquet, et `application/x-image` pour activer l'explicabilité de la reconnaissance d'image. La valeur par défaut est identique au format `dataset_type`. + `"accept_type"` – (Facultatif) Modèle *output (sortie)* à utiliser pour obtenir des inférences avec le point de terminaison fantôme. Les valeurs valides sont `"text/csv"` pour CSV et `"application/jsonlines"` pour JSON Lines. En cas d'omission, SageMaker Clarify utilise le type de données de réponse des données capturées. + `"content_template"` : (facultatif) chaîne de modèle utilisée pour créer l’entrée de modèle à partir d’instances du jeu de données. Elle est utilisée uniquement si `"content_type"` est `"application/jsonlines"`. Le modèle doit avoir un seul espace réservé, `$features`, qui est remplacé par la liste des fonctions lors de l’exécution. Par exemple, étant donné `"content_template":"{\"myfeatures\":$features}"`, si une instance (sans étiquette) est `1,2,3`, l'entrée du modèle devient JSON Lines `'{"myfeatures":[1,2,3]}'`. + `"label_headers"` – (Facultatif) Liste des valeurs que la `"label"` prend dans le jeu de données. Associe les scores renvoyés par le point de terminaison ou la tâche de transformation par lots du modèle à leurs valeurs d'étiquette correspondantes. S’il est fourni, le rapport d’analyse utilise les en-têtes à la place d’espaces réservés tels que `“label0”`. Les autres paramètres doivent être fournis dans `EndpointInput` (pour les points de terminaison en temps réel) ou `BatchTransformInput` (pour les tâches de transformation par lots) de l'API [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ModelExplainabilityJobInput](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ModelExplainabilityJobInput). + `FeaturesAttribute` : ce paramètre est requis si le format des données d'entrée du point de terminaison ou la tâche par lots est `"application/jsonlines"`. Il est JMESPath utilisé pour localiser les colonnes d'entités si le format du jeu de données est JSON Lines. + `ProbabilityAttribute`— Indice ou JMESPath emplacement dans la sortie du modèle pour les probabilités. Si la sortie du modèle est JSON Lines avec une liste d’étiquettes et de probabilités, par exemple, l’étiquette qui correspond à la probabilité maximale est alors sélectionnée pour les calculs de biais. ## Exemples de fichiers de configuration JSON pour les jeux de données CSV et JSON Lines Voici des exemples des fichiers JSON utilisés pour configurer les jeux de données CSV et JSON Lines afin de les surveiller pour détecter une dérive d'attribution de caractéristiques. **Topics** + [Jeux de données CSV](#clarify-config-json-monitor-model-explainability-parameters-example-csv) + [Jeux de données JSON Lines](#clarify-config-json-monitor-model-explainability-parameters-example-jsonlines) ### Jeux de données CSV Considérons un jeu de données comportant trois colonnes de caractéristiques numériques, comme dans l'exemple suivant. ``` 0.5814568701544718, 0.6651538910132964, 0.3138080342665499 0.6711642728531724, 0.7466687034026017, 0.1215477472819713 0.0453256543003371, 0.6377430803264152, 0.3558625219713576 0.4785191813363956, 0.0265841045263860, 0.0376935084990697 ``` Supposons que la sortie du modèle comporte deux colonnes, la première correspondant à l'étiquette prédite et la seconde à la probabilité, comme dans l'exemple suivant. ``` 1, 0.5385257417814224 ``` L'exemple de fichier de configuration JSON suivant montre comment ce jeu de données CSV peut être configuré. ``` { "headers": [ "feature_1", "feature_2", "feature_3" ], "methods": { "shap": { "baseline": [ [0.4441164946610942, 0.5190374448171748, 0.20722795300473712] ], "num_samples": 100, "agg_method": "mean_abs" } }, "predictor": { "model_name": "my_model", "instance_type": "ml.m5.xlarge", "initial_instance_count": 1 } } ``` L'étiquette prédite est sélectionnée par le paramètre `"ProbabilityAttribute"`. La numérotation basée sur zéro est utilisée, donc 1 indique la deuxième colonne de la sortie du modèle. ``` "EndpointInput": { ... "ProbabilityAttribute": 1 ... } ``` ### Jeux de données JSON Lines Considérez un jeu de données comportant quatre colonnes de caractéristiques et une colonne d'étiquettes, où la première caractéristique et l'étiquette sont binaires, comme dans l'exemple suivant. ``` {"features":[0, 0.5814568701544718, 0.6651538910132964, 0.3138080342665499], "label":0} {"features":[1, 0.6711642728531724, 0.7466687034026017, 0.1215477472819713], "label":1} {"features":[0, 0.0453256543003371, 0.6377430803264152, 0.3558625219713576], "label":1} {"features":[1, 0.4785191813363956, 0.0265841045263860, 0.0376935084990697], "label":1} ``` L'entrée du modèle est identique au format du jeu de données, et la sortie du modèle est JSON Lines, comme dans l'exemple suivant. ``` {"predicted_label":1, "probability":0.5385257417814224} ``` Dans l’exemple suivant, le fichier de configuration JSON montre comment ce jeu de données JSON Lines peut être configuré. ``` { "headers": [ "feature_1", "feature_2", "feature_3" ], "methods": { "shap": { "baseline": [ {"features":[0.4441164946610942, 0.5190374448171748, 0.20722795300473712]} ], "num_samples": 100, "agg_method": "mean_abs" } }, "predictor": { "model_name": "my_model", "instance_type": "ml.m5.xlarge", "initial_instance_count": 1, "content_template":"{\"features\":$features}" } } ``` Ensuite, la valeur de paramètre `"features"` dans `EndpointInput` (pour les points de terminaison en temps réel) ou `BatchTransformInput` (pour les tâches de transformation par lots) est utilisée pour localiser les caractéristiques dans le jeu de données, et la valeur de paramètre `"probability"` sélectionne la valeur de probabilité à partir de la sortie du modèle. ``` "EndpointInput": { ... "FeaturesAttribute": "features", "ProbabilityAttribute": "probability", ... } ``` # Programmer les tâches de surveillance de la dérive d’attribution des fonctions Après avoir créé votre référence SHAP, vous pouvez appeler la méthode `create_monitoring_schedule()` de votre instance de classe `ModelExplainabilityMonitor` pour planifier une surveillance horaire de l’explicabilité des modèles. Les sections suivantes expliquent comment créer une surveillance de l’explicabilité des modèles pour un modèle déployé sur un point de terminaison en temps réel ainsi que pour une tâche de transformation par lots. **Important** Vous pouvez spécifier une entrée de transformation par lots ou une entrée de point de terminaison, mais pas les deux, lorsque vous créez votre planification de surveillance. Si une tâche de baselining a été envoyée, le moniteur récupère automatiquement la configuration d’analyse à partir de la tâche de baselining. Toutefois, si vous ignorez l'étape de baselining ou si la nature du jeu de données de capture est différente de celle du jeu de données d'entraînement, vous devez fournir la configuration d'analyse. `ExplainabilityAnalysisConfig` a besoin de `ModelConfig` pour les mêmes raisons que la tâche de baselining. Comme le calcul de l'attribution de fonctions a seulement besoin de fonctions, vous devez exclure l'étiquetage Ground Truth. ## Surveillance de la dérive d'attribution des fonctions pour les modèles déployés sur des points de terminaison en temps réel Pour planifier une surveillance de l'explicabilité des modèles pour un point de terminaison en temps réel, transmettez votre instance `EndpointInput` à l'argument `endpoint_input` de votre instance `ModelExplainabilityMonitor`, comme indiqué dans l'exemple de code suivant : ``` from sagemaker.model_monitor import CronExpressionGenerator model_exp_model_monitor = ModelExplainabilityMonitor( role=sagemaker.get_execution_role(), ... ) schedule = model_exp_model_monitor.create_monitoring_schedule( monitor_schedule_name=schedule_name, post_analytics_processor_script=s3_code_postprocessor_uri, output_s3_uri=s3_report_path, statistics=model_exp_model_monitor.baseline_statistics(), constraints=model_exp_model_monitor.suggested_constraints(), schedule_cron_expression=CronExpressionGenerator.hourly(), enable_cloudwatch_metrics=True, endpoint_input=EndpointInput( endpoint_name=endpoint_name, destination="/opt/ml/processing/input/endpoint", ) ) ``` ## Surveillance de la dérive d'attribution des fonctions pour les tâches de transformation par lots Pour planifier une surveillance de l'explicabilité des modèles pour une tâche de transformation par lots, transmettez votre instance `BatchTransformInput` à l'argument `batch_transform_input` de votre instance `ModelExplainabilityMonitor`, comme indiqué dans l'exemple de code suivant : ``` from sagemaker.model_monitor import CronExpressionGenerator model_exp_model_monitor = ModelExplainabilityMonitor( role=sagemaker.get_execution_role(), ... ) schedule = model_exp_model_monitor.create_monitoring_schedule( monitor_schedule_name=schedule_name, post_analytics_processor_script=s3_code_postprocessor_uri, output_s3_uri=s3_report_path, statistics=model_exp_model_monitor.baseline_statistics(), constraints=model_exp_model_monitor.suggested_constraints(), schedule_cron_expression=CronExpressionGenerator.hourly(), enable_cloudwatch_metrics=True, batch_transform_input=BatchTransformInput( destination="opt/ml/processing/data", model_name="batch-fraud-detection-model", input_manifests_s3_uri="s3://amzn-s3-demo-bucket/batch-fraud-detection/on-schedule-monitoring/in/", excludeFeatures="0", ) ) ``` # Inspecter les rapports de dérive d’attribution des fonctions dans les modèles de production Une fois que le programme que vous avez configuré a démarré par défaut, vous devez attendre que sa première exécution démarre, puis l’arrêter pour éviter d’encourir des frais. Pour inspecter les rapports, utilisez le code suivant : ``` schedule_desc = model_explainability_monitor.describe_schedule() execution_summary = schedule_desc.get("LastMonitoringExecutionSummary") if execution_summary and execution_summary["MonitoringExecutionStatus"] in ["Completed", "CompletedWithViolations"]: last_model_explainability_monitor_execution = model_explainability_monitor.list_executions()[-1] last_model_explainability_monitor_execution_report_uri = last_model_explainability_monitor_execution.output.destination print(f'Report URI: {last_model_explainability_monitor_execution_report_uri}') last_model_explainability_monitor_execution_report_files = sorted(S3Downloader.list(last_model_explainability_monitor_execution_report_uri)) print("Found Report Files:") print("\n ".join(last_model_explainability_monitor_execution_report_files)) else: last_model_explainability_monitor_execution = None print("====STOP==== \n No completed executions to inspect further. Please wait till an execution completes or investigate previously reported failures.") ``` En cas de violations par rapport à la référence, celles-ci sont répertoriées ici : ``` if last_model_explainability_monitor_execution: model_explainability_violations = last_model_explainability_monitor_execution.constraint_violations() if model_explainability_violations: print(model_explainability_violations.body_dict) ``` Si votre modèle est déployé sur un point de terminaison en temps réel, vous pouvez visualiser dans SageMaker Studio les résultats d'analyse et les CloudWatch mesures en choisissant l'onglet **Points de terminaison**, puis en double-cliquant sur le point de terminaison. # CloudWatch Mesures pour l'analyse de la dérive des fonctionnalités Ce guide présente CloudWatch les métriques et leurs propriétés que vous pouvez utiliser pour l'analyse de la dérive des attributs d'entités dans SageMaker Clarify. Les tâches de surveillance de dérive des attributs d'entités calculent et publient deux types de mesures : + La valeur SHAP globale de chaque entité. **Note** Le nom de cette métrique ajoute le nom de la fonctionnalité fourni par la configuration de l'analyse des tâches à `feature_`. Par exemple,`feature_X` est la valeur SHAP globale de la fonctionnalité `X`. + Nom de la métrique `ExpectedValue`. Ces métriques sont publiées dans l'espace de CloudWatch noms suivant : + Pour les points de terminaison en temps réel : `aws/sagemaker/Endpoints/explainability-metrics` + Pour les tâches de transformation par lots : `aws/sagemaker/ModelMonitoring/explainability-metrics` Chaque métrique comporte les propriétés suivantes : + `Endpoint` : le nom du point de terminaison surveillé, le cas échéant. + `MonitoringSchedule` : le nom du référencement pour la tâche de surveillance. + `ExplainabilityMethod` : la méthode utilisée pour calculer les valeurs de Shapley. Sélectionnez `KernelShap`. + `Label` : le nom fourni par la configuration de l'analyse des tâches `label_headers`, ou un espace réservé comme `label0`. + `ValueType` : le type de valeur renvoyée par la métrique. Choisissez `GlobalShapValues` ou `ExpectedValue`. Pour empêcher les tâches de surveillance de publier des métriques, définissez `publish_cloudwatch_metrics` sur `Disabled` dans la `Environment`carte de définition du [modèle d’explicabilité de tâche](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateModelExplainabilityJobDefinition.html).