Note de transparence : Détecteur d’anomalies

Détecteur d’anomalies est un service IA qui vous permet de surveiller et de détecter des anomalies dans les données de série chronologique. Cet article fournit des informations de transparence pour vous aider à comprendre le fonctionnement du service, ses fonctionnalités, ses limitations et ses considérations relatives à l’utilisation responsable.

Qu’est-ce qu’une note de transparence ?

Un système IA comprend non seulement la technologie, mais aussi ses utilisateurs, les personnes qu’il touche et l’environnement dans lequel il est déployé. La création d’un système en alignement avec l’objectif visé exige de bien comprendre comment la technologie fonctionne, de connaître ses capacités et ses limites, et de savoir comment atteindre le meilleur niveau de performance. Les notes de transparence de Microsoft sont destinées à vous aider à comprendre le fonctionnement de notre technologie d'IA, les choix que les propriétaires de systèmes peuvent faire et qui influencent les performances et le comportement du système, et l'importance d'appréhender le système dans son ensemble, en englobant la technologie, les personnes et l'environnement. Vous pouvez utiliser les notes de transparence pendant le développement ou le déploiement de votre propre système ou les partager avec les personnes qui utiliseront votre système ou qui seront concernées.

Les notes de transparence de Microsoft s’inscrivent dans une volonté plus globale de Microsoft de mettre en pratique ses principes IA. Pour en savoir plus, consultez les principes de l’IA Microsoft.

Les principes de base du détecteur d’anomalies

Présentation

Détecteur d’anomalies est un service IA qui vous permet de surveiller et de détecter des anomalies dans les données de série chronologique sans expertise technique du Machine Learning. Les API Détecteur d’anomalies s’adaptent automatiquement en identifiant et en appliquant automatiquement les modèles les mieux adaptés à vos données, quel que soit le secteur, le scénario ou le volume de données. Le service Détecteur d’anomalies a deux fonctionnalités, la détection d’anomalie univariée et la détection d’anomalies multivariées.

L’API RESTful détecteur d’anomalies prend en entrée les données de série chronologique, dont les principales parties sont des horodatages et les valeurs numériques des métriques à analyser. La sortie de l’API contient l’état anormal de chaque point de données et, dans le cas d’anomalies identifiées, les variables qui ont contribué à l’état anormal.

Termes clés

Capacités

Comportement du système

L’utilisation du détecteur d’anomalies ne nécessite pas d’expérience préalable dans le Machine Learning. L’API RESTful vous permet d’intégrer facilement le service dans vos applications et processus. L’API Détecteur d’anomalies peut être déployée à l’aide du cloud ou de la périphérie intelligente avec des conteneurs.

Détecteur d’anomalies v1.1 prend en charge deux fonctionnalités différentes :

• Détection d’anomalie univariée : détecter les anomalies dans une variable, comme le chiffre d’affaires, le coût, etc. Le modèle est sélectionné automatiquement en fonction de votre modèle de données, sans avoir à être entraîné.
• Détection d’anomalies multivariées : détecte les anomalies dans plusieurs variables avec des corrélations, qui sont généralement collectées à partir de l’équipement ou d’un autre système complexe. Le modèle sous-jacent utilisé est des réseaux d'attention graphique, et la performance du modèle entraîné varie selon vos données d'entraînement, la personnalisation et les applications.

Cas d’utilisation

Utilisations prévues

Vous pouvez utiliser Détecteur d’anomalies pour plusieurs scénarios, avec ou sans entraînement en fonction de la fonctionnalité Détecteur d’anomalies que vous utilisez. Les utilisations prévues du système sont les suivantes :

• Surveillance des métriques métier : Suivez les performances des métriques métier en temps réel pour identifier les changements substantiels ou soudains. Par exemple, il s’agit d’un modèle numérique inattendu avec des utilisateurs actifs quotidiens d’un site web, d’un inventaire boursier ou d’un chiffre d’affaires.
• Surveillance des métriques des opérations informatiques : analysez et surveillez les données de télémétrie telles que les compteurs de performances des opérations informatiques pour détecter les anomalies susceptibles d’avoir un impact sur l’intégrité et les performances d’un système informatique. Par exemple, l’utilisation du processeur des machines virtuelles, le débit des bases de données, ou même le nombre de connexions et d’inscriptions d’un site web.
• Surveillance des données IoT à partir de capteurs et de maintenance prédictive : Les données de capteur lues à partir de capteurs IoT déployés sur les étages d’usine, les lignes de production, les plateformes pétrolières et les pipelines, ou même les voitures et les drones peuvent être analysés et surveillés avec détecteur d’anomalies. Les anomalies détectées à partir des données peuvent indiquer un état anormal de la machine. L’application que vous créez peut informer les réviseurs humains, ce qui permet d’effectuer des actions de maintenance préventives avant qu’un problème plus important ne se produise.

