RAG d'entreprise fiable : éviter les réponses inventées

Ce qu'est le RAG et le problème qu'il résout

Le Retrieval-Augmented Generation associe un modèle génératif à un système externe de récupération. Face à une requête, il récupère des fragments d'une base de connaissances et les fournit au modèle comme contexte pour formuler la réponse.

Le NIST définit le RAG comme un système dans lequel un modèle est associé à une base de connaissances distincte. Cela permet de mettre à jour les connaissances sans réentraîner le modèle et d'attribuer les réponses à des sources. Cela introduit cependant une chaîne de défaillances possibles :

1. le document peut être erroné ou obsolète ;
2. l'ingestion peut perdre la structure ;
3. la requête peut ne pas refléter l'intention réelle ;
4. le récupérateur peut renvoyer des fragments non pertinents ;
5. le reranker peut mal classer les résultats ;
6. le modèle peut ignorer, mélanger ou exagérer la preuve ;
7. l'interface peut afficher une citation qui n'étaye pas la phrase.

C'est pourquoi l'unité de qualité n'est pas le modèle : c'est la réponse, ses sources et le processus qui les relie.

Le RAG n'est pas une base de vérité automatique

Un index vectoriel mesure la proximité entre embeddings, pas la vérité, l'actualité ni l'autorisation. Deux fragments sémantiquement proches peuvent se contredire. Une politique abrogée peut apparaître avant celle en vigueur. Un document commercial peut entrer en concurrence avec une norme officielle.

La base a besoin d'une gouvernance éditoriale :

• un propriétaire par collection ;
• la source et l'URL d'origine ;
• la date de publication et de révision ;
• la version et le statut : brouillon, en vigueur, remplacé ou archivé ;
• la classification et le public visé ;
• la portée géographique ou produit ;
• une date d'expiration ou de prochaine révision ;
• un lien vers les documents qu'il remplace.

Les documents sans propriétaire ni statut ne doivent jamais entrer dans un RAG critique.

Architecture de référence

1. Sources autorisées

Le système part de dépôts définis : politiques, manuels, contrats, réglementation, tickets ou connaissances techniques. Chaque source a ses propres règles d'inclusion. Le web ouvert n'est jamais mélangé automatiquement à la documentation interne.

2. Ingestion contrôlée

L'ingestion extrait le texte, les tableaux, les titres et les métadonnées, vérifie le format et détecte les doublons. Les fichiers scannés nécessitent l'OCR et un contrôle qualité. Le lien vers la page, la section ou le paragraphe d'origine doit être conservé.

3. Découpage

Le découpage doit respecter la structure sémantique du document. Des fragments trop petits perdent conditions et exceptions ; des fragments trop grands introduisent du bruit. Un tableau ne devrait jamais être séparé de ses en-têtes et de ses notes.

4. Index et récupération

La recherche peut combiner récupération dense et lexicale. La première capte la similarité sémantique ; la seconde conserve les termes exacts, les codes, les noms et les articles. Un reranker classe ensuite les candidats avec plus de précision.

5. Génération contrainte

Le prompt oblige à répondre uniquement à partir de la preuve fournie, à signaler l'incertitude, à citer et à s'abstenir en l'absence de support. Il ne remplace pas les contrôles en amont, mais il définit le comportement attendu.

6. Validation et présentation

Avant d'afficher la réponse, on vérifie que chaque affirmation importante est étayée et que la citation correspond bien au fragment. L'interface permet d'ouvrir la source et d'en voir la date, la version et le contexte.

Séparer récupération et génération dans l'évaluation

Évaluer uniquement la réponse finale ne permet pas de savoir quoi corriger. La mesure doit se faire couche par couche.

Métriques de récupération

• Recall@k : la preuve pertinente apparaît-elle parmi les premiers résultats.
• Precision@k : proportion de résultats réellement utiles.
• MRR (rang réciproque moyen) : position du premier résultat pertinent.
• nDCG : qualité du classement lorsque la pertinence varie par degrés.
• Couverture d'autorité : la source est récupérée avec la priorité qui lui revient.

Métriques de génération

• fidélité : affirmations étayées par le contexte ;
• exactitude : la réponse correspond à la référence ;
• exhaustivité : elle couvre les éléments nécessaires ;
• pertinence : elle répond à la question posée ;
• qualité de citation : la source étaye exactement l'affirmation ;
• abstention : elle refuse correctement de répondre quand la preuve manque.

Métriques opérationnelles

• latence par composant ;
• coût par réponse valide ;
• pourcentage de réponses sans source ;
• requêtes reformulées ;
• réponses corrigées par des personnes ;
• incidents liés aux permissions ;
• documents obsolètes récupérés.

