RAG (Retrieval-Augmented Generation) : c'est quoi, concrètement ?

Un LLM, c’est un cerveau brillant qui a arrêté de lire le jour de son entraînement et qui n’a jamais ouvert tes documents internes. Le RAG, c’est l’astuce qui lui colle une bibliothèque sous le nez avant qu’il réponde : on va chercher les bons passages dans tes données, on les glisse dans le prompt, et le modèle répond à partir de ça plutôt que de sa mémoire floue. Résultat : moins d’hallucinations, accès à tes données privées, et des réponses que tu peux sourcer. Voici comment ça marche vraiment — et où ça casse encore.

La définition courte (et celle qui ne ment pas)

RAG = Retrieval-Augmented Generation : une architecture où, avant de répondre, le modèle récupère (retrieval) des passages de texte pertinents dans une base externe, puis génère (generation) sa réponse en s’appuyant sur ces passages injectés dans le prompt.

Le terme vient d’un papier de Patrick Lewis et al. publié à NeurIPS 2020. L’idée centrale tient en deux mots : combiner une mémoire paramétrique (ce que le modèle a appris dans ses poids, figé à la date d’entraînement) avec une mémoire non-paramétrique (un index de documents qu’on peut mettre à jour quand on veut, sans réentraîner quoi que ce soit).

La métaphore honnête : un LLM seul, c’est un candidat qui passe un examen à livre fermé, de mémoire. Le RAG, c’est le même candidat avec ses fiches ouvertes sur la table. Il reste faillible — mais il s’appuie désormais sur les bonnes sources au lieu d’inventer.

Ce que le RAG n’est pas : ce n’est pas du fine-tuning (tu ne modifies pas le modèle), ce n’est pas un simple « copier-coller de doc dans ChatGPT » à la main, et ce n’est pas magique — on verra plus bas que ça hallucine encore quand le retrieval rate sa cible.

Pourquoi tout le monde s’est mis au RAG : deux problèmes très concrets

Le RAG résout deux douleurs que tout founder ou dev qui a tenté de brancher un LLM sur son produit connaît par cœur.

1. Les hallucinations. Un LLM prédit le mot suivant le plus plausible au vu du contexte. Quand il ne sait pas, il ne dit pas « je ne sais pas » — il produit une suite plausible et fausse, avec un aplomb total. En ancrant la réponse dans des passages réels récupérés à la volée (le grounding), tu réduis nettement l’invention. Nuance importante, et je la garde honnête : le RAG réduit les hallucinations, il ne les élimine pas. L’étude Stanford de 2024 sur les outils juridiques RAG (Westlaw, Lexis+ AI) a mesuré des taux d’hallucination de 17 % à 33 % sur des produits commerciaux qui se vantaient d’être « hallucination-free ». Le RAG est un garde-fou, pas un vaccin.

2. Tes données privées et fraîches. Le modèle ne connaît ni ton contrat client signé hier, ni ta doc interne, ni les tickets de ton support. Le fine-tuning pour injecter ça coûte cher, vieillit instantanément, et un modèle peut restituer par bribes des données vues à l’entraînement. Le RAG, lui, va chercher l’info au moment de la requête : tu mets à jour ta base, et la réponse suivante est à jour. Pas de réentraînement. C’est exactement la logique d’agents qui « lisent 30 PDF avant d’agir » dont je parlais dans l’édition sur les percées à 1000 euros.

Comment ça marche, étape par étape (sans bullshit)

Un système RAG se découpe en deux temps : la préparation de la base (une fois, ou en continu) et la requête (à chaque question).

Phase 1 — Indexation (en amont) :

• Chunking. Tu découpes tes documents en morceaux (chunks) de quelques centaines de tokens. Trop gros : tu noies l’info. Trop petit : tu perds le contexte. C’est le réglage le plus sous-estimé du RAG.
• Embeddings. Chaque chunk passe dans un modèle d’embedding qui le transforme en vecteur — une liste de nombres (souvent 768 à 3072 dimensions) qui encode le sens du texte. Deux passages qui parlent de la même chose finissent proches dans cet espace, même sans mots en commun.
• Stockage. Ces vecteurs vont dans une base vectorielle (pgvector, Pinecone, Qdrant, Weaviate…) qui sait retrouver les plus proches voisins très vite.

Phase 2 — Requête (à chaque appel) :

