Littérature : Handbook of Neuroevolution through Erlang, de Gene I. Sher, édition Springer.

Mes maigres connaissances en littérature mathématique ont été un grand frein dans ma compréhension des réseaux de neurones. En effet, la plupart des livres traitant du sujet sont particulièrement centrés sur les théories mathématiques qui en décrivent les rouages, les preuves de leur efficacité, leurs applications dans les domaines statistiques ou même les différentes fonctions d’activation. Ces informations, j’en conviens, sont particulièrement importantes pour défendre l’usage des réseaux de neurones devant des décideurs, mais cela n’apporte pas grand chose quant à leur intégration dans une application.

C’est en cela que le livre de Gene I. Sher est très intéressant.

En effet, il traite essentiellement de l’application « Réseau de Neurones » et de la mise en place de conditions d’entrainement. Le livre ayant été publié courant 2011, ces informations sont encore d’actualité.

Au cours de la lecture du livre nous y apprenons :

Les bases du réseau de neurones et des techniques de programmations « intelligentes »

On y découvre le fonctionnement des réseaux de neurones, les différentes méthodes d’entraînement utilisées jusque là, ainsi que leurs avantages et leurs défauts. Gene I. Sher nous y présente une introduction aux algorithmes génétiques et aux stratégies évolutives car le réseau de neurones ne se suffit pas à lui même.

Une présentation rapide d’Erlang et de ces avantages pour la mise en place d’un réseau de neurones

Les principaux avantages cités sont les suivants :

Encapsulation : La propagation d’une erreur est limitée.

Concurrence : Il est très facile de lancer de multiples processus, et la communication entre eux y est aisée.

Gestion d’erreurs : Il est possible pour un processus d’en observer un autre afin d’être au courant lorsque des erreurs apparaissent.

Chargement de code dynamique : Il est possible de mettre à jour le code de l’application sans l’arrêter. Pour le coup, il est vrai que c’est possible avec Erlang (et Elixir), même si je trouve cela peu applicable à notre contexte.

Mise en place d’une plateforme simple d’entrainement de réseaux de neurone.

L’auteur prend le parti de construire cette plateforme en mettant en concurrence un certains nombres de réseaux sur une même tâche, évaluant et les modifiants alors automatiquement jusqu’à obtenir une solution optimum. Gene I. Sher nous accompagne pas à pas, présentant les différents problèmes et proposant des solutions pour chacun en y associant du code Erlang.

Malgré les quelques pages explicatives en préambules de chaque extrait de code, la syntaxe du langage particulièrement ingrate rend parfois difficile sa compréhension et il n’est alors pas aisé de suivre tout ce qui s’y passe !

L’Évolution de cette plateforme vers les dernières évolutions techniques.

Ici, l’auteur propose tout un tas d’outils qui autorisent une meilleur observation de la plateforme ainsi que d’autres approches du réseau de neurones. Ainsi ils permettent à cette dernière d’héberger des réseaux de tailles conséquentes, composés de plusieurs milliers de neurones, voir de plusieurs millions, tout en conservant une stabilité du système.

Ce passage est toujours particulièrement compliqué pour moi, je dois avouer ne pas l’avoir entièrement compris pour le moment, et j’admets que cela sera probablement plus clair une fois que j’aurai commencé à construire cette partie la de l’application !

Quelques exemples d’applications faisant appel directement a cette plateforme.

Pour finir son livre, Gene I. Sher présente deux exemples d’applications :

La première ALife est proche de ce que nous allons essayer de mettre en place ici. C’est-à-dire, une plateforme d’évolution de « créature » dans un environnement synthétique. Nous allons nous appuyer un peu sur cette présentation, même si mes objectifs sont quelques peu différents.

La deuxième est une application plus orientée finance sur la mise en place d’un agent boursier.


 

Pour conclure, ce livre est très bien pour avoir une approche concrète des réseaux de neurones. Il fournit de bonnes bases et des exemples solides. De plus, comme il est très récent, il est très proche des technologie qu’on utilise aujourd’hui. L’auteur poursuit le développement de sa plateforme DXNN présentée elle aussi dans cet ouvrage.

