Qu'est-ce que le RAG

RAG 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 :

1. 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.
2. 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)

1. La question utilisateur est aussi embedée avec le même encodeur.
2. La vector DB renvoie les Top-K chunks les plus proches (souvent K = 3-10).
3. Optionnellement - reranking : un second modèle reclasse les candidats plus finement que la similarité cosinus seule.
4. Les fragments trouvés entrent dans le prompt system/user avec l'instruction de "répondre uniquement à partir du contexte".
5. 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

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

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

1. Métadonnées - tags département, date, version ; filtrage avant vector search.
2. Recherche hybride - keyword (BM25) + sémantique ; surtout pour la doc technique.
3. Reranker - cross-encoder après Top-20 initial → Top-5 final.
4. Transformation de requête - reformulation, multi-query, HyDE (document hypothétique).
5. Graph RAG - entités liées (personnes, projets, dépendances) au-dessus de chunks plats.
6. É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.

Quand le RAG ne convient pas

Le RAG ajoute de la complexité technique et demande de la maintenance, donc son adoption n'est pas toujours justifiée :

• Base de connaissances petite et peu changeante - il suffit de coller le texte une fois dans le system prompt ; pas besoin de recherche ni de base vectorielle.
• Pas de ressources pour maintenir le pipeline - l'index doit être mis à jour à chaque changement de document et la qualité de recherche surveillée ; sans équipe ou prestataire dédié, le système devient vite obsolète et donne de mauvaises réponses.
• Exactitude garantie requise - pour des calculs, des formulations juridiques ou d'autres tâches où l'erreur n'est pas tolérable, des systèmes déterministes et une relecture humaine sont plus fiables que la génération du modèle.
• La tâche porte sur des actions, pas sur la recherche documentaire - créer un ticket, modifier un enregistrement - le RAG seul n'aide pas, il faut des tools/MCP (voir plus bas).

Avant de démarrer, mieux vaut estimer le volume de documents, leur fréquence de changement et qui sera responsable de l'index - c'est ce qui détermine si le RAG est rentable ou si une solution plus simple suffit.

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.

Si vous avez besoin d'aide pour le développement, l'intégration de l'IA ou la maintenance de site pour votre projet - contactez-moi.

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.

Termes de l'article

RAG — Retrieval-Augmented Generation — génération augmentée par récupération

pipeline — sequence of processing stages

production — live environment serving real users — environnement live avec de vrais utilisateurs

retrieval — finding relevant context before generation — recherche de contexte pertinent avant génération

LLM — Large Language Model — grand modèle de langage

Confluence — Atlassian wiki for team documentation — wiki Atlassian pour la documentation d'équipe

chunking — splitting documents into retrieval-friendly pieces — découpage de documents en fragments pour la recherche

embeddings — numeric vectors that capture text meaning — vecteurs numériques qui capturent le sens du texte

vector store — database optimized for similarity search over embeddings — base optimisée pour la recherche de similarité sur embeddings

Pinecone — managed vector database for similarity search — base vectorielle managée pour la similarité

pgvector — PostgreSQL extension for vector search — extension PostgreSQL pour la recherche vectorielle

vector db — database for similarity search over embeddings — base pour recherche de similarité sur embeddings

Qdrant — vector database for similarity search — base vectorielle pour la recherche de similarité

reranking — reordering search results by relevance — reclassement des résultats par pertinence

Chroma — open-source embedding database for RAG apps — base d'embeddings open-source pour apps RAG

chunks — small text pieces indexed for retrieval — petits fragments de texte indexés pour le retrieval

top-k — keep only the k most likely next tokens when sampling — ne garder que les k tokens les plus probables au sampling

LlamaIndex — framework for connecting LLMs to private data — framework pour connecter les LLM aux données privées

LangChain — framework for building LLM applications — framework pour applications basées sur LLM

fine-tuning — additional training of a model on domain data — entraînement supplémentaire du modèle sur des données métier

ANN — Approximate Nearest Neighbor — recherche approximative des plus proches voisins vectoriels

system prompt — hidden instructions that steer the model for a task — instructions cachées qui orientent le comportement du modèle

runbook — step-by-step playbook for incidents and operations — procédure pas à pas pour incidents et exploitation

vector search — finding nearest neighbors in embedding space — recherche des plus proches voisins dans l'espace d'embeddings

cross-encoder — rerank model that scores query and document together — modèle de rerank qui score requête et document ensemble

faithfulness — how well an answer sticks to the retrieved sources — fidélité d'une réponse aux sources récupérées

tool calling — model invoking external tools or APIs — le modèle appelle des outils ou API externes

hit rate — share of requests served from cache — part des requêtes servies depuis le cache

reranker — model that reorders search hits by relevance — modèle qui réordonne les résultats par pertinence

SKU — Stock Keeping Unit — unité de gestion des stocks

baseline — reference measurement before changes

MCP — Model Context Protocol — protocole de contexte de modèle

CRM — Customer Relationship Management — gestion de la relation client

self-hosted — software you run on your own servers — logiciel que vous hébergez sur vos serveurs

GPU — Graphics Processing Unit — unité de traitement graphique