Intégration distribuée de raisonnements multiples en contexte
N. Abchiche-Mimouni
[email protected] 523 Place des Terrasses de l'Agora
91000 Evry, France
Résumé
Cet article présente un modèle de co- opération permettant à des méthodes de raisonnement hétérogènes d’être intégrées pour la résolution d’un pro- blème donné, qu’elles ne pourraient résoudre individuellement, tout au moins, avec des critères acceptables.
Dans le système multi-agent (s.m.a), que nous avons implanté, chaque agent représente une méthode de rai- sonnement particulière et devient alors un point de vue spécifique sur le pro- blème. L’originalité de notre approche se situe dans la manière même de combiner les méthodes, puisque l’ac- tion à effectuer est déterminée de fa- çon dynamique et décentralisée en fonction de la pertinence des mé- thodes, qui elle-même dépend du contexte. En effet, une expertise de coopération est embarquée dans chaque agent et lui permet de décom- poser le problème, de raisonner sur les caractéristiques de ses propres mé- thodes et sur celles de ses accoin- tances, et d’observer l’évolution de la résolution du problème, afin de déter- miner son attitude de coopération. Ce type de raisonnement, qualifié de co- opératif, est illustré sur des scénarios dans le domaine du diagnostic de pannes. Nous avons pu observer l’or- ganisation du raisonnement coopératif autour d’un agent privilégié qu’il est difficile de prédire de façon centralisée.
La représentation de la notion de contexte individuel et de contexte so- cial d'une part, et l’introduction expli- cite, dans notre s.m.a, de la notion d’agent pivot d'autre part, a permis non
seulement d’optimiser le nombre de cycles exécutés par les agents, mais également de résoudre les problèmes de l’arrêt du s.m.a et de la collecte d’une solution globale à partir d’une résolution distribuée.
Mots-clés
: Agent (architecture), Coopération, Coordination, pertinence, contexte.Abstract
This paper addresses the problem of integrating several heterogeneous reasoning methods (R.M.) to solve a common problem. We want these R.M.
to cooperate in a Multi-Agents system,
where each agent represents one do-
main R.M. Since none of the R.M. is
able to solve a given overall problem
alone, the solution is the use of co-
operation between multiple agents. In
fact, each agent has a limited point of
view of the problem and has a set of
methods with limited performances. Our
distributed approach make each agent
using local cooperation expertise and
reasoning in a in two complementary
ways: first, it reasons about how to take
advantage of others' reasoning capab-
ilities, second, it has to find ways to
make others know their own reasoning
capabilities so that these others take
advantage of its capabilities. Such a
reasoning way is called cooperative
reasoning. In our diagnosis domain ap-
plication, in most observed cooperative
scripts, a particular agent seems to be
the most adequate to solve each par-
ticular problem. So, we have called this
agent a pivot agent and we have im-
plemented an automatic mechanism for
determining dynamically, the agent
having this role. This mechanism is based on agents' individual context and social context. This is to distinguish the context related to the methods which are internal to the agents of the context for interaction between them.
This result is very important because of the difficulty to analyze and classify the problems to determine the most ad- equate R.M. for a particular problem.
The pivot agent has also the role of de- tecting the end of the problem solving process.
Keywords: Agent (architecture), Co- operation, Coordination, context relev- ance.
1 Introduction
Le point de départ de nos réflexions est l’étude des modèles de raisonnement en Intelligence Artificielle (I.A). Gérard Sabah a réalisé dans (Sabah 89) une étude détaillée de divers modes de raisonnement. Il cite le raisonnement déductif, les raisonnements qualitatifs, les raisonnements non monotones et enfin, les raisonnements plausibles (induction et analogie). Il explique les spécificités de chacun en termes de types de déductions effectuées et d'incertitude de la validité des raisonnements eux-mêmes. Pour effectuer un raisonnement en vue de la résolution d'un problème, nous évoquons souvent, plus d'un type de raisonnement.
Par exemple, lors d'un raisonnement déductif en vue d'une démonstration d'un théorème, nous avons souvent recours à des exemples ou contre-exemples pour effectuer certaines étapes. Ainsi, un raisonnement par l’absurde peut être utilisé pour démontrer une partie du théorème.
Dans les systèmes d’I.A, la représentation de plusieurs types de connaissances (heuristiques, structures et comportement, connaissances de conception,…) avec différents modes d’exploitation de ces connaissances dans un même système est de plus en plus répandue.
Cela est dû aux limitations individuelles des modes d’exploitations des connaissances, et à la nécessité de faire intervenir différents types de connaissances pour cerner un problème dans sa totalité. Dans ce travail, nous appellerons méthode de raisonnement (M.R), un mode de raisonnement tel qu’il est défini par G. Sabah, associé à un type de connaissances spécifiques.
L’intégration de M.R consiste à mettre plusieurs M.R dans un même système afin de combiner leurs avantages. Cela permet d’augmenter la diversité des problèmes résolus pour un même domaine d’application et/ou d’améliorer la qualité des solutions trouvées. Par
exemple, dans une M.R basée sur un modèle comportemental, il est impossible de raisonner sur la structure du système, alors qu’avec une M.R basée sur la classification des connaissances sur la structure, le comportement ou de tout autre type peuvent être modélisées. De nombreuses approches que nous qualifions d’approches d’intégration existent dans la littérature. Ces approches sont centrées soit, autour d’une M.R particulière (Rissland & Skalak 89), soit autour d’un algorithme qui réalise l’intégration (Sticklen 88), (Chittaro & al. 89). Elles ont comme point commun, la difficulté à s’adapter dynamiquement au problème à résoudre en figeant la manière de combiner les M.R. De plus, l’ajout de nouvelles M.R à de tels systèmes remet en cause l’algorithme d’intégration.
Pour pallier cette insuffisance, nous proposons une intégration distribuée en utilisant la coopération dans les systèmes multi-agents. Les agents coopèrent pour intégrer les M.R et construisent ainsi dynamiquement, grâce à un modèle de coopération, un scénario permettant d’aboutir à la résolution d’un problème spécifié par l’utilisateur. Une telle intégration est possible car chaque agent adapte l’utilisation de ses propres méthodes en fonction de son contexte individuel (pertinence liée à la disponibilité des données nécessaires à leur exécution) et de leur contexte social (disponibilité des autres agents et pertinence de leurs méthodes).
Le prochain paragraphe traite les questions fondamentales que nous nous sommes posées pour la conception de notre modèle de coopération. Le paragraphe 3 illustre le fonctionnement de notre s.m.a sur un exemple de diagnostic de pannes. Ensuite, la mise en œuvre de notre modèle de coopération est expliquée en décrivant différents aspects de notre système. Avant de conclure, le paragraphe 5 est une discussion sur les résultats de notre approche et des principaux résultats. Enfin, en conclusion, nous citons quelques perspectives à ce travail.
2 Fondements de notre ap- proche
Nous partons du constat qu’aucune M.R ne peut prétendre résoudre, à elle seule, ne serait-ce qu’un type de problème dans sa totalité. Par ailleurs, il n’existe pas de démarche systématique permettant d’élaborer une manière de combiner des M.R sans que cette démarche n’ait une complexité rendant son utilisation limitée. En effet, les travaux existants sont tous basés sur une étude en amont, des M.R jugées pertinentes pour un type de problème donné, pour ensuite déterminer une approche procédurale permettant de les combiner. Nous nous proposons d’aborder le problème d’intégration de M.R d’une façon distribuée et décentralisée. Nous avons conçu et réalisé une approche multi-agents dans laquelle
un ensemble d’agents s’auto-organisent pour mettre en synergie un ensemble de M.R pour la résolution d’un problème. Afin d’éviter les inconvénients des aprroches d’intégration centralisées, nous nous sommes posé les questions suivantes :
a)
Est-il possible de doter chaque M.R de moyens pour déterminer sa propre pertinence dynamique- ment en fonction du contexte, qui lui-même évolue dynamiquement ? Pourquoi ne pas expliciter les ca- ractéristiques des M.R localement ?b)
A un instant donné, que ferait une M.R lorsque ses méthodes ne sont pas pertinentes ? Pourrait-on do- ter les M.R de moyens leur permettant de pallier à ces manques et à ceux d’autres M.R ?c)
A quel niveau de modélisation faudrait-il représen- ter les connaissances citées en a) et b) ?Tout au long de cet article, nous allons nous référer à ces questions de façon explicite à chaque fois que cela est possible, notamment dans la section dédiée aux résultats obtenus.
Notre approche consiste à utiliser les systèmes multi- agents adaptatifs pour construire dynamiquement et de façon distribuée, la manière de combiner plusieurs M.R - représentée chacune par un agent - pour la résolution d’un problème auquel le système est confronté. Plus précisément, il s’agit de concevoir un s.m.a dans lequel les M.R coopèrent et interagissent pour échanger des compétences et des résultats. Dans une telle approche, les M.R s’entrelacent en fonction de leur pertinence qui, elle-même, est déterminée en fonction du contexte individuel et social des M.R. Il en résulte un scénario de résolution du problème auquel le système est confronté.
Dans le prochain paragraphe, nous illustrons notre approche sur un exemple d’application au diagnostic de pannes. Par ailleurs, ce travail a fait l’objet d’une extension pour une application de modélisation biologique, en cours de publication dans une revue du domaine.
3 Une étude de cas
Depuis les débuts de l’I.A, le diagnostic de pannes est l’un des domaines d’application qui a suscité le plus d’intérêt pour l’utilisation de méthodes de raisonnements automatiques et pour la résolution de problèmes. C’est également un des domaines d’application qui fait l’objet de nombreuses approches d’intégration.
Nous allons illustrer notre système sur un exemple de la fonction de l'essuie-lave-vitre dans un véhicule automobile. Dans un s.m.a, où chaque agent représente une M.R particulière, on montre comment un raisonnement coopératif est mis en œuvre pour détecter la cause d'une panne de cette fonction. Dans le scénario choisi, quatre agents spécialistes en diagnostic
(utilisateur inclus), coopèrent en utilisant, chacun, des connaissances et méthodes spécifiques (point de vue particulier sur la fonction de l’essuie-lave-vitre).
L’exemple ci-dessous montre la situation à diagnostiquer fournie au système.
Exemple de situation à diagnostiquer
(nonOk Lave-vitre) //lave-vitre ne fonctionne pas (cmd4 M145 on) //monomanette actionnée (typeVéhicule X53)//Code marque véhicule (Rapidité #) //Critère de rapidité négligeable (Fiabilité 7) //critère de fiabilité important
L'agent comportemental, Comport, utilise des connaissances sur la structure et le comportement, tout en prenant en compte les liens entre les composants. Il procède à la détection de la cause d’une panne en propageant les symptômes et en effectuant des hypothèses sur le mode de comportement des composants. Le diagnostic est fourni en donnant les comportements des composants qui "expliquent" les symptômes considérés en entrée. Ses méthodes de diagnostic sont fiables mais avec un risque d’explosion combinatoire.
L'agentCBRraisonne à partir d'une bibliothèque de cas de pannes déjà rencontrés. Il s’agit déterminer une possible analogie entre la situation à diagnostiquer et les cas déjà répertoriés dans sa base de cas et d’adapter la solution au problème posé. Ses méthodes sont rapides, si des indexes pertinents sont disponibles pour le parcours de la base. Les résultats de ce type de raisonnement sont moins fiables que ceux de Comport, car ils sont liés à la fiabilité des méthodes d'accès aux cas
L'agentAmdec raisonne sur les causes de défaillances des composants du système à diagnostiquer ainsi que l'analyse de l'effet des défaillances sur des indices tels que : la gravité de la défaillance, la facilité de sa détection, son effet sur la sécurité, la vente, etc. Il est caractérisé par un degré de fiabilité élevé, même si ses méthodes sont basées sur des statistiques, tant ces statistiques sont significatives. Cependant, cela se paye par un risque d’explosion combinatoire des calculs.
L'utilisateur joue un double rôle très particulier : il répond, dans la mesure de ses possibilités aux requêtes des agents, ou bien il peut spontanément fournir une information résultant de ses observations. Il n’est pas représenté sur la figure, pour des raisons de clarté.
L’intérêt du scénario visualisé par la figure FIG.1, est dans le raisonnement, appelé raisonnement coopératif, mis en œuvre par les agents et qui permet une synergie entre les M.R, lors de la recherche de la cause de la panne décrite par l’utilisateur.
A T0, chaque agent va tenter de détecter les causes de ce dysfonctionnement décrit en TAB.1.
L'agent CBR va tenter d’accéder à sa bibliothèque de cas pour rechercher des cas candidats. Alors que
Comport va parcourir son circuit pour rechercher les éventuels suspects dont le mauvais comportement expliquerait les symptômes observés. L'agent Amdec peut identifier des causes possibles de défaillance de composants dont l'effet peut empêcher le fonctionnement du lave-vitre (car cet agent raisonne en termes de probabilité qu'une cause entraîne effectivement la défaillance). Quant à l’utilisateur, son intervention est motivée par l’observation du fonctionnement du s.m.a.
A T1, l'agent CBR constate qu'il n'a pas une description assez précise de la situation : il décide de ne pas entamer sa recherche des cas candidats. Il préfère attendre d'acquérir d'autres informations, et envoie une
requête de demande d’information ("demandeInfo" sur la figure) aux autres agents ; permettant ainsi de répondre à l’exigence de fiabilité de l’utilisateur.
Pendant ce temps, l'agent Amdec a trouvé deux hypothèses estimées être les plus probables : (1) le réservoir d'eau est vide et (2) la pompe est défaillante. A T3, l'agent Amdec décide de communiquer ces deux hypothèses à l’agent Comport. Sachant que l'agent CBR ne peut pas, actuellement, raisonner sur ce type de résultats, il ne les lui communique pas. Le but de l'agent Amdec est non seulement de faire connaître aux autres, ses résultats, mais surtout d'avoir leur avis, car ses méthodes de discrimination sont peu efficaces.
FIG.1 : Visualisation d’un scénario de coopération
(Légende : les rectangles représentent la boîte aux lettres des agents, alors que les rectangles aux bords arrondis représentent leur agenda)
L'utilisateur, par une simple vérification visuelle, s'aperçoit que le réservoir d'eau n'est pas vide. Il informe les autres agents que l'hypothèse (1) doit être écartée.
Pendant ce temps, Comport a recherché des tests permettant de discriminer entre ses hypothèses actuelles. Il décide de demander à l'utilisateur de tester la tension aux bornes de la pompe.
L'utilisateur a éliminé la pompe lave-vitre comme suspect (il entend qu'elle fonctionne). Il décide alors de communiquer le résultat de son test à tous les agents car ce type d'information (résultat de test) est susceptible d'être utile à tout type de raisonnement. Cela constitue la réponse à la demande de l'agent Comport (qui voulait
savoir s'il y avait bien une tension aux bornes de la pompe).
L'agent CBR décide, qu'avec cette nouvelle information, il peut amorcer le parcours de base de cas, il obtient alors une liste de cas candidats. Tandis que l'agent Comport, en utilisant cette information, élimine tous ses suspects, il conclut que le problème n'est donc pas de nature électrique.
L'agent Comport, sachant que l'agent CBR classe les cas de sa base, par type de problème, décide de lui communiquer son dernier résultat (le problème n'est pas électrique).
Enfin, l'agent CBR utilise l'information communiquée par Comport pour éliminer les cas qui identifient des problèmes électriques. Comme il ne lui reste qu'un seul
cas candidat :le tuyau du réservoir est détérioré, il n'a pas d'autre choix que de demander à l'utilisateur de vérifier si ce cas ne constitue pas la cause du symptôme de départ.
Finalement, l'utilisateur prend en compte le diagnostic de l'agent CBR et constate qu'effectivement, le tuyau du réservoir d'eau est bouché empêchant l'eau d'arriver.
Le scénario de coopération se construit dynamiquement au fur et à mesure de l’exécution des agents. Notre objectif est de concevoir des s.m.a capables de générer ce type de scénario de façon dynamique pour chaque nouvelle instance du problème.
4 Description de notre système
Afin de permettre aux agents de raisonner sur la pertinence de leurs méthodes en fonction de leur contexte individuel et social, nous avons introduit une modélisation explicite de la coopération au niveau de chaque agent. La coopération est alors vue comme une activité de raisonnement à part entière est prise en charge à part entière et au même titre que l’expertise du domaine d’application du s.m.a.
4.1 La coopération
La coopération est un thème central en Intelligence Artificielle Distribuée où il s’agit souvent, de mettre en place des mécanismes pour faire coopérer plusieurs systèmes intelligents distribués. De nombreux travaux proposent une modélisation de la coopération à travers des concepts précis tels que la notion d’engagement introduite par (Gasser 91), le Plan Partiel Global de (Lesser & al. 04) ou les réseaux contractuels pour l’allocation de tâches (Smith 88), ou encore la négociation pour résoudre des conflits (Sycara 88). Des travaux plus récents proposent des environnements permettant à des agents de raisonner sur les concepts liés à la coopération pour prendre des décisions d’interaction optimales. Par exemple, (Jiaying & al. 04) s’intéressent à ce qui peut améliorer les négociations en vue d’optimiser les performances de la résolution collective des agents. A un autre niveau, notre système se veut un cadre permettant à des agents de choisir leur propre vision de la coopération tout en étant indépendant d’une modélisation particulière. Il est basé sur une représentation explicite d’une expertise de coopération, qui est un corpus de connaissances issues de travaux sur la coopération. Il a pour objectif de combiner de façon dynamique et distribuée des méthodes de raisonnement hétérogènes pour la résolution d’un problème commun. Ainsi, il permet à la fois un raisonnement sur le processus de résolution du problème et sur les mécanismes de coopération. De plus, il répond aux exigences suivantes :
Généricité : indépendance par rapport au domaine
d’application. En effet, notre système distingue les connaissances de coopération des connaissances du domaine.
Ouverture : possibilité d’ajout de nouvelles mé- thodes de raisonnement, même en cours d’exécution car la prise ne compte de nouvelles tâches à réaliser a lieu durant la phase d’exécution des agents.
Robustesse : la défaillance d’une méthode de raison- nement n’affecte pas le fonctionnement global du système. En effet, les autres agents auront simple- ment à faire avec un contexte social appauvri.
Ces deux dernières propriétés sont, aussi, en partie une conséquence de l’utilisation des s.m.a.
4.2 Modéliser des expertises
Notre modèle de coopération est basé sur une modélisation des expertises du domaine (diagnostic) et de coopération à un niveau conceptuel, et sur la définition d’une représentation consensuelle des concepts manipulés au niveau du domaine. L’idée de la modélisation de connaissances à un niveau conceptuel a été introduite par (Newell, 82) pour concevoir des systèmes flexibles auxquels il est aisé d’ajouter de la connaissance ou de les modifier, éventuellement par le système lui-même. Ces connaissances forment un corpus permettant une compréhension des expertises représentées et de la manière dont elles vont opérer lors du fonctionnement du système indépendamment de leur implémentation. Nous exploiterons cette idée pour les expertises de coopération et du domaine dans, en employant la méthodologie ComMet (Steels 92). Il s’agit de décomposer les expertises selon 3 axes : les tâches ou buts à atteindre, les méthodes décrivent les différents moyens de réaliser les tâches et lemodèle du domaine décrit les connaissances nécessaires au choix d'une méthode et celles utilisées pour l'exécution de la méthode choisie. Une méthode peut donner lieu à des sous-tâches si une décomposition est nécessaire. En plus de représenter les dépendances entre ces trois dimensions, nous avons associé une liste de caractéristiques à chaque méthode, pour exprimer leurs performances en termes de rapidité, de complexité, de fiabilité ou de précision.
Le tableau ci-dessous montre des exemples de décomposition de tâches en sous-tâches avec différentes méthodes associées.
Exemples de décomposition de tâches
Diagnostic Coopération
Tâches générer-Hypothèse, discriminerHypothèse
allouerTâche, déléguerTâche, résoudreConflit Méthodes indéxer,
parcoursProfondeur
négocier, relaxerContrainte Modèle du
domaine
symptômes, base de cas
compétences, évolutionRésolution
Définir une représentation consensuelle permet aux agents de communiquer en dépit de représentations locales hétérogènes. La figureFIG.2montre comment le concept d’hypothèse de panne est instancié de façon spécifique pour chaque M.R. Chaque agent conserve une représentation individuelle adaptée à ses méthodes.
Lorsqu’il communique une information (ex. une hypothèse de panne), il passe par cette représentation consensuelle en employant une fonction (notée F sur la figure). Ainsi, il passe de sa représentation locale au concept consensuel. A l’inverse, à la réception d’un message, il applique une projection (notée P sur la figure) pour extraire une représentation du concept communiqué manipulable par ses méthodes.
FIG.2 : Instanciations du concept d’hypothèse
4.3 Modèle d’agent coopératif
Un agent coopératif est un agent capable de raisonner sur ses propres compétences et sur les compétences des autres afin de mener à bien une résolution d’un problème commun. Dans notre système, nous avons défini une architecture d’agent coopératif dont les composantes sont représentées par la figure FIG. 3. Le moteur est un algorithme qui se déroule en 5 principales étapes :
(1) Sélectionner la tâche la plus prioritaire,Tc,qui devient alors le but courant à atteindre.
(2) Soit E1 l’ensemble des méthodes activables1 pour ce but.
(3) SoitE2, l’ensembleE1privé des méthodes qui ne satisfont pas les critères associés au but courant.
(4) Sélectionner, en fonction du contexte, une méthode de l’ensemble E2 à exécuter.
(5) Tant qu’il y a des tâches dans l’agenda, aller à (1).
Cet algorithme implémente le fonctionnement de base de chaque agent. Il manipule les tâches et les méthodes en choisissant, pour chaque tâche, une méthode pour l’exécuter. L'agenda est une structure dynamique contenant la liste des tâches de coopération et/ou du domaine à effectuer. Les tâches y sont insérées par le
1 Une méthode est activable si ses entrées sont disponibles.
superviseurau fur et à mesure de leur candidature. La mémoire de travail contient les déductions et les résultats générés par l’exécution des méthodes. Elle contient aussi les structures de données spécifiques à la M.R de l’agent, telle que par exemple une base de cas pour l’agent CBR, un modèle de diagnostic pour Comport, ou un arbre de défaillance pour Amdec.
Le superviseur observe, évalue et guide l’activité du moteur. Pour cela, il procède en trois étapes :
a) Etape 1, la gestion des tâches : elle concerne la mise à jour de l’agenda. En particulier, des tâches de coopération deviennent candidates, soit s’il n’y a pas de méthode satisfaisant les critères associés à la tâche, soit s’il n’y a pas de méthodes activables.
Dans le premier cas, c’est une tâche de coopération déléguer-Tâche qui devient candidate pour per- mettre à l’agent de demander à un autre agent de réaliser la tâche. Dans le second, l’échec est dû à une absence de données nécessaires à l’exécution de méthodes. Alors, une tâche de coopération de- mander-information devient candidate. Ce dernier cas se présente dans notre scénario lorsque l’agent CBR, à T1, détecte que le parcours de la base de cas nécessite l’acquisition d’informations.
b) Etape 2, la mise en place d’une attitude de coopéra- tion : chaque agent peut adopter une attitude de co- opération self-Résolution, altruiste ou parasite.
L’attitudeself-Résolution, signifie que l’agent réalise ses tâches par lui-même.
De même qu’il résout ses propres buts en priorité au lieu de répondre aux demandes des autres agents. Un agent qui adopte une attitudealtruistedévoue ses ressources à effectuer en priorité des tâches qui ne le concernent pas directement. L’attitude de coopération parasite amène l’agent à déléguer ses propres tâches à ses accoin- tances ; cela peut être dû à un manque de données ren- dant ses méthodes inutilisables ou à l’absence totale de méthodes pour la réalisation d’une tâche, ou encore, à un agenda surchargé. L’attitude de coopération est cal- culée en fonction d’un certain nombre de paramètres se- lon un graphe d’influence (exemples : état d’avance- ment de la résolution, l’état de la boîte aux lettres, atti- tude de coopération des autres agents, état de l’agent lui-même). Les arcs qui relient les paramètres et les dif- férentes attitudes de coopération possibles symbolisent la manière avec laquelle le paramètre contribue à déter- miner l’attitude. Une influence positive signifie que le paramètre renforce l’attitude, une influence négative si- gnifie que le paramètre va à l’encontre de l’attitude. En- fin, une influence neutre signifie que le paramètre n’a pas d’incidence sur la détermination de l’attitude.
L’état de la boîte aux lettres d’un agent influence diffé- remment l’attitude de coopération selon qu’elle contienne des messages d’information, ou bien des mes- sages qui sont des demandes d’information. Dans le pre- mier cas, c’est l’attitude parasite qui est renforcée alors que dans le second c’est l’attitude altruiste. Dans le scé- nario présenté, l’agent CBR adopte une attitude parasite lui permettant de solliciter les autres agents pour la tâche de discrimination entre les hypothèses générées.
FIG. 3 : Architecture d’un agent
c) Etape 3, la gestion des critères : cette étape assure l’initialisation et le réajustement des valeurs des cri- tères associés aux tâches. Un réajustement a lieu en cas d’échec dû à l’absence de méthodes satisfaisant les critères, non résolu au niveau de l’étape de ges- tion des tâches. Dans ce cas, ni l’acquisition d’in- formations nouvelles, ni la sous-traitance de la tâche n’ont abouti à sa réalisation.
Si l’illustration de notre approche, par un scénario de recherche de panne, montre son intérêt et sa faisabilité, il n’en demeure pas moins que sa validation reste encore empirique. Dans le paragraphe suivant, nous soulignerons une avancée conceptuelle qualitative, réalisée grâce à diverses expérimentations et analyses de la dizaine de scénarios générés.
5 Apports et analyse des résul- tats de notre approche
Le scénario considéré ci-dessus montre, d’une part, comment la fiabilité d’un modèle comportemental, la rapidité et l’expérience d’un raisonnement à base de cas sont combinées par un ensemble d’agents d’une manière non déterminée à l’avance et totalement distribuée, de sorte à répondre à une situation de diagnostic posée par un utilisateur. D’autre part, le risque d’une explosion combinatoire des méthodes basées sur un modèle a été atténué par les modèles à base d’arbre de décision et de cas. Nous constatons que même si l’utilisateur a spécifié une fiabilité élevée (7 sur une échelle de 1 à 10), l’agent qui a fourni la solution finale (CBR) ne possède pas de méthodes ayant ce niveau de fiabilité. Ce résultat, à priori surprenant, s’explique par la possibilité que possèdent les agents de se "répartir" le problème à résoudre au fur et à mesure de l’avancement de sa
résolution en fonction des caractéristiques de leurs méthodes d’une part, et en fonction de l’exigence posée par l’utilisateur sur la solution et le processus de résolution d’autre part.
L’investissement nécessaire en termes de modélisation et de formalisation des connaissances en vue d’explorer divers scénarios de coopération a limité la diversité des expérimentations réalisées au diagnostic de pannes. Sur 10 scénarios générés et étudiés, 7 d’entre eux ont particulièrement retenu notre attention. Dans un premier temps, nous avons constaté qu’un agent semblait se distinguer des autres dans un rôle centralisateur. Un agent semble diriger la résolution sans qu’il soit capable, à lui seul, de mener la résolution à bout. C’est le cas de l’agent CBR du scénario présenté dans la figure FIG.1.
Etant donnée la difficulté à prédire de façon déterministe un tel fait avons alors formulé l’hypothèse suivante : "il existe, en général, une M.R privilégiée, difficilement prédictible automatiquement, pour la résolution de chaque type de problème. Cependant, cette M.R. nécessite quelques interventions sans lesquelles elle ne saurait donner satisfaction." Sur la base de cette hypothèse, nous avons introduit la notion d’agentpivotexplicitement dans notre s.m.a, qui est un rôle dévolu à un agent particulier. Un agent se reconnaît comme étant le pivot de la résolution, (1) s'il est celui qui fait avancer la résolution, (2) si la communication s'organise autour de lui et (3) s’il n’a pas fait appel à d’autres M.R sans que cela ne l’empêche de faire évoluer la résolution, depuis un certain temps. Pour notre application de diagnostic, les agents disposent localement d'une fonction d'évaluation de l'évolution de la résolution du domaine (nombre d’hypothèses traitées/nombres d’hypothèses discriminées). Un agent estime que la communication s'organise autour de lui en mesurant la diversité des messages reçus. Celle-ci est
mesurée par le quotient : Nombre d'émetteurs différents des messages reçus/Nombre total d’accointances. Plus ce rapport est voisin de un, plus la diversité des messages est élevée, et plus, cela signifie que la communication s'organise autour de lui. Dès qu'un agent possède un ratio supérieur à un seuil déterminé (0.5 pour nos tests) et qu'il s'estime être celui qui fait avancer la résolution, il est candidat au rôle de pivot. Il en informe les autres agents. Si la réception de cette information n'engendre aucun conflit, l'agent remplit son rôle normalement et il en informe les autres agents qui vont adapter leur résolution ou plus exactement, leur attitude de coopération en fonction de cette nouvelle organisation. Dans le cas contraire, c’est celui dont les valeurs sont les plus élevées pour la diversité des messages et la fonction d'évaluation du domaine qui assume le rôle de pivot. Cette organisation permet de résoudre simultanément les problèmes l’arrêt du s.m.a et de la collecte de la solution finale à partir de la résolution collective. En effet, ces deux fonctions sont alors assurées par l’agent pivot.
Un autre aspect que nous avons exploré à partir de nos scénarios est l’influence du contexte sur la pertinence des méthodes spécifiques aux M.R. nous avons introduit modifications du contexte sous la forme de "bruit", par le biais de l’agent utilisateur. Cela est réalisé par exemple, en modifiant l’attitude de coopération ou bien en fournissant spontanément des données aux agents.
6 Conclusion et perspectives
Nous avons proposé un modèle de coopération permettant de donner lieu à un s.m.a adaptatif , pour l’intégration distribuée de M.R hétérogène dans un s.m.a. Des approches (Dutta & al. 06), (Tambe & al.
00), basées sur les s.m.a proposent d’adapter le comportement des agents afin de combiner leurs compétences individuelles. Cependant, à notre connaissance, notre approche est la seule capable de procéder à une intégration distribuée pour construire dynamiquement et de façon adaptative, des scénarios permettant d’aboutir à une résolution collective pour un même problème. Le résultat le plus important est l’émergence de la notion d’agent pivot à partir de l’analyse de scénarios de coopération générés. La difficulté à expérimenter notre système à grande échelle est liée à l’investissement conceptuel nécessaire pour la modélisation des connaissances du domaine afin que le système soit capable de les compiler et de les manipuler au niveau des agents. Cependant, une étude théorique montre déjà la supériorité d’une approche distribuée et adaptative sur les approches centralisées puisque celles- ci peuvent être implémentées en tant que scénarios de coopération particuliers. Une implémentation de l’approche MDX2 (Sticklen 88) est en cours pour une estimation quantitative de l’apport de notre système.
La notion, d’agentpivot,introduite dans notre système sera employée dans les prochaines versions pour limiter les interactions visualisées entre agents à celles qui ont permis d’aboutir à un diagnostic effectif. En effet, actuellement, la sélection des interactions pertinentes est effectuée de façon manuelle. A plus long terme, nous envisageons d’étendre notre système à un environnement pour l’exploration de stratégies de coopération et pour l’étude de la pertinence de M.R. en fonction du contexte afin d’introduire dans le système des capacités d’apprentissage par l’expérience. Les agents auraient à mémoriser le contexte dans lequel une méthode a été pertinente pour ensuite, soit tenter de retrouver un contexte propice à une méthode, soit à l’inverse n’utiliser que les méthodes que l’agent juge ("de mémoire") pertinentes dans le contexte actuel.
Références
(Chittaro & al. 89) L. Chittaro, C. Costantini, &
al. Diagnosis Based on Cooperation of Multiple Knowledge Sources. 9th Interna- tional Workshop on Expert Systems and their Applications, Avignon, France, 1989 (Dutta & al. 06) P. S. Dutta, N. R. Jennings & L.
Moreau, Adaptive distributed resource al- location and diagnostics using cooperat- ive information sharing strategies, AA- MAS’06, Hakodate, Japan, pp.826-833, 2006
(Gasser 91) L. Gasser. Plurality: Why DAI sys- tems work and why they don't. Invited talk. Third European Workshop on Model- ling Autonomous Agents and Multi-A- gents Worlds, Kaiserslautern, Germany, 1991
(Jiaying & al. 04) J. Shen and X. Zhang and V.
Lesser, Degree of Local Cooperation and its Implication on Global Utility, In AAMAS’04, pp. 546-553, 2004
(Lesser & al. 04), V. Lesser and K. Decker and T. Wagner and N. Carver and A. Garvey &
al., Evolution of the GPGP/TAEMS Do- main-Independent Coordination Frame- work, AAMAS’04, pp. 87-143, Kluwer Academic Publishers, 2004
(Newell, 82) A. Newell, The knowledge level, A.I. 18(1) :87-127, 1982.
(Rissland & Skalak 89), E.L. Rissland and D.B.
Skalak. Combiningng Case-Based and Rule-Based Reasoning: A Heuristic Ap- proach. Eleventh IJCAI, Vol. 1, Detroit Mi- chigan USA, 20-25 August 1989
(Sabah 89) G. Sabah. L'intelligence artificielle et le langage. Volume 2 : processus de compréhension. Édition Hermès 1989 (Steels 92) L. Steels, Knowledge Systems.
(Smith 88) R.G. Smith. The Contract Net Pro- tocol: High-Level Communication and Control in a Distributed Problem-Solver.
In: A.H. Bond and L. Gasser (Eds.), Readings in Distributed Artificial Intelli- gence, 1988
(Sticklen 88), J. Sticklen. MDX2 an integrated medical diagnostic system. Dissertation, The Ohio State University 1987
(Sycara 88) K. Sycara. Resolving Goal Conflicts via Negotiation. Proceedings of the AAAI’88, Volume I, pp. 245-274, 1988 (Tambe & al. 00) M. Tambe and D V. Pynadath
and C. Chauvat & A. Das and G.
Kaminka, Adaptive agent architectures for heterogeneous team members, ICMAS’2000
