Accueil › Glossaire › Task-Oriented Dialogue

Task-Oriented Dialogue

Un task-oriented dialogue system (TOD, système de dialogue orienté tâche) est un système conversationnel conçu pour aider l’utilisateur à accomplir une tâche spécifique (réserver un restaurant, modifier une commande, résoudre un problème technique) en conduisant un dialogue multi-tours structuré, en collectant les informations nécessaires et en interagissant avec des systèmes externes (bases de données, APIs) pour fournir le résultat attendu.

TOD vs. Open-Domain : la distinction fondamentale

Un système de dialogue peut avoir deux objectifs radicalement différents. Un système open-domain (ou chitchat) vise à maintenir une conversation engageante et naturelle, sans objectif précis. ChatGPT en mode conversation libre est un exemple d’open-domain. Un système task-oriented a un but concret : compléter une tâche mesurable (réservation confirmée, problème résolu, information fournie). La conversation n’est pas une fin en soi, c’est un moyen d’atteindre un résultat.

Cette distinction a des implications techniques profondes. Un TOD doit gérer un état structuré (quels slots sont remplis ?), interagir avec des systèmes externes (bases de données, APIs, CRM), respecter des contraintes métier (un hôtel ne peut pas être réservé s’il est complet), et guider activement la conversation vers la complétion de la tâche (demander les informations manquantes, confirmer, exécuter).

L’architecture pipeline classique

L’architecture qui a dominé le domaine pendant une décennie décompose le système en quatre modules séquentiels :

1. NLU (Natural Language Understanding) : comprend le message utilisateur. Décomposé en intent classification (identifier l’objectif : « réserver », « annuler », « modifier ») et slot filling (extraire les paramètres : date, lieu, nombre de personnes). Les modèles BERT/DIET sont les standards pour ce module.

2. DST (Dialogue State Tracking) : maintient l’état cumulatif de la conversation. À chaque tour, le DST met à jour l’ensemble des slot-values : {restaurant_type: italien, date: ce soir, nb_personnes: 4, heure: 20h}. Il gère les corrections (« Pas 4, 6 personnes »), les confirmations et la mémoire du contexte. C’est le composant le plus évalué en recherche, avec la Joint Goal Accuracy comme métrique principale (~60% sur MultiWOZ pour les meilleurs systèmes).

3. Policy Learning : décide de l’action suivante du système étant donné l’état du dialogue. Actions possibles : demander un slot manquant, interroger la base de données, proposer un résultat, confirmer, finaliser. La politique peut être à base de règles, apprise par renforcement (RL) ou par apprentissage supervisé sur des dialogues annotés. Voir dialogue management pour plus de détails.

4. NLG (Natural Language Generation) : transforme l’action système en réponse en langage naturel. L’action inform(restaurant=Chez Marco, cuisine=italien, prix=€€) devient « J’ai trouvé Chez Marco, un restaurant italien à prix modéré. Voulez-vous réserver ? » Historiquement basé sur des templates, le NLG est aujourd’hui dominé par les LLMs qui génèrent des réponses naturelles et variées.

Approches end-to-end

Les approches end-to-end traitent l’ensemble du pipeline dans un modèle unique, éliminant la propagation d’erreurs entre modules :

End-to-end modulaire

Un seul modèle partage des représentations entre les sous-tâches, mais produit des sorties intermédiaires (dialogue state, action) en plus de la réponse finale. C’est le meilleur compromis entre performance et interprétabilité.

SimpleTOD : un modèle causal unique (GPT-2 fine-tuné) qui traite séquentiellement toutes les sous-tâches dans un format texte linéarisé : historique → belief state → résultats DB → action système → réponse. Simple et efficace.

PPTOD (Plug-and-Play TOD) : un modèle T5 pré-entraîné sur quatre tâches TOD avec des prompts spécifiques. Son avantage : il peut être entraîné avec des données partiellement annotées, réduisant le coût de création de datasets.

GALAXY/SPACE : une série de modèles développés par Alibaba DAMO Academy qui acquièrent la politique de dialogue par apprentissage semi-supervisé, combinant dialogues annotés et non annotés.

