La littérature scientifique présente plusieurs façons d’aborder le problème, mais nous nous sommes intéressés plus spécifiquement à la tâche de sélection de réponse. Cette tâche vise à prédire la réponse correcte parmi un ensemble de réponses candidates.

Elle suppose qu’il existe toujours une réponse correcte pour chaque question. Cependant, dans un système réel de questions-réponses, on souhaite parfois ne pas fournir de réponse, par exemple si un utilisateur pose une question hors domaine. La tâche de sélection optionnelle de réponse (answer triggering) offre cette possibilité.

Définition du système

Pour accomplir la tâche de sélection optionnelle de réponse pour une question donnée, l’implémentation choisie exécute deux sous-tâches:

1. Un modèle d’apprentissage automatique (un classifieur) accepte en entrée une représentation vectorielle de la question et retourne les probabilités par classe. Chaque classe est associée à une paire question-réponse.
2. La probabilité la plus élevée est comparée à un seuil pour déterminer si la réponse sera retournée ou non.

Des expériences ont ensuite été réalisées pour trouver la meilleure combinaison de modèle de vectorisation et de classifieur pour réaliser la première sous-tâche.

Expériences

Pour les expériences, l’ensemble de données bancaires BANKING77, créé par l’entreprise de solutions conversationnelles PolyAI, a été utilisé. Les combinaisons de modèle de vectorisation et de classifieur ont été évaluées sur l’ensemble de test avec la métrique d’exactitude (accuracy), qui calcule le pourcentage de prédictions correctes.

Modèles de vectorisation

Parmi les différents modèles de vectorisation, celui qui a le mieux performé est le Universal Sentence Encoder (USE) de Google. C’est un réseau de neurones préentraîné simultanément sur plusieurs tâches de nature sémantique qui accepte en entrée un texte et produit en sortie un plongement de phrase (une représentation vectorielle de la phrase). Le préentraînement est fait sur de très grands corpus de texte comme Wikipédia, ce qui lui permet de bien capturer la similarité sémantique de phrases jamais vues au préalable, comme on peut voir dans l’exemple ci-dessous.

Similarité sémantique de phrases tirées de BANKING77 avec USE. Référence

Classifieurs

Parmi les classifieurs évalués, on compte notamment un classifieur des k plus proches voisins (KNN) et un réseau de neurones. L’avantage principal du KNN par rapport au réseau de neurones est qu’il n’a pas besoin d’être entraîné, il ne fait que mémoriser les données d’entraînement. Ajouter de nouvelles questions au modèle ne nécessite donc pas un réentraînement. Un autre avantage est que ses prédictions sont interprétables. Pour prédire la classe d’un exemple de test, le KNN trouve ses k plus proches voisins et retourne la classe majoritaire. Le nombre de voisins ainsi que la fonction de distance sont des hyperparamètres configurables.

Pour illustrer le fonctionnement du KNN, un exemple simplifié est fourni ci-dessous pour un problème de classification binaire avec des données en 2 dimensions.

Exemple pour un KNN avec k=3 et distance euclidienne. Pour l’exemple de test en gris, on
prédira la classe en bleu (classe majoritaire parmi les 3 plus proches voisins).

Dans un premier temps, des expériences ont été réalisées avec un KNN avec distance cosinus. Dans un deuxième temps, d’autres expériences ont été réalisées avec une fonction de distance apprise (metric learning) dans le but d’améliorer la performance. L’algorithme utilisé avait pour but de rapprocher les exemples d’une même classe et éloigner les exemples appartenant à des classes différentes. Dans les deux cas, l’exactitude obtenue avec le réseau de neurones était supérieure, ce qui fait en sorte que ce dernier a été choisi comme classifieur.

Évaluation du système

Les expériences décrites précédemment ont permis d’établir que le meilleur modèle était celui combinant le Universal Sentence Encoder avec un MLP. Pour évaluer ce modèle, une comparaison a été effectuée sur la tâche de sélection optionnelle de réponse avec les modèles de classification d’intentions des engins NLU de Dialogflow ES et Rasa. Pour ce faire, une nouvelle intention “out_of_scope” (hors domaine) contenant des questions sur la COVID-19 a été ajoutée à l’ensemble de test de BANKING77. Pour tous les modèles, rejeter des exemples hors domaine s’est avéré plus difficile que bien classifier les exemples appartenant au domaine. Cependant, dans l’ensemble, c’est le modèle USE combiné à un réseau de neurones qui s’est démarqué. Cette évaluation a donc démontré que ce modèle peut être utilisé pour développer un système de questions-réponses performant et efficace.

