L’historique de dialogue dans les systèmes conversationnels 

Les systèmes de dialogue

Le but d’un agent conversationnel est de pouvoir communiquer avec un humain à travers un dialogue de questions/réponses. Les systèmes de dialogue, agents conversationnels ou encore chatbots, utilisent les technologies de l’apprentissage automatique (aussi appelé apprentissage machine ou machine learning en anglais), de l’intelligence artificielle et de la recherche d’information. Alors que les chatbots vont avoir un dialogue sous format textuel, les agents conversationnels peuvent également converser avec la parole en utilisant les technologies de reconnaissance et de synthèse de la parole. Nous nous focaliserons ici sur les systèmes de dialogue de type textuel.
Un système de dialogue est composé de différents modules, différents composants ayant leur propre rôle dans le système. Les trois modules que l’on retrouve toujours sont les modules de compréhension du langage, de gestion du dialogue et pour finir, de génération de la réponse.
La structure globale d’un système de dialogue peut être visualisée à l’aide de la figure 1.

Module de compréhension du langage

Le module de compréhension du langage est aussi souvent appelé NLU (en anglais, natural language understanding). Le rôle de ce module est de récupérer grâce à un analyseur sémantique les informations principales de la requête. Le domaine de détection des concepts (slot-filling) permet de récupérer ce que l’on appelle des slots, aussi appelés concepts. C’est une méthode de TAL qui permet d’étiqueter les mots selon leur sens dans la phrase. Ce module va par conséquent récupérer les slots de la phrase qui nous intéressent ainsi que leur valeur associée et transmettre ces informations au module de gestion du dialogue.

Module de gestion du dialogue

Le module de gestion du dialogue fait le plus gros du travail dans un système conversationnel. C’est lui qui va choisir la réponse à donner à l’utilisateur. Pour cela, il récupère la question et son information sémantique et fait le lien avec les données (base de données, divers documents, etc). Si besoin, un sous module est appelé pour récupérer les données appropriées à l’aide du domaine de la recherche d’information (IR, en anglais, information retrieval). C’est aussi lui qui va gérer tout le contexte autour du dialogue, dont l’historique de conversation. Le module renvoie l’information sémantique en sortie au module de génération.

Module de génération de la réponse

Le module de génération de la réponse (NLG, en anglais, natural language generation) s’occupe tout simplement de transformer l’information sémantique de la réponse en réponse textuelle, compréhensible pour un utilisateur humain.

L’historique de dialogue dans les systèmes conversationnels

Pourquoi un historique ?

Le défi principal d’un système de dialogue est d’avoir le dialogue le plus interactif possible et de simuler une conversation avec un humain. Pour cela, il est indispensable que le système prenne en compte l’entièreté du dialogue et non pas seulement la dernière question posée. Autrement dit, les tours de dialogue précédents jouent un rôle particulièrement important dans la compréhension de la question courante puisqu’ils participent au contexte autour de celle-ci. La figure 2 met en exergue l’importance de l’historique de conversation puisque pour comprendre la dernière question, la machine doit de se rappeler de la question précédente.

SELECTION DE L’HISTORIQUE

On retrouve dans chaque modèle ConvQA un module de sélection d’historique. C’est lui qui va s’occuper de sélectionner quelle partie de l’historique il est intéressant d’exploiter pour aider le système à répondre à la question. Certains modèles vont par défaut récupérer toutes les questions/réponses des n-tours précédents. Toutefois, prendre une grande partie de l’historique peut faire baisser la performance du système. En effet, en récupérant beaucoup de questions/réponses, on augmente les chances qu’il y ait eu un changement de sujet au fur et à mesure de la conversation. De ce fait, la question actuelle n’a potentiellement plus de lien avec l’historique, ce qui peut induire le système en erreur.
Pour remédier à ce problème, certains modèles, comme BiDAF++ w/2-Context (Ohsugi et al. 2019) et SDNet (Zhu, Zeng, et Huang 2019), ne récupèrent pas plus de trois tours de dialogue avant la question actuelle. D’autres conseillent de ne prendre en compte que les questions et de ne pas utiliser l’historique des réponses (FlowQA). D’autres encore proposent une sélection d’historique plus poussée comme FlowDelta (Yeh et Chen 2020) dans le but de ne récupérer que les parties de l’historique qui aident à répondre à la question actuelle.

