Généralisation aux procédures

L’utilité de l’introduction des variations d’une même action ne se limite pas aux actions primitives. Les procédures permettent de définir des opérations complexes⁶qui sont composées de plusieurs actions primitives assemblées par des constructions Golog. Il est tout à fait envisageable de définir plusieurs procédures effectuant des variantes de la même opération et de vouloir remplacer l’une par l’autre dans en programme en fonction du profil. De fait, nous définissons la notion de famille de procédures, similaires à celle de famille d’actions, et introduisons la transformation associée.

Définition 10. Le prédicat familyP est un prédicat défini par le concepteur de l’application. La

for-mule familyP(F ) est vrai si F est une famille de procédures, c’est-à-dire un ensemble de procédures effectuant la même opération.

De plus, une procédure ne peut faire partie que d’une seule famille de procédures :

∀P, F1, F2(family(F1) ∧ family(F2) ∧ P ∈ F1 =⇒ P 6∈ F2). (4.8)

Transformation 7 (T7). Si F = {P1, . . . , Pn} est une famille de procédures, ∀Pi∈ F Pi→ P1| . . . | Pn.

L’introduction de ce concept permet d’étendre la possibilité de transformation offerte par la famille d’actions à n’importe quel niveau du programme : la transformation n’est plus cantonnée au niveau le plus bas (les actions primitives). Il est possible de modéliser l’exemple précédent plus finement, en

4. Mais pas aux effets : une action ne peut que changer la valeur de fluents donnés, pas changer la valeur de vérité d’une formule quelconque. Un quantificateur existentiel dans les effets d’une action reviendrait à définir une action ayant des effets non-déterministes, ce qu’IndiGolog ne permet pas.

5. De même, pas dans les effets.

définissant openDoorWithKey, breakDoorOpen et lockPickDoor comme des procédures utilisant des actions plus précises plutôt que comme des actions primitives.

proc openDoorWithKey

take(key); move(key, lock); turn(key); putAway(key); push(door)

endProc

proc breakDoorOpen

take(axe); while ¬destroyed(door) do strike(door,axe)

endProc _(4.9)

4.3.4 Conclusion

Nous avons défini une nouvelle transformation permettant de remplacer une action par une autre effectuant la même opération. Cela offre la possibilité au concepteur d’application d’introduire des possibilités d’altération dans un programme qui n’en aurait pas assez.

Nous avons également étudié sous quelles conditions cette transformation offre la garantie de ne pas entraver le fonctionnement du programme et comment générer des familles d’actions offrant cette garantie.

Cette transformation s’applique aussi bien aux actions primitives du calcul des situations qu’aux procédures complexes écrites en Golog. Cela permet au concepteur d’application de remplacer n’im-porte quelle procédure d’un programme par une procédure similaire, mais différente, permettant ainsi d’introduire des possibilités de personnalisation ou de personnification n’importe où dans un programme.

En l’état, ces familles de procédures doivent être définies par le concepteur de l’application. Il serait possible d’étudier comment générer ces variantes d’une procédure : les différentes procédures obtenues par l’application de transformation sur une procédure pourraient être introduites comme des familles d’actions lors de la transformation du programme les contenant.

Chapitre 5

Affinités et critères de choix

Dans un programme Golog quelconque, il n’y a pas d’ordre parmi les exécutions possibles : toutes les exécutions valables sont égales, et l’interpréteur en choisit une arbitrairement. Il n’existe à la base aucun critère qui permette de distinguer deux exécutions ou de préférer une exécution à une autre. Pour permettre de faire cette distinction, nous introduisons la notion d’affinité d’une action, qui indique à quel point une action est désirable. L’affinité est définie relativement à un profil contenant des attributs. Nous introduisons également une comparaison de programme, basée sur l’affinité des actions, qui permet de déterminer si un programme est plus désirable qu’un autre programme vis-à-vis d’un profil (ou qu’une variante de programme est plus désirable que l’original).

Cette approche est inspirée de [BS11], qui met en relation des actions et des traits psychologiques dans le cadre d’agents BDI. Cette contribution a fait l’objet d’une communication [DPBS13].

5.1 Profils et attributs

