IA Lab

L’art difficile de la conversation artificielle

16 janvier 2019

Résumé

Concevoir des agents conversationnels en mesure de soutenir une conversation qui ne se résume pas à une simple succession de question-réponses reste aujourd’hui un défi. Dans cet article nous décrivons différentes options disponibles pour essayer de le relever. L’apprentissage supervisé, l’apprentissage par renforcement et les réseaux de neurones récurrents en sont les principaux ingrédients. Limiter le nombre d’exemples d’entraînement est un autre enjeu de taille. Sur ce sujet, nous présentons deux travaux de recherche récents. Le premier exploite l’apprentissage par renforcement ainsi qu’un simulateur d’utilisateur. Le second utilise une approche hybride qui intègre machine learning et code métier.

  1. Le problème lancinant du contexte
  2. Les options pour créer un agent conversationnel
  3. Zoom sur deux approches end-to-end (le framework RASA)
  4. Du provisoire qui pourrait durer…

1. Le problème lancinant du contexte

Les chatbots sont partout avec Siri, Google Now, Cortana et Alexa. A n’en pas douter leur usage se démocratise dans l’espace domestique où ils bénéficient depuis quelques années des énormes progrès réalisés en reconnaissance de la parole. Ils nous permettent de simplifier l’exécution de tâches aussi vitales que de baisser l’éclairage du salon, lancer un morceau de musique sur Spotify ou estimer la durée d’un trajet en fonction de l’état du trafic. Pour l’essentiel cependant, il s’agit là d’usages que l’on peut qualifier de transactionnels dans la mesure où l’utilisateur pose une question ou donne un ordre au système qui ensuite s’exécute. Point à la ligne.

Les choses se gâtent rapidement toutefois lorsqu’on essaie d’engager une conversation un peu plus élaborée comme l’illustre ironiquement la figure 1. Et, ne nous voilons pas la face, hormis les quelques usages domestiques évoqués, les chatbots sont pour l’instant des créatures qui, au mieux, sont d’une fort ennuyeuse compagnie et, au pire, nous accablent de leur exaspérante stupidité artificielle.

Figure 1 : Une illustration, à peine caricaturale, de l’état de l’art en matière de conversation artificielle.

De fait, la prise en compte du contexte sémantique d’une conversation qui s’étend sur plusieurs échanges reste un problème difficile et encore largement ouvert. A l’origine de ces faiblesses on trouve l’approche statistique qu’utilisent ces systèmes pour analyser une conversation [1]. Les phrases qu’ils formulent ne sont que celles qu’ils considèrent comme les plus vraisemblables à l’aune des exemples de conversations avec lesquels ils ont été entraîné. Ils ne disposent cependant d’aucun modèle symbolique ou sémantique du monde, même dans les domaines restreints sur lesquels ils interviennent. En ce sens, leur conversation n’est donc qu’un simulacre qui, dans certains cas précis, pourra toutefois être utile.

Pour l’heure, et quelle que soient ses limites intrinsèques, cette approche statistique demeure la seule à être praticable pour construire des agents conversationnels qui ambitionnent d’aller au-delà des simples échanges question-réponse. C’est celle dont il sera question dans cet article.

Entre les grands acteurs technologiques la compétition est féroce pour élaborer des agents capables de tenir une conversation cohérente dans des contextes certes limités mais face à de vrais utilisateurs. La démonstration de Google Duplex, un agent vocal capable de passer des réservations pour un restaurant, a marqué les esprits par son réalisme durant la conférence Google I/O 2018. La compétition est cependant en embuscade :

  • Ainsi Ali Baba aurait conçu un agent conversationnel plus élaboré encore que celui de Mountain View [ALI], bénéficiant en cela de gigantesques corpus de données conversationnelles et peut-être aussi de scrupules modérés sur les questions de confidentialité.
  • Microsoft de son côté mène une R&D très active sur le sujet. En témoigne son initiative récente de lancer un challenge à la communauté des chercheurs pour élaborer des agents conversationnels [MDC]. L’idée est de proposer une plateforme expérimentale, constituée de données annotées et de simulateurs d’utilisateurs, qui permettra une évaluation comparative rigoureuse entre différentes solutions.

