RAG

Le Retrieval-Augmented Generation, ou RAG, est un patron dans lequel une application recherche des informations externes, les ajoute au contexte d’une requête, puis demande à un modèle de générer une réponse fondée sur ces éléments. Le papier fondateur combinait un générateur paramétrique avec un index dense externe ; les systèmes actuels peuvent employer une recherche par mots-clés, sémantique, vectorielle ou hybride. [S1] [S2]

Le RAG facilite la mise à jour des connaissances, l’utilisation de données privées et la présentation de sources, mais ne garantit ni l’exactitude ni le respect des droits. Une récupération pauvre ou non autorisée peut produire une réponse plausible, incomplète ou confidentielle. [S1] [S2] [S5]

Décider avant de construire

Go

Un RAG est justifié lorsque toutes les conditions suivantes sont réunies :

• les questions utiles exigent un corpus trop vaste, trop changeant ou trop privé pour être placé directement dans un contexte court ; [S1] [S2]
• le corpus possède une autorité, un propriétaire, une politique de fraîcheur et des droits applicables au moment de chaque récupération ; [S2] [S5]
• un jeu de questions représentatives indique les preuves attendues et permet de comparer la récupération et la réponse à un baseline plus simple ; [S4]
• le pilote démontre une amélioration utile sans dépasser les budgets acceptés de latence, coût, exposition de données et maintenance. [S2] [S4]

Pilote limité

Choisir un pilote réversible lorsque le besoin de connaissances externes est réel mais que la qualité de récupération, les seuils d’abstention ou le coût restent inconnus. Le pilote doit porter sur un corpus autorisé et borné, conserver une sortie non décisionnelle, enregistrer des preuves minimales et posséder une condition d’arrêt. [S4] [S5]

No-go

Ne pas construire de RAG lorsque l’une de ces situations suffit :

• les documents utiles tiennent dans un contexte direct maintenable ou une recherche déterministe répond déjà au besoin ;
• la tâche attend un calcul, une validation de règles ou une action déterministe plutôt qu’une synthèse de connaissances ;
• la provenance, la fraîcheur ou les permissions du corpus ne peuvent pas être garanties à la récupération ; [S2] [S5]
• aucun jeu d’évaluation ne permet de reconnaître une meilleure récupération et une meilleure réponse ; [S4]
• le seul argument est qu’une base vectorielle, un modèle d’embeddings ou un service est disponible.

Ces exclusions sont une règle de décision pour OSIA : elles évitent d’ajouter un composant probabiliste et une surface de sécurité avant d’avoir observé une limite du baseline. [S2] [S4] [S5]

Entrées obligatoires

Avant toute architecture, consigner :

1. Le cas d’usage. Questions représentatives, utilisateurs, décision soutenue, erreurs acceptables, erreurs critiques et format de réponse attendu. [S4]
2. Le baseline. Contexte direct, recherche classique ou procédure humaine à dépasser ; sans comparaison, un score RAG isolé ne prouve aucun gain. [S4]
3. Le corpus. Sources incluses et exclues, format, langue, qualité, propriétaire, autorité, fréquence de mise à jour et procédure de suppression. [S2] [S5]
4. La matrice d’accès. Qui peut interroger quel document, selon quel attribut, et quel contrôle déterministe applique cette règle avant que le texte atteigne le modèle. [S2] [S5]
5. Les métadonnées. Identifiant stable, titre, provenance, date, version, classification, droits et lien vers le document source ; elles servent au filtrage, à la citation et à l’audit. [S2] [S3] [S5]
6. Le jeu d’évaluation. Questions normales, limites, absentes et adverses, avec preuves attendues, réponse acceptable et cas où le système doit s’abstenir. [S4] [S5]
7. Le budget opérationnel. Latence, coût, volume, taille de contexte, rétention des traces, disponibilité et charge de maintenance acceptables. [S2]

Flux de bout en bout

1. Sélectionner les sources. Accepter seulement les contenus dont la provenance, l’autorité et les droits sont connus. [S5]
2. Préparer sans perdre la provenance. Extraire le texte, le découper si nécessaire et rattacher à chaque unité son document, sa version, sa fraîcheur et ses permissions. [S2] [S3] [S5]
3. Indexer selon le besoin. La recherche peut être lexicale, sémantique, vectorielle ou hybride ; le choix doit découler des requêtes d’évaluation. [S2] [S3]
4. Autoriser la requête. Déterminer l’identité et les droits, puis restreindre l’espace de recherche avant tout résultat. Un prompt ne remplace pas ce contrôle. [S2] [S5]
5. Récupérer des candidats. Formuler la requête, appliquer les filtres de métadonnées et conserver les scores et identifiants de provenance. [S3] [S5]
6. Filtrer et classer. Écarter les résultats interdits, périmés, dupliqués ou peu pertinents ; un re-classement n’est utile que s’il améliore le jeu d’évaluation. [S2] [S3] [S4]
7. Augmenter comme données. Injecter uniquement les passages nécessaires, clairement séparés des instructions et marqués comme contenu non fiable. [S2] [S5]
8. Générer avec une politique de preuve. Demander une réponse appuyée sur les passages autorisés, des citations vérifiables et une abstention lorsque la preuve manque ou se contredit. Le modèle peut encore se tromper. [S2] [S4]
9. Rendre le résultat contrôlable. Exposer les sources effectivement utilisées, leur version et les limites de la réponse sans transformer la présence d’une citation en preuve automatique. [S1] [S2]
10. Évaluer et surveiller. Mesurer séparément la récupération, la génération, les refus, les droits, la sécurité, la latence et le coût ; enrichir le jeu avec les échecs réels. [S2] [S4] [S5]

Décisions obligatoires

• Autorité du corpus : qui accepte une source, corrige une erreur, révoque un document et vérifie sa fraîcheur. [S5]
• Unité de récupération : ce qui doit rester ensemble pour conserver le sens, les droits et la citation ; le découpage par défaut d’un outil n’est qu’un point de départ. [S3] [S5]
• Contrôle d’accès : identité, attributs, filtrage avant récupération, séparation entre utilisateurs ou espaces, et test explicite des fuites. [S2] [S5]
• Politique de réponse : preuves minimales, traitement des contradictions, citations, abstention, recours humain et actions interdites. [S2] [S4]
• Cycle de vie : ingestion, mise à jour, suppression, réindexation, délai de propagation et preuve qu’un contenu révoqué n’est plus récupérable. [S3] [S5]
• Évaluation et seuils : propriétaire du jeu, fréquence, critères de promotion ou de retour arrière et écarts tolérés face au baseline. [S4]
• Observabilité sûre : données journalisées, durée de rétention, accès aux traces et masquage des requêtes ou passages sensibles. [S2] [S5]

Choix d’implémentation facultatifs

• Recherche par mots-clés pour les termes exacts, identifiants ou vocabulaires stables ; recherche sémantique pour rapprocher des formulations différentes ; hybride si les tests montrent que les deux signaux sont complémentaires. [S2] [S3]
• Embeddings et vector store seulement si la recherche vectorielle apporte un gain mesuré. Ils ne sont requis ni par la décision métier ni par tous les patrons RAG. [S2] [S3]
• Re-classement, réécriture de requête ou plusieurs sous-requêtes lorsque les cas complexes restent mal couverts et que l’amélioration compense le coût et la latence. [S2] [S3] [S4]
• Résumé, compression ou sélection dynamique lorsque les passages pertinents dépassent le budget de contexte, avec un test de perte d’information. [S2] [S4]
• Recherche agentique uniquement si la décomposition de requêtes apporte un bénéfice sur des questions réellement composées ; elle augmente aussi le nombre d’étapes à évaluer et sécuriser. [S2] [S4] [S5]
• Produit ou fournisseur après avoir fixé les contrats de données, droits, suppression, évaluation et réversibilité. La disponibilité d’une fonction ne décide pas de son adéquation.

Évaluer par étages

1. Récupération

• la preuve attendue apparaît-elle dans les premiers résultats ;
• combien de passages récupérés sont réellement utiles ;
• les filtres excluent-ils systématiquement les documents non autorisés, révoqués ou hors périmètre ;
• les questions paraphrasées, ambiguës, sans réponse et adverses restent-elles sûres.

