BAA 101 · Chapitre 09
Évaluer sans se mentir
Le principe
Une évaluation ne vaut que ce qu’elle vérifie. On lit le détail plutôt que la moyenne, on change une seule chose à la fois, et on essaie de tromper son propre évaluateur.
Pourquoi c’est important
Une moyenne cache la forme des résultats. Un score mesuré sur les cas qu’on vient de corriger ne prouve rien. Un juge qui lit la réponse ne voit pas ce que l’AgentUn programme qui utilise un modèle de langage pour décider quoi faire (chercher, appeler un outil, répondre, refuser), en boucle, avec des règles d'arrêt.Voir dans le glossaire → a réellement fait. Et un test vert sur un Faux modèleUn modèle déterministe aux réponses prévues. Il teste le circuit, pas le jugement : un test vert sur lui prouve la tuyauterie.Voir dans le glossaire → prouve la tuyauterie, pas la qualité.
Le mécanisme
- Une suite par comportement : chaque chemin attendu, les cas limites, les attaques.
- Lire cas par cas, pas seulement le score global.
- Une variable à la fois, et un nouveau nom pour chaque run, pour comparer proprement.
- Des cas inédits : rapporter l’amélioration et la régression, avec leurs chiffres.
- Attaquer l’évaluateur : un faux modèle qui triche révèle les réussites gratuites.
- Savoir ce qui a produit le chiffre : quel modèle, quel fichier. Une mesure faite sur la mauvaise version se signale comme fausse.
Sur le terrain
- AWS Scholars, chapitre 1 : 0.92 sur 13 cas, c’est 12 réponses parfaites et un échec franc. Et le juge note le texte, pas la ligne écrite en base.
- Dev3Pack, Session 7 : un faux modèle qui cite toujours le même document obtient déjà 50 %.
- Dev3Pack, cap01 : une porte d’évaluation verte sur un faux modèle ne montre ni hallucinations ni mauvaises réponses.
- Dev3Pack, Final : un grade mesuré sur le mauvais fichier, écarté et signalé comme tel.
La question à se poser
Qu’est-ce que cette évaluation ne vérifie pas ?