La conférence NIPS 2018 a également dédié un workshop aux agents conversationnels [NIP]. Le sujet des agents conversationnels intéresse par ailleurs les chercheurs du monde académique car ils constituent à la fois un banc d’essai et une source d’inspiration pour développer des techniques comme l’apprentissage par renforcement.

Le reste de cet article est organisé comme suit. La section 2 présente une liste d’options techniques disponibles pour construire des agents conversationnels par apprentissage statistique. Seules les questions du NLP (Natural Language Processing) nous intéressent, les problématiques de reconnaissance vocale ne sont pas abordées. Le section 3 présente deux approches récentes prometteuses qui visent notamment à minimiser le nombre de conversations d’entraînement. La première permet de construire des agents conversationnels « Task Oriented » dont l’entraînement met en œuvre un mécanisme d’apprentissage coopératif entre de vrais utilisateurs et un simulateur. La seconde permet d’incorporer du code métier grâce à une approche hybride entre Machine Learning et développement spécifique, elle est à l’origine du framework open source RASA. La section 4 propose quelques éléments de conclusion.

2. Les options pour créer un agent conversationnel

2.1 Les modules de base

La grande diversité des architectures logiques sur lesquels on peut construire un agent conversationnel rend difficile une analyse comparative globale de toutes les options. Au risque d’une simplification excessive nous admettrons ici pour fixer les idées que toutes ces architectures, du moins celle qui utilisent le Machine Learning, possèdent schématiquement quatre modules ou fonction de base comme l’illustre la figure 2.

Figure 2 : les 4 modules de base d’un agent conversationnel : NLU, ST, DP et NLG.

La majorité des agents dits Task Oriented [MDC, TEE] que l’on sollicite pour accomplir une tâche précise, comme réserver une table dans un restaurant ou récupérer un enregistrement correspondant à certains critères dans une base de données, utilisent une architecture similaire. De même les bots grand public comme Amazon Echo ou Google Home [DDQ].

  • Un module NLU (Natural Language Understanding) extrait une représentation sémantique simplifiée à partir d’un énoncé textuel. Typiquement dans le cas d’un bot il s’agit d’identifier l’intention de l’utilisateur (trouver un restaurant) et de la qualifier par une liste d’entités (le type de restaurant, le nombre de convives, le lieu etc…)
  • Un module Conversational State Tracking (ST) se charge de construire l’état de la conversation à partir de l’historique des énoncés de l’utilisateur et des réponses de l’agent. C’est lui qui essaie de comprendre la conversation. Dans le cas particulier où l’objectif assigné à un agent est la récupération d’un enregistrement dans une base, cet état pourrait correspondre aux probabilités, estimées à un instant donné par l’agent, que l’utilisateur recherche une entité dotée des certaines caractéristiques. Dans d’autres cas, cet état conversationnel pourrait être une représentation latente difficile à interpréter mais générée automatiquement par l’entraînement d’un réseau de neurones récurrent (RNN).
  • Un module Dialog Policy (DP) décide de la prochaine action de l’agent (fournir telle réponse à l’utilisateur, déclencher telle requête vers une base de données, mettre un terme à l’échange etc…) en fonction de l’état de la conversation identifiée par le ST.
  • Un module Response Generation (NLG) qui construit le texte de la réponse en fonction de l’action choisie par l’agent. Il peut s’appuyer sur des modèles (templates) ou un mécanisme de NLP génératif.

Selon les architectures certaines de ces fonctions peuvent être implicites ou fusionnées comme nous le verrons dans la section 3.

2.2 Le machine learning au service de la conversation

Aucune conversation, aussi limité que soit le sujet sur lequel elle porte, ne suit rigoureusement un template. Si l’on souhaite construire un agent capable d’un minimum de flexibilité il est par conséquent irréaliste de vouloir définir des règles pour chaque issue envisageable d’un échange pour ensuite les coder en dur. Le machine learning est en revanche bien adapté pour apprendre à gérer des situations complexes et même des situations évolutives sans recourir à des règles explicitement formulées. L’apprentissage supervisé et l’apprentissage par renforcement ont tous deux un rôle à jouer.

Apprentissage supervisé

