Concevoir l'IA pour l'analyse des fichiers journaux

12

Je suis en train de développer un outil d'intelligence artificielle pour trouver les erreurs d'équipements connues et trouver de nouveaux modèles de défaillance. Ce fichier journal est basé sur le temps et contient des messages connus (informations et erreurs). J'utilise une bibliothèque JavaScript Événements pour afficher les données de manière douce, mais mon vrai travail et mes doutes sont de savoir comment former l'IA à trouver le connu modèles et trouver de nouveaux modèles possibles. J'ai quelques exigences:

1 - L'outil doit soit a. ne dépend pas de l'installation d'un environnement supplémentaire ou b. moins c'est mieux (le scénario parfait est d'exécuter l'outil entièrement sur le navigateur en mode autonome);

2 - Possibilité de fragmenter l'analyseur de motifs, une sorte de modularité, un module par erreur;

Quels sont les types d'algorithmes recommandés pour ce faire (réseau de neurones, algorithme génétique, etc.)? Exister quelque chose pour fonctionner en utilisant JavaScript? Sinon, quel est le meilleur langage pour faire cette IA?

Juliano Oliveira
la source
1
Je soupçonne que quelque chose basé sur des règles serait plus approprié pour cela que l'apprentissage
automatique
@antlersoft Pour les problèmes connus, je suis d'accord, mais je veux aussi rechercher des modèles pour établir des corrélations avec les défauts.
Juliano Oliveira
Conseillé? Réfléchissons ... Vous utilisez regexp? Les réseaux de neurones sont recommandés pour les problèmes qui n'ont pas de solution en utilisant des algorithmes classiques. Presque tous les réseaux de neurones reçoivent des données prétraitées. Si vous "prétraitez" le journal, vous obtenez également votre solution.
betontalpfa

Réponses:

9

Corrélation entre les entrées

La première recommandation consiste à s'assurer que les entrées d'avertissement et d'information appropriées dans le fichier journal sont présentées ainsi que les erreurs dans les composants d'apprentissage automatique de la solution. Toutes les entrées de journal sont des données d'entrée potentiellement utiles s'il est possible qu'il existe des corrélations entre les messages d'information, les avertissements et les erreurs. Parfois, la corrélation est forte et donc critique pour maximiser le taux d'apprentissage.

Les administrateurs système voient souvent cela comme une série d'avertissements suivie d'une erreur causée par la condition indiquée dans les avertissements. Les informations contenues dans les avertissements indiquent plus la cause première de l'échec que l'entrée d'erreur créée lorsque le système ou un sous-système tombe en panne.

Si l'on construit un tableau de bord d'intégrité du système pour un équipement ou un ensemble de machines qui interagissent, ce qui semble être le cas dans cette question, la cause première des problèmes et une capacité d'alerte précoce sont les informations clés à afficher.

De plus, toutes les mauvaises conditions de santé du système ne se soldent pas par un échec.

Les seules entrées de journal qui devraient être éliminées par filtration avant la présentation au mécanisme d'apprentissage sont celles qui sont sûrement hors de propos et non corrélées. Cela peut être le cas lorsque le fichier journal est une agrégation de la journalisation de plusieurs systèmes. Dans un tel cas, les entrées du système indépendant analysé doivent être extraites en tant qu'isolat des entrées qui ne pourraient pas être en corrélation avec les phénomènes analysés.

Il est important de noter que limiter l'analyse à une entrée à la fois limite considérablement l'utilité du tableau de bord. La santé d'un système n'est pas égale aux indications de santé de l'entrée de journal la plus récente. Ce n'est même pas la somme linéaire des indications de santé des N entrées les plus récentes.

L'intégrité du système a des relations très non linéaires et très temporellement dépendantes avec de nombreuses entrées. Des modèles peuvent apparaître progressivement au cours des jours sur de nombreux types de systèmes. La base (ou une base) du réseau neuronal du système doit être formée pour identifier ces indications non linéaires de santé, de dangers imminents et de conditions de risque si un tableau de bord très utile est souhaité. Pour afficher la probabilité d'une défaillance imminente ou d'un problème de contrôle de la qualité, une fenêtre temporelle entière d'entrées de journal d'une longueur considérable doit entrer dans ce réseau neuronal.

Distinction entre motifs connus et inconnus

Notez que l'identification des modèles connus est différente sur un point important que l'identification de nouveaux modèles. Les particularités de la syntaxe d'entrée des erreurs connues ont déjà été identifiées, ce qui réduit considérablement la charge d'apprentissage dans les étapes de normalisation des entrées du traitement de ces entrées. Les idiosyncrasies syntaxiques des nouveaux types d'erreur doivent être découvertes en premier.