L’approche que je compte employer pour le développement de CreepCamp en tant que service sera quelque peu différente, simplement parce que aujourd’hui, Docker et la Conteneurisation sont des technologies montantes, trop importantes pour qu’on puisse se permettre de passer a coté. Les applications entièrement monolithiques comme celles construites par l’auteur ne sont pas forcement adaptées, car elles nécessitent matériellement une machine excessivement performante. Alors que maintenant, il est totalement vraisemblable d’héberger une centaine ou un millier d’applications sur un cloud de Google ou d’Amazon, en utilisant une petite architecture et des canaux de communications centralisés, gérés par le système et non pas par le logiciel.

Ticket #4: Planning !

Attaquons nous enfin aux choses intéressantes !

Nous aborderons dans les tickets suivants les bases des réseaux de neurones, leur fonctionnement, leur mise en place avec Elixir et leur intégration dans notre système creepcamp. Nous verrons la communication inter process avec Elixir dans une autre partie.

Dans ce ticket, plus particulièrement, nous allons aborder l’intégration et la planification du système.

Vue macroscopique

Nous aurons les trois services suivants :

  1. Les arènes de combats et leur gestion
  2. Les Creep.
  3. Le mecanisme d’évolution des creeps.

Les arènes de combats et leur gestion nous avons déjà commencé à les voir de manière excessivement superficielle avec les tickets concernant Phoenix et Ecto. Cette partie va évoluer quelque peu dans les prochaines semaines pour fournir une interface minimaliste mais suffisante pour réserver et démarrer des arènes. Elle permettra aussi de mettre en relation les participants et l’arènes dans laquelle ils vont combattre, tout en exécutant l’arène.

L’arène c’est là où les neurones vont « vivre », c’est leur « réalité ». C’est aussi ce service qui va faire le job de juger et donner le score. A terme, nous aurons plusieurs juges pour évaluer plusieurs types de comportements.

Le service Creep correspond aux réseaux de neurones parlés. C’est ce sur quoi nous allons commencer à travailler dans les jours qui viennent. Les creeps seront responsables de leur propre entraînement. Les juges des arènes fourniront des appréciations concernant l’efficacité des creeps qui leurs serviront de point de repère pour savoir si ils évoluent correctement.

Le mécanisme d’évolution des creeps entrera en action beaucoup plus tard. Il permettra une étude des populations de creeps, de leur sélection et de de mutation pour produire de meilleurs creeps plus efficace.

CreepCamp

Un des premiers objectifs de se découpage est de séparer certaines responsabilités. Ainsi le code nécessaire a l’exécution d’un Creep est complètement indépendant et peux être intercalé par n’importe qui, ce qui nous arrange beaucoup étant donné que n’importe qui peux s’inscrire au service.

Une autre chose est à noter : la ferme de creeps, ainsi que les autres services, seront gérés et surveillés, de façon à s’assurer que les creeps n’utilisent qu’un nombre limité de ressources CPU et mémoire. De plus, il faudra prévoir une interface web pour chacun des services afin d’avoir un retour direct sur l’usage et l’évolution des choses, et peut-être même nous permettre d’intervenir facilement sur certaines opérations.

Continue reading

Ticket #3.2 : Elixir, les bases – Partie II

Au programme de ce deuxième ticket sur les bases d’Elixir :

Les fonctions : On en a déjà utilisé quelques unes, je vais vous indiquer les quelques méthodes pour en créer soi-même ainsi que les quelques trucs et astuces qui gravitent autour.

Les Modules : Tout aussi importants, ils définissent l’organisation du code et remplissent beaucoup de rôles dont je vous parlerais.

Les structures de contrôles : Hé oui ! Jusque là, je n’ai pas parlé du tout d’itération, de if ou d’autres trucs du genre… Bêtement parce que vous allez rarement en avoir besoin. Pour bien se servir d’Elixir, vous allez devoir acquérir le réflexe d’exploiter au maximum ses possibilités pour éviter de coder les choses vous mêmes.

Mais avant tout ça je vais vous présenter rapidement ExUnit.

Continue reading

Ticket #1.2 : Docker, PostgreSQL et nginx

Docker

Maintenant qu’on a la base pour coder, il nous reste juste à mettre en place le système qui va s’occuper de la gestion de notre service.

