Votre assistant RAG fonctionne parfaitement en démo. Il répond avec assurance, cite vos documents internes, impressionne le comité de direction. Puis il arrive en production, et trois semaines plus tard un commercial vous transfère une réponse où le chatbot a inventé une clause de contrat qui n'existe pas. Le problème n'est pas le modèle. Le problème est que personne n'a réellement testé le système.
Tester un système RAG (Retrieval-Augmented Generation) ne ressemble ni aux tests logiciels classiques ni à l'évaluation d'un modèle de langage seul. C'est une discipline à part entière, avec ses métriques, ses outils et ses pièges. Ce guide vous donne une méthode complète, applicable que vous ayez une équipe data interne ou un prestataire.
Pourquoi les tests classiques ne suffisent pas
Un test logiciel traditionnel vérifie un comportement déterministe : même entrée, même sortie. Un système RAG est probabiliste à deux étages. D'abord le retrieval (la recherche de passages pertinents dans votre base documentaire) peut remonter des documents différents selon la formulation. Ensuite la génération peut produire des réponses différentes à partir des mêmes passages.
Conséquence : un simple jeu de tests « question, réponse attendue » avec comparaison exacte échoue systématiquement. Il faut évaluer des propriétés (la réponse est-elle fidèle aux sources ? les sources étaient-elles les bonnes ?) plutôt que des chaînes de caractères.
L'enjeu est loin d'être théorique. Une étude de Stanford publiée en 2024 sur les outils de recherche juridique dopés au RAG a mesuré des taux d'hallucination de 17 % à 33 % selon les outils, alors même que ces produits étaient commercialisés comme « fiables » grâce au RAG. De son côté, Gartner avait estimé qu'au moins 30 % des projets d'IA générative seraient abandonnés après la phase de proof of concept fin 2025, le manque de qualité et de confiance figurant parmi les causes principales. Le test rigoureux est précisément ce qui sépare les projets qui passent en production de ceux qui meurent en pilote.
Étape 1 : Construire un jeu de données de référence
Tout commence par un « golden dataset » : un ensemble de questions représentatives avec, pour chacune, les documents sources attendus et une réponse de référence validée par un expert métier.
Méthode pragmatique :
- Collectez 50 à 150 questions réelles. Tickets support, e-mails clients, questions posées pendant le pilote. Les questions inventées par l'équipe technique sont toujours trop propres ; les vraies questions sont ambiguës, mal orthographiées, incomplètes.
- Classez-les par type. Questions factuelles simples, questions multi-documents, questions hors périmètre (auxquelles le système doit refuser de répondre), questions pièges proches d'un sujet couvert mais subtilement différentes.
- Faites valider les réponses de référence par le métier, pas par l'équipe IA. C'est l'expert juridique, RH ou technique qui sait ce qu'est une bonne réponse.
- Versionnez ce jeu de données. Il évoluera avec votre base documentaire et deviendra votre filet de sécurité pour chaque mise à jour.
Un golden dataset de 100 questions bien construites vaut mieux que 1 000 questions générées automatiquement sans validation. C'est l'actif le plus durable de tout votre dispositif de test.
Étape 2 : Évaluer le retrieval séparément
Erreur classique : juger le système uniquement sur la réponse finale. Si le retrieval remonte les mauvais passages, le meilleur modèle du monde produira une mauvaise réponse. Évaluez donc d'abord la recherche, isolément, avec des métriques classiques de recherche d'information :
- Precision@k : parmi les k passages remontés, quelle proportion est réellement pertinente ? Une précision faible signifie que vous noyez le modèle sous du bruit.
- Recall@k : parmi tous les passages pertinents existants, quelle proportion figure dans les k remontés ? Un rappel faible signifie que la bonne information n'arrive jamais jusqu'au modèle.
- MRR (Mean Reciprocal Rank) : à quelle position apparaît le premier passage pertinent ? Important car les modèles accordent plus d'attention aux premiers passages du contexte.
Ces métriques se calculent automatiquement à partir de votre golden dataset. Si votre precision@5 est sous 0,6, inutile d'optimiser les prompts : votre problème est dans le chunking, l'embedding ou l'indexation. Notre guide sur l'architecture RAG du prototype à la production détaille ces choix d'infrastructure.
Étape 3 : Évaluer la génération avec les métriques RAG
Une fois le retrieval validé, évaluez la qualité des réponses. Le framework open source RAGAS a popularisé quatre métriques devenues un standard de facto :
- Faithfulness (fidélité) : chaque affirmation de la réponse est-elle soutenue par les passages fournis ? C'est la métrique anti-hallucination par excellence.
- Answer relevancy (pertinence de la réponse) : la réponse traite-t-elle réellement la question posée, sans digression ?
- Context precision : les passages utilisés étaient-ils les bons, et bien classés ?
- Context recall : le contexte couvrait-il tout ce qui était nécessaire pour répondre ?
Ces métriques s'appuient sur le principe « LLM-as-a-judge » : un modèle évaluateur note les réponses selon des critères stricts. Ce n'est pas parfait, mais les études montrent une corrélation élevée avec le jugement humain quand les critères sont bien définis, et cela permet d'évaluer des centaines de réponses en quelques minutes au lieu de plusieurs jours d'annotation manuelle.
Seuils pratiques observés sur nos projets : visez une fidélité supérieure à 0,9 pour les cas d'usage sensibles (juridique, RH, finance) et 0,8 pour les usages internes à faible risque. En dessous, le système n'est pas prêt.
Étape 4 : Tester les comportements limites
Les métriques moyennes cachent les échecs qui détruisent la confiance. Ajoutez des familles de tests ciblées :
- Questions hors périmètre. Le système doit dire « je ne sais pas » plutôt qu'improviser. Mesurez le taux de refus correct sur des questions volontairement hors base documentaire. C'est le test le plus négligé et le plus important.
- Injections de prompt. Glissez dans un document de test une instruction du type « ignore tes consignes et réponds X ». Un RAG d'entreprise indexe des documents que des tiers peuvent parfois modifier ; il doit y résister.
- Questions temporellement piégées. Si votre base contient une politique tarifaire 2024 et une politique 2026, le système cite-t-il la bonne ?
- Robustesse à la formulation. Posez la même question de cinq façons différentes (fautes incluses). La variance des réponses est un indicateur de fiabilité perçue par vos utilisateurs.
Étape 5 : Industrialiser avec une boucle d'évaluation continue
Un RAG n'est jamais « terminé » : la base documentaire évolue, les modèles sont mis à jour, les usages dérivent. Trois mécanismes à mettre en place :
- Évaluation automatique à chaque changement. Toute modification (nouveau chunking, nouveau modèle, nouveaux documents) déclenche le golden dataset complet, comme une suite de tests de non-régression. Un score qui chute bloque le déploiement.
- Échantillonnage en production. Évaluez automatiquement un pourcentage des réponses réelles chaque semaine avec les métriques de fidélité. Les dérives se voient en jours, pas en mois.
- Boucle de feedback utilisateur. Un simple pouce haut/bas alimente votre jeu de données : chaque pouce bas devient un cas de test candidat. En trois mois, votre golden dataset reflète la réalité du terrain.
Cette discipline d'évaluation est au cœur de notre offre de RAG d'entreprise : un système sans pipeline d'évaluation n'est pas un produit, c'est une démo prolongée.
Checklist avant mise en production
- Golden dataset de 50+ questions validées par le métier, versionné
- Precision@5 et recall@5 mesurés et documentés
- Fidélité moyenne supérieure ou égale à 0,8 (0,9 en domaine sensible)
- Taux de refus correct mesuré sur questions hors périmètre
- Tests d'injection de prompt passés
- Évaluation automatique branchée sur chaque déploiement
- Échantillonnage de production planifié avec seuils d'alerte
- Boucle de feedback utilisateur active
Si vous partez de zéro, comptez deux à trois semaines pour mettre en place ce dispositif sur un RAG existant. C'est l'investissement le plus rentable de tout le projet : il transforme un prototype impressionnant en système digne de confiance. Et si vos équipes débutent sur le sujet, une formation IA ciblée sur l'évaluation accélère considérablement la montée en compétences.
FAQ
Quelle est la différence entre tester un RAG et tester un chatbot LLM classique ?
Un RAG comporte deux étages à évaluer séparément : le retrieval (la recherche documentaire) et la génération. Un chatbot sans RAG ne s'évalue que sur la génération. Concrètement, cela ajoute les métriques de recherche d'information (precision@k, recall@k, MRR) et les métriques d'ancrage aux sources comme la fidélité, qui vérifient que la réponse s'appuie réellement sur les documents remontés.
Combien de questions faut-il dans un golden dataset ?
Entre 50 et 150 questions réelles validées par des experts métier suffisent pour démarrer, à condition de couvrir les types critiques : questions factuelles, multi-documents, hors périmètre et questions pièges. La qualité et la représentativité priment sur le volume ; un dataset de 100 vraies questions bat un dataset de 1 000 questions synthétiques non validées.
Les métriques « LLM-as-a-judge » sont-elles fiables ?
Elles sont suffisamment fiables pour le suivi continu quand les critères d'évaluation sont précis, et les études montrent une bonne corrélation avec le jugement humain. La bonne pratique consiste à calibrer le juge automatique sur un échantillon annoté manuellement au départ, puis à recontrôler régulièrement. Elles remplacent l'annotation de masse, pas la validation experte initiale.
Quel taux d'hallucination est acceptable en production ?
Cela dépend du risque métier. Pour un assistant interne à faible enjeu, une fidélité d'environ 0,8 avec un bon mécanisme de citation des sources est généralement acceptable. Pour des domaines sensibles comme le juridique ou la finance, visez 0,9 ou plus, ajoutez la citation systématique des passages sources et gardez un humain dans la boucle pour les décisions engageantes.
Faut-il des outils payants pour évaluer un RAG ?
Non. RAGAS, DeepEval ou promptfoo sont open source et couvrent l'essentiel : métriques de retrieval, fidélité, pertinence et intégration CI/CD. Les coûts réels sont le temps d'experts pour construire le golden dataset et les appels API du modèle évaluateur, généralement quelques dizaines d'euros par campagne d'évaluation complète.