- ACN_ATLAS
- Cours pratique
- Informatique
Formation Développer un assistant conversationnel avec Rasa et LlamaIndex
Concevoir, enrichir et déployer un assistant conversationnel hybride combinant Rasa, NLP et architecture RAG avec LlamaIndex
- Durée
- 3 jours
- Niveau
- Fondamental
- Modalités
- Présentiel / Distanciel
Description de la formation Rasa LlamaIndex
Qu'est-ce qu'un assistant conversationnel avec Rasa et LlamaIndex ?
Les assistants conversationnels sont devenus des interfaces privilégiées dans les secteurs de la banque et de l’assurance : qualification de leads, assistance client, collecte d’informations structurées, orientation vers les bons services. Deux approches dominent : les chatbots ML avec Rasa, robustes et maîtrisables, et les architectures RAG avec LlamaIndex qui connectent un LLM à une base de connaissances interne.
Pourquoi suivre une formation Développer un assistant conversationnel avec Rasa et LlamaIndex ?
Cette formation s’appuie sur le projet fil rouge DataInsure : les participants construisent le chatbot d’accueil et d’orientation client de la plateforme. Ce chatbot s’intègre avec les modèles précédemment construits : il appelle le classifieur documentaire PyTorch pour router les documents entrants et le modèle de churn TensorFlow pour alerter les conseillers sur les clients à risque de résiliation. LlamaIndex enrichit l’assistant d’une base de connaissances sur les CGU et contrats DataInsure.
Objectifs pédagogiques
À l'issue de cette formation Développer un assistant conversationnel avec Rasa et LlamaIndex, vous aurez acquis les connaissances nécessaires pour :
- Concevoir un chatbot intelligent.
- Gérer le traitement du langage naturel.
- Intégrer et déployer le chatbot.
- Optimiser la compréhension et les réponses.
Objectifs opérationnels
Savoir créer et déployer un assistant conversationnel.
Programme
Contenu du cours, module par module
11 modules
- Panorama des approches : chatbots à règles, ML (Rasa), LLM natifs, LLM augmentés (RAG)
- Architecture d’un assistant : NLU, dialogue management, actions, canaux
- Cas d’usage DataInsure : accueil, qualification, orientation, FAQ
- Positionnement de Rasa : open source, maîtrise des données, déploiement on-premise
- Architecture de la plateforme DataInsure et place du chatbot dans l’écosystème IA
- Architecture d’un projet Rasa : domain.yml, nlu.yml, stories.yml, rules.yml, config.yml
- Installation et démarrage : rasa init, structure des fichiers, rasa train
- Composants du pipeline NLU : WhitespaceTokenizer, DIETClassifier
- L’interface Rasa Shell pour tester en ligne de commande
- Rasa X / Rasa Pro : l’interface d’annotation et d’amélioration continue
Travaux pratiques
Objectif : Créer le premier assistant DataInsure capable d’accueillir un client, d’identifier son besoin et de lui indiquer le bon service.
Description : Initialisation du projet Rasa DataInsure. Les participants définissent d’abord les cinq scénarios clients les plus fréquents (signaler un sinistre, demander un devis, résilier un contrat, poser une question sur sa garantie, être mis en relation avec un conseiller). Cette étape de conception en amont est intentionnelle : un chatbot mal conçu dès le départ ne sera jamais bon, quel que soit le raffinement NLU. Le domain.yml est créé avec les intents, les réponses et les actions nécessaires. Les premières stories sont rédigées, le modèle est entraîné et testé en shell. Le groupe confronte les formulations inattendues d’un client réel : « je veux changer ma formule », « y a eu un dégât des eaux » et obsèrve les premières limites.
Description : Initialisation du projet Rasa DataInsure. Les participants définissent d’abord les cinq scénarios clients les plus fréquents (signaler un sinistre, demander un devis, résilier un contrat, poser une question sur sa garantie, être mis en relation avec un conseiller). Cette étape de conception en amont est intentionnelle : un chatbot mal conçu dès le départ ne sera jamais bon, quel que soit le raffinement NLU. Le domain.yml est créé avec les intents, les réponses et les actions nécessaires. Les premières stories sont rédigées, le modèle est entraîné et testé en shell. Le groupe confronte les formulations inattendues d’un client réel : « je veux changer ma formule », « y a eu un dégât des eaux » et obsèrve les premières limites.
- Conception des intents : granularité, couverture, exemples diversifiés
- Entités : extraction par regex, lookup tables et DIETClassifier
- Qualité des données NLU : équilibre des classes, variations linguistiques
- Évaluation NLU : rasa test nlu, matrice de confusion des intents
- Augmentation des données : paraphrases, gestion des fautes d’orthographe
Travaux pratiques
Objectif : Améliorer la compréhension du langage naturel du chatbot DataInsure à partir de l’analyse des confusions NLU.
Description : Enrichissement du fichier nlu.yml avec des exemples variés couvrant le vocabulaire assurance (sinistre, dommage, couverture, franchise, cotisation…). Définition des entités métier : type_sinistre, num_contrat, date_incident. Après entraînement, rasa test nlu est exécuté et la matrice de confusion est analysée : quels intents sont confondus ? La paire « demande_resilier / demande_modifier » est intentionnellement ambiguë pour montrer comment les exemples mal choisis créent de la confusion. Les participants corrigent en divisant les intents ou en enrichissant les exemples et mesurènt l’impact sur les métriques NLU. Cette itération « tester / analyser / corriger » est le quotidien du développeur chatbot.
Description : Enrichissement du fichier nlu.yml avec des exemples variés couvrant le vocabulaire assurance (sinistre, dommage, couverture, franchise, cotisation…). Définition des entités métier : type_sinistre, num_contrat, date_incident. Après entraînement, rasa test nlu est exécuté et la matrice de confusion est analysée : quels intents sont confondus ? La paire « demande_resilier / demande_modifier » est intentionnellement ambiguë pour montrer comment les exemples mal choisis créent de la confusion. Les participants corrigent en divisant les intents ou en enrichissant les exemples et mesurènt l’impact sur les métriques NLU. Cette itération « tester / analyser / corriger » est le quotidien du développeur chatbot.
- Stories vs règles : quand utiliser l’une ou l’autre
- Structure d’une story : user steps, action steps, slots
- Politique de dialogue : TEDPolicy, RulePolicy, MemoizationPolicy
- Gestion des interruptions et des digressions
- Rasa Interactive : annotation interactive de conversations réelles
- Actions personnalisées : la classe Action et la méthode run()
- Le serveur d’actions : rasa run actions, endpoint.yml
- Appeler une API externe depuis une action : requêtes HTTP, gestion des erreurs
- Modifier les slots et le suivi de dialogue depuis une action
- Tests unitaires des actions avec pytest
Travaux pratiques
Objectif : Intégrer le classifieur documentaire PyTorch dans une action Rasa pour router automatiquement les documents reçus par DataInsure.
Description : Les participants implémentent une action Rasa « action_classifier_document » qui envoie une image de document reçue par le chatbot à l’endpoint TorchServe et récupère la catégorie prédite (sinistre / devis / résiliation). Selon la classification, l’assistant oriente le client vers le bon service et déclenche la story correspondante. Trois cas d’erreur sont implémentés : service indisponible, confiance NLU trop faible, catégorie inconnue. Cette intégration réelle d’un modèle ML dans un chatbot illustre comment les briques de la plateforme DataInsure fonctionnent ensemble.
Description : Les participants implémentent une action Rasa « action_classifier_document » qui envoie une image de document reçue par le chatbot à l’endpoint TorchServe et récupère la catégorie prédite (sinistre / devis / résiliation). Selon la classification, l’assistant oriente le client vers le bon service et déclenche la story correspondante. Trois cas d’erreur sont implémentés : service indisponible, confiance NLU trop faible, catégorie inconnue. Cette intégration réelle d’un modèle ML dans un chatbot illustre comment les briques de la plateforme DataInsure fonctionnent ensemble.
- Slots : types (text, bool, float, list, categorical), persistance et reset
- Formulaires : l’action FormAction, required_slots, slot_mappings
- Validation des slots : FormValidationAction
- Gestion des interruptions dans un formulaire : unhappy paths
- Cas d’usage : collecte d’un dossier de déclaration de sinistre
Travaux pratiques
Objectif : Construire le formulaire de déclaration de sinistre DataInsure avec validation métier et gestion des cas d’erreur.
Description : Implémentation d’un formulaire Rasa pour la déclaration de sinistre DataInsure : collecte du numéro de contrat, type de sinistre, date d’incident, description. La FormValidationAction vérifie que le numéro de contrat est au bon format (regex), que la date est dans le passé et que le type de sinistre correspond à une garantie active (vérification dans une API simulant le système de gestion DataInsure). Trois scénarios d’unhappy path sont implémentés : le client interrompt pour poser une question, fournit un numéro de contrat invalide, change d’avis sur le type de sinistre. La robustesse du formulaire est testée par tout le groupe avec des scénarios improbables pour révéler les cas non couverts.
Description : Implémentation d’un formulaire Rasa pour la déclaration de sinistre DataInsure : collecte du numéro de contrat, type de sinistre, date d’incident, description. La FormValidationAction vérifie que le numéro de contrat est au bon format (regex), que la date est dans le passé et que le type de sinistre correspond à une garantie active (vérification dans une API simulant le système de gestion DataInsure). Trois scénarios d’unhappy path sont implémentés : le client interrompt pour poser une question, fournit un numéro de contrat invalide, change d’avis sur le type de sinistre. La robustesse du formulaire est testée par tout le groupe avec des scénarios improbables pour révéler les cas non couverts.
- Stratégie de test : tests unitaires des actions, tests end-to-end, tests de régression NLU
- Analyse des conversations réelles : patterns d’échec, intents manquants
- Amélioration continue : cycle annotation → entraînement → évaluation
- Métriques clés : intent accuracy, entity F1, dialogue success rate
- Gestion du versionnement des modèles
Travaux pratiques
Objectif : Simuler le processus d’amélioration continue du chatbot DataInsure à partir de conversations réelles échouées.
Description : Un jeu de 30 conversations DataInsure échouées est fourni : clients ayant été mal orientés, formulaires abandonnés, intents non reconnus. Les participants analysent ces échecs, les catégorisent (problème NLU, problème de flow, manque d’intent, validation trop stricte) et définissent les corrections prioritaires. Les corrections sont implémentées, le modèle est réentraîné et les mêmes 30 conversations sont rejouées pour mesurer l’amélioration. Cette simulation d’un cycle d’amélioration continue est représentative du travail quotidien sur un chatbot en production.
Description : Un jeu de 30 conversations DataInsure échouées est fourni : clients ayant été mal orientés, formulaires abandonnés, intents non reconnus. Les participants analysent ces échecs, les catégorisent (problème NLU, problème de flow, manque d’intent, validation trop stricte) et définissent les corrections prioritaires. Les corrections sont implémentées, le modèle est réentraîné et les mêmes 30 conversations sont rejouées pour mesurer l’amélioration. Cette simulation d’un cycle d’amélioration continue est représentative du travail quotidien sur un chatbot en production.
- Limites des LLM natifs : hallucinations, données privées, kno cutoff
- Le paradigme RAG : retrieval + génération
- Architecture LlamaIndex : Data Connectors, Index, Query Engine
- Comparaison des approches : Rasa (déterministe) vs RAG (génératif) vs hybride
- Cas d’usage RAG DataInsure : FAQ sur les CGU, conditions de garanties, procédures
- Chargement de documents : SimpleDirectoryReader, connecteurs PDF, Word, CSV
- Chunking et Node Parsing : stratégies de découpage
- Modèles d’embedding : OpenAI, HuggingFace, Ollama pour les embeddings locaux
- Vector stores : FAISS, Chroma, Qdrant — critères de choix
- Évaluation de la qualité du retrieval : hit rate, MRR, precision@k
Travaux pratiques
Objectif : Indexer la base documentaire DataInsure (CGU, conditions de garanties) avec LlamaIndex et valider la pertinence des résultats de recherche.
Description : Chargement et indexation du corpus documentaire DataInsure (5 CGU produits, 3 guides de procédure, la grille tarifaire) avec LlamaIndex. Comparaison de deux stratégies de chunking : par taille fixe (512 tokens) et par section sémantique (découpage aux titres et sous-titres). Pour chaque stratégie, un jeu de 10 questions métier est testé (ex. : « quelle est la franchise pour un dégât des eaux ? ») et les passages récupérés sont évalués manuellement. Le VectorStore Chroma est persisté sur disque.
Description : Chargement et indexation du corpus documentaire DataInsure (5 CGU produits, 3 guides de procédure, la grille tarifaire) avec LlamaIndex. Comparaison de deux stratégies de chunking : par taille fixe (512 tokens) et par section sémantique (découpage aux titres et sous-titres). Pour chaque stratégie, un jeu de 10 questions métier est testé (ex. : « quelle est la franchise pour un dégât des eaux ? ») et les passages récupérés sont évalués manuellement. Le VectorStore Chroma est persisté sur disque.
- Intégrer LlamaIndex dans une action Rasa personnalisée
- Décider quand router vers le RAG et quand utiliser le dialogue structuré
- Construire un fallback intelligent : NLU confidence + RAG
- Chaîner retrieval et LLM : prompt engineering pour des réponses factuelles
- Gérer la citation des sources dans les réponses
Travaux pratiques
Objectif : Enrichir le chatbot DataInsure avec la base documentaire RAG pour répondre aux questions sur les garanties sans programmer chaque cas manuellement.
Description : Implémentation d’une action Rasa « action_ask_knowledge_base » qui interroge le VectorStoreIndex LlamaIndex construit dans le TP précédent. Le routage est implémenté : si la confiance NLU de l’intent est inférieure à 0.7 ou si l’intent est « ask_contract_details », l’action RAG est déclenchée. Test de l’assistant hybride sur 15 questions : 5 structurées (formulaire sinistre), 5 documentaires (garanties), 5 limites (questions hors-scope pour tester le fallback gracieux). Les participants observent que l’assistant n’a pas besoin de stories pour chaque question documentaire — le RAG l’en dispense — mais que le dialogue structuré reste indispensable pour les processus critiquest (déclaration, souscription). Ce modèle hybride est le pattern architectural de référence pour les assistants en production.
Description : Implémentation d’une action Rasa « action_ask_knowledge_base » qui interroge le VectorStoreIndex LlamaIndex construit dans le TP précédent. Le routage est implémenté : si la confiance NLU de l’intent est inférieure à 0.7 ou si l’intent est « ask_contract_details », l’action RAG est déclenchée. Test de l’assistant hybride sur 15 questions : 5 structurées (formulaire sinistre), 5 documentaires (garanties), 5 limites (questions hors-scope pour tester le fallback gracieux). Les participants observent que l’assistant n’a pas besoin de stories pour chaque question documentaire — le RAG l’en dispense — mais que le dialogue structuré reste indispensable pour les processus critiquest (déclaration, souscription). Ce modèle hybride est le pattern architectural de référence pour les assistants en production.
- Conteneurisation avec Docker : Dockerfile pour le modèle Rasa et le serveur d’actions
- Docker Compose : orchestrer Rasa, actions, vector store et APIs externes
- Canaux de déploiement : web socket, REST, Teams, WhatsApp
- Monitoring en production : logs de conversation, métriques de performance
- Sécurité et confidentialité : données PII, chiffrement, conformité RGPD
Programme mis à jour le 29/05/2026
Public concerné
Ce cours s’adresse aux développeurs AI et aux NLP engineers maîtrisant Python, souhaitant concevoir des assistants conversationnels robustes et déployables en production, capables de gérer des dialogues complexes et de s’intégrer aux systèmes métier.
Il intéressera également les data scientists impliqués dans des projets de chatbot ou de voicebot, et les architectes solutions évaluant les approches conversationnelles pour leur organisation.
Prérequis
Des connaissances solides en Python sont requises. Une familiarité avec les concepts de base du NLP (tokenisation, classification de texte, embeddings) et avec le ML facilitera la compréhension de Rasa NLU.
Des bases en développement web (API REST, JSON) et en Docker seront utiles pour les ateliers de déploiement. Une connaissance des APIs LLM facilitera l’intégration LlamaIndex.
J’évalue mes connaissances pour vérifier que je dispose des prérequis nécessaires pour profiter pleinement de cette formation en faisant le test de prérequis.
Faire le testFinancement
Cette formation peut être prise en charge par votre entreprise, seule ou avec l’appui de son opérateur de compétences. Nous fournissons le devis et les pièces attendues par l’OPCO.
Formations liées
- Intelligence Artificielle pour les spécialistes de l'ITRéf. IASI3 joursIntermédiaireProchaine session : 19 oct.2 090 €
- Intégrer les LLMs dans vos applications avec LangChainRéf. IADL3 joursFondamentalProchaine session : 12 oct.2 090 €
- Quarkus AIRéf. QUAI3 joursIntermédiaireProchaine session : 7 déc.2 090 €
- RAG Avancé et Agents Intelligents : Architectures, Graphes et DéploiementRéf. RAAI3 joursIntermédiaireProchaine session : 7 déc.2 090 €