Les systèmes RAG en IA expliqués

Qu'est-ce que le RAG ? Une définition claire

La génération augmentée par récupération (Retrieval-Augmented Generation, RAG) désigne une méthode dans laquelle un grand modèle de langage (Large Language Model, LLM), avant de générer une réponse, va chercher de manière ciblée des contenus de connaissance externes (retrieval) et les intègre au prompt (augmentation) afin d'appuyer la génération sur des sources vérifiables. La définition originale est due à Lewis et al. (Facebook AI Research, NeurIPS 2020) et décrit le RAG comme la combinaison d'une mémoire paramétrique (le modèle de langage entraîné) et d'une mémoire non paramétrique (un index externe interrogeable).

Au-delà des différentes définitions canoniques, on peut dégager un socle minimal commun. Un système RAG comprend trois éléments obligatoires : (i) une base de connaissances externe avec un index, (ii) un retriever qui trouve les passages pertinents et (iii) un LLM générateur dont le prompt est enrichi des contenus trouvés. L'intérêt central : le RAG fournit des réponses sourcées et traçables, réduit les hallucinations de façon mesurable et maintient les connaissances à jour sans qu'il soit nécessaire de réentraîner le modèle.

Pourquoi le RAG ? Le problème qu'il résout

Les LLM ont trois faiblesses structurelles : ils hallucinent, leurs connaissances sont figées à la date de l'entraînement et leurs réponses ne sont pas traçables. Le RAG répond aux trois. Au lieu d'entraîner le modèle sur de nouvelles données par un fine-tuning coûteux, on charge les connaissances pertinentes à l'exécution, pour chaque requête. Les mises à jour deviennent aussi simples qu'une réindexation ; les références aux sources (citations) sont possibles nativement via les ID de chunks ; et la réponse reste liée à des éléments vérifiables.

Ce sont précisément ces propriétés qui font du RAG le pattern standard de facto pour l'IA d'entreprise en Europe, où la traçabilité, l'actualité des informations et la maîtrise des données ne sont pas optionnelles, mais exigées par la réglementation comme par la confiance.

Le pipeline RAG : chemin d'indexation et chemin de requête

Un système RAG en production comporte deux chemins. Le chemin d'indexation (offline/batch) traite les sources de connaissances : des connecteurs chargent les documents depuis SharePoint, S3, Confluence ou des bases de données ; un parser (par exemple Docling) extrait le texte, les tableaux et les structures en respectant la mise en page ; un chunker découpe les contenus ; un modèle d'embedding génère les vecteurs et un upsert les écrit, avec leurs métadonnées (ID de tenant, ACL, source, horodatage), dans la base de données vectorielle ; le tout éventuellement accompagné d'un index BM25 parallèle.

Le chemin de requête (online) commence par la requête de l'utilisateur, éventuellement reformulée (query rewriting, HyDE). Vient ensuite une recherche hybride (typiquement top_k = 50–100), suivie d'un reranker qui condense le résultat aux 5–10 passages les plus pertinents. Ceux-ci sont insérés dans un template de prompt avec citation des sources et transmis au LLM ; un contrôle de fidélité (faithfulness check) peut vérifier la réponse par rapport aux sources.

Embeddings et bases de données vectorielles

Les embeddings sont des représentations vectorielles numériques du texte, dans lesquelles la proximité sémantique se traduit par une proximité géométrique (la similarité cosinus étant la mesure par défaut pour les vecteurs normalisés). Pour les corpus en allemand, une règle importante s'applique : le classement MTEB en anglais n'est pas le classement en allemand. Les modèles en tête en anglais perdent souvent 5–15 points de nDCG@10 sur les mots composés allemands, la langue technique et les mots longs. Ce qui compte, ce sont les benchmarks allemands ou multilingues (MMTEB, MIRACL-de, MTEB-DE). Les mots composés allemands génèrent en outre davantage de tokens ; règle empirique : selon le modèle, l'allemand consomme environ 1,3–1,7 fois plus de tokens que l'anglais.

