Notre stack RAG end-to-end en 2026 : schéma complet, composants, et coût mensuel

Les articles sur le RAG montrent généralement un schéma en trois boîtes : "ingestion → retrieval → génération". En production, c'est entre 8 et 12 composants avec des décisions non triviales à chaque étape. Ce texte documente notre stack actuelle, les alternatives qu'on a testées, et ce que ça coûte sur un projet B2B à volume modéré.

Le schéma complet

Documents bruts
    │
    ▼
[1] Ingestion & parsing
    │  (Docling / Unstructured)
    ▼
[2] Chunking sémantique
    │  (taille adaptative par type de doc)
    ▼
[3] Enrichissement métadonnées
    │  (source, date, catégorie, section)
    ▼
[4] Embedding
    │  (text-embedding-3-large / multilingual-e5-large)
    ▼
[5] Vector store
    │  (Qdrant)
    ▼
    ┌──────────────────────────────────┐
    │         QUERY PIPELINE           │
    └──────────────────────────────────┘
    │
[6] Query analysis & rewriting
    │  (expansion, décomposition)
    ▼
[7] Retrieval hybride
    │  (dense + sparse BM25)
    ▼
[8] Reranking
    │  (Cohere rerank / cross-encoder)
    ▼
[9] Context assembly
    │  (sélection, déduplication, formatage)
    ▼
[10] Génération LLM
    │  (GPT-4o / Claude 3.5 Sonnet)
    ▼
[11] Réponse avec citations
    ▼
[12] Observabilité (Langfuse)

Composant par composant

[1] Ingestion et parsing

Le parsing de documents est sous-estimé. Un PDF natif, un PDF scanné, un Word, et un HTML nécessitent des traitements différents. On utilise Docling (open-source, IBM) pour les documents structurés, il gère les tableaux, les listes, les headers avec une fidélité que PyMuPDF ou pdfminer ne donnent pas.

Pour les documents scannés ou les cas complexes, on passe par Unstructured avec une API externe. Le coût est de l'ordre de 0,01 $ par page pour les documents complexes, sur des corpus de quelques milliers de pages, c'est négligeable par rapport au temps de développement d'un parser maison.

Ce qu'on a abandonné : les parsers maison basés sur des regex. Maintenabilité trop faible face à la diversité des formats réels.

[2] Chunking sémantique

On ne chunke pas à taille fixe. On utilise une approche hybride :

from langchain.text_splitter import RecursiveCharacterTextSplitter

def chunk_by_document_type(text: str, doc_type: str) -> list[str]:
    config = {
        "technical": {"chunk_size": 600, "chunk_overlap": 100},
        "legal": {"chunk_size": 800, "chunk_overlap": 150},
        "narrative": {"chunk_size": 400, "chunk_overlap": 80},
        "structured": {"chunk_size": 300, "chunk_overlap": 50},
    }

    params = config.get(doc_type, {"chunk_size": 500, "chunk_overlap": 100})

    splitter = RecursiveCharacterTextSplitter(
        separators=["\n\n", "\n", ". ", " "],
        **params
    )
    return splitter.split_text(text)

La classification du type de document se fait avec un appel LLM léger sur les 500 premiers tokens. Coût : ~0,001 $ par document.

[3] Enrichissement métadonnées

Chaque chunk reçoit des métadonnées filtrables : source, date de création, date de dernière modification, catégorie, section parente, niveau de confidentialité. Ces métadonnées permettent le filtrage au moment du retrieval, indispensable sur des corpus multi-sources avec des droits différenciés.

[4] Embedding

On utilise text-embedding-3-large d'OpenAI (3072 dimensions) pour les projets en français ou multilingues. Sur des projets 100 % anglais avec un budget contraint, text-embedding-3-small (1536 dimensions) donne 85-90 % des résultats pour 5× moins cher.

Alternative open-source testée : multilingual-e5-large de Microsoft, déployé en self-hosted. Sur nos benchmarks internes (corpus de docs techniques français), il donne des résultats légèrement inférieurs à text-embedding-3-large mais comparables à text-embedding-3-small. Coût d'hébergement : une instance dédiée à ~150 $/mois.

[5] Vector store : Qdrant

