Attention, dialogue et apprentissage de modèles réutilisables

Rasa Core est un système de dialogue open source basé sur l'apprentissage automatique destiné à la construction d'assistants à l'IA contextuelle de niveau 3. Dans la version 0.11, nous avons fourni notre nouvelle politique d'intégration (REDP), qui est beaucoup mieux adaptée aux utilisateurs peu coopératifs que notre LSTM standard (les utilisateurs de Rasa le verront sous le nom de KerasPolicy). Nous présentons un article à ce sujet à NeurIPS, et cet article explique le problème que REDP résout et son fonctionnement.

Notre nouveau modèle de dialogue (REDP) surpasse nos stratégies LSTM standard en ce qui concerne les utilisateurs peu coopératifs. Ces parcelles sont expliquées plus en détail ci-dessous.

Les utilisateurs peu coopératifs rendent la vie d’un développeur difficile

La difficulté avec laquelle vous construisez un bon assistant d’intelligence artificielle consiste à gérer les innombrables manières par lesquelles vos utilisateurs s’écartent de la voie heureuse. REDP, notre nouvelle politique de dialogue, présente deux avantages: (1) il est beaucoup plus efficace pour apprendre à gérer un comportement peu coopératif et (2) il peut réutiliser ces informations lors de l’apprentissage d’une nouvelle tâche.

Qu'entendons-nous par comportement peu coopératif? Pour illustrer ce propos, prenons l'exemple de la recommandation de restaurant, toujours très populaire, mais il en va de même pour la création d'un assistant de dépannage informatique, de support client ou autre. Supposons que vous ayez besoin de 3 informations d’un utilisateur pour recommander un endroit où manger. L'approche évidente consiste à écrire une boucle while pour demander ces 3 choses. Malheureusement, le vrai dialogue n’est pas si simple et les utilisateurs ne vous donneront pas toujours les informations que vous avez demandées (du moins pas tout de suite).

Lorsque nous demandons à un utilisateur "quelle gamme de prix cherchez-vous?", Il peut répondre par:

  • «Pourquoi avez-vous besoin de savoir cela?» (Contexte étroit)
  • “Pouvez-vous me montrer encore quelques restaurants?” (Contexte général)
  • “En fait non, je veux de la nourriture chinoise” (correction)
  • “Je devrais probablement cuisiner plus pour moi-même” (bavardage)

Nous appelons tout ce comportement peu coopératif. Un utilisateur peut réagir de nombreuses autres manières, mais dans notre document, nous étudions ces quatre types différents. Voici un exemple de conversation:

Dans chaque cas, l’assistant doit répondre de manière utile au message (non coopératif) de l’utilisateur, puis orienter la conversation dans la bonne direction. Pour faire cela correctement, vous devez prendre en compte différents types de contexte. Votre dialogue doit rendre compte de l'état à long terme de la conversation, de ce que l'utilisateur vient de dire, de ce que l'assistant vient de dire, des résultats des appels d'API, et plus encore. Nous décrivons cela plus en détail dans cet article.

L'utilisation de règles pour gérer les comportements non coopératifs devient compliquée

Si vous avez déjà construit deux assistants d’AI ou des chatbots, vous vous rendrez probablement compte de la migraine que vous avez et vous pouvez passer à la section suivante. Mais essayons d’élaborer quelques règles pour l’une des réponses les plus simples et les plus courantes sans coopération: je ne sais pas. Pour aider un utilisateur à trouver un cas de restaurant, nous pourrions poser des questions sur la cuisine, l'emplacement, le nombre de personnes et la fourchette de prix. L’API que nous interrogeons demande une cuisine, un lieu et un nombre de personnes, mais la fourchette de prix est facultative.

Nous voulons que notre assistant se comporte comme suit: si l’utilisateur ne connaît pas la réponse à une question facultative, passez à la question suivante. Si la question n'est pas facultative, envoyez un message pour les aider à le comprendre, puis donnez-leur une autre chance de répondre. Jusqu'ici, si simple.

Mais si l’utilisateur dit que je ne le sais pas deux fois de suite, vous devez passer à la vitesse supérieure (par exemple, confier à un agent humain ou au moins reconnaître que cette conversation ne se déroule pas très bien). Sauf bien sûr, si l’un des «Je ne sais pas» répondait à une question facultative.

Vous pouvez très bien gérer autant de logique avec quelques instructions if imbriquées. Toutefois, pour faire face à de vrais utilisateurs, vous devrez gérer de nombreux types de comportement non coopératif, et pour chaque objectif utilisateur que votre assistant prend en charge. Pour un humain, il est évident que la bonne chose à faire est, mais il n’est pas si facile d’écrire et de maintenir un ensemble cohérent de règles qui le rendent ainsi. Et si nous pouvions construire un modèle capable de comprendre ces modèles de dialogue et de les réutiliser dans de nouveaux contextes?

Le REDP prend en compte le dialogue non coopératif

L'attention est l'une des idées les plus importantes de l'apprentissage en profondeur de ces dernières années. L'idée principale est que, en plus d'apprendre à interpréter les données d'entrée, un réseau de neurones peut également apprendre quelles parties des données d'entrée doivent être interprétées. Par exemple, un classificateur d'images capable de détecter différents animaux peut apprendre à ignorer le ciel bleu à l'arrière-plan (ce qui n'est pas très informatif) et à porter une attention particulière à la forme de l'animal, à ses pattes et à la forme de sa tête. .

