ATNoSFERES : Construction de contrôleurs pour envts non markoviens par algorithme génétique Samuel Landau, Sébastien Picault (équipe MIRIAD) Pierre Gérard, Olivier Sigaud (AnimatLab)

Problématique Construire une architecture de contrôle produisant un comportement adapté à un environnement non markovien Exemple : trouver de la nourriture dans un labyrinthe

Problème : le « perceptual aliazing » « Perceptual aliazing » : des situations perceptives identiques requièrent des actions différentes action = fonction du contexte  ETATS INTERNES

Questions Comment construire, par évolution, un comportement : – « adapté » (résolvant de façon satisfaisante le problème) ? – « intelligible » (exprimable comme un ensemble de règles) ? – « optimal » (menant le plus rapidement au but) ? – « économe » (de complexité minimale pour résoudre le problème) ? nb règles / spécificité vs. généralité ?

Approches évolutionnistes classiques (1) Algorithmes génétiques (Holland 75) Support héréditaire (génotype) Paramètres (phénotype) dans comportement prédéfini 51 2.78 faux Continuité génotype/phénotype et parents/enfants Pauvreté comportementale

Approches évolutionnistes classiques (2) Programmation génétique (Koza 92) IF > x – 3 y W Fd 10 Support héréditaire (génotype) Exécution (phénotype) Conception automatique de comportements complexes Contraintes structurelles fortes

ATNoSFERES : interprétation par pile Les variations affectent le contenu et la taille de la chaîne

Construction d’un graphe étiqueté (1) Interpréteur connect dupNode c1? a1! node Pile ATN (graphe étiqueté orienté) <vide>

Construction d’un graphe étiqueté (2) Interpréteur connect dupNode c1? a1! 1 Pile ATN 1

Construction d’un graphe étiqueté (3) Interpréteur a1! connect dupNode c1? 1 Pile ATN 1

Construction d’un graphe étiqueté (4) Interpréteur c1? a1! connect dupNode 1 Pile ATN 1

Construction d’un graphe étiqueté (5) Interpréteur 1 c1? a1! connect 1 Pile ATN 1

Construction d’un graphe étiqueté (6) Interpréteur 1 1 Pile 1 c1? a1! ATN

ATNoSFERES : Utilisation du graphe Etats intégrés dans l’architecture

Les systèmes de classeurs (LCS) • Systèmes à base de règles + apprentissage • Un classeur = – un vecteur spécifiant les valeurs des conditions : 0 (faux) / 1 (vrai) / # (indifférent) – action à effectuer si les conditions sont vérifiées – force du classeur (modifiée par RL) • Application d’un A.G. à la population de classeurs – généralisation : remplacement de 0/1 par # – spécialisation : replacement de # par 0/1 • Ajout d’états internes (XCSM, Lanzi) = conditions/actions « internes »

Utilisation des systèmes de classeurs + conditions internes (« état » de l’agent) + actions internes (changement d’état)

Sous-optimalité : la longue marche vers la perfection • Solution trouvée : marche très bien (98% du score théorique maximal), mais moins bien que XCSM • Solution trop simple ? • Coût structurel du test du coin S8 : 1 nœud, au moins 2 arcs + des conditions/actions appropriées = trop élevé • Problème « classique » de minimum local dans les A.G. !

Quelques avantages d’ATNoSFERES • La « mémoire » (états internes) fait partie du comportement (structure) Le nb de nœuds (=d’états), d’arcs (=de règles) n’a pas à être fixé a priori (adaptation taille génome) • Lisibilité des comportements directement donnés par le parcours du graphe en fonction des conditions environnementales (dans un LCS : – règles très nombreuses – force associée à chaque règle – suivi des changements d’états fastidieux)

Quelques inconvénients… • Force des classeurs (LCS) : apprise par renforcement  compensé par la définition de la fonction de fitness • La question de la généralisation : – sur les conditions / actions : implicite (seules les conditions pertinentes et les actions nécessaires sont présentes) – sur les états internes : INEXISTANT dans le modèle initial  fonction de la « simplicité » de la règle et de son utilité mais… pas pertinent dans le cas d’environnements non-markoviens

Faciliter la généralisation ? • Ajout d’un token de connexion opérant sur tous les nœuds présents dans la pile et leur rajoutant un même arc bouclé 1 c1? a1! 2 c1? a1! 4 3 2 4 c1? a1! c1? 3 c1? a1! a1! 1 Pile

Expériences : généraliser pour survivre • La généralisation est quasiment indispensable • Effet très positif du nouveau token • Effets également positifs sur le labyrinthe initial = convergence plus fréquente vers la bonne solution

Plus précisément... • En fait, dans le labyrinthe le token de généralisation est utilisé lorsqu’un seul nœud est présent dans la pile  C’est un « raccourci » permettant d’appliquer une règle sans changement d’état … et non la définition d’une règle valable quel que soit l’état !

Résultats : rien / règles générales / règles sans changement d’état

Conclusions • Nuancer l’utilité de la généralisation pour les problèmes non markoviens • Les avantages d’une représentation structurelle des états internes se paie du risque de sous-optimalité • Idée : rajouter de l’apprentissage sur une base évolutionniste

Algorithme évolutionniste : principe Variations aléatoires soumises à une sélection Forme d’apprentissage non supervisé Environnement (Sélection) Evolution de la population (reproduction avec variations) Population (variations)

Eléments de réponse 1. Objectif : algorithmes évolutionnistes pour construire des comportements d’agents (ATNoSFERES)  comparaison avec autres approches (apprentissage) 2. Architecture contrainte par 5° (intelligibilité)  symbolique + nécessité d’intégrer des états internes 4. Complexité ?  ajustée par l’apprentissage • nombre d’états internes • nombre de « règles » / spécificité vs. généralité + lien entre optimalité et complexité ? 1/ Question = est-ce vrai pour tout SMA ? Il semble que sous cette formulation ce soit le cas de tout SMA adaptatif… Problème : lien (antinomique ?) avec les méthodologies de conception de SMA ?