Architecture RAG : ingestion, récupération, génération et reranking

L'architecture RAG décrit la structure technique d'un système de Retrieval-Augmented Generation en deux phases clairement séparées. La première, l'ingestion (ou indexation), s'exécute hors ligne et transforme les documents sources en un index interrogeable. La seconde, la phase de requête (query time), s'exécute en ligne pour chaque requête : elle récupère les contenus pertinents, les reclasse et les transmet à un modèle de langage pour la génération. Si tu veux exploiter un RAG en production, tu dois comprendre et piloter ces deux flux séparément.

• Deux flux, pas un seul : l'ingestion (loading, chunking, embedding, upsert) tourne par lots ; le flux de requête (embedding, retrieval, filtrage, reranking, génération) s'exécute pour chaque requête.
• Le reranking est indispensable, pas facultatif : un cross-encoder placé après la recherche initiale réduit de façon mesurable le taux d'échec de la récupération (jusqu'à 67 % en combinaison avec le Contextual Retrieval, données de septembre 2024).
• Les métadonnées conditionnent la conformité : tenant_id, ACL et référence de la source dans chaque chunk constituent la base technique du multi-tenancy, du cloisonnement des données par client et de la possibilité d'effacer les données.

Phase 1 : ingestion / indexation (hors ligne)

Le flux d'ingestion est le travail préparatoire qui détermine d'avance la qualité et la latence de l'exploitation ultérieure. Il comprend quatre à cinq étapes :