Nous avons utilisé la même idée pour traiter les utilisateurs peu coopératifs. Après avoir répondu correctement au message de non-coopération d’un utilisateur, l’assistant doit revenir à la tâche initiale et pouvoir continuer comme si la déviation n’était jamais arrivée. Le REDP y parvient en ajoutant un mécanisme d’attention au réseau de neurones, lui permettant d’ignorer les parties non pertinentes de l’historique des dialogues. L'image ci-dessous est une illustration de l'architecture REDP (une description complète se trouve dans le document). Le mécanisme d’attention est basé sur une version modifiée de la machine de Turing neurale et, au lieu d’un classificateur, nous utilisons une approche d’intégration et de classement, comme dans le pipeline d’intégration de Rasa NLU.

L’attention a déjà été utilisée dans les recherches sur le dialogue, mais la politique d’incorporation est le premier modèle qui utilise l’attention spécifiquement pour traiter un comportement peu coopératif et pour réutiliser ces connaissances dans une tâche différente.

REDP apprend quand NE PAS faire attention

Dans la figure ci-dessous, nous montrons une histoire Rasa Core au milieu et une conversation correspondante à droite. Sur la gauche, un graphique à barres illustre l'attention que notre modèle accorde aux différentes parties de l'historique de conversation lorsqu'il sélectionne la dernière action (utter_ask_price). Notez que le modèle ignore complètement les messages utilisateur antérieurs non coopératifs (il n'y a pas de barre à côté de chitchat, correct, expliquer, etc.). La stratégie d’incorporation répond mieux à ce problème car, après avoir répondu à la question d’un utilisateur, il peut poursuivre la tâche en cours et ignorer que la déviation s’est produite. Les barres hachurées et pleines indiquent les pondérations de l’attention sur les messages de l’utilisateur et les actions du système, respectivement.

REDP est beaucoup mieux qu'un classifieur LSTM pour gérer les utilisateurs peu coopératifs

Ce graphique compare les performances de REDP et de Rasa Core LSTM standard (les utilisateurs de Rasa le reconnaîtront sous le nom de KerasPolicy). Nous traçons le nombre de dialogues dans l'ensemble de tests où chaque action est prédite correctement, à mesure que nous ajoutons de plus en plus de données d'apprentissage. Nous utilisons deux versions légèrement différentes du LSTM (pour plus de détails, lisez le document).

Réutilisation de modèles entre tâches

Nous ne voulions pas seulement savoir dans quelle mesure le REDP pouvait traiter les utilisateurs peu coopératifs, mais aussi s’il pouvait réutiliser ces informations dans un nouveau contexte. Par exemple, supposons que votre assistant Rasa dispose déjà de nombreuses données de formation provenant d'utilisateurs réels (qui ne coopèrent pas comme ils le sont toujours). Vous souhaitez maintenant ajouter un support pour un nouvel objectif utilisateur. Dans quelle mesure votre assistant peut-il gérer les déviations par rapport à la voie heureuse, même s’il n’a jamais été témoin d’un comportement peu coopératif dans cette tâche?

Pour tester cela, nous avons créé une scission de dialogues de test de train pour une tâche de réservation d'hôtel (contenant beaucoup de comportements peu coopératifs) et comparé la performance avec et sans inclure les données de formation d'une autre tâche (réservation de restaurant).

V1 de REDP a montré un grand avantage de l'apprentissage de transfert

L’intrigue ci-dessus montre quelques résultats pour une première version de REDP (pas la dernière, nous la montrerons ensuite). L'ensemble de test est dans le domaine hôtelier. Les carrés montrent comment la performance s'améliore lorsque nous incluons également des données de formation du domaine de la restauration. Les performances ont considérablement augmenté, ce qui montre que le REDP peut réutiliser les connaissances d’une tâche différente! Ceci est aussi appelé apprentissage par transfert. Voici le même complot pour le LSTM. Il existe des preuves d’apprentissage par transfert, mais il est beaucoup plus petit que pour le REDP:

V2 de REDP résout la tâche très rapidement

Ce graphique présente les résultats de la version «finale» de REDP, décrite dans le document et implémentée dans Rasa Core. La performance est bien meilleure que V1. Avec seulement la moitié des données, le REDP atteint une précision de test de presque 100%. L’apprentissage par transfert présente toujours des avantages, mais il n’ya guère de place pour l’amélioration lors de l’ajout des données de formation au restaurant.

Prochaines étapes

Nous sommes vraiment enthousiasmés par la politique d’intégration, et nous avons beaucoup d’expériences en cours pour montrer ce qu’elle peut faire. La première tâche que nous lui avons confiée a été réduite à néant. Nous nous attaquons donc à des problèmes encore plus difficiles pour étudier l’apprentissage par transfert à l’état sauvage.

Allez essayer REDP sur votre jeu de données! Le code et les données pour l'article sont disponibles ici. Veuillez partager vos résultats dans ce fil de discussion sur le forum Rasa.

Il vous reste encore beaucoup à faire pour que les 5 niveaux d’assistants d’IA deviennent une réalité. Si vous souhaitez résoudre ces problèmes et intégrer des solutions dans une base de code utilisée par des milliers de développeurs dans le monde entier, rejoignez-nous! Nous embauchons.

Publié à l'origine sur blog.rasa.com le 29 novembre 2018.