A condition de disposer de données annotées en quantité et en qualité suffisante, chacun des quatre modules décrits précédemment peut bénéficier d’un apprentissage supervisé :

  • Module NLU: pour entraîner ce module une liste d’exemples de requêtes utilisateurs annotées avec une intention et des entités fera l’affaire. Ainsi la requête « Quelle temps fera-t-il demain à Paris ? » serait par exemple annotée avec l’intention « Connaître météo » et par les deux entités « Lieu = ‘Paris’ » et « Date = ‘demain’ ».
  • Modules State Tracking (ST) et Dialog Policy (DP) : l’utilisation du ML supervisé pour entraîner un module de ST est plus délicat car la notion même d’état conversationnel est souvent difficile à définir explicitement celui-ci n’étant pas observé directement. De plus, même lorsqu’on peut le définir, les jeux de données qui permettraient l’entraînement d’un module de ST ou de DP sont rarement disponibles. Pour cette raison, on préfère souvent concevoir un tel état comme une collection de variables latentes dont les valeurs résultent de l’entraînement d’un modèle de ML. Avec un RNN entraîné à prédire une action correcte consécutive à une succession d’échanges, l’état conversationnel serait par exemple constitué par le vecteur caché associé au dernier instant de l’échange, le vecteur dans la figure 3.
Figure 3 : Un RNN qui implémente à la fois les modules ST et la DP. Il associe une succession  d’échanges à une action . L’état conversationnel peut être assimilé au vecteur caché  par exemple. LTSM désigne un type de RNN couramment utilisé. Chaque x représente un énconcé. Chaque h est un vecteur caché, le dernier étant l’état conversationnel.
  • Module Response Generation (NLG): ce module se base sur des templates de réponses avec, éventuellement, des paramètres (ou « slots ») auxquels seront affectées les valeurs de certaines entités. Celles extraites par le module NLU ou celles extraites d’une base, suite à une action sélectionnée par le module DP. L’avantage de cette approche est qu’elle garantit la qualité syntaxique et orthographique des réponses. Des systèmes plus avancés peuvent utiliser un mécanisme génératif basé sur un RNN qui convertira un état conversationnel en une réponse formée d’une suite de mots. L’avantage de ce procédé de génération dynamique de réponse est qu’il dispense d’avoir à prévoir toutes les réponses possibles. Les phrases générées sont cependant susceptibles de comporter des erreurs de syntaxe ou même être dépourvues de sens.

Ces dernières années ont vu l’apparition d’approches dites « end to end » (E2E) [MDC, TEE] qui délaissent l’entraînement séparé des modules au profit de systèmes intégrant l’ensemble des quatre fonctions NLU, ST, DP et NLG. Entraînés directement sur des transcriptions de dialogues entre humains, ces systèmes construisent leur réponse sous forme d’une suite de mots qu’ils prédisent à partir de l’historique de la conversation.

L’atout principal de ces approches E2E est qu’elles dispensent d’avoir à construire des données d’entraînement annotées spécifiquement pour chaque module. En revanche, elles rendent très difficile la prise en compte de règles métiers ou de contraintes auxquelles doivent être soumises les conversations [HCN] ce que résume bien la citation [WDN] :

Deep learning and hand-coding are unhappy bedfellows. »

Enfin, un point un peu plus technique, un algorithme E2E devra être différentiable par rapport à ses paramètres pour pourvoir bénéficier d’un entraînement par rétropropagation, un point délicat lorsque le modèle utilise des requêtes SQL qui sont des opérations discontinues [TEE].

Apprentissage par renforcement

L’apprentissage par renforcement (RL) constitue un cadre naturel pour formuler et construire des agents Task Oriented.

 

 

 

L’apprentissage par renforcement
L’apprentissage par renforcement (RL) est une forme de Machine Learning qui vise à construire des agents capables de prendre des décisions autonomes dans des environnements complexes ou même aléatoires. Les décisions que prend un agent modifient son environnement qui lui transmet un signal de récompense lui indiquant en retour si l’action était bonne ou mauvaise au regard d’un objectif à atteindre. En RL, l’objectif assigné à un agent est de trouver une stratégie, l’association d’une action à chaque état, qui maximise la somme cumulée sur le long terme de toutes ces récompenses. Des comportements sophistiqués peuvent émerger d’une telle formulation. D’une part l’agent devra parfois sacrifier des gains à court terme au profit de ceux obtenus de manière différée. D’autre part, comme l’agent ignore généralement l’environnement dans lequel il évolue, il aura, pour agir de manière optimale, à concilier l’exploration de cet environnement et l’exploitation des connaissances qu’il y a déjà acquises. Le RL permet à un agent d’apprendre à partir de sa propre expérience plutôt que d’exploiter une expérience passée comme le fait l’apprentissage supervisé.

 

