Accueil › Glossaire › Dialogue Management

Dialogue Management

Le dialogue management (gestion du dialogue) est le composant central d’un système de dialogue qui maintient l’état de la conversation, décide de l’action suivante à effectuer (demander une information, confirmer, exécuter une tâche, transférer à un humain) et orchestre l’interaction entre la compréhension du langage (NLU) et la génération de réponses (NLG) pour guider la conversation vers l’accomplissement de l’objectif de l’utilisateur.

Le cerveau du chatbot

Si l’intent classification est l’oreille du chatbot (comprendre ce que dit l’utilisateur) et la génération de texte est sa bouche (formuler la réponse), le dialogue management est son cerveau : il décide quoi faire à chaque tour de conversation.

Prenons un exemple concret. Un utilisateur dit : « Je veux réserver un restaurant italien pour ce soir. » Le NLU identifie l’intent (book_restaurant) et les slots (cuisine: italien, date: ce soir). Le dialogue manager reçoit ces informations, met à jour l’état de la conversation, constate que le nombre de personnes et l’heure ne sont pas spécifiés, et décide de l’action suivante : demander « Pour combien de personnes et à quelle heure ? » Il ne suffisait pas de comprendre le message ; il fallait raisonner sur ce qui manque, ce qui est connu, et ce qu’il faut faire ensuite.

Les deux sous-composants

Dialogue State Tracking (DST)

Le DST maintient une représentation structurée de l’état courant de la conversation : quels slots ont été remplis, quelles contraintes l’utilisateur a exprimées, quels résultats de recherche ont été présentés, et quel est l’historique des actions. L’état du dialogue est typiquement un ensemble de paires slot-valeur : {cuisine: italien, date: ce soir, nb_personnes: ?, heure: ?, lieu: ?}.

Le défi du DST est de gérer les corrections (« Finalement, pas italien, plutôt japonais »), les références implicites (« Le deuxième de la liste »), les confirmations partielles, et la coréférence au fil des tours de dialogue. Sur le benchmark MultiWOZ, les meilleurs systèmes DST atteignent environ 55-60% de Joint Goal Accuracy (pourcentage de tours où tous les slots sont correctement suivis simultanément), ce qui montre que la tâche reste difficile.

Policy Learning (PL)

La politique de dialogue détermine l’action suivante du système étant donné l’état courant. Les actions possibles incluent : demander un slot manquant (request(heure)), confirmer une valeur (confirm(cuisine=italien)), chercher dans une base de données (db_query), proposer un résultat (offer(restaurant=Chez Marco)), ou transférer à un humain (handoff).

La politique peut être apprise par renforcement (reinforcement learning), où le système apprend par essai-erreur à maximiser un score de réussite de la tâche, ou par imitation (supervised learning) sur des dialogues humains annotés.

Les grandes approches

Approche 1 : machines à états finis (rule-based)

L’approche la plus simple et la plus déployée en production. Le dialogue est modélisé comme un graphe d’états avec des transitions conditionnelles. Chaque état correspond à une étape du processus (accueil → collecte d’informations → recherche → confirmation → finalisation). Les transitions dépendent de l’input utilisateur et de l’état courant.

Rasa utilise cette approche via ses « stories » et ses « rules » qui définissent les parcours de dialogue attendus. Dialogflow et Amazon Lex utilisent des « flows » visuels similaires. Un système multi-party récent (Information, MDPI 2024) combine une state machine pour le contrôle du flux avec un LLM pour la compréhension du langage, atteignant 87% de taux de réussite des tâches et 89% en NLU.

Avantages : prédictibilité totale, facilité de debug, pas d’hallucination, conformité réglementaire. Limites : rigidité (chaque nouveau parcours doit être codé manuellement), incapacité à gérer les déviations imprévues, et coût de maintenance élevé quand le nombre de parcours croît.

Approche 2 : apprentissage par renforcement

