Explication de RAG : Empêcher les chatbots d’inventer des faits sur l’entreprise
Une présentation pratique du pipeline RAG : chargeurs, segmentation en blocs, embeddings, bases de données vectorielles, réclassement, recherche hybride et RRF — ainsi que les cas où il ne faut pas utiliser du tout la récupération d’informations.
Une tâche courante pour les premiers chatbots consiste à répondre aux questions issues de documents internes de l’entreprise. Un prototype rapide peut sembler parfaitement abouti — mais invente des faits. Il peut affirmer offrir un « soutien 24/7 dans 12 pays » alors que le support n’existe qu’en un seul pays, uniquement pendant les heures de bureau et seulement lorsque une personne informatique spécifique est disponible.
Ce type d’échec est justement l’objectif principal du RAG (Retrieval-Augmented Generation) : un modèle qui peut produire une réponse n’est pas identique à un modèle qui a accès aux vrais données de l’organisation. Sans cette base de données, les modèles performants se comportent comme un parent confiant qui invente l’histoire familiale lors d’un mariage — environ quarante pour cent de réponses correctes et cent pour cent de certitude.
Partie 1 : Qu’est-ce que le RAG, au juste ?
RAG signifie Retrieval-Augmented Generation. L’idée est simple.
Au lieu de demander au modèle de répondre uniquement en s’appuyant sur sa mémoire d’entraînement, le système récupère d’abord les documents pertinents, puis demande une réponse restreinte à ces documents.
Considérez le modèle de texte comme un stagiaire brillant mais trop confiant : excellent pour écrire, mais faible pour se souvenir de la politique RH de 2023. Le rôle du RAG est de mettre le document adéquat entre les mains du stagiaire avant même que la réponse ne commence.
Sans RAG : les réponses s’appuient sur la mémoire (obsolète, générique ou sans prise en compte de l’entreprise). Avec RAG : les réponses s’appuient sur la mémoire en plus des fichiers récupérés pour cette question.
Une formule concise et efficace :
Informations correctes × Contexte approprié × Prompt adapté = Réponse juste
Partie 2 : Le pipeline RAG
L’amélioration par récupération de données n’est pas une opération magique unique. C’est un processus en plusieurs étapes : si l’une d’elles échoue, les réponses arrivent en retard ou sont incorrectes.
Étape 1 — Sources de connaissances
Où se trouve le matériel ? Les PDF, les fichiers Word, les pages Notion, les tables SQL, les exportations Slack et les feuilles de calcul oubliées comptent tous comme des sources de connaissances.
Étape 2 — Chargeurs de documents (Intégration des données)
L’ingestion transforme les fichiers PDF/HTML/CSV, etc., en un format propre et uniforme — souvent quelque chose comme ceci :
Document(
page_content="The quick brown fox...",
metadata={"source": "annual_report.pdf", "page": 12, "author": "Finance Team"}
)
Éviter une charge minutieuse et verser directement des octets PDF bruts dans le flux a tendance à faire passer les en-têtes et pieds de page pour des « faits » (“Selon la page 47 sur 92…”). Personne n’a demandé ces éléments décoratifs.
Leçon : une ingestion sale entraîne des recherches sales et des réponses fausses. Nettoyez tout dès le début.
Étape 3 — Fragmentation (également appelée découpage)
Un PDF de 200 pages ne peut pas être intégré directement dans une requête. Les fenêtres de contexte sont limitées, et fournir au modèle tout un livre de recettes alors qu’une seule recette était demandée nuit à la précision.
Les documents sont donc divisés en segments.
Stratégies courantes :
- Chunking de taille fixe — découper tous les N tokens. Rapide, mais des coupes interviennent au milieu des phrases.
- Chunking de taille fixe avec chevauchement — mêmes coupes avec un léger chevauchement afin que le contexte des limites soit conservé. Valeur par défaut courante.
- Chunking hiérarchique/récursif — tenir compte des sections et des paragraphes avant de couper.
- Chunking sémantique — regrouper les phrases sur le même thème grâce aux embeddings. Plus intelligent, mais nécessite plus de ressources.
- Chunking basé sur des LLM / Agentic chunking — demander à un modèle où effectuer les coupes. Coûteux, utile pour les textes juridiques ou médicaux.
Une règle pratique, après avoir observé une division de contrat où « shall NOT be liable » suit « shall » : commencez par une taille fixe avec chevauchement ; n’ajoutez de complexité que lorsque la qualité de la récupération est réellement faible.
Étape 4 — Encodages (transformer des mots en coordonnées GPS)
sens, et non l’orthographe. Les phrases ayant un sens proche se trouvent à proximité les unes des autres, même si elles n’ont aucun mot en commun.
« Comment réinitialiser un mot de passe ? » et « Les identifiants d’accès ont été oubliés » ne partagent presque aucun terme, mais signifient pourtant à peu près la même chose. La recherche par mots-clés rate ce lien ; un outil d’encodage le détecte en comparant les sens.
L’histoire a évolué de Bag-of-Words (seulement des comptages) → TF-IDF → Word2Vec → BERT → vers des API d’encodage modernes et des modèles ouverts (OpenAI, Cohere, BGE, E5 et autres) qui tiennent compte du contexte.
Analogie : Bag-of-Words correspond à une traduction automatique mot par mot. Les encodages modernes ressemblent plutôt à quelqu’un ayant vécu dans les deux cultures et capable de comprendre l’intention.
Étape 5 — Stockage vectoriel (la bibliothèque où vous conservez toutes ces listes de nombres)
Lorsque les segments deviennent des vecteurs, ils nécessitent un stockage et une recherche rapides : Pinecone, Qdrant, Weaviate, Milvus, ChromaDB, FAISS et des systèmes similaires.
Étant donné une requête, retournez les K segments les plus pertinents dont les vecteurs sont les plus proches du vecteur de la requête. Les options d’indexation incluent :
- Force brute — comparer tout le contenu. Précis, mais lent à grande échelle.
- ANN (Proche voisin approximatif) — moins précis, mais beaucoup plus rapide. Valeur par défaut fiable.
- IVF — regrouper d’abord ; ne rechercher que dans les groupes prometteurs.
- HNSW — parcourir rapidement un graphe de voisins. Couramment utilisé dans les systèmes RAG en production.
L’utilisation de la force brute sur des millions de vecteurs « pour une précision parfaite » peut transformer des requêtes en quelques millisecondes en délais équivalents à une pause café. Adaptez l’index à la taille des données, et non à votre fierté.
Étape 6 — Récupération (Recherche de similarité)
Lorsqu’une question arrive, intégrez-la à l’aide du même modèle utilisé pour les fichiers — mélanger des modèles est une erreur classique — puis récupérez les segments similaires du top-K.
La similarité cosinus est la mesure habituelle : elle indique dans quelle mesure deux vecteurs sont alignés en direction, sans tenir compte de leur longueur. C’est une valeur par défaut stable quel que soit la longueur du texte.
Étape 7 — Augmentation (fournir au système le bon fichier)
Les segments récupérés sont insérés dans la demande accompagnée de la question de l’utilisateur. C’est là l’étape d’« augmentation » :
System: You are a helpful assistant. Only answer using the context below.
Context: [retrieved chunk 1] [retrieved chunk 2] [retrieved chunk 3]
Question: What is our refund policy?
Étape 8 — Génération (le LLM parle enfin)
C’est seulement alors que le modèle rédige la réponse finale — en s’appuyant sur le contexte obtenu et non sur des intuitions subjectives.
Partie 3 : Ce qui distingue « ça marche » de « ça marche bien »
Les tutoriels s’arrêtent souvent au flux de base. La qualité des systèmes en temps réel nécessite généralement davantage.
Re-classement — car le premier résultat de recherche n’est pas toujours le meilleur
La récupération à l’aide de bi-encodeurs est rapide mais grossière : la requête et le document sont encodés séparément, puis comparés. Elle est excellente pour réduire des millions d’éléments à environ 50 candidats.
« Rapide et approximativement correct » ne signifie pas toujours « vraiment correct », c’est pourquoi un re-classeur à cross-encodeurs, plus lent, évalue la requête et le document ensemble, permettant de prendre en compte les nuances, les négations et le contexte. Il ne fonctionne que sur la liste restreinte afin d’améliorer les vrais meilleurs résultats.
Analogie : les bi-encodeurs examinent rapidement les CV pour former une liste restreinte ; les cross-encodeurs organisent l’entretien.
Dans un bot de FAQ médical sans réclassement, une question concernant les interactions avec l’alcool peut faire apparaître un autre médicament qui ne partage que du vocabulaire similaire. Un réclasseur à base d’encodeur croisé corrige souvent ce problème immédiatement. Lorsque la précision est cruciale (en droit, en médecine, en finance), le réclassement est obligatoire et non optionnel.
Recherche hybride — car la recherche lexicale et la recherche vectorielle sont toutes deux un peu limitées seules
La recherche vectorielle saisit le sens mais peut manquer des éléments exacts — codes SKU, identifiants d’erreurs, noms propres. La recherche lexicale BM25 permet de trouver des chaînes exactes mais ignore les synonymes.
Recherche hybride combine la recherche BM25 et la récupération vectorielle : précision des mots-clés associée à une bonne capacité de rappel sémantique. Lorsque l’on hésite, la recherche hybride constitue un excellent choix par défaut — rarement pire, souvent meilleure.
Fusion RAG — combiner plusieurs opinions comme dans un projet de groupe (mais ça fonctionne vraiment cette fois)
Divers systèmes de récupération de documents (dense, basés sur des mots-clés, spécifiques à un domaine) génèrent plusieurs listes classées. RAG Fusion les fusionne à l’aide de Reciprocal Rank Fusion (RRF).
L’idée est simple, même si la formule semble formelle : un document qui se classe en tête selon plusieurs méthodes indépendantes est probablement pertinent. RRF privilégie la cohérence entre les listes plutôt que des scores bruts qui ne sont pas comparables entre différents systèmes de récupération.
RRF(d) = Σ 1 / (k + rank_i(d))
Ici, k vaut généralement 60 — c’est une convention du secteur plutôt qu’une constante dérivée.
Métadonnées — les étiquettes qui vous sauveront la vie plus tard
Les métadonnées sont des données sur les données : titre, auteur, date, source, niveau d’accès. Elles semblent peu intéressantes jusqu’à l’apparition d’une règle d’accès — « ne jamais montrer les documents internes RH aux utilisateurs externes » — et c’est alors que les balises access_level: internal deviennent cruciales.
Les métadonnées permettent l’application de filtres, des améliorations de classement, un contrôle d’accès et le débogage (« pourquoi un document de 2019 a-t-il répondu à une question de 2026 ? » → filtres de date manquants).
Mémoire et mise en cache — car personne ne veut payer deux fois pour la même calcul
Deux concepts souvent confondus :
- Mémoire = mémorisation à long terme des préférences, des échanges précédents et des faits durables.
- Mise en cache = réutilisation à court terme de résultats coûteux (réponses du modèle, résultats de recherche) pour des demandes répétées.
La mémoire permet aux assistants de paraître cohérents. La mise en cache les rend rapides et économiques. Les combiner — par exemple en mettant en cache des préférences avec une durée de vie de dix minutes — peut effacer le nom d’un utilisateur au milieu d’une conversation. Gardez ces concepts séparés.
Partie 4 : Quand ne pas utiliser RAG ?
L’amélioration par récupération d’informations n’est pas une solution universelle.
Évitez RAG lorsque :
- La question relève de connaissances générales que le modèle maîtrise déjà (« capitale de la France » n’a pas besoin d’index vectoriel).
- Les faits évoluent constamment (prix, scores en direct) — privilégiez une API.
- La tâche est purement créative (poésie, brainstorming) — la récupération d’informations est rarement utile.
- Le corpus est suffisamment petit pour être inclus directement dans l’instruction.
- Une latence extrêmement faible ne permet pas d’ajouter une étape supplémentaire de récupération.
Parfois, la solution réside dans l’élaboration de bonnes instructions ou le fine-tuning, et non dans un flux vectoriel complet. Choisissez l’outil avant de concevoir toute infrastructure.
Partie 5 : Bonnes pratiques apprises à la dure
- Divisez le texte de manière intelligente, pas en segments trop petits. Les segments trop petits perdent le contexte ; les segments trop gros perdent en précision. Préférez des chevauchements.
- Utilisez un même outil d’embedding pour les fichiers et les requêtes. Mélanger des modèles revient à utiliser des unités incompatibles.
Les équipes qui traitent la récupération des données comme une étape secondaire découvrent généralement les mêmes problèmes : dérive silencieuse du schéma dans les chargeurs, limites de blocs qui divisent les négations, incohérences entre les modèles d’incorporation utilisés pour l’indexation hors ligne et les requêtes en ligne, ainsi que des tableaux de bord ne mesurant que le « délai de réponse » tout en ignorant la fiabilité des résultats. Une pratique RAG solide considère chaque étape du processus comme une interface produit avec des responsables, des tests et des plans de réversion — surtout lorsque l’assistant est utilisé devant des clients ou dans des workflows réglementés.
Lors de l’évaluation des modifications, privilégiez les expériences en paires : même ensemble de questions, même grille d’évaluation, comparez le Recall@k et le niveau de pertinence avant et après une modification concernant le découpage en blocs ou le réordonneur. De petits gains en termes de récupération des données surpassent souvent de plus grandes modifications basées uniquement sur les prompts, car le générateur ne peut pas citer ce qui n’a jamais été inclus dans la fenêtre de contexte.
Le mantra RAG
Informations correctes → Contexte adéquat → Prompt approprié → Réponse juste.
RAG est une méthode technique, pas de la magie. Un flux d’entrée propre, un système de récupération judicieux, une augmentation honnête des données, ainsi qu’un prompt bien formulé transforment un outil trop confiant en un spécialiste informé qui lit d’abord le fichier — et évitent ainsi l’invention d’un service de support mondial disponible 24/7 qui n’a jamais existé.