Pour ce faire, j’ai choisi d’utiliser Docker, un système  d’application qui permet d’avoir une gestion application par application de l’espace CPU et mémoire disponible. Il permet aussi d’éviter les contaminations entre différentes applications. Ainsi, une application qui tourne sous Docker est presque totalement indépendante des autres. Les seuls liens autorisés sont des ports de communications établis au préalable qui permettent par exemple de rendre accessible une base de données pour d’autres services.

 

Service-port

 

Docker est un outils en cours de développement qui possède déjà une forte communauté. Ainsi de grosses parties des services qui nous seront utiles existent déjà, prêtes à l’emplois. De cette façon l’installation de PostgreSQL et du Reverse Proxy nginx sera aisée.

Continue reading

Ticket #1.1 Installation de l’environment


Petite Note
L’aspect Windows sera rarement abordé sur ce blog 🙂
Mon serveur de test est une machine Linux sous la dernière debian.
Je travail sous Mac (OS X Yosemite).

1°) Installation d’Elixir

Sous Mac OS X :

Sous Ubuntu, Elixir est une refonte d’Erlang et utilise la VM (Virtual Machine) d’Erlang. Vous pouvez installer soit :

  •  Avec le package Erlang Solution qui permet d’obtenir l’ensemble des outils
  •  Depuis les sources

Note : N’oubliez pas de rajouter le dossier elixir/bin dans votre Path !

Plus de détails

A partir de ce moment, vous êtes en mesure de commencer a écrire du code Elixir :

IEX est une invite de commande Elixir. Tout le code que vous taperez ici sera interprété et exécuté dans la foulée. Je ferai un ticket tout spécialement pour vous donnez les bases d’Elixir un peu plus tard.

Continue reading

Ticket #1: Elixir, Phoenix et Autres Magies

Bonjour,

Pour ce premier ticket technique, je vais vous introduire à quelques technologies que je vais utiliser pour mettre en place le Service.

Dans un premier temps, nous nous occuperons simplement de mettre en place l’affichage du service grâce à une méthode « rapide » pour avoir un retour directe et graphique. Ensuite, le site se construira petit à petit. Pour ce faire, nous utiliserons la framework Phoenix. En deux mots, cette framework permet de créer des applications web avec le langage de programmation Elixir. Un ticket arrivera bientôt pour présenté les différences entre Elixir et d’autres langages du même calibre comme Go et Rust, mais succintement, Elixir est un langage fondé sur Erlang, une machine de guerre de la fin des années 80 dont l’un des objectifs principaux était de fournir des interfaces efficaces pour des applications hautement concurrentielles et temps réel. Elixir est un descendant d’Erlang plus propre, ayant une syntaxe proche de Ruby, mais qui conserve tout les atouts techniques et les librairies d’Erlang. Ce qui le rend terriblement efficace malgré son jeune âge.

Phoenix dans sa gamme d’outils nous propose pas mal de choses utiles pour le développement d’une application web :

  • Un routeur de requête.
  • Un système MVC avec l’aide d’Ecto pour gérer les accès à la base de données PostgreSQL.
  • Un outil de template pour écrire les Vues proprement.
  • Un système de communication interne/externe simplifié, parfait pour créer des websocket. Un petit exemple se trouve ici

Pour terminer, nous encadrerons l’ensemble dans une série de dockers afin d’avoir une structure simple pour la maintenance du service. Nous utiliserons un docker nginx qui fera office de proxy et qui permettra de gérer et de répartir les différentes requêtes vers nos services.

Service v1Bastien

 

Creep Camp : un service ouvert à tous

Bonsoir et bienvenue à vous éleveurs ! 

Laissez moi vous faire visiter les lieux. Vous trouverez ici à CC, l’ensemble du matériel nécessaire à l’élevage et la prospérité de vos Creeps. Notre institution propose un espace d’entraînement commun en pool de taille variant de 10 à 100 unités (et peut-être exceptionnellement atteignant les 1000 unités), auquel vous pouvez inscrire vos dernières créations. Vous pourrez, en retour, comparer l’efficacité de celles-ci face à la violence de l’arène sélectionnée et des autres concurrents.

Nous mettons aussi à votre disposition notre scribe, un être tentaculaire dont le seul objectif dans la vie est de retranscrire les événements des différentes arènes. Vous pourrez, à tout moment, analysé les résultats de combat auxquels vous avez ou non participé, afin de mieux cerner vos adversaires.