• Embedding de la question. La requête de l’utilisateur est transformée en vecteur avec le même modèle.
• Recherche. On récupère les k chunks (les k passages, où k est un réglage — typiquement 3 à 10) dont le vecteur est le plus proche de celui de la question (similarité cosinus, le plus souvent). Les meilleurs systèmes mixent cette recherche sémantique avec une recherche lexicale par mots-clés (BM25) : c’est le hybrid search.
• Augmentation. On colle ces chunks dans le prompt : « Voici des extraits pertinents : […]. Réponds en t’appuyant uniquement dessus. »
• Génération. Le LLM rédige la réponse à partir du contexte fourni, idéalement avec des citations vers les sources.

Le maillon faible n’est presque jamais la génération — c’est le retrieval. Si la recherche te ramène le mauvais chunk, le meilleur GPT du monde répondra parfaitement… à côté.

Quand utiliser le RAG — et quand t’en passer

Le RAG n’est pas la réponse à tout. Voici la grille de décision que j’applique.

Utilise le RAG quand :

• Tu as un corpus qui change (doc produit, base de connaissance, catalogue, jurisprudence) et tu veux des réponses à jour sans réentraîner.
• Tu dois citer la source : support client, legal, médical, finance. La traçabilité est une feature, pas un détail.
• Tes données sont privées et tu ne veux pas les enfouir dans des poids de modèle.
• Le volume dépasse ce que tu peux raisonnablement coller dans une fenêtre de contexte à chaque appel.

Passe-t’en (ou complète-le) quand :

• Tu veux changer le style, le ton ou le format de sortie → c’est du fine-tuning, pas du RAG.
• Ton corpus est minuscule et stable (quelques pages) → glisse-le directement dans le prompt, le RAG est de l’ingénierie inutile.
• Tu as besoin d’un raisonnement profond sur l’ensemble du corpus, pas de retrouver des faits ponctuels → le RAG, qui pioche k chunks, risque de manquer la vue d’ensemble.

RAG vs long contexte ? Les modèles à fenêtre géante (centaines de milliers de tokens) laissent croire qu’on peut tout balancer dans le prompt et oublier le RAG. En pratique : c’est cher à chaque appel, c’est lent, et la précision se dégrade quand l’info utile est noyée au milieu d’un long contexte (lost in the middle). Le RAG reste plus économe, plus rapide et plus auditable pour la plupart des cas en production — un calcul de coût/latence qui rappelle les arbitrages d’inférence détaillés dans l’édition Cerebras vs Nvidia.

Les pièges qui font échouer 80 % des POC RAG

Un POC RAG se monte en un week-end. Un RAG fiable en production, c’est un autre métier. Les écueils récurrents :

• Chunking naïf. Découper tous les 500 caractères au milieu d’une phrase casse le sens. Découpe par structure (titres, paragraphes, sections), garde un chevauchement entre chunks, et conserve les métadonnées (source, date, auteur).
• Un seul embedding pour tout. Un modèle d’embedding entraîné sur de l’anglais généraliste sera médiocre sur ton jargon métier en français. Teste-en plusieurs, mesure le recall (la part des bons passages effectivement récupérés).
• Pas de reranking. La recherche vectorielle brute ramène souvent du presque-pertinent. Un reranker (un second modèle qui re-trie les k candidats par pertinence fine) améliore énormément la qualité finale. C’est souvent le meilleur rapport effort/gain du RAG.
• Zéro évaluation. « Ça a l’air de marcher » n’est pas une métrique. Construis un jeu de questions-réponses de référence et mesure : le retrieval ramène-t-il le bon doc ? La réponse est-elle fidèle au contexte (faithfulness) ? Sans ça, tu navigues à l’aveugle.
• Confiance aveugle. Rappelle-toi l’étude Stanford : même des produits pros à plusieurs millions hallucinent encore. Affiche les sources, laisse l’utilisateur vérifier, et ne déploie pas un RAG sur un domaine critique sans humain dans la boucle. C’est exactement le genre de prudence que défendait Stroustrup dans l’édition sur les trois patrons d’IA qui se contredisent.

Le RAG en une phrase pour ton board

Si tu dois pitcher le RAG à quelqu’un qui ne code pas : « C’est ce qui permet à une IA de répondre sur nos données à nous, à jour, en citant ses sources — sans qu’on ait à réentraîner ou exposer un modèle. »

C’est devenu l’architecture par défaut dès qu’on branche un LLM sur de la connaissance d’entreprise. Pas parce que c’est à la mode, mais parce que c’est le seul moyen raisonnable de concilier trois exigences contradictoires : données fraîches, données privées, et réponses vérifiables. Le fine-tuning ajuste comment le modèle parle ; le RAG ajuste de quoi il parle. La plupart des produits sérieux font les deux.

Le reste — le choix de la base vectorielle, le chunking, le reranking — c’est de l’artisanat. Important, mais secondaire face à la question de départ : est-ce que mon retrieval ramène vraiment la bonne info ? Réponds d’abord à ça.