RAG avancé : chunking, reranking et évaluation pour la production

Les limites du RAG naïf

La pipeline RAG de base fonctionne selon un schéma simple : découper les documents en chunks, les encoder en embeddings, stocker dans un vector store, puis à chaque requête : encoder la question, récupérer les k chunks les plus similaires, et les insérer dans le contexte du LLM. Ce schéma est correct — mais chacune de ses étapes présente des limitations qui se cumulent.

Le problème du chunk size fixe

Découper un document tous les N tokens (512, 1024...) crée des chunks qui coupent arbitrairement au milieu d'idées, séparent des questions de leurs réponses, et mélangent des sujets distincts. Un paragraphe de résumé et les détails techniques qui suivent se retrouvent dans des chunks différents — et le retriever peut récupérer l'un sans l'autre.

Impact : le LLM reçoit des fragments sans contexte suffisant. Il comble les lacunes avec ses connaissances générales — source d'hallucinations sur votre base documentaire.

Le top-k fixe : trop ou pas assez

Récupérer toujours les 5 mêmes premiers chunks est une mauvaise stratégie :

• Pour une question simple ("quelle est notre politique de congés ?"), un seul chunk suffit — les 4 autres polluent le contexte et augmentent les coûts
• Pour une question complexe ("synthétise notre politique RH et compare-la au Code du travail"), 5 chunks peuvent être insuffisants
• Un top-k élevé amène des chunks marginalement pertinents qui diluent le signal et induisent des confusions dans le LLM

L'absence de reranking

Les modèles d'embedding (bi-encoders) sont optimisés pour la rapidité — ils encodent la requête et les chunks séparément puis comparent les vecteurs. Cette architecture est rapide mais approximative : elle ne capture pas les relations fines entre la requête et un passage spécifique. Le résultat : des chunks sémantiquement proches de la requête mais pas réellement pertinents pour répondre à la question.

Stratégies de chunking avancées

Semantic Chunking : découper selon le sens, pas la taille

Le semantic chunking analyse la progression sémantique du document et découpe aux points de rupture naturels — là où le sens change significativement. L'algorithme :

1. Encode chaque phrase (ou groupe de phrases) en embedding
2. Calcule la similarité cosinus entre les phrases adjacentes
3. Identifie les points de faible similarité (ruptures thématiques) et y place les frontières de chunks

Résultat : des chunks qui correspondent à des unités sémantiques cohérentes, même si leur taille varie. Un paragraphe court mais complet reste un chunk entier ; une longue liste de données connexes reste unifiée.

Implémentation : LangChain propose SemanticChunker, LlamaIndex a son équivalent. Le coût : des appels d'embedding supplémentaires lors de l'indexation (négligeable en production).

Hierarchical Chunking : multi-granularité

Le hierarchical chunking indexe les documents à plusieurs niveaux de granularité simultanément :

• Chunks parents : sections entières (1000-2000 tokens) — riches en contexte
• Chunks enfants : paragraphes (150-300 tokens) — précis et ciblés

Le retrieval utilise les chunks enfants pour la précision (les petits chunks matchent mieux les requêtes courtes), mais renvoie au LLM les chunks parents correspondants (riches en contexte). Ce pattern — appelé Parent Document Retriever dans LangChain — résout l'antagonisme classique entre précision du retrieval et richesse du contexte.

Late Chunking : encoder d'abord, découper ensuite

Le late chunking est une technique plus récente (2024) qui inverse l'ordre classique : au lieu de découper puis d'encoder, on encode le document entier avec un modèle à longue fenêtre de contexte, puis on extrait les embeddings des chunks en préservant les représentations contextuelles de chaque token.

Avantage : chaque chunk "sait" ce qui est avant et après lui dans le document — les embeddings sont contextuellement enrichis. Cette technique est particulièrement efficace pour les documents techniques avec beaucoup de références croisées (spécifications, manuels, contrats).

Proposition-based Chunking

Une approche plus radicale : utiliser un LLM pour transformer chaque document en une liste de propositions atomiques ("L'entreprise XYZ a réalisé un CA de 120M€ en 2025", "La politique de congés prévoit 5 semaines de RTT"). Chaque proposition est un chunk minimal et autonome. Le retrieval devient extrêmement précis — mais l'indexation est coûteuse (appel LLM pour chaque document).

Reranking : cross-encoders et solutions disponibles

Le reranking est une deuxième passe de scoring après le retrieval initial. Après avoir récupéré les 20-50 chunks les plus proches par embedding, un modèle de reranking évalue chaque paire (requête, chunk) conjointement et produit un score de pertinence plus fin. Les top 3-5 chunks selon ce score sont envoyés au LLM.

Cross-encoders : le mécanisme du reranking

