Année : 2017

TensorFlow

LeanBI ist konstant auf der Suche nach neuen Technologien um innovative Geschäftsmodelle zu entwickeln und neue Projekte zu starten. Eine solche Technologie präsentieren wir in diesem TensorFlow Blog.

 

Was ist TensorFlow

TensorFlow ist eine plattformunabhängige und freie Programmbibliothek für künstliche Intelligenz bzw. maschinelles Lernen. Es ist der Nachfolger von DistBelief, eine ähnliche aber nicht freie Programmbibliothek von Google. TensorFlow wird vor allem für die Modellierung neuronaler Netze benutzt. Im Moment sind  Sprach- und Bildverarbeitungsaufgaben die Hauptanwendungsfälle. Andere Nutzungen sind aber möglich.

Wie funktioniert TensorFlow?

TensorFlow führt numerische Berechnungen durch gerichtete Datenflussgraphen aus. Die interne Struktur von TensorFlow ist wie folgt:

  • Die Tensoren sind Objekte bzw. Datenstrukturen, die Vektoren oder mehrdimensionale Matrizen enthalten.
  • Die Knoten des Datenflussgraphen entsprechen mathematischen Berechnungen (Operatoren).
  • Die Kanten des Datenflussgraphen entsprechen den Tensoren und geben diese an andere Knoten weiter.

Was sind die Vorteile von TensorFlow?

Im Unterschied zu Numpy ist TensorFlow für Machine Learning spezifische Berechnungen optimiert. Ein Beispiel ist die Ableitungen von Matrizen. Die dezentralisierte Architektur von TensorFlow ermöglicht die Berechnung auf mehreren Rechnern oder Grafikprozessoren.

Des Weiteren ist transferlernen (Englisch: transfer learning) möglich: Vortrainierte Modelle werden verwendet um die Merkmale neuer Datensätze automatisch extrahieren zu können. Eine praktische Möglichkeit um neuronale Netze zu benutzen ohne über grosse Datensätze und lange Trainingszeiten zu verfügen. Beispielsweise kann ein neuronales Netz, welches die Klassifizierung von LKWs gelernt hat, nach kurzem Training auch PKWs klassifizieren.

 

Schliesslich ermöglicht TensorFlow die Kreation, Modifikation und Ausnutzung von Neuronalen Netzen in einer vereinfachten Form. Diese Modelle sind oft komplex und dementsprechend profitiert man von bereits geleistetem Programmieraufwand. Die Verschiedene Programmierungsbibliotheken – inkl. Python die wir für unsere Teste verwendet haben – sind sehr einfach und effizient.

Möchten Sie TensorFlow spielerisch ausprobieren? Dann empfehlen wir Ihnen die folgende TenorFlow Homepage mit einem graphischen interaktiven neuronalen Netz.

Moteur rotatif – exemple de détection d’anomalies

Dans ce dernier article, nous détaillons de bout en bout une application de détection d’anomalies, de l’étude de cas à l’interface utilisateur. Nous expliquerons dans quel scénario de détection d’anomalie nous nous trouvons, ainsi que les anomalies que nous considérons. Pour plus de détails, nous vous invitons à lire (ou relire) les articles précédents traitant du sujet: « Les 3 différents types d’anomalies » et « Les 3 scénarios de détection d’anomalies ».

 

Il s’agit d’un moteur électrique rotatif. Ce dernier fait tourner différents disques métalliques reliés par une courroie. Les différentes pièces du moteur et les disques vibrent lorsque ce dernier est en marche. Les vibrations sont mesurées à l’aide d’un capteur de vibration sans-fil de l’entreprise Neratec. Ce sont précisément ces mesures qui vont nous permettre de détecter les potentielles anomalies du moteur.

 

L’ensemble de l’installation est présenté dans la Figure 5. Le moteur est encadré en bleu, le capteur de vibration en rouge et l’interface en vert. Nous avons construit cette démonstration à l’occasion du Sindex 2016, grand salon des technologies qui se déroule tous les deux ans à Berne.

 

