RAG en production : architecture et pièges à éviter

Un RAG en production (retrieval-augmented generation, ou génération augmentée par la recherche) consiste à retrouver dans vos propres documents les passages pertinents pour une question, puis à les fournir au modèle de langage afin qu'il réponde à partir de ces sources plutôt que de sa seule mémoire. L'approche, formalisée dans un article de recherche de 2020, associe une mémoire paramétrique, le modèle, à une mémoire non paramétrique, l'index documentaire 1.

En production, la qualité d'un RAG dépend bien davantage de l'ingestion, du découpage, de la recherche et du contrôle des droits que du choix du modèle de génération. Les échecs les plus fréquents ne sont pas des hallucinations spectaculaires, mais des réponses construites sur un document obsolète, un passage mal découpé, ou un document que l'utilisateur n'aurait jamais dû voir.

Voici une architecture de référence en deux chaînes, ingestion et requête, et les pièges à traiter à chaque étape avant d'ouvrir le service à des milliers d'utilisateurs.

Architecture de référence d'un RAG en production

Un RAG robuste se décompose en deux chaînes indépendantes, reliées par l'index. La chaîne d'ingestion, exécutée en tâche de fond, transforme les sources en fragments indexés. La chaîne de requête, exécutée à chaque question, retrouve les fragments autorisés et construit la réponse. L'évaluation, enfin, est transverse : elle mesure les deux chaînes séparément.

Ingestion : connecteurs vers les sources (GED, intranet, tickets, bases de connaissances), extraction du texte et de la structure, nettoyage, découpage, enrichissement par des métadonnées (source, version, date, propriétaire, droits), calcul des embeddings, indexation vectorielle et lexicale.
Requête : authentification de l'utilisateur, reformulation éventuelle de la question, recherche hybride filtrée par les droits, reclassement des résultats, construction du contexte, génération avec citations des sources, contrôles de sortie, journalisation.
Exploitation : supervision de la fraîcheur de l'index, des erreurs d'ingestion, des temps de réponse et des retours utilisateurs, avec un jeu d'évaluation rejoué à chaque modification.

Séparer les chaînes permet de faire évoluer l'une sans casser l'autre : changer de modèle d'embedding impose de réindexer, mais pas de toucher à l'interface ; changer de modèle de génération ne remet pas en cause l'index.

Ingestion et découpage : la qualité se joue en amont

La plupart des mauvaises réponses viennent d'un texte mal extrait. Les PDF en colonnes, les tableaux, les documents scannés et les présentations perdent leur structure si l'extraction est naïve, et le modèle reçoit alors des phrases tronquées ou des chiffres détachés de leur intitulé. Il faut tester l'extraction format par format, sur un échantillon représentatif, avant de régler quoi que ce soit d'autre.

L'extraction est aussi un point de contrôle de sécurité. L'OWASP cite parmi les scénarios d'attaque des documents contenant du texte caché, par exemple blanc sur fond blanc, destiné à manipuler les réponses, et recommande une extraction capable de détecter ce contenu ainsi que l'acceptation de données provenant uniquement de sources de confiance 2. L'ANSSI recommande de son côté d'évaluer le niveau de confiance des sources de données externes utilisées par un système d'IA 3.

Découper selon la structure, pas selon un nombre de caractères

Un découpage à taille fixe coupe les procédures au milieu d'une étape et sépare les définitions de leurs exceptions. Un découpage qui suit la structure du document (titres, sections, articles, lignes de tableau) produit des fragments qui ont un sens autonome. Deux pratiques complètent utilement cette approche : conserver le titre de section et le nom du document dans chaque fragment, et garder un lien vers le fragment parent pour élargir le contexte si nécessaire.

Dernier piège de l'ingestion : la mise à jour. Un document modifié doit être réindexé, et un document supprimé à la source doit disparaître de l'index. Sans synchronisation des suppressions, le RAG continue de citer des procédures abrogées, ce qui est plus dangereux qu'une absence de réponse.

Recherche hybride et reclassement des résultats

La recherche vectorielle retrouve les passages proches par le sens, même formulés différemment de la question. Elle est en revanche peu fiable sur les termes exacts : références de contrats, codes produits, numéros d'articles, acronymes internes. La recherche lexicale classique fait l'inverse. Les combiner, c'est la recherche hybride, et c'est généralement le meilleur point de départ pour un corpus d'entreprise.

Une méthode de fusion courante est la fusion par rang réciproque (reciprocal rank fusion) : chaque document reçoit la somme, sur chaque liste de résultats où il apparaît, de 1 divisé par (k + son rang). Elasticsearch, par exemple, fixe par défaut la constante k à 60 4. Cette méthode a l'avantage de ne pas exiger de normaliser des scores hétérogènes.

Les premiers résultats fusionnés passent ensuite par un modèle de reclassement (reranker), plus coûteux mais plus précis, qui ne conserve que les meilleurs fragments. Le contexte transmis au modèle reste ainsi court et pertinent : un contexte saturé de passages moyens dégrade les réponses et augmente le coût de chaque requête.

Un RAG qui cite un document que l'utilisateur n'a pas le droit de lire est une fuite de données, pas un défaut de qualité.

Droits d'accès : le piège le plus coûteux d'un RAG en production

