Un RAG naïf — embarquer la question, récupérer le top-k par similarité, générer — fonctionne sur quelques questions faciles. Mais dès qu'on le confronte à des questions réelles, variées, parfois mal formulées, il montre ses limites. Bonne nouvelle : ces limites ont des causes identifiables, et chaque cause a son levier d'amélioration. Cet article recense pourquoi le RAG naïf échoue, puis dresse la carte des leviers organisée par étape du pipeline — côté requête, côté indexation, côté récupération — avec une règle d'or : n'adopter un levier que s'il apporte un gain mesuré.
Pourquoi le RAG naïf échoue
Le RAG naïf repose sur un pari implicite : la question de l'utilisateur, telle quelle, est un bon vecteur de recherche, et le top-k par similarité contient la réponse. Ce pari tient mal dès qu'on sort des cas d'école.
- La question est mal posée pour la recherche. Trop vague, trop courte, pleine de sous-entendus, ou formulée très différemment des documents. « Et pour l'eau ? » ne ressemble à rien dans la base, même si la réponse y est.
- La question est en réalité plusieurs questions. « Quelle tente et quel réchaud pour un trek de 3 jours ? » mélange deux besoins ; un seul vecteur les sert mal tous les deux.
- La similarité sémantique ne suffit pas. Sur les noms propres, références produit, codes, sigles ou termes exacts, la recherche par mot-clé bat parfois la recherche vectorielle — et le naïf ignore cette piste.
- Le chunk récupéré manque de contexte. Un passage isolé (« Il est de 14 jours. ») a perdu, à l'indexation, l'information qui le rattache à son document.
- Le top-k mélange le bon et le médiocre. La similarité brute ne distingue pas finement le passage vraiment pertinent du passage seulement ressemblant ; le meilleur peut arriver en 4ᵉ position, hors d'un
k trop court.
Aucun de ces problèmes ne se règle en changeant de LLM. Ils se règlent en agissant sur le pipeline, à l'endroit où le problème naît. Les leviers s'organisent naturellement selon les étapes de ce pipeline.
La question brute est rarement la meilleure requête. Plusieurs techniques la retravaillent avant la recherche :
- Multi-query : reformuler la question en plusieurs variantes pour couvrir différents angles, puis fusionner les résultats.
- Décomposition : casser une question composée en sous-questions, chacune cherchée séparément.
- Step-back : prendre du recul avec une question plus générale, dont le contexte éclaire la question précise.
- HyDE (Hypothetical Document Embeddings) : générer une réponse hypothétique et l'embarquer à la place de la question — souvent plus proche des documents que la question elle-même.
- Routing (Adaptive RAG) : diriger la requête vers la bonne source ou stratégie selon son type, et exploiter les filtres de métadonnées pour restreindre au bon sous-ensemble.
Côté indexation : préserver le contexte
Le problème du chunk orphelin se règle en amont, au moment de découper et stocker.
- Contextual retrieval : préfixer chaque chunk d'un court résumé situant le passage dans son document avant de l'embarquer. Cela muscle nettement le retrieval, car le vecteur porte alors son contexte global.
- Late chunking : embarquer le document entier d'abord, puis découper les vecteurs, pour que chaque chunk garde la trace du contexte qui l'entoure.
Côté récupération : mieux trouver et mieux classer
- Recherche hybride : combiner la recherche dense (vectorielle, le sens) et la recherche sparse (lexicale type BM25, les mots exacts), puis fusionner leurs classements avec RRF (Reciprocal Rank Fusion, souvent avec k=60). L'hybride rattrape ce que chaque méthode rate seule.
- Re-ranking : re-classer le top-k récupéré avec un re-ranker — un modèle plus précis (mais plus lent) qui réordonne finement les candidats pour faire remonter le meilleur en tête. On récupère large, puis on affine.
Aller plus loin
Au-delà de ces leviers, des architectures repensent le RAG en profondeur : RAPTOR (indexation hiérarchique par résumés, efficace sur les questions thématiques), ColBERT (late interaction, un vecteur par token), GraphRAG (graphe de connaissances pour les relations complexes) ou l'agentic RAG, où un agent décide lui-même quoi chercher et quand — un pont vers les architectures d'agents.
La méthode : mesurer le gain à chaque étape
Ces leviers ont un coût — latence, appels LLM supplémentaires, complexité, parfois un service managé payant. Aucun ne doit être adopté par principe : chacun se justifie par un gain mesuré. La démarche est invariable : on part d'un RAG de référence, on mesure ses métriques (le baseline), on applique un levier, on re-mesure sur le même jeu d'évaluation, et on compare. Un levier qui n'améliore pas les métriques — ou les améliore à un coût disproportionné — n'a pas sa place.
Une mise en garde : ne pas tout empiler. Chaque levier ajoute de la complexité et de la latence. On les introduit un par un, on garde ceux qui paient, et on s'arrête quand le gain marginal ne vaut plus le coût.
Conclusion
Le RAG naïf échoue sur les questions mal posées, multiples, sur les termes exacts, sur les chunks orphelins et sur un top-k mal classé — autant de problèmes qui se règlent en agissant sur le pipeline, pas sur le modèle. Les leviers s'organisent par étape : côté requête (multi-query, décomposition, step-back, HyDE, routing), côté indexation (contextual retrieval, late chunking) et côté récupération (hybride + RRF, re-ranking). La discipline qui les gouverne est toujours la même : l'avant/après chiffré. On améliore par la mesure, un levier à la fois.