Pour un agent conversationnel Task Oriented une action consiste par exemple à interroger une base de données pour en extraire une ou plusieurs entités ou à renvoyer une réponse d’un certain type à l’utilisateur : lui demander une confirmation, l’informer de quelque chose ou le remercier. S’agissant de la récompense, on peut imaginer qu’une conversation qui s’achève avec utilisateur satisfait par la réponse apportée se voit gratifiée d’une récompense de +20. En revanche, une conversation qui s’achèverait avec un utilisateur insatisfait se verrait infliger une pénalité de -40. Pour inciter l’agent à la concision dans ses échanges on peut de surcroit décider que chaque échange coute une pénalité supplémentaire égale à -1.

Bien que très séduisante, l’approche par RL est difficile à mettre en œuvre en pratique, et ceci pour plusieurs raisons :

  • Il est impossible d’entraîner un agent RL au moyen de transcriptions statiques de conversations, il faut un interlocuteur dynamique. La première possibilité est d’avoir recours à d’authentiques utilisateurs. Hélas leur temps est généralement compté alors que des centaines d’échanges sont typiquement nécessaires à un entraînement par RL. Des utilisateurs humains risquent par ailleurs de perdre patience rapidement face à un agent qui, en début d’apprentissage, génère des réponses décousues.
  • La seule option, si l’on ne dispose pas d’une armée d’utilisateurs humains dotés d’une patience à toute épreuve, sera d’utiliser un simulateur d’utilisateurs piloté par des objectifs choisis dans un domaine bien précis (comme réserver une table pour n personnes dans une restaurant d’une certaine catégorie, dans un lieu et pour un certain créneau) [USI]. Le risque cette fois est que le comportement approximatif de cet utilisateur artificiel n’engendre des biais comportementaux dans l’agent qu’il entraîne, et ceci en dépit de son infinie patience.
  • La définition d’une fonction de récompense est une tâche délicate. Un agent RL s’exécutera sans aucun état d’âme pour atteindre son objectif une fois celui-ci fixé. Ainsi un agent ayant pour mission de vendre un service pourra se livrer, pour parvenir à ses fins, à toutes sortes d’excentricités verbales qu’un comportement civilisé prohiberait vraisemblablement.

Les deux formes d’apprentissage, supervisé et par renforcement, peuvent naturellement être panachés. Pour éviter les problèmes de cold start par exemple, on peut initialiser un agent conversationnel avec un apprentissage supervisé basé sur un corpus conversation, puis à mesure que s’accumulent les échanges avec de vrais utilisateurs, on pourra progressivement enclencher un apprentissage par renforcement qui affinera le comportement de l’agent [TEE].

2.3 Les questions à trancher

Synthétisons la discussion du paragraphe précédent sous forme de liste, non exhaustive, d’options parmi lesquelles il conviendra de choisir pour concevoir un agent conversationnel.

Apprentissage automatique ou arbres de décision ?

Construire un agent conversationnel à l’aide d’arbres de décisions qui cherchent à anticiper tous les échanges reste une approche encore utilisée dans de nombreux chatbots, même celle-ci nécessite un laborieux travail de scénarisation propre à chaque cas d’utilisation. Aucun progrès substantiel en termes de flexibilité n’est à attendre de ce côté et toutes les approches innovantes utiliseront dorénavant une forme de Machine Learning.

Apprentissage E2E ou module par module ?

L’apprentissage supervisé module par module exige de disposer de données d’entraînement correctement annotées qui peuvent s’avérer couteuses à fabriquer. Lorsqu’elle est praticable cette approche présente toutefois plusieurs avantages. Elle permet d’intégrer relativement aisément du code métier pour tenir compte de règles que l’on ne souhaite pas faire apprendre à l’agent. Disjoindre la logique de dialogue de la génération de réponse présente en outre l’avantage de pouvoir créer aisément des agents multilingues.

L’approche E2E autorise l’entraînement sur des données conversationnelles brutes non annotées. Elle dispense par ailleurs d’avoir à concevoir une notion explicite d’état conversationnel car le système l’apprendra sous forme de variables latentes induites par le processus d’apprentissage.

