Le modèle STROBE et ses évolutions : Interprétation des interactions GT Modèles Formels pour l’Interaction du GDR I3 5 décembre 2003 Je vais vous présenter le modèle STROBE proposé par Stefano Cerri il y a quelques années. Ce modèle a été l’objet de plusieurs travaux, et nous en proposons aujourd’hui une suite. Ce modèle de communication et de représentation agent est aujourd’hui un des intérêts de ma thèse. Avant de commencer cette présentation regardons en quoi notre modèle se situe à la croisée de plusieurs domaines et en quoi il peut être intéressant pour un GT comme le GT MFI ? Clément Jonquet

Où se situe notre modèle ? IAD/SMA : C’est un modèle de représentation et de communication agent IHM : C’est un modèle centré utilisateur qui tente de faire abstraction du type des agents (AH/AA) EIAH : Apprentissage => Interaction LA : STROBE est intimement lié à Scheme Globalement on parle de communication agent et d’interprétation des langages Notre travail a première vue s’inscrit dans la branche IAD/SMA du GT… puisque STROBE est a la fois un modèle de représentation et de communication des agents. Cependant, on est très proche de la communauté IHM dans le sens ou notre travail, se veut centrée utilisateur et que le modèle de communication agent que nous proposons tend à considérer les interactions entre agents artificiels et également avec des agents humains. Nous ne sommes pas proche de cette communauté dans le sens « ergonomique » ou intuitif…. Notre travail s’inscrit également dans une logique plus globale de la communauté EIAH, l’apprentissage humain à l’aide de l’informatique passe nécessairement par l’interaction des 2 types d’agents. En outre, nous pouvons citer l’exemple du projet E-LeGI pour … qui est un projet… Notre travail s’inscrit également dans le domaine des langages applicatifs, car dans le soucis de rester toujours proche d’une certaine réalité nous avons intimement lié notre modèle au langage Scheme. Ainsi, notre travail peut être vu aussi bien d’un point de vue conceptuel que d’un point de formel. Donc juste un petit mot sur le premier de ces domaines, la communication agent…

Au sujet de la communication agent La simple mise en commun de plusieurs agents ne suffit pas à former un SMA La communication permet la coopération et la coordination entre agents Modéliser la communication est difficile Le domaine de prédilection des agents est le Web… le GRID… La simple… c’est la communication… Aujourd’hui, nous pouvons trouver de nombreux modèles et langages de communication agent, mais pouvons nous dire qu’ils sont adaptés à de nouvelles formes de communication comme celle que l’on trouve sur le Web ? Il ne s'agit pas de prendre les langages traditionnels de communication ou même les paradigmes actuels de programmation et de les adapter au Web et aux agents. Il s'agit de développer de nouvelles architectures et de nouveaux langages conçus pour les agents sur le Web. Pour être effective, la communication doit être intrinsèque à un langage. Regardons 2 pré requis nécessaire sur la communication et les agents… Développer de nouvelles architectures et de nouveaux langages conçus pour les agents sur le Web

Pré requis sur la communication agent Autonomie et adaptation pendant la communication La représentation qu'un agent se fait de son interlocuteur Réflexivité et travail sur l’interprétation pour faire évoluer dynamiquement nos agents Les Environnements Cognitifs de STROBE Si nous considérons que la communication à des effets sur les interlocuteurs, nous devons considérer que ces agents doivent être autonomes et doivent pouvoir s’adapter pendant la conversation. Nous devons aussi considérer le fait que les agents peuvent interagir ensemble ou avec des agents humains suivant les mêmes principes… ce qui compte c’est la représentation de l’autre.… Pour le premier pré requis, la réflexivité et le travail sur l’interprétation peut nous aider car cela permet aux programmes de ce manipuler eux-mêmes en accédant à leur contexte d’exécution (expression, environnement, continuation) Pour le deuxième, nous nous sommes inspiré du concept d’Environnement Cognitif du modèle STROBE Donc, nous pouvons maintenant rentrer dans le vif du sujet, regardons le déroulement de cette présentation…