Les bases de données vectorielles stockent les embeddings et répondent aux requêtes de similarité via des index de plus proches voisins approximatifs (Approximate Nearest Neighbour). L'algorithme standard est HNSW (Hierarchical Navigable Small World, Malkov & Yashunin 2016), utilisé dans presque tous les systèmes en production, de Qdrant, Weaviate, Milvus et pgvector jusqu'à SAP HANA. Repère pratique : HNSW offre 95–99 % de recall et reste confortable jusqu'à ~100 millions de vecteurs ; au-delà, la quantification (halfvec, SQ8) ou des méthodes sur disque comme DiskANN prennent le relais.

Pour les PME européennes en dessous de ~10–50 millions de vecteurs, pgvector sur un Postgres managé (IONOS, STACKIT, OTC, Hetzner) constitue le choix souverain pragmatique par défaut : une seule base de données, une seule stratégie de sauvegarde, une seule chaîne de contrats de sous-traitance. Les grands groupes font généralement tourner deux ou trois stores en parallèle : SAP HANA Vector pour les données résidant dans SAP, plus une base vectorielle dédiée (Qdrant, Weaviate) pour les documents non structurés.

Chunking : comment découper la connaissance

Le chunking détermine dans une large mesure la qualité du retrieval. Le chunking naïf à taille fixe (par exemple 512 tokens avec un chevauchement de 50 tokens) est robuste, mais coupe les phrases, les tableaux et les listes ; un anti-pattern fréquent. De meilleures stratégies :

• Le chunking récursif/sémantique respecte la structure du document ou découpe aux ruptures de contenu.
• Le chunking hiérarchique (parent-child) utilise de petits chunks pour le retrieval et de grands chunks parents comme contexte pour le générateur.
• Avant l'embedding, le Contextual Retrieval (Anthropic, 09/2024) préfixe chaque chunk d'un court en-tête de contexte généré par un LLM. Résultat : −49 % d'erreurs de retrieval, −67 % avec un reranker supplémentaire. Le prix à payer : un appel LLM par chunk au moment de l'ingestion.
• Le Late Chunking (Jina, 2024) inverse l'ordre : on encode d'abord le document entier avec un embedder à contexte long, puis on calcule la moyenne des embeddings de tokens à l'intérieur des limites de chaque chunk ; les vecteurs des chunks conservent ainsi le contexte du document. Le late chunking ne coûte pratiquement rien à l'ingestion (aucun appel LLM supplémentaire) et, dans l'étude de Jina, fait ~24 % mieux que le chunking naïf. Pour les projets soucieux de leurs coûts, le late chunking avec Jina v3/v4 ou BGE-M3 est souvent le choix par défaut le plus rentable.