Entraînement avec des utilisateurs réels ou artificiels ?

L’entraînement d’un agent qui utilise le RL demande de soumettre l’agent à de nombreuses interactions avec des utilisateurs réels ou artificiels. Les utilisateurs humains sont impatients mais dotés de bon sens et produisent une grande diversité de dialogues. Les simulateurs d’utilisateurs sont d’une patience infinie mais sont limités à entraîner des agents Task Oriented. De plus, par leurs limitations, ils risquent d’induire des biais dans le comportement de l’agent qu’ils entraînent.

Synthèse des réponses ou utilisation de templates ?

Dans les solutions actuelles, les réponses d’un agent conversationnel sont le plus souvent sélectionnées par la DP parmi un ensemble des templates complétés à la volée. Cette manière de faire garantit la justesse syntaxique des locutions mais elle est incapable de faire face à une situation imprévue, sinon à utiliser un message générique. Les réponses générées dynamiquement n’ont pas cette limitation mais sont peu fiables au sens où elles sont parfois grammaticalement incorrectes.

Comment prendre en compte des contraintes métiers ?

Il existe deux raisons principales pour inclure des règles métiers explicites dans la logique de conversation. D’une part des contraintes réglementaires ou des impératifs de sécurité peuvent l’imposer. D’autre part, la prise en compte explicite d’une règle allège d’autant la quantité et la complexité des données d’entraînement qui seraient nécessaires pour l’apprendre [WDN]. Ce codage explicite est cependant difficile à incorporer à une approche E2E basée sur le Deep Learning.

Utilisation de l’apprentissage par renforcement ?

Nous ne reviendrons pas sur l’apprentissage supervisé dont les atouts et les inconvénients ont déjà été évoqués. Le cadre conceptuel de l’apprentissage par renforcement apparaît particulièrement bien adapté à la conversation artificielle. Une conversation peut en effet être assimilée à une succession de décisions à l’issue desquelles on évalue la satisfaction d’un utilisateur. L’agent apprend en même temps qu’il interagit avec les utilisateurs. La grande quantité de données nécessaire pour le RL exige cependant de disposer d’un simulateur d’utilisateurs, ce qui limite l’application du RL à des agents conversationnels Task Oriented pour lesquels on peut définir sans trop de difficulté la satisfaction d’un utilisateur.

3. Zoom sur deux approches end-to-end

Dans cette section nous allons décrire succinctement deux architectures proposées récemment [DDQ, HCN] pour construire des agents conversationnels entraînés sur un mode E2E. Chaque solution opte pour des compromis différents parmi les alternatives présentées précédemment.

3.1 Entraînement économique via un simulateur et Deep Dyna-Q

Construire des agents conversationnels capables d’apprendre rapidement à partir de quelques exemples de conversation entre humains reste pour l’instant une gageure. Dans un article récent [DDQ] des chercheurs ont tenté de relever le défi en restreignant le problème aux agents Task Oriented.

Figure 4 : le mécanisme Deep Dyna-Q fait coopérer trois mécanismes d’apprentissage, un RL direct de l’agent avec de vrais utilisateurs, un RL indirect basé sur un simulateur qui s’améliore en continu sur la base de l’expérience avec de vrais utilisateurs.

Leur idée principale est illustrée dans la figure 4, elle consiste à faire coopérer trois mécanismes d’apprentissage : un apprentissage par RL de l’agent face à des utilisateurs réels, un apprentissage par RL face à un simulateur et enfin une amélioration continue de ce simulateur sur la base des conversations réelles. Le cadre conceptuel de ce type d’apprentissage a été conçu dans les années 90 et s’appelle Dyna-Q [RLI].

Les auteurs de [DDQ] nomment leur méthode Deep Dyna-Q (DDQ) car elle met en œuvre deux réseaux de neurones (pas si profonds en réalité), un pour l’agent et un pour le simulateur. D’une certaine manière le problème d’entraînement de l’agent est converti en un jeu à trois acteurs : l’agent, le simulateur et les vrais utilisateurs.

Figure 5 : l’architecture DQN rajoute un module de simulation d’utilisateur à l’architecture de base.

