Guide Complet RAG 2026 : Génération Augmentée par Récupération

Retrieval-Augmented Generation (RAG) is the dominant pattern for building LLM applications grounded in real, up-to-date data. Instead of relying solely on what a model memorized during training, RAG fetches relevant documents at query time and feeds them as context to the LLM. This guide covers the complete RAG pipeline — from document ingestion and embedding to vector search, advanced retrieval strategies, evaluation with RAGAS, and production deployment patterns — with working Python code examples using LangChain and OpenAI.

TL;DR: RAG = Retrieve relevant documents + Augment the prompt + Generate a grounded answer. It eliminates hallucinations, keeps responses current, and avoids expensive fine-tuning. The pipeline is: Load docs, split into chunks, embed with a model like text-embedding-3-small, store in a vector DB (Pinecone, Qdrant, pgvector), retrieve top-k results at query time, and pass them to the LLM. Advanced techniques include HyDE, parent-child chunks, hybrid search, and re-ranking. Evaluate with RAGAS (faithfulness, relevance, context recall). Production tips: cache embeddings, stream responses, monitor retrieval quality.

Key Takeaways

• RAG grounds LLM responses in real data, reducing hallucinations by 80-95% compared to vanilla prompting.
• Choose chunk size based on your content: 512 tokens for Q&A, 1024 for summarization, with 10-20% overlap.
• text-embedding-3-small offers the best cost/performance ratio for most use cases at $0.02/1M tokens.
• Hybrid search (dense vectors + sparse BM25) consistently outperforms pure vector similarity search.
• Always evaluate with RAGAS before going to production — measure faithfulness, answer relevance, and context recall.
• Re-ranking with a cross-encoder after initial retrieval significantly improves answer quality for minimal latency cost.

What Is RAG and Why It Matters

Large language models are trained on static datasets with a knowledge cutoff. They cannot access your internal documents, latest API docs, or real-time data. When asked about information outside their training data, they either refuse or — worse — hallucinate confident-sounding but incorrect answers.

RAG solves this by introducing a retrieval step before generation. At query time, the system searches a knowledge base for relevant documents, injects them into the prompt as context, and instructs the LLM to answer based on that context. The LLM becomes a reasoning engine over your data rather than a memorization engine.

First described in the 2020 paper by Lewis et al. at Meta, RAG has become the standard architecture for enterprise AI applications, customer support bots, documentation assistants, and any system that needs factual, verifiable answers.

RAG vs Fine-Tuning vs Prompt Engineering

Before building a RAG system, understand when to use each approach:

In practice, most production systems combine all three: prompt engineering for formatting, RAG for knowledge, and fine-tuning for specialized behavior. But if you are building a knowledge-heavy application, start with RAG — it gives you the most impact with the least investment.

RAG Architecture: The Complete Pipeline

A RAG system has two main phases: an offline indexing pipeline that processes your documents, and an online query pipeline that handles user questions. Here is the complete architecture:

RAG Architecture Overview
========================

INDEXING PIPELINE (Offline)
--------------------------
                                                         
  [Documents]    [Text Splitter]    [Embedding]    [Vector Store]
  PDF, HTML  -->  Chunk into    -->  Convert to -->  Store in
  Markdown       256-512 tokens     dense vectors   Pinecone/
  Database       with overlap       (1536-dim)      Qdrant/PG
                                                         
QUERY PIPELINE (Online)
-----------------------
                                                         
  [User Query]   [Embed Query]   [Retrieve]   [Re-rank]   [Generate]
  "How do I  --> Convert to  --> Top-k     --> Cross-   --> LLM with
   deploy?"     query vector    similar      encoder      context
                                chunks       scoring      + prompt
                   |                            |            |
                   v                            v            v
              Same embedding              Filter &      Grounded
              model as indexing           compress      answer with
                                         context       citations

The indexing pipeline runs once (or on a schedule) to process your documents. The query pipeline runs for every user question, typically completing in 1-3 seconds end-to-end.

Step 1: Document Loading

The first step is loading your source documents into a format the pipeline can process. LangChain provides loaders for virtually every format:

from langchain_community.document_loaders import (
    PyPDFLoader,
    UnstructuredHTMLLoader,
    UnstructuredMarkdownLoader,
    TextLoader,
    CSVLoader,
    DirectoryLoader,
    WebBaseLoader,
)

# Load a single PDF
pdf_docs = PyPDFLoader("report.pdf").load()

