Le RAG naïf de 2023 (chunk, embed, top-k cosine) plafonne sur les vrais corpus d'entreprise. En 2026, un RAG en production combine hybrid search (BM25 + dense + ColBERT), reranking cross-encoder, et des patterns avancés : GraphRAG, Agentic RAG, Contextual Retrieval, late chunking, multi-hop. C'est ce que nous concevons.
Le RAG « chunk + embed + top-k » suffit pour une démo. Sur un vrai corpus métier (centaines de milliers de docs, vocabulaire spécialisé, requêtes ambiguës), il s'effondre. Quatre échecs récurrents.
Les embeddings denses généralistes manquent les acronymes métiers, les numéros de référence, les codes produit. Le BM25 voit les mots : il faut les deux.
Un paragraphe sorti de son chapitre perd la moitié de son sens. Le retriever ne sait pas que « le client » réfère au client mentionné 10 pages avant.
« Quelle est l'évolution du chiffre d'affaires de notre concurrent X entre Q1 et Q3 ? » nécessite plusieurs recherches successives. Un top-k single-shot ne sait pas faire.
Le RAG marche « globalement »… mais combien d'hallucinations passent en silence ? Sans RAGAS + llm-as-judge en CI, vous codez en aveugle.
La fondation d'un RAG sérieux en 2026. Trois étages : retrieval lexical (BM25), retrieval dense (embeddings), fusion (RRF ou pondération), puis reranking cross-encoder sur les top-50 pour produire le top-5 envoyé au LLM.
Un seul des deux retrievers donne ~75 % de qualité. Les deux fusionnés + reranking cross-encoder atteignent 90-95 % sur la majorité des corpus. Le coût supplémentaire est marginal.
Au-delà de l'hybrid+rerank, cinq patterns avancés transforment un RAG honnête en RAG redoutable. Chacun adresse une famille d'échecs distincte.
Avant l'indexation, chaque chunk est réécrit avec son contexte ambient (chapitre, section, document). Anthropic a montré -49 % d'échecs de retrieval. Coût : un appel LLM par chunk à l'indexation (one-shot, avec prompt caching).
L'indexation construit un graphe de connaissance (entités + relations) extrait du corpus. Les questions globales (« quels sont les principaux thèmes ? ») interrogent le graphe + summaries de communautés Leiden. Les questions locales (« qui a dit X ? ») restent en RAG classique.
Le retrieval n'est plus une étape monolithique mais un outil mobilisé par un agent LangGraph. L'agent peut interroger plusieurs fois le RAG, raffiner sa requête, croiser plusieurs sources, demander des clarifications. Le pattern le plus puissant en 2026.
Au lieu d'embedder chaque chunk séparément, on embedde le document entier en une passe, puis on extrait les embeddings de chaque chunk à partir des token embeddings finaux. Le contexte global imprègne chaque vecteur de chunk. Compatible avec les modèles à long contexte (Jina v3, voyage-3, BGE-M3).
Un nœud LangGraph décompose la question en sous-questions atomiques, exécute un RAG sur chacune, puis synthétise. Indispensable pour les questions analytiques : « Compare la stratégie de X et Y depuis 2024 », « Quelles évolutions réglementaires ont affecté Z entre Q1 et Q3 ? »
Pas de winner universel. Notre choix par défaut est Qdrant pour la majorité des cas, pgvector quand l'écosystème Postgres pèse, Weaviate pour les besoins hybrid+graph natifs.
| Vector DB | Hybrid natif | Filtres metadata | Scale | Souveraineté | Notre usage |
|---|---|---|---|---|---|
| Qdrant | excellent | payload riche | cluster | self-host EU | Défaut |
| Weaviate | BM25 + dense | GraphQL | cluster | self-host | Hybrid + classes liées |
| pgvector | via SQL | SQL natif | vertical | Postgres | Eco Postgres existant |
| LanceDB | en montée | SQL-like | vertical | embarquable | Apps embarquées |
| Milvus | hybrid | scalar fields | milliards | self-host | Très gros volumes |
| OpenSearch | BM25 natif | Lucene | cluster | self-host | Quand Elastic existe |
| Pinecone | hybrid serverless | filters | serverless | US SaaS | Rarement (souveraineté) |
| Chroma | limité | simple | dev | local | POC, jamais en prod |
Le choix d'embeddings change le top-5 de retrieval. Sur les corpus français/multilingues d'entreprise, nos benchmarks 2026 placent :
Notre défaut pour RAG souverain on-premise. Performance multilingue état de l'art, déployable via vLLM. Compatibilité parfaite avec les modèles génératifs Mistral.
Meilleur sur MTEB en 2026. 1024 dims, support binary embeddings, matryoshka. Notre choix quand on a accès aux API US.
Open-weight performants. BGE-M3 supporte dense + sparse + ColBERT en un modèle. Jina v3 excelle en long-context (8K).
Cas spécifiques : code, sciences, légal. Souvent vainqueurs sur leur niche.
Toujours benchmarker 3-4 modèles sur votre jeu d'évaluation avant de figer. Le « meilleur » embeddings dépend du domaine et de la langue. Différence de 15-25 % en Recall@5 fréquente entre modèles génériques et modèles fine-tunés sur votre corpus.
Pas de RAG en production sans jeu d'évaluation. Notre boîte à outils : RAGAS + DeepEval + llm-as-judge, orchestré dans MLflow, déclenché en CI à chaque PR.
Les bons documents sont-ils dans le top-k ? Mesurés contre un ground truth de questions / docs pertinents annotés en cadrage.
La réponse est-elle ancrée dans les docs (faithfulness) ? Répond-elle réellement à la question (relevancy) ? llm-as-judge Opus.
Chaque affirmation a-t-elle une citation traçable ? Detection des inventions via comparison embeddings entre réponse et contexte.
P50/P95 latence, €/requête, drift sur les questions production vs eval. Tracé dans MLflow, alertes Langfuse / Arize.
Chaque PR sur le RAG déclenche un eval RAGAS sur 200-500 questions de référence. Si Faithfulness chute de plus de 2 points ou Context Recall de plus de 3 points, la PR est bloquée. Régression invisible = impossible.
Audit retrieval, migration vers hybrid + rerank, intégration des patterns état de l'art 2026, mise en place RAGAS en CI. Première analyse de faisabilité offerte.