Représentation des connaissances sémantiques dans le cadre du
Transcription
Représentation des connaissances sémantiques dans le cadre du
Faculté des sciences et techniques Université du Maine Master 2 MÉMOIRE présenté en vue d'obtenir le diplôme de MASTER SCIENCES ET TECHNOLOGIES Mention « Génie Informatique » Parcours Recherche CHM&IE DUFOUR Richard Représentation des connaissances sémantiques dans le cadre du Dialogue Homme-Machine Finalisé Laboratoire d’Informatique de l’Université du Maine (LIUM) Encadrants : LEHUEN Jérôme LEMEUNIER Thierry LUZZATI Daniel Maître de Conférences à l’Université du Maine Maître de Conférences à l’Université du Maine Professeur à l’Université du Maine Faculté des Sciences et Techniques Avenue Olivier Messiaen – 72085 LE MANS Cedex 9 Tel : 02 43 83 38 31 Fax : 02 43 83 38 68 Faculté des sciences et techniques Université du Maine Master 2 MÉMOIRE présenté en vue d'obtenir le diplôme de MASTER SCIENCES ET TECHNOLOGIES Mention « Génie Informatique » Parcours Recherche CHM&IE DUFOUR Richard Représentation des connaissances sémantiques dans le cadre du Dialogue Homme-Machine Finalisé Laboratoire d’Informatique de l’Université du Maine (LIUM) Résumé : Notre travail s’inscrit dans le domaine du Dialogue Homme-Machine Finalisé, et plus particulièrement sur les relations sémantiques pouvant exister entre les mots (concepts). Nous nous sommes alors intéressés aux phénomènes d’inter-compréhension au sein d’un dialogue, sur la façon dont les protagonistes arrivent à se comprendre et à inférer le sens de certains mots par rapport à leurs connaissances. Nous avons alors cherché à mettre en place une solution permettant à la machine de comprendre des concepts propres aux utilisateurs, et à en inférer le sens pour trouver des concepts proches faisant parti du lexique utilisé par la machine. Faculté des Sciences et Techniques Avenue Olivier Messiaen – 72085 LE MANS Cedex 9 Tel : 02 43 83 38 31 Fax : 02 43 83 38 68 Remerciements Je tiens tout d’abord à remercier Jérôme Lehuen et Thierry Lemeunier, Maîtres de Conférences à l’Université du Maine et co-encadrants de mon stage, pour m’avoir fait découvrir le domaine du dialogue homme-machine, et m’avoir aidé tout au long de ce stage. La disponibilité, les conseils ainsi que les aides qu’ils ont su m’apporter, m’ont permis de réaliser ce stage dans les meilleures conditions. Je tiens tout particulièrement à remercier Daniel Luzzati, Professeur à l’Université du Maine et dernier encadrant de mon stage, pour sa sagacité et son soutien. Ses remarques précieuses m’ont énormément apporté, et leur impact dépasse le cadre de ce stage. Merci d’avoir pris le temps de répondre à toutes mes questions. Je remercie Pierre Tchounikine, Professeur et Directeur du Laboratoire d’Informatique de l’Université du Maine, pour m’avoir accueilli au sein de son laboratoire. J’aimerais également remercier Pierre Beust, Maître de Conférences à l’Université de Caen, pour l’aide qu’il m’a apporté concernant le modèle Anadia et ses outils dérivés utilisés durant mon stage. Je n’oublie pas les autres stagiaires du Master Recherche, Elise Gendron, Vincent Jousse, et Romain Roussel, ainsi que l’Ingénieur d’Etudes, Gaël Salaün, qui ont contribué au bon déroulement de ce stage. Sommaire REMERCIEMENTS............................................................................................................... 4 SOMMAIRE.............................................................................................................................5 TABLE DES ILLUSTRATIONS............................................................................................ 7 INTRODUCTION....................................................................................................................9 1 CONTEXTE......................................................................................................................... 10 1.1 LE PROJET DIALOGUE HOMME-MACHINE FINALISÉ................................................................................................10 1.1.1 Définition et enjeux.............................................................................................................................. 10 1.1.2 Modèle théorique.................................................................................................................................. 11 1.1.3 L’analyseur TALENT............................................................................................................................ 12 1.2 OBJECTIFS........................................................................................................................................................ 12 1.2.1 Problématique...................................................................................................................................... 12 1.2.2 Objectifs poursuivis.............................................................................................................................. 15 1.3 MÉTHODOLOGIE SUIVIE...................................................................................................................................... 15 2 LES FONDEMENTS THÉORIQUES............................................................................... 18 2.1 UNE APPROCHE INTERPRÉTATIVE.......................................................................................................................... 18 2.2 L’INFLUENCE DU CO-TEXTE................................................................................................................................. 18 2.3 LA SÉMANTIQUE DIFFÉRENTIELLE......................................................................................................................... 19 2.4 LE MODÈLE ANADIA.......................................................................................................................................... 22 2.5 JUSTIFICATIONS DU MODÈLE ANADIA.................................................................................................................... 26 3 MODÉLISATION DE L’INTER-COMPRÉHENSION...................................................29 3.1 CORPUS DE DIALOGUES...................................................................................................................................... 29 3.1.1 Acquisition et choix d’un corpus.......................................................................................................... 29 3.1.2 Exemples extraits.................................................................................................................................. 30 3.2 LE TERRAIN COMMUN....................................................................................................................................... 31 3.3 CONSTRUCTION DES TABLES ANADIA.................................................................................................................... 33 3.3.1 Objectifs................................................................................................................................................33 3.3.2 Modélisation réalisée........................................................................................................................... 34 3.4 CALCUL DE PROXIMITÉ DES CONCEPTS.................................................................................................................. 38 3.4.1 Au niveau de la table............................................................................................................................ 38 3.4.2 Au niveau de la hiérarchie....................................................................................................................39 3.4.3 Au niveau du domaine.......................................................................................................................... 40 4 APPLICATION INFORMATIQUE................................................................................... 41 4.1 RÉALISATION DE L’APPLICATION...........................................................................................................................41 4.1.1 Outils utilisés........................................................................................................................................ 41 4.1.2 Structure des données........................................................................................................................... 41 4.2 TACTIQUES DIALOGIQUES.................................................................................................................................... 43 4.2.1 Définition de seuils............................................................................................................................... 44 4.2.2 Déroulement des tactiques dialogiques................................................................................................ 45 4.3 TESTS RÉALISÉS................................................................................................................................................ 47 4.3.1 Au niveau du domaine d’application.................................................................................................... 47 4.3.2 Dans des domaines différents............................................................................................................... 50 4.3.3 Complexité du calcul............................................................................................................................ 52 CONCLUSION ET PERSPECTIVES................................................................................. 53 BIBLIOGRAPHIE.................................................................................................................55 ANNEXE I : CODE XML DE LA HIÉRARCHIE DE TABLES ANADIA......................57 ANNEXE II : DÉFINITION DES SEUILS EN CLIPS...................................................... 59 5 6 Table des illustrations FIGURE 1MODÈLE THÉORIQUE EXISTANT [LEH 06]...............................................11 FIGURE 2EXEMPLE HIÉRARCHIE DE CONCEPTS [LEH 06]...................................12 FIGURE 3EXEMPLE TIRÉ DU CORPUS PIC [NIC 03] ET DE [BEU 98] ...................13 FIGURE 4PROBLÉMATIQUE ABORDÉE........................................................................14 FIGURE 5EXEMPLE LANGAGE COMMUN/JARGON TECHNIQUE.......................15 FIGURE 6AXES DE TRAVAIL ............................................................................................16 FIGURE 7MÉTHODOLOGIE DU PROJET...................................................................... 16 FIGURE 8LES SIÈGES DE POTIER.................................................................................. 20 FIGURE 9MODIFICATIONS APPORTÉES PAR BEUST............................................... 21 FIGURE 10EXEMPLE DE CARRÉ SÉMIOTIQUE......................................................... 22 FIGURE 11ARBRE DE GRILLES DE CATÉGORISATION [BEU 98]..........................23 FIGURE 12EXEMPLE D’ATTRIBUTS, DE REGISTRES ET DE TABLES..................24 FIGURE 13HIÉRARCHIE DE TABLES ET TOPIQUES ASSOCIÉES.......................... 24 FIGURE 14ACTUALISATION DE SÈMES [BEU 98].......................................................26 FIGURE 15EXEMPLE DE STRUCTURE DU SÉMÈME « BASSE SAISON ».............26 FIGURE 16EXEMPLE TABLE DES CONCEPTS TAXE/DROIT/TAUX......................27 FIGURE 17COMPARAISON CONCEPTS COMMUN/TECHNIQUE...........................31 FIGURE 18MODÉLISATION DE L’INTER-COMPRÉHENSION................................. 32 FIGURE 19EXPLICATION DE LA MODÉLISATION DES TABLES SELON LE MODÈLE ANADIA................................................................................................................ 34 FIGURE 20MODÉLISATION DE LA RÉSERVATION DANS UNE AGENCE DE VOYAGES............................................................................................................................... 35 FIGURE 21MODÉLISATION DU MONDE FANTASTIQUE.......................................... 37 FIGURE 22MODÉLISATION DU DOMAINE DE L’INFORMATIQUE........................37 FIGURE 23MODÉLISATION DU DOMAINE DE LA NUTRITION..............................37 FIGURE 24CALCUL AU NIVEAU DE LA TABLE........................................................... 39 FIGURE 25EXEMPLE CALCUL PROXIMITÉ CONCEPTS « AVION » ET « VOL »39 FIGURE 26CALCUL AU NIVEAU HIÉRARCHIQUE.................................................... 39 FIGURE 27EXEMPLE CALCUL PROXIMITÉ CONCEPTS « AVION » ET « PREMIÈRE CLASSE ».......................................................................................................40 FIGURE 28CALCUL AU NIVEAU DU DOMAINE...........................................................40 FIGURE 29MODÉLISATION DE LA STRUCTURE ANADIA....................................... 42 FIGURE 30SCHÉMA STRATÉGIE DE DÉCISION......................................................... 44 FIGURE 31DÉROULEMENT CHOIX CONCEPT UTILISATEUR/TÂCHE................45 7 FIGURE 32COMPLEXITÉ DE L’ALGORITHME DE CALCUL...................................52 8 Introduction La communication d’un homme avec une machine au moyen de la langue naturelle est encore aujourd’hui une ambition et une voie de recherche. En effet, l’idée d’un Dialogue entre l’Homme et la Machine a émergé dans les années 1960, sans réellement aboutir à un système comparable permettant un réel dialogue. La souplesse d’expression qu’offre la langue naturelle ne peut être que profitable à un système informatique. La problématique de la production d’une réponse par une machine dans le contexte du Dialogue Homme-Machine, qu’il soit oral ou écrit, ne se réduit pas à la simple reconnaissance d’une phrase émise par un humain et à la reconnaissance de mots. Il y a de nombreux facteurs et de nombreuses analyses qui entrent en jeu lors d’un dialogue. Ainsi dans [ROU 01] est émise l’idée que pour pouvoir répondre à une question lors d’un dialogue, il faut connaître le monde et les objets, prendre conscience des non-dits qui le compose avant de pouvoir réaliser une tâche donnée. La difficulté réside donc dans cette compréhension du langage naturel. En effet, la machine devra comprendre toutes les subtilités d’un dialogue, comme entre autres les sousentendus, le contexte ou encore le thème développé. Le Dialogue Homme-Machine apparaît ainsi comme un domaine important mais difficile à mettre en place, faisant intervenir l’informatique mais également des techniques d’intelligence artificielle ainsi que des théories et des modèles issus de la linguistique. Nous nous sommes intéressés dans ce travail à la compréhension des énoncés, à leur sémantique, qui s’intéresse à l’étude des signifiés. Le principal objectif est d’analyser des énoncés émis en langage naturel par un utilisateur vers une machine, de fournir une analyse permettant au système de « comprendre » ce qu’attend l’utilisateur, dans l’optique de réagir en conséquence au niveau d’une tâche à accomplir ou d’une réponse à fournir. Nous pensons ainsi qu’une analyse sémantique assez fine permettrait à un analyseur d’être plus réactif face aux problèmes inhérents au dialogue, et notamment les difficultés liées au jeu du sens avec les figures de style, comme l’expose [BAC 03]. Notre rapport se découpe en trois parties. Nous présenterons ainsi dans une première partie notre contexte de travail, la problématique et les objectifs que nous nous sommes fixés. Dans la seconde partie nous exposerons les idées de la sémantique différentielle et du modèle Anadia, en cherchant à évaluer son intérêt dans le cadre de notre travail. Nous verrons ensuite la façon dont nous avons utilisé le modèle Anadia, et montrerons son apport dans notre travail. Finalement, dans une dernière partie, nous présenterons l’application informatique réalisée, ainsi que les différents tests réalisés permettant de valider les concepts développés au cours de ce stage. Enfin, pour conclure ce rapport, nous chercherons à analyser le travail effectué, pour montrer son intérêt et les perspectives de recherche. 9 Chapitre 1 : Contexte 1 Contexte 1.1 Le projet Dialogue Homme-Machine Finalisé 1.1.1 Définition et enjeux Caelen et Nguyen, qui ont travaillé sur l’élaboration d’un modèle générique d’un système de dialogue homme-machine, se sont intéressés dans [CAE 03] à différents systèmes existants, et ont fourni une définition du dialogue homme-machine. Ainsi, ils exposent qu’un système de dialogue est un système informatique qui est capable d’interagir de manière plus naturelle avec l’homme pour accomplir des tâches précises, c'est-à-dire d’une façon qui semble naturelle à l’homme en langage naturel. L’idée est ici de se détacher du simple système vocal, fréquemment limité à la reconnaissance de mots clés dans des énoncés, pour arriver à un système capable de réellement comprendre des phrases émises en langage naturel par un être humain. Le projet DHMF1, initié au LIUM par l’équipe Langue et Dialogue, a pour objectif d’obtenir un composant dialogique suffisamment générique pour permettre son intégration dans diverses applications, que ce soit dans des applications de dialogue, ou bien encore dans des EIAH2. Le dialogue se déroule selon un contexte précis et selon une tâche finalisée à accomplir (elle peut être simple comme très complexe, avec un enchainement d’actions), initiée par l’utilisateur et que la machine doit satisfaire (par exemple commander un billet d’avion ou acheter une baguette). Dans un dialogue finalisé, la tâche peut être planifiée (nous savons quand elle s’achève) mais par contre le dialogue ne l’est pas, mais dépend de l’avancement de la tâche. Une fois les différentes tâches accomplies, le dialogue n’a plus lieu d’être. A l’inverse, une conversation spontanée peut être vue comme un dialogue ne portant pas sur une tâche précise mais plutôt sur des sujets variés et différents, sans réel objectif. Le projet DHMF se décompose en deux axes complémentaires : • Axe modélisation informatique, dont le but est de construire un modèle de dialogue homme-machine qui considère les « non-attendus » (incompréhensions, incohérences, incomplétudes, quiproquos, sousdialogues…) non pas comme des « erreurs » mais comme des phénomènes inhérents au processus dialogique. Cet axe s’appuie alors sur l’idée d’une modélisation « opportuniste » du dialogue, qui pense que le dialogue est une activité de résolution collaborative de problèmes où l’imprévu est moins un obstacle qu’une nouvelle occasion de dialoguer [LEH 06]3. • Axe modélisation linguistique, dont l’idée est de mener, en interaction avec l’axe informatique, des études linguistiques et pragmatiques à partir de corpus de dialogues authentiques (homme-homme et homme-machine). L’objectif est ici de parvenir à modéliser la langue en interaction à partir de données réelles, si possible obtenues dans le contexte des applications visées. Projet Dialogue Homme-Machine Finalisé. Environnement Informatique pour l’Apprentissage Humain, pouvant être défini comme un environnement informatique permettant à un être humain d’apprendre. 3 Ce modèle est issu de critiques énoncées par rapport à d’autres approches, comme par exemple l’approche structurelle ou encore l’approche rationnelle 1 2 10 Chapitre 1 : Contexte 1.1.2 Modèle théorique L’idée principale véhiculée dans ce modèle est que la morphosyntaxe et la sémantique sont indissociables pour donner du sens à un énoncé. Cette idée est issue de la théorie de Tesnière, dans [TES 59], qui pense que le structural n’a de raison d’être que dans la sémantique. Différentes idées ont été reprises et adaptées, à savoir de structures actancielles vus comme des cristallisations des relations entre concepts, ces derniers étant constitués à la fois d’éléments sémantiques et d’éléments morphosyntaxiques, représentant les formes d’usages langagières du concept. Partant du constat que le langage naturel est fondamentalement imprédictible, qu’il est difficile de formaliser de façon univoque ses unités, et qu’il existe de nombreuses disfluences (agrammaticalité, anacoluthes, interruptions, répétitions…), l’équipe Langue et Dialogue a constaté que les analyseurs existants n’arrivent pas à « comprendre » les énoncés émis par un utilisateur lors d’un dialogue. En effet, ces analyseurs sont souvent désarçonnés face à des formes non prédites par le modèle linguistique, des erreurs surviennent lorsque des formes agrammaticales ne sont pas gérées, et finalement des problèmes existent au niveau technique, à savoir l’explosion combinatoire pouvant être générées suite à des ambiguïtés. Devant ces limites, l’équipe Langue et Dialogue a proposé un nouveau modèle d’analyse des énoncés guidée par la sémantique. Dans [LEH 06], Lehuen énonce les principes fondateurs du modèle : • Il faut faire intervenir le fond (aspects sémantiques) avant ou en même temps que la forme (aspects syntaxiques). • La syntaxe n’est intéressante que si elle contribue à l’analyse sémantique. L’idée principale de ce modèle réside dans l’algorithme qui a été mis en place. Cet algorithme est fondé selon l’idée qu’il existe des : • correspondances entre des offres et des attentes de traits sémantiques, • correspondances entre l’énoncé et des motifs syntaxiques (issus d’un corpus), • heuristiques calculées sur la base de distances entre les offres et les attentes. Figure 1 Modèle théorique existant [LEH 06] Le modèle a pour objectif de relier les concepts entre eux (au moyen de ces offres et attentes) et de permettre ainsi de répondre en fonction des liaisons trouvées. 11 Chapitre 1 : Contexte Figure 2 Exemple hiérarchie de concepts [LEH 06] Ce sont ces principes fondateurs qui vont permettre de mettre en place l’analyseur TALENT, que nous allons maintenant présenter. 1.1.3 L’analyseur TALENT Suite à la définition des objectifs du projet DHMF et à une réflexion sur la mise en place d’un modèle du dialogue, a été mis en place l’analyseur TALENT 4. Cet analyseur est écrit en langage CLIPS5 et date de 2005. Il évolue de manière incrémentale au fur et à mesure des avancées théoriques. Il permet de vérifier les théories soulevées ainsi que les modèles conçus en les implémentant et permet à l’analyseur de progresser sur des idées viables. L’idée est de le rendre de plus en plus performant, et non d’essayer d’avoir directement un analyseur complet. Cet analyseur s’appuie sur le modèle théorique que nous avons introduit précédemment, soutenant l’idée d’un couplage fort entre la morphosyntaxe et la sémantique. L’analyseur, dans son fonctionnement, fait intervenir la double reconnaissance lors de sa phase analyse des énoncés : les concepts sont rattachés entre eux sémantiquement, et peuvent également être différenciés par rapport à leur syntaxe. Ainsi, il fait intervenir la sémantique le plus tôt possible, n’utilisant la morphosyntaxe que si elle permet de fournir une ou plusieurs propositions d’analyse. Nous faisons intervenir l’idée d’appariement des concepts entre eux, en fonction des offres et des demandes de chacun, comme vu précédemment. Notre travail s’inscrit dans cette lignée, nous avons travaillé sur les problèmes liés à la sémantique, en utilisant l’analyseur TALENT pour mettre en place nos théories. Intéressons nous maintenant aux différents objectifs que nous avions à réaliser. 1.2 Objectifs 1.2.1 Problématique Nous retenons l’idée d’une coadaptation du sens lors d’un dialogue, c'est-à-dire l’ambition de chacune des parties de se mettre au niveau de l’autre, d’essayer de comprendre les idées véhiculées et de répondre en fonction de nos connaissances. En effet, Lehuen dans Talent Analyse Les Enoncés Non-normés Très vite. CLIPS est un langage de conception de systèmes à base de connaissances, permettant de formaliser un domaine d’expertise avec des faits et des règles. 4 5 12 Chapitre 1 : Contexte [LEH 97] montre très clairement les limites des logiciels de traitement linguistique, qui se basent sur des représentations figées, trop rigides, et donc qui n’évoluent pas. Ainsi, nous constatons que c’est à l’utilisateur de s’adapter à la machine, ce qui bien entendu rend le dialogue beaucoup moins naturel, l’utilisation en devient beaucoup plus fastidieuse. Un dialogue peut alors être perçu comme une recherche constante d’intercompréhension entre les acteurs du dialogue. En effet, l’idée est, dans [LEH 06], qu’au fur et à mesure des échanges, un terrain commun est construit entre les deux parties. Cette interprétation commune dépend de nombreux facteurs, qui sont véhiculés par les deux parties : chacun possède par exemple la proximité culturelle et sociale des interlocuteurs, l’historique de leurs relations, le contexte de l’échange… En fin de compte, nous nous servons tous de nos connaissances et expériences personnelles pour essayer de comprendre les énoncés émis par une autre personne. Cependant elles diffèrent selon les personnes, d’où parfois la difficulté de compréhension entre deux personnes. Généralement, c’est avec le dialogue que ces ambiguïtés de sens disparaissent. Figure 3 Exemple tiré du corpus PIC [NIC 03]6 et de [BEU 98] Nous constatons ici d’une incompréhension sur le mot « poste », qui peut avoir plusieurs significations : « poste téléphonique » ou « emploi ». Ce qui est intéressant est cette idée d’inter-compréhension, où le sens du mot poste est désambiguïsé grâce au dialogue : U (l’utilisateur) pense au travail (avec vacataire) alors qu’en fait D (le développeur) et R (le rédacteur) lui précisent le mot « poste » comme « poste téléphonique » pour qu’ils aient la même représentation du mot. Luzzati [LUZ 95] s’est intéressé au dialogue homme-machine finalisé et à ces problèmes d’inter-compréhension. Il a notamment émis l’idée que le dialogue se structure selon deux axes : • le dialogue régissant, où une réponse à une demande d’informations se réalise sans difficulté. Il correspondant à un enchainement direct du dialogue, où une demande aboutie directement à une réponse. • le dialogue incident, qui pourrait être vu comme un sous dialogue, permettant de demander des reformulations, des précisions par rapport à une demande. Nous nous trouvons dans le cas où il apparaît difficile de répondre directement à une demande, il est nécessaire d’avoir plus de détails sur les attentes. Ce problème de coadaptation du sens, de cette inter-compréhension, est important dans un dialogue. Nous voulons donc nous intéresser à ce problème du point de vue de la proximité du sens, ce qui permet à plusieurs entités de dialoguer avec leur propre vocabulaire, leurs propres expériences, tout en trouvant un terrain commun de compréhension. Ce problème pourrait s’apparenter à la compréhension d’un jargon. Un des exemples de ce jeu de sens serait l’idée développée par un jargon, définit comme un parler d’un groupe social ou d’une classe sociale, propre aux représentants d’une profession ou d’une activité (Wikipedia). Nous pouvons définir la classe sociale comme un groupe d’individus ayant en commun un statut social et un mode de vie. Nous voulons donc chercher à faire le lien entre un vocabulaire utilisateur, un lexique qu’il manipule, et l’enchainement dialogique de la Projet sur les Processus d’Interaction en Conception distribuée à propos de la conduite du projet rédactionnel des documentations utilisateurs. 6 13 Chapitre 1 : Contexte machine, guidé par les tâches. En effet, nous nous sommes aperçus que lors d’un dialogue homme-machine finalisé, l’utilisateur ne se servait pas (ou tout simplement ne connaissait pas) du vocabulaire technique utilisé par la machine, mais son propre vocabulaire basé sur ses connaissances. Or si ce vocabulaire ne coïncide pas, la tâche ne peut se poursuivre et la machine ne sait pas agir en conséquence, elle demande simplement à l’utilisateur de reformuler son énoncé. Finalement, il serait intéressant de s’interroger sur la synonymie, sur le mécanisme de passage d’un lexique utilisateur aux concepts manipulés par la tâche par une machine. Nous nous trouvons ainsi entre l’énoncé de l’utilisateur et la tâche à réaliser par la machine. En effet, comme nous l’avons vu dans le chapitre précédent, la machine interprète un énoncé selon un modèle basé sur la détection de concepts. Or les concepts manipulés dépendent d’un lexique manipulé par la machine, permettant alors d’accomplir une tâche. Cependant, l’utilisateur ne manipule pas forcément ces mêmes concepts, les mêmes idées, mais parfois des concepts proches. Figure 4 Problématique abordée La figure résume l’idée qu’il existe parfois une frontière entre les concepts manipulés par l’utilisateur et ceux manipulés par la machine. La problématique est donc de faire le lien entre les idées de l’utilisateur et les concepts compris et manipulés par la machine, qui peuvent être différents. Nous pouvons ainsi nous intéresser au langage commun et au jargon technique, qui nous semble un bon exemple de ce que peut être l’inter-compréhension. Prenons ainsi le cas où nous dialoguons pour réserver un billet d’avion. Nous voulons réserver un billet dans la période se situant dans la basse saison. Ce qui pour nous semble normal (le terme « basse saison » est souvent employé pour désigner une saison de faible affluence), ne l’est pas forcément pour l’employé devant répondre à notre requête. Dans notre exemple, « basse saison » correspondant à l’idée de « bleu ». 14 Chapitre 1 : Contexte Figure 5 Exemple langage commun/jargon technique Il nous faudra être capable de mettre en place un système faisant le lien entre des concepts (par exemple le lien entre le langage commun et le jargon technique). 1.2.2 Objectifs poursuivis Pour mener à bien cette problématique, nous avons défini différents objectifs à atteindre. Nous devons tout d’abord chercher à mettre en place un logiciel capable de détecter les incompréhensions. En effet, il faudrait dans un premier temps pouvoir trouver dans des énoncés les concepts que la machine ne peut interpréter, et au final en rendre compte. Ce premier objectif permettra ensuite de continuer la problématique, et de chercher à mettre en place un système pouvant gérer les incompréhensions utilisateur/machine. Il faudra chercher à définir un mécanisme capable de détecter une proximité de sens entre les concepts afin de réussir à faire le lien entre un jargon utilisateur et le langage technique de la machine dédié aux tâches à accomplir. Pour ce faire, il faudra définir un calcul du sens, permettant alors de définir une proximité entre les concepts. Le calcul permettra de prendre des décisions par rapport à la sémantique des concepts, et de pouvoir prendre des décisions au niveau de la tâche. En d’autres termes, cela permettra à la machine de continuer à exécuter une tâche, même si le concept énoncé par l’utilisateur est différent de celui utilisé pour l’exécuter. 1.3 Méthodologie suivie Afin de répondre à la problématique et aux objectifs poursuivis, nous avons choisi de mettre en place une certaine méthodologie, qui constitue une étape importante dans notre démarche de recherche puisqu’elle va conditionner les résultats finaux. L’idée est de développer le travail selon trois axes (Programmer, Modéliser, Exemplifier) dans l’optique que ceux-ci se recoupent finalement pour obtenir un composant dialogique générique réutilisable. Les trois branches sont bien entendues fortement couplées entre elles, la partie programmation pouvant par exemple permettre de mettre en lumière des difficultés ou des manques dans le modèle. 15 Chapitre 1 : Contexte Figure 6 Axes de travail La partie « programmation » est la branche consacrée au développement logiciel du composant, selon le modèle qui est défini, ainsi que des exemples trouvés. Le but est d’expérimenter les idées développées afin de vérifier la robustesse et la réaction du système. Elle permet de nous rendre compte de la pertinence de nos travaux. La partie « exemple » regroupe tous les exemples intéressants à prendre en compte pour « tester » le système ou permettre au modèle d’évoluer. Le but ici est de trouver ce qui peut poser problème, les spécificités de la langue naturelle qui devraient être prises en compte par le système. La partie « modèle » représente le modèle computationnel sur lequel s’appui le composant développé. En effet, celui-ci doit être suffisamment générique pour analyser sémantiquement des énoncés, et permettre de répondre à notre problématique. Afin de faciliter le déroulement de notre travail et de pouvoir mieux nous organiser, nous avons décidé de le décomposer en différentes parties. Le schéma suivant présente cette organisation : Figure 7 Méthodologie du projet 16 Chapitre 1 : Contexte La première et la seconde phase sont très liées puisque l’idée est de choisir un corpus de dialogues réels et de l’analyser. Le fait d’utiliser de vrais dialogues possède l’avantage de fournir des exemples concrets, et d’en extraire quelques phases d’intercompréhension entre les protagonistes du dialogue, permettant alors d’analyser la façon dont ce terrain commun est construit. Nous partons d’exemples réels d’énoncés qu’un dialogue peut engendrer, et avons pour objectif de montrer que la problématique a un intérêt certain dans le dialogue homme-machine, censé permettre une interaction proche d’un dialogue homme-homme. A partir de ces phases s’en suivent deux phases bien distinctes du travail qui seront accomplies en parallèles. D’une part il s’agira de choisir des exemples sur lesquels il sera possible de s’appuyer pour résoudre la problématique et pour réaliser différents tests. En effet, ceux-ci devront permettre de valider nos hypothèses émises. D’autre part, il faudra travailler sur les objectifs définis précédemment et notamment sur la mise en place d’un calcul permettant de faire le rapprochement entre différents concepts (le langage commun et le « jargon » technique). Ce calcul est essentiel car il constitue le fond du travail à accomplir. Ensuite, partant des exemples extraits, il s’agira notamment ensuite de créer les données, qui serviront de base au rapprochement des concepts. Ces données utiles au rapprochement seront réunies au sein d’une hiérarchie construite grâce au modèle Anadia, modèle qui nous permettra de mettre ce terrain commun entre l’utilisateur et la machine. Nous reviendrons plus en détail sur ce modèle et ses concepts dans la prochaine partie de ce rapport. Lorsque les phases de recherche du calcul à mettre en place, et de la création des tables du modèle Anadia auront été effectuées, il faudra implémenter informatiquement ces concepts. Puis nous effectuerons différents tests avec les exemples extraits afin de vérifier la fiabilité de nos choix. Les différents résultats seront ensuite analysés, et au besoin, notre modélisation ainsi que nos calculs seront retravaillés. Nous avons alors perçu au cours de cette partie la base de notre travail (les théories et l’analyseur TALENT) ainsi que la problématique que nous avons à résoudre. Nous allons maintenant nous focaliser sur les fondements théoriques de nos travaux, qui nous ont permis de mettre en place une solution face aux problèmes soulevés. 17 Chapitre 2 : Les fondements théoriques 2 Les fondements théoriques 2.1 Une approche interprétative Le modèle sémantique que nous allons utiliser s’inscrit dans l’idée d’une approche interprétative de la langue, initiée par Saussure [RAS 94]. Ainsi, comme le définit Beust dans [BEU 98], une approche interprétative consiste à se focaliser sur l’allocutaire dans son activité d’interprétation des paroles des autres, mais aussi des siennes lorsqu’il les entend. En d’autres termes, l’idée est de se différencier des théories basées sur le fait que le sens se construit en fonction des intentions du locuteur 7, en s’intéressant plutôt à l’idée que le sens est considéré comme étant propre à l’interprétant, les observations faites à partir des énoncés fournis le guidant. Il semble impossible de représenter les intentions du locuteur aux travers des énoncés émis, puisqu’elles lui sont propres, mais qu’il est envisageable de représenter les résultats de l’enchainement conversationnel par l’observation (on ne représente pas l’activité mais le résultat de l’observation de l’activité). Comme soutenu dans [BEU 98], l’approche interprétative rend compte de deux niveaux dans la compétence linguistique : • La compréhension est une activité langagière propre à l’homme permettant d’obtenir un résultat, dont on ne connait pas forcément les mécanismes sous-jacents. Beust, au travers de cette idée développée par Rastier, fournit l’exemple de la fermeture d’une fenêtre, suite à l’énoncé émis par une personne « il fait froid ». • L’interprétation n’est pas forcément une activité humaine, puisque elle peut se trouver dans d’autres systèmes, comme par exemple dans le monde des ordinateurs interprétants un code binaire. Cette interprétation est perçue comme le premier plan de la compréhension, et se situe au niveau de la sémantique. Finalement, l’approche interprétative implique de comprendre d’abord le sens de l’énoncé, pour pouvoir ensuite expliquer la signification des constituants de l’énoncé. Pour s’en convaincre, Beust fournit un exemple de métaphore emprunté à Lakoff8 « L’inflation dévore tous nos profits » où en fin de compte on ne cherche pas à comprendre directement le verbe dévorer, en l’appareillant directement avec l’idée de manger férocement, mais on fournit une signification en fonction de sens général de l’énoncé, donc plutôt l’idée de réduire de façon importante. 2.2 L’influence du co-texte Nous nous basons sur l’hypothèse que le sens se construit par rapport à un co-texte. Le co-texte correspond ici aux informations présentes tout autour d’un mot d’une phrase, qui agissent sur celui-ci. Il est souvent associé dans la littérature au contexte linguistique. Différents cotextes peuvent ainsi inférer différents sens à un même mot, puisqu’il n’est pas utilisé avec la même intention. Prenons par exemple le mot « avocat », que nous avons emprunté dans [BEU 98] : Avec notamment la théorie de la communication de Shannon et Weaver [SHA 49], et la théorie de la cognition de [FOD 86]. 8 Extrait de Lakoff G. et Johnson F. dans les métaphores de la vie quotidienne 7 18 Chapitre 2 : Les fondements théoriques Je mange un avocat. L’avocat a défendu l’accusé. Dans cet exemple, le mot avocat est utilisé dans deux sens différents, celui-ci étant polysémique. En effet, nous avons dans un premier temps « avocat » utilisé dans le sens de « fruit », puisqu’il y a utilisation du verbe « manger » qui lui confère ce sens. Dans le second exemple, le mot « avocat » prend le sens « d’homme de loi » grâce aux utilisations des mots « défendre » et « accusé » qui renvoient à des termes juridiques. Le co-texte semble clairement avoir son importance dans le sens et l’utilisation d’un mot. L’idée défendue par Saussure, est que les mots entretiennent entre eux une certaine proximité par rapport à des valeurs qui les définiraient. Ainsi, il serait possible de pouvoir remplacer une expression par une autre si les valeurs qu’elles partagent sont proches, et que finalement le sens dans le cotexte ne varierait pas beaucoup. Ce remplacement de ces deux expressions s’inscrirait au sein d’un même paradigme. Comme l’explique Beust, les relations qu’entretiennent les éléments d’un paradigme sont, d’un point de vue saussurien, celles qui organisent les significations en un système de valeurs. En d’autres termes, les différents paradigmes existants sont reliés entre eux et ne sont pas indépendants les uns des autres, puisqu’en fin de compte ils sont reliés par des relations de polysémie, un même mot pouvant se retrouver au sein de plusieurs paradigmes (l’idée développée précédemment de différents co-textes). 2.3 La sémantique différentielle Selon la conception véhiculée par la sémantique différencielle, le sens est vu comme « valeur ». Cette théorie linguistique, initiée par Rastier, met l’accent sur les relations entre les significations des mots au sein d’un lexique. La signification d’un mot est alors définit par les différences qu’elle entretient avec celle des autres mots. Ces différents mots peuvent prendre place au sein d’une même classe, et sont différenciés entre eux au moyen de sèmes (ou traits sémantiques) qui constituent, selon cette approche, la plus petite unité de sens. Ces sèmes marquent alors soient les points communs, soient les différences des mots présents dans la même classe sémantique. L’ensemble des sèmes, représentant la signification d’un mot est appelé sémème. La sémantique différentielle s’oppose à la sémantique référentielle, consistant, comme l’explique Beust [BEU 98] à définir le sème comme une qualité du référent, c'est-àdire une façon de caractériser une expression de façon descriptive9. Une approche différentielle préfère utiliser les sèmes non comme une façon de décrire une expression, mais plutôt une possibilité de différenciation entre différentes expressions s’inscrivant au sein d’une même classe sémantique, appelée taxème. Les sèmes sont donc choisis de façon à permettre une différenciation entre les différentes expressions. Pour illustrer la théorie de Rastier, Potier a pris pour exemple la description des sièges : Beust prend alors l’exemple de l’expression voiture qui possèderait les sèmes /quatre roues/, /un châssis/, /un moteur/… 9 19 Chapitre 2 : Les fondements théoriques Figure 8 Les sièges de Potier Grâce à cette table, il est ainsi possible de différencier les mots entre eux au moyen des sèmes /avec dossier/, /pour plusieurs personnes/ et /avec bras/. Ainsi, dans cette classe qui a été définie, « fauteuil » se différencie de « canapé » grâce au sème /pour plusieurs personnes/, qui est possible pour « canapé » mais impossible pour « fauteuil ». Comme l’explique Beust [BEU 98], le sème est vu comme le concept de base d’un premier palier de la sémantique, se limitant à la modélisation paradigmatique des signifiés, la microsémantique. L’axe paradigmatique concerne le choix des mots. Il est souvent opposé à l’axe syntagmatique qui concerne plutôt le placement de ces mots au sein d’un énoncé. La microsémantique a pour limite supérieure la lexie, unité minimale d’expression, correspondant souvent à un mot ou groupe de mots (exemple « assiette » mais aussi « pomme de terre »). Elle a deux objectifs : • Une étude componentielle des significations, qui consiste en la décomposition et la mise en évidences des sèmes. Cette étude permet donc d’apporter une information sémantique pour un signifié. • Une étude des systèmes de significations, permettant de définir la place de chaque signe linguistique dans le système. En d’autres termes, il s’agit de différencier un signifié par rapport à d’autres. Cependant, Beust émet l’idée que différentes conditions doivent être respectées pour qu’un sème puisse avoir sa place au sein d’un sémème. Tout d’abord, le sème doit permettre de décrire le sémème dans lequel il apparaît, mais aussi permettre de différencier un autre sémème sémantiquement proche. Par exemple, pour le sémème « humain », le sème /animé/ permet d’en donner un sens. Si ce sème est remplacé par /inanimé/, celui-ci traduira alors le signifié de « animal ». De plus, le sème peut avoir comme utilité d’indexer le sémème, de fournir une information au niveau de la classe. Beust décrit ainsi l’exemple des sièges de Pottier en précisant que les sémèmes « chaise », « fauteuil », « canapé » et « tabouret » contiennent tous le même sème /pour s’asseoir/. En fin de compte, on ne cherche pas ici à les différencier directement mais à les indexer dans une même classe (ici la classe des « sièges ») qui est finalement héritée. Cela permet de différencier à un niveau supérieur les sémèmes de la classe (on peut alors comparer « siège » et « table »). Ainsi, selon la fonction, le sème peut être soit spécifique (permettant de différencier les sémèmes au sein d’une même classe), soit générique (pas de différenciation directe des sémèmes, mais sème qui est hérité). En sémantique différentielle, l’ensemble des sèmes d’une même classe, les sèmes spécifiques, sont appelés sémantèmes, et les sèmes génériques sont appelés classèmes. Ce modèle, tel que l’a vu Rastier, ne peut cependant être utilisé directement par une machine, les concepts qu’il manipule n’étant pas à la base pensés dans cette optique. Beust choisit donc d’adapter ce modèle, et d’y introduire de nouveaux concepts afin de le rendre computationnel. Tout d’abord, le concept des sèmes décrivant les sémèmes, est vu comme un 20 Chapitre 2 : Les fondements théoriques ensemble de marqueurs qui se suffisent à eux-mêmes pour l’interprétation que peut en faire un humain. Or cela reste une approche linguistique présupposant une interprétation humaine [BEU 98]. Lors d’une utilisation du modèle par une machine, deux approches sont possibles : • La machine sert à aider l’utilisateur dans l’interprétation faite avec le modèle. La machine n’a donc aucun pouvoir de décision. • La machine possède les bases d’une interprétation. Le sème porte alors des informations qui orientent l’interprétation de la machine, et permet ainsi une négociation du sens dans interaction homme-machine. Ainsi, Beust préfère voir le sème comme une entité négative (différenciatrice)et non plus comme une entité positive (informative). L’idée est que la description qui est fait grâce au sème, mais plutôt ce à quoi le sème permet d’opposer. Il donne alors l’exemple du trait /animal/, qui ne semble pas très informatif pour une machine, mais qui peut être intéressant si on utilise ses opposés, à savoir /végétal/ ou /humain/. Il apparaît bien entendu impossible de représenter toutes les oppositions existantes pour un sème, mais l’intérêt est d’en choisir une partie selon le contexte, qui évoluera lors d’un processus interactif d’apprentissage entre l’homme et le machine. Beust fait également intervenir la notion de domaine d’interprétation, correspondant au domaine rattachant une opposition. Par exemple, les traits opposés /animal/ et /végétal/ n’ont de sens que dans le domaine d’interprétation des êtres vivants, alors que par exemple /animal/ et /objet/ auraient du sens dans le domaine d’interprétation du matériel. Il est alors possible d’entrevoir la notion de métaphore, notamment grâce à la combinaison du domaine d’interprétation ajouté aux oppositions. Selon la définition de Lakoff dans [LAK 85], l’essence d’une métaphore est qu’elle permet de comprendre quelque chose (et d’en faire l’expérience) en termes de quelque chose d’autre. En effet, il nous arrive très souvent d’utiliser de façon métaphorique des domaines d’interprétation. Beust le démontre par l’exemple du domaine d’interprétation des valeurs qualitatives, avec les oppositions bien et mal, qui est utilisé très souvent dans le domaine d’interprétation du « bien être » pour exprimer des états de santé (alors que le domaine d’interprétation premier serait plutôt celui de la « morale »). L’idée est donc d’utiliser les oppositions dans un autre domaine d’interprétation que son domaine initial, d’où une négociation du sens selon le contexte. Beust cherche à changer la façon dont est perçu le sème. En effet, Rastier, dans [RAS 94] propose de voir le sème comme une relation fonctionnelle entre significations10. Or Beust cherche plus une opposition dans l’idée du sème. Il cite notamment l’exemple du bistouri et du scalpel, en opposant les deux sèmes /pour les vivants/ et /pour les morts/ dans la sémantique différentielle. Ici, ces deux sèmes ne seront considérés que comme un seul sème dans le modèle de Beust, résultant de l’opposition vivant et mort dans le domaine d’interprétation de l’état physiologique. Figure 9 10 Modifications apportées par Beust La figure 8 représente bien cette utilisation du sème, avec le ‘+’ représentant une possession, et le ‘-’ un rejet. 21 Chapitre 2 : Les fondements théoriques 2.4 Le modèle Anadia En s’appuyant sur les concepts présentés précédemment, Beust [BEU 98] présente une méthode de catégorisation différentielle qu’il nomme Anadia. Cette méthode doit permettre à la machine d’appréhender la notion de sens, et ainsi de mettre en place un système de valeurs. Le modèle se veut interactionniste, dans le sens où un agent informatique ne possède pas toutes les connaissances, mais que ces connaissances évoluent au fur et à mesure des interactions que peut avoir un utilisateur avec le système. Le principe d'Anadia est de construire un analogue de la mémoire sémantique et non une représentation ontologique du monde : on ne cherche pas à tout modéliser, mais plutôt à se construire une représentation en fonction des interactions entre l'homme et la machine. Il s’agirait alors de proposer une grille de description des entités qui pourraient être intéressantes pour le dialogue, et d’en fournir leurs différences, permettant ainsi d’interpréter ou de produire des énoncés langagiers. Ces descriptions permettront alors d’avoir un champ de dialogue commun entre les utilisateurs et la machine, de pouvoir interpréter des énoncés émis par un utilisateur. Le modèle Anadia a également été conçu selon des principes issus du carré sémiotique [ERM 96], appelé aussi carré d’Aristote. Le principe défendu par le carré sémiotique est qu’il existe quatre places représentant les oppositions de signes. Ainsi, soit deux signes opposés p et q. Le carré sémiotique permet de représenter les contraires de p et q, soit non p et non q. L’idée est que, dans le carré, l’effet produit par la mise en opposition de p et q est le même que celui produit par non p et non q. Greimas dans [GRE 83] fournit alors un exemple d’un carré sémiotique, représenté par la figure ci-dessous, construit sur l’axe sémantique du désirable et du nuisible. Figure 10 Exemple de carré sémiotique Bien que ce type de système soit intéressant, Beust souligne qu’il n’est possible de faire intervenir que quatre places, ce qui limite grandement les oppositions. L’intérêt du modèle Anadia est de permettre une distinction bien plus grande entre des termes, puisque les différences ne sont pas limitées en nombre. Le modèle Anadia peut donc être considéré comme une généralisation du carré sémiotique. Anadia a pour objectif de catégoriser et de sous-catégoriser des termes, et d'y insérer les différents attributs différenciables étant les plus pertinents pour l'interprétation. Il faut bien se rendre compte que le modèle n’a pas pour objectif premier de représenter une ontologie du monde, mais une description de l’objectif que l'on s'est donné. Le processus de catégorisation permet d'obtenir un résultat sous forme d'arbre de tables contenant toutes les catégories et sous-catégories analysées. Beust prévient cependant qu’aucune relation n’existe entre les frères d’une même grille, les attributs utilisés étant généralement différents. Seules les relations de catégorisation et de sous-catégorisation peuvent prétendre avoir une pertinence au niveau du sens. 22 Chapitre 2 : Les fondements théoriques Figure 11 Arbre de grilles de catégorisation [BEU 98] Beust définit également différents concepts propres au modèle Anadia. Tout d’abord, il fait intervenir la notion d’attribut. Un attribut est considéré comme une propriété associée à une chose, permettant ainsi de la caractériser. Nous pouvons alors prendre l’exemple de l’attribut nom de famille associé à un être humain et pas à un vase, ou encore l’exemple de l’attribut vivant associé à un animal et non à un objet. L’attribut, tel que le conçoit Beust, possède une liste de valeurs qui a pour intérêt premier de distinguer les choses entre elles. En effet, on ne doit pas prendre des attributs de façon désordonnée et sans réel objectif, il faut que ceux-ci servent à catégoriser les différentes choses et à les différencier. Un attribut se compose d’un nom et de différentes valeurs. Afin de pouvoir catégoriser les différents concepts du modèle, il faut souvent définir différents attributs. Le regroupement de ces attributs est appelé registre. En fin de compte, la combinatoire des registres permet de fournir différents champs à une catégorie, et d’y associer différents concepts. Cette combinatoire est calculée grâce au produit cartésien des différents registres. Il s’agit d’avoir toutes les combinaisons possibles des places libres en multipliant les valeurs des différents registres utilisés dans la table. Par exemple, si deux registres (A et B) sont utilisés dans une table, A possédant deux valeurs et B possédant trois valeurs, alors il y a aura six places disponibles dans la table (« deux » multiplié par « trois »). L’ensemble des places ainsi créé permet de définir des tables, notion se rapprochant du concept de taxème de la sémantique différentielle. L’exemple de la figure suivante permet de mieux comprendre les différentes notions (attribut, registre et table) manipulées. En effet, dans le schéma suivant, A et B permettent de représenter les attributs, qui une fois regroupés forment un registre. Dès que le produit cartésien est effectué, une table se forme alors avec 6 places possibles, donc 6 concepts définissables. Par exemple, avec le jeu de valeurs 2 roues et sans moteur, nous pouvons placer le concept vélo. Ou encore avec le jeu de valeurs 4 roues et avec moteur, nous pouvons nommer le concept voiture. Cependant, il faut se rendre compte que la combinatoire peut amener à décrire des concepts que l’on ne peut nommer, qui n’existent pas. Par exemple il apparaît difficile de trouver un concept avec le jeu de valeurs avec moteur et 1 roue, concept qui ne semble pas forcément exister dans la réalité. 23 Chapitre 2 : Les fondements théoriques Figure 12 Exemple d’attributs, de registres et de tables Un des intérêts de ce type de représentation est finalement de pouvoir lier les différents concepts entre eux en cherchant les différences qu’ils entretiennent. En effet, ces concepts sont plus ou moins proches ou éloignés en fonction des différences existantes entre les attributs qu’ils possèdent11. Dans Anadia, ces relations de différence sont calculées par rapport au nombre de différences de valeurs d’attributs entre les places sélectionnées. Le graphe que l’on peut extraire de ces relations est alors appelé topique. Ce graphe peut être très intéressant à utiliser puisqu’il permet finalement de rendre compte de la proximité des différents concepts, surtout au sein d’une même table. Beust définit la topique « à un trait près » comme la plus intéressante car elle permet de rapidement s’apercevoir des liaisons les plus fines existantes entre les concepts. Il affirme ainsi que le topique est le graphe le plus détaillé qu’on puisse donner pour décrire le système. Figure 13 Hiérarchie de tables et topiques associées L’exemple montre les topiques existantes dans les tables //Organisation// et //Catégorisation// à un trait près. Il est ainsi possible de rapidement voir les liens existants entre les différents concepts, et alors s’apercevoir de la proximité des concepts entre eux. Saussure parle de ces différences comme « ce que les autres ne sont pas », en fin de compte ce qui permet de différencier les concepts entre eux. 11 24 Chapitre 2 : Les fondements théoriques Dans cet exemple, les concepts « Catégorie » et « Coloration » sont différenciés entre eux au moyen de l’attribut Nombre, seules valeurs de l’attribut qu’ils n’ont pas en commun. Dans l’exemple suivant, nous voyons très clairement deux parties dans les topiques construites, avec un rapprochement fort entre « Rouge » et « Haute saison », et entre « Bleu » et « Basse saison ». Ces deux groupes n’ont ainsi aucun lien entre eux si l’on s’intéresse aux topiques à un trait près. Beust parle alors de trois niveaux de topiques au sein d’une même classe, définissant finalement le degré de proximité des sémèmes : • Un sémème A qui se trouve à un trait près d’un autre sémème B. B peut alors être considéré comme un antonyme de A. Un antonyme peut être définit comme un mot ayant un sens opposé à un autre mot, donc ici que les sémèmes s’opposent au moyen d’un registre. • Un sémème A n’étant pas directement relié à un sémème B, mais qui l’est au moyen de sémèmes intermédiaires voisins (par exemple un sémème C, proche à un trait de A et à un trait de B). • Un sémème A n’est pas relié (ni directement ni indirectement) à un sémème B. Le processus de catégorisation des tables Anadia n’est pas automatique, il ne résulte pas d’une analyse faite par une machine qui, au final, construit elle-même les tables. La catégorisation est issue de l’interaction entre l’humain, qui a la responsabilité de construire et de représenter les tables en fonction d’une analyse qu’il a effectuée, et la machine, qui utilise les représentations au moyen de calculs (avec par exemple l’utilisation de topiques). Un des intérêts de ce type de modèle est alors la remise en cause fréquente des grilles de catégorisation mises en place. En effet, les grilles évoluent souvent puisqu’elles sont le résultat d’une analyse et d’une construction effectuée par un humain, qui sera ensuite utilisé par une machine. L’utilisation par la machine guidera ainsi la modification des tables, les résultats étant rarement satisfaisants du premier coup. C’est en cela que Beust [BEU 00] parle d’une démarche de modélisation expérimentale consistant à mettre en place des interactions langagières entre humains pour ensuite les analyser et fonder le modèle. Finalement, Beust s’inspire de dialogues entre humains pour mettre en place son système de catégorisation, permettant ainsi de s’utiliser de vraies situations dialogiques. Beust est ainsi parti d’un extrait de conversations pour mettre en place ses grilles et réaliser ses jeux de test. Finalement, le modèle Anadia se base sur les mêmes principes que la catégorisation, et peut donc être appliqué à la représentation componentielle et différentielle des signes linguistiques12. Ainsi, peut importe le but recherché avec l’utilisation des grilles, le modèle reste totalement dépendant de l’agent humain. L’intérêt de se modèle est donc de représenter le contenu sémantique des mots en contexte, sans avoir à représenter tous les sens possibles des mots. En se basant sur les concepts sur lesquels Beust s’appuie au départ, et ceux qu’il a apportés ensuite, il est alors possible de les rapprocher. Ainsi, la notion de sème introduite précédemment pourrait, dans la modèle Anadia, s’apparenter eu concept d’attribut développé par Beust. Beust donne alors l’exemple d’un attribut à trois valeurs a, b et c qui permettrait de représenter les oppositions a vs b, b vs c et c vs a. Par exemple si l’on utilise le sème possédant les oppositions liquide, gazeux et solide se trouvant dans le domaine d’interprétation de l’état physique [BEU 98], il est possible d’utiliser ce sème comme un attribut représentant l’état physique d’un composant, possédant les valeurs d’opposition liquide, gazeux et solide permettant alors de décrire une partie de mots. 12 Voir le chapitre 2.3 sur la sémantique différentielle 25 Chapitre 2 : Les fondements théoriques Beust [BEU 98] s’attarde également à faire le rapprochement entre le concept du sémème développé dans la sémantique interprétative, et le concept du sémème qu’il développe. En effet, l’idée est toujours qu’un sémème est constitué d’un ensemble de sèmes, mais dans l’idée que se fait Beust du sémème, il est ici constitué d’attributs. Chaque sémème actualise une valeur d’opposition de chaque sème qui le définit, permettant de différencier au final les sémèmes. Un des exemples déjà mis en avant précédemment est celui des sémèmes « scalpel » et « bistouri », qui dans le domaine de l’état physiologique, permet d’actualiser la valeur vivant de ce sème pour « scalpel », et mort pour « bistouri ». Figure 14 Actualisation de sèmes [BEU 98] Dans le modèle Anadia, les sèmes qui définissent le sémème au niveau d’une table ne sont pas les seuls sèmes à agir sur le sémème. En effet, comme nous l’avons vu précédemment lors de la description des principes du modèle, les sémèmes sont inscrits au sein d’une hiérarchie. Beust fait alors référence aux sèmes se trouvant au niveau directement supérieur au sémème dans la hiérarchie, sèmes qui se trouvent au niveau de la classe. Il parle alors de sèmes spécifiques (au niveau de la table) et de sèmes génériques (au niveau de la table supérieure). Figure 15 Exemple de structure du sémème « Basse saison » Enfin, Beust fait intervenir la notion de taxème dans Anadia, en s’inspirant de la sémantique différentielle. En effet, un taxème s’apparente à une classe de sémèmes sémantiquement proches car possédant des sèmes génériques en commun, et des sèmes spécifiques permettant de les différencier. La proximité entre les différents sémèmes est alors représentée au moyen des topiques, que nous avons présenté précédemment, notamment les topiques à un trait près. 2.5 Justifications du modèle Anadia Le modèle Anadia semble finalement totalement adapté à la problématique que nous nous sommes posés. Tout d’abord, le principe de catégorisation nous parait intéressant pour donner du sens aux concepts. En effet, le modèle existant que nous utilisons permet « d’assembler » les concepts entre eux par rapport aux descriptions que l’on en a faites13. Cependant, nous ne retrouvons pas dans ce modèle l’idée de proximité entre les concepts, une description assez précise permettant d’établir une proximité entre eux, ce que semble pouvoir apporter le modèle Anadia. Ce modèle permet une description des concepts au moyen 13 Nous pouvons alors nous référer à la partie 1.1 décrivant le Dialogue Homme-Machine Finalisé. 26 Chapitre 2 : Les fondements théoriques d’attributs (de sèmes) en se basant sur l’idée de la sémantique différentielle. Il est alors possible d’établir une proximité entre des concepts grâce aux différences dans les valeurs d’attributs au sein d’une même classe. Le modèle Anadia offre ainsi une puissance de description des concepts qui nous semble réellement utile pour réussir à répondre à notre problématique. Cette description se retrouve alors au sein de tables mais aussi au niveau d’une hiérarchie permettant alors de décrire des parties du monde. Il est envisageable de décrire différents domaines d’interprétation au moyen des tables Anadia, il suffit de mettre en place différentes hiérarchies décrivant différents domaines selon le dialogue mis en place (nous pouvons alors décrire des domaines différents tels que le domaine de l’informatique ou encore celui des moyens de transport). La hiérarchie complète peut alors permettre de mettre en place des calculs sur la proximité des différents concepts : l’intérêt est d’avoir différents choix possibles. Nous ne nous enfermerons donc pas dans une certitude, mais plutôt dans un panel décisionnel guidé par un calcul de proximité des concepts, permettant ainsi une plus grande flexibilité dans la compréhension de sémantique d’un mot par la machine. En effet, un mot peut posséder plusieurs synonymes, et plusieurs interprétations d’un même mot sont souvent possibles. Prenons un exemple tiré du corpus « Air France », collecté par le Centre de Linguistique Française à la Sorbonne Nouvelle de Paris III : Est-ce qu’il y a des droits de, enfin des prix, pour les aéroports, soient français soit américains. Cet exemple illustre bien que les concepts manipulés n’ont pas le même sens selon le contexte. En effet, un client utilise les concepts de droit et de prix pour ce qui semble être le concept de taxe. Or dans son sens premier, droit signifie ensemble des lois et des coutumes qui régissent un pays14. Idem pour prix, qui est une valeur, estimation d’une chose pour vendre et acheter. Le bon concept n’est alors pas bien choisi, mais le contexte et les concepts proches utilisés nous permettent de réaliser ce rapprochement. D’où l’intérêt d’utiliser un modèle capable de décrire des concepts, de faire ressortir ce qui les caractérise, pour finalement permettre de les rapprocher. L’exemple suivant montre une modélisation possible des concepts « Taxe », « Droit » et « Taux », très proches sémantiquement, que nous avons choisi de comparer au sein d’une même table //Taxation douanière//. Ces concepts sont différenciés grâce aux attributs Permission, Coût et Figé, qui, grâce à l’actualisation de leurs valeurs, apportent le sens aux concepts. Figure 16 Exemple table des concepts Taxe/Droit/Taux La description de domaines d’interprétation nous amène également à penser que le modèle Anadia serait adapté pour gérer des phénomènes spécifiques à la langue naturelle, les figures de style, et notamment la métaphore. Comme nous l’avons vu précédemment, la 14 Définition extraite du dictionnaire de Mediadico : http://dictionnaire.mediadico.com 27 Chapitre 2 : Les fondements théoriques métaphore peut être définie comme la transposition de sens d’un domaine vers un autre15. Or Anadia pourrait permettre de gérer ce genre de phénomène puisque le modèle repose sur une description du monde, d’un contexte, de domaines d’application. Nous pensons alors que si la description des tables, et donc la description des sémèmes au moyen des sèmes est assez fine, il sera possible de découvrir des métaphores et donc le sens « caché » recherché par l’auteur. Nous nous basons également sur l’idée développée par Tort dans [CHA 99] qui affirme que toute réalisation métaphorique consiste simplement dans la sélection de sèmes communs aux deux sémèmes mis en comparaison. A cela s’ajoute l’idée défendue par Gardes-Tamine [GAR 05] qui pense qu’il n’y a pas de figure hors contexte entretenant avec un terme propre une relation sur le mode de la synonymie, où le contexte joue en fin de compte un rôle dans la signification. Nous avons ainsi la conviction que le modèle Anadia pourrait répondre, au moins en partie, au problème de la compréhension de métaphores par la machine. Enfin, un des avantages du modèle Anadia est que le modèle a été conçu de façon à ce qu’il soit computationnel. Il reprend des idées issues de théories linguistiques pour finalement posséder un outil qui pourra être implanté et utilisé par une machine. Une de ses grandes forces est de pouvoir permettre de mettre en place des calculs notamment grâce à la hiérarchie des tables mise en place, et avec l’utilisation des topiques. Il apparaît alors possible d’estimer de manière mathématique le degré de relation entre les concepts, ce qui va nous être très utile pour répondre à notre problématique de recherche de proximité entre les concepts, avec notamment pour enjeu de pouvoir faire la liaison entre des termes techniques d’un domaine d’application, et des concepts manipulés par un utilisateur. Finalement, le modèle hiérarchique, comme le présente Beust, se construit grâce à l’interaction et l’analyse au cours de dialogues. En effet, les tables sont construites par rapport aux échanges durant un dialogue, et n’est en fin de compte pas figé. L’idée est que le modèle se développe continuellement et n’est jamais définitif. Nous nous trouvons dans une situation au cours de laquelle il ne faut pas prendre une modélisation pour acquise, mais remise en cause après chaque interaction, puisqu’il ne semble pas exister un terrain commun universel à toute personne. Pour notre part, nous utilisons le modèle Anadia dans ce travail de façon figé. Nous modélisons au départ une amorce langagière, une représentation des concepts, mais nous ne nous sommes pas intéressé à l’évolutivité du modèle au cours du dialogue. En conclusion, le modèle Anadia nous parait répondre à cette mise en place d’un terrain commun entre la machine et l’utilisateur, et c’est pour cette raison que nous l’utilisons. 15 Par exemple, l’homme est un loup transpose loup, du domaine « animal », vers le domaine « humain ». 28 Chapitre 4 : Application informatique 3 Modélisation de l’inter-compréhension 3.1 Corpus de dialogues 3.1.1 Acquisition et choix d’un corpus Afin de pouvoir répondre à notre problématique, nous avions besoin d’exemples concrets capables de confirmer (ou d’infirmer) nos théories en situation réelle de dialogue, l’intérêt étant d’avoir un dialogue homme-machine proche d’un dialogue homme-homme. Nous avons alors choisi de nous orienter vers la récupération et l’analyse d’un corpus de dialogues homme-homme existant. L’avantage d’avoir un corpus de dialogues déjà réalisé est de ne pas avoir à récolter nos propres données. Ainsi, cela nous permet de gagner du temps et d’avoir un corpus de dialogues déjà traité (transcription dialogue oral vers écrit). Cependant, le nombre de corpus existant de bonne qualité et mis à la disposition librement est assez limité. Nous avons quand même trouvé quelques corpus intéressants16, que nous avons étudiés, afin de trouver celui répondant au mieux à nos besoins. Notre choix dans le corpus devait se faire sur différents critères : • Il devait s’agir de dialogues (de préférence des dialogues oraux, plus spontanés que ceux écrits, et donc plus proches de la réalité) entre deux ou plusieurs personnes. • Le contenu du dialogue devait être important, afin de trouver des exemples variés et intéressants (difficiles à trouver sur des corpus de faible taille). • Il fallait que le dialogue porte sur une tâche précise à accomplir, puisque nous nous trouvons dans le contexte d’un dialogue homme-machine finalisé. • Pour une analyse plus facile, les échanges entre les protagonistes devaient être assez courts (éviter les longs monologues avec plusieurs idées : un énoncé, une tâche à accomplir). Nous avons finalement choisi d’utiliser le corpus récolté par le Centre de Linguistique Française de la Sorbonne Nouvelle à Paris III, que nous avons déjà cité comme exemple précédemment. Ce corpus possède de nombreux avantages, notamment celui d’être assez volumineux (73 dialogues oraux enregistrées puis retranscrits à l’écrit), d’être également orienté vers une tâche précise (la réservation de billets d’avions dans une agence de voyages), d’être à la base oralisé17, et de posséder des interventions relativement courtes (rarement plus de deux phrases par intervention d’un locuteur). Le fait d’utiliser et d’analyser un corpus réel permet également de voir plus loin que notre problématique. En effet, nous orientons pour l’instant notre analyse (notamment d’exemples) sur notre problématique, mais le corpus est assez complet pour qu’il puisse nous Les différents corpus trouvés sont extraits du site http://freebank.loria.fr/corpus.php qui se charge de les rassembler. 17 Nous nous trouvons ainsi dans un contexte réel de dialogue, les textes ne sont donc pas préparés, avec toutes les spécificités que cela suppose (pas forcément de structures grammaticales précises dans les énoncés, pas de structure dans le dialogue…). 16 29 Chapitre 4 : Application informatique intéresser plus tard lors de traitement d’autres problématiques du dialogue homme-machine. Ce corpus pourra alors servir de base à l’amélioration du dialogueur en trouvant d’autres problèmes liés au dialogue. 3.1.2 Exemples extraits Nous avons ensuite cherché des énoncés de ce corpus dans l’idée d’extraire des exemples capables de confirmer nos idées pour répondre à notre problématique. Quelle est la coloration du vol pour Marseille cette après-midi ? Est-ce qu’il y a des droits, enfin des prix, pour les aéroports français ou américains ? Est-ce qu’il existe des avions pour Catane en Sicile ? Est-ce qu’il y a des prix de vols vacances ? Et éventuellement, je peux retenir le billet ? Je voudrais savoir si ce vol s’arrête à Recife. Est-ce qu’il faut prendre un bus. Ce panel d’exemples18 montre bien qu’un vocabulaire unique n’existe pas. Nous utilisons souvent des concepts qui nous sont propres et que nous avons accumulés au cours de nos expériences. Et nous nous rendons compte que dialoguer nécessite souvent un ajustement de la part des protagonistes du dialogue. Nous sommes en plein cœur du processus de mise en place d’un terrain commun, où chacun essaie de se mettre au niveau de l’autre pour qu’il y ait une inter-compréhension. Chacun arrive dans le dialogue avec son propre bagage de connaissances, et c’est au cours de l’interaction entre les deux parties que le dialogue se construit. Les concepts manipulés sont donc différents, les exemples que nous avons extraits du corpus le montrent bien. Nous avons essayé de retenir les exemples qui nous paraissaient les plus pertinents et les plus intéressants à tester et modéliser. Nous constatons à la vue de ces exemples, qu’il n’est pas toujours évident de trouver des concepts qui appartiennent à l’utilisateur et non au domaine, l’utilisation de ces concepts nous étant très familière. Nous faisons généralement l’appariement direct entre les concepts (nous pouvons notamment penser à Est-ce qu’il y a des prix de vols vacances, où prix nous fait de suite penser à réduction par exemple). Il faut toujours garder à l’esprit que ce qui peut nous paraître « logique », et donc ce qui est induit, ne l’est pas pour la machine, d’où l’intérêt de la problématique soulevée. Nous présentons alors dans la figure suivante les concepts, spécifiques à l’agence de voyage, qui sont le pendant premier des concepts utilisés par les clients de l’agence. 18 Ce sont principalement des énoncés émis par le client lors de la réservation de billets. 30 Chapitre 4 : Application informatique Figure 17 Comparaison concepts commun/technique Nous nous apercevons qu’un effort est nécessaire à l’opérateur pour comprendre les concepts manipulés par les clients. Les opérateurs ont un vocabulaire précis qu’ils ont besoin de retrouver pour répondre aux attentes des clients. Cet ajustement peut paraître assez simple pour certains concepts mais semble parfois beaucoup plus complexe19. Le processus qui est mis en place doit donc rechercher ce que semble vouloir dire l’interlocuteur, pour pouvoir trouver le concept le plus proche sémantiquement, par rapport aux connaissances de l’opérateur. Prenons l’exemple de coloration, et cherchons à comprendre comment l’opérateur a pu faire le lien entre ce concept, et celui réellement attendu, catégorie. En fin de compte, l’exemple n’est pas si difficile à expliquer lorsque nous avons les connaissances suffisantes dans le domaine de la réservation de billets d’avion. En effet, un avion peut posséder une catégorie, qui permet d’avoir une idée sur le prix (chaque catégorie influe sur le prix). Les différentes catégories existantes sont identifiées par une couleur (catégorie bleue, rouge…) selon la période du vol. D’où le terme coloration utilisé par le client. Il doit savoir que la catégorie est identifiée par une couleur, donc il utilise ce concept pour parler de catégorie. Ce qui permet finalement à l’opérateur d’inférer qu’il parle d’une catégorie de vol, et non de la couleur de quoi que ce soit d’autre. Nous avons donc l’impression que le contexte et les connaissances acquises au préalable semblent indispensables pour comprendre et construire le terrain commun. 3.2 Le terrain commun L’avantage de travailler sur des données réelles est de pouvoir étudier certains phénomènes de la langue, et notamment certaines réactions humaines en situation de construction et d’avancée du dialogue. Nous avons alors pu remarquer que la co-construction d’un terrain commun était présente dans certains passages du dialogue entre un client et l’opérateur. La liaison bus/navette semble plutôt évidente, mais par exemple la liaison coloration/catégorie le semble beaucoup moins. 19 31 Chapitre 4 : Application informatique Client : Est-ce qu’il y a des droits, enfin des prix, pour les aéroports français ou américains ? Opérateur : des taxes ? Client : des taxes Dans cet exemple, nous constatons que le client veut connaître le coût des taxes d’aéroport. L’opérateur semble avoir compris ce que cherchait à savoir le client, mais ce qui est intéressant à remarquer est la façon dont cet échange se déroule. En effet, le client n’utilise pas directement le mot taxe mais il utilise droit et prix. Le client semble alors utiliser un vocabulaire qui lui est propre, en fonction des connaissances qu’il possède. L’opérateur semble alors se rendre compte que le client n’utilise pas le terme approprié à la situation. Et nous nous apercevons également que l’opérateur n’est pas totalement sûr de ce qu’il a déduit. Il attend le terme précis taxe pour pouvoir répondre à la requête du client, vu que droit et prix ne sont que des termes s’approchant de taxe. Il participe alors à la mise en place d’un terrain commun, en cherchant à découvrir le terme qu’il attend : il demande alors au client si c’est bien de taxe que l’on parle ici en lui posant la question des taxes ?. Ce n’est que lorsque le client confirme que l’opérateur sait réellement ce qu’attend le client. Or, ce processus nous parait intéressant pour comprendre en partie comment se passe la co-construction d’un vocabulaire commun, l’opérateur attendant des termes techniques, et le client utilisant ses propres termes. Figure 18 Modélisation de l’inter-compréhension Nous voulons ainsi pouvoir changer les concepts non reconnus par la machine en cherchant les concepts les plus proches, et en proposant une liste de concepts probables, qu’il faudra pouvoir valider par le dialogue. Ce phénomène semble assez présent dans les dialogues, où nous cherchons souvent à découvrir ce que « pense » l’autre, en utilisant le sens des mots pour les rapprocher. Nous verrons alors dans une autre partie de ce rapport 20 la manière dont nous avons concrètement réutilisé ce phénomène, ainsi que les avantages qu’il permet lors du dialogue homme-machine et la co-construction du sens. Nous reviendrons un peu plus en détail sur la façon dont a été mis en place le terrain commun entre l’utilisateur et la machine dans la dernière partie de ce rapport, en nous intéressant à l’application informatique réalisée. 20 32 Chapitre 4 : Application informatique 3.3 Construction des tables Anadia 3.3.1 Objectifs Afin de pouvoir valider nos théories concernant notre problématique, et notamment notre travail sur les problèmes de la recherche d’un terrain commun au cours du dialogue, nous nous devions tout d’abord de construire une hiérarchie de tables en nous basant sur le modèle Anadia. Nous nous sommes ainsi basé sur les exemples extraits du corpus Air France afin de pouvoir avoir une hiérarchie de concepts que nous pourrions utiliser au cours du dialogue homme-machine. Notre objectif était double : • Chercher à décrire au mieux le domaine de la réservation de billets au niveau des concepts qui nous intéressaient pour réaliser un jeu de test. Notre objectif n’était bien entendu pas d’avoir une modélisation la plus exhaustive possible, mais une hiérarchie de table assez conséquente pour pouvoir mettre en place nos calculs. • Enrichir (et modifier) au fur et à mesure notre modèle hiérarchique pour pouvoir au final tendre vers une modélisation satisfaisante. La conception du modèle devait se faire de manière incrémentale et expérimentale, les jeux de test devant guider le modèle vers une modélisation de plus en plus fine. Nous avons alors commencé par chercher les différents concepts21 qui seront présents au sein de la hiérarchie. Les concepts ont été choisis par rapport à leur particularité au niveau du sens : • Concepts « utilisateur » : nous avons cherché les concepts pouvant poser problème lors de la réservation de billets dans une agence de voyage, ce que les utilisateurs manipulent lors de leurs requêtes au système. En fin de compte, ce sont des concepts que la machine ne manipule pas pour réaliser les tâches demandées, puisqu’ils n’appartiennent pas à son langage technique. • Concepts « technique » : nous avons cherché les concepts manipulés par la machine correspondants aux concepts de la tâche. Ce sont ces concepts qui permettent à la machine de réaliser la tâche demandée par les utilisateurs. Nous avons alors choisi de rassembler au sein d’une même hiérarchie ces différents concepts qui seront manipulés par le système. Les concepts les plus proches ont été rassemblés dans des tables. Nous avons nous même choisi l’emplacement des concepts dans les différentes tables. Nous avons regroupé les concepts qui nous semblaient les plus proches sémantiquement au sein d’une même table, ce qui n’engage qu’une vision de la hiérarchie, d’autres points de vue étant possibles. Et ce n’est qu’une fois les tables trouvées que nous avons défini les différents attributs (ou sèmes) caractérisant chaque table (et donc chaque concept). L’idée finale étant d’avoir des attributs les plus pertinents, en permettant une description assez étendue des concepts, tout en étant assez précis pour les différencier. Nous voulions avoir des attributs pertinents en termes de différenciation, l’essence même du modèle Anadia, et non en termes de description. Nous nommons « concept » ce qui s’apparente aux sémèmes dans le modèle Anadia, afin de faire directement le lien entre l’idée de concept dans le modèle développé par Lehuen et Lemeunier, et l’idée de sémème partagée notamment par Beust et Rastier. 21 33 Chapitre 4 : Application informatique Nous avons ainsi cherché ce qui différenciait les concepts au niveau du sens. Par exemple, nous avons choisi de relier au sein d’une même table les concepts Bus et Navette. Ces deux concepts sont sémantiquement proches, et nous avons choisi de les regrouper dans la table //Transport//. La particularité de ces deux concepts est que Bus fait partie des concepts manipulés par l’utilisateur, alors que Navette est un concept manipulé par la machine. Différents sèmes composent la table, et permettent de différencier, ou de rapprocher les concepts entre eux. Prenons l’exemple de deux sèmes : • Le sème trajet, comportant les valeurs « Identique » et « Variable », permet aux concepts Navette et Bus de s’actualiser avec « Identique », ce qui a pour effet de les rapprocher. • Le sème public, comportant les valeurs « Variable » et « Ciblé », permet au concept Navette de s’actualiser avec Large et le concept Bus avec « Ciblé », ce qui permet de les différencier. Finalement, nous essayons de trouver ce qui caractérise chaque concept, mais surtout ce qui permet de les différencier pour pouvoir créer les sèmes correspondants. Ainsi, si nous allons plus loin dans ce raisonnement de différenciation, nous pouvons nous demander s’il est réellement judicieux d’utiliser le sème trajet puisque que finalement il ne semble servir qu’à décrire les concepts Navette et Bus (Les deux concepts actualisent la même valeur Identique). Cependant, nous pouvons voir, dans la figure ci-dessous, que d’autres concepts sont présents dans la table. Nous avons ainsi le concept Taxi qui actualise la valeur Variable de l’attribut trajet. Enfin, nous avons cherché à insérer les tables au sein d’une hiérarchie. Sans cette hiérarchie, notre modèle n’aurait pas été complet, et nous n’aurions pu mettre en place nos différents calculs. La hiérarchie de tables mise en place est donc créée en amont du dialogue, et non au cours du dialogue. Nous précisons qu’il n’y a aucun apprentissage, d’évolution de la hiérarchie au cours du dialogue : il est possible de modifier ces tables a posteriori, en analysant les échanges, et en affinant la description, mais nous ne nous sommes pas intéressés à la façon dont ces tables seraient modifiées « automatiquement » suite aux différentes interactions entre l’homme et la machine. 3.3.2 Modélisation réalisée La figure suivante présente le modèle Anadia que nous avons construit dans l’optique de réaliser notre jeu de tests. Il se présente sous la forme d’une hiérarchie de tables. Figure 19 Explication de la modélisation des tables selon le modèle Anadia Cette figure permet alors de présenter les différentes notations utilisées pour présenter notre hiérarchie de tables. 34 Chapitre 4 : Application informatique Figure 20 Modélisation de la réservation dans une agence de voyages Le modèle construit nous satisfait par rapport à nos objectifs, dans le sens où notre hiérarchie de tables est suffisamment complète pour pouvoir commencer à mettre en place nos 35 Chapitre 4 : Application informatique tests, tout comme la description des concepts au moyen des attributs qui nous semble assez précise. Afin de bien visualiser sur la figure les concepts manipulés par l’utilisateur et ceux manipulés par la machine, nous avons fait précédé les concepts de l’utilisateur par le signe « _ » devant chaque nom de concept. Nous rappelons que ce modèle n’est bien entendu pas représentatif d’une modélisation ontologique du domaine de la réservation dans une agence de voyages, mais description contextuelle des concepts par rapport à l’utilisation que nous voulons faire du modèle. Il n’a ainsi aucune vocation de généricité, même par rapport au contexte dans lequel il est utilisé. D’autres modélisations sont possibles, voire même envisageables, pour une représentation beaucoup plus précise des concepts manipulés. Cette modélisation ne représentait finalement que le domaine de la réservation au sein d’une agence de voyages. Or, comme énoncé dans la problématique, nous voulions aller plus loin que l’idée de synonymie, et essayer de voir si ce modèle pouvait nous permettre de donner des réponses par rapport à des jeux de rhétorique, et notamment au niveau de la métaphore. Nous avons donc décidé de chercher un exemple de métaphore que l’on pourrait utiliser dans notre jeu de tests. Cependant, nous n’avons pas réussi à extraire un exemple concret de métaphore de notre corpus de dialogues. Nous avons donc du en inventer un, et l’avons emprunté à la littérature : Combien coûte un billet pour Paris à Tunis dans votre monstre volant ? Nous avons alors pris le concept monstre volant pour faire allusion au concept de l’avion, et ainsi pouvoir mettre en place notre calcul de proximité. En effet, la machine ne peut prendre de décision sans cette étape intermédiaire de recherche d’un concept de la tâche. Elle ne connaît pas le concept monstre volant et ne peut donc faire le rapprochement avec avion. Même en inférant sur ce que pourrait être ce concept, sans avoir de connaissances à priori, elle ne pourrait que supposer le concept avion comme elle pourrait supposer un billet de bus ou encore de train, ce qui est totalement plausible dans le domaine de la réservation dans une agence de voyages. Nous devions ensuite nous intéresser plus précisément à ce que représentait la métaphore de monstre volant, et notamment son domaine d’application. En effet, monstre volant ne peut faire partie du domaine de la réservation dans une agence de voyages directement, puisque la métaphore projette un concept d’un domaine de représentation dans un autre domaine de représentation pour jouer avec le sens des mots22. Nous devions ainsi nous intéresser au domaine premier de ce concept, et devions ainsi modéliser au moyen des tables Anadia une partie du domaine du fantastique, en essayant de faire ressortir les points communs et les différences23 avec le domaine de la réservation. Nous avons ainsi réalisé le modèle Anadia correspondant, que nous présentons dans la figure ci-dessous. Pour de plus amples informations sur la métaphore, nous vous renvoyons à la partie 2.1. Une approche interprétative ainsi qu’au texte de Gardes-Tamine [GAR 05]. 23 Ce sont les attributs (sèmes) qui nous permettent de réaliser ces rapprochements de domaines. 22 36 Chapitre 4 : Application informatique Figure 21 Modélisation du monde fantastique Ce modèle reste pour l’instant simpliste24, mais va nous permettre de réaliser nos premiers tests sur cette figure de style. Les attributs Vitesse et Milieu nous sont apparus comme les sèmes étant en rapport avec le domaine de la réservation. Nous avons volontairement écarté d’autres sèmes plus spécifiques au domaine du fantastique puisqu’ici ils n’avaient aucun intérêt dans notre modélisation et dans nos calculs. Nous avons également choisi de modéliser d’autres domaines d’application pour essayer de trouver de nouvelles métaphores. Nous nous sommes alors penchés sur le domaine de l’informatique, et plus précisément sur l’imprimante qu’il nous arrive d’humaniser. Nous avons ainsi choisi l’exemple : Je voudrais savoir si l’imprimante a mangé le papier. En effet, cette métaphore est assez fréquente dans le domaine de l’informatique, notamment en cas de panne, où le concept « Manger » se substitue au concept de « Bloquer », l’imprimante ayant tenté d’imprimer des feuilles, mais serait rester bloquer avec les feuilles à l’intérieur. Nous avons alors modélisé une partie du monde de l’informatique. Figure 22 Modélisation du domaine de l’informatique Nous nous sommes également intéressés au domaine de la nutrition. Figure 23 Modélisation du domaine de la nutrition Il sera intéressant par la suite de le faire évoluer si l’on veut notamment réaliser des tests beaucoup plus poussés, voir même des tests sur d’autres figures de style (nous pouvons penser à la métonymie par exemple). 24 37 Chapitre 4 : Application informatique L’idée finale est de pouvoir faire le rapprochement entre des concepts qui ne semblent pas proches au départ, et de réussir à en extraire des attributs communs au moyen du modèle Anadia pour montrer leur proximité. Notre hiérarchie de tables mise en place, nous nous sommes focalisés sur les différents calculs que nous devions mettre en place pour réaliser le rapprochement de concepts. Nous avons donc cherché ce qui caractérisait la hiérarchie, et ce qui pourrait influer dans les différents calculs. 3.4 Calcul de proximité des concepts Nous avons cherché la façon de mathématiser le rapport de proximité entre les concepts inscrits dans une hiérarchie du modèle Anadia. En effet, nous avons pu constater qu’un des liens de proximité privilégié par le modèle développé par Beust est la topique, et notamment celle à un trait près. Nous trouvions cependant insuffisant de n’avoir que ce type de rapport entre les concepts, tout d’abord parce que cette proximité est surtout visuelle et ne permet pas une vision hiérarchique de la proximité, mais une vision limitée à la table. Nous constatons qu’il n’y a pas réellement de résultats quantifiables au niveau de la proximité d’un concept par rapport à un autre, mais plus une relation d’éloignement. Nous avons alors choisi de définir des calculs précis à mettre en place pour pouvoir donner des valeurs numériques à chaque concept de la hiérarchie, en définissant la proximité que chacun occupe par rapport au concept recherché. Nous voulions mettre en place des calculs différents selon la place occupée par le concept au sein de la hiérarchie. En effet, il apparaissait impossible d’avoir un calcul global efficace car les concepts ne se trouvent pas au même niveau (au sein d’une même table, voire au sein d’un même domaine, avec la métaphore par exemple). Nous avons donc cherché à rendre compte de ces différences en proposant un calcul spécifique au niveau de concepts d’une même table, d’une table différente mais d’un même domaine, et enfin de domaines totalement différents. 3.4.1 Au niveau de la table Nous nous sommes tout d’abord intéressé au calcul réalisé au sein d’une même table. Nous nous concentrons au niveau de la table car nous avons constaté que plus le nombre d’attributs décrivant les concepts (sémèmes) est élevé, plus les concepts semblent proches. Nous nous sommes inspirés de l’idée de topique (et notamment la topique « à un trait près ») développée par Beust, en cherchant faire ressortir de manière numérique de la proximité des concepts. Nous nous apercevons que plus le nombre de traits en commun est élevé, plus les concepts apparaissent sémantiquement proches. Il serait même possible de parler de synonymie, pour des concepts vraiment très proches (nombre de sèmes communs très élevé). L’inverse semble également vrai. Prenons l’exemple25 des concepts « scalpel » et « bistouri », qui, dans le domaine de l’état physiologique, permet d’actualiser la valeur vivant de cet attribut pour « scalpel », et mort pour « bistouri ». Dans cet exemple, « scalpel » et « bistouri » sont totalement différents, par rapport à la représentation que nous voulions en faire. En effet, avec d’autres sèmes, ces deux concepts ne sont peut être pas opposés, mais dans le cadre du contexte dans lequel nous l’utilisons, nous nous apercevons qu’ils n’ont aucun trait en commun, et que nous ne pouvons donc faire le rapprochement entre « bistouri » et « scalpel ». Il ne serait pas judicieux de mettre « scalpel » comme un synonyme de « bistouri » puisque rien ne nous indique au niveau de la sémantique qu’ils sont proches. A forteriori, si nous prenons l’exemple des concepts « avion » et « vol » avec les attributs Trajet, Public, Horaire, Milieu, Prix et Motorisé où seules valeurs de l’attribut Motorisé 25 Exemple déjà développé précédemment, voir figure 14. 38 Chapitre 4 : Application informatique permettent de différencier les deux concepts (Oui pour « avion » et Non pour « vol »), ce qui finalement rend les concepts sémantiquement proches dans le contexte dans lequel il a été défini. Figure 24 Calcul au niveau de la table Nous avons choisi un calcul assez simple mais qui rend bien compte de la proximité des concepts : la machine cherche dans la table du concept posant problème un concept de la tâche, et cherche à connaître le nombre de sèmes en commun dans celle-ci. Une fois ce nombre trouvé, il est divisé par le nombre total de sèmes de la table pour obtenir un ratio, donnant une valeur au concept trouvé. Pour bien comprendre les calculs mis en jeu, nous allons expliciter la façon dont est calculée la proximité. Par exemple pour le concept « VOL » et le concept « AVION », nous constatons que six valeurs d’attributs sont communes dans la table //Transport//, qui possède sept attributs au total. Nous avons ainsi divisé 6 par 7, ce qui nous donne bien 0,86. Figure 25 3.4.2 Exemple calcul proximité concepts « Avion » et « Vol » Au niveau de la hiérarchie Nous l’avons exprimé précédemment, nous ne voulions pas nous arrêter aux calculs au sein d’une même table, mais essayer d’élargir les choix de concepts aux concepts plus éloignés dans la hiérarchie, et notamment ceux se trouvant dans un même domaine (par exemple la réservation de billets) mais n’ayant pas vraisemblablement de liens directs (tables différentes). Pour mettre en place le calcul, nous nous sommes basé sur deux idées : • La comparaison, comme pour le calcul dans une même table, des traits en commun entre les deux concepts analysés. Nous pouvons alors voir les attributs qui les rapprochent sémantiquement. • La recherche des traits en commun au niveau de la branche de départ. En effet, tout d’abord Beust parle d’attributs au niveau de la classe26 pour un concept. Or en poussant cette idée plus loin, nous voulions poursuivre la proximité des concepts au niveau de l’arborescence. Figure 26 Calcul au niveau hiérarchique Le calcul rend compte des deux idées que nous venons de développer. Tout d’abord nous calculons les attributs en commun au niveau des tables des deux concepts, que nous divisons par le nombre total d’attributs des deux tables. Puis nous remontons dans l’arborescence pour trouver la table dans laquelle se trouvent les concepts à la base de leur 26 Table directement supérieur dans l’arborescence 39 Chapitre 4 : Application informatique arborescence. Une fois des concepts trouvés, nous cherchons les traits en commun et les divisons par le nombre total d’attributs27. Nous avons alors deux ratio de réalisés (pour les attributs en commun et l’arborescence), que nous divisant ainsi par deux pour en faire la moyenne et avoir un score compris entre 0 et 1. Intéressons nous au cas de « PREMIERECLASSE » et de « AVION ». Ils se trouvent dans des classes différentes, le calcul se situe là au niveau de la hiérarchie et non plus au niveau de la classe. Le premier calcul trouvé est celui des valeurs d’attributs communes par rapport au nombre total d’attributs des deux tables, ce qui nous donne ici 2 divisé par 8, soit 0,25. A cela s’ajoute le calcul du concept de base de la hiérarchie (en remontant l’arborescence, nous nous retrouvons à « VOL » pour le concept « PREMIERECLASSE »). La table de base est alors « Transport » (plus haute dans l’arborescence) et nous allons comparer « AVION » à « VOL », ce qui nous donne 0,86. Finalement, nous additionnons les deux résultats obtenus pour en faire la moyenne, ce qui donne (0,25+0,86)/2, soit 0,55. Figure 27 Exemple calcul proximité concepts « Avion » et « Première classe » 3.4.3 Au niveau du domaine Afin d’aller plus loin dans ce calcul de proximité, nous voulions essayer de voir s’il était possible de faire le rapprochement entre deux concepts de domaines différents, mais liés par un sens proche (typiquement le cas de la métaphore). Nous sommes restés dans la même lignée que les autres calculs précédents pour essayer de rendre compte d’un score. En effet, bien que les domaines soient différents, nous restons sur le principe que les concepts se rapprochent grâce aux valeurs des attributs. Et bien que nous soyons dans un domaine différent, les tables Anadia rendent permettent de définir le sens d’un concept par rapport à un contexte. Les descriptions dans les tables (les traits sémantiques) sont donc faites de la manière dont nous voulons que le sens soit rendu. En effet, le concepteur des tables issues du modèle Anadia choisit les attributs et les valeurs, il peut ainsi orienter le sens d’un concept. Figure 28 Calcul au niveau du domaine Le calcul se base alors sur le nombre de traits en commun des deux concepts. Le calcul ressemble aux précédents, à la différence que l’on ne divise pas ce nombre par le nombre total d’attributs des deux tables, mais nous le divisons en deux, en prenant d’une part la calcul du nombre de traits en commun par le nombre d’attributs de la table du concept 1, et d’autre part le calcul du nombre de traits en commun par le nombre d’attributs de la table du concept 2. Une fois ces deux calculs obtenus, nous les additionnons et les divisons ensuite par 2 pour avoir une moyenne des deux calculs, et ainsi assouplir le score obtenu. Il aurait été possible de diviser le nombre de traits en commun par rapport au nombre total des attributs des deux tables, mais nous nous sommes rendus compte que le score était plutôt faible (du au fait de domaines différents). Pour bien comprendre le calcul, nous vous reportons aux exemples traités dans la quatrième partie de ce rapport. 27 40 Chapitre 4 : 4 Application informatique 4.1 Réalisation de l’application 4.1.1 Outils utilisés Pour mettre en place les différents tests que nous allions effectuer pour vérifier nos théories, nous avons utilisés différents outils pour que l’intégration à l’analyseur TALENT se fasse facilement et qu’il ne remette pas en cause la structure existante de l’analyseur. Nous devions tout d’abord chercher à intégrer les tables Anadia dans le dialogueur. Un outil concernant l’aide à la création du modèle Anadia existait déjà, développé par Vincent Perlerin, maître de conférences en Informatique à l’Université de Caen. Le logiciel qu’il a développé en langage Java permet de construire de façon interactive les tables à travers une interface. L’avantage de cet outil est qu’il est très facile de créer une hiérarchie modélisée au moyen du modèle Anadia, et surtout qu’il est possible de récupérer les tables créées sous format XML28. Nous pouvions ainsi aisément traiter les données fournies sous format XML puisqu’il est possible a posteriori de manipuler les données comme nous le désirons, grâce par exemple à XSLT29. Nous n’avions donc pas à créer un nouvel outil pour construire nos tables, ni à subir toutes les contraintes que la mise en place d’un tel logiciel nécessite, notamment par rapport au temps important qu’il faut. Nous devions programmer en langage CLIPS le module que nous voulions mettre en place, puisque le dialogueur a été construit avec ce langage de programmation. Nous avons alors utilisé l’environnement XCLIPS30. Cet environnement nous a permis de faciliter la programmation et nos tests en langage CLIPS. Finalement, il nous fallait récupérer les données du modèle Anadia construit avec l’outil de Perlerin, pour qu’elles puissent être utilisées en langage CLIPS, et donc transformées en faits. Nous avons choisi de rendre ce passage (document XML / création de faits) automatique grâce à l’utilisation d’XSLT, que nous avons précédemment introduit. Nous avons alors utilisé la librairie Xalan, qui possédait l’avantage d’être « open-source » et de permettre l’utilisation du langage XML de requête XPath 31. 4.1.2 Structure des données Afin de pouvoir utiliser le modèle Anadia dans le dialogue, nous avons dû organiser les données (concepts, tables, attributs…) que nous allions utiliser. Pour mieux comprendre la manière dont les données sont manipulées, la figure suivante représente leurs structures qui seront implémentées dans le système. Nous avons choisi de schématiser les structures utilisées au moyen du digramme de classe de la méthode UML, qui nous semblait beaucoup plus simple à comprendre et à commenter que du code écrit en langage CLIPS. « Extended Markup Language », langage qui peut être utilisé pour décrire des données. « eXtended Stylesheet Language Transformations », permettant des transformations de fichiers XML. 30 XCLIPS est une interface graphique pour le langage CLIPS, permettant à l’utilisateur de gérer plus facilement l’exécution de programmes CLIPS (affichage d’un agenda de faits, affichage des instances…). 31 XPath est une syntaxe pour désigner une portion d’un document XML. 28 29 41 Chapitre 4 : Figure 29 Modélisation de la structure Anadia Nous avons alors une vision globale de ce qui a été implémenté dans le dialogueur au niveau de la structure du modèle Anadia. Nous ne pouvions cependant intégrer ce modèle tel quel, sa transcription en langage CLIPS étant impossible directement. Nous avons tout d’abord choisi de séparer les données en trois parties, pour plus de clarté et surtout une recherche plus efficace dans la hiérarchie de tables et de concepts : La première partie s’intéresse au concept : un concept se caractérise par un identifiant, son appartenance au lexique de la tâche, un nom de domaine, une table, des valeurs d’attributs qui lui correspondent ainsi qu’un concept père (pour la hiérarchie, donc finalement non obligatoire). Nous pouvons ainsi accélérer les recherches pour les calculs, et notamment ici pour les calculs au niveau de concepts issus d’une même table. En effet, nous ne pouvons facilement nous focaliser sur les valeurs des attributs qui sont dans la même table, sans avoir à nous intéresser à d’autres valeurs rendues inutiles (comme par exemple le nom des attributs). La seconde partie comprend la table et les attributs associés, pour connaitre à tout instant les attributs composant une table, ce qui permet notamment de réaliser nos calculs, opérations, au niveau de la hiérarchie (recherche d’attributs en communs, calcul du nombre d’attributs total…) de manière plus rapide. La dernière partie nous permet d’attribuer les valeurs aux noms d’attributs, et donc de pouvoir comparer les valeurs des concepts par rapport aux attributs communs. Nous présentons maintenant la structure CLIPS que nous avons mis en place dans le dialogueur. Nous avons tout d’abord la structure d’un concept (sémème) d’une table Anadia. (deftemplate MAIN::sememe "Les sémèmes (concepts) Anadia" (slot idsememe) ; identifiant (multislot semes) (slot idtable) (slot sememepere(default ---)) (slot tache(default TRUE)) ; permet de savoir si le concept fait partie de la tâche ou non (slot domaine) ; permet de connaitre le domaine d'interprétation du sémème (notamment pour les figures de style) ) 42 Chapitre 4 : Puis voici la représentation d’un attribut : (deftemplate MAIN::attribut "Les attributs Anadia" (slot idattribut) ; identifiant (multislot idsemes) ; les différentes valeurs associées ) Finalement les tables : (deftemplate MAIN::table "Les tables Anadia" (slot idtable) ; identifiant (multislot attributs) ) Nous pouvons alors prendre l’exemple du concept « Distance » de la table //Classement//, qui prend trois attributs : Hiérarchie, Tarification et Destination. Voici les attributs : (deffacts MAIN::attribut-Hierarchie (attribut (idattribut Hierarchie)(idsemes oui non)) ) (deffacts MAIN::attribut-Destination (attribut (idattribut Destination)(idsemes oui non)) ) (deffacts MAIN::attribut-Tarification (attribut (idattribut Tarification)(idsemes oui non)) ) La table : (deffacts MAIN::table-Classement (table (idtable Classement)(attributs Hierarchie Tarification Destination)) ) Et pour terminer le sémème : (deffacts MAIN::sememe-DISTANCE (sememe (idsememe DISTANCE)(semes oui non oui)(idtable Classement) (sememepere VOL)(tache TRUE)(domaine Agence_de_voyage)) ) 4.2 Tactiques dialogiques Comme nous avons pu le voir précédemment, différents calculs ont été mis en place, et permettent de donner une idée numérique de la proximité d’un concept. Cependant, sans réelle stratégie évoluée ni analyse du calcul trouvé, nous ne pouvons rendre compte de la valeur effective d’un concept. En effet, nous pourrions prendre des stratégies simplistes qui consisteraient par exemple à prendre le concept ayant la valeur la plus élevée. Or nous nous apercevons qu’aucune différenciation ne serait faite par rapport à un concept ayant une valeur élevée (s’approchant de 1) et une autre assez faible (s’approchant de 0), si ce n’est leur valeur maximum constatée dans un certain contexte. Par exemple, si nous avons un concept A ne faisant pas partie des concepts de la tâche, et un concept B, concept de la tâche le plus proche au niveau du calcul (calcul le plus élevé). Peu importe la valeur du calcul de B, comme il est le plus élevé, on le choisit, ce qui ne semble pas forcément logique puisqu’un calcul plus faible devrait entrainer une certitude plus faible, la proximité entre les concepts étant assez éloignée. Nous avons donc décidé de mettre en place des tactiques dialogiques selon la valeur du concept calculé, et donc finalement selon la proximité entre les concepts. 43 Chapitre 4 : 4.2.1 Définition de seuils Afin de mettre en place des tactiques dialogiques, nous voulions définir des paliers permettant de ranger les concepts. L’idée est de « catégoriser » les concepts selon la valeur obtenue. Ces rangements sont réalisés par rapport à la valeur trouvée lors du calcul de la proximité d’un concept. Ainsi, nous avons choisi de ranger les concepts par rapport à deux seuils : • Seuil de décision : ce seuil représente la limite qu’il faut franchir pour complètement assurer que le concept recherché est bien celui trouvé. • Seuil d’acceptabilité : ce seuil représente la valeur minimum à atteindre pour que le concept que l’on vient de calculer soit pris en compte (sinon il est rejeté). Figure 30 Schéma stratégie de décision L’intervalle de calcul varie entre 0 et 1. Lorsque l’on se rapproche de zéro, les deux concepts (celui recherché et celui trouvé) sont éloignés sémantiquement (peu de traits sont en commun, voire même aucun). Et inversement, lorsque l’on se rapproche de 1, les concepts sont très proches. L’utilisation de ces seuils nous permet de faire apparaître trois catégories : • 0 < Concept < Seuil d’acceptabilité : nous nous trouvons dans la cadre de « concepts refusés », catégorie dans laquelle nous mettons les concepts ayant peu de traits en commun. • Seuil d’acceptabilité ≤ Concept < Seuil de décision : nous nous trouvons dans une catégorie intermédiaire. Nous parlons de « concepts indécis » pour rendre compte d’une proximité trouvée mais non évidente (on hésite entre le refus et l’acceptation). • Seuil de décision ≤ Concept < 1 : nous nous trouvons dans la catégorie des « concepts acceptés », regroupant un score suffisant pour être considérés comme des concepts très proches. Volontairement, nous n’avons pas quantifié le seuil de décision et le seuil d’acceptabilité. En effet, d’une part nous n’avions pas pu expérimenter sur un volume de données assez important nos propositions pour pouvoir affirmer de manière certaine les niveaux des seuils, et d’autre part le nombre de facteurs influant sur les seuils est trop important pour être précisé. Ainsi, le niveau de description du modèle Anadia, le niveau d’aboutissement du dialogueur ou encore la façon dont nous voulons que le système réagisse (par exemple être plus strict au niveau du choix des concepts, donc relever le seuil 44 Chapitre 4 : d’acceptabilité…) peuvent influer sur les seuils. Nous avons décidé de laisser le choix aux concepteurs du dialogueur pour la définition de ces seuils. Il n’est cependant pas exclus d’essayer de trouver ces valeurs de manière plus expérimentale, en cherchant vraiment à trouver ces limites (décision, indécision, rejet) au cours de dialogues. Nous avons pour notre part utilisé des valeurs qui nous semblaient justes pour nos réaliser notre jeu de tests, que nous détaillerons dans la partie suivante de notre rapport. 4.2.2 Déroulement des tactiques dialogiques La catégorisation des concepts en fonction du score obtenu lors du calcul de la proximité permet de prendre des décisions de manière plus précise. Nous ne nous trouvons plus dans le cas d’une stratégie globale, mais plutôt dans le cas d’une stratégie prenant en compte d’une part les concepts les uns par rapport aux autres (une comparaison entre les différents calculs obtenus) mais aussi d’autre part la valeur obtenue suite au calcul de proximité d’un concept par rapport à un autre. Afin de rendre compte du déroulement de la stratégie du dialogueur pour la prise de décision lors de la détection d’un concept ne faisant pas partie de la tâche, nous avons abouti au schéma suivant (la scénarisation rendue compte dans la figure s’inspire du diagramme d’activité d’UML) : Figure 31 Déroulement choix concept utilisateur/tâche 45 Chapitre 4 : En premier lieu, le dialogueur récupère un énoncé émis par un utilisateur et l’analyse. Cette phase d’analyse de l’énoncé comprend notamment la détection des différents concepts le composant. Une fois les concepts détectés, le dialogueur cherche un scénario adapté pour créer la hiérarchie de concepts32. Cette étape nous permet en quelque sorte de contextualiser les concepts, puisqu’ils prennent leur sens au sein d’une hiérarchie. Ils pourraient, par exemple, ne pas avoir le même sens s’ils se trouvaient dans une hiérarchie différente. Si un scénario existe, l’arborescence de concepts est utilisée, sinon le dialogueur demande à l’utilisateur de reformuler son énoncé. L’analyse effectuée et le contexte placé, le dialogueur cherche ensuite les concepts ne faisant pas partie de la tâche. Si tous les concepts font partie de la tâche, alors l’action demandée par l’utilisateur est effectuée, puisque comprise par la machine. Sinon, dans le cas contraire, une tactique dialogique est mise en place. Le concept posant problème est extrait, et un calcul est effectué au sein des tables du modèle Anadia afin de faire ressortir les concepts les plus proches du concept recherché. Et c’est à partir de ce moment, et en fonction des résultats des calculs, que la machine va mettre en place une tactique dialogique. Dans tous les cas, c’est le concept présentant le score le plus élevé qui est choisi. Plusieurs cas de figure sont alors possibles (en nous appuyant sur les seuils mis en place33) : • Concepts acceptés : la valeur du calcul du concept est supérieure au seuil de décision, le remplacement des concepts est direct : on change le concept posant problème par celui de la tâche trouvé par calcul dans la hiérarchie de table Anadia. La réponse à l’énoncé de l’utilisateur est ensuite réalisée avec le nouveau concept trouvé. • Concepts refusés : la valeur du concept se situe en dessous du seuil d’acceptabilité, la machine décide de ne pas retenir le concept calculé. En effet, sa valeur est trop faible, la machine décide donc de ne pas échanger le concept et demande à l’utilisateur de reformuler son énoncé. La machine ne prend pas le risque de prendre une mauvaise décision. • Concepts indécis : la valeur du concept se trouve entre seuil de décision et le seuil d’acceptabilité, nous ne pouvons donner une réponse de façon définitive (confirmer ou infirmer). Le système décide alors de poser une question à l’utilisateur, pour savoir si le concept calculé est bien le concept dont le sens se rapproche le plus (ou non) du concept de départ. Deux possibilités par rapport à la réponse de l’utilisateur : o L’utilisateur répond négativement, le concept est rejeté. Afin de donner une plus grande liberté dans la recherche de concept, la tactique est relancée, et le futur choix de concept sera orienté par la valeur du nouveau calcul. Nous avons choisi de limiter le nombre de relances de la tactique. Ce choix est laissé à la discrétion du concepteur du dialogueur. S’il ne reste aucun concept trouvé, ou si le nombre de relances maximum est épuisé, nous nous trouvons dans le cas de figure d’un concept refusé. o L’utilisateur répond positivement, la recherche d’un concept s’arrête et le concept posant problème est remplacé, et l’on se retrouve dans le cas de figure d’un concept accepté. 32 33 La figure 2 permet de bien comprendre l’idée de hiérarchie de concepts. La figure 30 présente ces différentes parties. 46 Chapitre 4 : Finalement, nous avons cherché à aller plus loin que la simple idée de récupérer le concept possédant le score le plus élevé pour calculer la proximité entre les concepts. En nous inspirant des théories existantes sur le terrain commun et les constations faites à partir de corpus de dialogues, nous avons essayé de rendre l’interaction plus importante entre la machine et l’utilisateur, dans l’idée de tendre vers un dialogue plus naturel. 4.3 Tests réalisés Afin de donner plus d’importance aux idées que nous avons développées, et finalement nous rendre compte de l’apport dans la construction d’un terrain commun, nous avons réalisé différents tests à plusieurs échelons (tests au niveau du domaine d’application et au niveau de domaines différents). Nous avons choisi des données utilisées pour les seuils et le nombre de concepts maximum (notamment pour le cas de l’indécision) 34 : • Seuil de décision : supérieur à 0,8. • Seuil d’acceptabilité : inférieur à 0,5. • Nombre de concepts maximum : 3. 4.3.1 Au niveau du domaine d’application Nous allons tout d’abord nous intéresser à des tests effectués au niveau d’une même hiérarchie de tables. Nous allons ainsi utiliser des exemples de concepts ne faisant pas partie de la tâche35. Dans l’exemple qui va suivre, nous nous sommes intéressés à deux problèmes de concepts ne faisant pas partie de la tâche dans le même exemple : « avion » et « dégriffé ». M1: Air France bonjour, que puis-je pour votre service ? H2: je voudrais l'avion dégriffé de cette après-midi Nous allons maintenant nous intéresser à la phase de décision du dialogueur, chargée de résoudre les problèmes de conflits au niveau des concepts non compris par la machine. La machine a dans un premier temps trouvé « avion » comme un concept ne faisant pas partie de la tâche. Le système va alors chercher les termes les plus proches (au maximum 3) en parcourant les tables Anadia. ----------------------------------------Décision ------------------------------------------- En recherche de concepts proches --==> Calcul d'un nouveau concept au moyen des tables anadia Concept : PREMIERECLASSE Calcul : 0.553571 <== Fin du calcul d'un nouveau concept ==> Calcul d'un nouveau concept au moyen des tables anadia Concept : BUS Calcul : 0.571429 <== Fin du calcul d'un nouveau concept ==> Calcul d'un nouveau concept au moyen des tables anadia Concept : VOL Calcul : 0.857143 <== Fin du calcul d'un nouveau concept 34 35 Pour plus de précisions, voir partie précédente sur les tactiques dialogiques. Nous pouvons trouver les exemples extraits du corpus dans la partie 3.1 traitant du corpus de dialogue. 47 Chapitre 4 : --- Fin de la recherche --- Le système fournit alors les concepts les plus proches (« PREMIERECLASSE », « BUS » et « VOL »), et les calculs correspondants. Il va alors choisir le concept au score le plus élevé, ici « VOL » avec 0,86. Ce score est supérieur au seuil de décision, le changement sera donc effectif directement. Nous pouvons constater également que tous les concepts extraits ne font pas forcément partie de la table //Transport// où se trouve le concept « avion ». --- Changement Granule AVION#4 avec Concept VOL OK Le système a également détecté un autre problème avec « dégriffé » et va alors chercher les concepts de la tâche les plus proches. --- En recherche de concepts proches --==> Calcul d'un nouveau concept au moyen des tables anadia Concept : BLEU Calcul : 0.562500 <== Fin du calcul d'un nouveau concept ==> Calcul d'un nouveau concept au moyen des tables anadia Concept : AFFRETE Calcul : 0.600000 <== Fin du calcul d'un nouveau concept ==> Calcul d'un nouveau concept au moyen des tables anadia Concept : CHARTER Calcul : 0.800000 <== Fin du calcul d'un nouveau concept --- Fin de la recherche --- Nous nous trouvons devant un autre cas de figure que celui du concept « avion », puisque nous constatons alors qu’aucun concept trouvé n’arrive à dépasser le seuil de décision pour prendre directement la place de « dégriffé ». En effet, le plus haut (« CHARTER ») ne dépasse pas 0.8, mais reste néanmoins supérieur au seuil d’acceptabilité, on peut donc entrer dans le schéma tactique de l’indécision. --- Changement Granule DEGRIFFE avec Concept CHARTER incertaine ### Mise en œuvre de la tactique T5 ### Schéma incident (3,1) ==> Nouvel énoncé "Quand vous parlez de DEGRIFFE, vous parlez de CHARTER ?" ==> Nouvelle attente interactionnelle [confirmation] La machine va donc demander à l’utilisateur si le concept trouvé est bien le concept recherché : M3: Quand vous parlez de DEGRIFFE, vous parlez de CHARTER ? H4: oui Grâce à l’affirmation de l’utilisateur, le système peut remplacer « DEGRIFFE » par « CHARTER ». Le système a alors terminé le remplacement des concepts ne faisant pas partis de la tâche et peut maintenant répondre à la requête du client. ----------------------------------------Décision ----------------------------------------### Schéma régissant (5,0) ==> Nouvel état de la tâche (e2) ==> Nouvel énoncé "Le vol charter de cette APRES-MIDI est le vol A987. Que voulez-vous ?" ==> Nouvelle attente interactionnelle [demande] M5: Le vol charter de cette APRES-MIDI est le vol A987. Que voulez-vous ? 48 Chapitre 4 : Nous allons maintenant nous focaliser sur la stratégie mise en place lors d’une indécision détectée durant le calcul d’un concept. Reprenons notamment l’exemple précédent, en nous intéressant à ce qu’il se serait passé si l’utilisateur n’avait pas accepté le concept « CHARTER » comme correspondant à « AFFRETE ». M3: Quand vous parlez de DEGRIFFE, vous parlez de CHARTER ? H4: non ----------------------------------------Décision ------------------------------------------- Changement Granule DEGRIFFE avec Concept AFFRETE incertaine ### Mise en œuvre de la tactique T5 ### Schéma incident (6,3) ==> Nouvel énoncé "Quand vous parlez de DEGRIFFE, vous parlez de AFFRETE ?" ==> Nouvelle attente interactionnelle [confirmation] Nous constatons que la tactique est relancée (pour rappel il reste « AFFRETE » et « BLEU »). Le système reprend le concept le plus élevé après « CHARTER », et en fonction du score va choisir la stratégie à tenir. Le score se trouvant encore dans le seuil d’indécision, la même stratégie est conservée. M6: Quand vous parlez de DEGRIFFE, vous parlez de AFFRETE ? H7: non ----------------------------------------Décision ------------------------------------------- Changement Granule DEGRIFFE avec Concept BLEU incertaine ### Mise en œuvre de la tactique T5 ### Schéma incident (9,5) ==> Nouvel énoncé "Quand vous parlez de DEGRIFFE, vous parlez de BLEU ?" ==> Nouvelle attente interactionnelle [confirmation] Il ne reste plus que le concept « BLEU » de possible. Il est alors proposé à l’utilisateur. M9: Quand vous parlez de DEGRIFFE, vous parlez de BLEU ? H10: oui ----------------------------------------Décision ----------------------------------------### Schéma régissant (11,4) ==> Nouvel état de la tâche (e2) ==> Nouvel énoncé "Le vol de la catégorie bleue de cette APRES-MIDI est le vol A800. Que voulez vous faire ?" ==> Nouvelle attente interactionnelle [demande] M11: Le vol de la catégorie bleue de cette APRES-MIDI est le vol A800. Que voulez vous faire ? H12: Le fait d’avoir accepté conduit le système dans la même situation que l’exemple précédent (lorsque « CHARTER » a été choisi), sauf qu’ici le concept est différent, puisque « BLEU » est utilisé. Fatalement, celui induit une différence dans la réponse, où pour « CHARTER » on parlait du vol A987, alors que pour « BLEU » on parle du vol A800. Nous pouvons à présent nous focaliser sur la manière dont réagit la machine lorsque les concepts de la tâche trouvés n’ont pas un score suffisant pour permettre d’affirmer que c’est un concept relativement proche (au moins au dessus du seuil de d’acceptabilité). 49 Chapitre 4 : M1: Air France bonjour, que puis-je pour votre service ? H2: je voudrais savoir si certains vols de cette après-midi s'arrêtent à Tokyo Nous nous trouvons dans la situation où « arrêtent » (faisant partie du concept « ARRET ») ne fait pas partie des concepts de la tâche. ----------------------------------------Décision ------------------------------------------- En recherche de concepts proches --==> Calcul d'un nouveau concept au moyen des tables anadia Concept : NAVETTE Calcul : 0.000000 <== Fin du calcul d'un nouveau concept ==> Calcul d'un nouveau concept au moyen des tables anadia Concept : NON-STOP Calcul : 0.333333 <== Fin du calcul d'un nouveau concept ==> Calcul d'un nouveau concept au moyen des tables anadia Concept : ESCALE Calcul : 0.333333 <== Fin du calcul d'un nouveau concept --- Fin de la recherche – Le système a, comme précédemment, cherché à trouver un concept s’approchant le plus du concept « ARRET ». Cependant, nous constatons qu’aucun des trois concepts calculés ne dépassent le seuil d’acceptabilité. M3: Je n’ai pas bien compris ce que vous entendez par ARRET#2, veuillez reformuler votre questions. H4: Le dialogueur ne sait que faire devant ce problème, qu’il contourne en demandant à l’utilisateur de reformuler sa demande. 4.3.2 Dans des domaines différents Bien que nous ayons eu plus de résultats (car plus de tests) au niveau d’un domaine d’application, sur lequel nous nous sommes particulièrement intéressé, nous voulions voir, ou au moins apercevoir, le calcul de rapprochement de concepts au niveau de domaines séparés (avec le phénomène de métaphore). Nous avons pris en compte l’exemple de la métaphore avec « monstre volant » comme commenté dans une partie précédent. M5: Le vol charter de cette APRES-MIDI est le vol A987. Que voulez-vous ? H6: Combien coute dans votre monstre volant l'aller-retour pour Paris a Tunis Nous passons par les mêmes phases que précédemment au niveau du dialogueur. ----------------------------------------Décision ------------------------------------------- En recherche de concepts proches --==> Calcul d'un nouveau concept au moyen des tables anadia Concept : BUS Calcul : 0.000000 <== Fin du calcul d'un nouveau concept ==> Calcul d'un nouveau concept au moyen des tables anadia 50 Chapitre 4 : Concept : NAVETTE Calcul : 0.000000 <== Fin du calcul d'un nouveau concept ==> Calcul d'un nouveau concept au moyen des tables anadia Concept : VOL Calcul : 0.642857 <== Fin du calcul d'un nouveau concept --- Fin de la recherche ----- Changement Granule MONSTREVOLANT avec Concept VOL incertaine ### Mise en œuvre de la tactique T5 ### Schéma incident (7,1) ==> Nouvel énoncé "Quand vous parlez de MONSTREVOLANT, vous parlez de VOL ?" ==> Nouvelle attente interactionnelle [confirmation] Nous pouvons donc voir que le seul concept possible pour « monstre volant » est le concept « VOL ». Son score se trouve dans la partie d’indécision de la tactique, un sous dialogue se met ainsi en œuvre. M7: Quand vous parlez de MONSTREVOLANT, vous parlez de VOL ? H8: oui La confirmation entraine ainsi la validation du changement de « monstre volant » par « VOL » et permet ainsi de continuer dans l’analyse de la question de l’utilisateur. Nous avons également étudié une seconde métaphore possible, cette fois-ci dans le domaine de l’informatique. M1: Bonjour, que puis-je pour votre service ? H2: Je voudrais savoir si l'imprimante a mangé le papier S’en suit la phase de décision, avec la détection du concept « MANGER » ne faisant pas partie de la tâche. Le système cherche alors de nouvelles possibilités. ----------------------------------------Décision ------------------------------------------- En recherche de concepts proches --==> Calcul d'un nouveau concept au moyen des tables anadia Concept : ARRETER Calcul : 0.333333 <== Fin du calcul d'un nouveau concept ==> Calcul d'un nouveau concept au moyen des tables anadia Concept : TARIFICATION Calcul : 0.416667 <== Fin du calcul d'un nouveau concept ==> Calcul d'un nouveau concept au moyen des tables anadia Concept : BLOQUER Calcul : 0.666667 <== Fin du calcul d'un nouveau concept --- Fin de la recherche --- Nous avons trois concepts possibles. Le concept au score le plus élevé, ici « ARRETER », est considéré comme le plus proche. --- Changement Granule MANGER avec Concept BLOQUER incertaine ### Mise en œuvre de la tactique T5 « ARRETER » se trouve entre le seuil d’acceptabilité et le seuil de décision. M3: Quand vous parlez de MANGER, vous parlez de BLOQUER ? H4: oui 51 Chapitre 4 : Il est alors possible de valider le changement de concept. Nous avons choisi, pour traiter les métaphores, d’utiliser les tactiques utilisées pour la définition de concepts proches d’un même domaine. En effet, notre objectif était de montrer qu’il était possible de détecter des métaphores. Cependant, il sera intéressant pas la suite de marquer ces métaphores lorsqu’elles sont détectées afin qu’elles puissent avoir leur propre tactique de dialogue. La métaphore est une particularité de la langue, et nous ne pouvons la traiter comme tout rapprochement de concepts, le système doit pouvoir réagir différemment, voir même pourquoi pas lui aussi réutiliser une métaphore pour montrer à l’utilisateur qu’il l’a bien prise en compte. 4.3.3 Complexité du calcul Nous avons cherché à savoir si l’algorithme mis en place pour le calcul de la proximité des concepts était efficace. Pour ce faire, nous avons réalisé différents tests de temps de calcul en fonction du nombre de concepts comparés. Figure 32 Complexité de l’algorithme de calcul Nous nous sommes aperçus que l’algorithme semblait suivre une courbe de type exponentielle. Nous nous trouvons dans le cadre d’un prototype, l’algorithme nous a donc suffit à réaliser nos différents tests. Cependant, il faut garder à l’idée qu’il sera surement nécessaire de revoir l’algorithme, puisque le temps de calcul semble assez long lorsque le nombre de concepts à analyser devient trop grand (ce qui pourra poser problème si nous voulons que le système, plus tard, puisse apprendre automatiquement, puisque le nombre de concepts à analyser sera surement important). 52 Conclusion et perspectives Durant ce stage, nous avons cherché à rendre compte de problèmes liés au dialogue, et notamment sur le terrain commun qui s’établit entre les protagonistes y participent. Nous nous sommes alors penchés sur les difficultés liées à cette inter-compréhension, et avons choisi d’y répondre par l’utilisation du modèle Anadia. Nous avons alors cherché à définir la façon dont pourrait être utilisé ce modèle, ainsi qu’à ses apports concernant notre problématique. Nous nous sommes aperçus que le modèle Anadia semblait réellement répondre à nos attentes, puisque qu’il a été conçu dans l’optique d’une opérationnalisation36, et de façon à ce que des calculs numériques puissent être effectués. En effet, nous avons travaillé sur l’idée de la synonymie, et sur la manière dont les mots (concepts) se rapprochent les uns des autres. Cette proximité semble dans la plupart des cas, pour les humains, naturelle et évidente, mais l’est beaucoup moins pour une machine. Nous nous sommes interrogés sur la façon dont la machine pourrait prendre en compte cette idée de proximité. La mise en place d’un calcul (et donc de valeurs numériques sur les concepts) nous semblait obligatoire (une représentation « mentale » est impossible) pour que la machine se représente cette distance. Ainsi, nous avons choisi l’idée que si l’on veut trouver des concepts proches à un concept, des valeurs numériques seront apposées à ceux-ci et fourniront leur proximité (plus une valeur est faible, plus le concept est éloigné, et inversement). Nous avons alors intégrer le modèle Anadia au modèle existant (intégré dans l’analyseur TALENT). Pour ce faire, nous avons construit une représentation du domaine de réservation dans une agence de voyages (une hiérarchie de tables Anadia) au moyen d’un corpus de dialogues, que nous avons intégré dans l’analyseur TALENT. Nous avons ainsi pu réaliser nos premiers tests, qui nous ont confortés dans l’apport que pouvait fournir le modèle Anadia dans la mise en place d’un terrain commun, et notamment sur la définition d’une proximité entre des concepts. Nous avons même entrevu la gestion de la métaphore grâce au modèle employé, qui, au vu des premiers résultats, semble tout à fait réalisable. Le travail laisse entrevoir certaines possibilités d’évolution, d’autres perspectives de recherche. Nous pouvons tout d’abord penser au problème d’évolutivité du modèle Anadia. En effet, la hiérarchie de tables mis en place semble trop rigide, car comme nous l’avons vu, c’est une tâche qui incombe à l’être humain. Il doit effectuer une analyse (à partir de dialogues réels par exemple), qui permettra ensuite manuellement de créer cette hiérarchie. Or il serait intéressant que le modèle puisse évoluer au cours du dialogue homme-machine, que l’interaction qui se déroule soit défini automatiquement par la machine, qui mettrait à jour le modèle (ajout de tables, modifications de la hiérarchie, ajout de sèmes et de concepts…). Il serait également judicieux de s’intéresser aux calculs mis en place, pour essayer d’affiner la manière dont ceux-ci sont effectués, pour permettre une meilleure précision dans les valeurs de proximité des concepts. Par exemple, il pourrait être utile de s’intéresser aux attributs des différentes tables, qui caractérisent les concepts. Nous n’avons pour l’instant effectué aucune distinction entre les différents attributs mis en place. Or certains de ces attributs ne semblent pas représenter le même poids au sein de chaque table. Par exemple, prenons la table //Transport//, issue de la modélisation de la réservation au sein d’une agence de voyages37, ainsi que les deux attributs Prix et Motorisé. Nous nous apercevons que Prix 36 37 Le modèle est issu de théories linguistiques et adapté aux problématiques informatiques. Voir figure 20. 53 (avec les valeurs « Réduit » et « Elevé ») n’apparaît pas aussi fort au niveau de la différenciation que Motorisé (avec les valeurs « oui » et « non »). En effet, avec les valeurs de Prix, nous restons quand même dans une idée d’argent, bien que le rapport soit différent. Alors qu’avec Motorisé, nous nous trouvons avec un attribut permettant une énorme différence entre les concepts (motorisé ou non). Il apparaitrait donc intéressant de leur fournir un poids, permettant de prendre de façon plus important un attribut qu’un autre, moins discriminant. Il serait intéressant de continuer le travail entrepris sur la métaphore. En effet, nous avons montré, grâce à des exemples, que ce phénomène semblait pouvoir être géré au moyen du modèle Anadia. Cependant, il faudrait chercher à construire différents domaines d’interprétation de façon plus complète, afin de réaliser des tests beaucoup plus importants, pour réellement pouvoir émettre des conclusions complètement satisfaisantes. Il serait même envisageable d’étudier d’autres figures de style, pour chercher à savoir si le modèle peut également aider à leur détection et leur compréhension. Nous pouvons notamment penser à la métonymie, que Baccino [BAC 03] définit ainsi : La différence la plus notable tient au fait que l’expression métonymique est construite à l’intérieur d’un même domaine de connaissance alors que la métaphore est une projection d’un domaine de connaissance sur un autre domaine. Nous avons alors l’impression que le modèle Anadia pourrait résoudre ce phénomène, qui ne semble pas si éloigné de la métaphore. Nous pouvons également continuer à nous intéresser au travail fait sur la métaphore, et notamment sur la réaction du système face à ce phénomène. Nous pensons que le dialogueur pourra réagir différemment, selon une tactique de dialogue adaptée. Enfin, il faudra vraisemblablement revoir l’algorithme de calcul de la proximité des concepts. Comme nous l’avons vu, il ne semble pas optimisé, ni adapté à de gros traitements de données. Or nous voudrions, à terme, avoir les tables du modèle Anadia qui puissent évoluer automatiquement. Vraisemblablement, nous nous trouverons dans le cas d’un modèle contenant plusieurs centaines, voir milliers de concepts. Il faudra donc être capable de trouver des concepts proches rapidement, l’algorithme actuel ne semble pas optimisé pour. Il sera peut être utile de faire intervenir des heuristiques pour trouver les concepts. 54 Bibliographie [BAC 03] Baccino T. (2003), « Métonymies versus métaphores : une histoire de contexte ». In C.Tijus (Ed.), Métaphores et Analogies, p. 183-206, Paris : Hermès. [BEU 98] Beust P. (1998), « Contribution à un modèle interactionniste de la signification. Amorce d’une compétence interprétative pour les machines ». Rapport de thèse de l’université de Caen. [BEU 00] Beust P. (2000), « Pour une modélisation de la référenciation dans le dialogue homme-machine ». Journée de l’Atala du 18 novembre 2000. [CAE 03] Caelen J., Nguyen N.-H. (2003), « Vers une architecture générique de système de Dialogue Homme-Machine ». Conférence internationale Université Joseph Fourier, Grenoble. [ERM 96] Ermine J. L. (1996). « Les systèmes de connaissances », Paris, Hermès. [FOD 86] Fodor J. (1986). « La modularité de l’esprit », Paris, Editions de Minuit. [GAR 05] Gardes-Tamine J. (2005). « Métaphore et synonymie : quelques interrogations », document de travail publié sur http://www.info-metaphore.com. [LAK 85] Lakoff G., Johnson M. (1985). « Les métaphores dans la vie quotidienne », Paris, Editions de Minuit. [LEH 97] Lehuen J. (1997), « Un modèle de dialogue dynamique et générique intégrant l'acquisition de sa compétence linguistique - Le système COALA ». Rapport de thèse de l’université de Caen. [LEH 06] Lehuen J. (2006), « Modélisation du dialogue, des actes de langage aux modèles de dialogue ». Cours de Master 2 Recherche, LIUM, Université du Maine. [LUZ 95] Luzzati D. (1995), « Le dialogue verbal homme-machine ». Masson, Paris. [MAT 05] Mathet Y. (2005), « Sémantique et traitement automatique du langage naturel ». Hermès, Paris, p.215-259. [NIC 03] Nicolle A., Saint-Dizier De Almeida, V., Beust, P., Jacquet, D. et Brassac, Ch. (2003). « Étude des Processus d'Interaction en Conception Distribuée », Revue d’Interaction Homme Machine (RIHM), vol 4 n°2, p.9-40. [RAS 94] Rastier F., Cavazza M., Abeillé A. (1994). « Sémantique pour l’analyse », Paris, Masson. 55 [ROU 01] Rouillard J., Caelen J. (2001), « Le système Halpin : Recherche documentaire en langue naturelle et dialogue multimodal ». Revue d’Interaction HommeMachine, vol.2, n°2, p.55-81. [SHA 49] Shannon C. E., Weaver D. W. (1949). « The mathematical theory of communication », University of Illinois Press. [TES 69] Tesnière L. (1959), « Eléments de syntaxe structurale ». Paris : Klincksieck. 56 Annexe I : Code XML de la hiérarchie de tables Anadia Nous présentons un exemple de document au format XML contenant toutes les informations d’un domaine d’interprétation modélisé au moyen du modèle Anadia. Les premières informations représentent le nom du domaine, très important pour pouvoir les différencier (et ainsi répondre à des problèmes de métaphore par exemple). <ANADIA> <HEAD Auteur="" Sujet="Monde fantastique" Commentaires="" /> Puis tous les attributs sont décrits, avec les valeurs existantes pour chacun. <ATTRIBUT Nom="Milieu"> <VALEUR>air</VALEUR> <VALEUR>terre</VALEUR> <VALEUR>mer</VALEUR> </ATTRIBUT> <ATTRIBUT Nom="Vitesse"> <VALEUR>lente</VALEUR> <VALEUR>normale</VALEUR> <VALEUR>rapide</VALEUR> </ATTRIBUT> Finalement, les registres sont créés, avec les attributs qu’ils utilisent. <REGISTRE Nom="Personnages"> <ATT> Vitesse</ATT> <ATT> Milieu</ATT> </REGISTRE> Enfin, les tables associées aux registres sont décrites, ainsi que les différentes valeurs de chaque ligne, et le concept (optionnel) associé. Par exemple, « Monstre volant » se retrouve avec les valeurs rapide et air dans la table //Personnages//. <TABLE Nom="Personnages" X="272" Y="87"> <COLONNE>Vitesse</COLONNE> <COLONNE>Milieu</COLONNE> <LIGNE> <VALEUR>lente</VALEUR> <VALEUR>air</VALEUR> </LIGNE> <LIGNE> <VALEUR>normale</VALEUR> <VALEUR>air</VALEUR> </LIGNE> <LIGNE> <CATEGORIE>_Monstre volant</CATEGORIE> <VALEUR>rapide</VALEUR> <VALEUR>air</VALEUR> </LIGNE> <LIGNE> <VALEUR>lente</VALEUR> <VALEUR>terre</VALEUR> </LIGNE> <LIGNE> <CATEGORIE>_Monstre terrestre</CATEGORIE> <VALEUR>normale</VALEUR> <VALEUR>terre</VALEUR> </LIGNE> 57 <LIGNE> <VALEUR>rapide</VALEUR> <VALEUR>terre</VALEUR> </LIGNE> <LIGNE> <VALEUR>lente</VALEUR> <VALEUR>mer</VALEUR> </LIGNE> <LIGNE> <CATEGORIE>_Monstre aquatique</CATEGORIE> <VALEUR>normale</VALEUR> <VALEUR>mer</VALEUR> </LIGNE> <LIGNE> <VALEUR>rapide</VALEUR> <VALEUR>mer</VALEUR> </LIGNE> </TABLE> Il est également possible d’avoir les topiques à un trait près de chaque table (par exemple ici //Personnages//). <TOPIQUE> <Nom>Personnages</Nom> <ORIGINE>Personnages</ORIGINE> <NBDIFF>1</NBDIFF> <NODE> <LABEL>_Monstre terrestre</LABEL> <POINT>920, 418</POINT> </NODE> <NODE> <LABEL>_Monstre aquatique</LABEL> <POINT>124, 418</POINT> </NODE> <EDGE> <LABEL>Milieu</LABEL> <BEGIN>_Monstre terrestre</BEGIN> <END>_Monstre aquatique</END> </EDGE> </TOPIQUE> </ANADIA> 58 Annexe II : Définition des seuils en CLIPS Nous présentons la façon dont ont été implémentés, en langage CLIPS, les différents seuils que nous avons mis en place. Nous avons alors choisi de mettre ces variables en variables globales, afin de pouvoir aisément les modifier. Nous avons tout d’abord définit le seuil d’acceptabilité, seuil permettant de savoir si un concept est retenu (mais non sûr) ou invalidé (score trop faible) : (defglobal MAIN ?*accept* = 0.5) ; Puis nous avons initié le seuil de décision, qui permet de savoir si le concept fait partie de l’indécision, ou s’il peut être choisi directement (score très élevé) : (defglobal MAIN ?*decide* = 0.81) ; Et finalement, nous avons défini le nombre maximum de concepts que nous retenons lors du sous-dialogue avec l’utilisateur (concept à remplacer mais dont nous ne sommes pas sûr, et qui nécessite une validation par l’utilisateur) : (defglobal MAIN ?*nbconcepts* = 3) ; 59