Un rapide retour sur les frameworks python pour les systèmes multi-agents

J’ai la chance de donner des cours sur les systèmes multi-agents à l’ENSTA (si vous ne connaissez pas le domaine, je ne saurais trop vous recommander de vous renseigner par exemple ici. J’ai longtemps utilisé Gama, une plate-forme de développement et de simulation qui a pour avantage d’inclure toutes les extensions dont j’avais besoin pour mon cours. L’an dernier, j’ai eu un conseil de mes étudiantes et étudiants : ils m’indiquaient qu’elles et ils n’auraient sans doute pas beaucoup d’occasion d’utiliser leurs connaissances dans le langage de Gama, gaml. Il leur semblait qu’avoir des TP en python serait plus profitable. J’ai donc décidé de reprendre mes TP à zéro et de refaire des sujets équivalents ou proches, mais avec des bibliothèques python.

Le problème avec ces fameuses bibliothèques, c’est qu’aucune n’est aussi complète que Gama, et qu j’ai donc du en utiliser plusieurs. En fait, j’ai utilisé 5 bibliothèques, à différentes fins:

• mesa, que j’ai utilisé pour mon TP d’introduction, pour sa visualisation ainsi que pour les TP sur les agents réactifs,
• spade, que j’ai d’abord utilisé pour les échanges de messages,
• agentspeak, utilisé pour les agents BDI,
• pade, que j’ai utilisé ensuite pour les messages (je vous expliquerai pourquoi ensuite)
• negmas, que j’ai utilisé pour le projet de fin de module sur la négociation automatique

Mesa

Je connaissais déjà mesa, je l’avais utilisé lors de stages, et pour faire des expérimentations moi-même. Je savais déjà comment l’utiliser. mesa permet de créer un serveur python qui simule un certain nombre d’agents à l’aide d’un planificateur qui ordonne leur exécution. Ce serveur peut fonctionner de manière autonome, pour créer des batch, qui permettent de lancer des séries d’expérience, mais aussi un moyen de se connecter à un client léger en javascript, qui permet de visualiser l’exécution des agents, que ce soit dans un domaine continu ou discret (sur une grille) ; mesa est vraiment une bibliothèque intéressante sous plusieurs angles, mais elle ne propose aucun moyen d’envoyer ou recevoir des messages, ni, a fortiori, de moyen de mettre en place des protocoles de coordination comme le Contract Net Protocol. Enfin, il faut noter (même si cela ne m’a pas vraiment dérangé dans le cadre de ces travaux pratiques) que les planificateurs de mesa sont séquentiels, ce qui signifie qu’il est impossible d’exécuter les comportements des agents de manière simultanée et asynchrone.

J’ai principalement utilisé mesa à 2 fins : tout d’abord pour introduire la notion d’agent. La bibliothèque mesa est très facile d’accès, et la visualisation des agents permet de toucher plus facilement du doigt les concepts notamment liés à l’autonomie, à la proactivité des agents. Ensuite, il permet de représenter l’environnement et la localisation des agents dans l’espace, ce qui permet en particulier de facilement appréhender les agents réactifs (qui communiquent généralement à travers cet environnement, sans s’envoyer de messages). J’ai aussi utilisé les capacités de mesa pour visualiser les effets de l’organisation sur l’environnement et les agents.

Spade

Puisque Mesa ne permettait pas d’envoyer ni de recevoir de messages, j’ai dû utiliser une autre bibliothèque à cet effet. J’ai voulu prévoir le TP concernant le paradigme BDI et ai donc sélectionné une bibliothèque qui avait une extension dans ce sens, Spade. Cette bibliothèque est un peu particulière, car si elle permet de concevoir des agents qui peuvent envoyer et recevoir des messages, elle ne fournit pas de plate-forme et fonctionne pour cela de concert avec un serveur XMPP, Prosody. Spade ne fournit pas non plus de protocoles de coordination. Il reste relativement simple à utiliser, mais sa principale faiblesse réside dans la nécessité de recourir à Prosody. Tout d’abord, il faut installer la plate-forme. Si cela se fait sans trop d’encombre sous linux, la version Windows n’est, elle, plus maintenue. Les solutions fournies n’ont pas vraiment été à la hauteur de mes espérances, qu’il s’agisse du docker (je n’ai pas réussi à le faire fonctionner correctement), ou d’une installation sur le Windows Subsystem for Linux, qui est assez lourd et loin d’être disponible sous toutes les versions de Windows. Une fois cet obstacle de taille surmonté, il faut inscrire les agents sur la plate-forme (plus faite pour des discussions entre humains que pour un système multi-agents). Cela demande un effort supplémentaire nécessaire pour pouvoir utiliser la bibliothèque.

En raison de toutes ces difficultés, j’ai fini par abandonner, et par passer sur Pade. En revanche, cette bibliothèque propose des fonctionnalités intéressantes : d’abord, il permet d’activer les agents de manière simultanée et asynchrone. Il est aussi fait pour pouvoir être utilisé sur plusieurs plate-formes, puisqu’il suffit d’avoir l’adresse du serveur pour l’utiliser. Cela ne m’est cependant pas d’une grande utilité dans le cadre de mes travaux pratiques.

Pade

Pade s’est montré mieux adapté à mes besoins. Je ne suis pas allé chercher dans les entrailles de la bibliothèque — j’ai dû en changer en cours de route — mais pour autant que je puisse en juger, il y a un serveur inclus basé sur Tornado, et qui se lance avec une commande. Cela m’a semblé plus commode. Pour être tout à fait franc, j’ignore s’il est possible d’accéder à un serveur depuis une autre machine, une fois encore cela n’était pas nécessaire dans le cadre de mes TP, mais la bibliothèque a plusieurs fonctionnalités intéressantes : en particulier, elle permet de mettre en place des protocoles de coordination. Certains protocoles sont déjà implémentés, comme le Contract Net Protocol, mais j’ai pu recomposer un protocole d’enchères sans trop d’efforts. Pour autant que j’aie pu en juger, les agents sont exécutés de manière simultanée. J’ai trouvé l’accès assez simple, malgré quelques spécificités. Le seul bémol peut-être, l’exécution se fait à travers une commande et non un script python, ce qui le rend un peu plus complexe à utiliser notamment dans un notebook jupyter, ce qui a obligé mes étudiantes et étudiants à faire leur développement en dehors de cet environnement.

Agentspeak

Gama a l’avantage de fournir un module très simple et direct d’utilisation pour le paradigme BDI (Belief-Desire-Intention). Si ce terme vous est étranger, je vous recommande ce petit article sous Wikipedia. AgentSpeak est un méta-langage de programmation orienté agent, et plus particulièrement le paradigme BDI. Par méta-langage, il faut comprendre que le langage AgentSpeak doit être exécuté par un interpréteur écrit dans un autre langage, et qui s’occupera aussi de pratiquement mettre en application les décisions prises par l’agent BDI. L’interpréteur AgentSpeak le plus connu est écrit en Java, il s’agit de Jason. Le passage de ce genre de bibliothèque en python est à la mode en ce moment, et il existe un interpréteur AgentSpeak en python, sobrement appelé agentspeak. La librairie est un peu jeune en comparaison avec Jason, et propose donc moins de fonctionnalités, mais de le cadre de mon TP, cela était bien suffisant. À noter en passant, comme je l’avais évoqué plus haut, il existe une bibliothèque permettant de relier des agents SPADE à ce genre de raisonnements, spade_bdi, mais comme je l’ai expliqué, les restrictions concernant le serveur Prosody qui accompagne spade m’a finalement poussé à abandonner cette solution et à repasser uniquement sous agentspeak.

La principale source de difficultés pour les étudiantes et étudiants dans ce cadre a été de les faire travailler sur le méta-langage AgentSpeak, qu’elles et ils ne connaissaient donc pas. Le TP s’est montré assez complexe, d’autant que la documentation de la bibliothèque n’est pas très fournie (les utilisatrices et utilisateurs sont, je pense, supposé·e·s connaître le méta-langage et avoir déjà utilisé AgentSpeak) et même la liaison avec python ainsi que les détails d’implémentations ne sont pas très explicites. Je pense peut-être retenter l’an prochain, mais sans changer le TP au dernier moment comme j’ai été obligé de le faire cette année, et en prenant davantage le soin de fournir des notes sur le langage, même si j’avais déjà renvoyé les étudiantes et étudiants vers un bréviaire cette année ; peut-être aussi leur fournir davantage d’exemples. Il n’empêche que je trouve intéressant de voir que des méta-langages qui ont été principalement utilisés avec du Java dans la communauté sont peu à peu passés sous python. Cela tend à montrer que ce langage commence à s’implémenter sérieusement dans la communauté multi-agents (ce qui peut se comprendre, ne serait-ce que du point de vue de l’écosystème qu’il propose)

Bonus: negmas

Negmas est un peu particulier. Il ne s’agit pas à proprement parler d’une bibliothèque multi-agents, en tous cas pas généraliste comme peuvent l’être celles que nous venons de décrire. Negmas est une plate-forme de négociation automatique multi-agent. Elle a notamment été utilisée dans le cadre de l’Automated Negotiation Agent Competition (ANAC), la plus grande compétition de négociation automatique, qui se tient tous les ans et permet à des agent logiciels de négociation de s’affronter. Je n’ai pas grand chose à dire de plus sur negmas que ce que j’ai déjà dit sur agentspeak, il est intéressant de voir que le curseur se déplace peu à peu de Java vers python dans la communauté (la bibliothèque utilisée jusque il y a peu, Genius, était écrite en Java). La bibliothèque est accessible, facile à prendre en main, il ne m’a fallu que quelques dizaines de minutes pour en saisir les tenants et les aboutissants et créer mon propre agent simple de négociation automatique (aléatoire). Je n’ai pas pris le temps de fouiller dans les fonctionnalités, notamment en ce qui concerne les négociations dans le cas où l’espace des accords possible est très large (on utilise généralement un fichier contenant cet espace et les préférences des agents dessus dans ce cas pour ne pas tout stocker en mémoire). Je me suis donc restreint à un espace plus petit pour éviter de compliquer la tâche, à la fois pour les étudiantes et étudiants et pour moi-même. Il n’en reste pas moins que la bibliothèque est très modulaire, et à la fois moins “visuelle” que Genius (qui proposait une IHM basique), plus adressée à la communauté des développeuses et développeurs d’une part, et des chercheuses et chercheurs d’autre part.

Conclusion: de belles découvertes, mais aussi des limitations

On voit effectivement de plus en plus de bibliothèques multi-agents écrites en python, et je trouve ça très bien. D’abord parce que j’aime beaucoup python (j’assume), mais aussi parce que cela apporte tout l’écosystème qui va avec python: les pytorch, les sci-kit learn et les pandas, ce qui permet de décloisonner un peu les domaines de l’intelligence artificielle. J’ai notamment vu des étudiants utiliser pour leur projet de fin de module sous negmas des méthodes directement importées depuis sci-kit learn là où j’ai dû (très) péniblement les réimplémenter moi-même en Java.

Il n’en reste pas moins un certain nombre de limitations: la maturité de ces plates-formes me semble moins importante que celle qu’on trouve dans le langage historique de la communauté, Java. Cela concerne Jason, comme je l’ai évoqué, mais aussi JADE, la plate-forme multi-agents par excellence. Le besoin principal pour moi serait d’avoir une bibliothèque à la mesa, qui me permette de voir mes agents bouger, mais qui me donne aussi la possibilité, quand je le souhaite, d’utiliser des messages, et de passer en mode batch. Une plate-forme qui me permette aussi de facilement implémenter de nouveaux protocoles, comme le permet pade par exemple. En effet, dans un de mes TP, j’introduis l’environnement dans les systèmes multi-agents (qui nécessite une représentation de l’espace), mais aussi les aspects interaction et organisation, qui demandent la mise en place de protocoles de coordination. Mais qui sait ? Peut-être est-ce pour bientôt ?