RAG en 2026 : au-delà du tutoriel, vers une architecture de retrieval sérieuse

Le RAG, pour Retrieval-Augmented Generation, est devenu le pattern de référence pour connecter un LLM à une base de connaissances propriétaire. Toute l’industrie l’a adopté, les tutoriels se multiplient, et pourtant, les déploiements en production continuent souvent de décevoir. Le problème ne vient pas du concept en lui-même. Il vient plutôt du fait que la majorité des implémentations restent bloquées à une version “démo” :
embedding → vector store → top-k → prompt. Ce pipeline fonctionne très bien sur des données propres et des questions simples. En revanche, il montre vite ses limites dès qu’il est confronté à des cas d’usage réels. Cet article va donc plus loin qu’un simple tutoriel. L’objectif est d’analyser les points de défaillance courants des systèmes RAG, puis de présenter les architectures qui permettent d’y répondre sérieusement.

Pourquoi le RAG naïf échoue

Avant de parler de solutions, il faut identifier clairement les problèmes.

1. Le problème de la granularité

Le chunking, c’est-à-dire le découpage des documents en morceaux indexables, est l’une des étapes les plus déterminantes dans la qualité d’un système RAG. Pourtant, c’est souvent celle à laquelle on accorde le moins d’attention. Un chunk trop grand risque de contenir une information pertinente noyée dans beaucoup de bruit. Le LLM doit alors faire un effort supplémentaire pour extraire ce qui est réellement utile. À l’inverse, un chunk trop petit fragmente le contexte. Une information qui s’étend sur plusieurs paragraphes peut se retrouver coupée en plusieurs morceaux distincts, dont aucun n’est réellement exploitable seul. Le chunking à taille fixe, par exemple 512 ou 1024 tokens, ignore souvent la structure sémantique du document. Une phrase comme “En résumé, les trois risques identifiés sont…” n’a pas de valeur si elle est séparée des paragraphes précédents. Pourtant, dans un découpage automatique, elle peut être indexée seule et remontée comme résultat.

2. Le problème du décalage entre la question et le document

Les embeddings de similarité sémantique fonctionnent bien lorsque la question formulée par l’utilisateur ressemble à la réponse présente dans les documents. Mais ce n’est pas toujours le cas. Par exemple, un utilisateur peut demander :
“Quel est le délai de préavis si je veux résilier le contrat ?” Alors que le document contient plutôt :
“La partie souhaitant mettre fin à la présente convention devra en informer l’autre partie par lettre recommandée avec accusé de réception dans un délai minimum de quatre-vingt-dix jours calendaires.” Le sens est proche, mais les formulations sont différentes. L’utilisateur parle de “résilier”, le document parle de “mettre fin à la convention”. L’embedding peut capter une partie du lien sémantique, mais pas toujours de manière optimale.

3. Le problème de la récence et de la cohérence temporelle

Dans une base documentaire vivante, les documents évoluent. Une politique interne peut exister en plusieurs versions : une version 2023, une version 2025, puis une nouvelle mise à jour en 2026. Sans gestion explicite de la temporalité, un système RAG peut retourner une ancienne version avec autant de confiance qu’une version actuelle. C’est particulièrement problématique lorsqu’il s’agit de règles internes, de contrats, de procédures ou de documentation réglementaire.

4. Le problème du “lost in the middle”

Même lorsque le retrieval fonctionne correctement, le LLM peut passer à côté de l’information utile. Les modèles ont tendance à mieux exploiter les informations situées au début ou à la fin d’un long contexte. Lorsqu’une information importante se retrouve au milieu d’une grande quantité de chunks, elle peut être moins bien prise en compte. Autrement dit, même avec un bon retrieval, l’organisation du contexte envoyé au modèle peut dégrader la qualité de la réponse.

Les architectures qui répondent à ces problèmes

1. Le chunking hiérarchique et l’indexation multi-niveaux

Une approche plus robuste consiste à indexer les documents à plusieurs niveaux de granularité :

document entier ;
section ;
paragraphe.

Le retrieval peut se faire au niveau du paragraphe pour maximiser la précision. Ensuite, au moment de générer la réponse, on remonte vers la section parente pour fournir au LLM un contexte plus complet et cohérent.

Cette approche permet de combiner deux objectifs souvent opposés :
la précision du retrieval et la richesse du contexte fourni au modèle.

Elle est particulièrement utile pour les corpus structurés, comme les documentations techniques, les contrats, les procédures internes ou les bases de connaissances métier.

2. La recherche hybride : dense + sparse

La recherche vectorielle, aussi appelée recherche dense, est très efficace pour retrouver des contenus proches sur le plan sémantique. Elle permet de détecter des reformulations, des paraphrases ou des concepts exprimés différemment. Mais elle n’est pas toujours idéale pour les correspondances exactes. C’est là que la recherche sparse, par exemple BM25, devient complémentaire. Elle fonctionne très bien pour retrouver :

un terme technique précis ;
un nom propre ;
un numéro de version ;
une référence contractuelle ;
une expression exacte.

La recherche hybride combine donc les deux approches :
la similarité sémantique des embeddings et la précision lexicale de BM25. Dans la pratique, cette combinaison est souvent plus fiable qu’une recherche vectorielle seule, surtout dans les bases documentaires techniques, juridiques ou métier.

3. La query expansion et le rewriting

