Dernière mise à jour :

1 septembre 2026·6 min read

Retrieval-Augmented Generation (RAG) connects language models to external knowledge sources so answers can be grounded in documents, databases, and live data instead of relying only on training memory. RAG is one of the most deployed patterns in enterprise AI. This guide explains how RAG works, when to use it, and what to watch for in production.

RAG stands for Retrieval-Augmented Generation. It is an architecture where a language model retrieves relevant information from an external source before generating a response. Instead of asking the model to recall facts from pre-training alone, RAG fetches up-to-date passages from a knowledge base, injects them into the prompt as context, and asks the model to answer using that retrieved material. This reduces hallucination on factual questions and lets systems answer about private data the model was never trained on.

A typical RAG system has four stages: 1. Indexing: Documents are split into chunks, converted to embeddings, and stored in a vector database. 2. Retrieval: The user query is embedded and matched against stored chunks to find the most relevant passages. 3. Augmentation: Retrieved chunks are inserted into the prompt as context alongside the user question. 4. Generation: The LLM produces an answer conditioned on the provided context. Optional reranking steps improve retrieval quality by re-scoring candidates with a cross-encoder before generation.

RAG solves problems pure LLMs struggle with: Freshness: Answers can reflect documents updated yesterday, not just training cutoff knowledge. Provenance: Systems can cite source passages for audit and verification. Privacy: Sensitive data stays in your vector store; the model sees only retrieved snippets per request. Cost: Updating a knowledge base is cheaper than retraining a large model. Control: You decide exactly which corpora the system can access.

RAG is not magic. Common failures include: Bad retrieval: Wrong chunks retrieved, so the model answers confidently from irrelevant context. Lost in the middle: Models ignore context buried in long prompts. Chunking issues: Important information split across chunks never retrieved together. Stale indexes: Documents updated but embeddings not refreshed. Over-trust: Model ignores retrieved context and falls back to parametric memory. Production RAG requires evaluation on retrieval accuracy, answer faithfulness, and latency, not just generation quality.

RAG and fine-tuning solve different problems: RAG: Best for dynamic knowledge, citation requirements, and large document corpora that change frequently. Fine-tuning: Best for teaching behavior, tone, format, and domain reasoning patterns that should be baked into the model. Most enterprise systems combine both: fine-tune for how the model works, RAG for what it knows at answer time.

Frequently Asked Questions

RAG reduces factual hallucination when retrieval is accurate, but models can still misread context, ignore retrieved passages, or synthesize incorrectly. Evaluation and citation checks remain essential.
A vector database stores document embeddings and supports fast similarity search. When a user asks a question, the query embedding finds the closest document chunks to include as context.
Skip RAG when tasks need deep reasoning baked into model weights, when latency budgets cannot tolerate retrieval, or when knowledge is static enough that fine-tuning alone is simpler and cheaper.