# Load all markdown files from a directory
md_docs = DirectoryLoader(
    "./docs/", glob="**/*.md",
    loader_cls=UnstructuredMarkdownLoader
).load()

# Load a web page
web_docs = WebBaseLoader("https://docs.example.com/api").load()

# Load CSV data
csv_docs = CSVLoader("products.csv").load()

print(f"Loaded {len(pdf_docs)} pages from PDF")
print(f"First doc metadata: {pdf_docs[0].metadata}")

Each loader returns a list of Document objects with page_content (the text) and metadata (source, page number, etc.). Metadata is critical for citations — always preserve it.

Step 2: Text Splitting (Chunking)

Raw documents are too large to embed or fit in a prompt. You need to split them into chunks. The chunk size directly impacts retrieval quality — this is the single most important parameter to tune.

Common splitting strategies:

from langchain.text_splitter import (
    RecursiveCharacterTextSplitter,
    MarkdownHeaderTextSplitter,
)

# Default: RecursiveCharacterTextSplitter
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    length_function=len,
    separators=["\n\n", "\n", ". ", " ", ""]
)
chunks = text_splitter.split_documents(pdf_docs)
print(f"Split into {len(chunks)} chunks")

# Markdown-aware splitting
md_splitter = MarkdownHeaderTextSplitter(
    headers_to_split_on=[
        ("#", "h1"),
        ("##", "h2"),
        ("###", "h3"),
    ]
)
md_chunks = md_splitter.split_text(md_content)

Chunk size guidelines: For Q&A systems, use 256-512 tokens with 50-100 token overlap. For summarization, use 1024-2048 tokens. For code, split by function/class boundaries. Always test multiple sizes and measure retrieval accuracy.

Step 3: Embedding Models

Embeddings convert text chunks into dense numerical vectors that capture semantic meaning. Similar texts produce vectors that are close together in vector space, enabling semantic search.

from langchain_openai import OpenAIEmbeddings

# OpenAI embeddings (recommended for most cases)
embeddings = OpenAIEmbeddings(
    model="text-embedding-3-small",
    # dimensions=512  # optional: reduce dimensions for cost savings
)

# Embed a single query
query_vector = embeddings.embed_query("How to deploy a RAG app?")
print(f"Vector dimensions: {len(query_vector)}")  # 1536

# Embed multiple documents (batched automatically)
doc_vectors = embeddings.embed_documents(
    [chunk.page_content for chunk in chunks]
)

Tip: Start with text-embedding-3-small for prototyping. It handles most use cases well at the lowest cost. Switch to a specialized model only if evaluation metrics show a need.

Step 4: Vector Stores

Vector stores index your embeddings for fast similarity search. The choice depends on scale, infrastructure, and query patterns.

from langchain_chroma import Chroma
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-small")

# Create and persist a vector store
vectorstore = Chroma.from_documents(
    documents=chunks,
    embedding=embeddings,
    persist_directory="./chroma_db",
    collection_name="my_docs"
)

# Load an existing vector store
vectorstore = Chroma(
    persist_directory="./chroma_db",
    embedding_function=embeddings,
    collection_name="my_docs"
)

# Basic similarity search
results = vectorstore.similarity_search("deployment guide", k=4)
for doc in results:
    print(doc.page_content[:100])

Recommendation: Use ChromaDB or FAISS for prototyping. For production, Pinecone offers the lowest operational burden. If you already run PostgreSQL, pgvector avoids adding a new service. For hybrid search requirements, Weaviate or Qdrant are excellent choices.

Step 5: Retrieval Strategies

Retrieval quality determines RAG quality. A perfect LLM cannot generate correct answers from irrelevant context. Here are the key retrieval strategies:

For most production systems, the winning combination is: hybrid search (dense + BM25) followed by cross-encoder re-ranking. This consistently outperforms pure vector similarity across benchmarks.

Step 6: Generation with Context

The final step passes retrieved context to the LLM with a well-crafted prompt. The prompt template is critical — it tells the LLM to use only the provided context and to cite sources.

from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough

llm = ChatOpenAI(model="gpt-4o", temperature=0)

prompt = ChatPromptTemplate.from_template(
    """Answer the question based ONLY on the following context.
If the context does not contain the answer, say "I don't have 
enough information to answer this question."

Context:
{context}

Question: {question}

Answer (cite sources):"""
)

# Build the RAG chain
retriever = vectorstore.as_retriever(search_kwargs={"k": 4})

def format_docs(docs):
    return "\n\n".join(
        f"[Source: {d.metadata.get('source', 'unknown')}]\n"
        + d.page_content for d in docs
    )