1. Loading / connecteurs. Des sources comme SharePoint, S3, Confluence ou une base de données sont raccordées via des connecteurs. Dès cette étape, on enregistre pour chaque document des identifiants stables et des métadonnées (source, horodatage, client, droits d'accès).

2. Parsing. Les documents bruts, surtout les PDF et les contrats, sont convertis en texte structuré. Les parseurs sensibles à la mise en page préservent la structure des tableaux, des listes et des titres, ce qui évite ensuite des hallucinations. Parmi les outils disponibles : Docling (IBM, open source), Unstructured.io, LlamaParse ou Azure Document Intelligence.

3. Chunking. Le texte est découpé en unités récupérables. Le chunking naïf à taille fixe (par ex. 512 tokens, overlap de 50) est simple, mais coupe des phrases et des tableaux. Mieux vaut un chunking récursif/sémantique (découpe en cas de dérive de la similarité cosinus entre phrases) ou un chunking hiérarchique parent-enfant (petits chunks pour le retrieval, grands chunks parents comme contexte). Règle empirique : 200 à 800 tokens, 10 à 20 % d'overlap.

4. Embedding. Un modèle d'embedding convertit chaque chunk en vecteur. Pour les corpus en allemand, les modèles multilingues dominent : Cohere Embed v4, les modèles Voyage, Gemini Embedding 2 ou BGE-M3. Pour une exploitation souveraine, ce sont surtout les modèles open-weight comme BGE-M3 ou les Jina Embeddings qui s'y prêtent, on-premise ou chez un hébergeur européen. Jina AI appartient toutefois à Elastic depuis octobre 2025, et avant tout usage commercial, tu dois vérifier la licence de la version du modèle concernée. Mistral Embed provient de l'éditeur parisien Mistral AI. Aleph Alpha, basé à Heidelberg, fusionne avec l'éditeur canadien Cohere. Lors de la signature du contrat, en septembre 2026, l'autorisation des autorités n'avait pas encore été obtenue. Important : selon le tokenizer, l'allemand consomme environ 1,3 à 1,7 fois plus de tokens que l'anglais.

5. Indexation / upsert. Les vecteurs sont écrits avec leurs métadonnées dans une base de données vectorielle. L'algorithme d'indexation standard est presque partout HNSW (Malkov & Yashunin 2016), avec les paramètres M, ef_construction et ef_search, qui arbitrent entre recall et vitesse. En option, on construit en parallèle un index BM25 pour la recherche hybride et on place en tête de chaque chunk un en-tête de contexte généré par un LLM (Contextual Retrieval).

Phase 2 : traitement des requêtes (en ligne)

Le flux de requête s'exécute pour chaque question posée par un utilisateur. L'embedding de la requête, le retrieval, le filtrage et le reranking prennent ensemble, à titre indicatif, environ 100 à 800 millisecondes, selon la taille de l'index et le reranker. Un prétraitement optionnel par LLM, comme HyDE ou un query rewriter, ajoute un appel au modèle. La génération finale par le LLM prend généralement d'une à plusieurs secondes selon la longueur de la réponse. Les étapes en détail :

1. Prétraitement de la requête (optionnel). Un query rewriter, HyDE ou un décomposeur reformulent les questions complexes ou les décomposent. Dans les systèmes multi-tenant, c'est aussi à ce stade qu'interviennent l'AuthN/Z et la résolution du tenant.

2. Embedding de la requête. La question est convertie en vecteur avec le même modèle d'embedding que les chunks. En parallèle, une requête BM25 est générée.

3. Retrieval / recherche vectorielle. La base de données vectorielle renvoie les chunks les plus similaires (typiquement top_k = 50 à 100). En recherche hybride, la recherche dense et la recherche sparse tournent en parallèle et sont fusionnées par rank fusion (Reciprocal Rank Fusion).

4. Filtrage. Les filtres de métadonnées (tenant_id, ACL, date) restreignent les candidats. Cela touche aussi à la conformité : le guide d'orientation de la DSK sur les systèmes d'IA générative utilisant la méthode RAG (octobre 2025) cite le cloisonnement des données par client et un concept de droits et de rôles comme mesures garantissant la confidentialité et la limitation des finalités.

5. Reranking. Un cross-encoder (Cohere Rerank, BGE-Reranker, Jina Reranker) évalue conjointement la requête et le document et réduit les 50 à 100 candidats aux top_k = 5 à 10 les plus pertinents. Les cross-encoders sont plus précis, mais plus lents que les bi-encoders de la recherche initiale ; ils n'interviennent donc qu'après le recall, moins coûteux.

6. Assemblage du contexte & prompting. Les chunks retenus sont insérés avec leurs références de source dans un template de prompt. Les passages importants se placent en tête pour éviter le problème du lost in the middle.

7. Génération par le LLM. Le modèle de langage produit la réponse, idéalement avec du citation forcing et un garde-fou de fidélité (faithfulness guardrail) en aval, qui vérifie que la réponse est bien étayée par les sources.

Tableau : pipeline RAG par phase, tâche et outils

Le flux de données expliqué

Hors ligne, un document passe par le loader, le parser et le chunker, est vectorisé par le modèle d'embedding et atterrit, avec ses métadonnées, sous forme d'enregistrement dans la base de données vectorielle. Lorsqu'une question arrive en ligne, elle est convertie en embedding avec le même modèle et comparée via l'index HNSW à tous les vecteurs de chunks, ce qui produit une présélection. Les filtres de métadonnées écartent ce que l'utilisateur n'a pas le droit de voir. Le reranker condense la présélection en meilleurs résultats. Ceux-ci sont assemblés dans le prompt avec leurs sources, le LLM en tire la réponse, et un garde-fou vérifie la fidélité à la source. Point décisif : l'embedding d'ingestion et celui de requête doivent utiliser le même modèle, sinon les vecteurs ne sont pas comparables.

Exemple concret, chiffres à l'appui

Un bot de support pour un produit SaaS indexe 50 000 documents. Avec un chunking sémantique d'environ 500 tokens par chunk, on obtient environ 300 000 vecteurs. Selon Anthropic, l'indexation avec Contextual Retrieval coûte environ 1,02 dollar américain pour 1 million de tokens de documents avec prompt caching (données de septembre 2024). En production, chaque requête récupère top_k = 50 candidats ; le reranker de Cohere les réduit à top_k = 5.

L'évaluation d'Anthropic montre l'effet de chaque brique sur le taux d'échec de récupération dans le top 20 : sans optimisation, il s'élevait à 5,7 %. Avec les seuls Contextual Embeddings, il est tombé à 3,7 % (soit 35 % de moins), avec le Contextual Retrieval complet (embeddings plus Contextual BM25) à 2,9 % (soit 49 % de moins) et avec un reranking supplémentaire à 1,9 % (soit 67 % de moins). En termes de latence, une requête de retrieval hybride avec reranking se situe dans une fourchette d'environ 100 à 800 millisecondes.

Pseudocode du flux de requête :

```
q_vec = embed(query) # même modèle qu'à l'ingestion
dense = vdb.search(q_vec, top_k=50, filter={tenant_id})
sparse = bm25.search(query, top_k=50, filter={tenant_id})
cands = rrf_fuse(dense, sparse) # recherche hybride
top5 = rerank(query, cands)[:5] # Cross-Encoder
prompt = template(query, top5, cite=True)
answer = llm.generate(prompt)
assert faithfulness(answer, top5) > 0.8 # garde-fou
```

Erreurs d'architecture fréquentes

• Un chunking naïf à taille fixe ignore les limites des phrases et des tableaux, ce qui entraîne des contenus manquants et des hallucinations.
• Un modèle d'embedding inadapté à la langue (embeddings anglais pour un corpus allemand) ruine le recall sur les requêtes en allemand.
• Pas de reranking : les résultats sont sémantiquement proches, mais pas pertinents.
• Lost-in-the-chunks : sans en-tête de contexte, un chunk comme « Il a augmenté de 12 % » ne sait pas de quoi il parle.
• Sémantique pure sans BM25 : les codes et identifiants exacts restent introuvables.
• Pas de filtres de métadonnées : aucune protection multi-tenant ni ACL ; un chunk du client A peut être récupéré pour le client B.
• Un top_k surdimensionné envoyé au LLM : lost in the middle et coûts plus élevés.
• Ni évaluation ni citation des sources : régression silencieuse de la qualité et risque de non-conformité.
• Dérive des embeddings lors d'un changement de modèle : sans chaîne de version ni réindexation complète, anciens et nouveaux vecteurs sont incompatibles.

Pour les agences et le B2B

Une architecture RAG propre est un pipeline avec ingestion, retrieval hybride, reranking, évaluation et politique d'effacement. Pour les agences, la valeur réside dans la stratégie de données, le chunking et le cloisonnement des données par client. Pour les décideurs B2B en Europe, la souveraineté compte aussi : Qdrant, Weaviate, Haystack et un hébergement dans l'UE constituent une bonne base pour une exploitation conforme au RGPD. Blck Alpaca conçoit et exploite ce type de pipelines de bout en bout, y compris une évaluation avec RAGAS et un pipeline d'effacement conforme au guide d'orientation de la DSK. Contacte-nous si tu veux transformer un pilote IA en système de connaissances opérationnel et vérifiable.