Déroulement de la présentation Le modèle STROBE - Concept fondamentaux Les Environnements Cognitifs Les agents comme des interpréteurs Protocole de communication Évolutions du modèle - Intégration du méta-niveau Les 3 niveaux d’abstraction et d’apprentissage Ajout des interpréteurs dédiés Exemples et expérimentations Apprentissage au méta-niveau par la communication Spécification dynamique de problème Conclusion et perspectives Dans un premier temps nous verrons donc… ainsi que ses 2 concepts les plus importants. Puis nous verrons ses récentes évolution, en particulier l’intégration du méta-niveau pour nos agents… Un petit aperçu des expérimentations et exemples sur lesquels nous travaillons avant de conclure…. Donc, le modèle STROBE….

Le modèle STROBE Le modèle STROBE - Concept fondamentaux STReam + OBject + Environment Basé sur les ACL classiques (KQML, FIPA-ACL…) Dialogue = ensemble de message échangés sous forme de flots Le concept de mémoire via des objet (sous forme de procédure) Utilisation du concept de Dynamic Scheduler Apprentissage comme effet secondaire de la communication Décrire la communication par des flots (STReams) de messages échangés entre agent représentés comme des objets (OBjects) qui interprètent ces messages dans de multiple environnement (Environment) STROBE récupère les aspects intéressants des langages de communication agents « modernes » (type KQML & FIPA ACL). En particulier, le fait que le niveau pragmatique et contenu sont indépendants. STROBE modélise la notion de point de vue multiple et de représentation du partenaire par le concept d’Environnement Cognitifs STROBE considère que les messages sont en fait des flots de messages. Il se base sur le fait que un agent ne génère pas le message suivant a envoyer a son interlocuteur avant que celui-ci ne lui est renvoyé la réponse du premier. Il délaie cette génération. D’où l’utilisation des streams. La notion de mémoire privée est primordiale, c’est pour cela que notre modèles est basé sur des objets, qui modélise bien la connaissance privée de chaque agent. Nos objets sont en fait de procédures. [Normark 91] Les agents STROBE possède un scheduler dynamique qui leur permet de choisir le prochain message à traiter en fonction de méta-données sur ce message. Le modèle veut profiter de l’apprentissage comme effet secondaire de la communication. Cela se base sur le fait qu’une communication n’est pas une transmission et donc que l’on doit tenir compte des aspects pragmatique engendrés par une communication. Nous ne détaillons pas ce point mais nous y reviendrons tout de même à la fin de la présentation quand on parlera du projet E-LeGI

Les Environnements Cognitifs Le modèle STROBE - Concept fondamentaux Les Environnements Cognitifs KQML ne gère pas la modélisation de l’utilisateur 2 pré requis [Cerri 96]: Environnement de première classe Environnement multiples pour un même objet Structure des liaisons conservant l’historique Comportement multiples, émergents des différentes interactions Les environnements sont modifiés pendant la conversation Environnement au sens langage et non SMA Une des limites de KQML c’est est de ne pas gérer la modélisation de l’utilisateur. STROBE ajoute a KQML le 2ème pré requis. [Cerri 96] montre la nécessité de 2 pré requis pour le concept d’Environnement Cognitif : L’environnement d’évaluation des variables et procédures (et donc des messages) doit être un objet de première classe. Des environnements multiples doivent être à la disposition d’un même objet. Un agent possède en fait plusieurs environnements (en fonction des ses interlocuteurs) et un environnement privé. Ainsi, les effets d’une conversation avec un agent seront stockés répercutés dans l’environnement dédié à cette conversation. Les Environnements Cognitifs permettent à nos agents d’avoir des comportements multiples, émergents des différentes interactions qu’ils ont eus. Ils jouent dans le modèle le même rôle que l’ontologie en KQML. Ils sont des structures où les expressions prennent des valeurs (par évaluation).

