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