Pour évaluer un RAG, séparez la recherche documentaire de la rédaction. Un passage pertinent mal reformulé et une réponse fluide fondée sur le mauvais document sont deux défauts différents. Constituez un jeu de questions de référence, puis examinez les sources récupérées et les affirmations produites.
Construire un jeu de questions réaliste
Prenez des demandes fréquentes, des formulations imprécises et quelques questions hors périmètre. Pour chacune, rédigez la réponse attendue avec les passages qui la justifient. Faites valider cette référence par une personne qui connaît le sujet. Conservez des questions indépendantes des réglages du système pour éviter d’optimiser uniquement les exemples déjà utilisés pendant le développement.
Contrôler ce qui a été retrouvé
Avant de noter le style de la réponse, ouvrez les documents récupérés. Contiennent-ils effectivement l’information nécessaire ? La bonne version est-elle utilisée ? Une condition importante a-t-elle été coupée lors du découpage ? Classez les erreurs : document absent du corpus, recherche insuffisante, passage trop large ou version obsolète. Cette analyse indique quelle partie de la chaîne modifier.
Une petite recette qui révèle plusieurs familles d’erreurs
La grille suivante décrit des cas de démonstration, sans résultat mesuré sur un système client. Chaque question doit disposer d’une référence validée avant le test. La référence peut préciser qu’il ne faut pas répondre. Cela évite qu’un modèle soit récompensé pour avoir donné une réponse plausible à une question que le corpus ne permet pas de résoudre.
| Question de test | Attente à vérifier | Échec à classer |
|---|---|---|
| Que comprend cette offre ? | Réponse limitée au périmètre du document actuel | Prestation ajoutée sans source |
| Cette condition vaut-elle pour toutes les formules ? | Exception ou différence de périmètre conservée | Règle générale présentée sans sa condition |
| Quel est le prix d’une option non documentée ? | Reconnaissance du manque et orientation utile | Montant inventé |
| Que dit une ancienne procédure retirée ? | Absence de restitution comme règle actuelle | Version obsolète encore récupérée |
| Puis-je consulter ce document réservé ? | Respect des droits de l’utilisateur | Passage non autorisé exposé dans la réponse |
Pour chaque échec, gardez question, documents récupérés, réponse produite et décision du relecteur. Si plusieurs défauts coexistent, notez-les séparément. Une source pertinente peut être accompagnée d’une phrase inventée ; il serait trompeur de résumer ce cas par « source retrouvée, donc succès ». Le relevé doit aussi permettre à une autre personne de comprendre pourquoi la réponse a été acceptée ou refusée.
Évaluer la réponse affirmation par affirmation
Vérifiez exactitude, complétude, fidélité aux sources et reconnaissance de l’incertitude. Une citation cliquable ne suffit pas si le passage cité ne soutient pas la phrase. Un évaluateur automatique peut aider à trier les résultats, mais son jugement doit être contrôlé. Hugging Face présente une démarche d’évaluation avec questions, réponses de référence et critères explicites ; adaptez-la au risque de votre activité.
Exemple fictif : un délai mal repris
Le document distingue préparation et livraison. L’assistant additionne mal les étapes et annonce un délai global incorrect. La recherche a retrouvé le bon passage, mais la réponse reste fausse. Le correctif porte sur la formulation et le contrôle du calcul, pas nécessairement sur la base vectorielle. À l’inverse, une source périmée demande d’abord une correction documentaire.
Utiliser des mesures sans cacher les cas importants
Deux mesures simples peuvent aider au pilote : la proportion de questions pour lesquelles au moins un passage attendu est récupéré, puis la proportion de réponses acceptées selon votre grille. Ce sont des indicateurs proposés pour ce protocole, pas une définition universelle du rappel ni un score officiel de qualité des RAG. Publiez leur dénominateur et gardez les catégories de questions séparées. Un bon résultat global peut masquer l’échec de tous les cas sans réponse.
- Figez un lot de questions et une version du corpus. Réservez un autre lot pour vérifier que les réglages ne fonctionnent pas seulement sur les exemples déjà examinés.
- Faites relire une partie des réponses par deux personnes. Les désaccords indiquent souvent que la grille ou la référence manque de précision.
- Si vous utilisez un modèle évaluateur, confrontez ses décisions à cette relecture. Une appréciation automatique ne remplace pas une preuve dans le document.
- Comparez une seule modification importante à la fois et archivez les sorties. Contrôlez en priorité qu’aucune régression n’affecte les accès ou les cas hors périmètre.
Le carnet d’évaluation de Hugging Face présente une démarche de benchmark avec des références. Notre grille complète cette approche par des décisions adaptées au contenu d’un site et à ses utilisateurs. Pour un assistant public, une réponse prudente et vérifiable peut être préférable à une réponse plus complète qui ajoute une condition absente. Le passage à un humain doit faire partie des résultats autorisés.
Si les défauts semblent liés à la rédaction plutôt qu’à la recherche documentaire, le protocole de comparaison de LLM sur des tâches métier aide à préparer un essai ciblé. Gardez les mêmes sources et les mêmes questions pour ne pas confondre les causes.
Comparer un seul changement à la fois
Archivez configuration, corpus, questions et résultats avant chaque essai. Modifiez ensuite un paramètre, puis relancez les mêmes cas, y compris les refus attendus. Notez aussi temps de réponse et coût d’exploitation. La meilleure configuration est celle qui atteint vos critères de qualité sur des questions utiles. Préparez d’abord une base documentaire maîtrisée plutôt que de chercher un score spectaculaire sur quelques démonstrations.