Les agents comme des interpréteurs Le modèle STROBE - Concept fondamentaux Les agents comme des interpréteurs Boucles d’interpréteurs REPL (Read–Eval –Print–Listen) Même interpréteur pour le message et son contenu Les messages sont interprété par une procédure concrète d'évaluation (evaluate) Les effets de l’interprétation d’un message sont répercutés dans un environnement cognitif dédié à l’agent dont provient le message Le modèle considère que les agents exécutent des boucles REPL similaire à des interpréteurs. Pendant la communication, chaque agent exécute une boucle REPL et celles-ci sont imbriqués. Cela veut dire que dans une conversation un agent attend (Listen) un message puis lorsque il en reçoit un (Read), il l’évalue (Eval) ce qui peut engendrer chez lui des changements de représentation, produit la réponse approprié (Print) puis attend le message suivant. Nous ne considérons pas pour le moment le problème du boot-strap de la conversation.

Protocole de communication Le modèle STROBE - Concept fondamentaux Protocole de communication STROBE est « orienté » acte de langage (performatif) Format des messages : (kqmlmsg performative sender receiver content) Performatifs : assertion rép: ack request rép: answer order rép: executed Les messages que nous considérons sont inspirés de la structure des messages KQML ou FIPA-ACL. Ils sont de la forme… - Les assertions ont pour but de modifier le comportement ou les représentations de l'interlocuteur. - Les requêtes ont pour but de connaître une représentation de l'interlocuteur, comme par exemple la valeur d'une variable ou la fermeture d'une fonction. - Les ordres demandent à l'interlocuteur d'exécuter une procédure. - Les messages broadcast (sujet de l’expérimentation)…. Meta-performatif Pour prendre en compte ce protocole de communication, il faut donner à nos agents un interpréteur de message, une fonction d’interprétation de ces messages. Nous verrons plus loin que cette fonction est en fait une sous-fonction de l’interpréteur d’un agent (partie évolution). Un petit mot pour introduire les 3 niveaux d’abstraction et d’apprentissage…

3 niveaux d’abstraction et d’apprentissage Intégration du méta-niveau 3 niveaux d’abstraction et d’apprentissage Donnée Contrôle Interpréteur (set! a 3) (define b 4) (define square…) Modifier (evaluate e r k) en ajoutant une forme spéciale Le challenge se situe au niveau interpréteur – le méta-niveau Comment faire évoluer STROBE de façon à ce que ce méta-niveau soit accessible ? Comment réaliser un apprentissage à ce méta niveau par communication ? Dans tous les langages de programmation on retrouve les 3 niveaux : donnée, contrôle, interpréteur - Le niveau données consiste à affecter des valeurs à des variables déjà existantes, ou à définir de nouvelles données. Exemple en Scheme…. - Le niveau contrôle consiste à définir de nouvelles fonctions par abstractions sur celles existantes. Exemple en Scheme…. - niveau interpréteur ou méta niveau consiste à faire évoluer l'interpréteur Scheme. Exemple en Scheme…. Qu’est que cela veut dire de considérer les agents comme des interpréteurs….?

Ajout des interpréteurs dédiés Intégration du méta-niveau Ajout des interpréteurs dédiés Ajouts dans les Environnements Cognitifs d’interpréteurs dédiés Pour chacun de ses interlocuteurs un agent possède un environnement (et donc un interpréteur) dédié. Ce couple lui sert de modèle du partenaire Conversations Agent A GlobalEnvA GlobalInterA Other = {(BA, InterBA, EnvBA) (CA, InterCA, EnvCA)} Agent B GlobalEnvB GlobalInterB Other = {(AB, InterAB,EnvAB) (CB, InterCB, EnvCB)} Agent C GlobalEnvC GlobalInterC Other = {(BC, InterBC, EnvBC) (AC, InterAC, EnvAC)} STROBE suggère d’avoir un modèle du partenaire pour reconstruire son état interne. Il propose que chaque dialogue soit interprété dans une paire d'environnement : le premier privé, appartenant à l'agent, et le deuxième dédié, représentant le partenaire courant. C'est la notion d'Environnements Cognitifs. Notre travail exploite ce concept en rajoutant a ces environnements des interpréteurs. En conséquence l’interprétation des messages est … La figure montre les attributs qu’un agent doit avoir, GlobalEnv, GlobalInter, et une structure de donnée stockant les représentations des autres, Other un ensemble de triplet : name, environment et interpreter. L’idée est que leur environnement global est privé et ne change pas, il est cloné lors du début d’une conversation et c’est son clone qui est modifié au fur et à mesure de la conversation. Pourquoi décider de concrétiser tout ça avec Scheme…? L’ interprétation des messages est faite : - dans un environnement donné - avec un interpréteur donné tous les deux dédiés à la conversation courante