rag_chain = (
    {"context": retriever | format_docs,
     "question": RunnablePassthrough()}
    | prompt
    | llm
    | StrOutputParser()
)

answer = rag_chain.invoke("How do I deploy to production?")
print(answer)

Key prompt engineering tips for RAG: (1) Explicitly instruct the model to answer only from context. (2) Include source metadata for citations. (3) Tell the model to say "I don't know" when context is insufficient. (4) Use system messages for consistent behavior.

Advanced RAG Techniques

Once your basic RAG pipeline works, these techniques can significantly improve quality:

HyDE (Hypothetical Document Embeddings): Instead of embedding the user query directly, first ask the LLM to generate a hypothetical answer, then embed that answer for retrieval. This bridges the gap between question-style queries and document-style content. Improves recall by 10-25% on many benchmarks.

Parent-child chunks: Index small chunks (256 tokens) for precise retrieval, but return the parent chunk (1024-2048 tokens) as context. This gives the LLM more surrounding context while maintaining retrieval precision.

Multi-query retrieval: Generate 3-5 reformulations of the user query using an LLM, run retrieval for each, and merge results. Catches relevant documents that a single query phrasing might miss.

Contextual compression: After retrieval, use a smaller LLM to extract only the relevant sentences from each chunk. Reduces noise and fits more useful information in the context window.

Query routing: Classify the query type (factual lookup, comparison, how-to, etc.) and route to different retrieval strategies or knowledge bases. A simple classifier can dramatically improve results.

Complete RAG Implementation (Python)

Here is a complete working RAG pipeline using LangChain, OpenAI, and ChromaDB. This covers document loading, chunking, embedding, indexing, and querying:

# Complete RAG pipeline: pip install langchain langchain-openai
# pip install langchain-chroma unstructured pypdf

import os
os.environ["OPENAI_API_KEY"] = "sk-..."

from langchain_community.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_chroma import Chroma
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough

# 1. Load documents
docs = PyPDFLoader("knowledge_base.pdf").load()

# 2. Split into chunks
splitter = RecursiveCharacterTextSplitter(
    chunk_size=512, chunk_overlap=50
)
chunks = splitter.split_documents(docs)

# 3. Create vector store with embeddings
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma.from_documents(
    chunks, embeddings, persist_directory="./db"
)

# 4. Build RAG chain
retriever = vectorstore.as_retriever(search_kwargs={"k": 4})
llm = ChatOpenAI(model="gpt-4o", temperature=0)
prompt = ChatPromptTemplate.from_template(
    "Answer based ONLY on this context:\n{context}\n\n"
    "Question: {question}\nAnswer:"
)

rag_chain = (
    {"context": retriever | (lambda docs: "\n".join(
        d.page_content for d in docs)),
     "question": RunnablePassthrough()}
    | prompt | llm | StrOutputParser()
)

# 5. Query
print(rag_chain.invoke("What is the deployment process?"))

The code above creates a complete RAG pipeline in under 50 lines. For production, you would add error handling, streaming, caching, and swap ChromaDB for a managed vector store.

Advanced: Hybrid Search with Re-ranking

This example adds BM25 hybrid search and cross-encoder re-ranking for significantly better retrieval quality:

# pip install rank-bm25 sentence-transformers

from rank_bm25 import BM25Okapi
from sentence_transformers import CrossEncoder
import numpy as np

# BM25 sparse retriever
corpus = [doc.page_content for doc in chunks]
tokenized = [doc.split() for doc in corpus]
bm25 = BM25Okapi(tokenized)

def hybrid_search(query, k=10):
    # Dense search via vector store
    dense_results = vectorstore.similarity_search(query, k=k)
    
    # Sparse search via BM25
    bm25_scores = bm25.get_scores(query.split())
    top_bm25_idx = np.argsort(bm25_scores)[-k:][::-1]
    sparse_results = [chunks[i] for i in top_bm25_idx]
    
    # Merge and deduplicate
    seen = set()
    merged = []
    for doc in dense_results + sparse_results:
        if doc.page_content not in seen:
            seen.add(doc.page_content)
            merged.append(doc)
    return merged[:k]

# Cross-encoder re-ranking
reranker = CrossEncoder("cross-encoder/ms-marco-MiniLM-L-6-v2")

def rerank(query, docs, top_k=4):
    pairs = [[query, d.page_content] for d in docs]
    scores = reranker.predict(pairs)
    ranked = sorted(zip(scores, docs), reverse=True)
    return [doc for _, doc in ranked[:top_k]]

