Comment évaluer un système RAG : métriques de récupération, fidélité et monitoring

Évaluer un système RAG demande de séparer deux questions distinctes : la récupération a-t-elle trouvé les bons passages (recall@k, précision@k, MRR), et la réponse générée est-elle fidèle à ces passages avec des citations exactes. Un jeu de test construit à partir de vraies questions, rejoué régulièrement, permet de détecter les régressions avant qu'un utilisateur ne tombe sur une réponse fausse ou mal sourcée.

Pourquoi évaluer un RAG ne ressemble pas à évaluer un simple chatbot

Un système RAG fonctionne en deux temps : une étape de récupération qui va chercher des passages pertinents dans une base documentaire, puis une étape de génération qui rédige une réponse à partir de ces passages. Le détail de ce mécanisme est expliqué dans Comment fonctionne le RAG, étape par étape. Cette architecture en deux temps implique que l'évaluation doit, elle aussi, se faire en deux temps : une erreur de réponse peut venir d'une mauvaise récupération (le bon passage n'a jamais été trouvé) ou d'une mauvaise génération (le passage était là, mais le modèle l'a mal interprété ou a inventé un détail à côté).

Tester uniquement la réponse finale, sans regarder ce qui a été récupéré, revient à juger un élève sur sa copie sans jamais vérifier s'il avait le bon cours sous les yeux. C'est le piège le plus fréquent : on passe des heures à ajuster le prompt de génération alors que le problème vient du chunking ou de l'index de recherche, un sujet détaillé dans Chunking, indexation, recherche : comment fonctionne un pipeline RAG.

Mesurer la qualité de la récupération : recall@k, précision@k et MRR

La récupération se mesure avec des métriques classiques de recherche d'information, appliquées à un jeu de questions pour lesquelles vous connaissez à l'avance le ou les passages « corrects » (le gold standard).

En pratique, un recall@5 de 95 % avec une précision@5 de 40 % signifie que le système trouve presque toujours la bonne information, mais l'entoure de passages non pertinents qui peuvent distraire le modèle de génération ou gonfler le coût en tokens. À l'inverse, un recall@5 de 70 % indique un vrai problème de couverture : dans 30 % des cas, le système ne propose même pas au modèle de quoi répondre correctement. C'est souvent là que la recherche hybride, combinant mots-clés et vecteurs, fait la différence par rapport à une recherche purement sémantique, comme détaillé dans Recherche hybride : pourquoi combiner mots-clés et vecteurs bat chaque méthode seule.

La fidélité de la réponse : dit-elle seulement ce que disent les documents ?

La fidélité (faithfulness) mesure si chaque affirmation de la réponse générée est bien soutenue par les passages récupérés, sans ajout, extrapolation ou déduction hasardeuse. C'est une métrique différente de la « justesse » : une réponse peut être factuellement vraie dans l'absolu mais infidèle si elle invente un chiffre non présent dans les documents fournis, ou mélange une information correcte avec un détail issu des connaissances générales du modèle plutôt que du corpus.

• Découpez la réponse en affirmations unitaires et vérifiez chacune contre les passages source
• Utilisez un modèle de langage comme juge (LLM-as-judge) avec une consigne stricte : « cette affirmation est-elle déductible uniquement du texte fourni ? »
• Complétez par une relecture humaine sur un échantillon, surtout sur les sujets réglementés ou juridiques
• Testez volontairement des questions hors périmètre pour vérifier que le système répond « je ne sais pas » plutôt que d'inventer

Le dernier point est souvent négligé : un bon système RAG doit savoir refuser de répondre quand l'information n'est pas dans la base, plutôt que de combler le vide avec les connaissances générales du modèle sous-jacent. C'est l'un des leviers les plus efficaces pour limiter les hallucinations, un sujet approfondi dans Réduire les hallucinations de l'IA grâce aux réponses sourcées.

L'exactitude des citations : vérifier que chaque source existe et dit bien ça

Une réponse peut être fidèle sur le fond tout en citant la mauvaise source, ou citer un passage réel qui ne soutient pourtant pas l'affirmation qu'on lui attribue. L'exactitude des citations se mesure sur deux axes complémentaires : la précision des citations (chaque passage cité soutient-il réellement l'affirmation associée) et le rappel des citations (chaque affirmation importante est-elle bien accompagnée d'une source, ou certaines restent-elles « flottantes » sans justification).

Cette vérification peut être automatisée en comparant le texte de la citation à l'affirmation via un modèle d'entailment (le passage implique-t-il logiquement l'affirmation), mais elle gagne toujours à être spot-checkée manuellement sur un échantillon de dix à vingt réponses par semaine. La méthode complète, avec les pièges à éviter, est détaillée dans Réponses d'IA avec citations : comment vérifier une réponse sur vos documents.

Construire un jeu de test avec de vraies questions

Un benchmark générique ne vaut rien pour votre cas d'usage précis. Le jeu de test le plus utile est construit à partir de questions réellement posées : tickets de support, questions envoyées par les commerciaux, requêtes tapées dans une ancienne barre de recherche interne. L'objectif est de couvrir la diversité réelle des usages, pas seulement les questions faciles auxquelles le système répond déjà bien.

1. Collectez 50 à 150 questions réelles, réparties entre questions factuelles simples, questions nécessitant de croiser plusieurs documents et questions pièges hors périmètre
2. Faites valider les réponses attendues (gold answers) par un expert métier, avec les passages source associés
3. Catégorisez les questions par difficulté et par type de document interrogé, pour isoler les zones faibles
4. Rejouez l'intégralité du jeu à chaque changement important : nouveau découpage des documents, changement de modèle d'embeddings, mise à jour du corpus
5. Conservez les anciennes versions du jeu de test pour comparer les scores dans le temps, pas seulement à un instant T

La taille et la structure des chunks influencent directement les scores de récupération : un découpage trop grossier dilue l'information pertinente, un découpage trop fin la fragmente et complique le raisonnement du modèle. Les arbitrages à faire sont détaillés dans Stratégies de chunking pour le RAG : taille, chevauchement et découpage par structure.

Mettre en place un monitoring continu

L'évaluation ponctuelle avant mise en production ne suffit pas : un corpus documentaire évolue (nouvelles versions de contrats, mises à jour réglementaires, nouveaux produits), et une base qui répondait bien à un jeu de test en janvier peut dériver en juin si personne ne la surveille. Le monitoring continu repose sur trois réflexes simples.

• Échantillonner un pourcentage fixe des conversations réelles (par exemple 5 %) pour une revue manuelle hebdomadaire de fidélité et de citations
• Suivre dans le temps un tableau de bord avec recall@k, précision des citations et taux de refus approprié
• Déclencher une alerte quand un score chute de plus de quelques points par rapport à la moyenne mobile des quatre dernières semaines
• Rejouer automatiquement le jeu de test à chaque déploiement ou mise à jour majeure du corpus

Garder le contrôle sans construire toute la plateforme soi-même

Construire un pipeline d'évaluation complet (jeu de test versionné, métriques de récupération, revue de fidélité, monitoring automatisé) prend du temps, souvent plus que la construction initiale du RAG lui-même. Sur Kopik, chaque base de connaissances répond avec les passages cités par défaut, ce qui facilite grandement la vérification manuelle des citations sans outillage supplémentaire : vous voyez immédiatement quel passage a servi à quelle affirmation, et pouvez basculer en mode « passages seuls » pour auditer la récupération indépendamment de la génération. Interroger une base se fait depuis le site, via une API avec clés dédiées, ou via un serveur MCP utilisable depuis Claude, Cursor ou ChatGPT, ce qui permet de tester le même jeu de questions sur plusieurs canaux et de vérifier que les résultats restent cohérents.

Pour les équipes qui veulent constituer rapidement un premier jeu de test sur leurs propres documents, créer une base de connaissances à partir de PDF, Word ou fichiers texte permet d'avoir en quelques minutes un système interrogeable sur lequel rejouer ses questions, avant même de penser à l'infrastructure de monitoring.

Résumé : la checklist d'évaluation à garder sous la main

• Mesurer recall@k, précision@k et MRR sur la récupération, au k réellement utilisé en production
• Évaluer la fidélité des réponses, affirmation par affirmation, pas seulement leur justesse globale
• Vérifier l'exactitude des citations : chaque passage cité soutient-il vraiment ce qu'on lui fait dire
• Construire un jeu de test à partir de vraies questions, avec des cas hors périmètre volontaires
• Rejouer ce jeu à chaque changement de corpus, de chunking ou de modèle
• Mettre en place un échantillonnage régulier des conversations réelles, pas seulement des tests hors ligne

Pour revenir sur les bases du fonctionnement d'un RAG avant de s'attaquer à son évaluation, le guide Qu'est-ce que le RAG (génération augmentée par récupération) ? pose les fondamentaux utiles à toute démarche de test sérieuse.