Points à prendre en considération lors du choix d’un cas d’utilisation

Nous encourageons les clients à tirer parti du détecteur d’anomalies dans leurs solutions ou applications innovantes. Toutefois, voici quelques considérations à prendre en compte lors du choix d’un cas d’usage :

• Dans les cas d’usage susceptibles d’avoir un impact sur la sécurité physique des êtres humains, incluez l’examen humain des sorties avant toute décision concernant les opérations. Parmi ces cas d’usage, citons la surveillance et la détection d’un état anormal dans les performances des machines sur les étages d’usine ou dans les lignes de production.
• Détecteur d’anomalies n’est pas adapté aux décisions susceptibles d’avoir des effets néfastes graves. Parmi ces cas d’usage figurent des scénarios de soins de santé tels que la surveillance des pulsations ou des taux de glucose sanguin. Les décisions basées sur des résultats incorrects pourraient avoir de graves répercussions. De plus, il est conseillé d’inclure l’examen humain des décisions susceptibles d’avoir des répercussions graves sur les individus.
• Étant donné que détecteur d’anomalies n’a aucune capacité d’évaluation qualitative, il n’est pas adapté à la surveillance ou à l’évaluation de l’activité humaine, comme dans le lieu de travail. Nous vous déconseillons de l’utiliser de cette façon. En outre, la surveillance des lieux de travail peut ne pas être légale au sein de votre juridiction.

Limites

Limitations techniques, facteurs opérationnels et plages

Il existe plusieurs limitations du Détecteur d’anomalies à prendre en compte :

• Détecteur d’anomalies est sans état et ne stocke pas de données client ni de mises à jour de modèle. Cela signifie que chaque appel d’API est complètement indépendant. Plusieurs appels d’API avec beaucoup de données ne modifient pas la précision du service. Pour obtenir une meilleure exactitude, effectuez des réglages dans les appels d’API uniques.
• Détecteur d’anomalies ne paramétre pas automatiquement les paramètres pour les clients. Lorsque les clients souhaitent s’appuyer sur les résultats de détection d’anomalies du service pour déclencher des actions automatisées, nous vous recommandons vivement d’effectuer une évaluation avec des données réelles avant d’appliquer les paramètres à votre scénario.
• Le détecteur d’anomalies n'accepte que les données de séries temporelles en utilisant des horodatages et des nombres. Le service n’a aucune connaissance du contexte et de l’environnement où les données sont collectées. En matière d’utilisation de la production, les décideurs peuvent avoir besoin d’examiner les connaissances au-delà de ces mesures.

Performances du système

La précision de la détection des anomalies peut être mesurée en évaluant la façon dont les anomalies détectées par le système correspondent à des événements anormaux réels. Par exemple, lorsqu’une anomalie est capturée par détecteur d’anomalies et qu’une panne de service réelle est signalée par un client. Pour mesurer la précision, le client peut utiliser un ensemble de données historiques et permettre au détecteur d’anomalies d’effectuer des résultats de détection. Le client peut ensuite comparer ces informations avec l’enregistrement des événements réels et classer les résultats de détection en deux types d’anomalies correctes (ou « true ») et deux types d’anomalies incorrectes (ou « false »).

Précision et rappel

La précision est la proportion de vrais positifs parmi tous les résultats positifs retournés, indépendamment de leur exactitude (vrais positifs et faux positifs). Il indique le nombre d’anomalies détectées correspondant aux événements anormaux réels. Elle peut être calculée comme suit :

Precision = TP / (TP + FP)

Un score de précision de 1,0 signifie que chaque anomalie détectée correspond à un événement anormal réel.

Rappel est la proportion de vrais positifs parmi tous les positifs réels (vrais positifs et faux négatifs). Il indique le nombre d’événements anormaux réels détectés. Elle peut être calculée comme suit :

Recall = TP / (TP + FN)

Un score de rappel de 1,0 signifie que chaque événement anormal réel est détecté.

Bonnes pratiques pour améliorer les performances du système