Pour plus de détails sur les modèles utilisés, la méthodologie suivie et les résultats des expériences, nous vous invitons à consulter cet article.

The post Exploration d’approches pour un système de questions-réponses first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post Exploration d’approches pour un système de questions-réponses appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

Our banking IVR is a self-service application in which a caller can execute tasks like paying a bill or getting an account balance. The dialogue includes a loop that allows the caller to carry out tasks as many times as he or she wants:

The application accommodates expert users by allowing them to quickly complete their tasks:

It also adapts to less experienced users by providing them with a more directed dialogue when needed:

The IVR supports mixed initiative strategies like digressions:

As well as change requests or corrections:

The dialogue also handles error recovery, including errors that are specific to the voice channel:

This is only an overview of the patterns handled by our dialogue model; several others are already implemented. We are also planning on adding other dialogue strategies, such as cancelling a task or handling more complex corrections and change requests.

Implementation: why we opted for a deterministic approach

Early on, we decided to rely on a deterministic approach for our use cases. The main reasons why machine learning was less adapted to our current use cases are as follows:

• Task related dialogues are predictable and relatively directed
• Tasks can be executed repeatedly and the application behavior should be identical every time
• Tasks should be interrupted and resumed reliably
• Tokens of information that are collected for a given task are not relevant for another
• Tasks are independent and must not interact with each other

In addition, our requirements for error recovery and change management were rather strict.

Deterministic approach

Our deterministic approach consists in managing actions using a stack. A stack is a data structure of type last in first out; in other words, the last item added to the stack is the first one to be removed. The action at the top of the stack is the one in focus. When we add an action to a stack, it becomes in focus. When the action in focus is completed, it is removed from the stack and the dialogue goes back to the previous action. This allows to interrupt and resume actions in a predictable and robust manner.

This can be illustrated as follows:

Here is an example of the state of a stack for a dialogue in which the user interrupts the ongoing action (digresses) to ask for a list of their accounts. Once the digression to hear the list of accounts is completed, this action is removed from the stack and the focus comes back to the previous action, that is, the bill payment action.

In addition to allowing us to manage digressions elegantly, our approach allows us to define isolated contexts for each action. This ensures that they remain independent.

Next are some additional details on how this was implemented using Rasa.

Custom policy

In Rasa, a policy is what allows to predict/specify the next action to be executed in the dialogue depending on context (tracker). Out-of-the-box, Rasa offers a combination of deterministic and machine learning based policies. It is also possible to create our own policy. This is what we did by implementing a deterministic policy that alternates between waiting for the next user input and triggering an action used as an action manager (responsible for managing the action stack). Since we do not make predictions as to what action must be executed, our policy does not use stories and does not require a training phase. This is the only policy that we use.

Action manager

We have created an abstraction to manage the action stack that was described above. The stack is a complex object that we store in an unfeaturized slot. The action to be executed depends on the user’s input as well as the state of the stack.

Custom dialogue patterns

One frequent dialogue pattern is information token collection, or slot-filling. This pattern is used, for instance, by the bill payment action. Rasa provides an action for this pattern: the FormAction. However, we needed to support other, more complex patterns than what is offered by the FormAction, for example: slot confirmation when the speech recognition confidence score is low, final confirmation at the end of an action, etc. We have therefore created a custom class “Task” that handles these more complex patterns. Some of our actions inherit this class. We appreciate that Rasa offers the flexibility that we need to implement our own dialogue management strategies.

Unit test framework

Since we have implemented our dialogues using a deterministic approach, we were able to build our own unit test framework to test our dialogues. This allowed us to increase our application’s reliability.

Next steps

Although we have been relying on a deterministic approach to develop our banking use cases, we are also currently experimenting with machine learning to develop dialogues for different use cases.

• Here are some of the next items that we will explore:
• Use the Recurrent Embedding Dialogue Policy to support uncooperative user behavior
• Use Rasa X to learn from real conversations
• Create more natural dialogues by using recorded prompts instead of TTS
• Try to integrate machine learning in our deterministic model

We will share our experience in future posts as we move forward. Stay tuned!

The post La RVI conversationnelle avec Rasa – 3e partie : gestion du dialogue (Article en anglais) first appeared on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.

The post La RVI conversationnelle avec Rasa – 3e partie : gestion du dialogue (Article en anglais) appeared first on AI Virtual Voice Experts with Google Dialogflow CX - CCAI - Nu Echo.