Une autre limite fréquente du RAG naïf consiste à envoyer directement la question brute de l’utilisateur dans le vector store. Or, une question utilisateur est parfois trop courte, ambiguë ou formulée dans un vocabulaire différent de celui des documents. Pour améliorer le retrieval, on peut transformer la requête avant de l’exécuter. Deux approches sont particulièrement intéressantes : HyDE, ou Hypothetical Document Embeddings
L’idée consiste à demander au LLM de générer une réponse hypothétique à la question. Ensuite, on embed cette réponse hypothétique plutôt que la question initiale. Pourquoi ? Parce qu’une réponse hypothétique ressemble souvent davantage aux documents contenant la vraie réponse qu’à la question posée par l’utilisateur. Multi-query retrieval
Cette méthode consiste à générer plusieurs reformulations de la question, puis à agréger les résultats obtenus. Elle est utile lorsqu’une question peut être interprétée de plusieurs manières ou lorsqu’il existe plusieurs formulations possibles pour une même intention.

4. Le reranking post-retrieval

Le vector search retourne les documents les plus proches dans l’espace d’embedding. Mais cette proximité n’est pas toujours le meilleur indicateur de pertinence réelle. C’est pourquoi on ajoute souvent une étape de reranking. Le principe est simple :

On récupère rapidement un ensemble de candidats, par exemple les 50 chunks les plus proches.
On utilise ensuite un modèle plus précis, souvent un cross-encoder, pour réévaluer la pertinence de chaque couple question/document.
On sélectionne finalement les meilleurs résultats, par exemple les 5 chunks les plus pertinents, qui seront envoyés au LLM.

Cette étape améliore fortement la qualité finale, car elle permet de filtrer les résultats approximatifs et de prioriser les passages réellement utiles. Des modèles comme Cohere Rerank ou BGE-Reranker sont aujourd’hui largement utilisés pour ce type d’approche, notamment sur des corpus multilingues ou non anglophones.

5. La compression contextuelle

Renvoyer un chunk entier au LLM n’est pas toujours optimal. Un chunk de 500 tokens peut contenir la réponse utile dans seulement 50 tokens. Le reste constitue alors du bruit, qui occupe inutilement la fenêtre de contexte. La compression contextuelle consiste à extraire uniquement les passages réellement pertinents par rapport à la question posée. Cette approche permet de réduire le bruit, d’améliorer la lisibilité du contexte et de limiter le risque que le modèle se perde dans des informations secondaires.

Comment évaluer un pipeline RAG

Un pipeline RAG doit être évalué sur deux dimensions distinctes :

la qualité du retrieval ;
la qualité de la génération.

Les métriques de retrieval

Recall@k
Cette métrique mesure si le document attendu apparaît bien dans les k premiers résultats retournés. MRR, ou Mean Reciprocal Rank
Elle mesure la position du premier document pertinent dans la liste des résultats. Precision@k
Elle indique combien de documents parmi les k résultats retournés sont réellement pertinents. Ces métriques permettent de savoir si le système retrouve les bons documents avant même de regarder la réponse générée par le LLM.

Les métriques de génération

Pour évaluer la qualité de la réponse finale, on peut utiliser des frameworks comme RAGAS ou des approches de type LLM-as-judge. Les critères importants sont notamment : Faithfulness
La réponse est-elle fidèle aux documents fournis, sans hallucination ? Answer relevancy
La réponse répond-elle réellement à la question posée ? Context precision
Le contexte transmis au modèle était-il suffisant et pertinent pour générer une bonne réponse ? RAGAS permet d’automatiser une partie de cette évaluation et de mettre en place un suivi continu de la qualité. C’est particulièrement utile pour détecter les régressions avant qu’elles n’atteignent les utilisateurs finaux.

Ce qui fait vraiment la différence

Après plusieurs projets RAG menés jusqu’en production, certains leviers se démarquent clairement.

Impact fort, effort modéré

Passer d’un chunking à taille fixe à un chunking sémantique peut améliorer significativement le recall. Ajouter un reranker permet souvent d’améliorer la précision finale. Mettre en place une évaluation systématique permet de détecter les régressions avant qu’elles ne deviennent visibles pour les utilisateurs.

Impact moyen, effort plus important

Une architecture hiérarchique complète devient très pertinente sur des corpus fortement structurés, comme les contrats, les documentations techniques ou les bases de connaissances internes. Le fine-tuning des embeddings sur un domaine spécifique peut apporter de vrais gains, mais demande un investissement plus conséquent.

Souvent surestimé

Augmenter simplement le top-k sans reranking n’est pas toujours une bonne solution. Cela ajoute souvent plus de bruit que de valeur. Changer de modèle d’embedding peut aussi avoir un impact limité si les bases du pipeline, notamment le chunking, sont mal conçues.

Conclusion

Le RAG est aujourd’hui une approche mature. Les briques techniques existent, elles sont documentées et souvent disponibles en open-source. Ce qui distingue un système RAG fiable d’une simple démonstration, ce n’est donc pas seulement l’accès à la technologie. C’est la rigueur avec laquelle chaque couche du pipeline est pensée, testée et évaluée. Le chunking mérite autant d’attention que le choix du modèle.
L’évaluation n’est pas optionnelle.
Le retrieval hybride est, dans la plupart des cas, plus robuste qu’un retrieval dense utilisé seul. Ces principes ne sont pas révolutionnaires. Ce sont simplement des fondamentaux d’ingénierie appliqués à un nouveau domaine. Et c’est justement ce qui fait la différence entre un RAG qui impressionne en démonstration et un RAG qui fonctionne réellement en production. Olympp conçoit et déploie des architectures RAG en production pour des clients disposant de bases documentaires réelles, d’utilisateurs réels et d’exigences de fiabilité concrètes. Vous êtes dans ce cas ? Parlons-en.