Les entrées d'un type connu peuvent également être séparées de celles qui sont inconnues, ce qui permet l'utilisation de types d'entrée connus comme données d'apprentissage pour faciliter l'apprentissage de nouveaux modèles syntaxiques. Le but est de présenter des informations normalisées syntaxiquement à l'analyse sémantique.

Première étape de normalisation spécifique aux fichiers journaux

Si l'horodatage est toujours au même endroit dans les entrées, le convertir en millisecondes relatives et peut-être supprimer tous les caractères 0x0d avant que les caractères 0x0a puissent être effectués avant toute autre chose comme première étape de la normalisation. Les traces de pile peuvent également être repliées en tableaux de niveaux de trace délimités par des tabulations afin qu'il y ait une correspondance biunivoque entre les entrées de journal et les lignes de journal.

Les informations normalisées syntaxiquement provenant d'entrées d'erreur connues et inconnues et d'entrées de type non-erreur peuvent ensuite être présentées à des réseaux non supervisés pour l'identification naïve des catégories d'une structure sémantique. Nous ne voulons pas classer les nombres ou les variables de texte tels que les noms d'utilisateur ou les numéros de série des pièces.

Si les informations syntaxiquement normalisées sont marquées de manière appropriée pour indiquer des symboles hautement variables tels que les nombres, les capacités, les métriques et les horodatages, l'extraction de caractéristiques peut être appliquée pour apprendre les modèles d'expression d'une manière qui maintient la distinction entre la structure sémantique et les variables. Le maintien de cette distinction permet de suivre les tendances plus continues (moins discrètes) des métriques du système. Chaque entrée peut avoir zéro ou plusieurs de ces variables, qu'elles soient connues a priori ou récemment acquises grâce à l'extraction de caractéristiques.

Les tendances peuvent être représentées graphiquement en fonction du temps ou du nombre d'instances d'un type particulier. Ces graphiques peuvent aider à identifier la fatigue mécanique, l'approche des conditions de surcapacité ou d'autres risques qui dégénèrent en un point de défaillance. D'autres réseaux de neurones peuvent être formés pour produire des indicateurs d'avertissement lorsque les tendances indiquent que de telles conditions sont imminentes.

Journalisation paresseuse

Toute cette analyse de journal serait théorique si les architectes logiciels et les responsables de la technologie cessaient de laisser le format de stockage des informations système importantes aux caprices variés et pratiques des développeurs de logiciels. Les fichiers journaux sont généralement un gâchis et l'extraction d'informations statistiques sur les modèles qu'ils contiennent est l'un des défis les plus courants dans le contrôle de la qualité des logiciels. La probabilité que la rigueur soit appliquée universellement à la journalisation est faible, car aucun des cadres de journalisation populaires n'encourage la rigueur. C'est très probablement pourquoi cette question a été fréquemment consultée.

Section des exigences de cette question spécifique

