MADIS (pour MultimediA Discourse System) est un système de gestion du dialogue développé dans le but de permettre aux utilisateurs de systèmes d'informations d'effectuer des requêtes simples et complexes reliées à un domaine de conception. L'échange entre le système et l'utilisateur peut faire usage d'animations, de textes, de graphiques, de son et (éventuellement) de mécanismes de reconnaissance de la parole. Le système adapte ses réponses à l'utilisateur en fonction d'un profil des connaissances de ce dernier/cette dernière, du contenu et de la séquence des échanges.

MADIS à été appliqué à la modélisation conceptuelle des données (Parent, 1997), à la conception d'interfaces 2D et plus récemment en collaboration avec Protogon Inc. de Montréal, à la conception des compartiments de navires de la marine. Les deux images présentées illustrent une partie de la base de connaissances créée par Protogon pour le Vérificateur automatique des contraintes de conception. Ce dernier est un module du projet HFEICADD de la marine, plus spécifiquement du "Système intelligent de conception assisté par ordinateur pour l'ingénierie des facteurs humains". Le Vérificateur automatique est une application de l'intelligence artificielle. Il a pour but de détecter les erreurs de conceptions relevées sur les plans des compartiments d'un navire. Les erreurs de conceptions relevées par le Vérificateur sont identifiées par des "glyphs" - une séquence de carrés rouges placée au-dessus des objets CAO problématiques. La "simulation 3D" à laquelle le second image fait référence est le modèle du compartiment généré par le système.

Une version Java de MADIS a été développée. En plus d'offrir l'avantage d'être portable d'une platforme à l'autre, cette version peut être exécutée à distance par des utilisateurs visitant un site web. Diverses applications d'aide intelligente peuvent être développées avec MADIS. Le système peut offrir à l'utilisateur une aide interactive en fonctionnant en parallèle avec un autre logiciel contenant l'information requise.

Énoncés

Les énoncés que le système peut adresser incluent requêtes et affirmations.

Requêtes

(1) Quelle est la définition de... ?; (2) Je désire de l'information ... ; (3) Est-ce que je devrais...? ; (4) Est-ce que je devrais...ou...?; (5) Comment puis-je décider de...? (6) Comment dois-je décider si ...?; (7) Comment dois-je décider si...ou... ? (8) À quel moment dois-je ...? et (9) Clarifier.

Affirmations

(1) Offre (d'information); (2) Affirmation; (3) Promesse; (4) Expression de contentement; (5) Expression de mécontentement; (6) Retrait d'une requête; (7) Rejet d'une offre; (8) Retrait d'une offre et (9) Rejet d'une requête.

Aperçu des facteurs de convivialité

Les propriétés énumérées ci-dessous, estimées importantes au succès de la communication humaine, sont présumées désirables d'un système de gestion du dialogue. Nos objectifs de recherche en étaient par conséquent dérivés. Les propriétés sont présentées selon un ordre décroissant d'importance.

1) Facilité d'apprentissage : L'utilisateur doit être en mesure d'apprendre à effectuer et recevoir une communication en quelques minutes. La procédure de communication devrait être transparente.

2) Accessibilité : le module de dialogue doit être accessible en tout temps.

3) Cohérence : le lien entre les idées et les sujets abordés au cours des échanges doit être clair. Spécifiquement, chaque énoncé d'un message doit faire référence à un sujet abordé dans un énoncé précédent. Chaque message doit avoir un lien logique avec la requête ou le commentaire de l'utilisateur.

4) Inférence des intentions : Les intentions sous-jacentes aux énoncés du système doivent être apparentes à l'utilisateur. Par exemple, lorsque le système présente un message à l'utilisateur, il/elle doit percevoir le lien entre sa question ou son besoin et la réponse du système.

5) Acceptation : Le système doit inférer les objectifs de l'utilisateur et adapter ses communications à ces derniers.

6) Information : Les messages du système doivent être adaptés aux connaissances de l'utilisateur (e.g. sa connaissance du domaine de conception). L'information présentée doit être complète.

7) Contexte : Le système doit tenir compte du contexte de la communication. Le contexte peut être inféré à partir de plusieurs échanges se rapportant au même sujet ou des liens entre plusieurs sujets de dialogue. Par exemple,si l'utilisateur demande au système de clarifier un message à deux reprises, le système peut lui demander de spécifier la source de son ambiguïté (e.g. l'intention du système, le vocabulaire ou la structure de phrase utilisée).

8) Interaction : Le système doit permettre les interruptions telles que l'annulation d'une requête.

9) Cohésion : Le système doit être en mesure d'établir un lien entre les différents éléments d'un texte (e.g. à l'aide de pronoms).

10) Vitesse : Le système doit répondre à l'utilisateur en moins de 2 secondes ou donner une indication du processus de traitement effectué.

11) Exactitude : Le système doit suivre les spécifications fonctionnelles dans 90% des cas.

12) Robustesse : Le système ne doit jamais rencontrer une impasse. Lorsqu'une difficulté surgit et fait obstacle à son fonctionnement, le système doit aviser l'utilisateur d'un besoin de clarification. Par, exemple, il peut demander à l'utilisateur de répéter sa requête.

Publications reliées

Brahan, J.W., Farley, B., Orchard, R.A. Parent, A. Phan, C.S. (1992). A designer's consultant, Proceedings of Expert Systems '92, the Twelfth Annual Technical Conference of the British Computer Society Specialist
Group on Expert Systems, Cambridge, U.K. December 15-17. NRC C3234.

Boulet, M.-M., Brahan, J.W., Cole, A.J., Duchastel, P., Hartley, J.R., Orchard, R.A., Parent, A., Pilkington, R., Phan, C.S. (1989). A design task advisor . Artificial Intelligence and Education. Proceedings of the International Conference on AI and Education, Amsterdam, The Netherlands. May 24-26, Published by D. Biermans, J. Breuker, and J. Dandberg. pp. 25-31. NRC30444.

Boulet, M.M., Pascot, D., Parent, A., Slobodrian, S. (1988). Acquisition de connaissances pour un système conseiller méthodologique, Informatique cognitive des organisations (ICO), novembre, NRC 31126

Parent, A. (1990). Collection and analysis of dialogue protocols for the question-answering facility of the entity-relationship modeling advisor. Rapport technique ERB-1032, Octobre. NRC 31827

Parent, A. (1991). Analysis of dialogue protocols. Proceedings of the 4th University of New Brunswick Artificial Intelligence Symposium, Fredericton, N.B., 19-21 September. NRC 33149.

Parent A. (1993). Un module question-réponse pour la conception, Intelligence Artificielle au Canada, hiver, NRC 35022.

Parent A. (1997). Analysing design-oriented dialogues: a case study in conceptual data modelling, Design Studies, Vol 18, pp. 43-66. NRC 40153.

Parent, A., Farley, B. (1994). Un module question-réponse pour la conception: définition, formalisation et implantation. Informatique cognitive des organisations (ICO), automne 1994, 6(3), pp. 59-67. NRC 38353.

Page d'accueil / rendez-vous / adresse / intervention / recherche / liens / commentaires

Tous droits réservés