Pour les PDF à mise en page complexe (contrats, correspondance avec l'administration, rapports IFRS), les parsers qui tiennent compte de la mise en page (Docling, Marker) l'emportent ; et, à terme, les approches multimodales comme ColPali/ColQwen ou Jina v4, qui rendent chaque page sous forme d'image et contournent ainsi les erreurs d'OCR et de mise en page.

Recherche hybride et reranking

La recherche hybride combine le dense retrieval (embeddings, proximité sémantique) et le sparse retrieval (BM25 ou modèles sparse appris comme SPLADE/ELSER), puis fusionne les résultats, généralement via Reciprocal Rank Fusion (RRF). La raison : les embeddings seuls passent à côté des codes exacts, des ID, des numéros de dossier, des numéros d'article SAP ou des IBAN, c'est-à-dire justement des tokens qui comptent dans la pratique B2B en Europe. BM25 les rattrape. En allemand, avec ses mots composés et sa langue technique, l'hybride apporte systématiquement 5–15 points de nDCG@10 de plus que le dense seul.

Le reranking est la deuxième étape de tri, plus précise : un cross-encoder traite conjointement la requête et le document, puis réévalue les meilleurs candidats. C'est l'amélioration isolée au meilleur ROI de tout le pipeline : typiquement +5–15 points de pourcentage de recall@5. L'étude d'Anthropic (09/2024) mesure l'effet sur le taux d'erreur du retrieval top-20 : les Contextual Embeddings seuls le réduisent de 35 %, les Contextual Embeddings combinés au Contextual BM25 (ensemble, le Contextual Retrieval) de 49 %, et avec un reranker supplémentaire de 67 %. L'étape de reranking fait ainsi passer le taux d'erreur de 2,9 % à 1,9 %.

Budget de latence pour un pipeline standard (10 millions de vecteurs) : première étape BM25 et dense, 10–50 ms chacune ; RRF, moins de 1 ms ; reranker cross-encoder (par exemple BGE Reranker M3 sur un GPU), 100–300 ms ; au total, 150–500 ms avant la génération par le LLM. Avec des SLA stricts sous les 100 ms, le reranker est le premier candidat à la suppression, au prix d'une perte de recall de 5–15 points.

RAG ou alternatives : quand choisir quoi ?

Le RAG n'est pas la seule stratégie. Le choix face au fine-tuning, au long contexte et au prompt engineering dépend de l'objectif :

Le débat long contexte vs RAG reste ouvert, mais se clarifie de plus en plus. Les modèles actuels traitent environ 1 million de tokens de contexte, par exemple Gemini 3.1 Pro (preview) et les modèles Claude actuels. Dans le test classique à une seule aiguille (single needle), Gemini 1.5 Pro atteignait déjà plus de 99,7 % de recall à 1 million de tokens ; quand le modèle cherche 100 aiguilles simultanément, la valeur tombe à un peu plus de 60 % (rapport Gemini 1.5, arXiv:2403.05530). S'y ajoutent une latence ~30–60 fois plus élevée et des coûts par requête supérieurs de plusieurs ordres de grandeur par rapport à un pipeline RAG (estimation de Tian Pan, 2026). Le consensus en 2026 : le long contexte complète le RAG pour des workloads bien délimités, mais le remplace rarement dans les scénarios multi-needle, multi-tenant ou sensibles aux coûts.

RGPD et exploitation souveraine en Europe

Remarque : les informations suivantes sont fournies à titre indicatif et ne constituent pas un conseil juridique.

L'une des questions de fond les plus importantes liées au RGPD en 2025/2026 est la suivante : les embeddings sont-ils des données personnelles ? La réponse honnête : « très probablement oui, dès lors qu'ils sont dérivés de données personnelles ». Les attaques par inversion reconstruisent à l'identique jusqu'à 92 % d'entrées de 32 tokens (Morris et al., EMNLP 2023) ; un embedding n'est donc pas une pseudonymisation sûre. L'avis 28/2024 du CEPD exige une évaluation au cas par cas du risque de réidentification ; l'arrêt de la CJUE C-413/23 P (septembre 2025) précise que des données pseudonymisées ne sont pas automatiquement personnelles pour tout destinataire, mais il ne fait que restreindre les obligations, sans les supprimer.

Conséquences pratiques pour les architectures RAG, en s'appuyant sur le guide d'orientation RAG de la conférence allemande des autorités de protection des données (DSK) et sur les lignes directrices du CEPD :

• Droit à l'effacement (art. 17) : les embeddings et les chunks doivent eux aussi pouvoir être supprimés. Les graphes HNSW gèrent plus ou moins bien la suppression de points ; la sémantique de suppression est un critère d'achat éliminatoire (pgvector et Qdrant suppriment efficacement).
• Séparation des tenants : ID de tenant et ACL dans les métadonnées, filtre à chaque requête, défense en profondeur (authentification + filtre + revérification + journal d'audit). Un index partagé sans filtre de tenant est un incident RGPD programmé.
• Résidence des données : privilégier l'hébergement en région UE ; avec des fournisseurs cloud américains, évaluer le risque résiduel lié au CLOUD Act et à FISA 702 (CCT + TIA). Transférer des embeddings vers une base vectorielle hébergée aux États-Unis constitue un transfert vers un pays tiers.
• Minimisation avant l'embedding : supprimer autant que possible les noms, e-mails et ID avant l'embedding, ou les remplacer par des pseudonymes stables ; chiffrer les vecteurs avec des clés gérées par le client (CMK/BYOK).

Pour les workloads réglementés, chaque couche doit être déployable de manière souveraine. Dans l'UE, cela concerne par exemple le secteur financier soumis à DORA (en Allemagne, également à MaRisk), les dispositifs médicaux et de diagnostic in vitro soumis au MDR/IVDR, les entités essentielles et importantes soumises à la transposition nationale de NIS2 (en Autriche, la NISG 2026) et, en Allemagne, le secteur public soumis à l'OZG. En Suisse s'applique la loi fédérale révisée sur la protection des données (nLPD), conçue pour être compatible avec le RGPD.

L'infrastructure souveraine dans la région DACH (Allemagne, Autriche, Suisse) et dans l'UE est solide en 2026 : Qdrant (Berlin), Weaviate (Amsterdam), Haystack/deepset (Berlin), SAP HANA Cloud Vector Engine et pgvector sur STACKIT/IONOS/OTC/Hetzner. Côté fournisseurs de modèles, la situation a évolué. Aleph Alpha (Heidelberg) s'est détourné de ses propres modèles frontier et propose notamment la plateforme PhariaAI. En avril 2026, Cohere a annoncé son rapprochement avec Aleph Alpha, et le 16 septembre 2026, les deux entreprises ont signé l'accord de fusion. La nouvelle entité doit opérer sous le nom de Cohere, avec des sièges à Toronto et à Berlin, tandis que le site de Heidelberg se concentrera sur la recherche. La finalisation reste soumise aux autorisations réglementaires. Jina AI (Berlin), fournisseur de modèles d'embedding et de reranking, appartient à Elastic depuis octobre 2025.

Remarque sur le règlement européen sur l'IA (état 10/2026) : l'omnibus numérique sur l'IA, le règlement (UE) 2026/1744, est en vigueur depuis le 27 juillet 2026. Les obligations relatives aux systèmes à haut risque de l'annexe III s'appliquent donc à partir du 2 décembre 2027, et celles relatives à l'IA à haut risque intégrée dans des produits relevant de l'annexe I à partir du 2 août 2028. Les obligations de transparence de l'article 50 s'appliquent depuis le 2 août 2026. Seul le marquage lisible par machine prévu à l'article 50, paragraphe 2, bénéficie d'un délai : les fournisseurs de systèmes déjà sur le marché avant cette date ont jusqu'au 2 décembre 2026.

Assurance qualité avec RAGAS

Un système RAG sans évaluation se dégrade en silence. Le standard de facto est RAGAS, avec les métriques clés Faithfulness (fidélité à la source), Answer Relevancy, Context Precision et Context Recall, complété par TruLens (« RAG Triad ») ou DeepEval. L'approche pertinente combine un gold set, LLM-as-Judge et des tests A/B en production, solidement ancrés dans le pipeline CI. Le citation forcing, les garde-fous de fidélité et le refus de répondre en cas de score faible sont les moyens standards contre les hallucinations qui subsistent malgré le RAG.

Perspectives et conseil pratique

Les bases de données vectorielles et les modèles d'embedding se sont largement banalisés au niveau des API : HNSW est partout, la recherche hybride est la norme et la multimodalité (ColPali, Jina v4) est la nouvelle frontière. En parallèle, le RAG évolue selon les étapes Naive → Advanced → Modular → Agentic RAG, le retrieval étant de plus en plus conçu comme un outil dynamique d'un agent (Singh et al. 2025).

Le point de départ pragmatique pour un projet européen : commence par BM25 + Dense (BGE-M3) + reranker cross-encoder (BGE Reranker M3) sur une base Postgres/pgvector souveraine, classe les données personnelles avant l'embedding et mesure la qualité dès le premier jour avec RAGAS. Ce qui domine l'architecture en 2026, ce n'est plus la performance brute, mais la question de savoir où se trouvent les embeddings, qui peut y accéder et si la stack peut, au besoin, être rapatriée on-premise. Une stack RAG conçue de manière souveraine, pour l'allemand et orientée open source, est la réponse solide.