RAG avancé : optimiser votre pipeline de retrieval pour la production

Votre pipeline RAG fonctionne en développement mais déçoit en production ? Les réponses sont parfois excellentes et parfois à côté de la plaque ? C’est le problème classique du “naive RAG” — une implémentation basique qui fonctionne sur des cas simples mais échoue sur les cas complexes du monde réel. Voici les techniques qui font la différence.

Les limites du RAG naïf

Un pipeline RAG basique ressemble à ça :

Découper les documents en chunks de taille fixe
Créer un embedding vectoriel pour chaque chunk
À chaque requête, calculer la similarité cosinus avec l’embedding de la question
Retourner les top-k chunks les plus similaires
Injecter ces chunks dans le prompt avec la question

Ce pipeline a plusieurs problèmes connus :

Problème 1 : Les chunks de taille fixe coupent le contexte Un chunk de 500 tokens peut couper une clause contractuelle en plein milieu. Le début et la fin du chunk n’ont pas de sens sans le contexte environnant.

Problème 2 : La similarité sémantique ne suffit pas “Comment résilier le contrat ?” peut être sémantiquement distant des clauses de résiliation dans un contrat écrit en juridique dense — même si c’est exactement ce qu’on cherche.

Problème 3 : Les questions complexes nécessitent plusieurs chunks “Comparez les pénalités dans les contrats avec le fournisseur A et le fournisseur B” nécessite d’agréger des informations de plusieurs documents.

Technique 1 : Chunking intelligent

Chunking sémantique

Au lieu de couper à N tokens fixes, découpez sur des limites sémantiques naturelles :

Paragraphes
Sections (titres H1, H2, H3)
Sentences clusters (regroupement de phrases sémantiquement proches)

Outils :

# LangChain SemanticChunker
from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai.embeddings import OpenAIEmbeddings

text_splitter = SemanticChunker(
    OpenAIEmbeddings(),
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=95
)

Chunking avec chevauchement + contexte parent

Créez deux niveaux de chunks :

Small chunks (200 tokens) pour la précision de la recherche
Parent chunks (1000-2000 tokens) pour le contexte complet fourni au LLM

Lors de la recherche : trouvez via les small chunks, retournez les parent chunks pour le contexte.

# LangChain ParentDocumentRetriever
from langchain.retrievers import ParentDocumentRetriever

retriever = ParentDocumentRetriever(
    vectorstore=vectorstore,
    docstore=store,
    child_splitter=child_splitter,
    parent_splitter=parent_splitter,
)

Contextual Retrieval (Anthropic, 2024)

Anthropic a publié une technique qui consiste à enrichir chaque chunk avec son contexte avant de créer l’embedding. Pour chaque chunk, un LLM génère une courte description contextualisée (50-100 tokens) qui est préfixée au chunk.

CONTEXTE GÉNÉRÉ : "Ce chunk fait partie de la section 8 (Résiliation) du contrat
cadre avec le fournisseur Dupont & Fils, signé le 15 mars 2024. Il décrit
les conditions de résiliation anticipée."

CHUNK ORIGINAL : "La résiliation anticipée est possible moyennant un préavis
de 3 mois et le paiement d'une indemnité égale à 20% du montant..."

Résultat mesuré par Anthropic : réduction des échecs de retrieval de 49 à 67 % selon les benchmarks.

Technique 2 : Hybrid Search (Vectoriel + BM25)

La recherche vectorielle (similarité sémantique) est excellente pour les requêtes conceptuelles. La recherche lexicale (BM25/keyword) est excellente pour les requêtes avec des termes spécifiques (noms propres, numéros de contrat, termes techniques).

Combinez les deux avec RRF (Reciprocal Rank Fusion) :

from langchain.retrievers import EnsembleRetriever

# Keyword retriever (BM25)
bm25_retriever = BM25Retriever.from_documents(docs)
bm25_retriever.k = 5

# Vector retriever
vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 5})

# Ensemble (hybrid)
ensemble_retriever = EnsembleRetriever(
    retrievers=[bm25_retriever, vector_retriever],
    weights=[0.4, 0.6]  # Ajustez selon votre cas d'usage
)

Quand c’est crucial : quand votre base documentaire contient des termes très spécifiques (références produits, codes réglementaires, noms propres) qui peuvent être sémantiquement éloignés des requêtes naturelles.

Technique 3 : Reranking

Après la recherche initiale, les top-k résultats sont souvent dans le bon ordre approximatif mais pas parfait. Un reranker (cross-encoder) réévalue chaque paire (question, chunk) avec plus de précision qu’un bi-encoder.

Modèles de reranking :

Cohere Rerank : API cloud, très performant, facilement intégrable
BGE-Reranker (BAAI) : open source, hébergeable on-premise
MS-Marco models : modèles de reranking open source