Un cross-encoder est un modèle (généralement BERT-based) entraîné à scorer la pertinence d'un passage par rapport à une requête, en traitant la paire conjointement. Contrairement au bi-encoder (embedding), le cross-encoder voit simultanément la requête et le passage — ce qui lui permet de capturer les relations fines et les correspondances non-évidentes.

Limitation : un cross-encoder est trop lent pour scorer tous les documents d'une base (complexité quadratique). Il est donc utilisé uniquement sur les 20-50 candidats présélectionnés par le retriever initial — d'où le pattern retriever + reranker.

Cohere Rerank

Cohere Rerank est le service de reranking le plus utilisé en production. API simple, performances supérieures aux cross-encoders open-source sur la plupart des benchmarks. Inconvénient : service cloud externe (Cohere, entreprise canadienne) — les chunks passent par leur API. Pour les données sensibles, préférer une alternative souveraine.

BGE Reranker (BAAI)

BGE Reranker (BAAI, Beijing AI Institute) est le meilleur modèle de reranking open-source disponible pour un déploiement local. BGE-reranker-v2-m3 supporte le multilinguisme (dont le français) et peut être déployé sur CPU (lent) ou GPU (rapide). Modèle recommandé pour les déploiements souverains :

from FlagEmbedding import FlagReranker
reranker = FlagReranker('BAAI/bge-reranker-v2-m3', use_fp16=True)
scores = reranker.compute_score([[query, chunk] for chunk in candidates])

Jina Reranker

Jina Reranker (Jina AI, entreprise germano-chinoise) propose des modèles de reranking performants disponibles en open-source et en API. Le modèle jina-reranker-v2-base-multilingual excelle sur les langues européennes.

Solution reranking	Type	Souveraineté	Performance FR	Latence (100 paires)
Cohere Rerank	API cloud	Non (Canada)	Bonne	200-500ms
BGE Reranker v2-m3	Open-source local	Totale	Très bonne	100-300ms (GPU)
Jina Reranker v2	Open-source / API	Locale possible	Excellente	150-400ms (GPU)
Flashrank	Open-source local	Totale	Correcte	50-100ms (CPU)

Hybrid search : dense + sparse BM25

La recherche vectorielle pure (dense search) est puissante pour la similarité sémantique — trouver des passages qui parlent de la même chose avec des mots différents. Mais elle échoue sur :

• Les requêtes avec des termes très spécifiques (noms de produits, numéros de référence, termes techniques rares)
• Les requêtes courtes avec peu de signal sémantique
• Les requêtes en langue de niche ou avec un vocabulaire très spécialisé

BM25 : la recherche sparse classique

BM25 est l'algorithme de recherche textuelle classique (utilisé par Elasticsearch, Solr, Lucene). Il score les documents selon la fréquence des termes de la requête dans le document, normalisée par la longueur du document. BM25 est excellent sur les correspondances exactes de termes — là où le dense search est faible.

Reciprocal Rank Fusion : combiner les deux

La technique standard pour combiner dense et sparse est le Reciprocal Rank Fusion (RRF). Chaque requête produit deux listes de résultats classés (dense + BM25). RRF combine ces listes en attribuant à chaque document un score inversement proportionnel à son rang dans chaque liste :

score_rrf(doc) = 1/(k + rang_dense) + 1/(k + rang_sparse)  [k=60 par défaut]

L'avantage de RRF : il ne nécessite pas de normaliser les scores des deux systèmes (qui sont sur des échelles différentes), et se comporte bien empiriquement sur une large variété de cas d'usage.

SPLADE : le meilleur des deux mondes

SPLADE (Sparse and Dense Learned Sparse Expansion) est une approche qui combine apprentissage profond et représentation sparse. Il produit des vecteurs sparse (comme BM25) mais appris (comme les embeddings) — ce qui lui permet de faire de l'expansion de requête (trouver les termes synonymes pertinents) tout en restant efficace pour les requêtes exactes. SPLADE surpasse systématiquement BM25 sur les benchmarks BEIR tout en restant compatible avec des index sparse efficaces.

HyDE : Hypothetical Document Embeddings

HyDE (Hypothetical Document Embeddings, Gao et al., 2022) est une technique contre-intuitive mais efficace : plutôt qu'encoder la requête directement, on demande au LLM de générer un document hypothétique qui répondrait à cette requête, puis on encode ce document hypothétique pour le retrieval.

Pourquoi ça marche : les requêtes courtes ("quelle est notre politique de remboursement ?") sont sémantiquement éloignées des longs passages documentaires qui y répondent. Un document hypothétique généré par le LLM ("Notre politique de remboursement prévoit un délai de 30 jours, applicable aux achats..." ) est sémantiquement beaucoup plus proche des documents réels dans l'espace des embeddings.

Résultat : amélioration du recall de 10-20% sur les questions factuelles. Contre-indication : ajoute la latence d'un appel LLM supplémentaire avant le retrieval — non recommandé pour les applications temps réel très contraintes en latence.

