Tester un système RAG exige de séparer trois questions : le moteur a-t-il récupéré les bons passages, le contexte transmis au modèle est-il fidèle et autorisé, puis la réponse utilise-t-elle correctement ces preuves ? Une réponse finale correcte peut masquer une mauvaise récupération ; une bonne récupération peut être déformée par le modèle. Le plan de test doit donc mesurer chaque couche, les citations, les refus, les droits d’accès et la performance de bout en bout.
Qu’est-ce qu’un système RAG ?
Retrieval-Augmented Generation (RAG), ou génération augmentée par récupération, désigne une architecture qui récupère des informations dans une source externe puis les ajoute au contexte d’un modèle génératif afin de produire une réponse.
Le terme a été popularisé par l’article de Patrick Lewis et ses coauteurs, publié à NeurIPS 2020. Le travail combine une mémoire paramétrique — le modèle — avec une mémoire non paramétrique consultée par un mécanisme de récupération.
Un embedding désigne une représentation numérique d’un contenu dans un espace où une mesure de proximité peut être utilisée pour rechercher des éléments jugés similaires. La proximité vectorielle n’est pas une preuve que deux passages répondent à la même question ou possèdent le même niveau d’autorité.
Le RAG permet de mettre à jour une base documentaire sans réentraîner les poids du modèle. Il ne garantit ni la fraîcheur, ni la vérité, ni le respect des droits : ces propriétés dépendent des sources, de l’indexation, de la recherche, du contexte et de la génération.
Les quatre étapes fonctionnelles d’une chaîne RAG
1. Indexer
Les documents sont collectés, nettoyés, découpés en fragments et transformés en représentations consultables. Les métadonnées — source, version, date, langue, propriétaire et droits — doivent rester liées aux fragments.
2. Rechercher
La requête est transformée puis comparée à l’index. Le système sélectionne des passages selon sa stratégie : recherche lexicale, vectorielle, hybride, filtres ou reclassement.
3. Augmenter
Les passages retenus sont assemblés avec les instructions et la question. Leur ordre, leur longueur, leurs doublons et leurs conflits influencent la réponse.
4. Générer
Le modèle produit la sortie demandée, idéalement avec citations, limites et refus lorsque le contexte ne suffit pas.
Le test de bout en bout doit être décomposé en récupération + contexte + génération, car un score final seul ne localise pas la défaillance.
Que faut-il tester à chaque couche ?
| Couche | Question | Défauts typiques | Oracle ou preuve |
|---|---|---|---|
| Ingestion | les bons documents sont-ils indexés ? | version périmée, doublon, texte manquant | inventaire et empreintes |
| Découpage | les fragments conservent-ils le sens ? | règle séparée de son exception | document source annoté |
| Récupération | les passages nécessaires remontent-ils ? | faux négatif, passage hors sujet | passages pertinents attendus |
| Autorisation | seuls les documents permis sont-ils récupérés ? | fuite inter-client | matrice identité/document |
| Contexte | le prompt reçoit-il des preuves utiles ? | troncature, conflit, instruction hostile | contexte réellement envoyé |
| Génération | la réponse suit-elle les preuves ? | invention, mauvaise synthèse | réponse de référence et citations |
| Exploitation | le système reste-t-il observable ? | coût ou latence non bornés | traces, seuils et alertes |
Construire un jeu d’évaluation RAG
Un jeu utile associe une question à plusieurs niveaux de vérité : réponse attendue, passages nécessaires, documents interdits et comportement en absence de preuve.
Types de questions à inclure
- question factuelle avec un passage unique ;
- question nécessitant deux passages du même document ;
- question nécessitant plusieurs documents ;
- formulation utilisant un synonyme absent de la source ;
- question avec une négation ou une exception ;
- documents contradictoires de versions différentes ;
- information absente : le bon résultat est un refus ou
indéterminé; - question d’un utilisateur sans droit sur le document pertinent ;
- document contenant une instruction hostile ;
- requête longue, bruitée ou multilingue selon le périmètre.
Pour chaque cas, définissez les passages considérés pertinents avant l’exécution. Lorsque plusieurs sources sont acceptables, annotez l’ensemble plutôt qu’un unique fragment.
Métriques de récupération
Les métriques doivent être choisies selon le produit et la profondeur d’affichage.
Rappel à k
Le rappel à k mesure la proportion des passages pertinents attendus présents parmi les k premiers résultats. Il répond à la question : « les preuves nécessaires ont-elles été retrouvées ? »
Précision à k
La précision à k mesure la proportion des k résultats qui sont pertinents. Elle aide à détecter un contexte encombré de passages inutiles.
Rang du premier résultat pertinent
Cette mesure indique à quelle position apparaît la première preuve utile. Elle est pertinente lorsque seuls les premiers passages entrent dans le contexte.
Respect des filtres
Un résultat pertinent mais interdit constitue un échec de sécurité, pas un succès de récupération. Mesurez séparément les violations d’autorisation, de version, de langue ou de périmètre.
Aucune métrique unique ne suffit. Un rappel élevé peut s’accompagner d’un contexte bruyant ; une précision élevée peut manquer l’exception décisive.
Évaluer le contexte transmis au modèle
Le contexte réellement envoyé peut différer des résultats bruts après reclassement, déduplication, troncature ou assemblage.
Vérifiez :
- présence de tous les passages nécessaires ;
- maintien des titres, dates et identifiants ;
- absence de documents interdits ;
- ordre des sources concurrentes ;
- conservation des exceptions ;
- détection des contradictions ;
- séparation entre instructions fiables et contenu documentaire ;
- absence de troncature au milieu d’une règle ;
- budget de contexte et doublons.
L’ancrage aux sources désigne le degré auquel une réponse est soutenue par les informations récupérées et autorisées. Une réponse vraie mais non soutenue par le contexte échoue si l’application exige que le modèle réponde uniquement depuis la base documentaire.
Évaluer la génération et les citations
| Critère | Question de contrôle |
|---|---|
| Exactitude | la réponse est-elle correcte selon l’oracle ? |
| Fidélité | chaque affirmation découle-t-elle du contexte ? |
| Complétude | les éléments nécessaires sont-ils présents ? |
| Pertinence | la réponse traite-t-elle la question sans digression ? |
| Citation | chaque référence existe-t-elle et soutient-elle la phrase ? |
| Incertitude | le système refuse-t-il lorsque la preuve manque ? |
| Cohérence | les conflits de sources sont-ils signalés ? |
Une citation doit être évaluée au niveau de l’affirmation. Vérifier seulement que le document existe ne suffit pas : le passage doit soutenir la conclusion, appartenir à la bonne version et être accessible à l’utilisateur.
Méthode pratique pour tester un RAG en sept étapes
Étape 1 — Définir le périmètre et les autorités documentaires
Objectif : savoir quelles sources peuvent fonder une réponse.
Action : classer documents, versions, dates, langues, propriétaires et droits.
Résultat attendu : registre d’autorité et règle de priorité.
Erreurs à éviter : indexer toutes les versions sans métadonnées ; supposer que le document le plus proche est le plus fiable.
Étape 2 — Annoter les questions et passages attendus
Objectif : préparer l’oracle avant l’exécution.
Action : écrire questions, réponses acceptables, passages nécessaires, exclusions et comportement d’incertitude.
Résultat attendu : jeu versionné relu par le métier.
Erreurs à éviter : générer la référence avec le système évalué ; omettre les questions sans réponse.
Étape 3 — Tester l’ingestion et le découpage
Objectif : vérifier la présence et l’intégrité des connaissances.
Action : comparer inventaire source/index, inspecter les fragments et rechercher les règles coupées.
Résultat attendu : couverture documentaire et défauts de parsing identifiés.
Erreurs à éviter : commencer par ajuster les embeddings alors que le texte n’a pas été correctement extrait.
Étape 4 — Mesurer la récupération seule
Objectif : isoler le moteur de recherche.
Action : exécuter les requêtes, calculer rappel, précision, rang et violations de filtres.
Résultat attendu : erreurs de recherche localisées.
Erreurs à éviter : juger la recherche depuis la réponse finale ; oublier les métadonnées et autorisations.
Étape 5 — Inspecter le contexte augmenté
Objectif : confirmer ce que le modèle a réellement reçu.
Action : enregistrer les identifiants, passages, ordre, transformations et troncatures.
Résultat attendu : contexte reproductible et autorisé.
Erreurs à éviter : journaliser des données sensibles sans masquage ; cacher les conflits au modèle.
Étape 6 — Évaluer la réponse et les citations
Objectif : mesurer l’usage des preuves.
Action : vérifier faits, fidélité, complétude, refus et support de chaque citation.
Résultat attendu : diagnostic génération distinct du diagnostic récupération.
Erreurs à éviter : accepter une réponse correcte qui utilise un document interdit ; noter uniquement le style.
Étape 7 — Tester sécurité, charge et régressions
Objectif : valider le comportement en exploitation.
Action : tester isolation, empoisonnement, injection indirecte, volumétrie, latence, coût et changements d’index.
Résultat attendu : limites, alertes et critères de déploiement documentés.
Erreurs à éviter : limiter la recette aux questions nominales ; ne pas rejouer le jeu après réindexation.
Exemple hypothétique 1 — Assistant de procédures QA
La base contient une procédure actuelle v3, une version v2 obsolète et une FAQ. La question demande qui approuve une release critique.
Le moteur récupère v2 en première position et v3 en troisième. La réponse cite v2 et donne un ancien rôle. Le défaut principal est la gestion de version et le classement, même si la génération a fidèlement utilisé le premier passage.
La correction ajoute un filtre de statut, une priorité de version et un cas de non-régression. Le test vérifie la récupération de v3, l’exclusion de v2, la réponse attendue et la citation exacte.
Exemple hypothétique 2 — Bonne récupération, mauvaise synthèse
Deux passages correctement récupérés indiquent qu’un remboursement est possible sous certaines conditions et qu’une exception s’applique aux cartes expirées. Le modèle résume « tous les paiements sont remboursables ».
La récupération passe ; la fidélité de génération échoue. La mesure peut renforcer l’instruction de citer les conditions et utiliser une table structurée, mais le cas doit rester dans le jeu. Augmenter le nombre de documents récupérés ne corrigerait pas nécessairement le raisonnement.
Exemple hypothétique 3 — Fuite d’autorisation
Un utilisateur du projet A demande un terme présent uniquement dans un document du projet B. Le moteur retourne ce document, mais le générateur répond qu’il ne peut pas divulguer la source.
Le système échoue malgré le refus final : le passage interdit a été récupéré et transmis au modèle. Le filtre d’autorisation doit s’appliquer avant ou pendant la recherche. Le test examine les identifiants du contexte, pas seulement le texte affiché.
Risques de sécurité propres aux vecteurs et au RAG
La catégorie OWASP LLM08:2025 Vector and Embedding Weaknesses décrit notamment :
- accès non autorisé et fuite de données ;
- fuite entre contextes ou clients ;
- conflits de connaissances ;
- inversion d’embeddings ;
- empoisonnement des données ;
- altération du comportement du système.
Les mesures recommandées incluent contrôles d’accès fins, validation des sources, classification des données et journalisation des récupérations. Un document peut aussi contenir une injection indirecte : le contenu récupéré doit être traité comme donnée non fiable, pas comme instruction.
Erreurs fréquentes lors du test d’un RAG
Évaluer uniquement la réponse finale
Une bonne réponse peut venir des connaissances internes du modèle malgré une récupération vide. Testez les passages et imposez l’ancrage lorsque le produit l’exige.
Utiliser seulement des questions faciles
Ajoutez synonymes, exceptions, versions, contradictions, questions sans réponse et droits différents.
Confondre similarité et pertinence
Un passage lexicalement proche peut être inutile ou obsolète. L’annotation métier reste nécessaire.
Oublier le contexte réellement envoyé
Le reclassement ou la troncature peut retirer le passage pertinent après une bonne recherche. Enregistrez la chaîne complète.
Réindexer sans test de non-régression
Un nouveau découpage, modèle d’embedding ou corpus peut modifier tous les rangs. Rejouez les mêmes questions et contrôles d’accès.
Conclusion
Un RAG fiable se teste comme une chaîne, pas comme une boîte noire. Mesurez d’abord l’ingestion et la récupération, inspectez le contexte autorisé, puis évaluez fidélité, citations et refus. Ajoutez sécurité et performance avant chaque réindexation importante. Pour bâtir un benchmark sur votre base documentaire, vous pouvez demander un plan de test RAG.