Figure 5 Moteur rotatif sur notre stand lors du SINDEX 2016 à Berne. Encadré en bleu, le moteur. En rouge, le capteur de vibration. En vert, la détection, d‘anomalies en temps réel.

 

Voici en quelques lignes le détail de l’identification, de la résolution et de l’implémentation de ce problème de détection d’anomalies.

 

Identification du problème:

 

Les principales causes de dysfonctionnement d’un tel moteur sont les suivantes: le moteur tourne trop lentement, trop vite ou un des disques métalliques est biaisé. Nous avons volontairement ignoré d’autres dysfonctionnements du fait qu’ils ne sont pas détectables avec un capteur de vibration. Par exemple, un problème d’alimentation électrique empêchant le moteur de tourner : comment distinguer ce cas d’un moteur simplement éteint, à l’aide d’un capteur de vibrations seulement ?

 

Nous souhaitons reconnaître lorsque le moteur fonctionne correctement et distinguer les différentes anomalies. Nous sommes donc dans un problème de classification à 5 classes:

 

  1. 1. Le moteur est éteint
  2. 2. Le moteur tourne normalement
  3. 3. Le moteur tourne trop lentement
  4. 4. Le moteur tourne trop vite
  5. 5. Un des disques métalliques est biaisé

 

Nous avons préalablement effectué des mesures de chaque classe. Ces mesures sont labellées, rendant ce problème de détection d’anomalies entièrement supervisé.

 

Résolution du problème:

 

Les données à disposition sont celles collectées par le biais du capteur de vibration. Il s’agit d’un signal réel échantillonné à 2 kHz. Nous avons converti ce signal dans le domaine fréquentiel. Les coefficients de la transformée de Fourier sont ainsi nos features pour notre modèle.

 

Figure 6 Moyennes des fréquences par état du moteur (éteint, normal, trop vite, trop lent)

 

Nous avons entraîné et testé différents modèles dans l’exemple présenté. Notre but était d’obtenir de bonnes prédictions, rapidement et avec un algorithme simple. Notre choix s’est finalement porté sur l’algorithme Random Forest. Il est simple d’utilisation, rapide, présente des résultats satisfaisants et permet de comprendre quelles features influencent plus particulièrement la classification d’anomalies.

 

Implémentation:

 

L’implémentation du projet a été faite à l’aide du logiciel Dataiku. L’importation des données, le nettoyage et leur processing sont facilités et accélérés. La création d’un modèle est également simplifiée. On peut entraîner et valider notre algorithme Random Forest d’un seul click. Le cheminement d’un projet de Machine Learning reste cependant le même.

 

Figure 7 Flux de données du projet dans Dataiku

 

Pour terminer cet article, nous vous proposons une brève vidéo tournée lors du Sindex où nous présentons notre moteur en direct. Les commentaires sont en allemand, mais le fonctionnement de l’installation reste le même:

 

Les 3 scénarios de détection d’anomalies

Pour un problème réel, les données à dispositions ne sont pas toujours celles que l’on souhaiterait idéalement avoir. Il est souvent couteux, difficile et/ou long de récolter les différentes informations nécessaires.

Dans le cadre de la détection de vol d’une carte de crédit, le nombre de transactions frauduleuses est bien inférieur à celui des transactions normales. Autrement dit, les anomalies sont peu nombreuses et le système doit se contenter de très peu d’exemples pour s’entraîner à la détection. Dans certains cas, il n’est même pas possible de mesurer préalablement les anomalies. Pour l’aviation civile et militaire, plusieurs capteurs sont posés sur les différents moteurs des appareils. Le but est de détecter s’il y a un problème dans le fonctionnement complexe de la propulsion des appareils. Cependant, en phase de test, il est trop couteux de détériorer un moteur pour prendre des simples mesures. L’algorithme de détection d’anomalies doit se contenter, pour s’entraîner, de données où le moteur est en bon état.

