IMA5 2018/2019 P42 - Historique des versions

Nmehanna : /* Réalisation du Projet */

2019-03-01T12:24:34Z

‎Réalisation du Projet

Nmehanna : /* Documents Rendus */

2019-02-27T11:25:47Z

‎Documents Rendus

Nmehanna : /* Semaine 12 + Vacances (13&14) */

2019-02-27T09:11:54Z

‎Semaine 12 + Vacances (13&14)

Nmehanna : /* Semaine 21 */

2019-02-26T18:56:28Z

‎Semaine 21

Nmehanna : /* Documents Rendus */

2019-02-26T16:19:01Z

‎Documents Rendus

Nmehanna : /* Réalisation du Projet */

2019-02-25T19:29:47Z

‎Réalisation du Projet

Nmehanna : /* Documents Rendus */

2019-02-25T16:32:39Z

‎Documents Rendus

Nmehanna : /* Documents Rendus */

2019-02-25T16:32:12Z

‎Documents Rendus

Nmehanna : /* Semaine 19&20 */

2019-02-17T13:14:16Z

‎Semaine 19&20

Nmehanna : /* Réalisation du Projet */

2019-02-17T11:42:26Z

‎Réalisation du Projet

@@ Ligne 592 : / Ligne 592 : @@
 J'ai également pu mettre en place mon réseau de neurones, à la fois sur tensorflow et sur Keras. J'ai choisi de le réaliser en utilisant les deux frameworks en raison du fait que Keras permet la mise en place très rapide du réseau tandis que Tensorflow demande une connaissance plus détaillée et offre ainsi une plus grande maîtrise sur les paramètres du modèle. Sous Keras, le modèle est défini en une dizaine de lignes tandis que mon code utilisant tensorflow dispose de plus de 300 lignes de code :
+<div style="text-align: center;">
 [[Fichier:LSTM keras.png|500px]]
 Mon architecture est composée de deux couches de LSTMs composés de 128 couches cachés chacune, dans une configuration many-to-many : c'est à dire que le réseau va prendre une séquence en entrée et générer une séquence en sortie. Ces couches sont suivis d'une couche dense disposant d'une unique sortie de dimension 2 (une dimension pour l'axe des abscisses et une pour l'ordonnée), retournant un nombre situé entre 0 et 1 représentant le pourcentage de la position du curseur par rapport à la page.
@@ Ligne 607 : / Ligne 608 : @@
 Enfin, la semaine 19 à été conclus par l'execution avec succès de l'algorithme SARSA sur 500 épisodes (!), après m’être occupé du problème lié aux processus zombies. Le résultat permet clairement d'observer une tendance au fur et à mesure de l’exécution. Cependant, je trouve que ce n'est pas assez, en raison du fait que l'espace des états-actions est assez large, et 500 épisode n'est pas assez conséquent pour visiter toutes les paires d'état-action. Normalement, la parallélisation sur plusieurs machines devrait permettre de visiter d'avantage d'états et d'expérimenter d'avantage d'actions dans un temps réduit.
 L'architecture de ma vision de l'A3C adaptée à plusieurs machines est la suivante :
+<div style="text-align: center;">
 [[Fichier:A3C multiple machines architecture.png|600px]]
 ==Semaine 21==

← Version précédente		Version du 27 février 2019 à 11:25
Ligne 631 :		Ligne 631 :
	* '''Soutenance intermédiaire (le 18/12 à 21:50)''': [[Media:SoutenanceMiPFE P42.pdf\|Slides de soutenance intermédiaire]]		* '''Soutenance intermédiaire (le 18/12 à 21:50)''': [[Media:SoutenanceMiPFE P42.pdf\|Slides de soutenance intermédiaire]]
	* '''Rapport final de PFE (le 26/02 à 16:30)''' : [[Media:Rapport final naif mehanna.pdf\| Rapport final de projet]]		* '''Rapport final de PFE (le 26/02 à 16:30)''' : [[Media:Rapport final naif mehanna.pdf\| Rapport final de projet]]
		+	* '''Soutenance finale''': [[Media:Soutenance finale PFE FINAL P42.pdf\| Slides de soutenance finale]]

@@ Ligne 417 : / Ligne 417 : @@
 J'ai également écrit le rapport de mi-projet ainsi que réalisé les slides de soutenance.
-==Semaine 12 + Vacances (13&14)==
+==Semaine 12 + Interruption pédagogique (13&14)==
 Durant la semaine 12, qui est celle de la soutenance, j'ai du me concentrer d'avantage sur la finalisation de mon rapport et la préparation de la présentation. Cependant, à la suite de ma soutenance, j'ai pu me pencher d'avantage sur un problème dans mon algorithme : les proxies récupérés étants des proxies gratuits, venant de free-proxy.net, ils sont de mauvaise qualité et sont très rapidment blacklistés, ou non fonctionnels.

