Architecture RAG Moderne
Sommaire
Démo
Un chatbot juridique interne capable de répondre à des questions en s’appuyant sur une base documentaire enrichie par un pipeline RAG moderne.
Contexte
L’objectif de ce projet est de construire un pipeline RAG « moderne », ne pas simplement faire du retrieval classique, c’est-à-dire prendre la question de l’utilisateur, l’encoder avec un modèle d’embeddings, chercher les top-k chunks et espérer avoir la bonne réponse mais d’explorer les techniques récentes qui ont émergé pour améliorer significativement la qualité des réponses.
Le cas d’usage : un cabinet d’avocat en droit des affaires souhaite un chatbot interne sécurisé pour faciliter l’accès à l’information juridique. En plus du pipeline RAG, j’ai implémenté une couche de monitoring avec LangSmith, qui permet, grâce à LangChain, de faire nativement du tracing des appels LLM - et Elasticsearch + Kibana pour indexer et visualiser les logs de l’application.
Documents utilisés
Pour ce cas, les types de données étaient imposés : 3 formats distincts. Des fichiers TXT (notes pratiques, synthèses juridiques), des fichiers HTML (décisions administratives) et des fichiers CSV (tableaux réglementaires). Avant de construire le pipeline, j’ai commencé par faire de la veille sur la meilleure façon de traiter chaque format dans le contexte du RAG.
Pipeline d’ingestion (offline)
Preprocessing - TXT
Pour les fichiers texte, un preprocessing basique suffisait : normalisation des espaces et des retours à la ligne. Les fichiers étaient dans l’ensemble assez propres et ne nécessitaient pas de traitement particulier.
Preprocessing - HTML
Pour les fichiers HTML, la question était de savoir s’il fallait parser et nettoyer le HTML avant de l’indexer, ou le garder tel quel. Contre-intuitivement, HtmlRAG: HTML is Better Than Plain Text for Modeling Retrieved Knowledge in RAG Systems (2024) montre que le HTML, grâce à sa structure hiérarchique native (balises de titre, paragraphe, etc.), est meilleur que le texte brut pour le RAG : le LLM exploite la structure pour mieux comprendre le contexte de chaque chunk. J’ai donc conservé les fichiers HTML sans nettoyage agressif.
Preprocessing - CSV
Pour les fichiers CSV, la recommandation issue de la littérature est d’adopter une approche dite « header : valeur », plutôt que de traiter le CSV comme une table brute, on convertit chaque ligne en une phrase du type Objet : Encadrement reporting | Obligation : Documenter les flux financiers. Cette représentation est beaucoup plus proche du langage naturel et améliore la qualité des embeddings et donc du retrieval (Contextualising Tabular Data for Efficient Summarisation by Language Models, Allu et al., 2024).
Étant donné que les documents sont de taille réduite, j’ai choisi d’indexer chaque fichier source (CSV, HTML, TXT) comme un seul document avec un seul vecteur dans Elasticsearch - pas de chunking.
Pipeline d'inférence (online)
Le pipeline s’articule en 6 étapes qui s’enchaînent à chaque requête utilisateur. J’ai délibérément splitté la partie retrieval en deux branches parallèles : retrieval classique et HyDE. Afin de récupérer potentiellement des chunks différents, avant de les fusionner et de les reclasser.
Étape 1 - Guardrails
Étant donné que le domaine est restreint (juridique), j’ai implémenté une étape de guardrails par LLM juge en amont qui détermine si oui ou non la question est en lien avec le domaine juridique. Si la question est refusée, une justification est fournie afin de mieux comprendre les choix du LLM et d’améliorer les prompts.
Étape 2 - Query Rewriting
La question de l’utilisateur est ensuite réécrite pour être plus verbeuse et précise. Des études ont montré que des textes plus longs et détaillés tendent à améliorer la qualité des embeddings et, par conséquent, les performances du retrieval (Query Rewriting for Retrieval-Augmented Large Language Models, EMNLP 2023). La question reformulée est ensuite utilisée pour les deux branches du pipeline.
Étape 3 - HyDE
HyDE (Hypothetical Document Embeddings) : plutôt que d’effectuer le retrieval directement à partir de la question réécrite, on demande au LLM de générer une « réponse potentielle » hypothétique, puis on effectue le retrieval à partir de cette réponse. L’intuition : la réponse hypothétique sera sémantiquement plus proche des documents sources que la question elle-même, ce qui améliore la pertinence des chunks récupérés (Precise Zero-Shot Dense Retrieval without Relevance Labels, Gao et al., ACL 2023).
Étape 4 - Retrieval classique
En parallèle de HyDE, on effectue un retrieval classique par similarité cosinus directement à partir de la question réécrite. On obtient ainsi deux ensembles de chunks depuis deux sources différentes, qui seront ensuite fusionnés et reclassés à l’étape suivante. L’objectif est de maximiser le recall à cette étape.
Étape 5 - Reranking
Les chunks récupérés par les deux branches (retrieval classique et HyDE) sont fusionnés, puis passés à un modèle de reranking. Ce modèle, plus précis qu’une simple similarité cosinus, permet de sélectionner uniquement les chunks les plus pertinents pour la réponse finale. On maximise d’abord le recall au retrieval, puis la précision au reranking.
Étape 6 - Génération
Les chunks sélectionnés par le reranker sont finalement passés au LLM pour générer la réponse finale, enrichie uniquement par les documents les plus pertinents récupérés dans la base de connaissances.
Monitoring
Afin de maîtriser au mieux le comportement du pipeline, j'ai mis en place deux couches de monitoring complémentaires.
Elasticsearch & Kibana
Chaque appel LLM et chaque étape du pipeline sont logués dans Elasticsearch, ce qui permet de visualiser les traces via un dashboard Kibana. On peut ainsi voir en temps réel les questions posées, les chunks retrouvés, les réécritures effectuées et les décisions des guardrails.
LangSmith
LangSmith, l’outil de monitoring natif de LangChain, permet de visualiser en détail l’arbre d’exécution de chaque appel : inputs, outputs, tokens consommés, latence à chaque nœud. Très utile pour déboguer et optimiser les prompts.