End-to-end complet (LLM-based)

Un LLM gère l’intégralité du dialogue sans modules séparés :

InstructTODS : un framework zero-shot qui utilise un LLM pour générer un « proxy belief state » qui traduit les intentions utilisateur en requêtes dynamiques vers une base de connaissances. Les évaluations humaines montrent que les réponses d’InstructTODS surpassent les réponses gold ET les systèmes SOTA en helpfulness, informativeness et naturalness, sans aucune donnée d’entraînement spécifique.

SyncTOD : une approche qui injecte la base de données en JSON directement dans le prompt du LLM, lui permettant de générer la réponse en une seule étape. Les résultats surpassent les modèles SOTA en few-shot et en full-data.

LAMIA (ACL 2025) : combine un LLM avec un DSL (Domain-Specific Language) pour les systèmes de dialogue en robotique industrielle. Le LLM gère la compréhension et la génération, le DSL contrôle la logique métier. C’est l’architecture hybride la plus aboutie présentée récemment.

Datasets de référence

MultiWOZ reste le benchmark central malgré ses problèmes connus d’annotation (les versions 2.1 à 2.4 corrigent progressivement les erreurs). SGD (Schema-Guided Dialogue) est le plus ambitieux car il utilise des schémas de service explicites qui décrivent les intents et slots disponibles, facilitant le transfer cross-domaine. TaskMaster est unique car il contient des dialogues réels entre humains et assistants virtuels, pas des dialogues simulés entre crowdworkers.

Défis spécifiques du TOD

Cross-domaine et multi-domaine

Un dialogue réel traverse souvent plusieurs domaines : « Je veux réserver un restaurant italien près de l’hôtel que j’ai réservé hier, et aussi un taxi pour y aller. » Le système doit gérer les transitions entre domaines, partager l’information entre contextes (l’adresse de l’hôtel est un slot implicite pour le taxi), et maintenir un état cohérent à travers les domaines. SGD et MultiWOZ évaluent cette capacité.

Requêtes indirectes

« Il fait froid ici » au lieu de « Augmentez la température. » Les requêtes indirectes nécessitent un raisonnement pragmatique que les systèmes NLU classiques ne gèrent pas bien. Des travaux récents (IndirectRequests dataset, basé sur SGD) montrent que les LLMs gèrent mieux ces cas que les modèles spécialisés plus petits, mais des lacunes persistent.

Interaction avec les bases de connaissances

Le TOD doit interroger des bases de données en temps réel pour fournir des informations factuelles (disponibilité, prix, horaires). Le défi est de traduire l’état du dialogue en requête structurée, d’intégrer les résultats dans la réponse, et de gérer les cas où aucun résultat ne correspond (proposer une alternative). InstructTODS résout ce problème en générant un « proxy belief state » que le LLM traduit en requête dynamique.

Cohérence dialogique

Maintenir la cohérence sur un dialogue de 15-20 tours est un défi, surtout avec les LLMs. Des travaux formalisent la cohérence dialogique comme un Constraint Satisfaction Problem (CSP), montrant que les LLMs SOTA ne respectent les contraintes de cohérence que dans 15% des cas pour les dialogues re-lexicalisés, un chiffre alarmant qui souligne la nécessité de guardrails.

Multilingue

Les systèmes TOD entraînés sur des données parallèles (traduites de l’anglais) montrent des performances dégradées par rapport aux systèmes natifs, même avec des modèles multilingues. Des biais d’adaptation et des biais intrinsèques persistent pour les langues comme l’arabe ou le turc. Pour le français, les modèles multilingues (Mistral, mBERT, XLM-R) combinés avec des LLMs en zero-shot sont la meilleure option.

Implémenter un TOD

Option 1 : Rasa (pipeline classique)

Rasa est le framework open source le plus mature pour les TOD en production. Il fournit un pipeline NLU (DIET pour intent + slots), un dialogue manager (stories + rules + forms pour la collecte de slots), et des connecteurs vers les bases de données et APIs. C’est le choix pour les systèmes avec des parcours bien définis et des exigences de fiabilité élevées.