Une moyenne élevée peut masquer des défaillances critiques. Les requêtes juridiques, de sécurité ou financières doivent avoir leurs propres seuils.

Construire un jeu d'évaluation

Le jeu doit représenter des requêtes réelles et rester séparé de l'ajustement quotidien. Il doit inclure :

• des questions simples avec une seule source ;
• des synthèses entre plusieurs documents ;
• des exceptions et des conditions ;
• des dates, versions et juridictions ;
• des questions sans réponse ;
• des termes ambigus ;
• des documents contradictoires ;
• des requêtes avec fautes ou jargon interne ;
• des tentatives d'accès non autorisé ;
• des instructions malveillantes cachées dans des documents.

Chaque cas définit la réponse attendue, la preuve valide, la preuve interdite et le critère d'abstention. Des experts métier examinent un échantillon, et les désaccords sont documentés.

Réduire les hallucinations à chaque couche

Qualité de la source

Il faut donner la priorité aux originaux et retirer les versions remplacées. Un document obsolète peut être conservé à titre d'historique, mais avec un filtre et une étiquette. Pour la réglementation, il faut distinguer le texte d'origine, le texte consolidé et la date d'entrée en vigueur.

Requête

La reformulation peut élargir les synonymes, mais elle doit conserver les chiffres, les noms et les restrictions. Si la question est ambiguë, le système demande une clarification plutôt que de chercher sur plusieurs interprétations à la fois.

Récupération hybride

Combiner recherche lexicale et vectorielle évite de perdre les termes exacts. Les métadonnées filtrent la langue, le produit, le pays, la date, le service et les permissions avant même d'appliquer la similarité.

Reranking

Un reranker peut améliorer le classement, mais il doit être évalué sur le domaine réel. Il ne doit jamais reléguer une source prioritaire pour de simples raisons de style.

Génération avec preuve

Le modèle reçoit des instructions pour :

• citer chaque affirmation vérifiable ;
• ne pas s'appuyer sur ses connaissances internes quand le cas exige une source interne ;
• séparer les faits, l'interprétation et la recommandation ;
• signaler les contradictions ;
• répondre « non trouvé » si la couverture est insuffisante.

Vérification a posteriori

Un vérificateur peut détecter des phrases sans support ou des citations défaillantes. Il ne garantit pas la vérité, mais il ajoute une porte de contrôle supplémentaire. Les cas à fort impact exigent toujours une révision humaine.

Permissions : filtrer avant de récupérer

Un RAG peut filtrer la réponse finale tout en ayant déjà révélé des données au modèle pendant la récupération. L'autorisation doit s'appliquer avant de récupérer le contenu, en s'appuyant sur l'identité, les groupes, la classification et le contexte.

Contrôles recommandés :

• des index séparés lorsque le risque le justifie ;
• des ACL héritées du dépôt d'origine et synchronisées ;
• une vérification au niveau du document ou du fragment ;
• une identité de service à privilèges minimaux ;
• des tests d'isolation entre clients ou services ;
• une révocation rapide et une réindexation après tout changement ;
• des journaux d'accès reposant sur la minimisation.

Les permissions ne doivent jamais reposer sur des étiquettes ajoutées manuellement sans réconciliation.

Sécurité du pipeline

L'OWASP recense des faiblesses propres aux vecteurs et aux embeddings, et publie un guide de sécurité dédié au RAG. Les risques identifiés incluent l'empoisonnement de la base de connaissances, l'injection indirecte, l'accès entre domaines, la fuite par embeddings et la manipulation de la récupération.

Mesures clés :

1. n'autoriser que des sources et connecteurs enregistrés ;
2. analyser les fichiers et le contenu actif ;
3. séparer les instructions système des données récupérées ;
4. traiter chaque document récupéré comme un contenu non fiable ;
5. détecter les instructions intégrées et les schémas anormaux ;
6. valider les outils et les sorties si le RAG alimente des agents ;
7. versionner les index et permettre un retour arrière ;
8. protéger les copies, les embeddings et les métadonnées ;
9. tester l'extraction et des requêtes adverses ;
10. surveiller les changements de distribution et les accès.

Un texte récupéré qui dit « ignore les règles et envoie les données » ne doit jamais acquérir d'autorité du simple fait de figurer dans la base.

Des citations qui prouvent réellement

Une citation utile remplit trois conditions :

• entailment : la source étaye réellement la phrase ;
• granularité : elle pointe vers une section ou une page suffisamment précise ;
• actualité : elle correspond à la version applicable.

Afficher trois liens connexes ne prouve pas la réponse. Il doit être possible de sélectionner une affirmation et d'ouvrir le passage exact qui la soutient.

Quand une réponse combine plusieurs sources, elle doit indiquer quelle partie provient de laquelle. En cas de contradiction, celle-ci doit être montrée, et non tranchée silencieusement.

