Qu'est-ce que le RAG
RAG (Retrieval-Augmented Generation) est une approche où un modèle de langage trouve des fragments pertinents dans votre base de connaissances avant de répondre, puis génère du texte. Au lieu de "mémoriser" tous les documents dans les poids du modèle ou de les charger entièrement dans le contexte, le système cherche les bons morceaux et les injecte dans le prompt. Ci-dessous - ce qu'est le RAG, comment fonctionne le pipeline et quand la méthode est pertinente en production.
Définition en termes simples
Retrieval-Augmented Generation combine deux étapes :
- Retrieval (récupération) - à partir de la question de l'utilisateur, le système trouve les fragments de texte les plus adaptés dans un corpus : wiki, PDF, tickets, code, règlements.
- Generation (génération) - le LLM reçoit ces fragments comme contexte et formule la réponse en s'appuyant sur eux.
Le terme s'est imposé après Lewis et al. (2020) et est devenu standard pour les chatbots d'entreprise, le support et les assistants internes. Le RAG ne remplace pas le modèle - il le complète avec des données actuelles absentes de l'entraînement ou modifiées hier.
Comment fonctionne le RAG : pipeline typique
┌──────────┐ ┌─────────────┐ ┌──────────────┐ ┌─────────┐
│Documents │───▶│ Chunking + │───▶│ Vector DB │ │ │
│ (PDF, MD)│ │ Embeddings │ │ (index) │ │ LLM │
└──────────┘ └─────────────┘ └──────┬───────┘ │ │
│ │ │
Requête ──▶ Embedding ──▶ Top-K ──▶ Prompt + contexte ──▶ Réponse
1. Préparation des données (offline)
- Ingestion - parsing PDF, HTML, Markdown, Confluence, Notion, dépôts.
- Chunking - découpage en fragments de 256-1024 tokens avec chevauchement pour ne pas couper le sens en fin de paragraphe.
- Embedding - chaque chunk devient un vecteur via un modèle d'embeddings (OpenAI text-embedding-3, Cohere, BGE, E5 open source).
- Indexation - vecteurs stockés dans un vector store : Pinecone, Weaviate, Qdrant, pgvector, Chroma, Milvus.
Cette étape s'exécute à l'ajout ou à la mise à jour des documents, pas à chaque requête utilisateur.
2. Requête (online)
- La question utilisateur est aussi embedée avec le même encodeur.
- La vector DB renvoie les Top-K chunks les plus proches (souvent K = 3-10).
- Optionnellement - reranking : un second modèle reclasse les candidats plus finement que la similarité cosinus seule.
- Les fragments trouvés entrent dans le prompt system/user avec l'instruction de "répondre uniquement à partir du contexte".
- Le LLM génère la réponse ; des citations vers l'id du chunk ou la page source sont souvent ajoutées.
La qualité du RAG dépend à ~80% du retrieval : si le bon fragment n'est pas dans le Top-K, le modèle hallucine ou dit honnêtement "je ne sais pas".
Composants clés
| Composant | Rôle | Exemples |
|---|---|---|
| Modèle d'embedding | Texte → vecteur pour recherche sémantique | text-embedding-3-large, bge-m3, voyage-3 |
| Base vectorielle | Stockage et recherche ANN rapide | Qdrant, Pinecone, pgvector, Weaviate |
| Stratégie de chunking | Équilibre détail vs bruit | Taille fixe, split sémantique, par titres |
| LLM | Réponse finale avec raisonnement | GPT-5.6, Claude Fable 5, Gemini 3.1, modèles locaux |
| Orchestrateur | Enchaîne les étapes, cache, logs | LangChain, LlamaIndex, Haystack, code maison |
En 2026 de nombreux frameworks (LlamaIndex, LangGraph) et produits (Cursor @Codebase, Notion AI, systèmes type Glean) implémentent le RAG en coulisse, mais comprendre le pipeline de base reste nécessaire pour déboguer et ajuster.
Cas d'usage pratiques
- Support et FAQ - réponses depuis la base d'articles et tickets passés sans recherche manuelle.
- Wiki interne - "comment demander des congés", "où est le runbook d'incident".
- Juridique et conformité - recherche dans contrats et règlements avec référence à la clause.
- Assistants code - recherche sémantique dans le dépôt (index + embeddings), complément au contexte complet dans l'IDE.
- Analyse documentaire - questions sur rapports, études, transcriptions de réunions.
Schéma courant : grand corpus, mises à jour fréquentes, citations sources - le RAG convient mieux qu'un upload ponctuel de fichier dans le chat.
RAG vs fine-tuning vs long contexte
| Approche | Quand l'utiliser | Limite |
|---|---|---|
| RAG | Documents actuels, sources transparentes, mises à jour sans réentraînement | Dépend de la qualité de recherche |
| Fine-tuning | Style, format, terminologie métier, connaissance stable | Coûteux à mettre à jour |
| Long contexte | Document ou codebase entier en une session | Coût, latence, "lost in the middle" |
Ces approches ne s'excluent pas. Schéma typique 2026 : RAG pour le corpus + long contexte pour quelques fichiers complets + fine-tuning léger ou system prompt pour le ton de l'entreprise.
Limites et problèmes fréquents
Le RAG résout l'accès au savoir, mais pas :
- une exactitude factuelle garantie (le modèle peut ignorer le contexte)
- des actions complexes multi-étapes (tools / MCP requis)
- la fraîcheur automatique de l'index (ETL à chaque changement de document)
Échecs typiques :
- Mauvais chunking - tableau coupé en deux, formule sans titre.
- K inadapté - trop peu de chunks → faits manqués ; trop → bruit dans le prompt.
- Index obsolète - document mis à jour, embedding non recalculé.
- Recherche hybride absente - recherche sémantique pure rate SKU, ID, dates ; hybride (BM25 + vecteurs) aide.
En production : monitorer le hit rate du retrieval, A/B sur la taille des chunks, feedback humain, garde-fous "si confiance faible - ne pas répondre".
Améliorer un système RAG
- Métadonnées - tags département, date, version ; filtrage avant vector search.
- Recherche hybride - keyword (BM25) + sémantique ; surtout pour la doc technique.
- Reranker - cross-encoder après Top-20 initial → Top-5 final.
- Transformation de requête - reformulation, multi-query, HyDE (document hypothétique).
- Graph RAG - entités liées (personnes, projets, dépendances) au-dessus de chunks plats.
- Évaluation - jeu question-réponse gold ; métriques faithfulness, context recall (RAGAS, DeepEval).
Commencez par un pipeline simple (chunk → embed → Top-5 → GPT), mesurez la baseline, n'ajoutez de la complexité que là où les métriques progressent.
RAG et écosystème agents
Le RAG s'associe souvent au MCP et au tool calling : le RAG extrait le savoir des documents, les tools exécutent des actions (créer un ticket, consulter un solde). Dans Cursor l'index sémantique @Codebase est un cas de RAG sur les fichiers du projet ; en entreprise on scale le même pattern vers Confluence, Slack et CRM.
| Couche | Tâche |
|---|---|
| RAG | "Que disent les documents ?" |
| MCP / tools | "Qu'y a-t-il dans le système ? Agir" |
| LLM | Synthétiser la réponse et planifier |
Synthèse
Le RAG est la méthode standard pour connecter un LLM à vos données sans réentraînement : les documents sont indexés, des fragments pertinents sont récupérés par requête, le modèle répond en s'appuyant sur eux. L'approche scale d'un prototype Chroma + OpenAI à un cluster avec recherche hybride, reranking et monitoring qualité.
Pour un premier projet : choisissez un corpus (ex. FAQ de 50 pages), réglez chunking et Top-K, vérifiez si le bon paragraphe entre dans le contexte - c'est le principal prédicteur de succès.
Questions fréquentes
Quelle différence entre RAG et fine-tuning ?
Le fine-tuning modifie les poids du modèle sur vos exemples - adapté au style, au format et aux patterns stables. Le RAG ne touche pas aux poids : chaque requête apporte des fragments frais depuis l'index. Des documents qui changent chaque semaine se mettent à jour plus facilement via RAG (réindexation) que par réentraînement. Fine-tuning quand le modèle doit connaître une procédure par cœur ; RAG quand comptent l'actualité et la citation de source.
Faut-il du RAG si le modèle a un contexte d'un million de tokens ?
Le long contexte (1M+ tokens sur Claude, Gemini, GPT-5.6) permet de charger beaucoup de texte en une session, mais ne remplace pas le RAG pour de gros corpus : 100 Go de PDF ne tiennent pas dans le prompt, coût et latence croissent linéairement. Le RAG choisit des morceaux pertinents ; le long contexte convient à quelques fichiers complets après retrieval ou au code du repo dans l'IDE. En pratique on combine les deux.
Quelle base vectorielle choisir pour le RAG ?
Selon l'échelle et l'infrastructure. pgvector - si PostgreSQL est déjà là et jusqu'à des millions de vecteurs. Qdrant, Weaviate, Milvus - self-hosted ou managed à la croissance. Pinecone - managed sans ops cluster. Chroma - démarrage rapide de prototype. L'essentiel : qualité des embeddings, chunking et monitoring ; beaucoup de systèmes ont commencé sur Chroma puis migré vers pgvector ou Qdrant sans changer la logique applicative.
Pourquoi le RAG donne parfois de mauvaises réponses ?
Causes principales : (1) échec du retrieval - bon chunk absent du Top-K ; (2) modèle a ignoré le contexte et complété depuis la "mémoire" ; (3) index obsolète ; (4) chunks contradictoires. Se corrige par une meilleure recherche (hybride, reranker), un prompt strict ("si absent du contexte - dire je ne sais pas"), des citations et un jeu d'éval pour les régressions.
Peut-on construire du RAG avec des modèles locaux ?
Oui. Modèles d'embedding (bge-m3, nomic-embed) et LLM (Llama, Qwen, Mistral via Ollama) tournent offline ; la vector store peut être locale aussi. Limites - qualité sur matériel modeste ; adapter la taille du modèle au GPU/RAM. Pour des données sensibles (santé, finance, secteur public) le RAG local est courant : les documents restent dans le périmètre, l'architecture du pipeline reste la même qu'en cloud.