Évaluer et améliorer une appli IA, expliqué avec un examen
build-eval écrit avec vous l'examen de votre appli IA ; hillclimb révise contre lui, un changement à la fois, avec des cas mis de côté contre le bachotage.
Repensez à un bon examen. Il ressemblait au métier qu’il préparait. Le meilleur élève avait la meilleure note, et pourtant personne n’avait tout juste. Corrigée deux fois, la même copie obtenait la même note. Et ceux qui avaient appris les annales par cœur brillaient à l’examen blanc, puis trébuchaient le jour J.
L’évaluation d’une appli IA fonctionne exactement pareil, à ceci près qu’il faut écrire l’examen soi-même, le corriger, puis réviser contre lui sans se mentir. Anthropic a ajouté des consignes pour ces deux étapes au skill claude-api, livré avec Claude Code. Cet article développe la fiche n° 3 de ma série Claude · Mode d’emploi sur consonance.fyi, enrichie des détails du billet original sur claude.dev.
En une phrase : build-eval construit une évaluation dans votre code, avec votre accord, et hillclimb améliore votre appli contre elle, un changement à la fois, en gardant des exemples de côté pour repérer l’overfitting.
Ce qui fait un bon examen
Le billet de claude.dev décrit quatre traits des évals bien conçues, chacun avec son souvenir d’école :
- Les tâches ressemblent à la production. Un examen qui ressemble à la vraie vie : choisissez les tâches qui comptent vraiment, pas celles qui sont faciles à générer ou à corriger.
- Les modèles plus forts font mieux. Le meilleur élève a la meilleure note. Si un modèle plus capable, ou un niveau d’effort plus élevé, ne progresse pas, soupçonnez des tâches ambiguës ou un correcteur mal calibré.
- Il reste de la marge au sommet. Personne n’a 100 %. Le meilleur modèle à l’effort maximal doit rester bien sous la note parfaite, sinon impossible de savoir si un changement aide. Mais cet écart ne doit pas venir de tâches impossibles : une tâche qui échoue à chaque essai est un indice qui ne trompe pas.
- Peu de variance d’un essai à l’autre. La même copie, la même note. Le bruit vient de tâches floues, d’un correcteur qui change d’avis sur une sortie identique, ou d’un reste d’essai précédent (un fichier, un historique git) qui souffle la réponse à l’agent.
Un piège plus sournois s’appelle l’échantillonnage adversarial : un prof qui n’écrit que les pièges d’un seul élève. Ne gardez que les cas que le modèle d’aujourd’hui rate, et l’éval mesure les faiblesses de ce modèle-là, pas ce qui est réellement difficile pour votre appli. Choisissez les cas durs parce qu’un humain les a jugés durs, et sachez dire pourquoi. Les vrais échecs issus de bug reports et de tickets sont bienvenus, mais le trafic utilisateur brut peut pencher vers le facile : on essaie surtout ce qu’on s’attend à voir marcher.
build-eval : écrire l’examen ensemble
Lancez /claude-api build-eval : Claude vous interroge, construit l’éval dans votre code et s’arrête à des moments précis pour obtenir votre accord.
Les sujets. Claude puise les entrées dans cet ordre : transcripts de production (après avoir demandé la durée de conservation et les données sensibles), bug reports et tickets de support, cinq à dix cas écrits à la main, puis des cas synthétisés à partir de votre code. Une page simple liste chaque entrée et attend votre confirmation.
Le correcteur. Claude propose ensuite le correcteur le moins coûteux qui convienne. Une sortie contrainte appelle une vérification programmatique : correspondance exacte, étiquette parmi une liste fixe, JSON conforme à un schéma, tests qui passent. Une sortie ouverte appelle un LLM-juge, qui lit une grille rédigée en affirmations vérifiables plutôt qu’une échelle de 1 à 5 ; le juge ne doit pas être le modèle testé. Claude corrige une poignée de cas et vous demande si vous auriez noté autrement.
Les diagnostics. Pendant la baseline, le correcteur est lancé deux fois sur la même sortie pour voir si le verdict change, et Claude traque timeouts, erreurs d’API et réponses tronquées. Si la baseline atteint déjà environ 95 % ou plus, il prévient que l’ascension devrait viser le coût ou la latence plutôt que la qualité.
Vous récupérez les cas, le correcteur, le runner, un transcript par cas et une page de résultats toute simple.
hillclimb : réviser une chose à la fois
Avec un examen fiable en main, /claude-api hillclimb révise comme un élève discipliné, une chose à la fois. Vous choisissez ce qu’il a le droit de toucher : prompt système, skills, descriptions d’outils, modèle, effort et autres paramètres d’API, ou code du harness. Il demande votre objectif (la performance, ou le coût à performance égale), répartit les cas au hasard entre train et test, et vérifie que le bruit de l’éval est plus petit que le plus petit gain qui vous ferait agir. Puis chaque tour suit la même boucle :
Claude lit les transcripts train du tour précédent et propose un seul patch, en s’attaquant à la cause (réécrire une section, ajouter une règle manquante) plutôt qu’en reformulant une ligne, pour que l’effet ressorte au-dessus du bruit. Si train et test montent tous les deux, le patch reste. Une régression est annulée. Si train progresse pendant que test reste plat, Claude soupçonne l’overfitting et annule.
Quand le score stagne deux ou trois tours, Claude trie chaque échec restant par cause, ce qui révèle souvent un cas ambigu. À la fin, votre code reste sur la version qui a le mieux réussi sur le jeu test, avec des intervalles de confiance face à la baseline. Si le gain tient dans le bruit, Claude déconseille de merger.
Ce que ça a donné en pratique
Le billet de claude.dev partage deux essais. Le premier visait le coût, sur un benchmark de support client de 44 tickets, 30 pour la recherche et 14 mis de côté. La baseline, Opus 4.8 en effort élevé, obtenait 74,4 % à 4,6 centimes par ticket. Après un audit du prompt, Opus 5.5 en effort bas atteignait 87,8 % à 1,9 centime ; Sonnet 5 en effort bas, 88,9 % à environ 1 centime ; un meilleur prompt l’a ensuite porté à 98,9 %. Sur les 14 tickets jamais vus, la configuration finale obtenait 90,5 % contre 78,6 % au départ, pour environ un cinquième du coût.
Le second visait la performance du skill claude-api lui-même : de 66 % à environ 88 %, en partie en ajoutant des fonctionnalités manquantes, en partie en réparant des tâches et des correcteurs défaillants.
Pour essayer
-
Mettez Claude Code à jour : le skill claude-api est livré avec.
claude update -
Construisez l’éval dans votre code. Claude vous interroge et attend votre accord sur les exemples et le correcteur.
/claude-api build-eval -
Améliorez votre application contre elle, selon votre objectif (performance, ou coût à performance égale).
/claude-api hillclimb
En conclusion
L’image de l’examen, c’est la liste de contrôle. Écrivez une copie qui ressemble à la vraie vie, gardez un correcteur juste et constant, révisez une chose à la fois, et gardez toujours un examen blanc jamais vu. build-eval et hillclimb ne remplacent pas votre jugement : ils s’arrêtent là où il compte, et le jeu test mis de côté garde tout le monde honnête, le modèle compris.