Option 2 : LangGraph (LLM-centric)

LangGraph permet de construire des TOD basés sur un LLM avec un graphe d’états. Chaque nœud du graphe est une étape du dialogue (accueil, collecte d’info, recherche, confirmation), implémentée par un appel LLM avec un prompt spécifique. Les transitions sont contrôlées par des conditions sur l’état. Le function calling gère l’interaction avec les APIs externes.

# Exemple simplifié avec LangGraph
from langgraph.graph import StateGraph
from langchain_core.messages import SystemMessage

# Définir l'état
class DialogState(TypedDict):
    messages: list
    slots: dict
    task_complete: bool

# Nœud : collecte d'information
def collect_info(state):
    system_msg = SystemMessage(content="""
    Vous êtes un assistant de réservation de restaurant.
    Collectez : type de cuisine, date, heure, nb personnes.
    Slots actuels : {state['slots']}
    Demandez les slots manquants un par un.
    """)
    # Appel LLM avec l'historique + system message
    response = llm.invoke(state["messages"] + [system_msg])
    return {"messages": state["messages"] + [response]}

# Construire le graphe
graph = StateGraph(DialogState)
graph.add_node("collect", collect_info)
graph.add_node("search", search_restaurants)
graph.add_node("confirm", confirm_booking)
# Ajouter les transitions conditionnelles...

Option 3 : LLM pur avec system prompt

Pour un prototype rapide ou un TOD simple, un LLM avec un system prompt bien conçu suffit :

system_prompt = """Vous êtes un assistant de réservation.
Votre objectif : aider l'utilisateur à réserver un restaurant.

Informations à collecter (dans l'ordre) :
1. Type de cuisine
2. Date et heure
3. Nombre de personnes
4. Préférences (budget, quartier)

Règles :
- Demandez UNE information à la fois
- Confirmez chaque info reçue
- Quand tout est collecté, résumez et demandez confirmation
- Ne proposez JAMAIS de restaurant sans avoir tous les slots
- Si l'utilisateur change d'avis, mettez à jour les infos"""

Cas d’usage

Service client : résolution de problèmes techniques, modification de commandes, gestion de réclamations. Le domaine le plus déployé, avec Gartner estimant 80 milliards de dollars d’économies sur les coûts des centres de contact d’ici 2026.

Réservations : restaurants, hôtels, vols, rendez-vous médicaux. Le domaine le mieux couvert par les benchmarks (MultiWOZ, SGD).

RH et IT interne : demandes de congés, déclarations de notes de frais, réinitialisation de mots de passe, demandes d’accès. Le dataset HR-MultiWOZ est le premier à couvrir ce domaine.

Robotique industrielle : LAMIA (ACL 2025) démontre un TOD pour un robot de tri, avec des dialogues multi-tours en espagnol pour recevoir et exécuter des instructions de tri.

Commerce et vente : qualification de leads, recommandation de produits, configuration de services. Le TOD collecte les besoins du client et propose des solutions adaptées.

Verdict

Le task-oriented dialogue est en transition rapide de l’architecture pipeline classique (NLU → DST → Policy → NLG) vers des approches LLM-centric end-to-end. Les évaluations humaines montrent que les systèmes LLM zero-shot (InstructTODS) rivalisent avec les systèmes pipeline entièrement fine-tunés en qualité de réponse, tout en éliminant le besoin de données annotées.

Cependant, la production exige de la fiabilité (pas d’hallucination), de la contrôlabilité (respect des contraintes métier) et de l’auditabilité (tracer chaque décision), trois qualités que les LLMs seuls ne garantissent pas. L’architecture hybride (LLM pour le langage + logique déterministe pour les décisions) est le consensus qui émerge, incarné par des frameworks comme LAMIA et LangGraph.

Pour un projet concret en français : Rasa pour un chatbot structuré avec des parcours bien définis, LangGraph + Claude ou GPT-5.4 pour un agent conversationnel flexible, ou un LLM avec un system prompt détaillé pour un prototype rapide.