Dans le cas spécifique présenté dans cette question, l'exigence n ° 1 indique une préférence pour exécuter l'analyse dans le navigateur, ce qui est possible mais non recommandé. Même si ECMA est un merveilleux langage de script et que le mécanisme d'expression régulière qui peut être utile pour l'apprentissage des analyseurs est intégré à ECMA (qui est conforme à l'autre partie de l'exigence n ° 1, ne nécessitant pas d'installations supplémentaires), les langues non compilées ne sont pas aussi aussi efficace que Java. Et même Java n'est pas aussi efficace que C en raison de la collecte des ordures et des inefficacités qui se produisent en déléguant le mappage du code octet au code machine pour l'exécuter.

De nombreuses expérimentations en apprentissage automatique utilisent Python, un autre langage merveilleux, mais la plupart du travail que j'ai fait en Python a ensuite été porté sur du C ++ efficace en calcul pour près de 1000 à un gain de vitesse dans de nombreux cas. Même la recherche de méthode C ++ était un goulot d'étranglement, donc les ports utilisent très peu d'héritage, dans le style ECMA, mais beaucoup plus rapidement. Dans le code du noyau traditionnel traditionnel, l'utilisation des structures C et du pointeur de fonction élimine la surcharge de vtable.

La deuxième exigence des gestionnaires modulaires est raisonnable et implique un environnement de règles déclenchées que beaucoup peuvent être tentées de penser est incompatible avec les architectures NN, mais ce n'est pas le cas. Une fois que les catégories de modèles ont été identifiées, la recherche des plus courantes en premier dans d'autres données d'entrée est déjà impliquée dans la distinction connue / inconnue déjà intégrée dans le processus ci-dessus. Cependant, cette approche modulaire présente un défi.

Parce que la santé du système est souvent indiquée par des tendances et non par des entrées uniques (comme discuté ci-dessus) et parce que la santé du système n'est pas une somme linéaire de la valeur de santé des entrées individuelles, l'approche modulaire de la gestion des entrées ne doit pas être simplement dirigée vers l'affichage sans plus une analyse. C'est en fait là que les réseaux de neurones fourniront les gains fonctionnels les plus importants en matière de surveillance de la santé. Les sorties des modules doivent entrer dans un réseau neuronal qui peut être formé pour identifier ces indications non linéaires de santé, de dangers imminents et de conditions de risque.

De plus, l'aspect temporel du comportement de pré-défaillance implique qu'une fenêtre temporelle entière d'entrées de journal de longueur considérable doit entrer dans ce réseau. Cela implique en outre l'inadéquation de l'ECMA ou de Python comme choix pour la partie de la solution à forte intensité de calcul. (Notez que la tendance en Python est de faire ce que je fais avec C ++: utiliser une conception orientée objet, une encapsulation et des modèles de conception faciles à suivre pour le code de supervision et un code de type noyau très efficace en termes de calcul pour l'apprentissage réel et d'autres calculs intensifs ou intensifs en données) les fonctions.)

Algorithmes de prélèvement

Il n'est pas recommandé de choisir des algorithmes dans les premières étapes de l'architecture (comme cela a été suggéré à la fin de la question). Architectez d'abord le processus. Déterminez les composants d'apprentissage, le type d'entre eux nécessaires, leur état d'objectif après la formation, où le renforcement peut être utilisé et comment le signal de bien-être / d'erreur sera généré pour renforcer / corriger le comportement réseau souhaité. Basez ces déterminations non seulement sur le contenu d'affichage souhaité, mais également sur le débit attendu, les besoins en ressources informatiques et le taux d'apprentissage effectif minimal. Les algorithmes, le langage et la planification de la capacité du système ne peuvent être sélectionnés de manière significative qu'après avoir défini au moins grossièrement toutes ces choses.

Travail similaire en production

L'analyse syntaxique adaptative simple est exécutée dans le laboratoire ici dans le cadre de l'automatisation des réseaux sociaux, mais uniquement pour des ensembles limités de symboles et de modèles séquentiels. Il évolue sans reconfiguration vers une base linguistique arbitrairement grande, des préfixes, des terminaisons et des suffixes, limités uniquement par nos capacités matérielles et notre débit. L'existence de bibliothèques d'expressions régulières a été utile pour garder la conception simple. Nous utilisons la bibliothèque de la série PCRE version 8 alimentée par une forme ansiotrope de DCNN pour l'extraction de fonctionnalités à partir d'une fenêtre se déplaçant à travers le texte d'entrée avec une taille de fenêtre configurable et une taille d'incrément de déplacement. Les heuristiques appliquées à la saisie des statistiques de texte recueillies lors d'une première passe produisent un ensemble d'hypothétiques PCRE disposés en deux couches.

L'optimisation se produit pour appliquer des pondérations probabilistes plus élevées aux meilleurs PCRE dans une recherche de texte perturbée de manière chaotique. Il utilise les mêmes stratégies de convergence de descente de gradient que celles utilisées dans la propagation de retour NN en formation. Il s'agit d'une approche naïve qui ne fait pas d'hypothèses comme l'existence de back-traces, de fichiers ou d'erreurs. Il s'adapterait également aux messages arabes et espagnols.

La sortie est un graphique dirigé arbitrairement en mémoire, qui est similaire à un vidage d'une base de données orientée objet.

قنبلة -> dangereux -> 4anlyss
bomba -> dangereux
ambiguïté -> 4anlyss -> préemption -> قنبلة

Bien qu'un algorithme rentrant pour une version de renforcement soit tronqué et que le signal de bien-être soit déjà disponible, d'autres travaux ont anticipé sur la poursuite de l'analyseur adaptatif ou sur la prochaine étape pour utiliser le travail en langage naturel: faire correspondre les graphiques dirigés au graphique dirigé persistant des filtres représentant des idées, qui imiteraient l'aspect souvenir de la compréhension du langage.

Commentaires finaux

Le système a des composants et une architecture de processus similaires au problème d'analyse de journal et prouve les concepts énumérés ci-dessus. Bien sûr, plus la façon dont la journalisation est effectuée entre les développeurs du système effectuant la journalisation est désorganisée, plus il est difficile pour un agent humain ou artificiel de lever l'ambiguïté des entrées. Certains journaux système ont été si mal contrôlés pendant si longtemps que le journal est presque inutile.

Douglas Daseeco
la source