ENCODEUR

Une fois que le modèle a sélectionné l’historique de dialogue, on encode les tokens de la question actuelle, du contexte et de l’historique en plongements de mots. Les plongements de mots, aussi couramment nommés embeddings en anglais ou plongement lexical, est une technique de TAL permettant de représenter des mots avec des vecteurs de nombres réels. De cette manière, plus la différence entre les vecteurs de deux mots est moindre, plus on peut en conclure que le sens des deux mots est proche (cf Annexe n°1).

RAISONNEMENT CONTEXTUEL

Le module de raisonnement contextuel est la partie du système qui va transformer les embeddings de tokens en embeddings contextuels.
Pour cette étape, il existe autant de possibilités qu’il existe de modèle. Néanmoins, il est possible de la simplifier en utilisant un modèle de langue pré-entrainé comme BERT (Bidirectional Encoder Representations from Transformers). BERT est un modèle de langue développé par Google. Comme son nom l’indique, il a la particularité d’utiliser des Transformers, un mécanisme d’attention composé d’un encodeur qui lit le texte en entrée et d’un décodeur qui fait une prédiction. Contrairement aux modèles unidirectionnels, l’encoder ne lit pas les mots de gauche à droite ou de droite à gauche mais toute la séquence en même temps. Cela lui permet de prendre en compte tout le contexte d’un mot, c’est-à-dire les autres mots qui l’entourent (Devlin et al. 2019).
Dans un système ConvQA, BERT permet de simplifier l’architecture des modules puisque les étapes d’encodage et de raisonnement se font simultanément. Dans cette approche, on regroupe la question et le contexte en marquant la séparation des deux avec des marqueurs d’embedding. On donne cette entrée à BERT qui retourne un embedding contextualisé pour chaque token de segment donné en entrée. Nous verrons plus en détails ce fonctionnement dans le chapitre 3 en étudiant un modèle en particulier qui utilise BERT.

PREDICTION

Le module de prédiction va permettre, comme son nom l’indique, de prédire la réponse à la question. Il va récupérer les embeddings contextuels générés par le module de raisonnement et donner en sortie un extrait de texte provenant du contexte.

Datasets utilisés

Les modèles ConvQA utilisent en majorité les datasets QuAC (Choi et al. 2018) et/ou CoQA (Reddy, Chen, et Manning 2019). Ce sont des datasets de questions/réponses sous forme de dialogues. Chaque dialogue dispose d’un titre de section principal et d’un contexte sur lequel les questions vont se reposer.

QUAC

QuAC est un dataset assez conséquent qui comporte 14 000 dialogues dont 10 000 questions. Les données ont été récupérées à partir de dialogues entre étudiants et professeurs. D’un côté, les étudiants posent des questions concernant des articles Wikipédia , et de l’autre, les professeurs répondent aux questions à l’aide d’un extrait provenant de l’article. Contrairement à d’autres datasets, la majorité des questions de QuAC sont des questions ouvertes, parfois ambiguës et qui ne peuvent être réellement comprises qu’en prenant en compte le contexte autour de la question.

COQA

CoQA quant à lui détient 127 000 questions provenant de 8000 dialogues. Les données ont été produites par des dialogues entre collègues de travail se posant des questions sur un passage textuel.
Puisque certains modèles n’ont été évalués qu’avec QuAC, pour plus de simplicité, j’ai choisi d’utiliser seulement comme référence le dataset QuAC. C’est aussi le dataset qui détient la structure qui se rapproche le plus de DoQA (Campos et al. 2020), un troisième dataset que nous utiliserons avec le système de dialogue du projet LIHLITH et que je présenterai dans le prochain chapitre. De ce fait, je pourrais mettre en miroir les performances du modèle avec d’un côté le dataset QuAC et de l’autre le dataset DoQA.

Étude de modèles ConvQA