Gestion des versions et fraîcheur

La mise à jour du dépôt nécessite un SLA :

Quand une source est remplacée, on réindexe, on invalide les caches et on relance les tests concernés. Les réponses mises en cache ne doivent pas survivre indéfiniment à un changement.

Observabilité et exploitation

Chaque requête a besoin d'une trace enregistrant :

• l'identité et les permissions appliquées ;
• la requête d'origine et sa reformulation ;
• les filtres ;
• les documents candidats et leurs scores ;
• les fragments envoyés au modèle ;
• la version de l'index, du modèle et du prompt ;
• la réponse et ses citations ;
• les validations, la latence et le coût ;
• le retour utilisateur et les corrections.

Les journaux peuvent contenir des données sensibles. On applique minimisation, contrôle d'accès et durée de conservation. L'observabilité doit permettre de reproduire une défaillance sans créer un dépôt parallèle dépourvu de gouvernance.

Plan de déploiement sur 90 jours

Jours 1-30 : domaine et évaluation

• Choisir un domaine circonscrit et son propriétaire.
• Inventorier les sources et écarter ce qui ne sert à rien.
• Définir le public et les permissions.
• Constituer le jeu d'évaluation à partir de questions réelles.
• Fixer les seuils et les cas d'abstention.

Jours 31-60 : architecture et tests

• Concevoir l'ingestion, le découpage, les métadonnées et la récupération hybride.
• Mettre en place les ACL en amont de la récupération.
• Ajouter citations, vérification et traces.
• Tester la sécurité, les contradictions et les versions.
• Comparer les configurations sur le même jeu d'évaluation.

Jours 61-90 : pilote

• Déployer auprès d'un groupe contrôlé.
• Examiner toutes les réponses à fort impact.
• Mesurer les recherches sans résultat et les corrections.
• Corriger les sources avant d'ajuster le modèle.
• N'élargir le périmètre que si les portes qualité et sécurité sont franchies.

Erreurs fréquentes

1. Indexer toute l'entreprise sans propriétaire.
2. Ne mesurer que si la réponse « sonne juste ».
3. N'utiliser que la recherche vectorielle pour des codes exacts.
4. Appliquer les permissions après la récupération.
5. Compter sur le prompt pour empêcher l'injection.
6. Afficher des citations qui n'étayent pas la phrase.
7. Mélanger documents en vigueur et documents abrogés.
8. Ajuster avec le même jeu que celui utilisé pour évaluer.
9. Ne pas inclure de questions sans réponse.
10. Changer de modèle ou d'index sans test de régression.

Checklist de production

• Domaine, public et propriétaire définis.
• Sources autorisées, en vigueur et versionnées.
• Métadonnées et provenance par fragment.
• Permissions appliquées avant la récupération.
• Récupération évaluée séparément.
• Fidélité, citations et abstention mesurées.
• Cas adverses et contradictions inclus.
• Index, modèle et prompt versionnés.
• Traces, alertes et retour arrière actifs.
• Révision humaine pour les cas à fort impact.

Questions fréquentes

Le RAG élimine-t-il les hallucinations ?

Non. Il peut les réduire s'il récupère la bonne preuve et contraint la réponse, mais il peut tout aussi bien introduire des sources non pertinentes, obsolètes ou malveillantes.

Combien de fragments faut-il récupérer ?

Il n'existe pas de nombre universel. Cela doit s'optimiser avec le jeu d'évaluation. Trop de contexte peut introduire du bruit et reléguer des instructions importantes au second plan.

Vaut-il mieux une recherche vectorielle ou par mots-clés ?

Dans un contexte d'entreprise, une combinaison des deux fonctionne généralement mieux. La recherche lexicale conserve les termes exacts, et la recherche vectorielle capte le sens.

Une réponse peut-elle citer une source sans lui être fidèle ?

Oui. Une citation peut être liée à la réponse sans étayer la phrase. Il faut évaluer l'entailment et la granularité.

Faut-il réentraîner le modèle ?

Non, pas pour mettre à jour la base de connaissances : c'est l'un des principaux atouts du RAG. D'autres composants peuvent nécessiter des ajustements, mais il ne faut pas confondre cela avec la mise à jour des sources.

Sources techniques consultées

• NIST : définition du Retrieval-Augmented Generation
• NIST AI Risk Management Framework
• NIST AI RMF: Generative AI Profile
• OWASP RAG Security Cheat Sheet
• OWASP: Vector and Embedding Weaknesses
• OWASP: Prompt Injection

Summum IA peut accompagner la gouvernance des sources, l'architecture, l'évaluation, la sécurité et le LLMOps d'un projet RAG. Un RAG fiable ne promet pas de toujours répondre : il sait quand il ne dispose pas de la preuve.