Venons-en aux détails. L’architecture DDQ représentée dans la figure 5 rajoute un module à l’architecture de base illustrée sur la figure 1 : le simulateur.

Figure 6 : en fonction de l’état de la conversation et de la dernière action de l’agent le simulateur génère une réponse à l’agent (l’action), une valeur pour la récompense et décide d’arrêter ou non la conversation. L’implémentation utilise deux couches denses partagées, deux classifieurs et une régression.

En fonction de l’état s de la conversation et de la dernière action at choisie par l’utilisateur ce simulateur génère : (1) une réponse à l’agent, (2) une récompense et (3) une décision de terminer ou non la conversation. Il est entraîné à reproduire au mieux le comportement de vrais utilisateurs (voir l’étape d. de l’algorithme Deep Dyna-Q dans l’encadré ci-dessous). Il est implémenté comme un RN (MLP) multitâche à deux couches partagées comme l’illustre la figure 6.

Dans le cadre du RL de l’agent, on définit les notions suivantes :

  • L’état s d’une conversation à un instant t est défini par un état caché d’un RNN (comme dans la figure 3) qui encapsule l’historique de la conversation. Cet état n’est pas observé directement, c’est une variable latente déduite des observations que sont les messages échangés avec l’utilisateur.
  • L’action a que sélectionne la DP de l’agent lorsqu’il est dans l’état s est une décision qui, dans ce cas, est un type d’énoncé, du genre : « poser telle question à l’utilisateur », « lui confirmer son choix », « lui dire merci » etc…, un énoncé éventuellement précisé par une ou plusieurs entités identifiées par le module NLU.
  • La récompense r définie dans [DDQ] correspond à l’attribution de 80 points à une conversation jugée réussie, d’une pénalité de -40 à une conversation jugée comme ayant échoué et d’une pénalité -1 à chaque nouvel échange pour inciter l’agent à n’être pas trop bavard.

La figure 7 (c) illustre comment les trois mécanismes d’apprentissage coopèrent et l’encadré ci-dessous les décrit sur un plan séquentiel dans l’algorithme Deep Dyna-Q.

Figure 7 : (a) apprentissage RL direct avec de vrais utilisateurs, (b) apprentissage RL direct avec le simulateur (c) apprentissage direct et indirect via un simulateur affiné en continu pour reproduire au mieux le comportement des vrais utilisateurs.

Dans l’encadré ci-dessous Q(s,q ;θ) désigne l’estimation courante par la DP du gain que l’agent cumulera à long terme s’il choisit l’action a alors qu’il se trouve dans l’état s et s’il continue à utiliser cette même stratégie par la suite. Dans l’étape b. on améliore la stratégie courante en choisissant (le plus souvent) une action qui maximise Q(s,q ;θ). Dans l’étape c. on ajuste les paramètres  de l’estimation Q(s,q ;θ) pour qu’elle corresponde au mieux aux gains effectivement observés. L’estimation Q(s,q ;θ), qu’on appelle l’action-value function, est implémentée comme un simple RN à une couche cachée.

 

 

Algorithme Deep Dyna-Q
  • L’agent et le simulateur sont tous deux pré-entraînés à partir de transcriptions de vraies conversations entre humains portant sur la réalisation de la tâche que l’on souhaite voir réalisée par l’agent conversationnel. Cette étape initialise donc la action-value function Q(s,a; θ) de l’agent et celle du simulateur M(s,a; φ).

# RL direct de l’agent conversationnel avec 1 vrai utilisateur

  • Itérer sur N=400 étapes environ
    • Un vrai utilisateur démarre une nouvelle conversation
    • Pour chaque échange de cette conversation
    • Le plus souvent sélectionner l’action a qui maximise l’estimation Q(s,a; θ) pour favoriser l’exploitation
    • De temps en temps choisir une action a au hasard pour favoriser l’exploration
    • Exécuter l’action a sélectionnée
    • Observer la récompense r envoyée par l’utilisateur
    • Enregistrer l’échange dans un buffer D utilisateur
    • Mettre à jour l’état s de la conversation dans le ST
  • Échantillonner des échanges dans D utilisateur et ajuster les paramètres  pour faire en sorte que l’estimation Q(s,a; θ) prédite par la DP soit proche des valeurs observées dans D utilisateur.