On a évalué Pinecone, Weaviate, pgvector, et Qdrant. Notre choix actuel est Qdrant pour plusieurs raisons :

• Support natif du filtrage sur métadonnées avec des index payload efficaces
• Support hybride dense + sparse natif depuis la version 1.7
• Self-hosting simple (Docker) ou cloud managé
• Performance stable jusqu'à ~10 M de vecteurs sur une instance standard

pgvector est une alternative sérieuse si l'équipe veut rester dans l'écosystème PostgreSQL. On le recommande pour des projets avec moins de 500 k vecteurs, au-delà, les performances de Qdrant sont significativement meilleures.

[6] Query rewriting

Une requête utilisateur courte donne un mauvais retrieval. On réécrit systématiquement la query avant le retrieval :

QUERY_REWRITE_PROMPT = """
Tu es un expert en recherche documentaire.
Réécris la question suivante pour maximiser la pertinence du retrieval dans une base documentaire technique.

Question originale : {query}

Produis :
1. La question reformulée (plus précise, vocabulaire du domaine)
2. 2-3 questions alternatives qui couvrent des angles différents

Format JSON : {{"main_query": "...", "alternatives": ["...", "..."]}}
"""

On envoie les 3-4 queries résultantes en parallèle et on fusionne les résultats (Reciprocal Rank Fusion).

[7] Retrieval hybride

Le retrieval dense seul rate les correspondances exactes sur des termes techniques, des noms propres, des références numériques. Le BM25 les capture. Le retrieval hybride combine les deux.

Qdrant supporte nativement le mode hybride depuis 1.7. On configure le ratio dense/sparse empiriquement selon le corpus (typiquement 0.7/0.3 en faveur du dense sur des corpus narratifs, 0.5/0.5 sur des corpus techniques avec beaucoup de jargon).

[8] Reranking

Le retrieval remonte 20-30 candidats. Le reranking les classe avec un modèle cross-encoder, plus précis que la similarité cosinus car il analyse la paire (query, chunk) ensemble. On conserve les top 5 à 8 après reranking.

On utilise le modèle Cohere rerank v3 via API. Coût : 0,002 $ pour 1000 paires rerankées. Sur un volume de 100 k requêtes/mois avec 25 candidats en moyenne, ça fait ~5 $ par mois.

Alternative testée : des cross-encoders open-source (ms-marco-MiniLM) en self-hosted. Performance légèrement inférieure sur le français, mais coût marginal après le serveur.

[9-10] Context assembly et génération

Les chunks rerankés sont assemblés dans un contexte structuré avec séparateurs clairs. On ajoute les métadonnées source pour permettre les citations. La génération se fait sur GPT-4o ou Claude 3.5 Sonnet selon le projet, les deux donnent des résultats comparables sur le RAG.

On épingle toujours la version du modèle (gpt-4o-2024-11-20, pas gpt-4o).

Le coût mensuel sur un volume réel

Hypothèses : produit B2B, 5 000 utilisateurs actifs, 20 requêtes/utilisateur/mois = 100 000 requêtes/mois, corpus de 50 000 pages.

Ce budget monte linéairement avec le volume de requêtes. Le poste dominant est la génération LLM, sur des volumes importants, le passage à un modèle moins coûteux (Claude Haiku, gpt-4o-mini) sur les requêtes simples peut diviser ce poste par 5 à 10.

Ce qu'on changerait si on recommençait

On aurait investi plus tôt dans la qualité du parsing et des métadonnées. C'est invisible dans les démos, mais en production, un mauvais parsing génère des chunks non pertinents que ni le reranking ni la génération ne peuvent corriger. La qualité de l'index détermine le plafond du système.

On aurait aussi construit le jeu d'évaluation en parallèle de l'ingestion, pas après. Évaluer un RAG sans vérité terrain, c'est naviguer à vue.

La question ouverte : à quel moment le coût du retrieval hybride avec reranking est-il justifié par rapport à un retrieval dense simple ? Sur des corpus homogènes et bien structurés, on n'a pas toujours mesuré un gain significatif. Le retrieval hybride brille sur des corpus hétérogènes avec du jargon de niche, ce qui est le cas de la plupart des projets B2B réels.