Que fait eval-design ?
Vous concevez la mesure, pas le produit. Le résultat de cette compétence est une décision que quelqu'un peut défendre dans une salle, pas un chiffre.
La plupart du temps, la décision est quoi réparer ensuite. Un eval qui ne fait que classer des systèmes est un rapport ; un eval qui nomme les deux choses qui vous coûtent le plus, et prouve que la correction a fonctionné quand vous le relancez, est une boucle de développement. Construisez pour la deuxième option — la taxonomie des échecs et la décomposition par critère comptent plus que le score global, car ce sont les parties sur lesquelles quelqu'un peut agir.
La position
Quatre règles. Ce sont des opinions, et elles sont le cœur de cette compétence.
1. Pas de sensations. « Ça semble mieux » n'est pas un résultat. Si un changement ne peut pas être exprimé comme un mouvement sur un critère défini, mesuré sur un ensemble fixe, il n'a pas été évalué. Déployez-le si vous voulez — mais ne prétendez pas qu'il a été testé.
2. Chaque critère doit être contestable. Un critère sur lequel deux relecteurs attentifs ne pourraient pas se retrouver de part et d'autre ne mesure rien. « La sortie est-elle utile ? » n'est pas un critère. « La réponse indique-t-elle le délai de remboursement en jours ? » en est un. Chaque critère d'une grille porte le désaccord spécifique pour lequel il a été écrit — voir references/rubric-design.md.
3. Pas de LLM comme juge par défaut. Un juge est un système avec son propre taux d'erreur, et un juge non validé injecte cette erreur dans votre chiffre principal. Les humains labellisent d'abord, le juge est calibré sur ces labels, et l'accord est publié à côté de chaque résultat produit par le juge. Voir references/judges.md.
4. Signalez la baseline ou l'évaluation est du marketing. Une regex, une règle de mots-clés, le système de production actuel, ou ne rien faire. Environ un tiers des fonctionnalités IA déployées perdent face à quelque chose qui ne coûte rien sur au moins un critère, et vous voulez le découvrir avant un responsable du recrutement ou un VP.
Deux règles structurelles découlent de celles-ci :
- Les seuils sont des planchers, pas des pondérations. Un critère de sécurité, juridique ou de confiance ne s'échange pas contre une performance moyenne. Un système en dessous du plancher n'est pas un candidat, quel que soit le prix. Les moyennes pondérées cachent exactement cela.
- Intervalles de confiance ou pas de classement. À n=150, une différence de 3 points est du bruit. Classer des systèmes à l'intérieur du bruit est la façon la plus courante dont le travail d'évaluation induit en erreur la personne qui le lit.
Workflow
Travaillez dans cet ordre. Ne sautez pas à la notation — chaque échec d'un eval remonte à quelque chose sauté au-dessus.
- Trouvez la décision. Qu'est-ce qui change en fonction du résultat ? « Quel modèle déployons-nous », « cela peut-il fonctionner sans supervision », « le changement de prompt a-t-il régressé ». Si rien ne change, arrêtez-vous et dites-le — c'est le moment le plus précieux du processus, et la réponse honnête est parfois « vous n'avez pas besoin d'un eval ».
- Écrivez la taxonomie des échecs en premier. Avant les critères. Collectez 30 à 50 sorties réelles, lisez chacune, et regroupez ce qui a mal fonctionné. Les critères dérivés d'échecs observés surpassent toujours les critères dérivés de l'imagination.
→
references/failure-taxonomy.md - Transformez la taxonomie en critères. Chacun reçoit un poids, un désaccord, et éventuellement un seuil. →
references/rubric-design.md - Construisez l'ensemble de référence (golden set). Stratifié, adversarial, versionné, et assez petit pour qu'un humain le labellise réellement. →
references/golden-sets.md - Labellisez avec des humains, mesurez l'accord. Si deux labelliseurs ne peuvent pas s'accorder, la grille est cassée, pas les labelliseurs. Corrigez la grille et relabellisez.
→
references/statistics.md - Seulement maintenant, envisagez un juge, et uniquement calibré. →
references/judges.md - Exécutez chaque système, y compris une baseline non IA, écrivez
results.json, et générez le rendu. →references/scorecard-spec.md - Rédigez le verdict vous-même. La fiche d'évaluation montre des chiffres ; un humain expose le compromis fait et ce qui inverserait la décision.
Rendu
python3 skills/eval-design/scripts/render_scorecard.py results.json --md
Écrit un fichier scorecard.html autonome (aucune requête externe, mode clair et sombre) et un SUMMARY.md pour la lecture dans le dépôt. Schéma : references/scorecard-spec.md.
python3 skills/eval-design/scripts/validate_rubric.py results.json
Échoue sur les erreurs qui rendent une fiche d'évaluation malhonnête : des poids qui ne totalisent pas 1, des critères sans désaccord déclaré, des seuils sans justification, une baseline manquante, ou un classement déclaré à l'intérieur de l'intervalle de confiance.
Quand ne pas utiliser cela
- Une modification ponctuelle de prompt sans décision associée. Regardez simplement la sortie.
- Vous n'avez ni utilisateurs ni exemples. Obtenez d'abord 30 entrées réelles. Un eval construit sur des entrées imaginaires mesure votre imagination.
- La tâche a une réponse correcte qu'un programme peut vérifier — arithmétique, JSON valide, une compilation réussie. Écrivez la vérification, pas une grille.
- Quelqu'un veut un chiffre pour justifier une décision déjà prise. Dites-le à voix haute au lieu de construire l'évaluation.
Fichiers de référence
Chargez à la demande ; ne les lisez pas tous d'un coup.
| Fichier | Lire quand |
|---|---|
references/rubric-design.md | Écrire ou corriger des critères |
references/failure-taxonomy.md | Partir de sorties réelles |
references/golden-sets.md | Choisir et stratifier des cas |
references/judges.md | Quelqu'un propose un LLM comme juge |
references/statistics.md | Taille d'échantillon, IC, accord, dérive |
references/scorecard-spec.md | Écrire results.json |
references/antipatterns.md | Examiner l'évaluation de quelqu'un d'autre |