Query Decomposition

Pour les questions complexes, une autre technique complémentaire : la décomposition de requête. Le LLM décompose la question principale en sous-questions plus simples, chacune faisant l'objet d'un retrieval indépendant. Les résultats sont agrégés avant d'être fournis au LLM pour la réponse finale.

Exemple : "Compare notre politique de confidentialité avec le RGPD et identifie les lacunes" → sous-questions : (1) "Que dit notre politique de confidentialité sur les droits des utilisateurs ?" + (2) "Quelles sont les exigences du RGPD sur les droits des utilisateurs ?"

Évaluation RAG avec RAGAS

RAGAS (Retrieval-Augmented Generation Assessment) est le framework d'évaluation de référence pour les systèmes RAG. Il fournit 4 métriques complémentaires qui couvrent les deux composants du système : le retriever et le générateur.

Les 4 métriques RAGAS

1. Faithfulness : dans quelle mesure la réponse générée est-elle fidèle aux documents récupérés ? RAGAS décompose la réponse en affirmations atomiques et vérifie si chacune est supportée par un passage du contexte. Une réponse peut être "correcte" mais pas fidèle si elle introduit des informations absentes des sources — signe d'hallucination.

2. Answer Relevance : la réponse répond-elle réellement à la question posée ? RAGAS génère des questions hypothétiques à partir de la réponse et mesure si ces questions correspondent à la question originale. Une réponse qui "parle du sujet" sans répondre directement score bas.

3. Context Recall : les documents pertinents ont-ils été récupérés ? Cette métrique mesure la capacité du retriever à trouver toutes les informations nécessaires. Nécessite une réponse de référence (ground truth) pour comparer. Identifie si le problème vient du retriever ou du générateur.

4. Context Precision : les documents récupérés sont-ils tous pertinents ? Mesure le signal/bruit du retrieval. Un context precision faible indique trop de chunks non pertinents — qui dilue l'attention du LLM et augmente les coûts.

Métrique RAGAS	Ce qu'elle mesure	Problème identifié si bas	Levier d'amélioration
Faithfulness	Fidélité au contexte récupéré	Hallucinations du LLM	Prompt system, température, modèle
Answer Relevance	Pertinence de la réponse	Réponses hors sujet	Prompt, instructions LLM
Context Recall	Couverture du retriever	Documents manquants	Chunking, embeddings, top-k
Context Precision	Précision du retriever	Bruit dans le contexte	Reranking, filtrage métadonnées

Mettre en place RAGAS

RAGAS peut être utilisé avec des LLM locaux (via Ollama) — pas de dépendance à OpenAI :

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_recall
from langchain_community.llms import Ollama

llm = Ollama(model="mistral")

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

Pour construire le dataset d'évaluation, RAGAS peut générer automatiquement des paires question/réponse de référence depuis vos documents via TestsetGenerator — réduisant considérablement l'effort d'annotation manuelle.

Diagnostic et optimisation iterative

La séquence d'optimisation recommandée :

1. Mesurer le baseline : évaluer le système naïf sur 100 questions représentatives
2. Identifier le goulot d'étranglement : context recall faible → problème retriever ; faithfulness faible → problème LLM/prompt
3. Appliquer une optimisation à la fois : ne changer qu'une variable à la fois pour mesurer son impact isolé
4. Mesurer l'impact sur l'ensemble du dataset (pas seulement sur les exemples qui ont motivé le changement)
5. Itérer jusqu'à atteindre les seuils de qualité définis pour la mise en production

RAG vs fine-tuning pour la confidentialité des données

Le débat RAG vs fine-tuning a une dimension de confidentialité souvent ignorée.

Pourquoi le RAG est supérieur pour la confidentialité

Avec le fine-tuning, vos données métier sont intégrées dans les poids du modèle lors de l'entraînement. Ces données peuvent être :

