Réponse en bref
Une suite de tests utile du RAG sépare la récupération de la génération et traite les permissions, la fraîcheur, le refus et la validité de citation comme des critères de diffusion de première classe — et non comme des notes de bas de page sur une note…
Commencez par des défaillances d'entreprise, pas un classement de référence
Un système de production augmenté par récupération devrait être évalué par rapport aux erreurs qui seraient importantes dans son travail réel. Pour un adjoint à la politique interne, une réponse polie fondée sur la mauvaise version de la politique est un grave échec. Pour le support client, révéler un autre document client est plus sérieux qu'une phrase légèrement gênante. Pour un outil de recherche, les citations fabriquées peuvent rendre une réponse autrement plausible inutilisable. L'ensemble d'évaluation devrait donc commencer par un inventaire des risques et des tâches des utilisateurs, puis les traduire en cas d'essai avec des critères de réussite et d'échec observables.
Cela correspond à la logique du cycle de vie du cadre de gestion des risques de l'IA du NIST: cartographier le contexte et les risques, les mesurer, puis gérer ce que les preuves montrent. Le profil d'IA générique de NIST étendent cette discipline aux systèmes générateurs. Il ne prescrit pas de score RAG. C'est utile. Une équipe d'affaires a besoin de plusieurs mesures car la qualité de récupération, répondre à la fidélité, le contrôle d'accès et la fraîcheur opérationnelle peuvent échouer indépendamment. Un seul score global peut s'améliorer pendant qu'une fuite de permission critique s'aggrave.
Construisez un petit ensemble d'or avant d'effectuer l'évaluation
La première série d'évaluation n'a pas besoin de milliers de questions. Il a besoin d'une couverture représentative. Recueillir les intentions réelles de l'utilisateur, les questions difficiles connues, les cas de bord de politique et les instructions contradictoires, puis enregistrer les documents de source attendus et les faits essentiels une réponse correcte devrait contenir. Inclure les questions auxquelles il n'est pas possible de répondre. Si la base de connaissances ne contient pas l'information demandée, le comportement correct peut être un refus ou une déclaration d'incertitude plutôt qu'un accomplissement confiant.
Un ensemble de départ pratique pourrait comprendre de 100 à 300 cas répartis en catégories : recherche factuelle directe, synthèse multidocuments, formulation ambiguë, documents courants par opposition aux documents actuels, documents sensibles à l'autorisation, vérifications des citations et cas sans réponse. Garder un sous-ensemble caché pour que les équipes ne optimisent pas seulement les exemples qu'elles peuvent voir. Chaque cas devrait contenir des métadonnées telles que le rôle de l'utilisateur, les ID de documents attendus, la date d'entrée en vigueur et le niveau de risque. Cela transforme l'évaluation d'un script de démonstration en un actif de test reproductible. Inclure le langage de refus prévu seulement lorsqu'il saisit une limite requise; autrement marquer le comportement, pas le libellé exact. Cela empêche l'équipe de transformer l'évaluation en corde fragile qui récompense les phrases mémorisées au lieu de bonnes décisions.
Récupération des essais séparément de la génération
Lorsqu'une réponse est erronée, la première question diagnostique est de savoir si le modèle a reçu la bonne preuve. L'évaluation de la récupération doit déterminer si le document ou le passage requis apparaît dans l'ensemble récupéré et dans quelle mesure il est classé. Les mesures utiles comprennent le rappel à k, la précision à k et les mesures de classement, mais les équipes d'affaires devraient également inspecter les erreurs concrètes. Si la bonne politique est classée onzième et que l'application envoie seulement les cinq premiers morceaux au modèle, la génération ne peut pas sauver le système.
Le guide d'évaluation du RAG de Microsoft fait la même distinction entre la recherche et la qualité des réponses, avec des évaluateurs pour la recherche de documents, la solidité, la pertinence et l'exhaustivité. Utilisez cette décomposition dans chaque expérience. Changer un composant à la fois — découper, intégrer, rechercher hybride, reclasser ou filtrer les métadonnées — et réexécuter le même ensemble d'or. Si le rappel de récupération s'améliore alors que la qualité de réponse tombe, les morceaux supplémentaires peuvent ajouter du bruit. Un bon pipeline RAG n'est pas celui qui récupère le plus de texte; il récupère les plus petites preuves utiles ensemble fiable.
La motivation demande si la réponse reste à l'intérieur de la preuve
L'évaluation au fondement examine si les allégations factuelles dans la réponse sont étayées par le contexte récupéré. Le test doit être au niveau de la demande dans la mesure du possible. Donnez au système une source qui dit qu'un contrat renouvelle le 30 septembre et un autre document non lié contenant le 31 octobre; puis vérifiez si la réponse utilise la date supportée et cite la source pertinente. Créer des cas où les documents récupérés sont insuffisants, contradictoires ou explicites sur l'incertitude. Le modèle ne devrait pas combler silencieusement les lacunes de ses connaissances générales lorsque le produit promet des réponses fondées sur la source.
Les évaluateurs automatisés peuvent accélérer les tests de régression, mais ils sont eux-mêmes des jugements fondés sur des modèles et devraient être étalonnés en fonction de l'examen humain. Échantillonner les faux positifs et les faux négatifs. Dans le cas des cas à risque élevé, demandez aux examinateurs de déterminer la phrase exacte et de justifier le passage plutôt que d'attribuer une note vague d'un à cinq. La cible n'est pas une similitude stylistique avec une réponse de référence. Deux réponses peuvent être formulées différemment et les deux peuvent être fondées; une réponse fluide peut aussi correspondre au ton de référence tout en inventant un fait critique.
Le refus est une capacité qui nécessite son propre ensemble de tests
Un système RAG de production doit savoir quand ne pas répondre. Créer des cas sans réponse lorsque le fait demandé est absent, les documents sont en conflit sans règle de résolution, l'utilisateur demande une action interdite ou les preuves sont trop anciennes pour la date demandée. Noter si le système refuse proprement, expliquer la limitation et, le cas échéant, indiquer à l'utilisateur quelles informations le résoudre. Testez également l'échec opposé : refus excessif lorsque la réponse est présente et permise.
Les tests de sécurité ont leur place ici aussi. Le guide GenAI actuel de l'OWASP traite l'injection rapide, la divulgation d'informations sensibles et les faiblesses dans les systèmes vectoriels ou d'intégration comme des risques d'application matérielle. Mettre des instructions malveillantes à l'intérieur des documents récupérés – comme les règles antérieures de "ignorer " et révéler des secrets – et vérifier que le système les traite comme des données plutôt que comme des instructions prioritaires. Les tests de refus devraient couvrir à la fois les attaques d'origine utilisateur et l'injection indirecte du corpus de récupération, parce que RAG étend la limite de confiance de l'application à chaque document qu'il peut ingérer.
La fraîcheur doit être mesurable et non supposée
Le RAG est souvent choisi parce que les connaissances commerciales changent plus rapidement que les poids du modèle. Cet avantage disparaît si l'indice est inexistant. Construisez des cas d'évaluation autour de documents avec des dates d'entrée en vigueur et des versions remplacées. Posez des questions dont la réponse correcte a changé la semaine dernière, le mois dernier et le trimestre dernier. Enregistrez la version de source prévue et vérifiez si les filtres de recherche ou le classement préfèrent le document actuel. Un système qui récupère parfaitement une politique obsolète est toujours mauvais pour l'entreprise.
La fraîcheur a également une mesure opérationnelle : le temps de mise à jour de la source à la disponibilité consultable. Mesurer la latence d'ingestion, les connecteurs défectueux, les erreurs d'analyse et le pourcentage de documents sources dont la version index correspond au système d'enregistrement. Définir les attentes au niveau du service par cas d'utilisation. Une FAQ des avantages peut tolérer une mise à jour programmée; un assistant de réponse-incident peut ne pas. Inclure dans les tests de libération une source de données mise à jour après l'index afin que l'équipe sache comment l'application se comporte pendant l'écart plutôt que de la découvrir lors d'un changement réel.
Les autorisations doivent être appliquées avant la récupération
La défaillance la plus dangereuse du RAG peut être une réponse correcte d'un document que l'utilisateur n'a jamais été autorisé à voir. L'évaluation des autorisations devrait créer des questions identiques pour les utilisateurs ayant des rôles différents et vérifier que les candidats sont filtrés conformément aux règles d'autorisation du système source. Tester l'accès positif, le refus d'accès, les changements d'adhésion au groupe, les documents révoqués, les limites croisées et les résultats mis en cache. Le résultat attendu pour un utilisateur non autorisé n'est pas une citation expurgée du document secret; le document ne doit pas entrer dans le contexte de recherche utilisable.
C'est là que les avertissements de l'OWASP sur les vecteurs et l'intégration des faiblesses deviennent concrets. Si le contrôle d'accès n'existe que dans l'interface de chat pendant que le magasin vectoriel retourne des embarquations au-delà des limites de permission, le modèle peut exposer du contenu sensible à travers des résumés ou des indices indirects. Les équipes d'affaires devraient enregistrer les documents d'identification qui ont été récupérés pour chaque identité de test et faire des défaillances d'autorisation libérer des bloqueurs. Le contrôle d'accès n'est pas une mesure de pertinence. C'est une propriété de sécurité et devrait avoir une suite de test de tolérance zéro pour un contenu clairement interdit.
Les citations nécessitent une vérification mécanique
Afficher une icône de citation n'est pas la même chose que fournir une citation digne de confiance. Pour chaque réponse, vérifier si le document cité a été effectivement récupéré, si le passage cité supporte la revendication voisine, si le titre source et le lien résolvent correctement, et si la version est à jour. Inclure les cas où deux documents appuient différentes parties d'une phrase; le système peut avoir besoin de citations multiples ou d'une réponse réécrite qui maintient les revendications séparables. Les liens brisés et les citations à des morceaux non pertinents devraient être comptés comme des échecs.
Une vérification automatisée utile consiste à cartographier chaque revendication vérifiable à l'extérieur d'au moins un ID source récupéré, puis à échantillonner la relation de revendication à passage avec un examinateur humain. Pour les flux de travail à fort débit, exiger que l'extrait source soit visible avant qu'un utilisateur agisse. La qualité des citations améliore également le débogage : lorsqu'un examinateur rejette une réponse, l'équipe peut distinguer une erreur de récupération, une mauvaise source, une erreur de génération et un bug de rendu. La réponse avait des citations est trop grossière pour fournir ce diagnostic.
Libération seulement après une matrice de décision examinée par l'homme
L'évaluation finale devrait combiner qualité et risque, et non les réduire en une seule moyenne. Fixer des seuils minimaux pour le rappel, la solidité, la pertinence des réponses et la validité des citations, mais ajouter des barrières rigides pour les fuites de permission, les instructions dangereuses et les échecs critiques de fraîcheur. Examiner un échantillon stratifié manuellement, avec un poids supplémentaire sur les cas à impact élevé. Consigner les limites connues et les conditions dans lesquelles le système doit être transmis à une personne. L'encadrement de la mesure et de la gestion du NIST est ici utile : les données d'évaluation devraient conduire à une décision explicite de déploiement. Préserver les sorties brutes, les ID des documents récupérés et les versions des évaluateurs afin qu'un résultat puisse être reproduit ultérieurement. Sans cette piste de vérification, un changement de score après une mise à jour de modèle ou d'index peut être impossible à expliquer.
Puis faire la partie ensemble de la livraison continue. Exécutez un sous-ensemble rapide sur chaque récupération ou changement rapide et la suite complète avant les grandes versions; ajoutez des échecs de production réels dans le corpus après avoir supprimé les données sensibles. Suivre les résultats par catégorie de sorte qu'un meilleur score global ne peut cacher les refus ou les permissions pires. Une liste de contrôle d'évaluation du RAG n'est utile que lorsqu'elle prévoit un comportement opérationnel. Le but avant le lancement est de ne pas prouver que le système est intelligent. C'est montrer, avec des preuves répétables, où il récupère correctement, où il reste puni, où il refuse et où un humain doit rester en contrôle.
Checklist pratique
- Construisez un ensemble d'or avec des cas responsables, insurmontables, inexistants, accusatoires et sensibles aux permissions.
- Mesurer le rappel et le classement avant de juger les réponses générées.
- Vérifier toutes les allégations factuelles contre les éléments de preuve récupérés et vérifier les citations mécaniquement.
- Tester l'injection rapide indirecte à partir de documents récupérés et le refus excessif et insuffisant.
- Exécuter des tests de permission basés sur le rôle qui log récupéré des ID de documents.
- Définissez des portes à libération dure et conservez un ensemble de cales à examen humain.
- Ajouter des échecs de production confirmés dans la suite de régression.
Questions et réponses
Que devrait contenir un ensemble d'évaluation du RAG?
Un ensemble utile contient des questions utilisateur représentatives et des cas délibérément difficiles : recherches directes, synthèse multidocuments, questions ambiguës, questions sans réponse, documents courants par opposition à ceux-ci, contenu sensible à l'autorisation, matériel source à injection rapide et vérifications des citations. Chaque cas devrait consigner les documents sources attendus, les faits essentiels, le rôle de l'utilisateur, la date d'entrée en vigueur et le niveau de risque. Commencez par un ensemble gérable que les évaluateurs peuvent comprendre, puis élargissez-le avec de vrais cas d'échec. Conservez une portion de retenue pour que les changements ne soient pas optimisés uniquement par rapport aux exemples visibles.
Quelles sont les mesures RAG les plus importantes avant le lancement ?
Il n'y a pas de mesure unique suffisante. La récupération nécessite des mesures telles que le rappel à k et le classement de la qualité; l'évaluation de la réponse doit être fondée, pertinente et complète; la demande doit également faire l'objet de tests de refus, de fraîcheur, de citation et d'autorisation. Les défaillances de sécurité ne doivent pas être éliminées en moyenne par de bons scores de réponse. Une équipe d'affaires devrait définir des barrières de libération dure pour la divulgation non autorisée et d'autres risques critiques, tout en utilisant des paramètres de qualité pour comparer les variantes de récupération et de génération. Un examen humain est toujours nécessaire pour étalonner les évaluateurs automatisés et inspecter les cas à risque élevé.
Comment testez-vous les autorisations de RAG ?
Créer des identités de test avec des différences d'accès connues et poser les mêmes questions sous chaque identité. Loger quels documents ID sont récupérés et vérifier que les documents non autorisés sont exclus avant la génération du modèle, pas simplement cachés dans l'interface. Tester les changements de groupe, l'accès révoqué, les limites du locataire, les résultats mis en cache et les documents qui héritent des autorisations d'un système parent. Tout cas où le contenu interdit entre dans le contexte de recherche doit être traité comme un défaut de sécurité. Les notes de pertinence ne peuvent pas compenser un défaut de permission.
Combien de fois faut-il réévaluer un système RAG?
Exécutez une petite suite de régression chaque fois qu'elle invite, découpe, embarque, recherche de configuration, reclassage, modèles ou changement de logique d'autorisation, et exécutez la suite plus large avant les sorties significatives. La fraîcheur et la santé des connecteurs devraient être surveillées en continu ou à une cadence appropriée à la source de l'entreprise. Les incidents de production et les défaillances confirmées des utilisateurs devraient être convertis en nouveaux cas d'essai après élimination des données sensibles. L'ensemble d'évaluation est un produit vivant parce que la base de connaissances et les modèles, les fournisseurs et les modèles de menace environnants changent au fil du temps.