Événements
Créer des applications intelligentes
17 mars, 21 h - 21 mars, 10 h
Rejoignez la série de rencontres pour créer des solutions IA évolutives basées sur des cas d’usage réels avec d’autres développeurs et experts.
S’inscrire maintenantCe navigateur n’est plus pris en charge.
Effectuez une mise à niveau vers Microsoft Edge pour tirer parti des dernières fonctionnalités, des mises à jour de sécurité et du support technique.
Important
À partir du 20 septembre 2023, vous ne pourrez plus créer de ressources Détecteur d’anomalies. Le service Détecteur d’anomalies sera mis hors service le 1er octobre 2026.
Cet article fournit une aide autour des pratiques recommandées pour l’utilisation des API Détecteur d’anomalies multivarié (MVAD, Multivariate Anomaly Detector). Dans ce didacticiel, vous allez :
Suivez les instructions de cette section pour éviter les erreurs lorsque vous utilisez MVAD. Si vous recevez toujours des erreurs, consultez la liste complète des codes d’erreur pour obtenir des explications et savoir quelles mesures prendre.
Ces trois paramètres sont nécessaires dans les requêtes d’API d’entraînement et d’inférence :
source
: lien vers votre fichier zip situé dans Stockage Blob Azure avec signatures d’accès partagé (SAS).startTime
: heure de début des données utilisées pour l’entraînement ou l’inférence. Si elle est antérieure à l’horodatage réel le plus ancien dans les données, l’horodatage réel le plus ancien sera utilisé comme point de départ.endTime
: heure de fin des données utilisées pour l’entraînement ou l’inférence, qui doit être postérieure ou égale à startTime
. Si endTime
est postérieur à l’horodatage réel le plus récent dans les données, l’horodatage réel le plus récent sera utilisé comme point de fin. Si endTime
est égal à startTime
, cela signifie qu’il s’agit de l’inférence d’un point de données unique, qui est souvent utilisée dans les scénarios de streaming.Les autres paramètres de l’API d’entraînement sont facultatifs :
slidingWindow
: nombre de points de données utilisés pour déterminer les anomalies. Entier compris entre 28 et 2880. La valeur par défaut est 300. Si slidingWindow
est k
pour l’entraînement du modèle, au moins k
points doivent être accessibles à partir du fichier source pendant l’inférence pour obtenir des résultats valides.
La détection d'anomalie multivariée prend un segment de points de données pour décider si le point de données suivant est une anomalie. La longueur du segment est slidingWindow
.
Gardez deux choses à l’esprit lorsque vous choisissez une valeur slidingWindow
:
slidingWindow
. Lorsque vos données sont à fréquence élevée (haute précision), par exemple au niveau de la minute ou de la seconde, vous pouvez affecter une valeur supérieure à slidingWindow
.slidingWindow
peut provoquer un temps d’entraînement/d’inférence plus long. Il n’existe aucune garantie qu’une valeur plus élevée de slidingWindow
engendrera un gain de précision. Une slidingWindow
peu élevée risque de rendre le modèle difficile à converger vers une solution optimale. Par exemple, il est difficile de détecter des anomalies lorsque slidingWindow
ne compte que deux points.
alignMode
: comment aligner plusieurs variables (série chronologique) sur des horodatages. Il existe deux options pour ce paramètre : Inner
et Outer
. La valeur par défaut est Outer
.
Ce paramètre est essentiel lorsqu’il y a un mauvais alignement entre les séquences d’horodatage des variables. Le modèle doit aligner les variables sur la même séquence d’horodatage avant tout traitement ultérieur.
Inner
signifie que le modèle doit signaler les résultats de la détection uniquement sur les horodatages sur lesquels chaque variable a une valeur, c’est-à-dire l’intersection de toutes les variables.
Outer
signifie que le modèle doit signaler les résultats de la détection sur les horodatages sur lesquels une variable quelconque a une valeur, c’est-à-dire l’union de toutes les variables.
Voici un exemple illustrant différentes valeurs de alignModel
.
Variable-1
timestamp | value |
---|---|
2020-11-01 | 1 |
2020-11-02 | 2 |
2020-11-04 | 4 |
05-11-2020 | 5 |
Variable-2
timestamp | value |
---|---|
2020-11-01 | 1 |
2020-11-02 | 2 |
2020-11-03 | 3 |
2020-11-04 | 4 |
Jointure Inner
de deux variables
timestamp | Variable-1 | Variable-2 |
---|---|---|
2020-11-01 | 1 | 1 |
2020-11-02 | 2 | 2 |
2020-11-04 | 4 | 4 |
Jointure Outer
de deux variables
timestamp | Variable-1 | Variable-2 |
---|---|---|
2020-11-01 | 1 | 1 |
2020-11-02 | 2 | 2 |
2020-11-03 | nan |
3 |
2020-11-04 | 4 | 4 |
05-11-2020 | 5 | nan |
fillNAMethod
: comment renseigner nan
dans la table fusionnée. Il peut y avoir des valeurs manquantes dans la table fusionnée, et elles doivent être gérées correctement. Nous fournissons plusieurs méthodes pour les renseigner. Les options sont Linear
, Previous
, Subsequent
, Zero
et Fixed
, et la valeur par défaut est Linear
.
Option | Méthode |
---|---|
Linear |
Renseigner les valeurs nan par interpolation linéaire |
Previous |
Propager la dernière valeur valide pour remplir les vides. Exemple : [1, 2, nan, 3, nan, 4] ->[1, 2, 2, 3, 3, 4] |
Subsequent |
Utiliser la valeur valide suivante pour remplir les vides. Exemple : [1, 2, nan, 3, nan, 4] ->[1, 2, 3, 3, 4, 4] |
Zero |
Renseigner les valeurs nan avec 0. |
Fixed |
Renseigner les valeurs nan avec une valeur valide spécifiée qui doit être fournie dans paddingValue . |
paddingValue
: la valeur de remplissage est utilisée pour renseigner nan
lorsque fillNAMethod
est Fixed
et doit être fournie dans ce cas. Dans les autres cas, elle est facultative.
displayName
: il s’agit d’un paramètre facultatif servant à identifier des modèles. Vous pouvez par exemple l’utiliser pour marquer des paramètres, des sources de données et toute autre métadonnée relative au modèle et à ses données d’entrée. La valeur par défaut est une chaîne vide.
MVAD détecte les anomalies à partir d’un groupe de métriques. Nous appelons chaque métrique variable ou série chronologique.
Vous pouvez télécharger l’exemple de fichier de données de Microsoft pour vérifier le schéma accepté à partir de : https://aka.ms/AnomalyDetector/MVADSampleData
Chaque variable doit avoir deux champs, et seulement deux, timestamp
et value
. Elle doit être stockée dans un fichier de valeurs séparées par des virgules (CSV).
Les noms des colonnes du fichier CSV doivent être exactement timestamp
et value
, et sont sensibles à la casse.
Les valeurs timestamp
doivent être conformes à la norme ISO 8601. La colonne value
peut contenir des entiers ou des nombres décimaux avec n’importe quel nombre de décimales.
Voici un bon exemple du contenu d’un fichier CSV :
timestamp | value |
---|---|
2019-04-01T00:00:00Z | 5 |
2019-04-01T00:01:00Z | 3.6 |
2019-04-01T00:02:00Z | 4 |
... | ... |
Notes
Si vos horodateurs contiennent des heures, des minutes et/ou des secondes, assurez-vous qu’ils sont correctement arrondis à la valeur supérieure avant d’appeler les API.
Par exemple, si votre fréquence de données est censée être un point de données toutes les 30 secondes, mais que vous voyez des horodateurs comme « 12:00:01 » et « 12:00:28 », il s’agit d’un signal fort que vous devez effectuer le prétraitement des horodateurs pour obtenir de nouvelles valeurs comme « 12:00:00 » et « 12:00:30 ».
Pour plus d’informations, reportez-vous à la section « Arrondir les horodateurs à la valeur supérieure » dans le document sur les meilleures pratiques.
Le nom du fichier CSV est utilisé comme nom de la variable et doit être unique. Par exemple, « température.csv » et « humidité.csv ».
Les variables pour l’apprentissage et les variables pour l’inférence doivent être cohérentes. Par exemple, si vous utilisez series_1
, series_2
, series_3
, series_4
et series_5
pour l’apprentissage, vous devez fournir exactement les mêmes variables pour l’inférence.
Les fichiers CSV doivent être compressés dans un fichier zip et chargés sur un conteneur d’objets blob Azure. Le fichier zip peut porter le nom de votre choix.
Une erreur courante dans la préparation des données est l’ajout de dossiers supplémentaires dans le fichier zip. Imaginons par exemple que le nom du fichier zip est series.zip
. Après avoir décompressé les fichiers dans un nouveau dossier ./series
, le chemin correct d’accès aux fichiers CSV est ./series/series_1.csv
. Un chemin incorrect pourrait être ./series/foo/bar/series_1.csv
.
Exemple correct de l’arborescence de répertoires après avoir décompressé le fichier zip dans Windows
.
└── series
├── series_1.csv
├── series_2.csv
├── series_3.csv
├── series_4.csv
└── series_5.csv
Exemple incorrect de l’arborescence de répertoires après avoir décompressé le fichier zip dans Windows
.
└── series
└── series
├── series_1.csv
├── series_2.csv
├── series_3.csv
├── series_4.csv
└── series_5.csv
Vous pouvez maintenant exécuter votre code avec les API MVAD sans aucune erreur. Que pouvez-vous faire pour améliorer l’exactitude de votre modèle ?
Le modèle sous-jacent de MVAD possède des millions de paramètres. Il a besoin d’un volume minimal de points de données pour apprendre un ensemble optimal de paramètres. La règle empirique est qu’il faut fournir au moins 5 000 points de données (horodateurs) par variable pour entraîner le modèle avec une bonne justesse. En général, plus il y a de données d’apprentissage, meilleure est l’exactitude. Si vous n’êtes pas en mesure d’accumuler autant de données, nous vous encourageons à effectuer quand même des essais pour voir si la précision compromise reste acceptable.
Chaque fois que vous appelez l’API d’inférence, vous devez vous assurer que le fichier de données source contient le bon volume de points de données. Ce volume s’élève généralement à slidingWindow
+ le nombre de points de données qui ont vraiment besoin des résultats de l’inférence. Prenons par exemple un cas de diffusion en continu : chaque fois que vous souhaitez effectuer une inférence sur UN nouvel horodateur, le fichier de données peut contenir uniquement la fenêtre slidingWindow
de début + UN point de données. Vous pouvez alors créer un autre fichier zip comportant le même nombre de points de données (slidingWindow
+ 1), mais en vous décalant d’UN pas vers le côté « droit », et l’envoyer pour une autre tâche d’inférence.
Les points situés au-delà ou « avant » la fenêtre glissante de début n’ont aucun impact sur le résultat de l’inférence. Les seules conséquences possibles sont une dégradation des performances. Les points situés au-dessous risquent d’entraîner une erreur NotEnoughInput
.
Dans un groupe de variables (séries chronologiques), chacune peut être collectée à partir d’une source indépendante. Dans certains cas, les horodateurs de différentes variables présentent des incohérences les uns avec les autres et avec les fréquences connues. Voici un exemple simple.
Variable-1
timestamp | value |
---|---|
12:00:01 | 1.0 |
12:00:35 | 1.5 |
12:01:02 | 0.9 |
12:01:31 | 2.2 |
12:02:08 | 1.3 |
Variable-2
timestamp | value |
---|---|
12:00:03 | 2.2 |
12:00:37 | 2.6 |
12:01:09 | 1.4 |
12:01:34 | 1.7 |
12:02:04 | 2.0 |
Deux variables sont collectées à partir de deux capteurs qui envoient un point de données toutes les 30 secondes. Cependant, les capteurs n’envoient pas les points de données à une fréquence strictement égale, mais parfois plus tôt, parfois plus tard. Étant donné que MVAD prend en compte les corrélations entre différentes variables, les horodateurs doivent être bien alignés pour que les métriques puissent refléter correctement l’état du système. Dans l’exemple ci-dessus, les horodateurs des variables 1 et 2 doivent être correctement « arrondis » à leur fréquence avant alignement.
Voyons ce qui se passe s’ils ne sont pas prétraités. Si nous définissons alignMode
sur Outer
(ce qui correspond à l’union de deux ensembles), nous obtenons la table fusionnée suivante :
timestamp | Variable-1 | Variable-2 |
---|---|---|
12:00:01 | 1.0 | nan |
12:00:03 | nan |
2.2 |
12:00:35 | 1.5 | nan |
12:00:37 | nan |
2.6 |
12:01:02 | 0.9 | nan |
12:01:09 | nan |
1.4 |
12:01:31 | 2.2 | nan |
12:01:34 | nan |
1.7 |
12:02:04 | nan |
2.0 |
12:02:08 | 1.3 | nan |
nan
indique des valeurs manquantes. De toute évidence, la table fusionnée ne correspond pas aux attentes. Les variables 1 et 2 s’imbriquent, et le modèle MVAD ne peut pas extraire d’informations sur leurs corrélations. Si nous définissons alignMode
sur Inner
, la table fusionnée est vide, car il n’existe aucun horodateur commun dans les variables 1 et 2.
Par conséquent, les horodateurs des variables 1 et 2 doivent être prétraités (arrondis aux 30 secondes les plus proches), et les nouvelles séries chronologiques sont les suivantes :
Variable-1
timestamp | value |
---|---|
12:00:00 | 1.0 |
12:00:30 | 1.5 |
12:01:00 | 0.9 |
12:01:30 | 2.2 |
12:02:00 | 1.3 |
Variable-2
timestamp | value |
---|---|
12:00:00 | 2.2 |
12:00:30 | 2.6 |
12:01:00 | 1.4 |
12:01:30 | 1.7 |
12:02:00 | 2.0 |
La table fusionnée est maintenant plus raisonnable.
timestamp | Variable-1 | Variable-2 |
---|---|---|
12:00:00 | 1.0 | 2.2 |
12:00:30 | 1.5 | 2.6 |
12:01:00 | 0.9 | 1.4 |
12:01:30 | 2.2 | 1.7 |
12:02:00 | 1.3 | 2.0 |
Les valeurs de variables différentes présentant des horodateurs proches sont bien alignées. Le modèle MVAD peut maintenant extraire les informations de corrélation.
Les API d’entraînement et d’inférence présentent toutes deux des limites dont vous devez avoir conscience pour éviter les erreurs.
per_second
.Nous avons des informations sur la gravité qui indique l’importance des anomalies. Les faux positifs peuvent être filtrés en définissant un seuil de gravité. Parfois, les faux positifs peuvent apparaître en trop grand nombre quand il existe des changements de modèle dans les données d’inférence. Dans ce cas, un modèle peut avoir besoin d’être réentraîné avec de nouvelles données. Si les données d’entraînement comportent trop d’anomalies, il se peut que les résultats de détection contiennent des faux négatifs. Cela est dû au fait que le modèle apprend des patterns des données d’entraînement et que les anomalies peuvent biaiser le modèle. Ainsi, un nettoyage approprié des données peut contribuer à réduire les faux négatifs.
En règle générale, il est difficile d’identifier le meilleur modèle sans un jeu de données étiqueté. Cependant, nous pouvons tirer parti des pertes d’entraînement et de validation pour se faire une idée approximative et écarter les mauvais modèles. Dans un premier temps, nous devons vérifier s’il existe une convergence entre les pertes d’entraînement. Les pertes divergentes indiquent souvent une mauvaise qualité de modèle. En second lieu, les valeurs de perte peuvent aider à déterminer s’il y a sous-ajustement ou surajustement. Les modèles qui sont en sous-ajustement ou surajustement peuvent ne pas offrir le niveau de performance souhaité. En troisième lieu, même si la définition de la fonction de perte n’est pas directement révélatrice des performances de détection, les valeurs de perte peuvent être un outil auxiliaire pour estimer la qualité d’un modèle. Un bon modèle se caractérise nécessairement par une faible valeur de perte. Nous pouvons donc écarter les modèles ayant une valeur de perte élevée.
En dehors de la table des codes d’erreur, nous avons appris auprès de clients quelques pièges courants liés à l’utilisation des API MVAD. Ce tableau vous aidera à éviter ces problèmes.
Piège | Conséquence | Explication et solution |
---|---|---|
Les horodateurs dans les données d’entraînement et/ou d’inférence n’étaient pas arrondis pour s’aligner sur la fréquence de données respective de chaque variable. | Les horodateurs des résultats de l’inférence ne correspondent pas aux attentes : ils sont trop ou pas assez nombreux. | Consultez Arrondi des horodateurs. |
Trop de points de données anormaux dans les données d’apprentissage | L’exactitude du modèle est affectée, car il traite les points de données anormaux comme des modèles normaux pendant l’apprentissage. | De manière empirique, il est utile de maintenir un taux anormal inférieur ou égal à 1 % . |
Trop peu de données d’apprentissage | L’exactitude du modèle est compromise. | De manière empirique, l’apprentissage d’un modèle MVAD exige au moins 15 000 points de données (horodateurs) par variable pour garantir une bonne exactitude. |
Tous les points de données pour lesquels isAnomaly =true pris comme des anomalies |
Le nombre de faux positifs est trop élevé. | Utilisez isAnomaly et severity (ou score ) pour filtrer les anomalies qui ne sont pas graves et (éventuellement) le regroupement pour vérifier la durée des anomalies en vue de supprimer les bruits aléatoires. Consultez la section FAQ ci-dessous pour connaître la différence entre severity et score . |
Sous-dossiers compressés dans le fichier de données à des fins d’apprentissage ou d’inférence | Les fichiers de données CSV situés dans les sous-dossiers sont ignorés au cours de l’apprentissage et de l’inférence. | Aucun sous-dossier n’est autorisé dans le fichier zip. Pour plus d’informations, consultez Structure des dossiers. |
Trop de données dans le fichier de données d’inférence (par exemple compression de toutes les données historiques dans le fichier zip des données d’inférence) | Il ne se produit pas forcément d’erreurs. En revanche, une dégradation des performances est observée au moment de télécharger le fichier zip vers l’objet Blob Azure ou d’exécuter l’inférence. | Pour plus d’informations, consultez Quantité de données. |
Création de ressources Détecteur d’anomalies sur des régions Azure qui ne prennent pas encore en charge MVAD et appel des API MVAD | Vous obtenez une erreur de type « ressource introuvable » en appelant les API MVAD. | Pendant la phase de préversion, MVAD n’est disponible que dans certaines régions. Veuillez créer un signet Nouveautés du Détecteur d’anomalies pour rester informé des déploiements de régions MVAD. Vous pouvez également signaler un problème GitHub ou nous contacter à l’adresse AnomalyDetector@microsoft.com pour demander l’ajout de régions spécifiques. |
Prenons deux exemples pour découvrir comment fonctionne la fenêtre glissante de MVAD. Supposons que slidingWindow
= 1 440 et que les données d’entrée présentent une granularité d’une minute.
Scénario de diffusion en continu : vous souhaitez prédire si LE point de données situé à « 2021-01-02T00:00:00Z » est anormal.
startTime
et endTime
possèdent la même valeur (« 2021-01-02T00:00:00Z »). Votre source de données d’inférence, toutefois, doit contenir au moins 1 440 + 1 horodateurs. En effet, MVAD prend les données de début avant le point de données cible (« 2021-01-02T00:00:00Z ») pour déterminer si la cible constitue une anomalie. La longueur des données de début nécessaires est slidingWindow
, soit 1 440 dans ce cas. Or, 1 440 = 60 × 24. Les données d’entrée doivent donc commencer à « 2021-01-01T00:00:00Z » au plus tard.
Scénario de traitement par lots : vous avez plusieurs points de données cibles à prédire.
endTime
est supérieur à startTime
. Dans ce cas, l’inférence est effectuée en mode « fenêtre mobile ». Par exemple, MVAD utilise les données de 2021-01-01T00:00:00Z
à 2021-01-01T23:59:00Z
(inclus) pour déterminer si les données situées à 2021-01-02T00:00:00Z
sont anormales. Il passe ensuite aux données de 2021-01-01T00:01:00Z
à 2021-01-02T00:00:00Z
(inclus) pour déterminer si les données situées à 2021-01-02T00:01:00Z
sont anormales. Il avance ainsi (en prenant 1 440 points de données à comparer) jusqu’au dernier horodateur spécifié par endTime
(ou le dernier horodateur proprement dit). Par conséquent, la source de données d’inférence doit contenir des données à partir de startTime
- slidingWindow
. Dans l’idéal, sa taille est de slidingWindow
+ (endTime
- startTime
).
Normalement, nous vous recommandons d’utiliser severity
afin de filtrer les « anomalies » qui ne sont pas si importantes pour votre activité. En fonction du scénario et du modèle de données, ces anomalies non essentielles possèdent souvent des valeurs severity
relativement basses ou des valeurs severity
élevées autonomes (discontinues) comme des pics aléatoires.
Dans les cas où vous avez identifié qu’il vous fallait des règles plus sophistiquées que des seuils pour severity
ou qu’une durée de valeurs constamment élevées pour severity
, vous pouvez utiliser score
pour créer des filtres plus puissants. Comprendre comment MVAD utilise score
pour déterminer les anomalies peut vous aider :
Nous considérons si un point de données est anormal du point de vue global et local. Si la valeur score
à un horodateur donné est supérieure à un certain seuil, l’horodateur est marqué comme une anomalie. Si la valeur de score
est inférieure au seuil, mais relativement élevée dans un segment, elle est aussi marquée comme étant une anomalie.
Événements
Créer des applications intelligentes
17 mars, 21 h - 21 mars, 10 h
Rejoignez la série de rencontres pour créer des solutions IA évolutives basées sur des cas d’usage réels avec d’autres développeurs et experts.
S’inscrire maintenant