Fast and Furious Decision Tree Induction

Fast and Furious Decision Tree Induction
Projet 4INFO INSA Rennes Fast and Furious Decision Tree Induction Andra BLAJ Nicolas DESFEUX Emeline ESCOLIVET Simon MANDEMENT Renaud PHILIPPE Gareth THIVEUX Encadreurs : Nikolaos PARLAVANTZAS Christian RAYMOND le 17/12/10

Contexte Technologies utilisées lors du projet Apprentissage automatique Arbres de décision MapReduce Hadoop Spécifications fonctionnelles Données présentes en entrée Données en sortie L’application Planification initiale Conclusion

Contexte Origines du projet
Projet lié aux activités de recherche de l’IRISA. Équipe Texmex: exploitation de documents multimédia. Équipe Myriads: développement et administration de systèmes distribués à large échelle.

Contexte Objectifs Objectifs Développer un algorithme capable de faire de l’apprentissage automatique. Créer des arbres aidant à la décision. Réduire le temps d’exécution. Généraliser le fonctionnement pour l’adapter à plusieurs domaines. La problématique est: le volume des données à traiter est gigantesque (vidéo, fichiers textes). Donc il faut des outils capables de faire de l’apprentissage automatique sur de grands volumes de données. But du projet: développer un algorithme capable de le faire. Ensuite, plus précis: un arbre de décision. Fil rouge: un exemple « jouet » = la base de données médicale. Algo générique capable de traiter de gros volumes de données (d'ou l'association myriad texmex) (donner un exemple d'utilisation par exemple le repérage des entités nommées dans le texte noms de personnes, de dates, de lieu pour après les exploiter dans la recherche documentaire ou le résumé automatique de texte, la traduction etc) les gens ne connaissent pas forcement l'apprentissage automatique et ne savent pas a quoi on peut l'appliquer

Technologies utilisées 1. Apprentissage automatique
Définition - Fonctionnement Discipline dans laquelle un outil est capable d’apprendre par lui-même à partir d’une base de données d’exemples. Forme d’intelligence artificielle. Discipline de l’informatique où un outil est capable d’apprendre par lui-même. Etiqueter, Classer des exemples dont on connaît les caractéristiques. C’est-à-dire de reproduire des comportements qu’il aura déjà vu ou déduit. On peut comparer ça à une sorte d’intelligence artificielle. Pour effectuer un apprentissage automatique, il faut une base de données d’exemple, Il existe plusieurs type d’apprentissage automatique : plus ou moins supervisé. Sur un ensemble d’exemples, on peut distinguer plusieurs cas : Pour chaque exemple, on connaît l’étiquette qui y est associé. Supervisé. L’outil n’a pas besoin de créer de nouvelles étiquettes. Au contraire, dans le cas d’un apprentissage automatique non supervisé, il faut créer de nouvelles étiquettes. Regrouper les individus ayant les mêmes caractéristiques. Plusieurs étapes : Observation, Construction, Utilisation.

Technologies utilisées 2. Arbres de décisions : tableau de données
Age Boutons IMC Observations Diagnostic 25 OUI 19 Mal à la tête Rhume 46 NON 26 Tousse 37 17.9 Fièvre Grippe 68 22 Plaques dans le dos Eczéma 51 35 18 17 Exemple : base de données médicales. Symptômes, diagnostic. Il y a du texte, des nombres,… Outils devra être capable de générer un arbre à partir de ce type de données,

Technologies utilisées 2. Arbres de décisions : arbre construit
Arbre construit à partir du tableau de données Facile à comprendre et à utiliser. Arbre ayant à chaque fois deux sous arbres. Question binaire uniquement. Exemple : un patient : à des boutons ? Oui. A moins de 24 ans ? Oui. => Plus forte probabilité d’avoir une grippe. Pour aider l’homme, pas pour le remplacer ! L’idée est qu’à chaque nœud, on doit avoir un réduction de l’entropie : entropie : mesure du désordre => données de mieux en mieux organisé.

Technologies utilisées. 2
Technologies utilisées 2. Arbres de décisions : algorithme parallélisable Arbres de décisions Algorithme aisément parallélisable au niveau des calculs: Au niveau des nœuds Au niveau des questions Nécessité d’utiliser un modèle de parallélisation: MapReduce. Algorithme aisément parallélisable: On peut paralléliser les calculs : Au niveau des nœuds : Chaque nœud peut être indépendaments des autres. Au niveau des questions : Pour chaque nœud, on va chercher la meilleur question, celle qui réduit l’entropie au maximum : On peut parraléliser cette recherche de question est uniquement comparer l’entropie à la fin. Utiliser un modèle de parallélisation : MapReduce

Technologies utilisées 3. MapReduce : map
Partie Map Opération exécutée en parallèle Chaque nœud travaille indépendamment des autres, sur une partie du fichier d’entrée. Traitement différent selon le type: Discrète, Continue ou Texte. Il faut parler plus de Google et Facebook -> ils utilisent des quantités faramineuses de données.

Technologies utilisées 3. MapReduce : reduce
Partie Reduce Partitionnement des données. Multiprocessus. Nœuds esclaves font remonter l'information. Groupement des couples ayant la même clé. Le nœud origine peut, à la fin de l'opération Reduce, donner une réponse. Chaque partie peut être traitée par un cœur du processus différent.

Technologies utilisées 4. Hadoop : présentation
Projet libre qui permet une implémentation de MapReduce. Un nœud maître et des nœuds esclaves. Fractionnement du traitement sur différentes machines.

Technologies utilisées 4. Hadoop : fonctionnement
Système de fichiers distribué propre à Hadoop. Répartition des données entre les Datanodes. Assignation des tâches aux nœuds esclaves. Retour du résultat au nœud maître.

Technologies utilisées Parallélisation
Exemple de fonctionnement de MapReduce, pour compter les occurrences de mots dans un texte. Fichier d’entrée: 1. savoir être et 2. savoir faire 3. sans faire savoir

Technologies utilisées Solution envisagée
Spécification importante du projet → réduire le temps de construction des questions et du parcours de l’arbre. Solution envisagée → utilisation d’un cluster de machines via Hadoop (de manière plug-and-play). Parallélisation – répartition de plusieurs "job" sur plusieurs machines connectées. Lors de ce projet, nous demanderons à nos machines d’effectuer des calculs très longs. L’une des spécifications de ce projet est de réduire le temps de construction des questions de notre arbre de décision, ainsi que le temps de parcours de celui-ci. En utilisant une seule machine, il serait difficile de construire rapidement ces arbres de décision. C’est pourquoi notre seconde méthode de parallélisation consistera en l’utilisation d’un cluster de machines. Et encore une fois c’est Hadoop qui va nous permettre de le réaliser. Hadoop permet également la répartition de plusieurs "job" sur plusieurs machines connectées. Hadoop utilise pour cela un nœud maître qui envoie les "job" à effectuer à des nœuds esclaves qui effectuent ces tâches puis renvoient le résultat.

Spécifications fonctionnelles 1. Données présentes en entrée : données
Données en entrée 3 types de descripteurs: discrete : données faisant partie d’une liste prédéfinie (ex: « oui », « non », « peut être »); continuous : valeurs numériques ordonnées (ex : IMC); text : phrases ou expressions; « Fast and Furious Decision Tree Induction » est une application générique qui doit pouvoir traiter des données issues de divers domaines (bioinformatique, ensemble de textes, etc.). C’est pourquoi nous allons développer afin de pouvoir traiter trois types d’attributs différents: – discrete : ce qui signifie que les données présentes dans cette colonne devront forcément faire partie d’une liste prédéfinie (ex : oui, non, je ne sais pas), – continuous : valeurs numériques ordonnées (par exemple, dans notre base médicale : l’IMC), – text : ce qui veut dire que les informations présentes dans ces colonnes sont des phrases, des expressions (par exemple : « merci NCMS joël PRENOM collado NPI »est une expression que l’on peut être amené à rencontrer.

Spécifications fonctionnelles. 1
Spécifications fonctionnelles 1. Données présentes en entrées : fichiers Fichiers en entrée Grippe, Rhume. age : continuous : ignore. boutons : discrete : cutoff = 15. imc : continuous. observation : text. 2 fichiers en entrée: - fichier descripteur: la liste des annotations possibles une description du contenu du fichier de données une description du type des descripteurs ou des attributs - fichier de données : les données et les annotations associées L’application recevra les données en entrée sous forme de deux fichiers. Un fichier « .data » contiendra les données et les annotations associées et un fichier « .names » détiendra la liste des annotations possibles et une description du contenu du fichier de données, du type des descripteurs ou des attributs. Nous allons donc décrire plus précisément le contenu de ces deux fichiers. Dans le fichier « .names », la première ligne correspond à la liste de l’ensemble des annotations que l’on peut trouver dans la base de données. Comme dans le premier fichier, chaque annotation est séparée par une virgule et la liste se finit par un point. Nous pourrons trouver ensuite, dans le fichier, une description des colonnes (type, caractéristique). nom_colonne : type_colonne : options_facultatives Le fichier « .data » contient l’ensemble des exemples que l’on veut fournir à l’application. Dans le fichier .data, chaque ligne représente un exemple. (ex: un ligne se décompose de la façon suivante : Age, toux, maux de tête, IMC 1, diagnostic) Les caractéristiques (dans un ordre précis) et l’annotation (unique, et toujours en fin de ligne), sont séparés par des virgules. Un point en fin de ligne permet d’indiquer le fin de l’exemple. Cette syntaxe particulière est importante pour permettre une bonne lecture du fichier en entrée. En effet, l’ordre des caractéristiques, leur type, et leurs particularités sont décrites dans le fichier « .names », il est donc important que le fichier « .data » soit correctement renseigné, afin que chaque colonne puisse être correctement identifiée. 25, Oui, 19, Mal à la tête, Rhume. 46, Non, 26, Tousse, Grippe. 37, Non, 17.9, Fièvre, Rhume.

Spécifications fonctionnelles 2. Données en sortie : format XML
<? xml v e r s i on =" " e n c o d i n g ="UTF-8" ?> <Tree> <Node id =" 1 "> <Result > < !-- compte-rendu des etiquettes . --> <Result number=“1" name=“grippe" percentage=“50" / > < !– Exemple de resultat --> <Question . . >+ < !-- question qui amenera a la creation de ces noeud --> <Question column=" Fumeur " value=“oui" entropy =" 1 " nbOcuurence=" 12 "> < !-- Exemple de question --> <TrueNode id="2" / > <!– noeud où la réponse à la question est “oui” --> <Result...> <Question...> <FalseNode id="3" / >  </Node> </Tree> Notre application doit être capable de générer un fichier de sortie utilisable. L’objectif est de rendre un fichier que l’utilisateur pourra consulter : avoir une vision de ce qu’est l’arbre, et pouvoir l’interroger (lui fournir les caractéristiques, et avoir l’étiquette la plus probable). Nous avons donc choisi de représenter notre arbre de décision sous forme d’un fichier XML, format qui nous permettra de définir facilement la structure de nos arbres, créant ainsi un fichier lisible décrivant les résultats et les probabilités d’obtenir ce résultat. Le XML nous permettra d’obtenir en sortie un fichier qui n’est pas « opaque » donc facilement analysable, et surtout utilisable en dehors de l’application. De plus, c’est un format très répandu et utilisé, et donc probablement mieux reconnu et compris par les utilisateurs, et pour lequel il existe beaucoup d’outils. Pour pouvoir naviguer dans l ’arbre, on utilise un id associe a chaque Noeud de l ’arbre.

Spécifications fonctionnelles. 2
Spécifications fonctionnelles 2. Données en sortie : visualisation graphique Données en sortie Visualisation graphique Notre application doit être capable de générer un fichier de sortie utilisable. L’objectif est de rendre un fichier que l’utilisateur pourra consulter : avoir une vision de ce qu’est l’arbre, et pouvoir l’interroger (lui fournir les caractéristiques, et avoir l’étiquette la plus probable). Nous avons donc choisi de représenter notre arbre de décision sous forme d’un fichier XML, format qui nous permettra de définir facilement la structure de nos arbres, créant ainsi un fichier lisible décrivant les résultats et les probabilités d’obtenir ce résultat. Le XML nous permettra d’obtenir en sortie un fichier qui n’est pas « opaque » donc facilement analysable, et surtout utilisable en dehors de l’application. De plus, c’est un format très répandu et utilisé, et donc probablement mieux reconnu et compris par les utilisateurs, et pour lequel il existe beaucoup d’outils. Pour pouvoir naviguer dans l ’arbre, on utilise un id associe a chaque Noeud de l ’arbre.

Spécifications fonctionnelles 3. L’application
Concrètement, notre application fonctionnera ainsi : – étape no 1 : L’application lit les fichiers en entrée et génère toutes les questions possibles à partir de la base de données et des paramètres précisé par l’utilisateur. Nous pouvons donc trouver des questions sur des données discrètes, continues ou encore textuelles. Une fois toutes les questions générées, nous pouvons alors calculer l’entropie liée à chaque réponse et ainsi en déduire le gain en entropie du découpage qu’elles permettent d’obtenir si nous choisissons de poser telle ou telle question. – étape no 2 : Après avoir effectué tous ces calculs, nous pouvons donc enfin décider de la meilleure question à poser, c’est-à-dire celle qui apporte le meilleur gain en entropie en application. Une fois, la question à poser trouvée, nous passons à l’étape no 3. Cependant plusieurs cas signifient l’arrêt de l’algorithme. Tout d’abord, si l’ensemble des individus impliquent le même résultat ou encore s’il n’y a plus de question à poser ou que le gain en entropie est nul ou insuffisant (seuil défini par l’utilisateur). Dans ces cas, nous passons à l’étape no 5. – étape no 3 : Nous entamons cette étape no 3 si et seulement si une question a pu être posée et donc si aucun fichier XML n’a été généré. Cette étape consiste à récupérer la base de données sur laquelle la question est posée et à la diviser en deux. Les deux parties présentes sont définies par les réponses à la question. – étape no 4 : On va parcourir le fichier des données (.data) pour pouvoir générer toutes les questions possibles, à l’exception près que le fichier des données concerné sera celui de l’arbre fils, c’est-à-dire qu’on parcourra les bases de données des deux fils, afin de construire un arbre complet. De plus, un nouveau tri sera effectué sur l’ensemble des questions générées (car une question ne peut pas être posée deux fois). Après avoir effectué ce tri, nous pouvons donc calculer l’entropie et le gain en entropie de chaque question. Une fois cette étape achevée, on retourne à l’étape no 2 pour chacun des deux fils. – étape no 5 : L’algorithme des arbres de décision ayant abouti, il ne nous reste plus qu’à afficher le ou le(s) résultats trouvé(s). Ces derniers sont alors générés dans le format xml vu dans la première partie de ce rapport. On peut aussi trouver dans ce fichier toutes les étapes et toutes les questions qui ont été posées pour arriver à ce(s) résultat(s).

Planification initiale Calendrier, ressources et tâches
Calendrier : - 7h par semaine - entre 25 et 28h en semaine de projet - ajout de semaines de congés (semaine de partiels, vacances de Noël …) Ressources : 6 personnes, ayant chacune la même charge, mais avec différentes responsabilités Détermination des tâches : 5 phases, chacune divisées entre 3 et 5 tâches, elles-mêmes découpées en sous-tâches et sous-sous-tâches Estimation des durées : - 1re estimation basée sur le temps déjà passé sur les tâches - 2ème estimation grâce au Planning Poker Afin de d’établir notre planning, il nous a donc tout d’abord fallu spécifier un calendrier de travail. Nous avons estimé et nous nous sommes mis d’accord sur 7h de travail passées sur le projet par semaine par personne, exception faite des semaines de projet durant lesquelles 25h à 28h de travail pourront être consacrées au projet. Je dis bien estimé, car nous avons pu basé celà sur un décompte précis des horaires de travail rempli par chacun et tenu à jour jusque-là. Nous avons enfin ponderés tout celà par des semaines dites de congés, à savoir des jours chômés pour les semaines de partiels ou encore pour certains jours des vacances de Noël par exemple. Nous avons ensuite aisément déterminer les ressources, à savoir 6 personnes parties prenantes du projet = 6 ressources, ayant chacune la même charge de travail, mais avec différentes responsabilités (désignation des responsables de phases …). La répartition des tâches s’effectuera donc ultérieurement lors de la phase de conception. Il a fallu ensuite établir un listing des tâches, le plus détaillé possible à partir de notre vision des choses actuelle. Les tâches se répartissent donc en 5 phases, à savoir les phases d’analyse, de conception, de planification, de construction et de déploiement/livraison. Chaque phase est donc découpée en 3 à 5 tâches, elles-mêmes divisées en sous-tâches et sous-sous-tâches. Enfin il a fallu estimer la charge par tâche. Nous avons pu établir une première estimation grâce au décompte de temps passé sur le projet dont je vous ai parlé précédemment, notamment pour les temps passés sur les rapports. Nos connaissances en Java nous ont permis également d’affiner nos estimations quant aux tâches de la phase de construction. Mais nous avons avant tout pu affiner nos estimations grâce à la méthode du Planning Poker. C’est une méthode qui nous a été présenté par Mr. Yvon Bréhut, ingénieur chez Technicolor, lors d’une conférence donnée à notre attention il y a peu. Cette méthode d’estimation consiste en la distribution de cartes à chacun des participants (donc aussi bien les responsables que les développeurs), ces cartes portant des valeurs représentant une durée (dont l’unité, heures – jours – semaines, est à établir). Chacun des participants propose alors après réflexion, et en même temps, une carte avec la durée qu’il estime nécessaire pour réaliser la tâche. Les deux participants ayany proposés les valeurs extrêmes, la plus forte et la plus faible, débattent alors et exposent leurs arguments au groupe. Se basant sur ces nouveaux arguments, les joueurs reffectuent une estimation jusqu’à consensus, ce qui dans notre cas, a abouti au bout de deux ou trois itérations.

Planification initiale Tâches et diagramme de Gantt
Voici donc le découpage et l’ordonnancement de nos phases et première indentation de tâches. On voit donc sur la partie droite l’agancement de ses phases/tâches au fil de l’année. Le trait orange représentant la date actuelle, on observe donc que la phase d’analyse est terminée, que celle de conception est bien entamée et que la phase de planification a tout juste commencé. On peut remarquer également un avancement notoire dans la phase de construction, qui correspond en fait à disons une phase de “prototypage” afin de pouvoir étudier les différentes solutions aux problématiques du sujet.

Planification initiale Risques et suivi de planification
Analyse des risques : Chemin critique à définir pour prévenir tout retard sur la date finale du projet Prévenir le risque de la perte de données : SVN sur GoogleCode, Forge INSA, copies locales Difficultés et éventuels problèmes techniques lors de la mise en place de la parallélisation, utilisation du cluster Hadoop, pannes de PC Suivi de planification : Rectification et mise à jour du planning. Affinage de la planification lors de la phase de construction. Il a ensuite fallu, pour compléter notre planification, procéder à une analyse des risques. Pour prévenir tout retard, il nous a donc par exemple fallu définier un chemin critique, pour prévenir tout retard sur la date finale du projet, et donc évaluer et affecter des priorités différentes à certaines tâches, par exemple jugées comme facultatives ou compressibles. On peut également citer le risque de perte de données. C’est donc un risque que nous minimisons en multipliant tout simplement les copies de travail : sous l’espace de stockage mis gratuitement à disposition par GoogleCode, sur la Forge INSA récemment créée ou encore tout simplement avec des copies en local. On peut enfin aborder le risque de rencontrer des difficultés ou des problèmes techniques lors de la phase de mise en place de la parallélisation, l’utilisation d’un cluster de machines, les éventuelles pannes de PC. Il ne faut enfin pas négliger le bon suivi de la planification en rectifiant et mettant à jour régulièrement le planning, notamment à la fin de la phase de conception et au fur et à mesure de la phase de construction,

Planification initiale Prototypes
Ce que nous avons réalisé : Lecture et analyse des fichiers d’entrée. Génération de tous les types de questions. Agrégation des réponses pour les questions discrètes et continues. Génération d’un fichier qui contient toutes les questions. Pour pouvoir étudier les solutions aux problématiques du projet, nous avons du réaliser des prototypes. Lecture et analyse des fichiers d’entrée (volume de données (+ d’un million de lignes)), génération des questions, agrégations des réponses (telle question mène tant de fois l’étiquette X, tant de fois l’étiquette Y) . Fournir un fichier en sortie avec toutes les questions, et les statistiques associées.

Conclusion Fast and Furious Decision Tree Induction :
Projet à l’origine d’équipes de l’IRISA. Création d’arbres aidant à la décision. Traitement des fichiers de données volumineux grâce à une parallélisation des calculs. Réussite et respect des délais « If you fail to plan then you plan to fail » => une bonne planification et un suivi régulier. - Projet à l’origine d’équipes de l’IRISA, travail combiné des équipes Texmex et Myriads. - Création d’arbres aidant à la décision, reproduction du comportement d’un expert - Généralisation du fonctionnement pour l’adapter à tous les domaines : bioinformatique, textes, génétique, - Traitement des fichiers de données volumineux grâce à une parallélisation des calculs gérée par la technologie Hadoop/MapReduce Réussite et respect des délais passent par une bonne planification et un suivi régulier. Comme on dit : « If you fail to plan, then you plan to fail ».

Fast and Furious Decision Tree Induction

Présentations similaires

Présentation au sujet: "Fast and Furious Decision Tree Induction"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Fast and Furious Decision Tree Induction

Présentations similaires

Présentation au sujet: "Fast and Furious Decision Tree Induction"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back