# Entraînement du simulateur sur les conversations existantes

  • Échantillonner des échanges dans D utilisateur et ajuster les paramètres f pour faire en sorte que les estimations M(s,a; φ ) prédites par le simulateur soient proches des valeurs observées sur les échantillons.

# RL indirect de l’agent conversationnel avec K utilisateurs fictifs

  • Créer K objectifs de conversations au hasard et demander au simulateur de démarrer ces conversations
  • Pour chacune de ces conversations procéder comme en b. et c. du point 2 sauf que l’on utilise un buffer D simulateur distinct de D utilisateur.

 

Les résultats expérimentaux semblent démontrer l’intérêt d’intercaler un grand nombre K de simulations entre deux interactions avec des utilisateurs réels comme l’illustre la figure 8.

Figure 8 : Le taux de succès des conversations augmente fortement lorsque le nombre K de conversations artificielles croit car on optimise ainsi l’usage des données réelles – [DDQ]

3.2 Entraînement incrémental et intégration de code métier

Incorporer du code métier ou des templates de réponses dans un agent conversationnel s’avère une solution très efficace pour limiter de manière drastique le volume des données d’entraînement. Intuitivement, l’idée est d’économiser un important travail d’apprentissage de la part de l’agent au prix d’un modeste effort de codage pour un développeur. Hélas, les approches E2E qui construisent une réponse à partir d’un historique de conversation avec un RNN, par nature opaque, ne s’y prêtent pas naturellement. Dans [HCN] les auteurs proposent cependant une approche hybride prometteuse, Hybrid Code Networks (HCN) qui parvient à concilier un entraînement E2E et l’intégration de code métier pour réaliser des agents conversationnels peu gourmands en données et qui ne sont pas nécessairement Task Oriented.

Figure 9 : Architecture Hybrid Code Network (HCN) proposée dans [HCN], voir le texte. Les rectangles noirs représentent des modules entraînables. Les trapèzes correspondent à du code métier.

La figure 9 illustre l’architecture HCN, les encadrés encapsulent, approximativement, les quatre fonctions décrites précédemment dans la section 2. Sans entrer dans les détails que l’on trouvera dans [HCN] en voici les principaux éléments :

  • Dans le module NLU l’extraction d’entités utilise un module ML usuel. On lui adjoint un module métier (le trapèze) qui permet à un développeur de définir des variables prédictives qu’il jugera utiles pour aider en aval les modules ST et DP à sélectionner une action correcte. Au besoin il peut aussi définir un masque qui empêchera la DP de sélectionner certaines actions en fonction des entités identifiées. Les six rectangles verticaux représentent autant de features qui numérisent le message en entrée.
  • Le module ST est implémenté à l’aide d’un RNN, un vecteur caché correspondant à l’état qui alimentera la DP implémentée comme un simple classifieur chargé du calcul de l’action la plus vraisemblable, une action correspondant au choix d’un template de réponse. La DP tient compte par ailleurs du masque d’action.
  • Le module Response Generation incorpore le code métier « entity output » qui construit une réponse complète à partir du template sélectionné par le DP et des entités identifiées par le NLU ou invoque une API métier qui à son tour peut contribuer à l’état du système à l’étape suivante.

Cette architecture HCN réduit considérablement la complexité d’apprentissage.

Le framework Open Source RASA

L’architecture HCN a en particulier inspiré celle du framework Open Source RASA [RAS] qui ambitionne de jeter un pont entre les laboratoires de recherche en NLP et les développeurs métiers non spécialisés. RASA est constitué de deux API : RASA NLU et RASA Core (le Dialog Manager). Comme HCN, RASA permet de construire des chatbots généralistes et ne se limite pas à des agents Task Oriented.

Certaines options retenues par les concepteurs de RASA diffèrent toutefois de l’architecture HCN :

  • RASA ne propose pas d’entraînement E2E et sépare délibérément l’entraînement du module NLU de celui du module RASA Core qui implémente la logique de dialogue. L’un des avantages de ce choix est qu’il offre la possibilité de réutiliser une même logique de dialogue pour créer rapidement des chatbots multilingues.
  • RASA Core propose aussi un entraînement supervisé classique basé sur l’écriture par les concepteurs de stories qui sont des exemples de conversations entre le bot et les utilisateurs.
  • RASA propose aussi un mode Machine Teaching pour accélérer l’entraînement de la logique de dialogue dans RASA Core. Au lieu d’évaluer une conversation lorsque celle-ci s’achève, ce que l’on fait avec le RL, RASA propose à l’entraîneur de corriger le comportement d’un agent au coup par coup, après chaque réponse. Une fois corrigée la conversation vient enrichir la liste de stories disponibles pour l’entraînement. Un tel apprentissage interactif est plus efficace que le RL à condition d’avoir suffisamment d’utilisateurs disposés à jouer les tuteurs de chatbot.

