Architecture RAG
Naive RAG
Le pipeline RAG le plus simple : chunk, embed, retrieve, generate. Point de départ pour tout projet RAG, du prototypage à la première mise en production.
Mis à jour en avril 2026 - Génération 2020-2023
Qu'est-ce que le Naive RAG ?
Le Naive RAG est le pipeline RAG le plus simple et le plus répandu. Il suit un flux linéaire en 4 étapes : découper les documents en fragments (chunks), les transformer en vecteurs (embeddings), rechercher les plus proches sémantiquement à chaque question, puis injecter ces contextes dans le prompt d'un LLM pour générer une réponse.
Formalisé en 2020 par Lewis et al. (Meta AI), ce pattern reste en 2026 le point de départ de tout projet RAG. Un pipeline Naive RAG se déploie en quelques heures avec LangChain, LlamaIndex ou Haystack. Pour un POC, un petit corpus et des questions directes, il fait le travail.
Sa simplicité a un prix. Les benchmarks documentent un taux d'hallucination de 15 à 25 % au-delà de 1 000 documents, des pertes de contexte aux frontières de chunks, et aucune capacité de raisonnement multi-étapes. Cet article détaille chaque étape du pipeline, les coûts réels, les limites mesurées, et quand migrer vers une architecture plus avancée.
Estimez votre pipeline Naive RAG
Deux simulateurs pour dimensionner votre projet : estimez le coût mensuel et visualisez l'impact de vos paramètres de chunking.
Calculateur de coûts pipeline RAG
Tarifs publics OpenAI et Anthropic, avril 2026. Hypothèses : 2 000 tokens/doc, 5 chunks/doc, K=5, 300 tokens/réponse.
Simulateur de chunking
Visualisation des chunks (max 30 affichés)
15
Chunks générés
6 500
Tokens totaux
51
Tokens overlap
< 0,001 $
Coût embedding
Ratio : 1 mot = ~1,3 token (français). Coût embedding avec text-embedding-3-small (0,02 $/1M tokens).
Le pipeline Naive RAG en 4 étapes
Le Naive RAG suit un flux strictement linéaire. Chaque étape alimente la suivante sans boucle de rétroaction ni vérification intermédiaire.
Chunking
Découpage des documents
Les documents source (PDF, pages web, emails) sont découpés en fragments de 256 à 512 tokens. Chaque chunk devient une unité autonome, indexée et recherchée indépendamment. Le choix de la taille et du recouvrement (overlap) influence directement la qualité du retrieval.
Embedding
Vectorisation des chunks
Chaque chunk est transformé en vecteur de haute dimension (768 à 3 072 dimensions) par un modèle comme text-embedding-3-small ou BGE-M3. Deux textes de sens proche produisent des vecteurs proches dans l'espace vectoriel. Ces vecteurs sont stockés dans une base vectorielle.
Retrieval
Recherche des chunks proches
À chaque question, la query est convertie en vecteur avec le même modèle. Une recherche de similarité cosinus identifie les K chunks les plus proches - typiquement K = 3 à 5. Ces chunks sont les contextes candidats pour la génération.
Generation
Réponse par le LLM
Les K chunks récupérés sont concaténés dans le prompt du LLM avec la question originale. Le modèle génère sa réponse en s'appuyant sur le contexte fourni. En Naive RAG, aucune vérification n'est faite sur la qualité du contexte ni sur la fidélité de la réponse.
Comment découper vos documents (chunking)
Le chunking est l'étape la plus sous-estimée et pourtant la plus impactante du Naive RAG. Trois stratégies existent, avec des compromis différents.
Le chunking fixe découpe à intervalles réguliers (512 tokens). Simple à implémenter, mais il coupe souvent au milieu d'une phrase, fragmentant l'information.
Le chunking par paragraphe utilise les sauts de ligne comme délimiteurs. Il préserve mieux la cohérence mais produit des chunks de taille très variable.
Le chunking sémantique découpe en fonction du sens (changement de sujet détecté par un embedding). Plus précis mais plus coûteux - et déjà hors scope du Naive RAG pur.
Paramètres recommandés
- Taille - 256-512 tokens (source : benchmarks LangChain)
- Overlap - 10-20 % du chunk (25-50 tokens)
- Format source - Markdown > HTML > texte brut
- Métadonnées - Inclure titre du document et section dans chaque chunk
Embeddings et bases vectorielles
Un embedding est une représentation numérique du sens d'un texte. Le modèle compresse un chunk en un vecteur de centaines de dimensions. Deux textes sémantiquement proches - même avec des mots différents - produisent des vecteurs proches. La recherche utilise la similarité cosinus, accélérée par un index HNSW pour des temps sub-milliseconde, même sur des millions de vecteurs.
Modèles d'embedding de référence (2026)
| Modèle | Éditeur | Dimensions | MTEB | Coût |
|---|---|---|---|---|
| text-embedding-3-small | OpenAI | 1 536 | 62.3 | 0,02 $/1M tokens |
| text-embedding-3-large | OpenAI | 3 072 | 64.6 | 0,13 $/1M tokens |
| BGE-M3 | BAAI | 1 024 | 68.2 | Self-hosted (GPU) |
| embed-v4 | Cohere | 1 024 | 66.5 | 0,10 $/1M tokens |
Bases vectorielles
| Base | Type | Idéal pour | Coût |
|---|---|---|---|
| Chroma | Open source, in-process | Prototypage, dev local | Gratuit |
| Qdrant | Open source, self-hosted/cloud | Production, self-hosted | Dès 25 $/mois (cloud) |
| Pinecone | Managé, serverless | Production, zéro ops | Dès 0,08 $/1M reads |
| pgvector | Extension PostgreSQL | Stack PostgreSQL existant | Gratuit (+ infra PG) |
Combien coûte un pipeline Naive RAG en 2026
Le Naive RAG est l'architecture la moins coûteuse. Le principal poste de dépense est le LLM de génération, pas les embeddings.
Indexation initiale
2-5 $
One-shot : embedding de 10 000 documents (~10M tokens) avec text-embedding-3-small
Inférence mensuelle
15-50 $/mois
1 000 requêtes/jour avec Claude Haiku 4.5 ou GPT-4o mini (K=5 chunks de 512 tokens)
Stockage vectoriel
0-30 $/mois
Chroma en local (gratuit), Qdrant Cloud dès 25 $/mois, Pinecone dès 0,08 $/1M reads
Estimation totale : 50-100 $/mois
Pour un déploiement type de 10 000 documents avec 1 000 requêtes par jour. Ce budget couvre l'indexation, l'inférence LLM et le stockage vectoriel. En comparaison, un Advanced RAG avec reranking ajoute 20-40 % au coût d'inférence. Tarifs publics OpenAI, Anthropic et éditeurs de bases vectorielles, avril 2026.
5 limites documentées du Naive RAG
Ces limites sont mesurées sur des benchmarks publics. Chacune correspond à une amélioration spécifique dans les architectures avancées.
Lost in the Middle
Les LLM accordent plus d'attention aux premiers et derniers éléments du contexte. Liu et al. (2023) documentent une chute de performance de 20 % quand l'information pertinente est en position 5-15 sur 20 documents. En Naive RAG, l'ordre des chunks suit la similarité, pas la pertinence logique.
Source : Liu et al., Lost in the Middle, 2023
Frontières de chunks
Quand la réponse est répartie sur deux chunks adjacents, le retrieval n'en ramène souvent qu'un seul. Les benchmarks MTEB montrent un recall@5 qui chute de 0,72 à 0,58 dans ces cas. L'overlap atténue le problème sans le résoudre.
Source : MTEB Benchmarks, Muennighoff et al.
Gap lexical (pas de BM25)
La recherche vectorielle capture le sens, mais le Naive RAG n'utilise pas de recherche lexicale (BM25) en complément. Il manque les passages qui utilisent un vocabulaire différent de la question mais répondent exactement au besoin. L'Advanced RAG corrige cela avec la hybrid search.
Source : Recommandation standard, pipeline RAG 2024+
Aucun raisonnement multi-étapes
Sur le benchmark HotpotQA, l'accuracy d'un Naive RAG chute de 78 % (questions directes) à 34 % (questions multi-hop). Si la réponse nécessite de combiner des informations de plusieurs documents, le Naive RAG échoue systématiquement.
Source : HotpotQA Benchmark, Yang et al.
Pas de vérification
Le LLM génère sa réponse sans vérifier si les chunks récupérés sont pertinents ni si sa réponse est fidèle au contexte fourni. C'est la source principale des hallucinations : le modèle peut ignorer le contexte et répondre depuis ses propres connaissances.
Source : Self-RAG, Asai et al., 2023
Quand garder le Naive RAG, quand migrer
| Critère | Naive RAG suffit | Migrer vers Advanced+ |
|---|---|---|
| Taille du corpus | < 1 000 documents | > 1 000 documents |
| Type de questions | Directes, factuelles | Multi-hop, analytiques |
| Tolérance aux erreurs | Acceptable (interne, POC) | Critique (client, médical, juridique) |
| Budget mensuel | < 100 $/mois | > 100 $/mois |
| Équipe | 1 dev, pas de MLOps | Équipe data/ML dédiée |
Le Naive RAG est le bon choix quand le corpus est petit, les questions sont directes, et une hallucination occasionnelle n'a pas de conséquence grave. Pour un chatbot interne sur 200 documents de procédures, c'est suffisant et déployable en une journée.
Dès que le corpus dépasse 1 000 documents, que les questions deviennent complexes, ou que la fiabilité est critique, il faut passer à Advanced RAG (hybrid search + reranking) ou au-delà. La plupart des améliorations s'ajoutent au pipeline existant sans tout reconstruire.
Aller plus loin
Le Naive RAG est la fondation de toutes les architectures RAG. Le comprendre est indispensable avant d'explorer les variantes plus avancées - chaque amélioration (reranking, hybrid search, graph traversal, agents) corrige une limite spécifique documentée dans cet article.
Pour choisir l'architecture adaptée à votre cas, utilisez le simulateur interactif ou consultez la matrice de décision par besoin.