Triebwerk
De manière générale, on distingue les trois scénarios suivants, avec un degré de difficulté habituellement croissant : la détection d’anomalie supervisée, semi-supervisée et non supervisée.

Détection d’anomalie supervisée :

C’est le cas le plus simple, mais aussi le moins fréquent et le moins réaliste. Dans ce scénario, des données représentant chaque anomalie sont présentes en quantité suffisante, ainsi que des données sans anomalies. Simple car il s’agit d’un problème de classification, avec deux classes ou plus selon le nombre d’anomalies considérées, où des méthodes éprouvées peuvent être appliquées. Moins fréquent et moins réaliste car il est rarement aisé d’obtenir des données avec label et représentatives pour chaque classe, particulièrement pour les anomalies. Même si l’on ne prend pas un cas extrême comme celui du moteur d’avion, il est facile d’imaginer que récolter des données pour toutes les anomalies imaginables est une tâche ardue. Pour cette raison, ce scénario n’est que rarement applicable.

Détection d’anomalies semi-supervisée :

Dans ce cas de figure, les données à disposition pour entraîner l’algorithme et/ou construire un modèle sont disponibles seulement pour l’état normal, c’est-à-dire sans anomalies. L’exemple du moteur d’avion se situe dans cette catégorie. Du fait que ce scénario correspond à des conditions réelles, cela en fait un domaine de recherche très actif.

La difficulté ici réside dans la création d’un model exhaustif qui représente l’ensemble des données normales. Mais il faut faire attention que ce modèle ne soit pas trop généraliste non plus et ne considère pas les anomalies comme des instances normales (voir l’article « Les 5 plus grandes difficultés de la détection d’anomalies » paragraphe « Choix du seuil de décision »).

Détection d’anomalies non supervisée :

Le dernier scénario ne requière pas de données avec label pour s’entraîner. C’est donc le scénario le plus largement applicable. Pour identifier les anomalies, l’algorithme part du principe que le nombre d’instance normales et bien plus élevé que le nombre d’anomalies.

Dans l’exemple de détection de vol de carte de crédit, l’algorithme s’entraînerait sur l’ensemble des transactions disponibles. Il considérerait les transactions à très gros montant comme anormales vu que celles-ci sont bien moins fréquentes. A contrario, les transactions frauduleuses à petit montant seraient plus difficilement détectables. Notons que dans un cas réel, l’algorithme considérerait également d’autres paramètres comme la date de la transaction, le lieu, la marchandise achetée, etc.

Les 3 différents types d’anomalies

Le troisième article de notre série décrit les différents types d’anomalies telles qu’on les rencontre habituellement. Nous pouvons répartir les anomalies en trois groupes : les anomalies ponctuelles, contextuelles et collectives. Il est important de bien identifier leur type pour ensuite choisir l’algorithme le plus adapté à leur détection. Le type d’anomalies considéré dépend du problème en question. Comme illustré dans le précédent article, en médecine, une simple variation de la température corporelle d’un patient doit être considérée comme anormale. Alors qu’en finance, les variations dans les marchés sont au contraire très courantes. Il est également possible de vouloir détecter plusieurs types d’anomalies à la fois, rendant le problème plus complexe et le choix de l’algorithme de détection plus compliqué.

Anomalies ponctuelles :

Deux anomalies ponctuelles
Figure 2 Deux anomalies ponctuelles dans un espace bi-dimensionnel

Si une donnée seule peut être considérée comme anormale en comparaison avec le reste des données, alors celle-ci est définie comme une anomalie ponctuelle. L’exemple de la carte de crédit volée en est une parfaite illustration. Visuellement, nous illustrons ce type d’anomalies avec la Figure 1 : dans un espace à deux dimensions, les deux points très éloignés du nuage de données centré en (0,0).

Anomalies contextuelles :

Anomalies contextuelles : Courbe de la température durant l'année
Figure 3 Courbe de la température durant l’année (Source : Anomaly detection: A survey, V. Chandola, A. Banerjee, V. Kumar, 2009, p.58)