Il peut être difficile d’optimiser à la fois la précision et le rappel en même temps. Selon le scénario spécifique, les clients peuvent vouloir hiérarchiser l’un par rapport à l’autre. Par exemple, les parties prenantes qui surveillent des indicateurs de performance clés spécifiques peuvent avoir besoin d’un taux de rappel élevé afin qu’aucun problème ne soit manqué. En revanche, les parties prenantes au niveau exécutif peuvent souhaiter être averties uniquement lorsque quelque chose de grave se produit, ce qui nécessiterait un taux de précision élevé.

Plusieurs facteurs doivent être équilibrés pour obtenir la précision nécessaire pour répondre aux exigences de l’entreprise.

Détection d’anomalie univariée

Sensibilité

Le paramètre de sensibilité (consultez la référence de l’API pour obtenir plus de descriptions de paramètres) est la clé du réglage des résultats de la détection. En général, une valeur de sensibilité élevée signifie que le modèle est plus sensible aux valeurs hors norme et est susceptible d’identifier plus d’anomalies. Une valeur de faible sensibilité signifie généralement que le modèle tolérera des anomalies mineures.

Choisir le mode approprié

Il existe deux modes de détection différents proposés par le Détecteur d'anomalies : /mode dernier et /mode entier. Ces deux opérations d’API ressemblent en termes de paramètres d’entrée et de format de sortie. Mais il existe une différence clé concernant le comportement de détection qui doit être pris en compte lors du choix du mode à utiliser. L’opération /entière utilise tous les points de données de la requête pour créer un modèle statistique unique. L’opération /last examine uniquement la fenêtre des points de données que vous avez passés à l’API, qui est généralement un sous-ensemble de l’ensemble du jeu de données. Dans la pratique, l’opération /entière est plus susceptible d’ignorer le bruit aléatoire et faible, car elle examine le modèle statistique global. L’opération /last examine uniquement la fenêtre locale que vous avez indiquée et est plus susceptible d’identifier ces points de bruit comme anomalies.

Granularité des données

Lorsque les données brutes sont à faible granularité ( par exemple, un point de données par seconde ou même une sous-seconde), une pratique courante consiste à l’agréger (somme/moyenne/échantillon) à une granularité plus élevée. Les avantages de l’agrégation sont les suivants :

• Faciliter l’alignement pour une distribution uniforme au bon moment, ce qui correspond à un protocole de l’entrée de l’API.
• Tolérance accrue du bruit aléatoire.
• Moins de points de données et moins de transactions d’API.

L’inconvénient de l’agrégation est que les modifications subtiles dans la granularité inférieure ne sont pas prises en compte, ce qui peut entraîner des anomalies importantes manquantes.

D’autres facteurs peuvent également être utilisés pour améliorer la précision du modèle, comme la spécification d’un modèle saisonnier connu. Pour plus d’informations sur l’amélioration de la précision pour la détection d’anomalie univariée, consultez les meilleures pratiques lors de l’utilisation de la détection d’anomalie univariée.

Détection d’anomalie multivariée

Qualité et quantité des données

La qualité et la quantité du jeu de données d’entraînement sont très importantes pour les performances du modèle.

• À mesure que le modèle apprend des modèles normaux à partir de données historiques, les données d’entraînement doivent représenter l’état normal global du système. Il est difficile pour le modèle d’apprendre ces types de schéma (pattern) si les données d’entraînement sont remplies d’anomalies. Un seuil empirique pour le taux anormal est de 1% ou inférieur pour une bonne précision.
• En général, le ratio des valeurs manquantes des données d’apprentissage doit être inférieur à 20%. Trop de données manquantes peuvent entraîner des valeurs remplies automatiquement (généralement des valeurs linéaires ou des valeurs constantes) apprises en tant que modèles normaux. Cela peut entraîner la détection de points de données réels (et pas manquants) comme étant des anomalies.
• Le modèle sous-jacent de MVAD compte des millions de paramètres. Il a besoin d’un nombre minimal de points de données pour apprendre un ensemble optimal de paramètres. La règle empirique est que vous devez fournir 5 000 points de données ou plus (horodatages) par variable pour entraîner le modèle pour une bonne précision. En général, plus les données d’apprentissage sont meilleures, plus la précision est meilleure. Toutefois, dans les cas où vous n’êtes pas en mesure d’accumuler autant de données, nous vous encourageons toujours à expérimenter avec moins de données et à voir si la précision est toujours acceptable.

Fenêtre Glissante

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 une slidingWindow. Gardez deux éléments à l’esprit lors du choix d’une valeur slidingWindow :