La politique de dialogue est apprise par un agent RL qui interagit avec un simulateur d’utilisateur. L’agent reçoit une récompense quand la tâche est accomplie avec succès et une pénalité quand le dialogue échoue ou s’allonge inutilement. Les algorithmes courants incluent DQN, PPO et VTRACE.

ConvLab-3, le toolkit de recherche le plus complet pour les systèmes de dialogue, intègre des simulateurs d’utilisateur et des politiques RL. Les approches récentes utilisent des LLMs comme simulateurs d’utilisateur pour entraîner la politique RL, permettant de générer des dialogues d’entraînement plus diversifiés et réalistes sans intervention humaine.

Avantages : optimisation automatique, adaptation aux comportements utilisateur réels. Limites : nécessite un simulateur d’utilisateur réaliste (difficile à construire), convergence lente, comportements imprévisibles en edge cases.

Approche 3 : LLM end-to-end

L’approche la plus récente et la plus disruptive. Un LLM gère l’ensemble du pipeline de dialogue (NLU + DST + Policy + NLG) de manière unifiée. Le LLM reçoit l’historique complet de la conversation, un system prompt définissant le domaine et les contraintes, et produit directement la réponse suivante.

Le framework InstructTODS (2024) montre que cette approche atteint des performances comparables aux systèmes pipeline entièrement fine-tunés en zero-shot, sans données spécifiques. Les évaluations humaines montrent que les réponses LLM surpassent à la fois les réponses gold et les systèmes état de l’art en termes de qualité et de naturel.

Le framework LAMIA (ACL 2025) combine un LLM avec un DSL (Domain-Specific Language) pour conserver le contrôle sur la logique métier tout en bénéficiant de la flexibilité linguistique du LLM. C’est l’architecture hybride qui émerge comme la plus prometteuse : le LLM gère la compréhension et la génération de langage naturel, tandis qu’un système déterministe (state machine, DSL, API) gère la logique métier et les contraintes.

Approche 4 : hybride LLM + state machine

C’est la tendance dominante. Le système utilise une machine à états ou un graphe de décision pour structurer le flux de dialogue et garantir le respect des règles métier, tandis qu’un LLM gère la compréhension du langage naturel et la génération de réponses naturelles. Chaque nœud du graphe peut invoquer le LLM pour interpréter le message utilisateur ou formuler la réponse, mais les transitions et les actions sont contrôlées par la logique déterministe.

LangGraph (de LangChain) est un outil emblématique de cette approche : il permet de construire des graphes de dialogue avec des nœuds LLM, des conditions de branchement et des outils externes, combinant la flexibilité des LLMs avec la structure d’un workflow contrôlé.

Datasets et benchmarks

MultiWOZ est le benchmark de référence depuis 2018. Plusieurs versions corrigent des erreurs d’annotation progressivement (2.1, 2.2, 2.4). Le Joint Goal Accuracy sur MultiWOZ est la métrique la plus suivie en recherche DST. SGD (Schema-Guided Dialogue) de Google est le plus ambitieux avec plus de 20 domaines et un système de schémas explicites qui facilite le transfer cross-domaine.

Métriques d’évaluation

Task Success Rate : le pourcentage de dialogues qui aboutissent à l’accomplissement de la tâche. C’est la métrique la plus importante en production. Un chatbot qui comprend tout mais ne résout pas le problème est inutile.

Joint Goal Accuracy (JGA) : pour le DST, le pourcentage de tours où tous les slot-values du dialogue state sont correctement prédits. Métrique sévère (une seule erreur = échec du tour). Les meilleurs systèmes atteignent ~60% sur MultiWOZ.

Inform Rate : le pourcentage de dialogues où le système fournit l’information correcte demandée (par exemple, le bon restaurant correspondant aux critères).

BLEU score : mesure la qualité linguistique des réponses générées, par comparaison avec des réponses de référence. Moins pertinent avec les LLMs qui génèrent des réponses naturelles mais différentes des références.