Le comportement de nos agents Intégration du méta-niveau Le comportement de nos agents LISTEN - Retirer le premier message de la file des messages en entrée - Si ce message est nul, renvoyer(pas de message) - Sinon transmettre ce message à READ READ - Transmettre ce message à EVAL EVAL - Récupérer l’évaluateur et l’environnement dédié à la conversation - Évaluer ce message avec l’évaluateur et l’environnement choisi - Transmettre via la continuation le résultat à PRINT PRINT - Si le résultat est un message alors envoyer ce message - Sinon si le résultat est une liste de message alors envoyer ces messages Sinon traiter la réponse - Revenir à LISTEN Comme nous l’avons avant , le comportement de nos agents consiste à appliquer un boucle REPL. Cela commence dans la procédure LISTEN… Maintenant, quels outils allons nous utiliser pour modifier dynamiquement nos interpréteurs ?

Et le méta-niveau alors ? Intégration du méta-niveau Et le méta-niveau alors ? Agents = Entités autonomes contrôlé par une procédure concrète d'évaluation (evaluate) Ces interpréteurs correspondent au comportement d’un agent, ainsi qu’aux langages qu’il reconnaît. Réifier le niveau contrôle au niveau interpréteur pour rendre le méta-niveau accessible Alors ces interpréteurs correspondent à la connaissance d’un agent et son évolution dans le temps Il faut réifier le niveau contrôle au niveau interpréteur, c’est-à-dire utiliser une architecture telle que l’évaluation des messages puisse engendrer des modifications de l’interpréteur qui les évaluent. Les interpréteurs représente en fait la connaissance de nos agents et son évolution dans le temps Pourquoi Scheme ? Nous allons voir cela mais d’abord je vous présente la 2ème caractéristique importante de notre modèle qui est la représentation des autres… Nous proposons une architecture (Scheme) qui permet de faire évoluer ces interpréteurs dynamiquement au fur et à mesure des conversations

A propos de Scheme ? Intégration du méta-niveau Scheme = puissance et simplicité Modèle de mémoire (environnements de première classe) Modèle de contrôle (procédures et les continuations de première classe) La modification dynamique d’un interpréteur : Méta-évaluateur réflexif proposant le mécanisme des reifying procedures qui permet à un programme d’accéder à son contexte d’évaluation et de le modifier Utiliser un schéma d’évaluation du type (eval (apply ‘eval …)) Scheme est considéré dans notre modèle comme langage de description et langage de prototypage. Nous apprécions tout particulièrement... Langage a typage dynamique Remark: Un objet de première classe peut être nommé par une variable, stocké dans des structures de données, être passé en paramètre et être retourné comme résultat d'une autre procédure Et surtout, Scheme nous fourni 2 schémas relativement simple de… Le but est de transporter ces schémas dans nos agents Avant de conclure, un petit mot sur les exemples et expérimentations sur lesquelles nous travaillons…

Première expérimentation Exemples et expérimentations Première expérimentation Apprentissage du type « apprendre en étant dit » (learning-by-being-told) Dialogue type « professeur – élève » où un agent apprend à l’issu de la conversation un nouveau performatif. Apprentissage au méta niveau (fonction d’interprétation des messages qui est modifiée) Je ne détaille pas ici ces exemples, je les sites simplement pour montrer que ce modèle est viable et qu’il est en cours d’expérimentation Le but de l'éducation est de faire changer d'état son interlocuteur. Ce changement se fait après l'évaluation des nouveaux éléments apportés par la communication. Pour conclure…