Un RAG agrège des documents issus de systèmes qui ont chacun leur modèle de droits. Si l'index ne les reproduit pas, n'importe quel utilisateur peut obtenir, reformulé par le modèle, le contenu d'un document confidentiel. L'OWASP classe ce risque dans les faiblesses des vecteurs et embeddings : contrôles d'accès insuffisants, fuites de contexte entre utilisateurs ou entités dans un index partagé, et même possibilité de reconstituer une partie du texte source à partir des embeddings. Il recommande des permissions fines et un cloisonnement strict des jeux de données 2. L'ANSSI demande de prendre en compte le besoin d'en connaître dès la conception du système d'IA 3.

Capturer les droits à l'ingestion, document par document, sous forme de métadonnées (groupes, entités, niveau de classification).
Filtrer au moment de la recherche, avant tout reclassement et toute génération, avec l'identité réelle de l'utilisateur propagée depuis l'application.
Synchroniser les changements de droits aussi vite que les changements de contenu : un collaborateur qui quitte un projet ne doit plus en voir les documents.
Isoler dans des index distincts les corpus les plus sensibles plutôt que de compter sur un seul filtre.
Tester les droits comme une fonctionnalité : des comptes de test aux profils différents posent les mêmes questions et ne doivent pas obtenir les mêmes sources.

Les documents indexés sont enfin une porte d'entrée pour l'injection de prompt indirecte : un texte récupéré peut contenir des instructions que le modèle risque d'exécuter. L'OWASP rappelle que le RAG ne suffit pas à neutraliser ce risque et recommande de séparer et de signaler clairement le contenu non fiable dans le contexte 5.

Évaluer un RAG : mesurer séparément recherche et génération

Une note globale de satisfaction ne dit pas où corriger. Il faut distinguer la qualité de la recherche (les bons fragments sont-ils retrouvés ?) de la qualité de la génération (la réponse est-elle fidèle à ces fragments ?). Les bibliothèques d'évaluation comme Ragas proposent des métriques dédiées, dont la précision et le rappel du contexte, la fidélité de la réponse au contexte et la pertinence de la réponse 6.

Le socle reste un jeu de questions de référence construit avec les métiers : questions réelles, réponses attendues, documents sources attendus, y compris des questions sans réponse dans le corpus, pour vérifier que le système sait dire qu'il ne sait pas. Ce jeu est rejoué à chaque changement de découpage, de modèle d'embedding, de paramètres de recherche ou de prompt. En production, la journalisation des questions, des fragments retrouvés et des réponses, recommandée par l'ANSSI pour l'ensemble des traitements d'un système d'IA 3, alimente l'enrichissement du jeu de test.

Avant d'ouvrir le service, vérifiez au minimum les points suivants :

Extraction validée format par format sur un échantillon réel, tableaux et scans compris.
Suppressions et changements de droits propagés à l'index dans un délai défini et supervisé.
Filtrage par droits testé avec plusieurs profils, y compris des tentatives de contournement par reformulation.
Seuils minimaux atteints sur le jeu de référence pour la recherche et pour la fidélité des réponses.
Citations des sources affichées à l'utilisateur, avec lien vers le document d'origine.
Comportement explicite quand aucune source pertinente n'est trouvée.

Conclusion

Un RAG en production est d'abord un système de recherche documentaire sécurisé, auquel on ajoute un modèle de langage. Les gains viennent d'une extraction soignée, d'un découpage structuré, d'une recherche hybride reclassée et d'un contrôle d'accès appliqué avant la génération, le tout mesuré par un jeu d'évaluation vivant. C'est sur cette intégration avec les sources, les identités et l'exploitation que DATASWING accompagne ses clients.

RAG en production architecture RAG recherche hybride évaluation RAG

— Questions fréquentes

Ce qu'on nous demande souvent

Qu'est-ce qu'un RAG en entreprise ?

Un RAG, ou génération augmentée par la recherche, est une architecture qui retrouve dans les documents de l'entreprise les passages utiles à une question, puis les fournit à un modèle de langage pour qu'il rédige une réponse sourcée. Il permet d'exploiter des informations internes et à jour sans réentraîner le modèle, à condition de bien gérer l'ingestion, la recherche et les droits d'accès.

Quelle taille de chunk choisir pour un RAG ?

Il n'existe pas de taille universelle. Mieux vaut découper selon la structure du document (sections, articles, procédures) que selon un nombre fixe de caractères, conserver le titre et la source dans chaque fragment, puis comparer plusieurs réglages sur un jeu de questions de référence. Le bon découpage est celui qui maximise la qualité de recherche mesurée sur votre corpus.

Comment gérer les droits d'accès dans un RAG ?

Les droits doivent être capturés à l'ingestion sous forme de métadonnées, puis appliqués comme filtre au moment de la recherche, avec l'identité réelle de l'utilisateur, avant toute génération. Les changements de droits et les suppressions doivent être synchronisés rapidement, et les corpus les plus sensibles isolés dans des index distincts. Des tests avec plusieurs profils vérifient le cloisonnement.

Pourquoi utiliser une recherche hybride plutôt que vectorielle ?

La recherche vectorielle comprend le sens d'une question mais retrouve mal les termes exacts, comme une référence de contrat, un code produit ou un acronyme interne. La recherche lexicale fait l'inverse. Les combiner, puis reclasser les meilleurs résultats, améliore la pertinence sur les corpus d'entreprise, qui mêlent langage naturel et identifiants précis.

— Sources