Table des matières
- 1. Rappel : les limites du RAG naïf
- 2. Le pipeline RAG moderne en un coup d'œil
- 3. ① Chunking (le plus important)
- 4. ② Choisir un modèle d'embedding
- 5. ③ Choisir une base vectorielle (comparatif)
- 6. ④ Recherche hybride (BM25 + vecteur)
- 7. ⑤ Reranking (retrieve-then-rerank)
- 8. Frameworks (LlamaIndex/LangChain)
- 9. RAG vs long contexte
- 10. Précautions pour la mise en production
- Résumé
- FAQ
Vous comprenez ce qu'est le RAG. Mais lorsqu'on en construit un réellement, beaucoup se heurtent à un mur : « ça marche à peu près, mais la réponse essentielle est à côté de la plaque. » La cause est presque toujours la même — il s'agit encore d'un « RAG naïf » : découper le document sans soin et faire une simple recherche vectorielle.
Le RAG pratique en 2026 a clairement dépassé ce stade. Les clés résident dans un pipeline multi-étapes : « chunking intelligent → le bon embedding → recherche hybride (mots-clés + vecteur) → reranking. » En tant que volet implémentation de l'article 030, cet article couvre le comment-faire concret de chaque étape, le choix d'une base vectorielle (Chroma/pgvector/Qdrant/Pinecone/Weaviate/Milvus), les frameworks, et même « a-t-on encore besoin du RAG à l'ère du million de tokens ? » — l'essentiel d'une implémentation plus avancée.
Les 5 étapes du RAG moderne
— du RAG naïf au RAG qui fonctionne en production
Les deux plus grands gains de précision : la recherche hybride (BM25 + vecteur) et le reranking.
Le simple ajout de ces deux éléments corrige largement le problème du « réponse à côté » du RAG naïf.
* Les noms d'outils, méthodes et chiffres de benchmark sont basés sur des sources officielles et plusieurs médias techniques (à la date de 2026). Ce domaine évolue vite et les meilleures options changent. Les chiffres de benchmark sont rapportés par les sources et varient selon les données et les conditions. Évaluez sur vos propres données (ci-dessous) avant de choisir.
1. Rappel : les limites du RAG naïf
Le RAG minimal consiste à « découper le document → vectoriser avec des embeddings → stocker dans une base vectorielle → vectoriser la question et récupérer les chunks les plus proches → les transmettre au LLM pour répondre. » Ce sont les bases du RAG. Mais ce « RAG naïf » présente des faiblesses typiques.
- Chunks bâclés : coupés en plein milieu d'une phrase, ce qui casse le sens.
- Recherche vectorielle seule : faible sur les termes exacts comme les noms de produits ou les numéros de modèle (elle attrape/manque des éléments sémantiquement proches mais lexicalement différents).
- Transmettre les N premiers tels quels : les éléments réellement les plus pertinents finissent enfouis.
Le RAG pratique en 2026 écrase ces trois problèmes grâce au « découpage intelligent », à la « recherche hybride » et au « reranking ». Voyons cela dans l'ordre.
2. Le pipeline RAG moderne en un coup d'œil
Le flux de données d'un RAG en production comporte deux voies : la préparation (indexation) et le moment de la requête (recherche et génération).
Deux phases
Préparation (hors ligne) : chunker le document intelligemment → vectoriser avec des embeddings → stocker dans une base vectorielle (construire un index par mots-clés en même temps).
Moment de la requête (en ligne) : récupérer les 50-100 premiers avec la recherche hybride (BM25 + vecteur) → réduire à quelques-uns avec le reranking → transmettre au LLM pour générer la réponse.
La différence avec le RAG naïf tient à la présence ou non de « ④ la recherche hybride » et de « ⑤ le reranking ». Ces deux étapes portent la précision de recherche à un niveau exploitable.
3. ① Chunking (le plus important)
On peut affirmer que le chunking détermine la moitié de la qualité du RAG. Voici les principales stratégies.
| Stratégie | Ce qu'elle fait | Adaptée à |
|---|---|---|
| recursive 512 tokens | Un choix par défaut pragmatique. Classée n°1 sur 7 stratégies dans un benchmark de février 2026 | En cas de doute, celle-ci |
| semantic | Découpe là où le sens change, pour que chaque chunk soit thématiquement cohérent | Documents techniques denses |
| structural | Respecte les titres, les blocs de code, les sections HTML | Documentation et code |
| parent-child (hiérarchique) | Recherche précise sur de petits chunks ; renvoie le chunk parent environnant au moment de la réponse | Équilibrer précision et contexte |
Si la perte de contexte aux frontières pose problème, Contextual Retrieval (attacher le contexte du document entier à chaque chunk) ou Late Chunking aide. Anthropic rapporte que Contextual Retrieval + reranking ont réduit les échecs de récupération du top-20 jusqu'à 67 % (chiffre rapporté). L'ordre réaliste : commencer par « recursive 512 », puis ajouter semantic / parent-child / Contextual Retrieval si la précision est insuffisante.
4. ② Choisir un modèle d'embedding
Le modèle d'embedding convertit les chunks en vecteurs — le fondement de la précision de recherche.
- Choix par défaut sûr : OpenAI text-embedding-3-large. Un bon équilibre entre qualité de récupération et facilité d'intégration.
- Autres options : Cohere, Voyage, les embeddings Gemini, et divers modèles OSS.
- Important : de nombreux embeddings OSS sont largement suffisants pour la production lorsqu'ils sont combinés à la recherche hybride + le reranking. Ne vous focalisez pas uniquement sur l'embedding.
L'essentiel est de traiter « l'embedding comme une partie de l'ensemble du pipeline de recherche ». Plutôt que de remplacer par un embedding coûteux, ajouter la recherche hybride et le reranking est souvent plus rentable.
5. ③ Choisir une base vectorielle (comparatif)
La base vectorielle stocke et recherche les vecteurs. Voici les leaders de 2026 selon leur caractère.
| BD | Caractère / point fort | Pour qui |
|---|---|---|
| Chroma | AI-native, local-first, API Python simple | Particuliers/PoC prototypant un RAG le plus vite |
| pgvector | Une extension Postgres. Pas de seconde base, cohérence transactionnelle | Équipes déjà sur Postgres |
| Qdrant | Faible latence (p50 ~4ms ; rapporté vs Milvus ~6ms / Pinecone ~8ms) | Axé vitesse, production |
| Pinecone | Entièrement managé. Zéro infra, démarrage avec une simple clé API | Veulent déléguer l'exploitation, cloud-first |
| Weaviate | Champion de la recherche hybride (BM25 + vecteur + métadonnées en une requête) | Gros utilisateurs de recherche hybride |
| Milvus | De qualité entreprise, gère des milliards de vecteurs | Très grande échelle |
Les axes de sélection : « échelle, managé vs auto-hébergé, stack existante, budget ». En cas de doute — Chroma pour le prototypage, pgvector si vous avez Postgres, Qdrant/Pinecone pour une production équilibrée, Weaviate pour les usages hybrides intensifs. Pour la plupart des charges RAG, Pinecone / Weaviate / Qdrant sont considérés comme de solides choix.
6. ④ Recherche hybride (BM25 + vecteur)
Ce qui corrige la plus grande faiblesse du RAG naïf — sa faiblesse sur les termes exacts — c'est la recherche hybride. Elle fusionne BM25 (recherche par mots-clés / lexicale) avec la recherche vectorielle dense.
Fusionner lexical + sémantique
Fusionner les deux avec le Reciprocal Rank Fusion (RRF) est rapporté pour
battre systématiquement chaque approche prise isolément (NDCG plus élevé).
En pratique, le plus simple est d'utiliser une base qui renvoie des résultats hybrides en une seule requête, comme Weaviate. Laissez le réglage délicat des scores au RRF (fusion basée sur le rang) et cela ne cassera pas. Résultat : une recherche solide à la fois sur les termes exacts et les paraphrases.
7. ⑤ Reranking (retrieve-then-rerank)
Le standard de 2026, c'est « deux étapes : récupérer largement d'abord → puis réduire (rerank). »
- Étape 1 (retrieve) : récupérer rapidement les 50-100 premiers avec un bi-encoder (embeddings).
- Étape 2 (rerank) : avec un cross-encoder, scorer (question, chunk) conjointement et réduire aux quelques-uns réellement les plus pertinents.
Les rerankers populaires sont Cohere Rerank 3.5, Voyage rerank-2.5, BGE reranker-v2, Jina Reranker v2. Le reranking ajoute environ 50-200ms de latence et un coût, mais comme les chunks transmis au LLM se réduisent à un petit nombre choisi, il réduit souvent la consommation de tokens du LLM et abaisse le coût total. Sur la précision comme sur le coût, le reranking devient une étape qu'on « n'a aucune raison de ne pas ajouter ».
8. Frameworks (LlamaIndex/LangChain)
Utiliser un framework est plus rapide que tout écrire soi-même. Voici la répartition des rôles en 2026.
- LlamaIndex : axé récupération. Fort sur l'indexation de documents, la qualité de recherche et l'itération rapide sur le RAG.
- LangChain / LangGraph : le volet orchestration (contrôle). Workflows complexes et coordination d'agents.
- Schéma combiné : en pratique, beaucoup utilisent LlamaIndex comme couche de récupération et LangGraph comme couche de contrôle.
Notez que, dernièrement, avec la standardisation des outils via MCP et la montée des Agent SDK, une tendance se dessine où les agents construisent des pipelines à la volée sans frameworks LLM lourds. Cela dit, si vous peaufinez la qualité de recherche, la famille LlamaIndex reste solide. Pour la construction d'agents en général, voir comment construire un agent IA.
9. RAG vs long contexte
« Avec une fenêtre de contexte de 1M tokens, ne puis-je pas tout y mettre et me passer du RAG ? » — une question fréquente. La réponse est « non, le RAG n'est pas remplacé. »
Le piège du « tout y mettre »
- Inefficace en tokens : envoyer à chaque fois un contexte énorme et redondant coûte cher.
- Lost in the middle : l'information au milieu d'un long texte tend à être ignorée.
- Distraction : plus il y a d'informations non pertinentes, plus la qualité de la réponse baisse.
La ligne directrice : utilisez le long contexte pour les petits corpus et l'itération rapide, ajoutez tôt le prompt caching pour un contexte répété stable, et ajoutez le RAG dès que « fraîcheur, échelle, provenance » deviennent des exigences. « Tout mettre dans la fenêtre de contexte » est le nouveau « il suffit d'ajouter une base vectorielle » — pas une panacée. Associez cela à une compréhension de la fenêtre de contexte.
10. Précautions pour la mise en production
- Construisez d'abord une évaluation : « ça s'est un peu amélioré » ne peut pas être amélioré. Quantifiez la précision de récupération avec un ensemble de questions représentatives × sources attendues et comparez à chaque changement.
- Monitoring : surveillez en continu le taux de réussite de récupération, la pertinence après rerank et l'ancrage des réponses.
- Conception des coûts : la facturation provient des embeddings, du reranking et du LLM. Réduire les tokens du LLM via le reranking est l'économie standard. Voir économie de tokens.
- Fraîcheur et provenance : concevez pour refléter les mises à jour des données (ré-indexation) et joignez toujours la source (quel document) aux réponses — clé pour lutter contre les hallucinations.
- Données confidentielles : soyez prudent lors de la vectorisation de documents internes et de leur placement à l'extérieur. Voir directives d'utilisation de l'IA en entreprise.
Résumé
Le RAG pratique a évolué du naïf « découper et rechercher par vecteur » vers un pipeline multi-étapes : « chunking intelligent → embedding → base vectorielle → recherche hybride → reranking ». Les deux plus grands gains de précision sont la recherche hybride (fusionner BM25 + vecteur avec RRF) et le reranking (retrieve-then-rerank) — le simple ajout de ces deux éléments corrige largement le « réponse à côté ».
Pour les bases vectorielles : Chroma pour le prototypage, pgvector si vous avez Postgres, Qdrant/Pinecone pour la production, Weaviate pour les usages hybrides intensifs. Pour les frameworks : LlamaIndex pour la récupération, LangChain/LangGraph pour le contrôle. Et même à 1M tokens, le RAG n'est pas remplacé — si vous avez besoin de fraîcheur, d'échelle et de provenance, c'est le RAG. Un dernier impératif : « construire d'abord l'ensemble d'évaluation. » On ne peut pas améliorer ce qu'on ne peut pas mesurer. Gardez cela et votre RAG évoluera de façon fiable du « ça marche à peu près » au « ça fonctionne en production ».
Lectures associées : qu'est-ce que le RAG (bases), qu'est-ce qu'une fenêtre de contexte, comment construire un agent IA, Claude Agent SDK, et qu'est-ce que MCP.
FAQ
Q. La précision de mon RAG est faible. Que dois-je corriger en premier ?
A. Ajouter les deux éléments — « recherche hybride » et « reranking » — est le plus efficace. La simple recherche vectorielle seule est faible sur les termes exacts comme les numéros de modèle et les noms propres, et les chunks les plus pertinents finissent enfouis. Fusionner avec BM25 (via RRF) + un rerank par cross-encoder porte la qualité de recherche à un niveau exploitable. Si cela ne suffit toujours pas, revoyez votre chunking.
Q. Quelle base vectorielle choisir ?
A. Chroma pour le prototypage, pgvector si vous avez déjà Postgres sont les démarrages faciles. Pour une production équilibrée, Qdrant (faible latence) ou Pinecone (entièrement managé) ; pour une recherche hybride intensive, Weaviate ; pour une très grande échelle, Milvus. Choisissez selon l'échelle, la préférence d'exploitation, la stack existante et le budget.
Q. Quelle taille de chunk est bonne ?
A. Environ 512 tokens avec un découpage recursive est un choix par défaut pragmatique (rapporté proche du sommet dans les benchmarks 2026). Pour les documents techniques, semantic (découpe par le sens) ; pour la documentation/le code, structural (respecter les titres/le code) ; pour la précision plus le contexte, parent-child. Commencez à 512 et ajustez en évaluant.
Q. Avec une fenêtre de 1M tokens, le RAG n'est-il pas inutile ?
A. Il ne devient pas inutile. Tout entasser dans le contexte fait chuter la qualité par inefficacité en tokens, « lost in the middle » et distraction. Utilisez le long contexte pour les petits corpus et les prototypes, et le RAG dès que la fraîcheur, l'échelle et la provenance sont des exigences — voilà la répartition réaliste.
Q. LangChain ou LlamaIndex — lequel utiliser ?
A. LlamaIndex si vous peaufinez la qualité de recherche ; LangChain/LangGraph pour le contrôle complexe et la coordination d'agents. En pratique, beaucoup les combinent — « LlamaIndex comme couche de récupération, LangGraph comme couche de contrôle ». Dernièrement, il y a aussi une tendance à assembler légèrement avec les Agent SDK, alors choisissez selon vos besoins.