Pour procéder à l’altération d’un programme, il est nécessaire de définir les facteurs de cette altération. La réponse dépend du type d’application, et surtout du type d’altération. Dans le cadre d’un système de recommandation d’articles de presse que l’on souhaite personnaliser, la person-nalisation consistera à prendre en compte le fait qu’un utilisateur n’aime pas le sport ou préfère lire des articles courts, alors que dans le cadre d’un robot personnifié évoluant dans un bâtiment¹, on voudra personnifier l’agent en prenant le compte le fait qu’il soit brutal, prudent ou roublard. Nous réunissons tous ces facteurs sous la notion d’attributs, définis comme des termes clos de la logique des prédicats. Le domaine des attributs dépend du domaine de l’application, et est défini par le concepteur de l’application.

Définition 11 (attribut). Soit un ensemble de symbolesΣ d’arité quelconque, défini par le concepteur d’application.

Un attribut est un terme clos deΣ. L’ensemble des attributs est noté A .

Intuitivement, un attribut est un terme auquel un agent associe une certaine valeur. Selon le domaine, cette valeur peut signifier «l’utilisateur avec lequel l’agent interagit aime ou n’aime pas cet attribut» ou encore «l’agent incarne ou n’incarne pas cet attribut». Les attributs correspondant

aux exemples précédents seront likesSubject(sport) (l’utilisateur aime les articles traitant de sport), shortArticles (l’utilisateur préfère les articles courts), brutal, cautious et outlaw (l’agent doit montrer une personnalité brutale, prudente ou roublarde). Les attributs sont liés aux actions (voir section suivante) et permettent de déterminer quelles actions sont préférables pour un agent donné.

Le programme est altéré en fonction de l’attitude de l’agent vis-à-vis d’un attribut et donc des actions qui y sont liées. Les attitudes d’un agent vis-à-vis d’un ensemble d’attributs sont regroupées dans un profil. En nous inspirant de [BS11], nous définissons cinq valeurs possibles pour un attribut donné :

hostile l’agent tient à éviter à tout prix ce qui est lié à cet attribut ; défavorable l’agent préfère éviter ce qui est lié à cet attribut ;

neutre l’agent n’a pas d’avis sur cet attribut, n’y est ni favorable ni défavorable ; favorable l’agent préfère ce qui est lié à cet attribut ;

inconditionnel l’agent veut à tout prix ce qui est lié à cet attribut.

On positionne ces valeurs selon deux axes :

— polarité : l’agent est soit favorable à l’attribut, soit défavorable ;

— intensité : l’attitude vis-à-vis d’un attribut peut-être une simple préférence, ou une contrainte absolue. Intensité Polarité neutre neutral hostile req− défavorable pref − favorable pref + inconditionnel req+

FIGURE5.1 – Les valeurs possibles du profil peuvent se répartir selon deux axes.

De fait, ces cinq positions sont respectivement représentées par les symboles suivants : req−, pref −, neutral, pref + et req+. Les deux positions extrêmes req− et req+ indiquent des avis forts qui peuvent aller au-delà de la rationalité, et nuire au bon fonctionnement de l’agent. De fait, on s’autorisera des transformations pouvant être destructrices en réponse à ces valeurs. Le concepteur d’application devra garder ceci en tête en définissant les profils.

Définition 12 (profil). Un profil p est une fonction de l’ensemble des attributsA vers l’ensemble {req−,pref −,neutral,pref +,req+}.

Le profil peut être fourni directement par le concepteur de l’application, ou calculé à partir d’une autre source. Dans le cas de la personnalisation, le profil de l’agent peut par exemple être calculé à partir d’un profil utilisateur recueilli précédemment sous la forme de couples clé-valeur.

La fonction de profil est définie en donnant sa valeur pour chacun des attributs existants. Un profil p dans un domaine ayant pour attributs a1et a2sera défini ainsi : p(a1) = pref +, p(a2) = req−. Cette formulation étant un peu longue, nous utiliserons l’abréviation suivante, avec le même sens : p = {a1: pref +, a2: req−}.

Cette classification des valeurs du profil selon deux axes est un choix que nous faisons. Ce choix offre la possibilité d’exprimer des contraintes plus fortes que la simple préférence dans le profil. Il serait possible de ne représenter ces valeurs que sur un axe, ce qui mènerait à un formalisme similaire offrant moins de possibilités pour le profil. De la même manière, nous avons choisi de l’utiliser que des valeurs discrètes pour simplifier les équations. Il serait tout à fait possible de choisir de représenter le profil par des valeurs continues (entre -1 et 1, par exemple), ce qui amènerait à un formalisme plus complexe, mais permettant plus de variation dans les profils.