Bien entendu, tout cela n’est pas gratuit …
Ah, mais si, en faite ! J’ai seulement besoin d’une petite signature en bas. Juste ici, vous voyez ? Après « En échange de mon âme  Pour le bien des Creeps estropiés ».

Ignace


Plus sérieusement,  CC se veux être un service ouvert en constante évolution. Pour ce premier ticket je vais rapidement vous présenter le premier service à paraître :

La Sandbox, ainsi que le nécessaire de gestion qui gravite autour.

Le premier objectif de cette Sandbox est de fournir un espace de liberté contrôlé pour nos Creeps. Lesquels sont de simples consommateurs du service Sandbox. Par espace contrôlé, j’entends, un modèle dans lequel chaque action et réaction sont contrôlées et calculées par le service. Cette Sandbox va avoir plusieurs fonctionnalités, dont, pour commencer :

  • Gestion de Déplacement : Nous allons produire une Sandbox au format grille tridimensionnelle. C’est-à-dire, un plateau où chaque case possède un attribut x, y et z. On notera que pour des raisons de simplicité, pour chaque entrée x, y, il n’y aura qu’un seul et unique z. Ce qui implique qu’une action « Déplacement » sera disponible pour les Creeps prenant en seul et unique paramètre, une direction (pour le moment le déplacement se fait de case en case). Les Creeps en tant qu’être « vivants » sont orientés, de façon à ce qu’il y ait une face et un dos, sans parler évidement des cotés.
  • Gestion des Dégâts : Chaque Creep aura l’occasion de choisir d’effectué une Attaque, quand son tour viendra, sur la case adjacente en face de lui, ou bien d’effectuer une Défense de face.

Donc pour simplifier la chose, la Sandbox fournis :

  • En Sortie : Un contexte géographique immédiat (contenu des cases adjacentes, de face et sur les cotés).
  • En Entrée : Une décision de déplacement, un ordre d’Action (Attaque ou Défense).

Le service se compose de plusieurs parties :

  • Le Service Web : Dont l’objectif est de fournir une interface publique, et de récupérer et fournir les informations adéquates pour le bon usage de la sandbox. Mais aussi, la gestion d’utilisateurs pour le catalogage des informations et la réservation de sandboxes, ainsi que le nécessaire à la communication des sandboxes actives vers les différents consommateurs.
  • La gestion et surveillance des Sandbox: Les sandboxes seront le nerf de la guerre. Elles vont devoir interagir avec des dizaines voir des centaines d’individus simultanément. Il faut donc que la communication entre la sandbox et l’extérieur soit la plus directe et efficace possible ! Pour cela il faut contrôler l’environnement afin que les différentes sandboxes ne se marchent pas dessus (Bonne gestion de l’espace mémoire et des ressources CPU). Mais il faudra aussi plancher sur les mécanismes d’accès, afin d’éviter les goulot d’étranglement. Pour cela, il faudra être capable de prédire les prochains problèmes et de pouvoir y remédier à l’avance.
  • Les Sandboxes : Ici, les sandboxes correspondent au service des sandboxes lui mêmes. C’est-à-dire, finalement, à l’état courant du modèle, et à son évolution dans le temps au fil des interactions avec les différents acteurs.

Des trois services, le premier est probablement le plus simple, dans le sens où le code qui va gérer les utilisateurs n’a pas vocation à être complexe, l’inscription d’un participant de ne pas être non plus un grand poids.
Le second service quand à lui va être durement mis à l’épreuve, le temps d’arriver à une gestion correcte du système et d’obtenir des temps de communications satisfaisants (au début l’objectif sera d’avoir une communication sandbox-consommateur de moins de 100ms). Ce service restera en place pendant un temps, puis il nécessitera une nouvelle boucle de travail quand il y aura plus de clients externes.
Le troisième par contre, sera en évolution constante. La sandbox permet l’évolution des Creeps. En effet les fonctionnalités qui ne sont pas gérées dans la sandbox ne sont pas « imaginable » pour les Creep. Ils ne peuvent fonctionner que dans ce milieu clos et contrôlé. Pour le moment nous produisons une sandbox minimaliste, mais nous allons ajouter de la complexité au fur et à mesure. Gestion de champs de vision, d’obstacle, de piège, de bruit,…

De prochains billets aborderont les techniques mises en place pour résoudre les différents problèmes de ces différents services.

Bastien