Si une donnée seule est considérée comme anormale dans un contexte spécifique, mais pas autrement, il s’agit d’une anomalie contextuelle. La Figure 2 représente les données d’un capteur de température sur une année. Les valeurs t1 et t2 sont semblables, mais la très basse température t2 se trouve en été, ce qui n’est pas normal par rapport à son contexte, c’est-à-dire qu’il fait chaud en été.

Anomalies collectives :

Kollektive Anomalie des Elektrokardiogramms
Figure 3 Électrocardiogramme (Source : Anomaly detection: A survey, V. Chandola, A. Banerjee, V. Kumar, 2009, p.58)

Si un groupe de données est anormal par rapport au reste des données, les données de ce groupe sont définies comme des anomalies collectives. Pour illustrer ce dernier type d’anomalie, nous prenons l’exemple de l’électrocardiogramme. On remarque sur la Figure 3 que le signal est stable sur une période anormalement longue (entre t=1100 et t=1400 environ). Pour détecter cette anomalie, il faut considérer l’ensemble des valeurs sur l’intervalle. C’est leur répétition qui est anormale, pas leur valeur, ni le contexte.

De par ces trois groupes d’anomalies, nous remarquons qu’il est crucial de bien caractériser les anomalies initialement. Un algorithme destiné à détecter les anomalies ponctuelles n’aura aucune chance de reconnaître des anomalies contextuelles et collectives. L’inverse est également vrai.

Dans le prochain article, nous aborderons la problématique liée aux données à disposition, plus particulièrement leur type et leur disponibilité. Différents scénarios seront présentés et illustrés.

Les 5 plus grandes difficultés de la détection d’anomalies

Dans ce deuxième article de notre série consacrée à la détection d’anomalies, nous présentons les difficultés liées à l’analyse des données et à la détection des anomalies elle-même.

Bien qu’ardue également, nous faisons ici abstraction du processus de collecte et stockage des mesures. Nous supposons que les données sont disponibles sous la forme voulue. Si l’on devait considérer le problème dans son ensemble, il faudrait prendre en compte le type de capteurs à utiliser, leur calibration, leur mise en réseau, l’envoi des données sur un serveur, le type de base de données utilisée, etc.

La détection d’anomalies
Source: www.dbta.com
Les cinq principaux challenges sont décrits ci-après.

1. Choix du seuil de décision

Dans le précédent article, l’exemple du poids d’une fiole de médicament qui différait de 20% du poids habituel. Maintenant, si la différence de poids n’est que de 2%, est-ce toujours un problème ? Et de 5% ? On le comprend aisément, définir un seuil n’est pas facile. De plus, que faut-il faire avec les valeurs très proches du seuil (par exemple, 4.9% et 5.1% si ce dernier est à 5%) ? Le problème devient plus compliqué si l’on considère le problème dans des dimensions plus élevées. Pour notre exemple, cela revient à traiter d’autres informations supplémentaires : pH, température de production, etc.

2. Identification des anomalies

Parfois, les anomalies sont le résultat d’actions malveillantes, comme dans le cas d’une attaque informatique et de requêtes malicieuses vers un serveur. L’attaquant va tout mettre en œuvre pour que ses requêtes paraissent normales. Cela rend la définition d’une anomalie plus complexe et leur détection plus difficile.

3. Evolution de la définition de l’anomalie

Dans plusieurs domaines d’application, la définition d’une anomalie peut évoluer avec le temps. Des observations d’abord considérées comme normales peuvent ne plus l’être par la suite, et vice-versa. Par exemple, admettons qu’un mouvement mécanique soit mal réglé et implique une friction entre deux pièces de métal. Un grincement est alors audible et permet d’identifier l’anomalie. Cependant, le métal peut, à force, se lisser. Le grincement va petit à petit disparaître, mais pas la friction elle-même. La forme de l’anomalie a évolué avec le temps.

4. Données bruitées

Les données à disposition peuvent contenir du bruit. Ce dernier provient généralement des instruments de mesures ou capteurs. Il devient alors difficile de distinguer les anomalies du bruit. Notons que, parfois, les anomalies recherchées sont le bruit lui-même.

