Int´ egrit´ e des ´ etats

Les changements d’´etat sont orchestr´es par l’assistant personnel, en fonction des informations qu’il re¸coit des autres modules de l’environnement. Avant de soumettre un changement d’´etat au processus d’apprentissage, il est n´ecessaire de v´erifier sa coh´erence. Par exemple, lorsque l’utilisateur entre dans le bureau, il ne faut pas seulement remplir le pr´edicat inOffice, mais ´egalement vider le

5.6 – Interactions avec l’environnement 119

pr´edicat absent car les deux ne peuvent pas avoir des valeurs non nulles dans un mˆeme ´etat. Ceci est effectu´e par l’agent d’ar en se basant plutˆot sur la valeur de l’estampille des pr´edicats afin d’ˆetre ind´ependant de l’assistant et de pouvoir v´erifier la coh´erence d’un ´etat `a tout moment. Les valeurs du pr´edicat dont l’estampille a la plus haute valeur (donc le pr´edicat le moins r´ecemment mis `a jour) sont effac´ees. En effet, ce pr´edicat est alors consid´er´e obsol`ete. Un autre exemple est le pr´edicat alarm qui ne garde sa valeur que pour un pas. Lorsqu’un rappel est ´emis, une action est imm´ediatement choisie et ex´ecut´ee, puis le rappel est effac´e. Cette action peut ˆetre de ne rien faire, mais une d´ecision est prise imm´ediatement.

Ce m´ecanisme est mod´elis´e sous forme d’un ensemble de r`egles sur les valeurs d’arguments de pr´edicats ou bien sur les estampilles. Ces r`egles sont enregistr´ees dans la base de donn´ees (d´ecrite section 4.4), dans les tables de la figure 5.4. Une r`egle est l’association d’une ou plusieurs parties gauches (les conditions `

a remplir pour d´eclencher la r`egle) et d’une ou plusieurs parties droites (les actions `a ex´ecuter si toutes les conditions sont remplies). Les actions possibles sont (pour un argument) : effacer la valeur (la remplacer par <null>), mettre une valeur donn´ee ou bien mettre la valeur d’un autre argument (d’un autre pr´edicat). Les parties gauches et droites font r´ef´erence aux pr´edicats et `a leurs arguments, ´egalement enregistr´es dans la base.

Fig.5.4 – Une partie du sch´ema services de la base de donn´ees.

5.6.3 D´efinition d’une action

Notre ensemble d’actions est form´e de toutes les actions que nous pouvons ex´ecuter dans l’environnement. Il serait facile de rajouter des actions si nous d´eveloppons d’autres modules effecteurs. Ajouter une action en cours de route

ne perturbe pas le syst`eme. La nouvelle action s’int´egrera progressivement dans la q-table, sans que nous perdions le comportement appris jusque l`a.

Les actions ´el´ementaires dont nous disposons sont les suivantes :

– Transf´erer un rappel `a l’utilisateur. Nous disposons de plusieurs modalit´es pour cette action, la modalit´e choisie ´etant le param`etre de l’action. Le choix de la modalit´e s’appuie sur le contexte de l’utilisateur (y compris les ressources disponibles) et sur ses pr´ef´erences. Nous pouvons transf´erer le rappel par synth`ese vocale, en utilisant des haut-parleurs se trouvant dans la mˆeme pi`ece que l’utilisateur. Nous pouvons lui afficher un message ´ecrit sur un ´ecran qu’il serait susceptible de remarquer, y compris son appareil mobile (t´el´ephone ou pda). Enfin, nous pouvons simplement envoyer un mail `a l’utilisateur.

– Informer l’utilisateur d’un nouveau mail qu’il vient de recevoir. Nous dis-posons ´egalement de diff´erentes modalit´es : la synth`ese vocale ou bien un message ´ecrit.

– Verrouiller l’´ecran de l’utilisateur. – D´everrouiller l’´ecran de l’utilisateur.

– Mettre en pause la musique qui joue sur l’ordinateur de l’utilisateur. – Reprendre la lecture de la musique.

– Ne rien faire est ´egalement une action.

L’ensemble des actions de l’assistant est l’ensemble form´e par toutes les com-binaisons des actions possibles pour chacune des quatre parties suivantes : que faire `a propos

1. du rappel ; 2. du nouveau mail ; 3. de l’´ecran ; 4. de la musique.

Pour chacune de ces parties, il y a trois possibilit´es : faire quelque chose (par exemple transf´erer ou verrouiller), faire l’inverse (ne pas informer du mail, relancer la musique) ou bien ne rien faire.

Chaque action est d´efinie avec un attribut indiquant si cette action modifie ou non l’environnement. Par exemple, ✭✭ ne pas informer l’utilisateur d’un mail ✮✮ ne modifie pas l’´etat de l’environnement, ce qui n’est pas le cas de ✭✭ verrouiller l’´ecran ✮✮.

Ayant d´efini les actions, nous sommes en mesure de pr´esenter un extrait de la q-table : la figure5.5montre les q-valeurs de toutes les actions possibles pour l’´etat suivant :

alarm(minute =<*>, title =<*>, hour =<*>) ; xActivity(isActive =<true>, machine =<+>) ; inOffice(office =<+>, user =<+>) ;

absent(user =<*>) ;

hasUnreadMail(from =<*>, to =<*>, body =<*>, subject =<*>) ; entrance(isAlone =<*>, friendlyName =<*>, btAddress =<*>) ; exit(isAlone =<*> friendlyName =<*>, btAddress =<*>) ; task(taskName =<*>) ;

user(login =<+>) ;

userOffice(office =<+>, login =<+>) ; userMachine(login =<+>, machine =<+>) ;

5.6 – Interactions avec l’environnement 121

Fig. 5.5 – Un extrait de la q-table pour l’´etat ci-dessus, dans lequel l’utilisa-teur est simplement pr´esent dans son bureau. Nous pouvons constater que la meilleure action est de d´everrouiller l’´ecran et de jouer la musique.

Un extrait plus complet est fourni en annexeC.1.

5.6.4 Collecte des r´ecompenses

L’apprentissage par renforcement se base sur les r´ecompenses (ou renforce-ments) que l’utilisateur donne pour des actions que l’assistant d´ecide d’ex´ecu-ter. L’apprentissage est d’autant meilleur (rapide et pr´ecis) que les renforce-ments re¸cus sont fr´equents. Mais il est fort probable que l’utilisateur ne donne pas un renforcement pour chaque action, simplement parce qu’il sera trop oc-cup´e ou n’y pensera pas. D’apr`es [Richard et Yamada, 2007], les utilisateurs sont souvent r´efractaires `a fournir des informations pr´ecises ou une r´ecom-pense explicite `a un syst`eme d’apprentissage. De plus, comme le mettent en avant [Isbell et al., 2001], les r´ecompenses donn´ees par l’utilisateur peuvent sou-vent ˆetre incoh´erentes et se d´ecaler dans le temps :

✭✭ Individual users may be inconsistent in the rewards they provide (even when they implicitly have a fixed set of preferences), and their preferences may change over time (for example, due to becoming bored or irritated with an action). Even when their rewards are consistent, there can be great temporal variation in their reward pattern. ✮✮

[Thomaz et al., 2006] ont ´etudi´e sp´ecifiquement l’apprentissage par renfor-cement guid´e par des utilisateurs humains non experts. La conclusion de cette ´etude est que, pour les humains, l’entraˆınement est un processus `a double sens. Les humains ont tendance `a vouloir communiquer avec le syst`eme, `a voir l’en-traˆınement comme un enseignement, un partenariat. Les participants ont ´ega-lement montr´e une tendance `a consid´erer les renforcements plutˆot comme une guidance, une indication sur le comportement `a avoir dans le futur et non pas une appr´eciation de la derni`ere action effectu´ee.

En outre, les participants ont plus souvent donn´e des renforcements positifs que n´egatifs, ind´ependamment de la qualit´e de l’apprentissage. Dans le cadre o`u l’entraˆınement est per¸cu comme un enseignement, les humains ont tendance `

a vouloir motiver l’´el`eve qu’est le syst`eme par des r´ecompenses encourageantes. D’autre part, les participants attendaient une am´elioration imm´ediate suite `a un

renforcement n´egatif. Les algorithmes d’AR ne r´eagissant pas aussi rapidement, les personnes sentaient donc leur retours n´egatifs ignor´es.

Enfin, l’´etude a montr´e une adaptation des personnes au syst`eme. Au fur et `

a mesure de l’interaction, les participants ont construit un mod`ele mental du syst`eme et s’y sont adapt´es. Constatant les r´esultats de leur entraˆınement, ils ont augment´e la fr´equence de leurs renforcements.

Les conclusions de cette ´etude sont int´eressantes pour nous, mais, pour le moment, nous ne savons pas comment en tenir compte. Comment savoir si l’uti-lisateur donne un renforcement positif parce qu’il est satisfait du syst`eme, ou bien parce qu’il essaye de l’encourager ?

Il est possible de se demander si ces participants r´eagiraient de la mˆeme fa¸con en entraˆınant un syst`eme dans le cadre de leur vie quotidienne et `a long terme, comme c’est le cas pour notre assistant. Dans l’´etude men´ee par [Thomaz et al., 2006], les participants ´etaient l`a clairement pour une ex-p´erience et n’avaient qu’une seule tˆache en tˆete : entraˆıner le robot. Comme le soutiennent [Richard et Yamada, 2007], les utilisateurs d’un syst`eme au quoti-dien seront plus r´eticents et moins participatifs.

Par cons´equent, nous devons adapter notre syst`eme au fait que les renfor-cements donn´es seront rares et que, lorsqu’une r´ecompense est donn´ee, il se peut qu’elle ne concerne pas seulement la derni`ere action, mais plusieurs actions r´ecentes. Ce dernier point est pris en compte par l’algorithme d’apprentissage (le q-Learning avec traces d’´eligibilit´e, algorithme2) qui propage en arri`ere les renforcements.

Pour pallier le manque de renforcements, une id´ee est de recueillir des renfor-cements implicites, en plus des renforrenfor-cements explicitement donn´es par l’utilisa-teur. Ces r´ecompenses implicites proviendraient d’indices tels que la r´eaction de l’utilisateur quant `a la derni`ere action du syst`eme. Prenons par exemple l’action d’informer l’utilisateur d’un e-mail. Si la personne lit l’e-mail imm´ediatement, alors l’action ´etait probablement appropri´ee, et le renforcement implicite – posi-tif. Si, au contraire, l’utilisateur ignore le message, alors la r´ecompense d´eduite est n´egative. Cependant, ces r´ecompenses implicites devraient avoir une valeur num´erique limit´ee, car elles sont incertaines et ne devraient pas avoir un im-pact trop important et trop imm´ediat sur le comportement. Cette solution est pr´econis´ee par [Richard et Yamada, 2007] et [Maes, 1994].

Enfin, nous devons tenir compte de l’incoh´erence ´eventuelle des renforce-ments. En effet, l’utilisateur peut ˆetre influenc´e par des ´el´ements que nous ne pouvons pas percevoir lorsqu’il donne une r´ecompense (tels que son humeur ou l’influence d’une tierce personne, ou il peut simplement commettre une erreur). Nous g´erons cette possibilit´e en limitant l’influence d’un renforcement. Ceci sera expliqu´e en d´etail section 5.9.2, qui traite de l’apprentissage supervis´e du mo-d`ele de renforcement. En effet, ce momo-d`ele n’est pas totalement modifi´e par un renforcement contradictoire avec la connaissance actuelle du monde, mais ´evo-lue lentement. Si ce renforcement incoh´erent est une observation aberrante, il ne causera pas de probl`emes ; s’il est repr´esentatif d’un changement dans les pr´e-f´erences de l’utilisateur, il se r´ep´etera et le mod`ele s’adaptera peu `a peu. Il est d’ailleurs pr´ef´erable de ne pas modifier radicalement le comportement du sys-t`eme afin de ne pas perturber l’utilisateur (nous mentionnons ceci section5.2.1). Les renforcements explicites sont collect´es au travers d’une interface gra-phique montr´ee figure5.6. Cette interface est toujours `a disposition de l’utilisa-teur et affiche `a tout moment la derni`ere action ex´ecut´ee et l’´etat dans lequel

5.6 – Interactions avec l’environnement 123

cette action a ´et´e choisie. Le pr´edicat ayant ´et´e mis `a jour dans cet ´etat est en gras afin d’ˆetre facilement rep´erable. Dans l’exemple de la figure 5.6, l’uti-lisateur vient de passer absent et l’action qui a ´et´e choisie est de verrouiller l’´ecran et de mettre la musique en pause. Enfin, l’interface contient un curseur `

a positionner sur la valeur de renforcement d´esir´ee. Puis, le bouton Set permet de soumettre cette r´ecompense. L’avantage d’un tel curseur est que les valeurs num´eriques n’ont pas d’importance. Dans la version finale de cette interface, il serait mˆeme inutile de les afficher. L’important est que l’utilisateur donne une r´ecompense relative au minimum, maximum et milieu des valeurs possibles. La valeur exacte n’est pas importante pour l’utilisateur qui positionne le curseur de mani`ere intuitive. [Schiaffino et Amandi, 2004] ont ´etudi´e le comportement des utilisateurs face `a un syst`eme qui leur demande un retour d’information. Les auteurs ont conclu que les usagers sont, en g´en´eral, d’accord pour donner des retours simples qui ne leur demandent pas beaucoup d’effort, c’est-`a-dire une ´evaluation sur une ´echelle quantitative ou qualitative. Les utilisateurs sont d’autant plus enclins `a fournir ce retour s’ils savent que cela aide `a entraˆıner le syst`eme. Par contre leur motivation diminue dans le temps car ils estiment que le syst`eme doit avoir fini son apprentissage au bout d’un certain temps.

Remarque : L’interface de la figure 5.6 n’est pas la version d´efinitive, mais plutˆot un prototype. En effet, cette interface doit ˆetre toujours disponible mais d’une mani`ere non intrusive et non d´erangeante. Elle ne devrait pas ˆetre visible en permanence, mais plutˆot ˆetre facilement invoquable par l’utilisateur. De plus, bien que l’´etat soit compr´ehensible tel quel, il serait pr´ef´erable de trouver un moyen de l’afficher d’une mani`ere encore plus lisible. Par exemple, en masquant les pr´edicats vides ou encore en construisant une phrase `a partir des noms des pr´edicats, des arguments et de leurs valeurs.

5.6.5 Interactions en direct

Dans un syst`eme d’apprentissage par renforcement classique, seules les ac-tions de l’agent modifient l’´etat. Comme nous l’avons mentionn´e dans les sec-tions 4.5.1 et 5.6.2, l’assistant personnel re¸coit des ´ev´enements des capteurs de l’environnement et en d´eduit les modifications correspondantes de l’´etat de l’agent d’ar. Dans notre cas, des ´ev´enements ext´erieurs dans l’environne-ment provoquent ´egalel’environne-ment des changel’environne-ments d’´etat. Par exemple, les rappels de l’agenda de l’utilisateur sont d´etect´es par le service KdeEventsService et envoy´es, format´es en xml, `a l’assistant. Celui-ci modifie alors le pr´edicat alarm en remplissant ses arguments avec les valeurs re¸cues.

L’assistant personnel est plac´e dans un environnement modifi´e par des ´el´e-ments ext´erieurs sur lesquels il n’a aucun contrˆole. L’utilisateur fait partie de ces ´el´ements ext´erieurs qui agissent sur l’environnement. Ses all´ees et venues, les e-mails qu’il re¸coit, son activit´e courante, les rappels de son agenda, etc. sont autant d’´el´ements non d´eterministes provoquant des changements d’´etat.

Deux choix se pr´esentent alors. Nous pouvons consid´erer que l’utilisateur (et avec lui tous les ´ev´enements impr´evisibles) fait partie de l’environnement ou bien qu’il n’en fait pas partie. Il nous est impossible de connaˆıtre l’´etat interne de l’utilisateur. Si celui-ci fait partie de l’environnement, alors l’assis-tant personnel n’a pas compl`etement acc`es `a l’´etat de l’environnement. Nous ne pouvons alors pas mod´eliser le probl`eme sous la forme d’un pdm, nous nous trouvons dans le cas d’application des pdmpo (introduits section5.3). Comme

Fig.5.6 – L’interface de collecte des renforcements.

l’explique [Buffet, 2003], nous avons alors un probl`eme non-markovien station-naire. Le probl`eme sous-jacent est en r´ealit´e toujours markovien, mais l’assistant ne peut pas observer le pdm enti`erement, il n’a donc acc`es qu’`a un processus non-markovien. Le probl`eme est stationnaire car toute la non-stationnarit´e in-troduite par l’utilisateur est d´ej`a prise en compte dans la partie non-observable. L’environnement lui-mˆeme peut ˆetre consid´er´e comme stationnaire.

Dans le deuxi`eme cas, nous ne consid´erons pas l’utilisateur comme faisant partie de l’environnement, mais comme un ´el´ement ext´erieur qui perturbe l’envi-ronnement de mani`ere non d´eterministe. L’envil’envi-ronnement est d´esormais consti-tu´e de seuls ´el´ements que nous pouvons observer grˆace `a nos capacit´es de per-ception. ´Etant donn´e que nous sommes revenus `a un environnement enti`ere-ment observable, nous sommes revenus `a un pdm. L’utilisateur est alors pris en compte par le fait que l’environnement est non-stationnaire. Pour reprendre le terme de [Buffet, 2003], nous avons un probl`eme markovien non-stationnaire.

Nous avons choisi d’adopter la deuxi`eme mani`ere d’aborder le probl`eme, c’est-`a-dire en restant dans le cadre des pdm et en consid´erant que la loi d’´evo-lution de l’environnement n’est pas stable. Nous pouvons nous permettre ce choix `a cause d’une hypoth`ese tr`es importante : l’´evolution de notre environne-ment est lente. En effet, l’environneenvironne-ment est modifi´e par l’ajout ou le retrait de dispositifs, ou bien la modification du fonctionnement de ces dispositifs. L’hypo-th`ese que ceci n’arrive pas fr´equemment est r´ealiste. Les pr´ef´erences utilisateur changent ´egalement `a une faible vitesse. L’utilisateur ne change tr`es probable-ment pas d’avis tous les jours. L’apprentissage supervis´e va int´egrer dans le mod`ele, `a partir des exemples, les modifications de l’environnement. Mais il est envisageable de v´erifier en plus si le mod`ele s’applique enti`erement aux exemples

5.6 – Interactions avec l’environnement 125

r´ecents (observ´es dans les derniers x jours, semaines voire mois selon la vitesse d’´evolution de l’environnement), et de supprimer les parties du mod`ele qui n’ont plus ´et´e observ´ees.

Pour la raison de ce choix, les pr´edicats que nous avons s´electionn´es pour mod´eliser les ´etats (voir le tableau5.1) correspondent chacun `a un de nos cap-teurs (d´ecrits section 4.5.1). Ainsi seuls les ´el´ements per¸cus font partie de l’´etat, qui est alors enti`erement observable. Les autres ´el´ements ne sont pas mod´elis´es et sont trait´es comme des ´ev´enements impr´evisibles.

Notre probl`eme est similaire au probl`eme d’apprentissage par renforce-ment dans un cadre multi-agent. Les agents apprennent tous simultan´erenforce-ment `a agir dans un mˆeme environnement, sans se connaˆıtre mutuellement. Chaque agent per¸coit donc les autres agents comme des perturbations de l’environ-nement. Dans notre cas, il n’y a qu’un agent mais l’on peut voir l’utilisa-teur comme l’autre agent perturbant l’environnement. C’est le cadre ´etudi´e par [Buffet, 2003].

La non-stationnarit´e de l’environnement est souvent trait´ee en laissant une part d’adaptation dans le comportement de l’agent [Sutton, 1990]. Au lieu de progressivement faire d´ecroˆıtre le taux d’apprentissage α du q-Learning (algo-rithme1) jusqu’`a z´ero, on ne le d´ecroˆıt que jusqu’`a une limite non nulle, dont la valeur refl`ete la vitesse d’´evolution de l’environnement.

Cette non-stationnarit´e a plusieurs cons´equences. Elle implique que nous ne savons pas tout de l’environnement et de l’utilisateur, et qu’ils peuvent toujours ´evoluer. Nous avons d´ej`a abord´e ce point d`es la section 2.3. En effet, nous appliquerons un apprentissage `a vie, ce qui nous permet de prendre en compte les ´evolutions de l’environnement et de l’utilisateur. Pour l’environnement, il s’agit de l’apprentissage supervis´e des mod`eles dont il sera question section 5.9. De plus, l’environnement ´etant non d´eterministe, son mod`ele est, par cons´equent, probabiliste. Ce point sera abord´e section5.7.

D’apr`es [Sutton, 1990], l’avantage de dyna est justement de pouvoir ˆetre ap-pliqu´ee `a des environnements stochastiques. La planification peut ˆetre effectu´ee sur des mod`eles incomplets, changeants et probablement incorrects, construits par apprentissage. Pour pallier ces probl`emes, diff´erentes techniques peuvent ˆetre appliqu´ees [Sutton et Barto, 1998]. Notamment, il est possible de garder en m´emoire le nombre de pas effectu´es depuis la derni`ere fois qu’un exemple a ´et´e observ´e dans le monde r´eel. Dans la phase de planification, pour tester ces ac-tions obsol`etes, un renforcement ✭✭ bonus ✮✮ est donn´e aux exp´eriences simul´ees impliquant ces actions. En effet, un ´etat qui n’a pas ´et´e observ´e depuis long-temps peut avoir ´evolu´e dans le monde r´eel. Par cons´equent, il est n´ecessaire de le re-tester.

Si nous choisissons de consid´erer notre cas comme un probl`eme non-markovien stationnaire, le formalisme du pdm ne s’applique plus et il est n´ecessaire de mod´eliser le probl`eme sous la forme d’un pdmpo, voire d’un dec-pdmpo (un pdmpo d´ecentralis´e), dont il est question section 5.3.