Détails du dialogue Exemples et expérimentations TEACHER STUDENT Voici la définition de la procédure square : (kqmlmsg 'assertion teacher student '(define (square x) (* x x))) Ok, je connais maintenant cette procédure : (kqmlmsg 'ack student teacher '(*.*)) Diffuse à tous tes correspondants : (kqmlmsg 'broadcast teacher student '(order (square 3))) Désolé, je ne connais pas ce performatif : (kqmlmsg 'answer student teacher `'(no-such-performative broadcast)) Ok, voilà comment ajouter broadcast à la liste des performatifs que tu reconnais : Voilà le code que tu devras générer et ajouter à ta procédure evaluate-kqmlmsg : (kqmlmsg 'assertion teacher student learn-broadcast-code-msg) Exécute cette procédure : (kqmlmsg 'order teacher student ’(set! evaluate-kqmlmsg learn-broadcast-code)) Ok, j'ai rajouté ce code dans une variable de mon environnement : (kqmlmsg 'ack student teacher '(*.*)) Ok, J’ai modifié mon évaluateur : (kqmlmsg 'executed student teacher '(*.*)) Le premier message envoyé par teacher est learn-broadcast-code-msg. Cette variable correspond au code que le student doit rajouter pour générer la nouvelle fonction evaluate-kqmlmsg pour plus tard l’affecter a cette fonction. Le student construit ce code en recupérant le corps de sa fonction evaluate-kqmlmsg et en lui ajoutant (if (eq? performative ' broadcast)…) et le taritement associé.. Le second message est le plus important. Il defini la reifying procedure learn-broadcast qui va modifier l’interpréteur du student . Finalement, teacher sollicite le student pour appliquer cette reifying procedure avec pour argument un appel à set! (modifiant la fonction evaluate-kqmlmsg par le code générer plus tôt) Alors la …La procedure evaluate-kqmlmsg du student est modifiée: Il peut traiter le performatif broadcast Cette expérimentation montre comment modifier dynamiquement les interpréteurs de nos agents, donc comment les modifier au méta-niveau. C’est un toy example de communication d’une connaissance dans un SMA. Nous pouvons maintenant voir en quoi ces principes peuvent être intéressant pour d’autres domaines : Diffuse à tous tes correspondants : (kqmlmsg 'broadcast teacher student '(order (square 3))) Ok, je diffuse… (kqmlmsg ’order student … '(square 3))

Deuxième expérimentation Scénario de type e-commerce de réservation de billet de train. Spécification dynamique d’un problème (utile pour la génération dynamique de service) Considérer les agents comme des interpréteurs non déterministes Intéressant pour la programmation par contraintes Construire des programmes à contraintes par communication Spécifier et coder au même moment Si nos agents sont des interpréteurs, alors ils peuvent être des interpréteurs non déterministes. En quelques mots, un interpréteur non déterministe sait traiter les formes spéciales… amb, require, et try-again Cela permet à un programme d’être évaluer de différente manière grâce à des retours en arrière (backtrack) qui permettent d’évaluer une autre branche de l’arbre des solutions. Notre modèle grâce aux modifications dynamique des environnements locaux permet de construire des programmes par le dialogue au fur et a mesure de la conversation … donc en spécifiant en même temps qu’en codant soit en réalisant la spécification dynamique. Le prochain poster illustre un exemple de dialogue e-commerce ou un agent Client recherche un billet de train auprès d’un agent SNCF:

Dialogue e-commerce Exemples et expérimentations (define (find-ticket) CLIENT SNCF Début de la construction de find-ticket : (define (find-ticket) (let ((depart(amb *ens-ville*)) (dest (amb *ens-ville*)) (prix (amb *ens-prix*) (date (amb *ens-date*) (require (not (eq? depart dest))) (require (eq? depart montpellier)) (require (eq? dest paris)) (list (list ’depart depart) (list ’destination dest) (list ’prix prix) (list ’date date)))) Pour quand ? Je voudrais un billet de Montpellier à Paris (require (eq? depart montpellier)) (require (eq? dest paris)) Demain avant 10H du matin (require (< date *demain10H*)) Pourriez vous me faire une proposition ? (find-ticket) Modification de la fonction find-ticket en lui ajoutant la nouvelle contrainte. Puis exécution de cette fonction. ((depart montpellier) (destination paris) (prix 150) (date *dem9H30*)) Voilà, train 34170, départ demain 9H30, Montpellier en direction de Paris, 150€. Vous n’auriez pas à moins de 100 € ? (require (< prix 100)) (find-ticket) C’est le dialogue qui construit petit à petit la fonction.. L’idée est que ce soit l’interaction qui construise le calcul à effectuer et non le contraire. Ce genre de scénarios peuvent être le sujet de future recherche. Un autre exemple d’application de nos principes est le GRID Computing: idem. ((depart montpellier) (destination paris) (prix 95) (date *dem8H41*)) Voilà, train 34730, départ demain 8H41, Montpellier en direction de Paris, 95€. Execution de find-ticket : Voilà, train 34392, départ demain 9H15, Montpellier en direction de Paris, 98€ ((depart montpellier) (destination paris) (prix 98) (date *dem9H15*)) Une autre proposition s’il vous plait ? (try-again) Ok, celui-ci me va

Approche centrée dialogue www.lirmm.fr/~jonquet Conclusion Simplicité Fonctionnalité Apprentissage au méta niveau par la communication Potentiel applicatif important (Grid, e-commerce, Web..) Spécification dynamique d’un programme pour la génération dynamique de service Approche centrée dialogue La mise en commun de ces 2 domaines à permit l’émergence d’une nouvelle architecture… Cette architecture simple et fonctionnelle (comme le montre les exemples et l’expérimentation) permet : - Apprentissage… - Potentiel … - Spécification … - Approche … Merci de votre attention… et n’oubliez pas les 60% restant du concept qui n’attende que vous…

Références Pour le modèle STROBE : Et plus récemment : Cerri S.A., “Cognitive Environments in the STROBE Model”, Presented at EuroAIED: the European Conference in Artificial Intelligence and Education, Lisbon, Portugal, 1996. Cerri S.A., “Shifiting the Focus from Control to communication: The STReams OBject Environments (STROBE) model of communicating agents”, In Padget, J.A. (ed.) Collaboration between Human and Artificial Societies, Coordination and agent-Based Distributed Computing, Berlin, Heidelberg, New York: Springer-Verlag, Lecture Notes in Artificial Intelligence, pp 71-101, 1999. Cerri S.A., Sallantin J., Castro E., Maraschi D., “Steps towards C+C: a Language for Interactions”, In Cerri, S. A., Dochev, D. (eds), AIMSA2000: Artificial Intelligence: Methodology, Systems, Applications, Berlin, Heidelberg, New York: Springer Verlag, Lecture Notes in Artificial Intelligence, pp 33-46, 2000. Et plus récemment : Clement Jonquet, Stefano A. Cerri, Apprentissage issu de la communication pour des agents cognitifs, 11ème Journées Francophones sur les Systèmes Multi-Agents, JFSMA'03, Hammamet, Tunisie, Novembre 2003 Clement Jonquet, Stefano A. Cerri, Cognitive Agents Learning by Communicating, 7ème Colloque Agents Logiciels, Coopération, Apprentissage & Activité humaine, ALCAA'03, Bayonne, France, Septembre 2003 Pour l’aspect langage Abelson H., Sussman G.J., Sussman J., Structure and Interpretation of Computer Programs, Second Edition, MIT Press, Cambridge, Massachusetts, 1996. Friedman D.P., Jefferson S., “A Simple Reflective Interpreter”, IMSA'92: International Workshop on Reflection and Meta-Level Architecture, Tokyo, 1992.