5. Généralisation compliquée

Il est difficile de généraliser un algorithme de détection d’anomalies car les anomalies elles-mêmes dépendent fortement du problème considéré. En médecine, une simple variation de la température corporelle d’un patient doit être considérée comme anormale. Alors qu’en finance, les variations dans les marchés sont au contraire très courantes.

Les différents types d’anomalies font l’objet du prochain article. De manière générale, les difficultés présentées ne sont pas exhaustives et peuvent être complétées par différents aspects qui sont propres à chaque domaine ou problème. Ils sont cependant en dehors de la portée de cet article.

Qu’est-ce que la détection d’anomalies ?

On dit souvent que l’erreur est humaine, mais les machines en font parfois aussi !
S’assurer du bon fonctionnement d’une ligne de production, de la conformité d’un produit ou encore de sa qualité est chose courante dans l’industrie et d’autres domaines. Tout au long de tels processus, différents tests sont effectués, qu’ils soient visuels ou sensitifs. Par exemple, un menuisier va inspecter sa chaise nouvellement créée à la recherche de défauts de ponçage alors qu’un fabricant de câbles électriques va tester si le courant est bien transmis à travers ceux-ci. Tous deux sont à la recherche de potentielles anomalies. Cette recherche est alors cruciale pour s’assurer de la qualité des produits et optimiser la production.

 

Dans un monde résolument plus informatisé et plus connecté, nous abordons ici une approche du problème reliée au traitement et à l’analyse des données. Dans l’exemple du menuisier, il s’agirait de détecter les défauts à partir de photos des différentes parties de la chaise. Pour le fabricant de câbles, les données provenant des capteurs de courant électrique seraient alors analysées.

Anomaly Detection

Figure: Quelques-uns des éléments clés d’un problème de détection d’anomalies.

 

Lorsqu’elle est automatisée, la détection d’anomalies dans un jeu de données est une tâche complexe qui fait intervenir les domaines tels que le « Machine Learning », les statistiques, le « Data Mining », etc. La nature des données, les informations correspondantes, le type d’anomalies à considérer et le résultat à fournir pour le système en question vont déterminer le choix de l’algorithme à utiliser. Tous ces aspects sont des éléments clés d’un problème de détection d’anomalies (voir Figure).

 

Quant à une définition plus formelle du problème, elle peut être donnée comme suit : « La détection d’anomalies est définie comme la recherche de structures dans un jeu de données qui ne correspondent pas au comportement attendu » [Anomaly detection: A survey, V. Chandola, A. Banerjee, V. Kumar, 2009, p.58].

 

De manière plus pratique, il s’agit de reconnaître quelles valeurs sont problématiques parmi toutes les données. Par exemple, un fournisseur de carte de crédit va chercher à identifier les transactions frauduleuses. Si le système enregistre un achat de plusieurs milliers de francs alors que vous avez l’habitude d’utiliser votre carte pour acheter votre billet de train, il y a de fortes chances pour que vous vous soyez fait voler votre carte ou vos identifiants de paiement. Dans un autre contexte, si la ligne de fabrication d’une entreprise pharmaceutique enregistre un poids final d’une fiole de médicament 20% supérieur à d’habitude, une erreur s’est probablement glissée dans sa fabrication.

 

Les domaines concernés donc sont très variés et la manière de les résoudre diffère souvent. Nous aborderons dans le prochain article les raisons qui rendent la détection d’anomalies un problème complexe.

La détection d’anomalies en cinq chapitres

Cette suite d’articles est une introduction à la détection d’anomalies. Les principaux enjeux, les difficultés d’un tel problème ainsi que ses spécificités techniques seront présentés au fil des écrits qui suivent. Cette série se terminera avec un exemple illustré de détection d’anomalies dans le domaine industriel que nous avons rencontré chez leanBI.

La détection d’anomalies
Source: www.dbta.com

Sommaire: