Le problème avec l’évaluation d’un système RAG, c’est qu’il n’existe pas de benchmark universel qui dise si votre assistant répond correctement à vos utilisateurs. Vous pouvez obtenir d’excellents scores sur des jeux de données publics et produire des réponses médiocres sur vos propres cas, parce que vos documents, vos questions et vos attentes n’ont rien à voir avec ceux du benchmark. La seule évaluation qui compte est celle qui ressemble à votre usage réel.
Cela pose une difficulté immédiate : comment mesurer la qualité d’un système sans disposer d’un étalon fiable ? La réponse, c’est de construire soi-même cet étalon. Un jeu de test représentatif, constitué de vraies questions posées sur vos documents, avec des réponses attendues et des critères de jugement explicites, est la base de toute démarche d’évaluation sérieuse. Sans lui, chaque amélioration est un pari, et chaque régression passe inaperçue.
Construire ce jeu de test demande du travail, mais c’est un travail qui se rentabilise très vite. Il transforme l’évaluation d’un exercice subjectif, où chacun défend son intuition, en une mesure objective et reproductible. Cet article explique comment constituer un jeu de test représentatif, quels pièges éviter, et comment l’utiliser pour piloter l’amélioration de votre RAG.
Pourquoi un jeu de test générique ne suffit pas
Les jeux de test publics mesurent des capacités générales : retrouver un passage, synthétiser une réponse, respecter un format. Ils sont utiles pour comparer des modèles entre eux, mais ils ne disent rien de votre cas précis. Votre RAG travaille sur vos documents, avec votre vocabulaire métier, et répond à des questions qui ont une structure particulière : des questions de procédure, des questions de comparaison, des questions qui exigent de croiser plusieurs sources.
Le décalage se voit surtout sur les cas limites. Un jeu public ne contient pas vos acronymes, vos cas particuliers, ni les pièges de votre domaine. Résultat : un système peut passer de « très bon » sur le benchmark à « inutilisable » chez vous sans que les métriques ne bougent. À l’inverse, un système médiocre sur le benchmark peut être parfaitement adapté à votre corpus restreint.
La conclusion est simple : le jeu de test doit être construit à partir de votre usage, pas importé d’ailleurs. Les benchmarks publics gardent une utilité pour la sélection initiale des modèles, mais l’évaluation continue de votre RAG doit reposer sur des questions qui vous ressemblent.
Collecter de vraies questions
La première source d’un jeu de test représentatif, ce sont les vraies questions que vos utilisateurs posent. Les journaux de votre système, les tickets de support, les échanges avec les équipes : tout ce qui documente les questions réellement posées est de l’or. Ces questions ont une distribution que vous devez reproduire, car c’est elle qui définit ce que « bien répondre » veut dire chez vous.
Collectez ces questions sur une période suffisante pour couvrir la variété des usages. Une semaine de questions peut suffire à identifier les grands types, mais plusieurs semaines donnent une meilleure couverture des cas rares. Classez ensuite les questions par catégorie : questions factuelles, questions de procédure, questions de comparaison, questions qui nécessitent plusieurs documents. Chaque catégorie doit être représentée dans le jeu de test à hauteur de sa fréquence réelle.
Cette collecte révèle souvent des surprises. Les utilisateurs posent des questions que vous n’aviez pas anticipées, dans des formulations plus relâchées, avec des implicites que le système doit deviner. Un jeu de test construit uniquement à partir de questions « idéales » passe à côté de cette réalité, et vous évaluez alors un système qui répond bien aux questions que personne ne pose.
Définir les réponses attendues
Une fois les questions collectées, il faut définir pour chacune ce qu’est une bonne réponse. C’est l’étape la plus coûteuse, mais aussi la plus importante, car elle conditionne toute la mesure. Pour chaque question, vous devez préciser ce que la réponse doit contenir, ce qu’elle doit citer comme source, et ce qui constituerait une erreur.
La réponse attendue peut prendre plusieurs formes. Pour une question factuelle, c’est une valeur ou une affirmation précise. Pour une question de procédure, c’est une séquence d’étapes correctes. Pour une question de comparaison, c’est l’ensemble des critères pertinents. L’important est que la réponse attendue soit suffisamment explicite pour qu’un évaluateur, humain ou automatique, puisse décider sans ambiguïté si une réponse produite est correcte ou non.
Définir ces réponses attendues demande de l’expertise métier. C’est le moment de mobiliser les personnes qui connaissent le domaine, car elles savent ce qu’une réponse acceptable doit contenir. Ce travail, bien qu’exigeant, constitue un capital durable : il documente la connaissance du domaine et sert de référence à toutes les évaluations futures.
Couvrir les cas difficiles
Un jeu de test qui ne contient que des questions faciles donne une fausse impression de performance. Il faut intégrer délibérément les cas difficiles : les questions ambiguës, les questions dont la réponse est répartie sur plusieurs documents, les questions auxquelles votre corpus ne permet pas de répondre, et les questions pièges qui testent la capacité du système à ne pas inventer.
Les cas de non-réponse sont particulièrement importants. Un RAG qui invente une réponse quand le corpus ne contient pas l’information est plus dangereux qu’un RAG qui admet ne pas savoir. Votre jeu de test doit donc contenir des questions dont la bonne réponse est « l’information n’est pas disponible dans les documents », pour vérifier que le système sait s’abstenir.
Les questions multi-documents testent la capacité à croiser les sources. Une question dont la réponse exige de combiner un tarif trouvé dans un document avec une condition trouvée dans un autre est un excellent test de la qualité de la recherche et de la synthèse. Ces cas sont plus difficiles à constituer, mais ils sont ceux qui révèlent le plus les faiblesses d’un système.
Mesurer ce qui compte vraiment
Avec un jeu de test en main, la question des métriques se pose. Les métriques classiques, comme la similarité sémantique entre la réponse produite et la réponse attendue, donnent une première approximation, mais elles ne capturent pas tout. La fidélité à la source, la présence des éléments clés et la qualité de la citation sont des dimensions qui demandent des vérifications plus ciblées.
Une approche pragmatique consiste à combiner des vérifications automatiques et des jugements humains. Les vérifications automatiques passent en premier : elles sont rapides, reproductibles et détectent les régressions grossières. Les jugements humains, sur un sous-ensemble du jeu de test, valident ce que les métriques ne savent pas mesurer : la justesse du ton, la pertinence du niveau de détail, la qualité de la formulation.
L’important est de mesurer régulièrement et de garder l’historique. Un RAG évolue à chaque changement de modèle, de découpage ou de prompt, et chaque changement peut améliorer une dimension au détriment d’une autre. Seul un jeu de test stable, exécuté à chaque itération, permet de savoir si une modification est réellement un progrès.
L’accompagnement Agenticiel sur l’évaluation des RAG
Construire un jeu de test représentatif et le faire vivre dans la durée est un investissement que beaucoup d’équipes reportent, faute de temps. C’est un travail que nous réalisons chez Agenticiel, avec une équipe de développement offshore francophone basée à Madagascar. Nous collectons les questions réelles, constituons le jeu de test, définissons les réponses attendues et mettons en place la chaîne d’évaluation qui mesure la qualité à chaque itération.
Notre accompagnement ne s’arrête pas à la construction du jeu de test. Nous l’intégrons dans votre processus de développement, pour que chaque évolution de votre RAG soit mesurée avant d’être déployée, et que les régressions soient détectées tôt. Nous travaillons en sous-traitance de développement, dans vos outils et avec vos équipes, en documentant ce qui est mis en place pour que l’évaluation reste maintenable.
Évaluer un RAG n’est pas un luxe : c’est la condition pour améliorer sans régresser. Sans mesure, vous pilotez à l’aveugle et vous découvrez les erreurs par vos utilisateurs. Notre approche consiste à construire un jeu de test représentatif de vos vraies questions, et à l’utiliser pour mesurer objectivement la qualité de votre RAG à chaque itération.