# Usage: hybrid search + re-rank
candidates = hybrid_search("How to handle auth?", k=10)
final_docs = rerank("How to handle auth?", candidates, top_k=4)

Evaluating RAG Quality with RAGAS

You cannot improve what you do not measure. RAGAS (Retrieval-Augmented Generation Assessment) is the standard framework for evaluating RAG pipelines. It measures four key metrics:

# pip install ragas

from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_precision,
    context_recall,
)
from datasets import Dataset

# Prepare evaluation dataset
eval_data = {
    "question": [
        "How do I deploy to production?",
        "What authentication methods are supported?",
    ],
    "answer": [  # generated by your RAG pipeline
        rag_chain.invoke("How do I deploy to production?"),
        rag_chain.invoke("What auth methods are supported?"),
    ],
    "contexts": [  # retrieved chunks for each question
        [d.page_content for d in retriever.invoke(
            "How do I deploy to production?")],
        [d.page_content for d in retriever.invoke(
            "What auth methods are supported?")],
    ],
    "ground_truth": [  # human-written correct answers
        "Deploy using Docker with the provided Dockerfile...",
        "OAuth 2.0, API keys, and JWT are supported...",
    ],
}

dataset = Dataset.from_dict(eval_data)
results = evaluate(
    dataset,
    metrics=[faithfulness, answer_relevancy,
             context_precision, context_recall],
)
print(results)
# {faithfulness: 0.92, answer_relevancy: 0.89,
#  context_precision: 0.85, context_recall: 0.78}

Run RAGAS on a test set of 50-100 questions with known answers. A faithfulness score below 0.8 indicates your RAG system is hallucinating. Context recall below 0.7 means your retriever is missing relevant documents.

Production Considerations

Moving from prototype to production requires addressing several concerns:

Caching: Cache embedding results for identical queries. Cache LLM responses for identical query + context combinations. Use Redis or a simple in-memory LRU cache. This reduces costs by 40-60% in typical workloads.

Streaming: Stream the LLM response token by token. Users perceive the system as faster when they see partial responses. LangChain and OpenAI both support streaming natively.

Cost optimization: Use text-embedding-3-small (not large) unless evaluation shows a need. Batch embedding requests. Cache aggressively. Consider a smaller model (GPT-4o-mini) for simple queries and route complex ones to GPT-4o.

Monitoring: Log every query, retrieved chunks, and generated answer. Track retrieval latency, generation latency, and user feedback. Set up alerts for faithfulness drops. Tools: LangSmith, Phoenix, Weights & Biases.

Security: Implement access control on documents — users should only retrieve documents they are authorized to see. Sanitize user queries to prevent prompt injection. Never expose raw retrieved chunks in the UI without filtering.

Common Pitfalls and How to Avoid Them

These are the mistakes that trip up most RAG implementations:

RAG Frameworks Comparison

Several frameworks simplify RAG development. Here is how the major options compare:

Our recommendation: Start with LangChain for its ecosystem breadth and documentation. If your use case is heavily document-oriented with complex indexing needs, evaluate LlamaIndex. For TypeScript web applications, the Vercel AI SDK is increasingly capable.

Real-World RAG Use Cases

RAG is not a theoretical concept — it powers thousands of production applications today:

Cost Estimation Guide

Understanding RAG costs helps with budgeting. Here is a breakdown for a typical knowledge base with 10,000 documents (averaging 2,000 tokens each):

Key insight: Embedding costs are negligible. The LLM generation model choice dominates your bill. Use GPT-4o-mini for 80% of queries and route only complex ones to GPT-4o. This "model routing" strategy can cut costs by 60-70%.

Monitoring and Observability

A RAG system without monitoring is a system waiting to fail silently. You need visibility into every stage of the pipeline:

LangSmith, Phoenix (Arize), and Weights & Biases Traces are the leading observability tools for LLM applications. LangSmith integrates seamlessly with LangChain and provides trace visualization, evaluation, and cost tracking out of the box.

Production Setup: pgvector with PostgreSQL

If your team already runs PostgreSQL, pgvector is the easiest path to production. No new infrastructure, no new vendor — just an extension on your existing database:

-- Enable the extension
CREATE EXTENSION IF NOT EXISTS vector;

-- Create a table for document chunks
CREATE TABLE documents (
    id SERIAL PRIMARY KEY,
    content TEXT NOT NULL,
    metadata JSONB DEFAULT '{}',
    embedding vector(1536),  -- matches text-embedding-3-small
    created_at TIMESTAMP DEFAULT NOW()
);

