Trois architectures cohabitent en 2026 — bien choisir économise 10×
Trois architectures cohabitent en 2026 selon ton volume. Pour < 100K tokens → LLM Wiki Karpathy (95 % moins coûteux). Pour 100K-10M tokens → RAG hybride (dense + sparse + reranking). Au-delà → RAG hybride avec sharding et caching avancé. Le mauvais choix coûte 10x plus.
Le vector DB n'est PAS la décision principale. Beaucoup de PME se trompent en passant 80 % du temps sur le choix Pinecone vs Qdrant. Le bon embedding model et le reranking pèsent 5-10x plus sur la qualité finale.
Une pipeline de retrieval bien faite réduit les hallucinations de 70 à 90 %. Les chiffres de Techment 2026 sont reproductibles. Mais cela exige une discipline : chunking adapté, retrieval hybride, reranking obligatoire, eval pipeline pour mesurer.
Le LLM Wiki Karpathy (avril 2026) change la donne pour les petits corpus. Pour une base < 100K tokens stable (manuel produit, FAQ technique, documentation interne d'un domaine), une simple base markdown maintenue par un LLM peut surpasser un RAG vectoriel — et coûter 95 % moins en tokens.
Signal de rupture potentielle 3-6 mois — la trajectoire bascule de discussion à infrastructure. Quatre sources convergentes en mai-juin 2026 (SubQ, Karpathy LLM Wiki, Hermes Agent, agentmemory avec benchmarks publiés 95,2 % r@5 + coût token ÷ 100+) suggèrent que les RAG classiques pourraient être à risque de rupture sur certains cas d'usage. Voir section 2bis pour la grille de décision par profil de projet.
Cette page est utile si…
- Tu envisages de déployer un RAG en production sur ton patrimoine documentaire interne
- Tu veux choisir entre LLM Wiki / RAG dense / RAG hybride
- Tu cherches un référentiel pour benchmarker les vector DB sans te perdre dans les détails techniques
- Tu as un budget mensuel à arbitrer pour ta pipeline RAG
RAG en 2026 : pourquoi le débat a évolué
1.1 Ce qui a changé en 2025-2026
Trois ruptures structurent le marché aujourd'hui :
- Le RAG dense pur plafonne sur les corpus métier réels. Quand le corpus contient des acronymes, des codes produits, des références techniques (numéros ATC, codes SKU, références ISO), l'embedding sémantique ne suffit plus. D'où la bascule massive vers le retrieval hybride (dense + sparse BM25 + reranking).
- Le LLM Wiki d'Andrej Karpathy (gist GitHub avril 2026, 17 M de vues, 5 000 stars en quelques jours) propose une alternative radicale pour les petits corpus : pas de vector DB, pas de chunking, juste une base markdown maintenue par un LLM. 95 % moins coûteux en tokens que le RAG vectoriel pour les bases < 100K tokens stables.
- Les vector DB se sont commoditisés. Pinecone, Qdrant, Weaviate, Chroma, MongoDB Atlas Vector Search : 5+ acteurs solides, prix qui baissent, performances équivalentes sur la majorité des cas. Le débat n'est plus « lequel choisir » mais « comment l'utiliser correctement ».
1.2 La règle de décision en 30 secondes
Trois questions pour choisir l'architecture :
- Volume du corpus : < 100K tokens ? 100K-10M ? > 10M ?
- Fréquence de mise à jour : statique ? hebdomadaire ? continue ?
- Nature des données : texte narratif ? techniques avec acronymes/codes ? mixte ?
Le tableau de décision en section 4 te donne la réponse.
Le LLM Wiki Karpathy — alternative crédible pour les petits corpus
2.1 Le pattern en deux phrases
Au lieu d'embedder ton corpus dans un vector DB et de retrieve des chunks à chaque requête, tu maintiens une base markdown structurée par un LLM. Quand tu ajoutes un document, le LLM met à jour les pages markdown affectées (synthèses, entités, contradictions). Quand un utilisateur pose une question, le LLM consulte directement les pages markdown pertinentes.
2.2 Quand c'est pertinent (les cas types)
- Manuel produit stable (ex : documentation technique d'une machine industrielle) : 30K-80K tokens, mises à jour trimestrielles
- FAQ métier : questions/réponses standardisées, < 50K tokens
- Procédures internes RH : règlement intérieur, processus de recrutement, etc.
- Documentation projet : un cahier des charges, un manuel d'intégration
2.3 Quand ce n'est PAS pertinent
- Volume > 200K tokens : le contexte LLM devient trop coûteux et lent
- Mises à jour temps réel : pas adapté
- Corpus très hétérogène : la maintenance markdown devient une charge
2.4 Coût-bénéfice mesuré
Pour une PME avec un corpus de 50K tokens :
- RAG vectoriel : ~150-300 €/mois (vector DB managed + embeddings + LLM)
- LLM Wiki : ~10-50 €/mois (juste le LLM, pas de vector DB)
→ Économie potentielle de 90 % sur les petits corpus.
2.5 Le signal de rupture — durée de vie des architectures RAG actuelles
⚠️ Signal fort 2026 à intégrer dans tout cadrage de projet RAG en production : les architectures RAG classiques pourraient avoir une durée de vie de 3-6 mois sur certains cas d'usage, si les ruptures observées (long context 10M+ natif + LLM Wiki + persistent memory + agentmemory) se confirment. La trajectoire bascule désormais de « discussion » à « infrastructure ».
Quatre sources convergentes en mai-juin 2026 :
- @0xCVYH (SubQ) — long context 10M+ tokens en production, réduction coût attention ×1000
- @Suryanshti777 — gist Karpathy LLM Wiki à 5 000+ stars, écosystème de patterns dérivés
- @JE4NVRG (Hermes Agent / Jean Vargas) — persistent memory > RAG stateless pour agents scalables
- @ghumare64 (agentmemory) — 13 200+ stars GitHub, première implémentation mutualisable cross-agents (Claude Code, Hermes Agent, OpenClaw, Codex CLI, Cursor, Gemini CLI) avec benchmarks publiés
Signal 4 — agentmemory : la persistent memory devient infrastructure mutualisable
Côté production, agentmemory est la première implémentation mutualisable cross-agents d'une couche de persistent memory :
- Serveur local SQLite + FAISS (pas de SaaS — souveraineté / RGPD respectés)
- Hooks officiels pour Claude Code, Hermes Agent, OpenClaw, Codex CLI, Cursor, Gemini CLI
- Benchmarks publiés : 95,2 % r@5 vs 86,2 % BM25 fallback + coût token ÷ 100+
- Pattern de déploiement local-first, compatible avec les architectures A3/A4 (souveraineté contrôlée / forte)
Implication pour l'équipe qui industrialise un projet RAG en 2026 : avant de surinvestir dans une infrastructure RAG classique, évaluer si un pattern hybride RAG-light + persistent memory ne suffit pas. La barre de qualité (95,2 % r@5) et le ratio coût (÷ 100+) rendent l'arbitrage non trivial. Voir la fiche outil détaillée agentmemory.
Implication opérationnelle pour ton choix d'architecture RAG
| Si ton projet est… | Recommandation 2026 |
|---|---|
| POC ou pilote court (< 6 mois) | Architecture RAG simple, ne pas optimiser à outrance. La stack restera valide sur l'horizon. |
| Production sur corpus < 1 M tokens | Évaluer une architecture hybride RAG-light + long context pour ne pas être prisonnier de la rupture annoncée. |
| Production sur corpus > 10 M tokens | RAG hybride classique reste pertinent — le long context natif ne couvrira pas ces volumes à court terme. |
| Agent en production avec mémoire conversationnelle | Privilégier une couche persistent memory mutualisable (cf. agentmemory) plutôt que RAG hybride. Architecture local-first (SQLite + FAISS) compatible souveraineté A3/A4. Benchmark de référence : 95,2 % r@5 + coût token ÷ 100+. |
| Stack RAG déjà déployée en prod | Documenter la dette technique RAG ; tester en parallèle une alternative sur un cas non critique ; ne pas paniquer (le RAG classique reste pertinent pour citation et sourcing précis). |
Ce qui ne change pas
Le RAG hybride reste pertinent pour :
- Les corpus volumineux (> 10 M tokens) où le long context natif ne suffira pas
- Les besoins de sourcing précis (citation source, traçabilité du chunk d'origine)
- Les contextes réglementés (RGPD, AI Act) où la traçabilité de l'information injectée dans le contexte est exigée
- Les architectures multi-tenant où chaque tenant doit avoir un isolement strict des données
Le RAG hybride devient à risque de rupture pour :
- Les agents avec mémoire conversationnelle simple
- Les corpus petits-moyens (< 1 M tokens) où le long context natif suffira
- Les use cases « ingestion + synthèse + évolution » où le LLM Wiki est plus efficace
Le RAG hybride — le standard 2026 pour les corpus moyens et grands
3.1 Anatomie d'une pipeline RAG hybride
Sept étapes à connaître (ton prestataire doit te les réciter sans hésiter) :
- Chunking : découpage du corpus en passages de 256-1024 tokens avec overlap de 100 tokens
- Embedding : conversion de chaque chunk en vecteur (OpenAI text-embedding-3-small, Mistral embed, Cohere embed)
- Indexation : stockage des vecteurs + métadonnées dans le vector DB
- Query rewriting : reformulation de la requête utilisateur pour optimiser la recherche
- Retrieval hybride : recherche dense (vector similarity) + recherche sparse (BM25) en parallèle
- Reranking : un cross-encoder (Cohere Rerank, BGE-reranker) re-classe les top-K résultats par pertinence réelle
- Generation : le LLM consulte les chunks pertinents et génère la réponse avec citations
3.2 Les choix techniques qui pèsent vraiment sur la qualité
Par ordre d'impact sur la qualité finale :
- Embedding model : 30-40 % d'impact sur la pertinence
- Reranking : +10-30 % de précision (sauter cette étape sacrifie 30 % de précision)
- Chunking : sweet spot Q&A factuel = 256-512 tokens, tâches analytiques = 512-1024 tokens
- Choix vector DB : 5-10 % d'impact (souvent surestimé en PME)
3.3 Eval pipeline obligatoire
Sans eval pipeline, tu ne sais pas si une modif améliore ou dégrade. Une eval pipeline = un dataset golden de 50-200 questions/réponses avec scoring automatique. Mise en place : 1-2 semaines, mais c'est ce qui sépare le RAG amateur du RAG production.
Tableau de décision RAG (à utiliser avec ton prestataire)
| Volume corpus | Nature données | Fréquence MAJ | Architecture recommandée | Coût mensuel typique |
|---|---|---|---|---|
| < 50K tokens | Texte narratif stable | Trimestrielle | LLM Wiki Karpathy | 10-50 € |
| 50K-100K tokens | Mixte | Mensuelle | LLM Wiki ou RAG dense Chroma | 50-150 € |
| 100K-1M tokens | Texte avec acronymes/codes | Hebdomadaire | RAG hybride Qdrant | 150-500 € |
| 1M-10M tokens | Mixte | Quotidienne | RAG hybride Pinecone/Qdrant + cache | 500-2000 € |
| > 10M tokens | Hétérogène | Continue | RAG hybride sharded + LLM Wiki layer | 2000-10K € |
Important : ce tableau est indicatif. Le vrai choix dépend aussi de ta latence cible, de ton SLA, et de ta contrainte de souveraineté (cf. page Architectures).
Choix vector DB : panorama 2026
5.1 Les 5 acteurs solides
| Vector DB | Profil | Quand le choisir |
|---|---|---|
| Pinecone | Managed serverless, premium | Enterprise sans équipe ops, pricing OK |
| Qdrant | Open-source, self-host possible, performant | Contrôle des coûts, souveraineté EU |
| Weaviate | Hybrid search natif, multi-tenant | Multi-clients, hybrid en standard |
| Chroma | Simple, local, gratuit | Prototypage, petits volumes |
| MongoDB Atlas Vector Search | Si déjà sur Mongo | Pas de nouvelle brique infra |
5.2 La question piège : « Quel vector DB choisir ? »
Mauvaise question. La bonne question est : « Quel embedding model + quelle pipeline de reranking ? ». Le vector DB n'est qu'un moteur de stockage. La qualité vient de l'embedding et du reranking.
Si tu n'as pas encore d'avis : Qdrant self-hosted pour démarrer (gratuit, contrôle, EU). Migration vers Pinecone managed si tu atteins les limites ops.
Les 5 écueils typiques RAG en production
À éviter à tout prix.
- Mauvais chunking = mauvais résultats, indépendamment du modèle. Sweet spot : 256-512 tokens Q&A, 512-1024 tokens analytique. Trop petit → perte de contexte. Trop grand → bruit dans le retrieval.
- Croire que le choix vector DB est central : c'est l'embedding model qui pèse le plus sur la qualité.
- Oublier le reranking : -30 % de précision en moyenne.
- RAG dense pur sur corpus métier avec acronymes/codes : rate les références. Hybride obligatoire.
- Construire un RAG sans eval pipeline : impossible de mesurer si une modif améliore ou dégrade.
Le cycle d'itération continue — Stitch, Evaluate, Iterate
Constat largement documenté en 2026 : rien sur les leaderboards ne prédit la performance d'un RAG sur tes données spécifiques. Les benchmarks publics (MTEB, BEIR, etc.) testent sur des datasets génériques. Sur ton corpus métier, l'écart entre la performance benchmark et la performance réelle peut être significatif.
Implication pratique : tu ne peux pas choisir ton stack RAG sur la base des leaderboards. Tu dois itérer sur tes données réelles.
Le cycle Stitch → Evaluate → Iterate
- Stitch : assembler une première version du pipeline (chunking + embeddings + retrieval + reranking + génération) avec des choix par défaut raisonnables. Ne pas chercher l'optimum dès le départ.
- Evaluate : évaluer la performance sur un eval set réel (50-200 cas représentatifs de tes données et requêtes), avec un LLM Judge aligné sur le feedback humain (calibrer le LLM Judge sur 10-20 cas annotés humain).
- Iterate : modifier un seul composant à la fois (changer d'embedding, ajuster le chunking, ajouter un reranker, etc.), réévaluer, comparer.
RetEx documenté — embeddings open-source qui battent OpenAI
Cas documenté mai 2026 : sur un dataset d'enchères, un embedding open-source classé #130 sur le leaderboard MTEB a battu les embeddings d'OpenAI (#1 du leaderboard) :
- +11 % de qualité (mesurée sur l'eval set spécifique au dataset)
- 240× plus rapide (latence par requête)
- Gratuit (vs coût API OpenAI)
Leçon : les leaderboards ne prédisent pas la performance sur tes données. L'eval set sur ton corpus est le seul juge fiable.
Implication pour la PME
- Construire son eval set est l'investissement le plus rentable d'un projet RAG en production. Coût : 1-3 jours de travail manuel pour annoter 50-200 cas. ROI : permanent (tout choix futur s'évalue dessus).
- Itérer cheapest-first : changer le chunking ou ajouter un reranker coûte moins cher que changer le modèle de génération. Le réflexe « plus gros modèle » est souvent le plus coûteux et le moins efficace.
- LLM Judge aligné : utiliser un LLM (Claude, GPT) comme juge automatisé pour scorer les sorties contre les attendus, mais calibrer ce juge sur 10-20 cas annotés humain pour vérifier qu'il reproduit ton jugement.
Le détail du dataset golden et du LLM Judge calibré est traité dans la fiche Évaluation continue et qualité IA. Pour le pattern LLM Wiki comme alternative au RAG classique, voir le module Knowledge base RAG.
Plan d'action 60 jours pour un RAG production-ready
Jours 1-15 — Cadrage
- Inventaire du corpus (volume, nature, fréquence MAJ)
- Décision architecture via tableau section 4
- Définition KPI (précision sur dataset golden, latence cible, coût/requête max)
Jours 16-30 — Pilote
- Mise en œuvre de la pipeline (chunking + embedding + retrieval + reranking + generation)
- Construction du dataset golden (50-100 questions/réponses)
- Mesure des KPI sur le golden
Jours 31-45 — Optimisation
- Itération sur chunking, embedding, reranking
- Mesure systématique sur le golden après chaque modification
Jours 46-60 — Mise en production
- Déploiement sur 5-15 utilisateurs cibles
- Monitoring (latence, coût, satisfaction utilisateur)
- Décision Go/No-Go production large
Pour aller plus loin
📚 Bibliographie transverse : les ressources de fond (études, communautés, newsletters) sont centralisées sur la page Ressources → Bibliographie. Cette section ne liste que les ressources spécifiques à ce cadrage RAG.
📰 Articles de fond
- VentureBeat — Hybrid retrieval intent tripled (mars 2026)
- MindStudio — LLM Wiki vs RAG comparison
- Techment — RAG in 2026
- @0xCVYH (SubQ) — Long context 10M+ vs RAG playbook
- @Suryanshti777 — Obsolescence progressive du RAG classique
- @JE4NVRG (Hermes Agent) — Persistent memory > RAG stateless
- @ghumare64 (Rohit Ghumare) — agentmemory : persistent memory layer