Lance Martin, d'Anthropic, publie sur le blog claude.dev un guide sur la conception d'évaluations et sur l'amélioration d'une application ou d'une skill contre elles, sans se tromper soi-même. Il annonce l'ajout de deux sous-commandes à la skill claude-api de Claude Code : /claude-api build-eval construit une évaluation dans le dépôt, /claude-api hillclimb améliore l'application contre elle, une modification à la fois, avec un jeu d'exemples tenu à l'écart pour détecter le surapprentissage.
La première partie énonce quatre propriétés d'une bonne évaluation. Les tâches reflètent la production. Les scores montent avec un modèle plus capable et un effort plus élevé, faute de quoi des tâches ambiguës ou un grader mal calibré sont en cause. Le meilleur modèle reste nettement sous 100 %, sans que l'écart tienne à des tâches impossibles : une tâche qui échoue à chaque run est suspecte, et une bonne tâche est celle sur laquelle deux experts donnent le même verdict. Enfin la variance est faible, ce qui suppose un grader stable, un effort appliqué de façon constante et un environnement sans état résiduel. L'auteur ajoute une mise en garde sur l'échantillonnage adversarial : choisir les cas que le modèle actuel échoue mesure son empreinte d'échec plutôt que la difficulté réelle. Il préconise des cas jugés difficiles par un humain, des échecs réels tirés de tickets ou de bugs, tout en notant que le trafic brut peut biaiser vers le facile.
il est important de lire un échantillon de transcriptions notées avant de croire votre évaluateur
build-eval interroge l'utilisateur, puis construit l'évaluation avec des pauses d'approbation. Les entrées viennent, dans l'ordre, des transcriptions de production, des tickets, de cinq à dix cas écrits à la main, puis de cas synthétisés. Le grader est le moins cher qui convienne : programmatique quand les sorties sont contraintes, sinon un modèle juge avec une grille d'affirmations vérifiables. Claude note quelques cas et demande si l'utilisateur les aurait jugés autrement, puis lance la ligne de base avec intervalle de confiance et trois contrôles : stabilité du grader, plomberie, marge de progression.
La seconde partie traite du hillclimbing. Il convient aux surfaces peu coûteuses à modifier, dont le score est attribuable, avec un objectif cadré ; le coût en est un bon. Pour le surapprentissage, trois parades : séparer train et test, ne jamais coller les échecs dans le prompt, garder les réponses hors de portée. La commande découpe l'évaluation, vérifie que le bruit est inférieur au gain visé, propose un patch par tour et le retire si le train monte seul. Sur stagnation, elle classe les échecs par cause avant d'éditer.
Deux exemples illustrent l'ensemble. Sur un benchmark de support de 44 tickets, le passage d'Opus 4.8 à Opus 5.5 puis à Sonnet 5 en effort bas, avec un prompt amélioré, donne 90,5 % contre 78,6 % sur les tickets tenus à l'écart, pour environ un cinquième du coût. Sur la skill claude-api, l'évaluation passe de 66 % à environ 88 % : sections manquantes, tables de types, table des formes d'API à abandonner, correction de tâches et graders défectueux.