Le problème fondamental des LLM et pourquoi le RAG existe
Les modèles de langage (LLM) comme GPT-4, Claude ou Llama sont entraînés sur d’immenses corpus de textes publics. Ils possèdent des connaissances générales impressionnantes mais souffrent de deux limitations majeures pour un usage professionnel. D’abord, leurs connaissances s’arrêtent à une date de coupure : ils ne connaissent pas les informations publiées après leur entraînement. Ensuite, ils n’ont aucune connaissance de vos données privées : les documents internes de votre entreprise, vos procédures, vos historiques clients ou vos catalogues produits leur sont totalement inconnus.
Le RAG (Retrieval-Augmented Generation), introduit par Patrick Lewis et ses collègues chez Meta AI dans un article de recherche publié en 2020, résout ces deux problèmes en ajoutant une étape de recherche documentaire avant la génération de réponse. Au lieu de se fier uniquement à sa mémoire interne, le modèle consulte d’abord une base de connaissances externe pour trouver les informations pertinentes, puis génère sa réponse en s’appuyant sur ces documents. C’est comparable à la différence entre répondre à une question de mémoire et répondre en consultant d’abord ses notes de cours.
Comment fonctionne un système RAG en détail
Un système RAG comporte trois composants principaux : une base de connaissances vectorielle, un mécanisme de recherche sémantique et un modèle de langage pour la génération. Le processus se déroule en quatre étapes séquentielles lors de chaque requête utilisateur.
La première étape est le découpage des documents sources en segments (chunks) de taille gérable, typiquement entre 200 et 1000 tokens. Chaque segment est ensuite transformé en un vecteur numérique (embedding) par un modèle d’embedding comme text-embedding-ada-002 d’OpenAI ou sentence-transformers en open source. Ces vecteurs capturent le sens sémantique du texte : deux textes qui parlent du même sujet auront des vecteurs proches mathématiquement, même s’ils utilisent des mots différents.
La deuxième étape est le stockage de ces vecteurs dans une base de données vectorielle spécialisée comme Pinecone, Weaviate, Chroma ou Qdrant. Ces bases de données sont optimisées pour la recherche par similarité : étant donné un vecteur de requête, elles trouvent rapidement les vecteurs les plus proches dans la base.
La phase de requête : de la question à la réponse
Quand l’utilisateur pose une question, la troisième étape commence. La question est transformée en vecteur par le même modèle d’embedding que celui utilisé pour indexer les documents. Ce vecteur est envoyé à la base vectorielle qui retourne les K segments les plus similaires (K est généralement entre 3 et 10). Ces segments constituent le « contexte » pertinent pour répondre à la question.
La quatrième et dernière étape est la génération. Les segments retrouvés sont insérés dans le prompt envoyé au LLM, avec une instruction du type : « Réponds à la question de l’utilisateur en te basant uniquement sur les documents suivants. Si l’information n’est pas dans les documents, dis-le. » Le LLM synthétise alors les informations des documents pour produire une réponse cohérente et sourcée.
Choisir la bonne stratégie de découpage des documents
Le découpage (chunking) est l’étape la plus déterminante pour la qualité du RAG. Un découpage trop fin (50 tokens) perd le contexte nécessaire à la compréhension. Un découpage trop large (2000 tokens) dilue l’information pertinente avec du contenu non pertinent et consomme inutilement la fenêtre de contexte du LLM.
La stratégie de découpage doit s’adapter au type de document. Pour des documents techniques structurés (documentation, manuels), un découpage par section ou par en-tête (heading) préserve la cohérence logique. Pour des textes longs sans structure marquée, un découpage par paragraphes avec un chevauchement (overlap) de 10 à 20 % entre les segments améliore la couverture contextuelle. La bibliothèque Python LangChain propose plusieurs types de text splitters adaptés à différents cas d’usage.
Évaluer et améliorer la qualité de votre RAG
La qualité d’un système RAG se mesure sur deux dimensions : la précision de la recherche (le système retrouve-t-il les bons documents ?) et la qualité de la génération (la réponse est-elle fidèle aux documents retrouvés ?). Pour la recherche, les métriques standard sont le recall@K (parmi les K documents retournés, combien sont pertinents) et le MRR (Mean Reciprocal Rank, position moyenne du premier résultat pertinent).
Pour améliorer la recherche, plusieurs techniques sont efficaces. Le re-ranking consiste à utiliser un modèle spécialisé (comme Cohere Rerank ou un cross-encoder) pour réordonner les résultats de la recherche vectorielle initiale. Le query expansion reformule la question de l’utilisateur pour capturer davantage de résultats pertinents. Le filtrage par métadonnées (date, source, catégorie) réduit l’espace de recherche et améliore la précision.
Outils et frameworks pour construire un RAG
Plusieurs frameworks simplifient la construction d’un système RAG. LangChain (Python et JavaScript) est le plus populaire, avec des intégrations pour la plupart des LLM, bases vectorielles et sources de documents. LlamaIndex (anciennement GPT Index) est spécialisé dans l’indexation et la recherche documentaire avec des stratégies de chunking avancées. Haystack de deepset est une alternative robuste pour les déploiements en production.
Pour un prototype rapide, vous pouvez utiliser l’API Assistants d’OpenAI qui intègre nativement une fonctionnalité RAG : vous téléchargez vos fichiers, et l’assistant les consulte automatiquement pour répondre aux questions. Pour un contrôle total et une utilisation en production, construire votre propre pipeline avec LangChain et une base vectorielle dédiée offre la flexibilité nécessaire pour optimiser chaque composant.
Cas d’usage concrets du RAG en entreprise
Le RAG trouve des applications dans de nombreux contextes professionnels. Le support client intelligent interroge la base de connaissances des FAQ et de la documentation technique pour répondre aux questions des clients. L’assistant juridique consulte les textes de loi et la jurisprudence pour fournir des réponses contextualisées. L’onboarding des employés donne accès aux procédures internes, aux politiques RH et aux guides de démarrage via une interface conversationnelle.
Dans le contexte africain, le RAG permet de créer des assistants multilingues qui consultent des documents en français, anglais et langues locales. Une entreprise sénégalaise peut construire un assistant qui répond aux questions sur ses produits et services en français et en wolof, en s’appuyant sur sa documentation interne, sans nécessiter un fine-tuning coûteux du modèle de base.