Parmi les différents articles que j’ai pu lire, certains ont plus particulièrement retenu mon attention. Je vais m’attarder un peu plus longtemps dans cette partie sur le modèle HAM (History Attention Mechanism) sur lequel je me suis par la suite appuyé lors de mes expériences. Je vais par conséquent décrire ses particularités avant de brièvement les comparer à celles des autres modèles qui m’ont intéressé.

Modèle HAM

MODELISATION DE L’HISTORIQUE ET ENCODEUR

Le modèle HAM (Qu et al. 2019) utilise le modèle de langue BERT pour la partie encodage. C’est lui qui va encoder la question, le contexte et l’historique de conversation en représentations contextualisées. Cela revient à incorporer du contexte à l’intérieur des plongements de mots. Le fonctionnement de cet encodeur peut être observé dans la figure 6.

Particularités du système de dialogue

Description du système

La deuxième étape de mon stage fut la lecture et compréhension du code du système de dialogue. Pour m’aider, j’ai illustré le système avec des schémas des différents modules pour visualiser leurs structures et les données d’entrée et de sortie. Il me paraît tout d’abord important de décrire de manière générale la manière dont fonctionne ce système de dialogue. La figure 7 permet de visualiser la structure générale du système. On y retrouve les différents modules que je vais décrire plus en détails dans ce chapitre.

MODULE NLU

Le système de dialogue est tout d’abord composé du module NLU (en anglais, Natural Language Understanding). Comme nous l’avons dans le chapitre 1, ce module permet au système de récupérer grâce à un analyseur sémantique les informations principales de la requête, c’est-à-dire les slots, aussi appelés concepts. C’est une méthode de TAL qui permet d’étiqueter les mots selon leur sens dans la phrase. Ce module va par conséquent récupérer les concepts sémantiques de la phrase qui nous intéressent ainsi que leur valeur associée. Par exemple, respectivement, « recipe_type » et « pancakes » comme on peut le voir dans la figure 8, qui est une capture d’écran de l’étape de détection des concepts du système de dialogue du projet LIHLITH.

MODULE FAQ

Si on ne trouve pas la réponse dans le module KB, le système va alors appeler le module FAQ. Ce module utilise deux sources principales de données. Il utilise une partie du datas et DoQA et un Cookbook, composé de divers paragraphes contenant des informations sur la cuisine. Dans un premier temps, le système va effectuer une recherche de paragraphes à l’aide de Solr . Solr est un serveur de recherche très utilisé dans le domaine de recherche d’information (IR). Ce dernier va indexer les documents que l’on détient et rechercher les dix meilleurs paragraphes. C’est BERT qui va faire les prédictions des extraits de texte à l’intérieur des meilleurs paragraphes dans le sous module ConvQA. On peut voir un exemple de ces . Serveur de recherche d’Apache https://solr.apache.org/ résultats dans la figure 10. Pour trois paragraphes différents, le module ConvQA propose quatre extraits de texte différents.

Protocole expérimental

Une des premières étapes importantes et techniques de mon stage fut d’intégrer le modèle HAM comme module de remplacement du module ConvQA dans le système de dialogue. Le but final était de pouvoir tester le système avec le modèle entrainé sur différentes données et avec différents paramètres. Pour ça, il a fallu dans un premier temps modifier le code du modèle HAM pour pouvoir l’entrainer avec les données et paramètres choisis.

Choix des données et paramètres du modèle

CHOIX DES DONNEES

Le modèle de base ConvQA qui s’occupe de prédire l’extrait de réponse dans le paragraphe a été entrainé avec QuAC avant d’effectuer un fine-tuning avec le dataset DoQA.
De plus, une partie des données utilisées pour trouver les paragraphes correspondants aux questions proviennent de DoQA. C’est donc avec ce dataset que j’ai entrainé le modèle.

ADAPTATION DU MODELE POUR DOQA

Pour adapter le script du modèle fonctionnant avec le dataset DoQA, j’ai dû modifier le code pour récupérer les différentes informations selon la structure de DoQA. En effet, le système doit parcourir l’ensemble de données et récupérer les différents éléments imbriqués dans des balises dans un fichier .json. Selon les datasets, la structure varie plus ou moins et il est donc nécessaire de s’assurer que les différentes données sont bien récupérées.

CHOIX DES PARAMETRES