4.   Du provisoire qui pourrait durer…

Nos agents conversationnels, rigides et dépourvus de bon sens, font pâle figure si on les compare aux fantasmes véhiculés par la science-fiction. Sans modèle du monde, procédant par associations statistiques, ils n’ont de l’intelligence et du sens de la conversation que l’apparence, et encore, à condition que l’échange ne s’écarte pas d’un chouia du minuscule domaine qu’on leur a assigné.

Pour l’instant leur conception est un bric-à-brac fait de ML supervisé, d’apprentissage par renforcement, de règles métier codées en dur et de transcriptions fastidieuses de conversations humaines, un art qui exige de faire beaucoup de compromis comme on l’a vu. Faute d’une percée conceptuelle majeure en IA que rien n’annonce, il y a fort à parier que la conception d’agents conversationnels restera dans les années à venir un labeur fastidieux, du moins si le résultat doit être autre chose qu’un gadget agaçant.

Pour autant, à condition de maîtriser la délicate notion de contexte conversationnel, ils pourront s’avérer utiles dans des circonstances précises comme l’ont démontré les systèmes de Google et de Baidu. L’exécution de tâches dont l’objectif et la progression peuvent aisément être formalisés sont les situations auxquelles ils seront le plus adaptés. A ce propos, on gardera à l’esprit que, dans un contexte commercial, un client ne sait bien souvent pas ce qu’il veut. Il regarde, il rêvasse, il hésite. Il est donc illusoire de chercher à représenter son intention comme un enregistrement dans une base de données qu’un chatbot Task Oriented aurait à deviner au moyen d’un interview serré.

Voilà une bonne nouvelle pour le marché l’emploi : les métiers commerciaux ne sont pas prês de disparaître !

En revanche, pour s’entretenir avec HAL 9000 [2], il faudra encore patienter un peu.

Notes

[1] Nous n’évoquerons pas ici les approches classiques par arbres de décision qui, bien qu’encore largement utilisées, n’ouvrent pas de perspectives d’innovation significatives.

[2] Personnage IA du film Odyssée 2001.

Références

Newsletter

Inscrivez-vous à notre newsletter pour recevoir nos dernières actualités*

Les informations recueillies sur ce formulaire sont enregistrées dans un fichier informatisé de gestion des Clients et Prospects (CRM).

Le Responsable de traitement est la société weave, 37 rue du rocher 75008 Paris RCS Paris 802 396 085.

Elles sont destinées à l’activité marketing du groupe weave ainsi quà celle de ses filiales, à l’exclusion de tout transfert hors de l’UE. Elles sont conservées pour une durée conforme aux dispositions légales (par exemple 3 ans pour les données prospects).

Ce traitement nécessite votre consentement que vous pourrez retirer à tout moment sans que cela ne remette en cause sa licéité.

Conformément à la loi « Informatique et Libertés » et au règlement européen n°2016/679, vous bénéficiez d’un droit d’accès, de rectification ou d’effacement, ainsi que d’un droit à la portabilité de vos données ou de limitation du traitement. Vous pouvez également pour des raisons tenant à votre situation particulière, vous opposer au traitement de vos données et donner des directives relatives à la conservation, à l’effacement et à la communication de vos données après votre décès. Vous disposez également du droit d’introduire une réclamation auprès de la Commission Nationale de l’Informatique et des Libertés (www.cnil.fr).

Vous pouvez exercer vos droits en nous contactant à l’adresse vosdonnees@weave.eu.

En poursuivant votre navigation sur ce site, vous acceptez l’utilisation de cookies pour mesurer notre audience, vous proposer des contenus et des offres personnalisées, ainsi que des fonctionnalités de partage sur les réseaux sociaux. En savoir plus sur notre politique de cookies et notre charte des données personnelles