• Extraites par des attaques de memorization (le modèle reproduit des extraits de données d'entraînement)
• Transmises si vous utilisez un fournisseur cloud pour le fine-tuning (vos données transitent vers leurs serveurs)
• Irrécupérables si vous souhaitez "désapprendre" une information (pas de suppression ciblée possible dans les poids)

Avec le RAG, vos données restent dans votre vector store — séparé du modèle. Si une donnée doit être supprimée (droit à l'oubli RGPD, document obsolète), on supprime simplement le vecteur correspondant. Le modèle LLM n'a jamais eu accès à cette donnée — il ne peut pas la mémoriser.

RAG souverain on-premise : l'architecture complète

Une architecture RAG 100% souveraine combine :

• Modèle d'embedding local : multilingual-e5-large-instruct (Microsoft, open-source) ou nomic-embed-text (Nomic AI, open-source) déployé via Ollama ou HuggingFace Inference
• Vector store on-premise : Qdrant (performant, Docker-ready, open-source), Chroma (simple, SQLite), ou pgvector (extension PostgreSQL — si vous avez déjà PostgreSQL)
• Reranker local : BGE-reranker-v2-m3 (open-source, GPU ou CPU)
• LLM local : Mistral 7B/Large, Llama 3.3, ou Qwen 2.5 via Ollama ou vLLM
• Orchestration : LangChain ou LlamaIndex (Python, open-source)

Aucun composant de cette stack ne nécessite une connexion externe. Vos documents, vos embeddings, et vos réponses restent entièrement dans votre périmètre.

Questions fréquentes sur le RAG avancé

Quelle taille de chunk utiliser pour commencer avec le semantic chunking ?

Le semantic chunking adapte automatiquement la taille — c'est son avantage. Mais vous pouvez contraindre des tailles min/max : typiquement 100 tokens minimum (pour éviter les micro-chunks sans contexte) et 800-1000 tokens maximum (pour éviter les méga-chunks qui noient le signal spécifique). Pour commencer, utilisez le SemanticChunker de LangChain avec le seuil de rupture à 95e percentile de similarité — c'est un bon point de départ à ajuster selon vos résultats RAGAS.

Le reranking ralentit-il significativement les réponses RAG ?

Avec un modèle de reranking GPU (BGE-reranker sur une RTX 3090), scorer 50 paires (requête, chunk) prend environ 100-200ms — ajout de latence très acceptable pour la grande majorité des cas d'usage. Sur CPU, comptez 500ms à 2 secondes selon le modèle et le hardware. Pour les applications ultra-latence-sensibles (<500ms end-to-end), des modèles de reranking plus légers (Flashrank, ms-marco-MiniLM-L-6) offrent un compromis performance/vitesse acceptable. En pratique, le gain de qualité du reranking vaut presque toujours les 100-500ms additionnels.

Quelle base vectorielle choisir pour un RAG souverain ?

Qdrant est notre recommandation principale pour les déploiements production souverains : open-source (Apache 2.0), performant, supporte les filtres de métadonnées complexes, hybrid search natif (dense + sparse), et se déploie en un conteneur Docker. pgvector est idéal si vous avez déjà PostgreSQL dans votre infrastructure — évite un service supplémentaire. Chroma est excellent pour les prototypes et les petits volumes (quelques millions de chunks) mais montre des limites en performance à grande échelle. Évitez les solutions SaaS cloud (Pinecone, Weaviate cloud) si la souveraineté est une exigence.

Comment gérer les documents multilingues dans un RAG ?

Trois stratégies : (1) Modèle d'embedding multilingue (multilingual-e5-large, mGTE) qui encode toutes les langues dans le même espace vectoriel — une requête en français trouvera des documents pertinents en anglais et vice versa. C'est la solution la plus simple et souvent la meilleure. (2) Index par langue si les documents sont clairement séparés par langue et que la recherche cross-lingue n'est pas souhaitée. (3) Traduction avant indexation (via un LLM local) — coûteux mais maximise la précision si vos embeddings monolingues sont meilleurs que le multilingue disponible.

À quel moment le fine-tuning est-il préférable au RAG pour la gestion des données métier ?

Le fine-tuning surpasse le RAG dans des cas spécifiques : (1) Style et format — si votre LLM doit systématiquement écrire dans un style ou format très spécifique (langage juridique précis, terminologie technique propriétaire), le fine-tuning inculque ce style mieux que le RAG ; (2) Raisonnement métier tacite — des règles implicites complexes qui ne s'expriment pas facilement en documents mais qui s'apprennent d'exemples (ex : jugement d'un expert senior) ; (3) Latence ultra-faible — un modèle fine-tuné répond sans overhead de retrieval. Dans tous les autres cas (données qui changent, confidentialité stricte, explication des sources, droit à l'oubli), le RAG est préférable. Les deux approches sont complémentaires — RAG + fine-tuning combinés donnent souvent les meilleurs résultats.

Comment évaluer un RAG sans ground truth (sans réponses de référence) ?

RAGAS propose des métriques qui ne nécessitent pas de ground truth : Answer Relevance et Faithfulness peuvent être calculées sans réponses de référence préétablies — RAGAS génère lui-même les questions hypothétiques ou les affirmations à vérifier. Pour Context Recall (qui nécessite normalement une ground truth), RAGAS TestsetGenerator peut générer automatiquement des paires question/réponse de référence depuis vos documents via un LLM — réduisant l'annotation manuelle à une revue de validation plutôt qu'une création from scratch. En pratique, avec 50-100 questions générées et validées par vos experts métier, vous avez un eval set suffisant pour diagnostiquer les problèmes majeurs de votre pipeline RAG.