Une action proposée par un agent contexte est contredite

Problématique Lorsqu’un agent contexte ayant proposé une action à l’agent contrôleur est sélectionné, l’agent contrôleur ordonne l’application de cette action sur l’effecteur associé. L’agent contrôleur pense que la réalisation de cette action dans la situation courante va satis- faire les utilisateurs. Cependant, l’agent contexte peut se tromper, soit parce qu’il a proposé une action dans la mauvaise situation, soit parce que cette action n’est plus appropriée à cette situation du fait des changements de préférences des utilisateurs. L’agent contrôleur va donc se retrouver incapable de décider de la bonne action à réaliser à cause des informations erronées envoyées par ses agents contexte, ce qui l’amènera à être contredit ; il est donc en situation d’incompétence.

Détection En l’absence de retour explicite des utilisateurs sur leur satisfaction, l’agent contrôleur doit être en mesure de détecter si l’action qu’il a réalisée est contredite ou pas par un utilisateur (les utilisateurs sont satisfaits ou pas). En effet, si une action du système est contredite par l’utilisateur, nous pouvons supposer que le système a eu tort de réaliser cette action, tandis que si elle ne l’est pas, alors le système a bien agi.

Soit une action a réalisée par un agent contexte ; l’agent contrôleur doit alors déterminer si l’action réalisée par un utilisateur suite à l’action a est une contradiction, ou une action

indépendante. Pour cela, nous définissons une action accomme une contradiction de l’action

a si elle vérifie les deux conditions suivantes :

1. L’action acest réalisée après a, sans qu’aucune autre action du système ou d’un utilisa-

teur n’ait été réalisée entre-temps sur ce même effecteur ;

2. La situation dans laquelle a a été réalisée est “similaire” à celle qui suit la réalisation de ac.

Une action est donc contredite si l’action “contradictoire” ramène l’environnement dans un état similaire à celui ayant précédé cette action. Dans un environnement statique, la se- conde condition aurait été simplifiée : la situation précédant l’action a serait identique à la

situation suivant l’action de contradiction ac. N’étant pas dans ce cas de figure, la réaction

des utilisateurs suite à l’action erronée réalisée par le système n’est pas instantanée. Même si ce laps de temps peut être relativement court, la dynamique de l’environnement ambiant fait que la situation aura pu évoluer entre-temps, et donc la situation suivant la réalisation

de la contradiction acne pourra pas être parfaitement identique à la situation dans laquelle

l’action a a été réalisée.

Un agent contrôleur n’a de notion de situation qu’au travers des propositions envoyées par les agents contexte. Aussi, de son point de vue, une situation ne se caractérise pas par l’état courant des données perçues, mais par l’ensemble des agents contexte valides et non

valides. Par conséquent, si deux situations S1 et S2 sont similaires, alors les mêmes agents

contexte seront valides dans chacune de ces situations.

Lorsqu’une action a1est réalisée, l’agent contrôleur enregistre la liste des agents contexte

valides dans cette situation (avant la réalisation de l’action a1). Par la suite, au moment

où l’action suivante a2 est réalisée, l’agent contrôleur compare la liste des agents contexte

deux listes sont identiques, l’agent contrôleur considère que la seconde action a2 était une

contradiction de la première action a1.

Résolution Le traitement réalisé pour résoudre cette SNC dépend du type de la contradic-

tion. Trois types de contradiction peuvent se présenter, selon que les actions a1et a2ont été

réalisées par le système ou par un utilisateur :

– l’action a2, réalisée par un utilisateur, contredit l’action a1réalisée par le système ; – l’action a2, réalisée par le système, contredit l’action a1réalisée par un utilisateur ; – l’action a2, réalisée par le système, contredit l’action a1réalisée aussi par le système. Pour les deux premiers types de contradictions, peu importe si c’est l’utilisateur qui contredit le système, ou le système qui contredit l’utilisateur. Dans les deux cas, nous consi- dérons que l’action de l’utilisateur prévaut toujours sur celle du système ; c’est donc l’agent contexte qui est contredit.

Nous présentons d’abord une première solution basée sur un mécanisme d’ajustement et permettant de résoudre cette SNC pour les deux premiers types de contradiction. Si cette so- lution s’avère inapplicable, une seconde solution basée sur un mécanisme de réorganisation est proposée. Enfin, nous présentons la méthode de résolution employée pour le troisième type de contradiction, où une action d’Amadeus contredit une de ses propres actions. En revanche, nous ne considérons pas le cas d’une contradiction d’un utilisateur par un uti- lisateur ; dans le pire des cas, cette situation entrainera la création de deux agents contexte qui mèneront le système à se contredire lui-même, et donc au cas de l’auto-contradiction du système.

