Eléments mécaniques - Fernand Léger
Il y a une architecture qui marche... Paul Claudel
Si longtemps les mondes de la Communication Homme-Machine et de l'Intelligence Artificielle se sont affrontés pour des raisons obscures, ils ont contribué et contribuent toujours à la réalisation d'architectures originales afin de faire communiquer le plus efficacement possible des entités informatiques. Ces contributions apportent toutes des concepts et des idées qu'il est possible au moins d'évoquer, sinon d'utiliser, quand on réalise un système interactif qui met en jeu des objets aussi différents qu'un programme Unix ou qu'un reconnaisseur de parole sous DOS par exemple, et dont la principale caractéristique est l'hétérogénéité.
Quelque soit le nom qu'on lui donne, la principale idée de ces dernières années pour la conception d'une architecture est celle faisant coopérer des entités informatiques plus ou moins intelligentes: les agents. C'est ce type d'architecture qui est décliné dans les lignes qui suivent.
Dans le domaine de la communication Homme-Machine, des architectures spécifiques aux systèmes interactifs ont été développées. Nous donnons ici les principales orientations et les concepts qui s'en dégagent.
Ce modèle d'architecture de système interactif est fondé sur les couches de la grammaire du langage d'interaction [PFAF93]. Le principal credo de ce modèle est la séparation entre le noyau fonctionnel et l'application. On dégage les composants suivants (Figure 10):
Le Modèle MVC (Figure 11) sur lequel est basé Smalltalk [GOLD84], est un ensemble d'agents à trois facettes:
La communication entre les agents de ce modèle se fait par envoi de messages, conformément à la philosophie Smalltalk.
Le modèle PAC, proposé par [COUT90], est à base d'agents interactifs composés de trois éléments: la Présentation, l'Abstraction et le Contrôle.
En effet, les agents PAC ne sont pas isolés dans le monde, et pour définir une application ils sont organisés de façon hiérarchique afin de coller au mieux à tous les niveaux d'affinement et d'encapsulation d'un système interactif. Le modèle PAC est récursif (Figure 12).
Si les idées de parallélisme et de séparation sont séduisantes, nous n'avons malheureusement jamais trouvé d'application concrète se basant explicitement sur ce modèle.
Le modèle ARCH s'appuie sur les modèles conceptuels décrits à Seheim avec les notions de noyau fonctionnel, de contrôleur de dialogue et de présentation (Figure 13).
L'arche repose d'un côté sur le noyau fonctionnel de l'application, de l'autre sur le composant d'interaction qui est en contact avec l'utilisateur. Le lien entre les deux piles est fait par le contrôleur de dialogue qui gère le flux d'information entre les deux composants intermédiaires. L'adaptateur de domaine traduit les petites différences conceptuelles entre le noyau fonctionnel et le contrôleur de dialogue. Quant à la Présentation, elle joue le même rôle du coté du composant d'interaction.
Comme on le voit, l'organisation générale du modèle ARCH est très similaire à celle d'un agent PAC à une décomposition fonctionnelle près. D'où l'idée de Laurence Nigay de rassembler le tout en une architecture hybride: PAC-Amodeus [NIGA94].
Le modèle PAC-Amodeus se veut plus pratique que PAC tout en conservant son aspect conceptuel. Comme le montre la Figure 14, cette architecture reprend les composants du modèle ARCH dont il affine le contrôleur de dialogue en terme d'agents PAC.
L'apport essentiel de ce nouveau modèle vient de l'incorporation d'une hiérarchie d'agents PAC dans la clé de voûte de l'édifice: le contrôleur de dialogue. Les rôles de ce dernier sont multiples:
Enchaînement des tâches
Transformation du formalisme
Mise en correspondance entre le monde des concepts et celui de l'interface
Gestion d'une interaction coopérante
Le fait d'avoir une collections d'agents indépendants pour gérer ces problèmes permet une meilleure répartition des tâches et donc un meilleur traitement. De plus certaines tâches comme la mise en correspondance des concepts et de la présentation est particulièrement adaptée à la nature même d'un agent PAC avec ses éléments Abstraction et Contrôle.
Les applications MATIS, Notebook et VoicePaint [GOUR92] sont basées sur les architectures PAC ou PAC-Amodeus.
Il existe aujourd'hui des dizaines d'applications multimodales qui ont des architectures spécifiques, mais où fondamentalement on retrouve toujours les mêmes concepts. Ainsi DEMMONS (DEclarative Multimodal MOdelliNg System) d'une équipe de Toulouse [VIGO92] propose une architecture supportant les commandes progressives dont l'utilisateur fait varier les paramètres en cours d'exécution. Au DFKI, on s'attache surtout à formuler des solutions pour la multimodalité en sortie qui est souvent négligée par ailleurs [WAHL93]. Voir aussi [YAKO93]. Enfin, on trouve des architectures dédiées comme celle de LIMSI-DRAW [BELL95] qui est proche de celle que nous avons élaborée pour nos applications (chapitre III.3.).
Parallèlement aux recherches menées dans le domaine de la communication Homme-Machine, des études étaient effectuées au sein de la communauté de l'intelligence artificielle. Certaines architectures originales qui sont le fruit de ces recherches sont facilement adaptables et utilisables pour créer des systèmes interactif.
Le concept de partage des tâches, ou de parallelisme est vu par David Gelernter comme une métaphore: la métaphore du piranha [GELE92]. Un programme prend la forme d'un nuage de petits morceaux de tâches. Le programme est effectué lorsque tous les morceaux ont été consommés. Tous les ordinateurs d'un réseau se comportent alors comme des piranhas. Plus il y a de piranhas pour attaquer le nuage, plus l'exécution du programme est rapide (Figure 15).
On peut voir dans cette métaphore deux notions importantes:
Pour organiser et contrôler les activités de la tribu, on crée un endroit où toutes les entités informatiques, désormais des agents, viennent chercher ou déposer des informations utiles à la réalisation de la tâche qui incombe à cette société; c'est le tableau noir, ou blackboard, nous aurions préféré l'Agora. Mais la métaphore (encore une!) du tableau noir n'est pas mauvaise: tout le monde peut y lire ou y écrire distinctement pour les autres. Le système FLiPSiDE de Schwartz est un bon représentant des architectures basées sur des tableaux noirs [SCHW93]. Il est possible d'organiser les tableaux noirs eux-même, devenus alors agents, en une structure hiérarchique si l'on suit le modèle LINDA de Gelerntner [GELE92]. Une clef du bon fonctionnement de ce genre de modèles est la définition d'un langage commun à tous les agents du système. Ainsi on voit apparaître des ICL (Interagent Communicatin Language) comme KQML (Knowledge Query and Manipulation Language) [FINI94], KIF (Knowledge Interchange Formalism) [NECH91] ou COOL (COOrdination Language) [BARB95] qui se posent en standards puisque déjà utilisés dans une architecture proche de FLiPSiDE proposée par Genesereth and Singh [GENE94] ou dans le projet SHADE [McGU93].
Divers autres projets utilisant des approches plus ou moins différentes sont en court. Nous citerons CORBA [OMG91] qui, plus qu'un langage commun, cherche à déterminer un ensemble d'objets distribués commun, MASCOS [PARK95] qui développe une architecture à base d'agents mais qui est encore peu détaillée et enfin TELESCRIPT de General Magic Inc. [GENE95] permet que des agents soient envoyés au travers du réseau pour s'exécuter sur des machines distantes. Cette version commerciale, donc réellement implémentée, a le mérite d'exister mais ne permet pas tout à fait tout ce que les concepts sur lesquels elle est basée laissent espérer. Ainsi, dans sa version courante, les agents de TELESCRIPT ne peuvent s'exécuter que sur un type précis de machine.
Cette architecture peut être vue comme une version simplifiée de FLiPSiDE [COHE94], le tableau noir proposé par Schwartz. Une structure hiérarchique de « facilitators » sur lesquels se connectent les agents clients est créée, éventuellement dynamiquement: c'est-à-dire que de nouveaux agents peuvent venir se greffer aux autres en cours d'exécution du programme. Les facilitators sont eux même des agents, comparables à des blackboards, qui fournissent les structures de base pour la communication inter agents, coordonnent le dialogue entre les agents qui leurs sont connectés, s'occupent de la gestion des données qui transitent par eux et mettent à jour une liste des fonctionalités de leurs sous-agents. Ainsi, quand une requête complexe en ICL arrive à un faciltator, il la découpe au mieux pour distribuer des buts à chacun de ses sous-agent spécialisé et en récupère les solutions. A quelque niveau que ce soit, un agent peut avoir besoin d'une information complémentaire pour résoudre un but, il en référe alors à la hiérarchie d'agents jusqu'à une éventuelle demande à l'utilisateur si aucun autre moyen n'est trouvé.
En effet, tournée plus résolument vers un utilisateur potentiel, nous permettant ainsi de faire le lien avec les interfaces, O.A.A. (Figure 16)est formée d'une société d'agents qui interagissent et coopèrent pour résoudre les problèmes de cet utilisateur. Dans sa version pratique, l'utilisation des agents fournit un accès distribué à des applications commerciales comme le mail, des bases de données, etc... Les points forts qui se dégagent de cette architecture et de son application (chapitre V.4.) sont les suivants:
Un langage de communication inter-agent (ICL) et un protocole de requêtes ont été clairement définis. La première conséquence est que les agents peuvent tourner sur différentes plates-formes et être implémentés dans de multiples langages de programmation.
Quelques systèmes de langage naturel sont directement intégrés dans O.A.A. permettant notamment de traduire des requêtes anglaises en ICL. Ceci est indépendant de l'agent de reconnaissance vocale qui est utilisé dans l'application utilisant cette architecture.
L'architecture a été créée de telle façon qu'un nombre important d'agents puissent travailler ensemble, éventuellement en parallèle, pour apporter des réponses rapides aux requêtes reçues.
Plus simple que FLiPSiDE (surtout au niveau de la communication entre agents), cette architecture a le mérite d'avoir été mise en œuvre d'une manière totalement fidèle au modèle conceptuel. C'est grâce à ce démonstrateur que nous pourrons construire de nouvelles architectures tout aussi utilisables mais affinées à l'aide de quelques concepts.
Dans notre première approche, nous avons défini une architecture à base d'agents afin de dégager une vision structurée de l'application tant au niveau de sa description que de sa réalisation. Les agents agissent d'une manière autonome simulant ainsi un fonctionnement parallèle du système. Ceci permet d'envisager le dialogue multimodal en terme de coopération et par la suite d'optimiser la répartition du travail entre agents en distribuant certaines fonctions. C'est de cette façon qu'une interaction faisant intervenir plusieurs canaux de communication est possible: chaque canal est associé à un agent autonome spécialisé. Les agents sont organisés de manière hétérarchiques (Figure 17). On distingue un niveau périphérique, un niveau d'interprétation et un niveau de sémantisation où se fait le lien entre l'application et l'interface. A cette structure en niveaux, s'ajoute la possibilité de communication directe entre agents, indépendamment de leur niveau.
Au niveau périphérique, les agents assurent la relation avec le monde extérieur. Cinq media, associés à des agents spécialisés, sont utilisés dans TAPAGE pour communiquer avec le monde extérieur: un microphone, un stylo, un clavier, un haut-parleur et un écran. Ils engendrent sept modalités: quatre en entrée (parole, écriture, dessin et geste) et trois en sortie (son, parole et affichage), chacune étant prise en charge par un agent spécifique, dit de présentation, qui récolte en permanence des Unités d'Informations (UI) en scrutant les actions de l'utilisateur. Ces UI sont les constituants des événements. Au niveau de l'interprétation, les événements sont stockés sous la forme d'une représentation symbolique amodale en effectuant éventuellement une fusion entre les modalités (Figure 18 et chapitre II.5.2). Cette représentation est alors interprétée dans les termes de l'application par l'agent de contrôle qui établit le lien avec l'application et active les procédures relatives aux actions spécifiées par les événements.
Les agents possèdent des propriétés qui seront exploitées dans les systèmes. L'autonomie et la spécialisation des agents assurent un parallélisme qui rend possible la simulation de la perception multi-canaux. Chaque agent périphérique ne réagit qu'aux stimuli pour lesquels il est programmé et ceci indépendamment de ce qui peut être reçu ailleurs. C'est ainsi que peuvent être réalisés les deux types de multimodalité: synergique ou substitutive. Ces propriétés d'autonomie et de spécialisation vont aussi permettre une répartition des tâches au sein des agents et des notions de distribution de certaines fonctions comme l'interprétation ou l'affichage. Les effets les plus visibles de cette organisation du travail se manifestent par la rapidité de réaction de la machine.
Les agents périphériques possèdent une vue des représentations internes et de la surface d'affichage. Ils peuvent ainsi savoir si le signal produit par l'utilisateur les concernent en fonction de l'état de l'application. L'interpréteur a la possibilité de résoudre la plupart des ambiguïtés en analysant son propre état. S'il sait qu'il traite un objet, il n'a d'autre représentation de cet objet qu'une représentation symbolique: c'est l'agent de contrôle qui fournira les coordonnées et le type de l'objet. On peut affirmer ici que l'interprétation est distribuée sur divers niveaux de l'interface et de l'application car le premier tri effectué par l'agent d'interprétation permet d'alléger considérablement le noyau fonctionnel, en particulier au niveau de la gestion des cas difficiles et des erreurs.
La communication directe entre agents, indépendamment de leur niveau, permet des actions que nous appelons réflexes. Suite à un événement qui n'est pas une commande, qui n'a donc pas à impliquer le noyau fonctionnel comme la sélection d'un objet par exemple, l'agent d'affichage est directement prévenu par l'agent responsable des gestes pour qu'il mette en pointillés l'objet ou les objets sélectionnés. L'application n'est en rien perturbée par ces dialogues inter-agents. Ceci implique bien entendu que les agents possèdent un minimum d'informations sur les données et le contexte de l'application. De façon réciproque, l'application peut afficher des informations à l'écran sans recourir à l'agent d'affichage mais en activant directement l'agent Ecran. La fonction d'affichage est distribuée entre l'interface et l'application pour améliorer encore les performances du programme.
Nous donnons deux exemples pour illustrer les avantages de l'autonomie des agents périphériques et des actions réflexes:
Les gestes sont utilisés aussi bien pour sélectionner des parties d'un dessins que pour désigner une position (dans la commande «mets ça là», l'utilisateur sélectionne en pointant à l'aide du stylo l'objet «ça» puis la position «là»). L'agent en charge des gestes compare alors les coordonnées physiques (x,y) du stylo sur l'écran qui lui sont fournies avec la représentation qu'il a du dessin effectivement affiché sur cet écran. C'est à ce niveau, très tôt dans le processus, que la discrimination est faite entre un objet et une position et que l'information est envoyée à l'interpréteur. C'est aussi l'agent geste qui va activer une action réflexe en envoyant directement à l'agent d'affichage un ordre de retour à l'écran (un objet sélectionné est réaffiché en pointillés, une position est matérialisée par une croix). L'utilisateur réalise alors que la machine comprend ce qu'il est en train de faire, le retour apparaissant alors que la commande n'est pas complète, ceci lui laissant la possibilité d'effectuer des changements sans avoir à aucun moment impliqué le noyau fonctionnel. Toutes ces opérations ont été menées au niveau périphérique.
Un autre exemple de l'intérêt offert par les actions réflexes concerne l'équivalence entre la parole et les gestes. Un élément dans un menu peut être pointé par le stylo ou sélectionné en prononçant son nom, quelque soit le mode de sélection, il y a un retour visuel confirmant le choix (en changeant de couleur). Ceci est réalisé par l'agent d'affichage après qu'il a reçu (de la part de l'agent parole ou geste) l'information adéquate.
L'architecture MMAAR que nous présentons ici est née d'une fusion des architectures O.A.A. et de TAPAGE. L'idée de base provient du constat que les agents d'O.A.A. n'ont pas une assez grande indépendance de décision au niveau local, c'est notamment le cas de l'agent interface. Tandis que TAPAGE possède dans ce domaine une grande marge de manœuvre puisque beaucoup de décisions (les réflexes par exemple) sont prises sans en référer au noyau fonctionnel. D'autre part une interface de type blackboard comme O.A.A. permet, comme on le prouvera plus loin, une plus grande indépendance entre l'application et l'interface en ouvrant de plus la porte aux systèmes de type « plug and play ». Nous avons donc pris dans chacune des deux architectures les meilleurs éléments pour construire MMAAR. Les Micro Agents sont comparables aux agents périphériques de TAPAGE. Afin de ne pas restreindre le concept de Micro Agents au domaine des interfaces Homme-Machine (agent écriture, parole, etc...), nous avons imaginé d'autres types de Micro Agents comme l'agent GPS (Global Positioning System). L'agent GPS est, comme tous les Micro Agents, très spécialisé et unidirectionnel (Monde Réel vers Monde Informatique pour l'agent GPS, Monde Informatique vers Monde Réel pour l'agent affichage par exemple) et fournit à une base de données les coordonnées sur le globe des objets appartenant à cette base en temps réel. C'est un agent d'interface Monde Réel-Monde Informatique. L'interpréteur présent dans TAPAGE devient alors un Macro Agent comme tous les autres noyaux fonctionnels autonomes qui vont constituer l'application (Figure 19).
Nous pouvons donner une définition plus générale des Micro et des Macro Agents:
Dans les applications utilisant MMAAR, l'ICL utilisé est le Prolog, ce langage étant particulièrement bien adapté à l'envoi de messages. En effet, Prolog permet l'unification et le backtracking, qui sont très utiles pour résoudre n'importe lequel des éléments d'un message. Ainsi, si le message envoyé est phone('julia', X), le numéro de téléphone correct sera mis dans X, mais si la commande est phone(Y, X), alors tous les numéros associés à tous les noms seront renvoyés, sans plus d'effort.
L'architecture en réseau que nous décrivons peut être lue à plusieurs niveaux, un peu comme un algorithme récursif. En effet, les Micro Agents sont attachés à un Macro Agent qui s'occupe généralement de l'interprétation des données envoyées mais les Macro Agents ont eux-mêmes cette structure quand ils se liguent pour fournir des informations à un Macro Agent Hiérarchiquement supérieur.
Afin de bien comprendre l'implémentation concrète de MMAAR, nous donnons ici une liste des agents généralement impliqués dans les applications développées et leurs rôles. On remarquera que certains des Macro Agents autonomes sont utilisés de la même manière que dans l'architecture O.A.A:
Les interfaces à base d'agents ne font évidemment pas l'unanimité. Souvent les objections présentées sont plus philosophiques que techniques. Pour s'en persuader nous donnons ici quelques arguments avancés par les détracteurs [LAUR92]:
Les utilisateurs n'ont pas envie d'avoir quelqu'un dans leur machine, qui prennent des décisions à leur place. Les agents sont décrits comme des virus.
Si un agent ressemble et agit tant comme une personne réelle et que l'utilisateur le maltraite sans retour de bâton, il y a danger que ce même utilisateur agisse de même avec ses vrais agents humains parce qu'il n'a plus une vraie représentation du vrai monde. C'est un peu le problème de l'immersion dans les jeux vidéos, où certains continuent à vivre des heures après avoir arrêté.
L'implémentation d'agents dans une interface implique l'utilisation de techniques d'Intelligence Artificielle (nous avons vu que nous nous sommes effectivement inspirés de telles techniques) et l'IA ne marche pas (il s'agit bien sûr d'un argument provocateur).
S'il est difficile d'entrer dans la polémique philosophique et éthique de l'utilisation des agents, nous avons réalisé et étudié des architectures d'interfaces qui nient le dernier argument avancé, et nous rappelons de plus que certaines d'entre elles n'emploient pas des techniques de l'IA.
Malgré le peu de développements pratiques, PAC est une architecture de référence dans le monde des interfaces Homme-Machine. En effet, ce modèle met bien en évidence les problèmes de la séparation entre le noyau fonctionnel d'une application et de son interface, amplifiant ainsi les conseils donnés à Seheim. L'autre apport est la confirmation de l'efficacité du traitement parallèle pour les interfaces au niveau le plus extrème de l'interaction. Si PAC-Amodeus tente de rendre plus fonctionnel ce type d'architecture en y introduisant les concepts d'ARCH, nous préférons utiliser des modèles d'architecture comme ceux de TAPAGE, O.A.A. ou MMAAR qui ont fait la preuve de leur efficacité. Ils sont directement et pratiquement applicables et surtout facilement modifiables pour correspondre aux besoins d'un concepteur de systèmes à agents.
|
|