Évaluation humaine : reste le gold standard. Les évaluations de InstructTODS montrent que les réponses LLM surpassent les réponses gold en helpfulness, informativeness et humanness, confirmant que les métriques automatiques sous-estiment la qualité des systèmes LLM.

Cas d’usage

Service client automatisé : le cas d’usage dominant. Le dialogue manager gère des flux comme la résolution de problèmes techniques (diagnostic → identification du problème → solution étape par étape → confirmation de résolution), les modifications de commande (identification → recherche → présentation des options → validation), et les réclamations (écoute → qualification → proposition de résolution → suivi).

Réservation et transaction : restaurants, hôtels, vols, rendez-vous médicaux. Le dialogue manager collecte les paramètres nécessaires, interroge les disponibilités, présente les options et confirme la réservation. C’est le domaine le mieux couvert par les benchmarks (MultiWOZ, SGD).

Assistants vocaux et smart home : Alexa, Google Assistant. Le dialogue manager gère les requêtes multi-tours (« Mets de la musique… Plus fort… Non, la chanson d’avant ») et les changements de contexte rapides (« Et sinon, quel temps fait-il demain ? »).

Agents IA autonomes : les agents planificateurs utilisent le dialogue management pour interagir avec l’utilisateur, collecter les informations nécessaires, et demander des confirmations avant d’exécuter des actions irréversibles (envoi d’email, paiement, modification de données).

Robotique : le framework LAMIA (ACL 2025) démontre le dialogue management pour un robot de tri industriel, où le système conduit une conversation multi-tours en espagnol pour recevoir des instructions de tri de cartouches d’encre. Les contraintes sont strictes : pas d’hallucination possible, les instructions doivent être correctement interprétées et exécutées.

L’impact des LLMs sur le dialogue management

Les LLMs transforment le dialogue management de plusieurs manières :

DST simplifié : au lieu d’un module DST dédié qui prédit des slot-values, le LLM maintient l’état du dialogue dans sa fenêtre de contexte. L’historique complet de la conversation est accessible à chaque tour. Pour les dialogues courts, c’est suffisant. Pour les dialogues longs, des techniques de compaction (résumé automatique du contexte) sont nécessaires.

Policy implicite : le LLM décide implicitement de l’action suivante via son prompt et ses instructions système. Un bon system prompt (« Vous êtes un agent de réservation. Collectez le lieu, la date, l’heure et le nombre de personnes avant de procéder à la réservation. Ne confirmez jamais sans avoir tous les paramètres. ») encode une politique de dialogue efficace.

NLG naturel : les réponses générées par un LLM sont nettement plus naturelles et variées que celles des templates classiques. C’est l’avantage le plus immédiat et le plus visible.

Zero-shot cross-domaine : un LLM peut gérer un nouveau domaine de dialogue sans ré-entraînement, simplement en modifiant le system prompt et les outils disponibles. C’est un avantage considérable par rapport aux systèmes pipeline qui nécessitent des données annotées par domaine.

Verdict

Le dialogue management est en pleine mutation. L’approche pipeline classique (NLU → DST → Policy → NLG avec des composants séparés) cède la place à des architectures LLM-centric où le modèle gère une partie croissante du pipeline. Mais la production exige de la fiabilité, de la prévisibilité et de l’auditabilité que les LLMs seuls ne garantissent pas encore.

Le consensus émergent est l’architecture hybride : LLM pour le langage (compréhension et génération), logique déterministe pour les décisions métier (state machine, rules, DSL), et function calling pour l’interface entre les deux. C’est ce que proposent Rasa Pro, LangGraph et les frameworks d’agents de nouvelle génération.

Pour un projet concret : si vous avez des parcours de dialogue bien définis et des contraintes métier strictes, commencez par Rasa avec des stories/rules. Si vous voulez de la flexibilité et que les risques d’hallucination sont acceptables, un LLM avec un bon system prompt et du function calling est la voie la plus rapide. L’idéal est de combiner les deux via LangGraph ou un framework équivalent.