Comment évaluer un système RAG ? Les métriques qui comptent
On évalue un RAG en deux temps, avec un jeu de questions écrit avant de construire. D’abord la recherche : le bon passage arrive-t-il en tête ? Hit@K et MRR répondent. Ensuite la réponse : est-elle fidèle aux passages fournis ? La fidélité, mesurée par un modèle juge ou une relecture, répond. Sans ce jeu, aucun chiffre n’a de sens.
Pourquoi « ça a l’air bon » n’est pas une évaluation ?
Parce que celui qui regarde a choisi les questions, connaît les documents et sait ce qu’il attend. Une démonstration réussie prouve que le système peut répondre juste ; elle ne dit pas à quelle fréquence il le fait sur les questions que posent vraiment les utilisateurs. C’est la raison pour laquelle tant de prototypes s’arrêtent après la réunion.
Évaluer, c’est remplacer l’impression par une mesure qu’on peut rejouer. Et un RAG se mesure en deux endroits distincts, parce qu’il peut échouer à deux endroits distincts : il peut ne pas retrouver le bon passage, ou le retrouver et répondre à côté.
Que faut-il écrire avant de mesurer ?
Un jeu d’évaluation : une liste de questions réelles, la réponse attendue à chacune, et le document ou le passage qui la contient. Écrit avant le code, validé par les personnes qui poseront ces questions. « Avant » n’est pas un détail : un jeu écrit après coup finit par contenir les questions qui donnent raison au système.
Les questions se rangent en catégories qui correspondent à ce qui risque de rater. Sur Mnemo, mon moteur de recherche sur mes propres notes, j’ai écrit vingt requêtes en sept catégories avant de comparer deux modèles d’embeddings : noms propres rares, concepts en français, mots-clés techniques en anglais, sigles, références personnelles, procédures en français, et questions mêlant les deux langues. Ces catégories ne sont pas théoriques. Elles reprennent ce que la recherche sémantique fait le plus mal en français : un nom propre ou un sigle n’a pas de « sens » à rapprocher, et les modèles entraînés surtout en anglais y sont faibles.
Pour un corpus d’entreprise, les catégories seront d’autres : références de produits, numéros de procédure, jargon interne, questions formulées avec une faute, questions dont la réponse est dans un tableau ou une image. Ce qui compte est de les écrire à partir des questions que les utilisateurs posent aujourd’hui, pas de celles qu’on imagine.
La recherche retrouve-t-elle le bon passage ?
C’est la première mesure, et elle ne demande aucun modèle de langue : on compare la liste des passages retrouvés à celle des passages attendus.
Hit@K vaut 1 si au moins un passage attendu figure dans les K premiers résultats, 0 sinon ; on fait la moyenne sur toutes les questions. Hit@1 dit si le bon passage arrive en tête, Hit@5 s’il est au moins dans les cinq premiers, ce que l’utilisateur ou le modèle verra. MRR, le rang réciproque moyen, affine : il vaut 1 divisé par le rang du premier passage attendu, donc 1 s’il est premier, 0,5 s’il est deuxième, 0 s’il est absent. Un système qui met souvent le bon passage en deuxième position a un Hit@5 parfait et un MRR médiocre.
Voici les deux rapports de Mnemo, produits par le même script le 27 mai 2026, avant et après le changement de modèle d’embeddings, sur les mêmes vingt requêtes. Le code, les requêtes et les rapports sont dans le dépôt public.
| Catégorie (nombre de requêtes) | Hit@1 avant | Hit@1 après | MRR avant | MRR après |
|---|---|---|---|---|
| Noms propres rares (3) | 0 % | 100 % | 0,048 | 1,000 |
| Sigles (3) | 0 % | 100 % | 0,111 | 1,000 |
| Références personnelles (3) | 0 % | 100 % | 0,233 | 1,000 |
| Concepts en français (3) | 67 % | 100 % | 0,667 | 1,000 |
| Mots-clés techniques en anglais (3) | 33 % | 67 % | 0,500 | 0,667 |
| Procédures en français (3) | 67 % | 67 % | 0,833 | 0,778 |
| Deux langues mêlées (2) | 50 % | 100 % | 0,750 | 1,000 |
| Total (20) | 30 % | 90 % | 0,434 | 0,917 |
| Score moyen du premier résultat | 0,703 | 0,636 |
Trois catégories passent de zéro à cent pour cent : exactement celles qui échouaient. Une requête rate encore après le changement, « Docker Compose », un mot-clé anglais que le nouveau modèle relie à d’autres notes techniques que celles attendues. Une catégorie recule légèrement en MRR, les procédures en français, où un passage attendu est descendu de la deuxième à la troisième place. Un rapport honnête montre les deux.
Le détail par catégorie est ce qui rend la mesure utile. Un total de 90 % ne dit pas quoi corriger ; « les sigles sont à zéro » le dit.
Pourquoi le score de similarité est-il un piège ?
La dernière ligne du tableau va dans le sens inverse de toutes les autres. Le score de similarité moyen du premier résultat, ce nombre entre 0 et 1 que renvoie toute base vectorielle, a baissé de 0,703 à 0,636 pendant que la justesse triplait.
Un tableau de bord qui afficherait ce score aurait signalé une régression au moment précis où le système devenait le plus utile. La raison est simple : le score mesure la confiance du modèle d’embeddings dans un rapprochement, pas la justesse du résultat. Un modèle qui discrimine mal donne des scores serrés et élevés à tout, y compris au bruit ; un modèle qui discrimine bien donne des scores plus bas en moyenne et un écart plus net entre le passage pertinent et les autres. Sur Mnemo, les scores du premier modèle se tenaient entre 0,60 et 0,75 pour tout, pertinent ou non ; c’est ce resserrement qui aurait dû alerter, pas la valeur.
La conséquence pratique : ne pilotez jamais un système de recherche au score brut, et ne fixez jamais un seuil de score comme critère de qualité sans l’avoir confronté à un jeu d’évaluation. Le seul juge est la position du bon passage dans la liste.
La réponse est-elle fidèle aux passages ?
Deuxième mesure, une fois la recherche validée : le modèle qui rédige la réponse s’en tient-il aux passages qu’on lui a fournis ? C’est ici qu’un RAG invente, quand il complète un passage incomplet avec ce qu’il croit savoir.
Le cadre de référence est Ragas, proposé en septembre 2023, qui évalue un RAG sans annotation humaine en faisant juger la réponse par un modèle de langue. Sa métrique centrale, la fidélité, se calcule ainsi selon sa documentation : la réponse est découpée en affirmations, chaque affirmation est vérifiée contre les passages fournis, et le score est le nombre d’affirmations soutenues divisé par le nombre total. Une réponse à 0,6 contient deux affirmations sur cinq que rien dans les sources ne justifie. La pertinence de la réponse, autre métrique du même cadre, vérifie qu’elle répond à la question posée et pas à une autre. La précision de contexte rejoint la première mesure, en vérifiant que les passages pertinents sont classés avant les autres.
Un modèle juge évalue vite et sur beaucoup de questions, ce qu’aucune équipe ne fera à la main. Mais il juge avec ses propres biais et se trompe parfois dans le même sens que le modèle jugé. La pratique raisonnable combine les deux : un juge automatique sur l’ensemble du banc à chaque changement, et une relecture humaine sur un échantillon, dix à vingt réponses, à intervalle régulier. Si les deux divergent, c’est le juge qu’on recalibre.
Combien de questions faut-il, et que vaut un chiffre sur vingt ?
Les 90 % de Mnemo, c’est dix-huit requêtes sur vingt. Sur un échantillon de cette taille, l’intervalle de confiance est large ; le même système mesuré sur deux cents questions donnerait un autre chiffre, probablement plus bas. Le corpus est le mien, les questions sont les miennes, personne d’autre ne les a validées. Ce que ce chiffre démontre, ce n’est pas un niveau de performance transposable, c’est qu’on peut décider sur une mesure plutôt que sur une impression.
Pour une entreprise, trente à cinquante questions validées par les utilisateurs forment un premier banc raisonnable : assez pour que chaque catégorie compte plusieurs questions, assez peu pour être écrit et relu en quelques heures. Le banc grandit ensuite avec les questions réelles que les utilisateurs posent et que le système rate.
Une leçon que j’ai apprise en construisant le banc de Mnemo : quand le système remonte en tête des passages pertinents qui ne figurent pas dans la référence, ce n’est pas le système qui rate, c’est l’évaluation qui est trop étroite. Il faut alors corriger la référence, pas le système. Un jeu d’évaluation est un objet vivant, et ses erreurs comptent autant que celles du modèle.
Comment faire vivre l’évaluation après la mise en production ?
Le banc ne sert pas qu’à choisir un modèle au départ. Il sert à chaque changement : nouveau découpage des documents, nouvel embedding, nouveau modèle de rédaction, nouvelle version imposée par un fournisseur d’API. Sur Mnemo, chaque exécution du script laisse un rapport daté dans le dépôt, avec les métriques globales, par catégorie et par requête, et la liste des échecs avec ce qui était attendu et ce qui est sorti. Deux rapports côte à côte suffisent à dire si un changement a aidé.
En production, cela devient une routine : rejouer le banc avant d’accepter une modification, un seuil d’alerte sur Hit@K et sur la fidélité, un échantillon de réponses réelles relu chaque mois par une personne du métier, et les questions ratées qui rejoignent le banc. Ce n’est pas de la mesure pour la mesure : c’est ce qui permet de répondre à une direction qui demande « est-ce que ça marche encore ? » autrement que par « je crois ».
Écrire ce jeu d’évaluation avec vos utilisateurs est le premier livrable d’un cadrage, et il reste utile même si vous ne poursuivez pas avec moi. Si vous avez un système en place dont personne ne sait dire s’il répond juste, ou un projet qui commence, décrivez votre cas d’usage : la première question portera sur les questions.