Partager via

Bonnes pratiques en matière d’utilisation de l’API Détecteur d’anomalies multivarié

  • Article

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 :

  • Utilisation des API : découvrez comment utiliser MVAD sans erreurs.
  • Engineering données : découvrez comment préparer au mieux vos données de sorte que MVAD fonctionne avec plus d’exactitude.
  • Pièges courants : découvrez comment éviter les pièges courants que rencontrent les clients.
  • FAQ : retrouvez les réponses aux questions fréquentes.

Utilisation de l’API

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.

Paramètres d'entrée

Paramètres obligatoires

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.

Paramètres facultatifs pour l’API d’entraînement

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 :

    1. Les propriétés de vos données (sont-elles périodiques, et quel est le taux d’échantillonnage ?). Lorsque vos données sont périodiques, vous pouvez affecter une longueur de un à trois cycles à 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.
    2. Le compromis entre le temps d’entraînement/d’inférence et l’impact potentiel sur les performances. Une valeur plus élevée de 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.

Schéma de données d’entrée

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.

Structure de dossiers

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

Engineering données

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 ?

Qualité des données

  • Étant donné que le modèle apprend les modèles normaux à partir de données historiques, les données d’apprentissage doivent représenter l’état normal global du système. Il est difficile pour le modèle d’apprendre ces types de modèle si les données d’entraînement sont pleines d’anomalies. Le seuil empirique de taux anormal, au-dessous duquel l’exactitude est bonne, s’élève à 1 % .
  • En général, le ratio des valeurs manquantes des données d’entraînement doit être inférieur à 20 % . S’il manque trop de données, les valeurs renseignées automatiquement (généralement des valeurs linéaires ou constantes) risquent d’être apprises comme des modèles normaux, ce qui peut entraîner la détection de points de données réels (et non manquants) comme des anomalies.

Quantité de données

  • 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.

Arrondi de l’horodateur

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.

Limites

Les API d’entraînement et d’inférence présentent toutes deux des limites dont vous devez avoir conscience pour éviter les erreurs.

Limites générales

  • Fenêtre glissante : 28-2880 horodatages, la valeur par défaut est 300. Pour des données périodiques, définissez une longueur de 2 à 4 cycles pour la fenêtre glissante.
  • Nombres de variables : pour un entraînement et une inférence par lots, au maximum 301 variables.

Limites de l’entraînement

  • Horodatages : au maximum 1 000 000. Trop peu d’horodatages peut réduire la qualité du modèle. Recommandez l’utilisation de plus de 5 000 horodatages.
  • Granularité : la granularité minimale est de per_second.

Limitations de l’inférence par lots

  • Horodatages : au maximum 20 000, au minimum 1 longueur de fenêtre glissante.

Limitations de l’inférence par streaming

  • Horodatages : au maximum 2 880, au minimum 1 longueur de fenêtre glissante.
  • Détection des horodatages : de 1 à 10.

Qualité du modèle

Comment traiter les faux positifs et les faux négatifs dans des scénarios réels ?

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.

Comment déterminer quel est le meilleur modèle à utiliser en fonction de la perte d’entraînement et de la perte de validation ?

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.

Pièges courants

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.

Forum aux questions

Comment fonctionne la fenêtre glissante MVAD ?

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).

Quelle est la différence entre severity et score ?

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.

Étapes suivantes