• 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 définir la longueur de 1 à 3 cycles comme fenêtre glissante. Lorsque vos données présentent une fréquence élevée (granularité fine), par exemple au niveau de la minute ou de la seconde, vous pouvez affecter une valeur relativement supérieure à SlidingWindow.

• Compromis entre le temps d’entraînement/d’inférence et l’impact potentiel sur les performances. Une fenêtre glissante plus grande peut entraîner un temps d’entraînement/d’inférence plus long. Il n’existe aucune garantie que des fenêtres glissantes plus grandes entraînent des gains de précision. Une petite fenêtre glissante peut rendre difficile la convergence du modèle vers une solution optimale. Par exemple, il est difficile de détecter les anomalies lorsque lewindow glissant n’a que deux points.

Gravité et score

Nous vous recommandons d’utiliser la gravité comme filtre pour examiner les « anomalies » qui ne sont pas importantes pour votre entreprise. Selon votre scénario et votre modèle de données, les anomalies qui sont moins importantes ont souvent des valeurs de gravité relativement inférieures ou des valeurs de gravité autonomes (discontinues) élevées, comme des pics aléatoires.

Dans les cas où vous avez besoin de règles plus sophistiquées que des seuils par rapport à la gravité ou à la durée des valeurs de gravité élevée continue, vous pouvez utiliser le score pour créer des filtres plus puissants. Comprendre comment MVAD utilise le score pour déterminer les anomalies peut aider : nous considérons si un point de données est anormal du point de vue global et local. Si le score à un horodatage est supérieur à un certain seuil, l’horodatage est marqué comme une anomalie. Si le score est inférieur au seuil, mais qu’il est relativement plus élevé dans un segment, il est également marqué comme une anomalie.

Pour plus d’informations sur l’amélioration de la précision pour la détection d’anomalie univariée, consultez les meilleures pratiques lors de l’utilisation de la détection d’anomalie multivariée.

Évaluation et intégration du détecteur d’anomalies pour votre utilisation

Les performances du détecteur d’anomalies varient en fonction des utilisations réelles que les clients implémentent. Pour garantir des performances optimales dans leurs scénarios, les clients doivent effectuer leurs propres évaluations des solutions qu’ils implémentent à l’aide du détecteur d’anomalies. Comme vous le faites, tenez compte des éléments suivants :

• Les clients peuvent avoir leurs propres préférences pour voir les résultats des anomalies. Dans ce cas, ils devront développer des éléments d’interface supplémentaires pour afficher les résultats en fonction de leurs préférences.
• Détecteur d’anomalies traite de différentes métriques. Certaines de ces métriques peuvent être sensibles et ne doivent pas être accessibles publiquement. Lorsque vous envisagez d’implémenter une solution qui utilise détecteur d’anomalies, envisagez de contrôler l’accès sur différentes données de métriques. Assurez-vous que votre solution est sécurisée et dispose de contrôles adéquats pour préserver l’intégrité de votre contenu et empêcher l’accès non autorisé.
• Avant de déployer détecteur d’anomalies dans votre scénario, testez son fonctionnement à l’aide de données réelles et assurez-vous qu’il peut servir l’objectif que vous essayez d’atteindre.
• Validez la précision des résultats générés par le service, effectuez des réglages précis en fonction des meilleures pratiques pour améliorer la précision et assurez-vous qu’elle offre la précision dont vous avez besoin.
• Le détecteur d’anomalies n’est pas 100% précis. Réfléchissez donc à la façon dont vous identifierez et répondez aux erreurs qui peuvent se produire.
• Détecteur d’anomalies offre des insights de données, et non des recommandations sur les actions à entreprendre. Par conséquent, lorsque vous répondez aux anomalies identifiées par ce service, vous devez agir en fonction de votre expertise dans votre domaine.

En savoir plus sur l’IA responsable

• Les principes de l’IA de Microsoft.
• Ressources d’IA responsable Microsoft
• Identifier les principes et les pratiques d’une IA responsable

En savoir plus sur le détecteur d’anomalies

• Détecteur d’anomalies - Système de détection d’anomalie | Microsoft Azure
• Identifier les données de série chronologique anormales avec détecteur d’anomalies - Formation | Microsoft Learn
• Qu’est-ce que le Détecteur d’anomalies ? - Azure AI services | Microsoft Learn

Contactez-nous

Envoyez-nous vos commentaires sur ce document par e-mail pour : anomalydetector@microsoft.com