RAG Formation · Leçon · Fondations et mesure

Construire un jeu d’évaluation fiable

Transformer les attentes de qualité en une vérité terrain explicite et testable.

Feuille de route Laboratoire d’ingénierie IA

$ lesson --status
▸ course RAG Formation
▸ lesson 03 / 16
▸ phase Fondations et mesure
▸ status Terminé
● build → measure → learn

Leçon autonome

Apprenez la leçon complète et vérifiez votre compréhension ici.

Le contenu des 16 leçons de RAG Formation est complet. Cette page contient le contenu complet, les références locales et des exercices immédiats dans le navigateur.

Le gain concret de cette leçon

À la fin de cette leçon, vous saurez analyser une question d’évaluation et expliquer précisément pourquoi sa vérité terrain est solide — ou ce qui ne va pas si elle ne l’est pas.

Regarder la vidéo

1 · Une évaluation est un contrat

Une question d’évaluation n’est pas seulement une phrase qu’un utilisateur pourrait saisir. C’est un contrat entre l’équipe produit et le système qui effectue la notation :

Question : ce que demande l’utilisateur

Sources attendues : les documents qui doivent étayer la réponse

Faits requis / must_include : les faits importants qu’une réponse correcte doit contenir

Réponse attendue : le sens de référence utilisé par l’évaluateur

Refus attendu / expect_refusal : si le système doit refuser parce que le corpus ne contient pas la réponse

Ignorez ce contrat et votre score pourra sembler parfaitement rigoureux tout en mesurant discrètement quelque chose de complètement différent.

Lecture principale : bonnes pratiques d’évaluation d’OpenAI — observez pourquoi les systèmes d’IA non déterministes ont besoin d’évaluations structurées.

2 · Lire le jeu de démonstration

Ouvrez :

demo/eval_set.yaml

Ce jeu de démonstration contient 65 questions réparties sur 25 documents synthétiques :

35 questions factuelles
7 questions de recherche par référence
9 questions à raisonnement multi-étapes
5 questions multilingues
3 questions sur des acronymes
6 questions sans réponse possible

Cette composition n’est pas arbitraire. Un chatbot peut répondre sans difficulté à des questions sémantiques ordinaires tout en échouant sur des identifiants SOP exacts, le raisonnement entre plusieurs documents ou la capacité à savoir quand dire non.

3 · Pourquoi la correspondance de récupération utilise uniquement les métadonnées

Prenons q30 :

Sources attendues : `PR-QA-MRD-001`, `PR-QA-MRD-009`

Fait requis : `90 jours`

Voici le piège : les documents de ce corpus se renvoient les uns aux autres. Un fragment de `PR-QA-MRD-001` peut mentionner `PR-QA-MRD-009` dans son texte. Si vous recherchez aveuglément dans tout le fragment, l’évaluateur pourrait attribuer à tort la récupération de `PR-QA-MRD-009`, alors qu’il n’est jamais apparu comme source.

C’est précisément pourquoi `eval.py` ne fait confiance qu’aux métadonnées de source — des champs comme `source`, `document_name` et `filename` — au lieu d’accorder un point parce qu’un identifiant apparaît quelque part dans le texte.

4 · Questions traitables et questions sans réponse

Ces six questions sans réponse possible ne sont pas dues à une conception négligente des tests : ce sont des contrôles de sécurité. Elles posent toutes la même question simple : le système sait-il où s’arrête sa propre connaissance ?

Type de question	Source attendue	Comportement attendu
Traitables	Un ou plusieurs documents	Répondre au fait demandé et citer les sources
Sans réponse	Aucune	Refuser ou indiquer que les données indexées ne contiennent pas la réponse

5 · Exercice : faire confiance à la question ou la rejeter ?

Cas A : `expect_sources` nomme `PR-QA-MRD-009`, mais aucun fichier de ce nom n’existe dans le corpus. Cette question est-elle encore valide ?

Cas B : L’identifiant du document attendu n’apparaît que dans le texte d’un autre document, nulle part ailleurs. La récupération mérite-t-elle tout de même le point ?

Cas C : Une question n’a aucune source attendue et porte l’indicateur `expect_refusal: true`. Que doit faire un bon chatbot ?

6 · Votre revue du jeu d’évaluation

Choisissez une question dans chaque catégorie de `eval_set.yaml` et notez :

La question peut-elle réellement recevoir une réponse ?
Quel(s) document(s) source l’étaye(nt) réellement ?
Quel fait doit apparaître dans une réponse correcte ?
Un renvoi croisé pourrait-il tromper l’évaluateur et produire un faux crédit ?
À quoi ressemble un échec sûr dans ce cas ?

Lien avec la mission

Dans les cas d’usage SOP, QA, réglementaires, fournisseurs et audits, le jeu d’évaluation n’est pas seulement un outil de test : il fait partie de la limite de sécurité du produit. C’est lui qui définit les notions de « fondé », « correct » et « inconnu ».

Prochaine action

Exécutez une nouvelle fois la vérification de cohérence hors ligne :

cd demo
python3 eval.py verify

Choisissez ensuite une question dans chacune des six catégories et rédigez une courte revue. Envoyez-moi vos réponses, notamment un cas où la correspondance fondée uniquement sur les métadonnées vous évite d’accorder à tort un crédit de récupération.

Vous avez des questions sur la vérité terrain, la notation ou l’une de ces catégories ? Posez-les-moi. Une fois votre revue terminée, je marquerai la leçon 3 comme terminée.

← Leçon précédente Fiche de référence Leçon suivante →