Première solution La première solution consiste à faire en sorte que si la même situation S se présente, l’agent contexte contredit ne soit pas valide afin qu’il ne soumette pas à nou- veau sa proposition d’action dans une situation similaire. Il s’agit donc d’exclure la situation courante des plages de validité de l’agent contexte. Une situation étant représentée par l’en- semble des états de chaque variable perçue à un instant donné, il suffit d’exclure la valeur courante d’au moins une plage de validité pour que la situation soit elle-même exclue.

L’AVRT, qui est utilisé pour modéliser chaque plage de validité, propose un certain nombre de mécanismes énoncés plus en détail dans le chapitre 4.1. En particulier, il pro- pose un mécanisme d’exclusion de valeur qui, étant donnée une valeur v appartenant à la plage de valeur de l’AVRT, va tendre à exclure v. Cette exclusion n’est pas directe : selon la proximité de la valeur v avec une des bornes de la plage de valeur, l’AVRT peut réussir à l’exclure directement en modifiant une de ses bornes, ou bien uniquement tendre à l’ex- clure sans modifier suffisamment sa borne pour que v se retrouve en dehors de la plage de valeur. L’AVRT propose alors un second mécanisme qui, considérant cette même valeur v, sera capable de dire si l’AVRT est capable de l’exclure directement grâce à son mécanisme d’exclusion ou pas.

S’il existe au moins une plage de validité chez l’agent contexte pour laquelle le mécanisme d’exclusion de l’AVRT est applicable, cette solution est suffisante pour résoudre cette SNC. De plus, elle n’implique qu’un mécanisme de tuning, car elle n’entraîne de modifications que dans l’état interne de l’agent contexte. Dans la mesure où cette solution est applicable,

elle sera préférée à la seconde solution, cette-ci impliquant un mécanisme de réorganisation.

Seconde solution La seconde méthode de résolution consiste à modifier le gain estimé de l’agent contexte contredit. Lorsque l’agent contrôleur détecte une contradiction, il envoie un message à l’agent contexte contredit, dans lequel il lui précise la liste des agents contexte valides en même temps que lui.

Vu que son action s’est avérée inappropriée, l’agent contexte contredit considère qu’il au- rait mieux valu que l’agent contrôleur sélectionne un autre agent contexte à sa place. Cepen- dant, ni lui ni l’agent contrôleur n’est capable de déterminer a priori, parmi la liste des agents contexte qui étaient valides en même temps que lui, lequel aurait réellement était le plus ap- propriée à la situation. En revanche, l’agent contexte sait qu’il ne l’a pas été, aussi n’importe lequel de ces agents est susceptible de fournir une proposition d’action plus satisfaisante. C’est pourquoi il intègre l’ensemble de ces agents contexte à sa liste d’agents supérieurs. Plus de précisions sur le mécanisme d’auto-ordonnancement utilisé par les agents contexte sont présentés au chapitre 4.2.

Cet ajout entraîne la mise à jour automatique de sa valeur de gain estimé, qui est alors inférieure à celles de tous les agents contexte valides en même temps que lui lors de sa sélec- tion. Ainsi, si cet agent contexte se retrouve valide dans la même situation que celle où il a proposé son action contredite, il est assuré (sauf changement ultérieur dans les préférences des utilisateurs) qu’au moins un autre agent contexte proposera une action accompagnée d’un meilleur gain estimé que le sien, et sera donc sélectionné à sa place.

Auto contradiction Dans le cas d’une contradiction Amadeus/utilisateur, nous considérons que l’action de l’utilisateur est prépondérante, et donc que la contradiction concerne forcé- ment l’agent contexte. En revanche, dans le cas d’une auto-contradiction d’Amadeus, deux agents contexte sont concernés, sans information permettant de savoir lequel d’entre eux est à l’origine de la mauvaise proposition d’action. Plusieurs solutions sont alors envisa- geables pour déterminer l’agent contexte responsable de cette SNC : choisir au hasard un des agents, ou bien choisir l’agent le moins confiant, ou au contraire le plus confiant (la notion de confiance intégrée aux agents contexte sera introduite plus en détail en section 3.2.4.5), ou encore les considérer les deux comme responsables.

Toutes ces solutions présentent forcément un inconvénient. La dernière solution nous parait pourtant être la plus pertinente. En effet, nous considérons qu’il est plus important d’éviter que le système agisse mal (quitte à ce qu’il n’agisse pas du tout) plutôt que de faire en sorte qu’il agisse à tout prix (quitte à agir mal). En dégradant les deux agents contexte, nous empêchons l’agent contexte d’agir, mais nous empêchons aussi le bon agent contexte d’agir, cette dégradation de l’agent contexte correct étant toujours réparable par la suite. De plus, dans le cas extrême où les deux agents contexte ont tort, cette solution permet de ré- soudre en une fois les deux conflits.

La résolution de la SNC liée à l’auto-contradiction d’Amadeus est donc réalisée par les deux agents contexte et est identique à celle mise en oeuvre lorsque l’agent contexte est contre- dit par un utilisateur.