Concernant les paramètres de l’entrainement je me suis particulièrement posé des questions sur le nombre de tours d’historique maximum à prendre à compte.

Entrainements

Une fois que l’on peut entrainer notre modèle avec nos données et paramètres choisis, on peut utiliser ce modèle entrainé dans notre système de dialogue.

ENVIRONNEMENT DU SYSTEME DE DIALOGUE

Le système de dialogue a été développé avec le langage de programmation python (version 3.6) et fonctionne à l’aide de plusieurs bibliothèques. Pour faciliter leurs installations, j’ai utilisé Conda , un gestionnaire de package permettant de créer divers environnements python et d’y installer des bibliothèques.
Le système utilise notamment les bibliothèques torch , pour l’apprentissage profond, et transformers.

ENVIRONNEMENT DU MODELE HAM

Le modèle HAM lui aussi fonctionne avec la version 3.6 de python, ce qui a grandement facilité l’intégration du modèle au système de dialogue. De plus, c’est la bibliothèque TensorFlow (version 1.8.0) qui va permettre de gérer l’entièreté du modèle HAM. TensorFlow permet de créer et gérer des réseaux de neurones.

AJOUT DU MODELE AU MODULE FAQ

Pour intégrer le modèle dans le système de dialogue, il a fallu que je modifie principalement trois parties du code, visibles dans les encadrés verts de la figure 12.

Difficultés et problèmes

Afin de pouvoir tester les performances du modèle HAM dans le système de dialogue, il a d’abord fallu l’entrainer. Pour commencer , et également dans le but d’être sûr que le modèle fonctionne bien dans mon environnement, j’ai entrainé le modèle tel quel avec les données recommandées (dataset QuAC) et les paramètres de base.

Entrainement du modèle avec Slurm

Le modèle HAM fonctionne sur GPU (Graphic Processing Units), à la différence de ceux que l’on fait fonctionner seulement avec des CPU (Central Processing Units). J’ai pu utiliser le cluster de calcul lab-ia qui permet de lancer des jobs à l’aide de slurm . Le modèle nécessite des ressources assez élevées et obtenir des résultats prend en général 90h.

Problèmes rencontrés

Outre le temps de s’habituer à utiliser Slurm et de parvenir à correctement installer mes différents environnements sur la machine distante, j’ai également passé beaucoup de temps pour parvenir à reprendre mes entrainements après un checkpoint. Pour ça, il a fallu que je me familiarise avec la version 1.8 de TensorFlow et que je comprenne bien comment les

PROBLEMES AVEC LES DONNEES

Le problème majeur que j’ai pu observer lors de mes tests utilisant le module FAQ du système de dialogue concerne les données utilisées. Tout d’abord, une grande partie des paragraphes récupérés par le module IR provient des données du Cookbook. Ces données ne sont pas ordonnées et ont des défauts qui influencent la performance du système. Par exemple, pratiquement tous les passages commencent par « information about » suivi du mot clé qui caractérise le sujet du paragraphe. Par conséquent, le module IR a tendance à prioritiser ces paragraphes et la détection de l’extrait dans le passage se situe souvent au début.

Résultats de l’entrainement

Les premiers entrainements que j’ai faits ont été produit avec le modèle HAM sans modification et avec le dataset QuAC. L’évaluation du modèle se fait à partir des données de test de QuAC et à l’aide de son script d’évaluation. J’ai pu par la suite comparer ces résultats avec les résultats des entrainements fait avec le dataset DoQA. Le Tableau 4 affiche un résumé de ces premiers résultats. Pour évaluer la performance globale du modèle, on regarde principalement le score F1. Il correspond à la moyenne harmonique du taux de la précision et du rappel . Le score F1 humain calculé sur le dataset QuAC est de 81.1%. Comme l’on peut le voir, la grandeur du dataset QuAC fait que l’on obtient de bien meilleurs résultats, dont un F1 de 56.01 face à un F1 de 47 en moyenne pour DoQA. J’ai aussi comparé un entrainement en regardant les 11 derniers tours de dialogue et un autre en ne prenant en compte que les 6 derniers tours de dialogue. On remarque une légère hausse de la performance lorsqu’on prend on compte un historique de conversation plus réduit. Par défaut, le modèle HAM ne prend en compte que l’historique de réponse et non pas les questions précédentes car, comme on peut le voir dans le tableau, la performance est moins bonne. Néanmoins, nous avons tout de même trouvé plus intéressant de prendre en compte réponses et questions de l’historique.