La précision et le rappel du contexte doivent être définis sur les requêtes du produit, pas repris comme seuils universels. [S4] [S5]

2. Réponse

• chaque affirmation décisive est-elle soutenue par un passage récupéré ;
• la citation pointe-t-elle vers le bon document et la bonne version ;
• les contradictions et preuves insuffisantes déclenchent-elles l’abstention prévue ;
• la réponse satisfait-elle le besoin sans introduire de détail absent des sources.

Les évaluations automatiques doivent être calibrées avec des jugements humains et des réponses de référence, puis complétées avec les échecs observés. [S4]

3. Exploitation et sécurité

• latence et coût aux volumes représentatifs ;
• délai entre ajout, correction ou suppression et résultat de recherche ;
• absence de fuite entre utilisateurs, rôles ou espaces ;
• résistance aux documents empoisonnés, aux instructions cachées et aux requêtes d’exfiltration ;
• traces suffisantes pour diagnostiquer sans conserver inutilement des données sensibles.

Le RAG ajoute une récupération, des tokens et des opérations d’indexation ; ces coûts et risques doivent être mesurés avec la qualité. [S2] [S5]

Risques matériels et contre-mesures

• Fuite inter-utilisateurs. Cause : filtrage tardif ou métadonnées de droits perdues. Contre-mesure : autorisation et filtrage déterministes avant récupération, tests négatifs pour chaque frontière. [S2] [S5]
• Injection indirecte. Cause : un document contient des instructions que le modèle traite comme autorité. Contre-mesure : considérer les passages comme données non fiables, préserver les rôles, isoler le contenu et limiter les actions possibles. [S5]
• Empoisonnement. Cause : une source compromise entre dans l’index ou persiste après correction. Contre-mesure : ingestion autorisée, provenance, versionnement, validation, révocation et tests adverses. [S5]
• Contenu périmé ou supprimé encore visible. Cause : cycle de vie incomplet ou propagation asynchrone. Contre-mesure : dates et versions filtrables, procédure de suppression vérifiée et délai maximal mesuré. [S3] [S5]
• Citation trompeuse. Cause : le passage existe mais ne soutient pas l’affirmation. Contre-mesure : évaluer la correspondance affirmation-preuve et ouvrir la source exacte, pas seulement afficher un lien. [S2] [S4]
• Journal sensible. Cause : requêtes, passages ou réponses brutes conservés sans limite. Contre-mesure : minimisation, masquage, contrôle d’accès, durée de rétention et finalité documentée. [S5]
• Confiance excessive. Cause : une réponse fluide est assimilée à une réponse fondée. Contre-mesure : politique d’abstention, preuves visibles, évaluation continue et recours humain pour les décisions matérielles. [S2] [S4]

Checklist de décision OSIA

Répondre oui, non ou inconnu :

1. Le cas d’usage exige-t-il réellement une connaissance externe ou changeante ?
2. Le baseline simple et les erreurs à corriger sont-ils mesurés ?
3. Le corpus a-t-il un propriétaire, une autorité, une fraîcheur et une procédure de suppression ?
4. Les permissions peuvent-elles être appliquées avant chaque récupération et testées négativement ?
5. Les métadonnées permettent-elles provenance, filtrage, citation et révocation ?
6. Le jeu d’évaluation couvre-t-il preuves attendues, absences, contradictions et attaques ?
7. La réponse sait-elle citer, signaler ses limites et s’abstenir ?
8. Le pilote améliore-t-il le résultat face au baseline sans dépasser les budgets de risque, coût et latence ?
9. Une personne est-elle responsable des seuils, incidents, réévaluations et retours arrière ?

Décider go seulement si les contrôles de corpus, droits et évaluation sont prêts et si le gain est mesuré. Décider pilote limité si ces contrôles existent mais que le gain ou les seuils restent inconnus. Décider no-go si une frontière de sécurité n’est pas applicable, si le corpus n’est pas gouverné ou si le baseline satisfait déjà le besoin. [S2] [S4] [S5]