-- Create an HNSW index for fast similarity search
CREATE INDEX ON documents
    USING hnsw (embedding vector_cosine_ops)
    WITH (m = 16, ef_construction = 64);

-- Similarity search query
SELECT id, content, metadata,
    1 - (embedding <=> $1::vector) AS similarity
FROM documents
WHERE 1 - (embedding <=> $1::vector) > 0.7
ORDER BY embedding <=> $1::vector
LIMIT 5;

# Python: LangChain + pgvector
# pip install langchain-postgres psycopg2-binary

from langchain_postgres import PGVector
from langchain_openai import OpenAIEmbeddings

CONNECTION = "postgresql://user:pass@localhost:5432/mydb"

embeddings = OpenAIEmbeddings(model="text-embedding-3-small")

vectorstore = PGVector.from_documents(
    documents=chunks,
    embedding=embeddings,
    connection=CONNECTION,
    collection_name="my_docs",
)

# Query with metadata filtering
results = vectorstore.similarity_search(
    "deployment guide",
    k=4,
    filter={"source": "docs/deploy.md"}
)

pgvector supports IVFFlat and HNSW indexes for fast approximate nearest neighbor search. For up to 1 million vectors, it performs well without sharding. Beyond that, consider a dedicated vector store.

RAG vs Agentic RAG

Traditional RAG follows a fixed pipeline: retrieve then generate. Agentic RAG gives the LLM control over the retrieval process itself — it can decide when to search, what to search for, whether to search again, and when it has enough context to answer.

In an agentic RAG system, the LLM acts as a reasoning agent that can call retrieval as a tool. If the first retrieval does not return relevant results, the agent reformulates the query and tries again. It can also combine information from multiple searches, verify facts across sources, and decide when to give up gracefully.

Agentic RAG is particularly powerful for complex questions that require multi-step reasoning: "Compare the pricing of products X, Y, and Z" requires three separate retrievals that a fixed pipeline cannot handle elegantly. Frameworks like LangGraph and CrewAI make it straightforward to build agentic RAG systems.

Multi-Modal RAG: Beyond Text

Modern RAG is not limited to text. Multi-modal RAG can index and retrieve from images, tables, and structured data:

Multi-modal RAG adds complexity but significantly improves coverage. Start with text-only RAG, then add modalities based on what your users are asking about but not finding answers for.

Document Preprocessing Tips

The quality of your input documents directly determines RAG quality. Garbage in, garbage out. Here are preprocessing best practices:

Getting Started Checklist

Follow this checklist to build your first RAG pipeline from scratch:

Streaming RAG Responses

Users expect real-time responses. Streaming delivers tokens as they are generated rather than waiting for the complete response. Here is how to implement streaming with LangChain:

import asyncio
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough

llm = ChatOpenAI(model="gpt-4o", temperature=0, streaming=True)

prompt = ChatPromptTemplate.from_template(
    "Answer based ONLY on this context:\n{context}\n\n"
    "Question: {question}\nAnswer:"
)

retriever = vectorstore.as_retriever(search_kwargs={"k": 4})

rag_chain = (
    {"context": retriever | (lambda docs: "\n".join(
        d.page_content for d in docs)),
     "question": RunnablePassthrough()}
    | prompt | llm | StrOutputParser()
)

# Synchronous streaming
for chunk in rag_chain.stream("How do I set up auth?"):
    print(chunk, end="", flush=True)

# Async streaming (for web frameworks)
async def stream_response(question: str):
    async for chunk in rag_chain.astream(question):
        yield chunk  # Send to client via SSE or WebSocket

# FastAPI example
from fastapi import FastAPI
from fastapi.responses import StreamingResponse

app = FastAPI()

@app.get("/ask")
async def ask(q: str):
    return StreamingResponse(
        stream_response(q),
        media_type="text/event-stream"
    )

Streaming reduces perceived latency from 3-5 seconds to under 500ms for first token. Always implement streaming in user-facing applications — the impact on user experience is dramatic.

Frequently Asked Questions

RAG is the most practical and impactful architecture for building LLM applications that need grounded, accurate, and up-to-date answers. Start simple with a basic pipeline (LangChain + OpenAI + ChromaDB), measure with RAGAS, then iterate. Add hybrid search and re-ranking when you need better retrieval. The ecosystem is mature and the tools are production-ready — the key differentiator is how well you tune your chunking, retrieval, and prompts for your specific data and use case.