from langchain.retrievers.contextual_compression import ContextualCompressionRetriever
from langchain_cohere import CohereRerank

# Étape 1 : Retrieval initial (top 20)
base_retriever = vectorstore.as_retriever(search_kwargs={"k": 20})

# Étape 2 : Reranking (retourner les 5 meilleurs)
compressor = CohereRerank(model="rerank-multilingual-v3.0", top_n=5)
compression_retriever = ContextualCompressionRetriever(
    base_compressor=compressor,
    base_retriever=base_retriever
)

Gain typique : amélioration de la précision à 5 de 20-35 % sur des benchmarks de QA documentaire.

Technique 4 : HyDE (Hypothetical Document Embeddings)

Au lieu d’embedder la question directement, demandez au LLM de générer un document hypothétique qui serait la réponse idéale, puis embeddez ce document.

Pourquoi ça marche : une question (“Quelles sont les conditions de résiliation ?”) est sémantiquement très différente d’une réponse (“Les conditions de résiliation sont : 3 mois de préavis…”). HyDE “comble” ce fossé.

from langchain.chains import HypotheticalDocumentEmbedder
from langchain_openai import ChatOpenAI, OpenAIEmbeddings

llm = ChatOpenAI(model="gpt-4o-mini")
embeddings = OpenAIEmbeddings()

# L'embedder crée d'abord un document hypothétique puis l'embed
hyde_embeddings = HypotheticalDocumentEmbedder.from_llm(
    llm=llm,
    base_embeddings=embeddings,
    custom_prompt="""Génère un extrait de document qui répondrait
    à la question suivante : {question}"""
)

Technique 5 : Query expansion et reformulation

Les utilisateurs posent souvent des questions ambiguës ou incomplètes. Avant la recherche, un LLM peut :

Multi-query retrieval : générer 3-5 reformulations de la question, faire la recherche avec chacune, dédupliquer les résultats.

from langchain.retrievers.multi_query import MultiQueryRetriever

retriever = MultiQueryRetriever.from_llm(
    retriever=vectorstore.as_retriever(),
    llm=ChatOpenAI(temperature=0)
)

Step-back prompting : pour les questions très spécifiques, demander au LLM de reformuler en une question plus générale qui capture le concept sous-jacent.

Technique 6 : Filtrage par métadonnées

Si vos documents ont des métadonnées riches (date, auteur, département, type de document, statut), utilisez-les pour filtrer avant la recherche vectorielle.

# Recherche restreinte aux documents actifs du département juridique
results = vectorstore.similarity_search(
    query=question,
    filter={
        "department": "legal",
        "status": "active",
        "date": {"$gte": "2024-01-01"}
    }
)

Investissement en amont : enrichir les documents avec des métadonnées structurées au moment de l’ingestion est crucial. C’est fastidieux, mais c’est ce qui permet des pipelines de recherche précis et contrôlables.

Architecture RAG recommandée pour la production

Requête utilisateur
    ↓
Query preprocessing
├── Détection de langue
├── Classification du type de requête
└── Expansion/reformulation (optionnel)
    ↓
Hybrid retrieval (BM25 + Vectoriel)
    ↓
Reranking (Cohere Rerank ou BGE)
    ↓
Contextual enrichment (parent chunks)
    ↓
LLM generation avec citations
    ↓
Post-processing
├── Vérification des citations
├── Détection des "je ne sais pas"
└── Scoring de confiance
    ↓
Réponse + sources citées

Métriques d’évaluation d’un pipeline RAG

RAGAS (RAG Assessment) est le framework de référence pour évaluer les pipelines RAG :

Faithfulness : la réponse est-elle fidèle aux chunks récupérés ? (détection d’hallucinations)
Answer Relevancy : la réponse répond-elle à la question posée ?
Context Recall : les chunks récupérés contiennent-ils l’information nécessaire ?
Context Precision : les chunks récupérés sont-ils tous pertinents ?

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_recall

results = evaluate(
    dataset=eval_dataset,
    metrics=[faithfulness, answer_relevancy, context_recall]
)

Questions fréquentes

Quel embedding model choisir pour le français ? text-embedding-3-large d’OpenAI ou multilingual-e5-large (open source) offrent les meilleures performances en français. Évitez les modèles entraînés uniquement sur l’anglais pour des bases documentaires en français.

À partir de quelle taille de base documentaire le RAG avancé est-il nécessaire ? Dès que vous avez des retours d’utilisateurs indiquant que les réponses “manquent” l’information pertinente malgré son existence dans la base. La taille absolue compte moins que la diversité et la complexité des documents.

BetterPeople accompagne les équipes dans le design et l’optimisation de leurs pipelines RAG. Planifiez un audit de votre RAG.