← Version précédente		Version du 26 février 2019 à 18:56
Ligne 611 :		Ligne 611 :

	==Semaine 21==		==Semaine 21==
		+
		+	Au cours de la dernière semaine, j'ai pu finaliser l'implémentation de mon approche face à l'algorithme A3C dans le but de paralléliser les crawlers. Le papier original de l'A3C préconise une utilisation de plusieurs threads afin d’accélérer l'apprentissage. Mon approche utilise plusieurs machines différentes afin que les environnements évoluent tous sous une adresse IP différente. L'obstacle résidait dans la communication entre les différentes machines et le partage de l'expérience obtenue par chaque crawler. Le papier original utilise des variables globales partagés entre plusieurs threads, ce qui n'est pas possible dans notre cas. Un second obstacle résidait dans le fait que les implémentation de l'algorithme A3C original est réalisée en Python, et utilisant l'API Python de Tensorflow, qui est la plus complète.
		+	Travaillant sous NodeJS et Javascript, je n'avais d'autre choix que d'utiliser le module Tensorflow.JS, disposant de moins de fonctionnalités, ce qui levait un troisième obstacle : l'A3C original préconise de réaliser manuellement la phase de mise à jour des paramètres du réseau de neurone (c'est à dire, sans utiliser les fonctions d’entraînement tels que model.fit() sous TensorflowJS), et donc, de calculer la perte du réseau de neurone manuellement , en utilisant les fonctions mathématiques élémentaires de calcul matriciel, et de calculer les dérivée partielles de cette perte, encore une fois, manuellement.
		+	Les solutions que j'ai ainsi adoptés sont :
		+
		+	* Mise en place d'un serveur HTTP permettant d'instaurer une communication HTTP entre les machines, afin de partager les variables, tels que le meilleur score, l'épisode cumulé à l'instant t, et, le plus important, le transfert des paramètres des réseaux de neurones locaux au réseau de neurone global (voir schéma de la semaine 20). Les appels sont tous bloquants afin d'éviter un conflit d'écriture. Ainsi, si l'on a deux même requêtes HTTP simultanées, elles sont traités de manière séquentielle et non asynchrone.
		+
		+	* Mise en place d'un réseau de neurones pour l'acteur et un réseau de neurones pour la critique, ce qui permet de simplifier les formules de calcul des pertes et le calcul des dérivées partielles. Au final, si l'on dispose de deux réseaux de neurones, la perte associée au critique est simplement une application de la formule Mean Squarred Error (MSE), et la formule de perte Categorical cross-entropy pour l'acteur.
		+
		+	Enfin, j'ai pu tester l'algorithme mis en place, et vérifier son fonctionnement avec 3 crawlers parallèles sur 3 machines virtuelles installés sur mon PC. Cependant, je n'ai pas pu tester ce dernier à l'INRIA sur différentes machines virtuelles en raison d'une panne électrique dans le local informatique.

	=Documents Rendus=		=Documents Rendus=

@@ Ligne 616 : / Ligne 616 : @@
 * '''Git du test''' (une branche pour chaque modèle): https://github.com/naifmeh/smartbot
 * '''Git du crawler en conditions réelles''' (plusieurs branches): https://github.com/naifmeh/smartbotjs
 * '''Rapport intermédiaire de PFE (le 17/12 à 20:31)''' : [[Media:Rapport intermediaire de PFE.pdf|Rapport de mi-projet]]
 * '''Soutenance intermédiaire (le 18/12 à 21:50)''': [[Media:SoutenanceMiPFE P42.pdf|Slides de soutenance intermédiaire]]
-* '''Git de l'extension''': https://github.com/naifmeh/mouselogger
+* '''Rapport final de PFE (le 26/02 à 16:30)''' : [[Media:Rapport final naif mehanna.pdf| Rapport final de projet]]

← Version précédente		Version du 25 février 2019 à 19:29
Ligne 609 :		Ligne 609 :

	[[Fichier:A3C multiple machines architecture.png\|600px]]		[[Fichier:A3C multiple machines architecture.png\|600px]]
		+
		+	==Semaine 21==

	=Documents Rendus=		=Documents Rendus=

← Version précédente		Version du 25 février 2019 à 16:32
Ligne 616 :		Ligne 616 :
	* '''Rapport intermédiaire de PFE (le 17/12 à 20:31)''' : [[Media:Rapport intermediaire de PFE.pdf\|Rapport de mi-projet]]		* '''Rapport intermédiaire de PFE (le 17/12 à 20:31)''' : [[Media:Rapport intermediaire de PFE.pdf\|Rapport de mi-projet]]
	* '''Soutenance intermédiaire (le 18/12 à 21:50)''': [[Media:SoutenanceMiPFE P42.pdf\|Slides de soutenance intermédiaire]]		* '''Soutenance intermédiaire (le 18/12 à 21:50)''': [[Media:SoutenanceMiPFE P42.pdf\|Slides de soutenance intermédiaire]]
		+	* '''Git de l'extension''': https://github.com/naifmeh/mouselogger
		+	* '''Git de l'API REST utilisée par l'extension''': https://github.com/naifmeh/mouselogger_rest

← Version précédente		Version du 17 février 2019 à 13:14
Ligne 584 :		Ligne 584 :

	==Semaine 19&20==		==Semaine 19&20==
		+
		+	Lors de la semaine 19, je me suis notamment intéressé à l'amélioration de l'extension web réalisée, ainsi que la mise en place du réseau de neurones. Les améliorations de l'extension dispose des points suivants :
		+
		+	* Obtention des scrollHeight et scrollWidth, afin d'obtenir la taille réelle de la page, et non seulement de la fenêtre visible. J'ai remarqué dans les données enregistrés que parfois, la taille renvoyée était bien inférieur à la position x ou y du curseur de la souris.
		+
		+	* Le point précédent permet de générer des pourcentages représentant la position du curseur par rapport à la page. Par exemple, si le curseur est aux positions (100, 100) d'une page dont la taille est de (1000, 1000), nous pourrons représenter sa position par (0.1,0.1), ce qui permet de normaliser les données pour le réseau de neurones entre 0 et 1 (normalisation nécessaire).
		+
		+	J'ai également pu mettre en place mon réseau de neurones, à la fois sur tensorflow et sur Keras. J'ai choisi de le réaliser en utilisant les deux frameworks en raison du fait que Keras permet la mise en place très rapide du réseau tandis que Tensorflow demande une connaissance plus détaillée et offre ainsi une plus grande maîtrise sur les paramètres du modèle. Sous Keras, le modèle est défini en une dizaine de lignes tandis que mon code utilisant tensorflow dispose de plus de 300 lignes de code :
		+
		+	[[Fichier:LSTM keras.png\|500px]]
		+
		+	Mon architecture est composée de deux couches de LSTMs composés de 128 couches cachés chacune, dans une configuration many-to-many : c'est à dire que le réseau va prendre une séquence en entrée et générer une séquence en sortie. Ces couches sont suivis d'une couche dense disposant d'une unique sortie de dimension 2 (une dimension pour l'axe des abscisses et une pour l'ordonnée), retournant un nombre situé entre 0 et 1 représentant le pourcentage de la position du curseur par rapport à la page.
		+	En écrivant ces lignes, je remarque que je n'ai pas prévu une entrée pour la taille de la page, que j'ajoute dès que possible en parallèle à la dernière couche LSTM et en entrée de la couche dense.
		+
		+	Sous Keras, l'entraînement est simple : il suffit de récupérer le dataset et de le diviser en trois sub-dataset : training, validation et test, puis d'appeler la fonction model.fit() sur le modèle créé. Sous Tensorflow, l'entraînement est plus manuel et requiert une compréhension plus avancée de la phase d'entraînement, allant de la définition et du calcul de la perte, jusqu'à la maîtrise du nombre de threads utilisés par l'entraînement.
		+
		+	Enfin, nous avons décidés de se lancer définitivement dans la mise en place de l'algorithme de parallélisation des crawlers en utilisant le reinforcement learning. J'ai pu lire deux papiers de recherches décrivant une démarche permettant de paralléliser les crawlers sur différents threads.
		+	Connaître et comprendre leur approche me permettra de mettre en place l'architecture nécessaire à une parallélisation sur plusieurs machines. Les deux papiers m'ayant parus utiles sont les suivants :
		+	* [https://arxiv.org/pdf/1602.01783.pdf\| Papier original de l'A3C]
		+	* [https://arxiv.org/abs/1705.04862\| Amélioration du papier précédent]
		+
		+	Enfin, la semaine 19 à été conclus par l'execution avec succès de l'algorithme SARSA sur 500 épisodes (!), après m’être occupé du problème lié aux processus zombies. Le résultat permet clairement d'observer une tendance au fur et à mesure de l’exécution. Cependant, je trouve que ce n'est pas assez, en raison du fait que l'espace des états-actions est assez large, et 500 épisode n'est pas assez conséquent pour visiter toutes les paires d'état-action. Normalement, la parallélisation sur plusieurs machines devrait permettre de visiter d'avantage d'états et d'expérimenter d'avantage d'actions dans un temps réduit.
		+	L'architecture de ma vision de l'A3C adaptée à plusieurs machines est la suivante :
		+
		+	[[Fichier:A3C multiple machines architecture.png\|600px]]

	=Documents Rendus=		=Documents Rendus=

← Version précédente		Version du 17 février 2019 à 11:42
Ligne 582 :		Ligne 582 :

	Je pense également à paralléliser les crawlers en utilisant l'algorithme A3C, pour Asynchronous Advantage Actor Critic, qui, comme son nom l'indique, permet de paralléliser les agents, tout en utilisant la même base pour le choix des actions (les même réseaux de neurones pour l'acteur et la critique).		Je pense également à paralléliser les crawlers en utilisant l'algorithme A3C, pour Asynchronous Advantage Actor Critic, qui, comme son nom l'indique, permet de paralléliser les agents, tout en utilisant la même base pour le choix des actions (les même réseaux de neurones pour l'acteur et la critique).
		+
		+	==Semaine 19&20==

	=Documents Rendus=		=Documents Rendus=