Pour mesurer la performance d'un RAG, on pose à l'assistant un jeu de 20 à 50 questions dont on connaît la réponse, puis on note chaque réponse de façon binaire : juste, complète, fausse. On obtient un pourcentage, que l'on rejoue à chaque évolution du système. Un RAG basique répond correctement à environ 50 à 70 % des questions.
C'est la première question que je pose en mission : « Comment mesurez-vous la performance de votre RAG ? ». En général, l'entreprise n'a pas de réponse chiffrée. Cet article explique pourquoi c'est si fréquent, ce que révèle une première mesure sur des projets réels, et les cinq questions à poser à votre équipe ou à votre prestataire.
En bref
- Un RAG basique répond juste à environ 50 à 70 % des questions, et la première mesure surprend souvent
- On mesure en binaire : réponse juste, réponse complète, réponse fausse. Pas de note de 1 à 5
- 20 à 50 questions suffisent pour démarrer, dès les 2 ou 3 premiers jours
- La mesure se rejoue à chaque évolution, sinon on ne sait pas si l'on progresse ou si l'on régresse
- La cause la plus fréquente d'un mauvais score est un bug dans la chaîne de traitement, pas le modèle de langage
La première question qu'on pose en mission, et ce qu'on nous répond
En mission d'amélioration, la première question que je pose est toujours la même : « Comment mesurez-vous la performance de votre RAG ? ». En général, l'entreprise ne sait pas répondre. Ce n'est pas un reproche : c'est le constat le plus fréquent sur la vingtaine de RAG que j'ai construits, améliorés ou audités.
Les réponses se ressemblent d'une entreprise à l'autre :
- « Comment on fait pour mesurer ? »
- « Non, pas vraiment. »
- « On pose quelques questions. » Parfois toujours les trois mêmes, à chaque nouvelle version.
Le vrai problème n'est pas l'absence de score au lancement. C'est que l'évaluation n'est ni faite ni suivie au moment des évolutions et des nouvelles fonctionnalités. Résultat : impossible de dire si l'assistant s'améliore ou s'il régresse. Votre ressenti (« il répond moins bien qu'avant ») ne se corrige pas, parce qu'il ne se chiffre pas.
Pourquoi si peu de RAG sont mesurés : la difficulté est réelle
La plupart des RAG que nous reprenons ont été construits par l'équipe interne, par un stagiaire ou par une équipe junior, sur la foi de démos simples. C'est un cadrage naturel : on trouve en quelques heures des tutoriels qui donnent un assistant capable de répondre à une question sur trois documents.
L'écart apparaît ensuite. Un stagiaire est là pour apprendre, et ce type de projet le dépasse souvent, malgré les démos qu'on voit sur internet. Une ESN peut aussi staffer des profils juniors sans connaissance précise du sujet. Personne n'a mal fait son travail : le sujet est plus difficile que la démo ne le laisse croire.
Ce qui change tout, c'est que la démo teste des questions choisies pour marcher. Au quotidien, vos utilisateurs posent des questions imprécises, sur des centaines de documents, avec des tableaux, des schémas, des doublons et des PDF délicats. Sans jeu de questions représentatif, personne ne voit l'écart entre les deux.
Ce qu'on constate
Un assistant qui impressionne en démonstration et déçoit à l'usage n'est pas un cas rare. C'est la situation de départ de la plupart des missions d'amélioration. Voir aussi notre guide du RAG en entreprise pour le panorama complet.
Ce que montre la première mesure : des chiffres qui surprennent
Un RAG basique répond correctement à environ 50 à 70 % des questions. Le résultat de la première mesure surprend régulièrement le client : l'impression donnée par quelques questions testées à la main est rarement celle que donne un jeu de questions représentatif.
C'est après ce palier que ça se complique. Le plus souvent, les premières corrections portent sur des bugs de la chaîne de traitement, pas sur le modèle :
- un modèle d'embeddings différent à l'indexation et à la recherche, ce qui fausse toute la recherche ;
- un seul passage extrait par mégarde, au lieu de plusieurs ;
- une recherche qui ne tient compte que du dernier message, et non de toute la conversation.
Après ces premières corrections, voici les trajectoires que nous avons observées, en ordres de grandeur :
| Cas observé | Avant corrections | Après les premières corrections |
|---|---|---|
| Un premier projet | Environ 30 % de réponses justes | Environ 70 % |
| Un deuxième projet | Environ 50 % de réponses justes | Environ 70 % |
| Cas d'usage complexes | Environ 20 % de réponses justes | Environ 50 % |
Le deuxième enseignement : sur les cas complexes, un score de 50 % après correction peut être un vrai progrès. Ce qui compte n'est pas un seuil universel, mais l'écart entre votre point de départ et votre cible, au regard du risque d'une réponse fausse dans votre métier.
Ce qu'on mesure : bonne, complète, fausse, en binaire
Nous mesurons trois pourcentages : le taux de réponses justes, le taux de réponses complètes et le taux de réponses fausses, chacun en notation binaire. Pas de note de 1 à 5, peu pertinente : deux relecteurs ne mettent pas le même 3, et un 3 ne dit pas ce qu'il faut corriger.
| Mesure | Question posée | Exemple de verdict |
|---|---|---|
| Réponse juste | Le contenu de la réponse est-il exact par rapport au document source ? | Oui ou non |
| Réponse complète | Tous les éléments attendus sont-ils présents ? | Oui ou non |
| Réponse fausse | La réponse contredit-elle la source ou invente-t-elle un élément ? | Oui ou non |
Pourquoi trois mesures et pas une seule ? Une réponse peut être juste mais incomplète (elle cite une condition sur deux). Une réponse peut aussi être fausse avec aplomb, ce qui est le cas le plus coûteux pour l'entreprise. Séparer les trois permet de savoir quoi corriger en priorité.
Cette méthode donne un pourcentage de performance dès le début du projet. C'est la base de notre façon de travailler : des sprints d'un mois avec des objectifs précis et des livrables, et l'évaluation au centre. Je le résume ainsi : « Je ne promets pas la lune, mais une procédure scientifique, qui a fait ses preuves, avec l'évaluation au centre. »
Pour la mécanique technique (métriques RAGAS, jeux de questions synthétiques), les articles de mon blog technique détaillent le protocole d'évaluation d'un RAG en production et la construction du jeu de questions.
Combien de questions, et quand les mesurer
Il faut démarrer avec 20 à 50 questions, prêtes dès les 2 ou 3 premiers jours du projet. Pas besoin de centaines : le but est d'avoir un premier score fiable pour orienter le travail, pas un benchmark académique.
Comment constituer le premier jeu
Demandez à trois ou quatre utilisateurs réels de lister les questions qu'ils posent vraiment, avec la réponse attendue et le document où elle se trouve. Mélangez des questions simples, des questions sur plusieurs documents et quelques questions piégeuses où la bonne réponse est « l'information n'existe pas ».
Comment il grossit
Pendant les tests, toutes les questions des utilisateurs sont reprises dans l'évaluation. Le jeu s'empile ainsi de lui-même et devient représentatif de l'usage réel, bien plus que ce qu'on aurait imaginé au départ. C'est aussi pour cette raison que nous mettons en place, très tôt, un système de collecte des retours des utilisateurs test.
À quel moment rejouer la mesure
À chaque évolution : changement de modèle, nouvelle source, nouvelle fonctionnalité, modification du découpage des documents ou de la recherche. Sans mesure à chaque évolution, on ne sait pas si une modification améliore ou dégrade l'assistant. Une amélioration sur un cas peut en dégrader d'autres, et seul le rejeu complet le montre. Sur un assistant en service, le même rejeu détecte la dérive décrite dans notre article sur la maintenance d'un RAG en production.
Cinq questions à poser à votre équipe ou à votre prestataire
Ces cinq questions permettent de savoir en une réunion où en est votre RAG. Si les réponses sont floues, c'est déjà une information.
- Quel est le pourcentage de réponses justes aujourd'hui ? Un chiffre, une date, un jeu de questions identifié.
- Sur combien de questions est-il calculé, et d'où viennent-elles ? Idéalement, des questions réelles d'utilisateurs, pas seulement celles de l'équipe projet.
- Que se passe-t-il quand on modifie le système ? La mesure est-elle rejouée à chaque évolution, avec comparaison à la version précédente ?
- Où sont les réponses fausses ? Sur quels types de documents ou de questions le score est-il le plus bas (tableaux, schémas, questions multi-documents) ?
- Les réponses sont-elles sourcées ? Un utilisateur peut-il remonter au document pour vérifier ? C'est une proposition que je fais souvent, car elle rend la fiabilité vérifiable au quotidien.
Si deux de ces cinq réponses manquent, vous avez probablement un RAG non mesuré. La suite logique est de poser un premier score, puis de corriger dans l'ordre. Nous détaillons cet ordre sur un projet réel dans l'ordre des étapes pour améliorer un RAG.
Faire mesurer votre RAG
Si votre assistant existe mais que personne ne sait dire à quel point il répond juste, la première étape est un score chiffré sur vos propres documents et vos propres questions. C'est le point de départ de notre audit RAG et agents IA, sur devis selon le périmètre.
Questions fréquentes sur la performance d'un RAG
Articles recommandés
- Évaluer un RAG en production avec RAGAS : les métriques et le protocole côté technique.
- Les mauvais réflexes des équipes RAG : les pièges classiques quand on corrige sans mesurer.
- Améliorer un RAG : l'ordre des étapes sur un cas réel : de la première mesure aux corrections successives.
- Maintenir un RAG en production : surveiller la dérive après la mise en service.