Résultats de l’entrainement avec slots

J’ai d’abord effectué les entrainements avec les deux datasets et avec des paramètres différents pour établir lesquels détiennent la meilleure performance et conviennent le mieux à notre tâche. Puis, j’ai comparé les résultats en prenant en compte les slots et valeurs des questions. Comme nous l’avons vu dans le Chapitre 5, j’ai pris en compte deux manières d’annoter les slots dans le datas et. On peut trouver un résumé des meilleurs résultats que j’ai pu obtenir pour chaque méthode dans le tableau 6. Comme anticipé, diminuer le nombre de tours maximums à étudier pour répondre à la question améliore nettement les performances du modèle. En plus de ça, la méthode qui se démarque plus est celle utilisant un embedding de séparation entre les plongements lexicaux de la question et ceux des concepts et valeurs. En effet, rajouter ces séparateurs permet au système de séparer la question de ses slots. Néanmoins, les résultats entre les deux méthodes sont peu différents, certainement dû en partie au fait que BERT est un modèle de langue entrainé avec des données de textes et non pas des données de slots.

Table des matières
PREAMBULE 
INTRODUCTION 
LE PROJET LIHLITH 
MISSIONS ET OBJECTIFS 
Partie 1 – État de l’art 
CHAPITRE 1. LES SYSTEMES DE DIALOGUE 
1. MODULE DE COMPREHENSION DU LANGAGE
2. MODULE DE GESTION DU DIALOGUE
3. MODULE DE GENERATION DE LA REPONSE
CHAPITRE 2. L’HISTORIQUE DE DIALOGUE DANS LES SYSTEMES CONVERSATIONNELS 
1. POURQUOI UN HISTORIQUE ?
2. LES MODELES CONVQA
3. LES DIFFERENTES METHODES
4. DATASETS UTILISES
CHAPITRE 3. ÉTUDE DE MODELES CONVQA 
1. MODELE HAM
2. RESULTATS DES MODELES LES PLUS PERFORMANTS
Partie 2 – Contributions et expérimentations 
CHAPITRE 4. PARTICULARITES DU SYSTEME DE DIALOGUE 
1. DESCRIPTION DU SYSTEME
2. DATASET DOQA
CHAPITRE 5. PROTOCOLE EXPERIMENTAL 
1. CHOIX DES DONNEES ET PARAMETRES DU MODELE
2. ENTRAINEMENTS
CHAPITRE 6. ENRICHIR LE CONTEXTE 
1. INTEGRATION DES SLOTS AU MODELE
2. INTEGRATION DES SLOTS AU SYSTEME
CHAPITRE 7. DIFFICULTES ET PROBLEMES 
1. ENTRAINEMENT DU MODELE AVEC SLURM
2. PROBLEMES RENCONTRES
Partie 3 – Résultats et analyse 
CHAPITRE 8. INTERPRETATION DES RESULTATS
1. METRIQUE D’EVALUATION
2. RESULTATS DE L’ENTRAINEMENT
3. RESULTATS DE L’ENTRAINEMENT AVEC SLOTS
CHAPITRE 9. PERSPECTIVES D’AMELIORATIONS 
1. FINE-TUNING DU MODELE AVEC LES DONNEES DU COOKBOOK
2. AMELIORATION DE L’UTILISATION DE DOQA
3. FINE-TUNING DE BERT SUR DES DONNEES DE SLOTS
CONCLUSION 
1. BILAN DU TRAVAIL ACCOMPLI
2. BILAN PERSONNEL
BIBLIOGRAPHIE 
SITOGRAPHIE 
GLOSSAIRE 
SIGLES ET ABREVIATIONS 
TABLE DES FIGURES 
TABLE DES TABLEAUX 
TABLE DES ANNEXES
RÉSUMÉ 
ABSTRACT

Télécharger le rapport complet