REVIEWS
COOPÉRATION HOMME-MACHINE
ET EXPLICATION
par L. KARSENTY1 et P. BRÉZILLON2Texte paru dans la revue Le Travail Humain, tome 58(4), 289-310, 1995
SUMMARY
MAN-MACHINE COOPERATION AND EXPLANATION.
Recent studies have pointed out several limitations of expert systems regarding the actual users' needs. We believe that the main cause of these limitations corresponds to the passive and limited role assigned to the user in the processing of his/her problem. Analyzing these limitations has led to introduce the concept of human-computer cooperation at the same time in the focus of cognitive ergonomics and artificial intelligence. The purpose of this paper is to contribute to the definition of human-computer cooperation. In particular, we focus our discussion on the explanation needs required by a cooperative problem-solving process.
A first section argues about the need of cooperation between the system and the user. Our argument is based on a review of studies of human cooperative dialogues. This review leads us to say that a user must be seen as a competent agent. Facing a problem, a competent agent is able to evoke a set of elements to be taken into account in the solution. The system's responses are then understood by the user with respect to this set of elements. In doing so, the user is trying to appropriate the system's actions and results. Thus, we talk about a cooperative system as a system able to enhance this user's appropriation task. Because the effectiveness of this task relies on the understandability and the acceptability of the system's responses, explanation facilities become a requirement for cooperative systems.
A second section presents a review of the work on the generation of explanations. Basically, the system's explanations are based on a record of the rules fired during a problem-solving session. This record is called a reasoning trace. The reasoning trace has been augmented with support knowledge, in order to justify the rules of an expert system. We discuss the necessity of this kind of explanatory knowledge, with respect to some observations on human dialogues. In particular, we argue that trace-based explanations are not useful for users with a different competence than the system one's. In order to produce explanations satisfying different types of users, expert systems were provided with others’ abilities: rhetorical schemas, user modelling technics and context-based processing of the user's requests. A last discussion argues that the construction of explanations must be conceived as a cooperative process itself.
The third section concludes by discussing our approach to man-machine cooperation with respect to the one elaborated by others’ studies, especially those which focus on the issue of task allocation between men and machines.
Keywords: Cooperative aiding system, Man-machine communication, Explanation.
1 Le travail rapporté dans le texte a été en grande partie réalisé alors que l'auteur était membre du Laboratoire d'Ergonomie du CNAM, Paris. Adresse de contact : laurent.karsenty@laposte.net
I - INTRODUCTION
Des études récentes font apparaître différentes limites des systèmes experts (SE) vis-à-vis des besoins réels des utilisateurs, lorsqu'on envisage leur utilisation face à des problèmes complexes (Carr, 1992). Par problèmes complexes, nous entendons des problèmes pour lesquels il n'est pas possible de spécifier tous les états possibles du domaine de tâches, et des problèmes pour lesquels le nombre de solutions possibles n'est pas prévisible (ex. : diagnostic dans les systèmes complexes, conception, recherche d'information dans un espace documentaire vaste). Pour pallier ces limites, les concepts de coopération homme-machine (H-M) (Fischer, 1990, Clarke & Smyth, 1993, Soubie & Kacem, 1994), de systèmes cognitifs associés (Woods, Roth & Benett, 1990), ou de partenariat homme-machine (Cahour & Falzon, 1991) ont été proposés en Ergonomie Cognitive et en Intelligence Artificielle3.
L'objet de ce papier est d'apporter une contribution à la définition du concept de coopération H-M. Cette contribution repose sur une analyse des limites des SE, tentant d'adopter le point de vue de l'utilisateur. Plus exactement, nous nous sommes appuyés sur des résultats d'interviews d'utilisateurs, et plus largement sur des résultats d'études portant sur la coopération inter-humaine (H-H) dans des situations de résolution de problème, pour dégager une réflexion critique sur la relation actuelle entre un SE et son utilisateur. Soulignons que notre exploitation de l'analogie entre coopération H-H et coopération H-M ne repose pas tant sur la conviction que la coopération H doit être le modèle pour concevoir la coopération H-M, mais plutôt sur le fait que l'étude de la coopération H-H peut aider à comprendre et dépasser les problèmes d'utilisation avec les systèmes experts existants. En particulier, elle permet d'identifier et éventuellement de remettre en question des présupposés implicites concernant l'utilisateur, fondant certains choix de conception.
L'utilisateur que nous considérons est caractérisé par deux traits : (i) il possède une certaine compétence dans son domaine lui permettant de traiter seul un éventail de problèmes, (ii) il n'a pas nécessairement la connaissance du fonctionnement du SE censé l'aider. Ce deuxième trait a une implication forte sur la coopération H-M. Il signifie en effet que l'utilisateur et le SE ne vont pas toujours utiliser les mêmes connaissances, ni les mêmes modes de raisonnement pour résoudre un problème. Ce type d'asymétrie peut rendre difficile la compréhension et l'acceptation des réponses du système, et entraver du même coup la
3 Face aux limites des systèmes experts, une autre réaction a consisté à introduire le paradigme des "systèmes à base de connaissances" (SBC). En reprenant les termes de V. Prince (1991), on peut définir le SBC comme "un 'produit', dont la proximité avec une source humaine n'est en aucun cas une raison de validité, mais qui doit appuyer certaines activités humaines présentant un caractère cognitif." (p. 26) Le paradigme des SBC ne repose pas sur l'émergence d'une technologie différente de celle des systèmes experts, mais plutôt sur un recul délibéré des prétentions liées à ce type de système (cf. Visetti, 1991). Ce changement de dénomination, associé à des positions théoriques différentes, n'a cependant pas encore été intégré par la plupart des concepteurs ou responsables de projets de conception de système d'aide. C'est la raison pour laquelle dans notre texte nous conserverons le terme de "système expert".
coopération entre l'homme et la machine. Les travaux visant à doter les systèmes d’une capacité à générer des explications tentent de dépasser cette difficulté.
Tout en défendant la nécessité d’une coopération H-M, nous montrerons que l'explication en est une condition nécessaire. Un ensemble de travaux ayant tenté d'améliorer les capacités explicatives d'un système expert seront alors présentés, suivis d'une analyse critique des choix de conception développés dans ce cadre. En conclusion, l'approche de la coopération H-M défendue dans ce texte sera discutée par rapport à celle développée dans d'autres travaux, centrés sur la question de la répartition des tâches entre l'homme et le système.
II - POURQUOI ENVISAGER UNE COOPERATION HOMME-MACHINE ? II.1. L'utilisateur et le système dans le paradigme des systèmes experts
Dans le paradigme des systèmes experts, la machine a le contrôle total des échanges avec l'utilisateur. Le rôle accordé à l'humain dans la conception de ces systèmes est celui d'être "les yeux et les mains " de la machine. Un scénario classique de relations entre un système expert et un utilisateur est composé des étapes suivantes : l'utilisateur débute une session en spécifiant une requête et en fournissant un ensemble de données censées décrire le problème à traiter ; le système expert traite les données disponibles et propose une solution ; l'utilisateur, d'une part fournit des données manquantes, et, d'autre part, peut demander des explications4 ; l'utilisateur accepte alors la solution du système expert ou la rejette.
La recherche d'une solution est donc basée sur une relation entre un fournisseur de données (l'utilisateur) et un résolveur de problème (le système). L'acceptation d'une solution, elle, est laissée à la seule appréciation de l'utilisateur.
II.2 Les besoins des utilisateurs face à des problèmes complexes
Dans la mesure où l'utilisateur fait appel à un SE pour résoudre certains problèmes particuliers, l'utilisateur est assimilé, le plus souvent implicitement, à un "novice". Par "novice", nous entendons un utilisateur incapable d'envisager une solution à son problème. C'est cette conception qui justifie en grande partie l'idée d'une "assistance par la réponse", termes empruntés à P. Falzon (1989). Or, plusieurs études de dialogues d'aide, sur lesquelles nous reviendrons ci-dessous, et notre propre expérience dans des projets de conception de SE, nous amènent à considérer l'utilisateur comme un utilisateur compétent.
4 Si un système expert peut effectivement expliciter son raisonnement, il faut toutefois souligner le peu d'utilité de cette explicitation pour l'utilisateur dans la majorité des implantations. Ce point est développé dans la section 3.
L'objet de cette section est non seulement de cerner plus précisément la notion d'utilisateur compétent, mais dans le même temps de souligner les types de besoins liés à cette compétence.
II.2.A. Les types d'assistance nécessaire à un utilisateur compétent
Plusieurs études montrent qu'un agent compétent ne reste pas "passif" dans la détection d'un problème. Ainsi, une étude de dialogues dans la conception de réseaux, entre un concepteur expérimenté et d'autres moins expérimentés, indique que ces derniers proposent souvent des éléments de solution auxquels l'expert réagit par une évaluation (Darses, Falzon & Robert, 1993, voir aussi Pollack, Hirschberg & Webber, 1982, et Maïs & Giboin, 1989, qui mettent l'accent sur cette capacité à générer des solutions partielles, même face à un problème dépassant son cadre de compétence). De plus, Darses et al. observent que l'expert ne se contente pas de répondre strictement à la requête de l'autre concepteur, il évalue comment ce dernier peut intégrer sa réponse. Plus précisément, on peut observer : (i) qu'un développement de la solution, ou des énoncés préventifs de l'expert peuvent suivre une évaluation positive ; (ii) qu'une justification, souvent accompagnée de propositions alternatives, suit toujours une évaluation négative (ou critique).
On peut relier ces résultats à d'autres, extraits de l'analyse des besoins d'agents compétents dans des tâches de diagnostic (Woods & Hollnagel, 1987). Ces auteurs avancent que de bonnes interactions consultatives aident à (i) bien formuler le problème, (ii) générer des plans, (iii) déterminer la bonne question à poser, (iv) chercher et évaluer les réponses possibles. Ainsi, une aide effective à des agents compétents doit permettre de répondre à des questions du type : Que se passerait-il si X ? Que produit X ? Comment empêcher X ? Quelles sont les pré-conditions (ou exigences) et post-conditions pour X (pour X donné, quelles sont les conséquences) ? Comment X interagit-il avec Y ? (Woods et al., 1990, voir aussi Kidd, 1985).
Toutes ces études conduisent à la conclusion que tout en reconnaissant son incapacité à résoudre un problème, l'agent/utilisateur compétent garde un rôle de résolveur de problème. L'incapacité à résoudre un problème est donc plus une incapacité à statuer sur une solution ou à développer complètement une solution qu'une incapacité totale à envisager des solutions. Le paradigme des systèmes experts, tel qu'il est décrit en 1., ne prend absolument pas en compte cette caractéristique de l'utilisateur.
II.2.B. Le type d'interaction nécessaire à la résolution d'un problème complexe
Les besoins des utilisateurs compétents incluent la nécessité d'une autre forme d'interaction, grâce à laquelle l'utilisateur pourrait participer activement dans la résolution du
problème. Ainsi, certains auteurs préfèrent voir les dialogues expert-utilisateur comme un processus de négociation plutôt que comme un simple dialogue de consultation (ex. : Pollack et al., 1982). Résoudre le problème de l'utilisateur revient non pas à trouver une solution, mais plutôt à trouver une solution mutuellement acceptable. Pollack et al. montrent pourquoi le dialogue peut prendre la forme d'une négociation : souvent, les personnes demandant un avis "ont des pré-conceptions sur ce que la solution à leur problème implique ou sur les contraintes que la solution doit satisfaire" (p. 361). Etant donné une proposition de l'expert, le demandeur peut désirer comprendre pourquoi la solution proposée par l'expert est meilleure que celle qu'il attendait.
Les pré-conceptions du demandeur ne sont pas les seules raisons qui conduisent à concevoir la résolution collective d'un problème comme un processus de négociation. Cette vision se fonde aussi sur le fait que la compréhension mutuelle du problème, nécessaire à la génération d'une solution pertinente et mutuellement acceptable, n'est pas assurée par la seule description du problème donnée à l'initiation d'une session par l'utilisateur. Deux types d'observation conduisent à cette conclusion :
- L'utilisateur ne sait pas toujours poser la question la plus appropriée car il ne connaît pas toujours l'information dont il a besoin (Pollack, 1985, Belkin, 1988). Pollack note qu'un expert humain compense le manque de pertinence de la question d'un utilisateur en inférant ses plans ou structures de buts. Autrement dit, l'expert doit trouver quel est le problème avant de le résoudre. D'autres auteurs observent que définir le problème de l'utilisateur ne se limite pas à une activité d'inférence de plans de l'utilisateur, il faut aussi un dialogue où les agents "négocient" ensemble la demande de l'utilisateur (Gilbert, 1989). Ces remarques sont aussi valides pour la résolution de problèmes complexes (en conception, par exemple). On note que, dans de telles situations, les utilisateurs sont incapables de développer une spécification complète de ce qu'ils désirent. En conséquence, les spécifications doivent être construites de façon incrémentale (Visser, 1990).
- Différents techniciens, confrontés à une même défaillance, décrivent des symptômes différents. Cette observation est extraite d'une étude sur des interactions avec un système expert diagnostiquant les pannes d'un appareil électromécanique (Woods et al., 1990). L'analyse rapportée dans cette étude montre en outre que certaines de ces descriptions dévient de ce que l'ingénieur de la connaissance, donc la machine, aurait attendu. Ces divergences peuvent bloquer la machine. Pour pallier de tels blocages, certains utilisateurs préfèrent reprendre le processus de diagnostic depuis le début, voire abandonner la session.
Ces différentes études montrent donc que poser un problème à un expert, c'est tenter de le résoudre avec lui, et qu'une résolution collective d'un problème nécessite de revenir à certaines occasions sur la définition du problème à traiter.
L'étude de dialogues coopératifs H-H montrent que cette construction dynamique d'une compréhension partagée du problème repose sur deux phénomènes (Karsenty, 1994) : - l'apparition de conflits entre les propositions ou les jugements des différents agents ; - un processus explicatif, dont l'objectif immédiat est de faire comprendre la position
d'un agent (i.e., une action, un résultat, une évaluation), mais qui conduit plus globalement à construire un contexte de connaissances mutuellement acceptables permettant de supprimer le conflit. Cette construction du contexte passe par une explicitation des informations composant la représentation du problème de chaque agent. Le processus explicatif donne ainsi l'occasion aux agents de réaliser un ajustement réciproque de leur représentation du problème tout en continuant à le résoudre.
II.3. La double tâche de l'utilisateur : résoudre le problème et comprendre le système Le système et l'utilisateur peuvent avoir des niveaux d'expertise différents, dépendant notamment de leur expérience propre. De telles divergences peuvent impliquer des lignes de raisonnement différentes qui, à leur tour, impliqueront une suite de questions du système incohérentes aux yeux de l'utilisateur (Keravnou & Washbrook, 1989). Dans ce cas, la charge de travail allouée à la recherche d'une solution peut être augmentée d'une charge de travail allouée à la compréhension des actions du système.
On peut rattacher ce problème à des observations concernant les difficultés à suivre les instructions proposées pour utiliser un photocopieur (Suchman, 1987). Suchman montre clairement que chaque instruction comprend toujours une part d'implicite lié non seulement au(x) but(s) que doit permettre d'atteindre l'application de l'instruction, mais aussi à la situation particulière dans laquelle se trouve l'utilisateur. Suivre les instructions nécessite par conséquent de reconstruire activement l'implicite sur la base d'une compréhension des buts à atteindre et des relations structurelles et fonctionnelles des objets mis en cause. Des incompréhensions peuvent donc résulter d'une distance entre le niveau d'implicite composant l'instruction du système, et l'implicite reconstruit par l'utilisateur.
Les utilisateurs ont besoin de comprendre les actions du système aussi bien au niveau de la procédure de résolution du problème que du résultat de son raisonnement. Teach et Shortliffe (1984) présentent une étude portant sur plus de deux cents médecins. L'étude met en évidence que les médecins ne souhaitent pas se trouver face à un système qui donnerait un avis d'une manière dogmatique, même si cet avis est précis et sûr. Les docteurs affirment que
sans pouvoir comprendre comment le système atteint ses conclusions, ils rejetteraient cet avis.
Les études citées ici peuvent conduire aux deux conclusions suivantes : (i) les raisonnements et les connaissances manipulées par la machine doivent être homogènes avec ceux de ses utilisateurs (ex. : Keravnou & Washbrook, 1989) ; cependant, quel que soit l'effort consacré à cette exigence d'homogénéité, on ne pourra jamais prévoir la diversité de ses utilisateurs, ce qui nous conduit au deuxième type de conclusion ; (ii) le raisonnement du système doit être “visible” à l’utilisateur ; ou, dit autrement, les utilisateurs doivent pouvoir obtenir des explications du raisonnement suivi par le système.
II.4. En conclusion …
La conception d’un système expert, envisagé comme outil d’aide, est basée sur une relation entre un utilisateur possédant le problème, et un système capable d’y apporter une solution. Les études rapportées dans cette partie montrent que, de toute évidence, un utilisateur faisant face à un problème qu’il ne sait pas immédiatement résoudre dispose toutefois d’éléments de solution, ou plus exactement d'éléments à prendre en compte dans la solution. Or, c’est dans le cadre délimité par ces éléments, jouant un rôle d’attentes, que l’utilisateur cherche à construire le sens des actions et des propositions du système. Ou, dit autrement, c'est dans ce cadre qui lui est propre que l'utilisateur cherche à s'approprier les actions et les résultats du système.
Lorsque nous parlons de coopération H-M, nous envisageons des systèmes experts, et plus généralement des systèmes à base de connaissances, facilitant ce processus d'appropriation mis en œuvre par l'utilisateur. L'outil d'aide coopératif doit être capable non pas de présenter une solution à l'utilisateur, mais de l'aider à construire sa solution. En d'autres termes, il ne doit pas construire une solution sur la seule base de ses connaissances ; il doit construire une solution dans le cadre des attentes de l'utilisateur, et ce en exploitant les connaissances dont il dispose.
Nous envisageons alors le besoin d'explication par rapport à cette nécessité pour l'utilisateur de s'approprier les réponses du SE : l'utilisateur a besoin d'explications sur le fonctionnement du SE lorsqu'il rencontre des difficultés pour réaliser cette appropriation.
La réalisation d’un système d’aide coopératif doit par conséquent intégrer une exigence en termes de possibilités d’explication requises par l’utilisateur. La partie suivante est consacrée à un certain nombre d’études qui ont tenté de concrétiser cette exigence.
III - EXPLICATION ET INTERACTION HOMME-MACHINE
En guise d'introduction à l'état de l'art sur la question des explications, on décrit brièvement le développement des travaux qui ont porté sur le premier système expert, MYCIN5. Outre l'intérêt historique de cette introduction, le récit de ces travaux permet de dégager un principe essentiel pour aborder la spécification de capacités explicatives : les besoins en explication dépendent du type d'utilisateur et du type d'utilisation du système. III.1. Finalité de l'interaction et besoins en explication : l'exemple de MYCIN
Dès 1973, date de la parution du premier article sur MYCIN (Shortliffe et al., 1973), Shortliffe avait ajouté une commande RULE pour aider à la mise au point (debugging). Cette commande demandait à MYCIN de présenter en LISP la règle actuellement activée. On s'aperçut alors que si cette présentation pouvait se faire en anglais, elle fournirait une justification de la question posée à l'utilisateur, et ainsi serait utile au médecin. On a ainsi traduit le LISP en anglais "naturel".
Une seconde étape dans le développement de Mycin résulte du travail de Randy Davis. Celui-ci modifia la commande RULE avec une commande POURQUOI et implémenta un historique du raisonnement (history tree) qui permettait à l'utilisateur d'examiner toute la chaîne de raisonnement de bas en haut en posant la question POURQUOI plusieurs fois. Il développa aussi une commande COMMENT qui permettait à l'utilisateur de descendre les différentes branches de l'arbre de raisonnement (Shortliffe et al., 1975). Il faut noter qu'à cette époque, le besoin en explication était ressenti comme nécessaire non seulement pour les concepteurs du système--experts du domaine ou ingénieurs de la connaissance--pour qui l'explication devenait une aide à l'activité de debugging, mais aussi pour les utilisateurs finaux, pour qui l'explication était un élément de visibilité qui facilitait la compréhension, et favorisait l'acceptation des suggestions du système expert.
Une troisième étape du développement de Mycin découle des analyses portant sur les explications inadéquates que générait MYCIN. Ces explications étaient jugées inadéquates si elles ne satisfaisaient pas l'utilisateur qui les demandait. Deux problèmes importants ont été identifiés :
1. Le premier problème reposait sur le manque de connaissances dites de "soutien" (support knowledge) qui justifiaient pourquoi telle action dictée par une règle de production était induite par telles prémisses incluses dans la règle. Ce manque n'était pas perceptible tant que l'on considérait que l'utilisateur était l'un des concepteurs du système ; celui-ci attendait essentiellement de la capacité explicative qu'elle lui 5 Le lecteur intéressé pourra consulter l'ouvrage de Buchanan & Shortliffe (1984) pour le détail de ces développements.
rappelle le contenu des règles. Face à des utilisateurs novices, ou dans des situations de formation, les besoins en explication se révélaient différents. Les travaux qui ont traité ce problème (notamment Clancey, 1983) ont développé l'idée que les connaissances de l'expert avaient une dimension implicite qui manquait au novice pour pouvoir les comprendre ou les acquérir.
2. Le deuxième problème reposait sur l'incapacité de MYCIN d'une part à prendre en compte le contexte dans lequel était posée la question de l'utilisateur, et d'autre part à interpréter correctement l'intention de l'utilisateur posant la question. Ces problèmes ont conduit à relier la problématique Explication à une autre problématique de l'IA, la compréhension du Langage Naturel. Elle a introduit la nécessité d'implémenter une mémoire du dialogue avec l'utilisateur, et des procédures permettant au système d'adapter ses réponses en fonction de ce contexte (cf. Buchanan & Shortliffe, 1984) A la même époque, les responsables du projet MYCIN se sont intéressés au travail de Clancey sur la modélisation d'un étudiant dans le cadre du système tutoriel GUIDON. La question était de savoir comment la modélisation des connaissances de l’utilisateur pourrait être utilisée pour guider la génération d'explications. Le travail de J. Wallis s'est centré sur ce problème, et a conduit au développement d'un système prototype portant sur des chaînes de raisonnement causal (Wallis & Shortliffe, 1984). Ce système associait une valeur de complexité à chaque règle et à chaque concept, et une valeur d'importance à chaque concept. L'utilisateur spécifiait son niveau d'expertise (de 1 à 10) et le niveau de détail souhaité dans l'explication (de 1 à 10). Le système pouvait ainsi adapter la génération de l'explication en prenant en compte l'ensemble de ces facteurs. Par exemple, si le niveau d'expertise était bas, les concepts trop complexes n'étaient pas présentés, sauf s'ils avaient une valeur d'importance très élevée.
En conclusion, on constate que ces développements reflètent un élargissement des fonctions de l'explication dans MYCIN. Shortliffe voulait aider les concepteurs dans leur tâche de debugging en implémentant la commande RULE. Puis, en envisageant MYCIN face aux utilisateurs finaux, on s'est aperçu que l'explication pouvait remplir des fonctions liées à la compréhension et à l'acceptation. Enfin, en envisageant MYCIN comme outil de formation, donc utilisé par des élèves, de nouveaux besoins en explication surgissaient. Ce rapide historique montre ainsi le fait que les besoins en explication, s'ils dépendent bien sûr du domaine de tâches couvert par le SE (on ne recensera pas les mêmes besoins en explications face à un diagnostic, et face à une solution dans un problème de conception), sont en outre liés de manière intrinsèque au type d'utilisateur à qui est destiné le système, en particulier ses buts d'utilisation.
III.2. Les types de besoins en explication III.2.A La trace du raisonnement
De façon générale, la plupart des tentatives initiales pour fournir des explications à l'utilisateur sont parties de ce qui était déjà disponible dans le système expert. L'un des éléments qui a ainsi été utilisé est la trace du raisonnement du système. Cette trace est constituée de l'enchaînement des règles déclenchées par le système pour résoudre un problème donné.
Une trace du raisonnement permet de répondre à deux types de questions : (i) POURQUOI?, le système remonte la chaîne des prémisses dans la trace du raisonnement à partir de l'action interrogée, (ii) COMMENT?, le système descend la chaîne des actions et des résultats auxquels elles ont mené jusqu'à l'action interrogée. On présente ci-dessous un exemple d'interaction avec MYCIN pour ces deux questions :
• POURQUOI ?
Système : (1) Quel est l'âge du patient ?
Utilisateur : (2) Pourquoi ? (i.e., pourquoi est-ce important de connaître l'âge du patient pour déterminer une prescription ?)
Système : (3) Pour déterminer si on peut prescrire de la tétracycline
Si le patient a moins de 8 ans, Alors on ne peut pas prescrire de la tétracycline • COMMENT ?
Système : (4) L'identité la plus vraisemblable d'organisme-1 est PSEUDOMONAS Utilisateur : (5) Comment ? (i.e. comment avez-vous décidé que l'identité la plus vraisemblable
d'organisme-1 était PSEUDOMONAS)
Système : (6) J'ai utilisé REGLE163 pour conclure que l'identité d'organisme-1 était PSEUDOMONAS. Ceci a donné un facteur de certitude cumulé de 0.651. La dernière question posée avant que la conclusion soit tirée était 26.
Notons que la trace de raisonnement peut présenter des informations incompréhensibles (voir la réponse (6) qui introduit l'information "REGLE163"). Pour pallier ce défaut, on a introduit des connaissances terminologiques permettant de répondre à une question de type "QUOI?" (ex. : Paris, 1991).
La compréhension du raisonnement nécessite en outre dans certains cas de comprendre pourquoi une alternative n'a pas été considérée par le système. Certains travaux ont ainsi été consacrés à doter un système expert de la capacité à répondre à des questions du type POURQUOI-PAS ? (ex. : Safar, 1990).
III.2.B. Les connaissances implicites dans le raisonnement de l'expert
Les informations qui composent la trace du raisonnement représentent les règles de raisonnement de l'expert. Celles-ci sont suffisantes pour résoudre un problème, mais s'avèrent souvent insuffisantes pour expliquer les actions et conclusions du système. Par exemple, face
au message (3) dans l'extrait présenté ci-dessus ("Si le patient a moins de 8 ans, Alors on ne peut pas prescrire de la tétracycline"), l'utilisateur peut rester insatisfait s'il ne sait pas pourquoi on ne peut pas prescrire de la tétracycline à un patient de moins de 8 ans. En fait, les règles de raisonnement reposent sur des justifications qui doivent être explicitées face à un utilisateur novice du domaine (Clancey, 1983, Swartout, 1983, Kassel, 1990). On a ainsi parlé de "connaissances compilées" pour caractériser les connaissances de l'expert : les pas intermédiaires dans le raisonnement ont été supprimés pour rendre l'application des règles plus efficace.
L'analyse approfondie des justifications des règles de l'expert, dans le cadre du diagnostic médical, a montré qu'elles étaient liées à différents types de connaissances (Clancey, 1983) : règles d'identification d'un concept basées sur les propriétés de la classe; connaissances causales (par exemple, modèle causal du fonctionnement d'un organisme humain); connaissances du sens commun ("si le patient est un homme, alors il ne peut pas être enceinte") ; et connaissances du domaine, liant des hypothèses sur la base de principes du domaine ("si un médicament a été administré par voie orale et est peu absorbé dans le GI tract, alors le médicament n'a pas été administré de façon adéquate").
La nécessité de ces connaissances pour les utilisateurs novices a donc introduit de nouvelles exigences, notamment au niveau de l’acquisition des connaissances. Cette phase ne doit plus seulement permettre d’acquérir l’ensemble des règles qui permettent d’associer un problème particulier du domaine à une solution particulière, mais aussi un ensemble de connaissances qui expliquent par exemple pourquoi telles prémisses sont associées à telles conclusions, ou pourquoi telles règles sont appliquées dans tel ordre (Dieng, Giboin, Tourtier et Corby, 1992).
III.2.C. Discussion …
Deux types de besoins en explication se dégagent des travaux qui viennent d’être rapportés. Soulignons qu’ils sont tous deux orientés-système, puisque basés sur la trace du raisonnement du système. On a en outre vu que le second type de besoins devait être envisagé face à des utilisateurs apprenants (rappelons que les travaux de Clancey à cette époque étaient essentiellement dédiés à l’utilisation de systèmes experts dans un but de formation).
La question qui se pose est de savoir si ces besoins correspondent effectivement à ceux des utilisateurs que nous envisageons, à savoir des utilisateurs compétents. En réalité, pour répondre à cette question, il est nécessaire d’introduire une nouvelle distinction entre les utilisateurs compétents, dans laquelle un premier type correspondrait aux utilisateurs partageant la même compétence que le système, et un second type correspondrait aux utilisateurs ne partageant pas la même compétence avec le système.
En se basant sur une analyse de dialogues H-H (Karsenty, 1994), dont l’objet était l’analyse des besoins en explication, on peut alors avancer que les explications basées sur la trace du raisonnement expert semblent répondre uniquement, et en partie seulement, aux besoins du premier type d’utilisateur. On a en effet mis en évidence les faits suivants : • Dans l'analyse de dialogues de validation réunissant un concepteur de base de données
et des futurs utilisateurs, on a pu montrer qu'aucune des explications de la solution proposées par le concepteur ne portait sur sa compétence propre, à savoir la formalisation des informations du domaine sous forme d'un schéma conceptuel des données. Les explications identifiées concernaient plutôt la signification des éléments composant la solution, leur lien avec les objectifs des utilisateurs, leurs conséquences au niveau de l'activité des utilisateurs, et les procédures d'utilisation de la future base de données. Bref, ces explications traduisent le fait que la solution du concepteur, pour être validée par les utilisateurs, devait être comprise et acceptée de leur point de vue. • Au cours de la même étude, nous avions observé des dialogues entre concepteurs cette
fois. Ces dialogues ont permis de reconnaître les mêmes types d'explications que dans les dialogues concepteur-utilisateurs, mais ont surtout fait apparaître des explications nouvelles, directement liées à la compréhension de la formalisation des données proposée par l'un des concepteurs. Des questions telles que "Pourquoi as-tu structuré cette information en entité et non en association ?" ou "Est-ce que tu ne pouvais pas remonter cette propriété dans l'entité générique ?", qui sont directement rattachables à des règles de formalisation connues des concepteurs de base de données, ont ainsi pu être identifiées.
Ces résultats permettent donc de douter de l'intérêt des capacités explicatives des SE centrées sur la trace du raisonnement, surtout si l'utilisateur ne possède pas la même compétence que le système. Un ensemble de travaux ont alors tenté de résoudre ce problème, en poursuivant un même objectif : la production d'explications pouvant satisfaire différents types d'utilisateurs.
III.3. La génération d’explications satisfaisantes pour l’utilisateur
Clancey (1983) a souligné un problème de détermination du "bon" niveau de détail de l’explication, concernant notamment l'explication des règles causales : il n'y a en effet pas de limite aux détails qui peuvent être inclus dans la justification. On peut toujours, après une justification X, se demander pourquoi X. Il concluait alors en disant que pour expliquer une règle, on a besoin de prendre en compte le degré attendu de compréhension par l'interlocuteur, ainsi que ses connaissances déjà acquises.
Plus généralement, la prise en compte de l'utilisateur dans la génération d'une explication a conduit à mettre l'accent sur trois aspects essentiels :
1. Si l'explication comprend plusieurs contenus, il y a nécessité de les structurer en un texte cohérent et pertinent par rapport au but explicatif.
2. L'explication doit être adaptée aux connaissances déjà acquises par l'utilisateur et à ses buts.
3. L'explication doit être construite interactivement.
Cette section est consacrée aux études ayant traité les deux derniers objectifs. Le premier objectif relève principalement d'études linguistiques. Celles-ci ont conduit à définir (i) des relations rhétoriques entre les contenus explicatifs (ex. : Weiner, 1980 , Mann & Thompson, 1987), ou (ii) des schémas explicatifs, décrivant un agencement de contenus explicatifs pertinent par rapport à un but donné (ex. : McKeown, 1985, Paris, 1988, Cawsey, 1993). La gestion de ces relations rhétoriques ou de ces schémas explicatifs permet actuellement à un système explicatif de produire des explications de plusieurs phrases agencées sous forme d'un texte cohérent.
Des explications adaptées à l'interlocuteur
L’étude de l’adaptation des explications à l’interlocuteur soulève deux questions :
• Qu’est-ce qui doit être adapté dans une explication ? Nous allons voir que deux dimensions de l’explication sont concernées par cette question : le type de contenu explicatif, et le niveau de détail.
• Quels indices sur l’interlocuteur sont utilisés pour réaliser l’adaptation ? L'adaptation du type de contenu explicatif
Un exemple représentatif de cette adaptation est le système TAILOR qui a pris en compte les résultats d'une étude linguistique (Paris, 1988). Cette étude portait sur des descriptions textuelles d'objets complexes. Certaines de ces descriptions appartenaient à des ouvrages destinés à une population d'expert (par exemple, des manuels techniques), d'autres à des ouvrages destinés à une population de novices dans la matière (par exemple, des encyclopédies juniors). L'étude comparative de ces descriptions a conduit à la conclusion suivante : pour les novices, les descriptions sont principalement axées sur le processus mécanique, tandis que pour les experts, elles présentent essentiellement les composants de l'objet et leurs propriétés.
L'adaptation du contenu explicatif peut être envisagée encore plus précisément. On peut ainsi décrire un concept avec ses propriétés et ses composants, ou grâce à une analogie, ou encore avec un exemple. Moore et Swartout (1991) ont implémenté un système qui choisit
entre ces différents types d'explication suivant le niveau d'expertise de l'utilisateur et suivant le contenu des échanges antérieurs.
L'adaptation du niveau de détail de l'explication
On a déjà évoqué ce type d'adaptation dans le récit historique du développement de MYCIN. Wallis et Shortliffe (1984) font varier le nombre de relations causales en fonction du niveau d'expertise de l'utilisateur, du taux d'information demandé par celui-ci, ainsi que d'une mesure de la complexité et de l'importance des concepts représentés dans le système.
Le système XPLAIN (Swartout, 1983) adapte aussi ses réponses en faisant varier le nombre de pas du raisonnement inclus dans une explication. Cette adaptation est réalisée en fonction du niveau d'expertise de l'utilisateur. Pour cela, des marqueurs sont attachés à chaque pas du raisonnement, indiquant à quel type d'utilisateur tel pas peut être décrit.
Dans ces deux études, le SE adapte le niveau de détail des explications qu'il génère au niveau d'expertise de l'utilisateur. Nous avons montré récemment, à partir d'une analyse des explications dans les dialogues inter-humains, que le niveau de détail devait aussi varier en fonction des buts de l'utilisateur (Karsenty, 1994).
L'adaptation des explications aux connaissances et aux buts de l'interlocuteur
Pour adapter ses explications à l'utilisateur, le système doit construire une représentation de cet utilisateur. Cette représentation est couramment désignée par l'expression de "modèle de l'utilisateur" dans la littérature en Intelligence Artificielle (ex. : Cahour & Paris, 1991). En général, deux propriétés sont prises en compte par le système pour construire ce modèle :
• les connaissances déjà acquises par l'utilisateur • les buts de l'utilisateur
Ce mode d'adaptation nécessite de rassembler ces informations au cours d'une phase d'interaction avec le système. Il y a deux manières d'aborder l'adaptation des explications au niveau d'expertise de l'utilisateur.
1. L'adaptation basée sur un niveau d'expertise global. En général, dans ce cas, on demande à l'utilisateur de spécifier lui-même son niveau d'expertise. Le système utilise alors un modèle stéréotypique de l'utilisateur correspondant à ce niveau d'expertise (Rich, 1979).
2. L'adaptation basée sur un niveau d'expertise local, c'est à dire pour chaque information questionnée. La nécessité de cette approche est justifiée par le fait qu'un utilisateur peut rarement être considéré comme expert ou novice face à tous les objets du dialogue.
- Tous les concepts supposés être connus de l'utilisateur sont supprimés de l'explication construite par le système, (ex. : Weiner, 1980, McKeown, 1985). - Les concepts supposés être inconnus de l'utilisateur sont décrits avec plus de détails (McKeown, 1985, Paris, 1988, Cawsey, 1993).
- Les concepts supposés être inconnus de l'utilisateur sont rattachés à des concepts supposés connus (Kass & Finin, 1988), de préférence des concepts pertinents par rapport aux buts de l'utilisateur (Sarner & Carberry, 1993). Cette dernière exigence nécessite d'implémenter des réseaux structurés des connaissances du domaine ainsi qu'une bibliothèque de plans décrivant les actions du domaine et les plans pour les réaliser. Lorsque le système doit générer une définition d'un concept, l'intérêt des concepts hérités des réseaux de connaissances peut ainsi être évalué par rapport au plan d'action attribué à l'utilisateur. Par exemple, si l'utilisateur cherche un moyen pour soulager une indigestion, alors la levure chimique (qu'il a pu ingérer) devra être définie comme un type de bicarbonate de soude, car ce concept jouera un rôle dans la recherche d'une solution médicamenteuse.
Les travaux sur la génération d'explications basée sur un modèle de l'utilisateur doivent permettre de dépasser certaines limites associées à l'explication type trace du raisonnement. Elles traduisent en effet une tentative pour prendre en compte la façon dont l'utilisateur va tenter de s'approprier les réponses du système. Cependant, cette approche, qui repose sur une conception de "l'expliqueur isolé", présente un inconvénient majeur : elle suppose une parfaite connaissance de l'utilisateur , car dans le cas contraire, le système générerait des explications non adaptées. Or, les conditions d'accès aux connaissances et aux buts de l'utilisateur restent encore limitées.
Une autre conception de l'explication est ainsi née, en partie pour dépasser cette limite. L'aspect novateur de cette autre approche est que l'expliqueur n'est plus isolé dans sa tâche d'explication.
Des explications construites interactivement
Parfois, le destinataire d'une explication ne comprend pas l'explication apportée, ou a besoin d'un autre type d'explication, ou juge l'explication non pertinente. Dans de telles situations, une explication alternative doit être formulée. Mais tout en produisant cette explication alternative, l'expliqueur devra tenir compte des échanges antérieurs.
Pour permettre une telle interaction avec un système explicatif, Moore et Swartout (1991) ont développé une approche "réactive" de l'explication. Cette approche est basée sur le feedback de l'utilisateur, et sur la prise en compte de l'historique des échanges antérieurs. Ces auteurs ont vu dans cette approche une alternative nécessaire à l'utilisation d'un modèle de
l'utilisateur, celui-ci pouvant être incomplet ou comprendre des hypothèses incorrectes sur l'utilisateur.
D'autres auteurs ont prôné la nécessité de construire l'explication de façon interactive avec l'utilisateur (Goguen, Weiner & Linde, 1983 ; Gilbert, 1989) et ont implémenté des systèmes donnant un rôle réacteur à l'utilisateur dans la génération d'une explication (ex. : Lemaire & Safar, 1991, Cawsey, 1993). D'un point de vue informatique, cette possibilité d'interaction nécessite que le système développe un plan de l'explication, c'est à dire une structure de buts et de sous-buts. Le niveau le plus bas du plan correspond aux énoncés explicatifs. Ainsi, si l'utilisateur pose une question ou exprime une incompréhension après qu'une première explication ait été donnée, le système l'interprétera dans le contexte du plan développé. Ceci permet notamment de retrouver le but d'un énoncé qui ne satisfait pas l'utilisateur, et de déterminer une stratégie explicative alternative pour satisfaire le même but (voir aussi Moore et Paris, 1992).
Comme on l'a dit, l'approche réactive est en grande partie née du constat qu'un modèle de l'utilisateur pouvait difficilement assurer au système de produire des explications réellement adaptées (étant donné l'état de l'art actuel). Face au même constat, on peut cependant adopter une toute autre approche. Brézillon (1992) a ainsi implémenté un système qui laisse l'utilisateur construire lui-même l'explication qu'il recherche. Pour cela, le système permet à l'utilisateur de l'interrompre au cours d'un raisonnement, et présente alors la structure des connaissances du système relative au point d'arrêt.
III.4. Le besoin d'une coopération pour expliquer
La quasi-totalité des travaux qui viennent d'être cités ont en commun les trois caractéristiques suivantes :
• L' explication est donnée à la demande de l'utilisateur6 • Seul l'utilisateur a besoin d'explications
• Le système explique seul
Ces trois caractéristiques traduisent le fait que la tâche d'explication est conçue comme une tâche réactive et individuelle, attribuée au système. Il est alors frappant de voir la distance qui existe entre cette vision de l'explication et celle que nous livre l'observation des dialogues H-H. En particulier, ces dialogues révèlent la nécessité d'une réelle coopération de l'expliqueur et du demandeur d'explication pour construire l'explication qui satisfera celui-ci. Précisons de nouveau qu'en relevant ces caractéristiques de l'explication dans les dialogues inter-humains, nous ne cherchons pas à imposer le modèle de la communication H-H pour la 6 En réalité, on trouve quelques exceptions notables à cette règle dans la littérature sur le sujet. On peut notamment citer les travaux de McCoy (1988) sur la correction par le système des mauvaises conceptions (misconceptions) de l'utilisateur. Le système ROMPER qu'elle propose peut détecter une mauvaise conception derrière la question de l'utilisateur. Il prend alors l'initiative de le signaler et d'expliquer pourquoi la conception de l'utilisateur est erronée.
conception de l'interaction H-M. Plutôt, nous cherchons à comprendre pourquoi les humains ont recours à d'autres comportements que ceux permis dans l'interaction H-M, une telle réflexion créant un cadre pour discuter les choix de conception actuellement réalisés. III.4.A. Quand l'expliqueur anticipe les demandes d'explication: l'explication spontanée
L'analyse des explications dans un dialogue coopératif inter-humains, caractérisé par une asymétrie des compétences des participants, montre de façon flagrante que l'explication n'est pas réactive, mais pro-active : elle est donnée, dans la majorité des cas, spontanément, et non en réponse à une question. L'analyse de plusieurs dialogues de validation de base de données, dont il a déjà été fait mention, a par exemple montré que sur plus de deux cent éléments de solution7 décrits par un concepteur à différents groupes de futurs utilisateurs, 29% (donc près de soixante) étaient expliqués spontanément par le concepteur, et seulement 0,25% (donc 5) étaient expliqués suite à une question des utilisateurs. Autrement dit, sur l'ensemble des explications recensées dans ces dialogues, plus de 90% sont des explications spontanées.
D'autres auteurs ont relevé ce fait. Belkin (1988), analysant des dialogues entre une personne désirant utiliser un système de recherche de documents et un expert du système, a ainsi noté la forte proportion d'explications spontanées de la part de l'expert. Dans des dialogues de diagnostic enregistrés dans une station d'épuration des eaux usées, et réunissant un technicien et un ingénieur, Cahour et Darses (1993) observent que 80% des explications identifiées sont données spontanément.
De façon générale, on peut dire que les explications spontanées apparaissent dans trois situations (Draper, 1987) :
- lors de la soumission d'une information nouvelle ou conflictuelle par rapport aux connaissances des autres agents ;
- lors de la détection d'une mauvaise conception dans une question ou une assertion d'un autre agent ;
- lors de la détection d'un obstacle dans le plan d'un autre agent (voir à ce propos le travail d'Allen & Perrault, 1980).
Karsenty et Falzon (1992) ont interprété l'explication spontanée comme une anticipation des besoins en explication de l'interlocuteur. Cette capacité d'anticipation traduirait le fait qu'un agent soumettant une proposition tente de l'envisager dans le contexte des agents à qui est destinée la proposition. Plus encore, son importance semble montrer que le travail d'appropriation des propositions de l'un ne revient pas uniquement à l'autre ; l'appropriation apparaît comme un but commun, nécessitant une coopération des agents. 7 Dans le cadre de la conception de base de données, un élément de solution correspond à un élément du schéma conceptuel des données construit par le concepteur, donc à une donnée stockable, une entité regroupant plusieurs données, une association entre plusieurs entités, et les contraintes sur ces associations, aussi dénommées cardinalités.
Commenté [En+1]: Si on prévoit un système qui explique
spontanément, il faut prévoir une fonctionnalité pour que l'utilisateur puisse réguler cette activité : interruption du type "je connais déjà", interruption du type "ça ne m'intéresse pas".
III.4.B. Quand le demandeur d'explication aide l'expliqueur …
Même dans la conception interactive de l'explication, l'utilisateur n'est pas réellement acteur, tout juste "ré-acteur". Ses capacités d'intervention dans la construction d'une explication sont limitées et indirectes. Ceci est flagrant lorsqu'on observe des dialogues explicatifs H-H (Baker, 1992; Karsenty, 1994), dans lesquels on peut observer une série de comportements dénotant une tentative du demandeur d'explication pour aider l'expliqueur à formuler l'explication satisfaisante. Ces comportements sont notamment les suivants : • Reformulation de l'explication apportée et demande de confirmation à l'expliqueur.
L'exemple suivant, tiré d'un dialogue de conception entre un ingénieur (I) et un technicien (T), illustrera cette possibilité :
T1 Mais pourquoi tu veux mettre des pions ?
I1 Ben, parce que si tu as juste une frette, quand tu vas tirer dessus, tu risques d'avoir un glissement, puis ça va s'ouvrir, et puis ensuite ça va se coincer. Il faut les solidariser…
T2 D'accord. C'est pour lier les deux … (reformulation) I2 Voilà.
• Explication du besoin d'explication. L'intérêt est ainsi d'amener l'expliqueur à mieux cerner le problème d'incompréhension, et par voie de conséquence, à mieux y répondre. L'exemple suivant est extrait des dialogues de validation dont il était question précédemment, réunissant un concepteur de base de données (C) et des utilisateurs (U) :
C Pour chaque point de livraison, on stocke un "code BMM".
U Attendez, je ne comprends pas pourquoi ? On pourrait prendre l'adresse tout simplement (explication de la demande d'explication).
Soulignons que l'explication du besoin d'explication est soit donnée spontanément par le demandeur d'explication, soit demandée par l'expliqueur, comme dans l'exemple suivant extrait des mêmes dialogues :
U1 Pourquoi n'a-t-on pas la valeur du prix dans le catalogue ?
C1 Qu'est-ce que vous voulez dire ? (demande d'explication sur la demande d'explication) U2 Le prix des vêtements est reporté sur les catalogues. Pourquoi cela n'apparaît pas ici ?
• Enoncé d'une hypothèse d'explication avec la demande d'explication. L'exemple suivant est extrait d'un dialogue entre deux ingénieurs (I1 et I2) en conception mécanique, l'un découvrant une solution réalisée par l'autre à partir des plans de fabrication de celle-ci :
I1.1 La 37, c'est un pion de cisaillement aussi ?
I2.1 Non, c'est plutôt une indexation angulaire celui-là en fait.
I1.2 Pourquoi ? Pour éviter la rotation relative? (Hypothèse d'explication) I2.2 C'est plutôt pour indexer les plateaux supérieurs et inférieurs.
Ce dernier comportement est important à relever, car il contredit une autre hypothèse implicite dans les travaux sur la génération d'explication : de la même façon qu'on conçoit le plus souvent un novice comme un utilisateur ayant un problème mais incapable de construire
une solution, on conçoit le demandeur d'explication comme un utilisateur ayant un problème de compréhension mais incapable de construire l'explication avec lequel ce problème pourrait disparaître. Nous pensons à l'inverse que le demandeur d'explication peut éventuellement construire une explication, mais il a alors besoin d'une évaluation/confirmation de la part de son interlocuteur.
III.4.C. L’explication, une activité coopérative
L'objet du processus d'explication est l'appropriation par le demandeur d'explication d'une information ou d'une connaissance détenue par l'expliqueur. Comme on l'a montré, ce processus n'est pas seulement réactif, l'expliqueur peut anticiper les besoins d'explication de son interlocuteur. Il n'est pas non plus basé sur les seules actions de l'expliqueur : le demandeur d'explication aide celui-ci dans la recherche d'une explication satisfaisante.
L'analyse des dialogues inter-humains autorise donc une conception du processus d'explication comme une activité coopérative en soi (Karsenty & Brézillon, 1995). La raison essentielle qui exige cette coopération semble tenir au fait que des agents humains engagés dans une résolution collective d'un problème n'ont pas nécessairement les mêmes représentations de la situation. Or, lorsque l'un d'eux émet une proposition, celle-ci est comprise par les autres dans le contexte de ces représentations. Si les représentations de la situation ne sont pas partagées entre les agents humains, alors des incompréhensions sont toujours possibles. Pour les résoudre, il est très souvent nécessaire que l'expliqueur prenne conscience des représentations de ses partenaires. Il peut bien sûr tenter de les inférer, et répondre par rapport à la représentation qu'il s'en est construit (nous rejoignons ici l'approche de l'explication basée sur un modèle de l'utilisateur). Mais cette stratégie s'avère dans un certain nombre de cas insuffisante, comme le témoignent les extraits rapportés ci-dessus. Parce que les représentations sont par nature inobservables, seul son détenteur peut réellement les traduire en mots, et les rendre ainsi accessible à l'autre.
La question qui se pose maintenant est de savoir si la communication H-M peut négliger cette exigence de coopération pour satisfaire un utilisateur dans ses besoins en explication. La première section de ce texte a mis l'accent sur le fait que l'utilisateur d'un SE, même de compétence différente de celle du système, amenait avec lui un cadre d'attentes sur la solution, qui conditionnait sa compréhension et son acceptation des actions et des résultats du système. L'interaction H-M ne semble donc pas très différente de ce point de vue de l'interaction H-H. Pour nous, un système d'aide coopératif, vu comme un système facilitant l'appropriation de ses réponses par l'utilisateur, doit prendre en compte ce cadre d'attentes. Or parce qu'il s'agit de représentations mentales, il nous semble peu probable que cela soit atteignable sans l'aide de l'utilisateur.
IV - CONCLUSION
Ce papier défend une vision de la coopération H-M dans laquelle le système doit faciliter l'appropriation des réponses du système par l'utilisateur. L'outil d'aide coopératif ne doit pas seulement être un résolveur de problème. Il doit aider l'utilisateur à construire sa solution.
Pour cela, il doit être capable non seulement de se représenter le contexte cognitif de l'utilisateur, mais aussi de réagir intelligemment à ses requêtes - c'est à dire en tentant de les comprendre par rapport aux échanges antérieurs et au modèle qu'il s'est construit de cet utilisateur, et enfin de permettre à ce dernier de l'aider dans sa tâche d'explication.
Il est vrai que cette dernière exigence nécessite des capacités de gestion du dialogue et de traitement du langage naturel encore difficiles à mettre en œuvre. Des solutions intermédiaires peuvent toutefois être élaborées, basées notamment sur des langages plus formels que la langue naturelle (cf. Coombs & Alty, 1984, pour une tentative).
Notre vision de la coopération H-M met donc l'accent sur la communication entre l'homme et la machine. Cette position peut être distinguée d'un ensemble d'autres travaux sur la coopération H-M, focalisés essentiellement sur la question de la répartition des tâches entre l'utilisateur et le système (ex. : Millot, 1988, De Greef & Breuker, 1992, Krivine, Monclar et Delouis, 1994). Le problème traité dans ces travaux est plutôt de permettre au système de jouer plusieurs rôles différents, selon les besoins de l'utilisateur et les exigences de la situation. L'objectif est ainsi de réussir le meilleur couplage H-M pour traiter une situation donnée. Il est étonnant de constater que ces travaux n'accordent qu'une faible place au problème de la communication. Par exemple, dans la méthode KADS (De Greef & Breuker, 1992), la communication est réduite à des tâches de transfert exigées par les buts des agents impliqués dans la coopération. Toute notre réflexion vise à montrer justement que voir la communication comme un transfert d’information peut conduire à concevoir des systèmes incompréhensibles aux yeux des utilisateurs, pouvant conduire à un rejet. La communication des réponses du système doit être conçue comme une activité de co-construction du sens de ces réponses (pour reprendre l'expression de Trognon et Brassac, 1992), impliquant des informations qui dépassent les seules exigences de la tâche.
Il nous semble donc nécessaire de tenter d'intégrer ces deux types de travaux, pour aboutir à des outils d'aide qui pourront être qualifiés de coopératif.
BIBLIOGRAPHIE
Allen J.F. & Perrault C.R. (1980). Analyzing Intention in Utterances. Artificial Intelligence, 15, 143-178.
Baker M. (1992). Analysing rhetorical relations in collaborative problem-solving dialogues. Proc. of
NATO Workshop "Natural Dialogue and Interactive Student Modelling", Varenna, Italie, Oct.
16-19.
Belkin N.J. (1988). On the nature and function of explanation in intelligent information retrieval Proc.
of the 11th Conf. on Research and Development in Information Retrieval, Grenoble. 135-145.
Brézillon P. (1992). Building Explanation during Expert Computer Interaction. Proceedings of the
EWHCI'92, St-Petersburg, Russia, 4-8 August 1992.
Buchanan B.G. & Shortliffe E.H (Eds.). (1984). Rule-Based Expert Systems: The MYCIN Experiments
of the Stanford Heuristic Programming Project. Reading, MA : Addison-Wesley.
Cahour B. & Darses F. (1993). Cognitive Processing and Explanation Strategies in a Diagnosis Task. ISEE Deliverable D140.2, Esprit project 6013.
Cahour B. & Falzon P. (1991). Assistance à l'opérateur et modélisation de sa compétence. Intellectica,
12, 159-186.
Cahour B. & Paris C. (1991). Role and Use of User Models. Proceedings of the IJCAI-91 Workshop
on Agent Modelling for Intelligent Interaction, Sydney, Australia. August 1991.
Carr C. (1992). Performance Support Systems: A New Horizon for Expert Systems. AI Expert, May
1992. 44-49.
Cawsey A. (1993). Planning Interactive Explanations. International Journal of Man-Machine Studies,
38(2), 169-200.
Clancey W.J. (1983). The Epistemology of a Rule-Based Expert System - A Framework for Explanation. Artificial Intelligence, 20, 215-251.
Clarke A.A. & Smyth M.G.G. (1993). A operative computer based on the principles of human co-operation. International Journal of Man-Machine Studies, 38, 3-22
Coombs M. & Alty J. (1984). Expert systems: an alternative paradigm. International Journal of
Man-Machine Studies, 20, 21-43.
Darses F., Falzon P. & Robert J.M. (1993). Cooperating partners: investigating natural assistance. In: G. Salvendy & M.J. Smith (Eds.), Human-Computer Interaction: Software and Hardware
Interfaces (pp. 997-1002). Amsterdam: Elsevier.
De Greef H.P. & Breuker J.A. (1992). Analysing system-user cooperation in KADS. Knowledge
Acquisition, 4, 89-108.
Dieng R., Giboin A., Tourtier P.A. & Corby O. (1992). Knowledge-acquisition for explainable, multi-expert knowledge-based design systems. In: T. Wetter, K.A. Althoff, J. Boose, B. Gaines, M. Linster & Schmalhofer F. (Eds.), Current Developments in Knowledge Acquisition: EKAW-92. Berlin: Springer-Verlag.
Draper S.W. (1987). The Occasions for Explanation. Proceedings of the 3rd Alvey Explanation
Workshop, Guilford, September 1987, 199-207.
Falzon P. (1989) Analyser l'activité pour l'assister. Actes du XXVe Congrès de la SELF, Lyon, 4-6 Octobre.
Fischer G. (1990). Communication Requirements for Cooperative Problem Solving Systems.
Information Systems, 15(1), 21-36.
Gilbert N. (1989). Explanation and Dialogue. The Knowledge Engineering Review, 4(3), 235-247. Goguen J.A., Weiner J.L. & Linde C. (1983). Reasoning and natural explanation. International
Journal of Man-Machine Studies, 19, 521-559.
Karsenty L. (1994). L'explication d'une solution dans des dialogues de conception. Thèse de doctorat de l'Université de Paris VIII, St-Denis.
Karsenty L. & Falzon P. (1992). Spontaneous explanations in cooperative validation dialogues.
Proceedings of the ECAI-92 Workshop on Improving the use of knowledge-based systems with explanations. August 4, Vienne: Autriche.
Karsenty L. & Brézillon P. (1993). Actes de la journée “Explication et Coopération homme-machine:
Vers la co-construction d’explication”, CNAM, Paris, 28 Juin (disponible sous forme de rapport
de recherche n° 105, CNAM, Laboratoire d’Ergonomie).
Karsenty L. & Brézillon P. (1995). Cooperative problem solving and explanation. International
Journal of Expert Systems with Applications, 8(4), 445-462.
Kass R. & Finin T. (1988). The Need for User Models in Generating Expert Systems Explanations.
International Journal of Expert Systems, 1(4), 345-375.
Kassel G. (1990). L'apport des systèmes experts de seconde génération et l'explication du raisonnement. Revue d'Intelligence Artificielle, 4(2), 89-100.
Keravnou E.T. & Washbrook J. (1989). What is a deep expert system? An analysis of the architectural requirements of second-generation expert systems. The Knowledge Engineering Review, 4(3), 205-233.
Kidd A.L. (1985). What Do Users Ask? Some Thoughts on Diagnostic Advice. In: M. Merry (Ed.),
Expert Systems 85 (pp. 9-19). Cambridge: Cambridge University Press.
Krivine J.P., Monclar F.R. & Delouis I. (1994). Systèmes à base de connaissances coopératifs: Rôles et modes de coopération. In: B. Pavard (Ed.) Systèmes coopératifs : de la modélisation à la
conception (pp. 289-308). Toulouse: Octarès.
Lemaire B. & Safar B. (1991). Some necessary features for explanation planning architectures: study and proposal Proc. of the AAAI'91 Workshop on Explanation, Anaheim, USA, Juillet 1991. McCoy K.F. (1988). Reasoning on a Dynamically Highlighted user Model to Respond to
Misconceptions. Computational Linguistics, 14(3), 52-68.
McKeown K.R. (1985). Discourse Strategies for Generating Natural-Language Text. Artificial
Intelligence, 27, 1-41.
Maïs C. & Giboin A. (1989). Helping users achieve satisficing goals. In: M.J. Smith & G. Salvendy (Eds.), Work with Computers: Organizational, Management, Stress and Health Aspects (pp. 98-105). Amsterdam: Elsevier.
Mann W.C. & Thompson S.A. (1987). Rhetorical Structure Theory: A Theory of Text Organization. In: L. Polanyi (Ed.), The Structure of Discourse, Norwood, N.J.: Ablex.
Millot P. (1988). Supervision des procédés automatisés et ergonomie. Paris : Hermès.
Moore J.D. & Swartout W.R. (1991). A Reactive Approach to Explanation: Taking the User's Feedback into Account. In: C.L. Paris, W.R. Swartout et W.C. Mann (Eds.), Natural Language
Processing in Artificial Intelligence and Computational Linguistics. Kluwer.
Moore J.D. & Paris C.L. (1992). Exploiting User Feedback to Compensate for the Unreliability of User Models. User Modeling and User-Adapted Interaction, 2, 287-330.
Paris C.L. (1988). Tailoring object descriptions to a user's level of expertise. Computational
Linguistics, 14(3), 64-78.
Paris C.L. (1991). Generation and Explanation: Building an Explanation Facility for the Explainable Expert Systems Framework. In: C.L. Paris, W.R. Swartout et W.C. Mann (Eds.) Natural Language
Generation in Artificial Intelligence and Computational Linguistics. Kluwer, Boston.
Pollack M.E. (1985). Information Sought and Information Provided: An Empirical Study of User/Expert Dialogues. Proc. of CHI'85 San Francisco. 155-159.
Pollack M.E., Hirschberg J. & Webber B. (1982). User Participation In The Reasoning Processes of Expert Systems. Proc. of AAAI-82, National Conference on Artificial Intelligence. 358-361. Prince V. (1991). Expertise naturelle, expertise artificielle, vers quels paradigmes cognitifs ?
Intellectica, 12, 7-31.
Rich E. (1979). User modeling via stereotypes. Cognitive Science, 3, 329-354.
Safar, B. (1990). Répondre à des questions du type POURQUOI-PAS ? Revue d'Intelligence
Artificielle, 4(2), 101-112.
Sarner M.H. & Carberry S. (1993). Tailored Definitions in Task-Oriented Dialogues. User Modeling
and User-Adapted Interaction, 2(3), 181-210.
Shortliffe E.H., Axline S.G., Buchanan B.G., Merigan T.C. & Cohen S.N. (1973). An artificial intelligence program to advise physicians regarding antimicrobial therapy. Computers and
Biomedical Research, 6, 544-560.
Shortliffe E.H., Davis R., Axline S.G., Buchanan B.G., Green C.G. & Cohen S.N. (1975). Computer-based consultations in clinical therapeutics: Explanation and rule acquisition capabilities of the MYCIN system. Computers and Biomedical Research, 8, 303-320.
Soubie J.L. & Kacem A.H. (1994). Modèles de coopération homme/système intelligent. In: B. Pavard (Ed.), Systèmes coopératifs : de la modélisation à la conception (pp.73-90). Toulouse: Octarès. Suchman L. (1987). Plans and situated actions: The problem of human-machine communication.
Cambridge: Cambridge University Press.
Swartout W.R. (1983) XPLAIN: a System for Creating and Explaining Expert Consulting Programs.
Artificial Intelligence, 21(3), 285-325.
Teach R.L. & Shortliffe E.H. (1984). An Analysis of Physicians' Attitudes. In: B.G. Buchanan et E.H Shortliffe (Eds.), Rule-Based Expert Systems: The MYCIN Experiments of the Stanford Heuristic
