Liste de vérification pour l'évaluation des prompts

Maya a un prompt qui résume l'exportation des commandes internes pour l'ingénieur de garde. Dans la fenêtre de chat, il est excellent. Elle modifie une ligne pour rendre les résumés plus concis, les deux suivants qu'elle essaie semblent excellents, et elle livre. Trois jours plus tard, un ingénieur de garde lit un résumé qui liste un total de commande qui n'apparaît nulle part sur la page d'exportation. La formulation plus concise a également supprimé l'instruction qui gardait le modèle fondé, et cela ne se montre que dans le cas de page vide que personne n'ouvre lors d'une démo. C'est ainsi que les prompts échouent. Ils ne se brisent pas bruyamment, ils dérivent, et la dérive se manifeste sous forme de billet.

Le piège est que les changements de prompt semblent sûrs. Vous ajoutez une phrase comme "soyez concis et précis" et supposez que vous avez amélioré les choses. Des recherches publiées en 2026 (l'article When "Better" Prompts Hurt) ont mesuré exactement cela et ont découvert que c'est souvent faux. Ajouter des règles génériques à un prompt utilisateur a fait chuter de manière mesurable la performance augmentée par la récupération d'un modèle, car les instructions plus lâches l'ont poussé à répondre au-delà des sources fournies. Le prompt semblait plus fort sur papier. Il était bien pire en pratique. La seule façon dont quelqu'un a remarqué cela était en évaluant un ensemble fixe d'entrées avant et après le changement. Un changement qui semble être une amélioration évidente est exactement le genre qui nécessite un chiffre, car l'intuition qu'il a aidé est la chose qui est fausse.

C'est le travail de ce guide. C'est la moitié post-résultat de la paire de prompts. La liste de vérification de révision de prompt examine un prompt avant que vous ne l'envoyiez et demande s'il a suffisamment de contexte, de contraintes et d'exemples. Cette liste de vérification commence une fois que les résultats existent et pose une question plus difficile : à travers de nombreuses exécutions, sur des entrées que vous n'avez pas choisies, ce prompt fait-il le travail, et votre dernière modification a-t-elle aidé ou nui ? Les propres directives d'évaluation d'Anthropic encadrent de bonnes évaluations comme la différence entre deviner et savoir, et les directives sont cohérentes dans le domaine. Optimiser un prompt est un processus empirique que vous pouvez mesurer. Vous changez la formulation, vous réévaluez l'ensemble fixe, vous lisez les échecs, vous décidez.

Le coût de l'ignorer est subtil. Un prompt ne se brise pas bruyamment. Il dérive. Une modification améliore le ton et régresse silencieusement le fondement sur un cas limite que personne ne teste lors d'une démo. Un mois plus tard, le cas limite est le rapport de bogue. Un harnais d'évaluation est ce qui l'aurait détecté le jour où vous avez fait le changement, alors que la différence était encore devant vous et que la correction était peu coûteuse.

Le harnais n'est aussi bon que les trois éléments qui le sous-tendent : l'ensemble d'entrées fixes, la grille d'évaluation et les conditions d'exécution. La plupart des évaluations faibles échouent sur l'un de ces trois, alors passez votre temps ici.

L'ensemble d'entrées fixes. C'est un fichier d'entrées réelles qui ne change pas entre les exécutions. Les directives actuelles d'Anthropic et des outils d'évaluation de prompt convergent vers un petit départ honnête : 20 à 50 cas suffisent pour détecter de vraies régressions, car les tailles d'effet sont grandes au début. Le mélange compte plus que le nombre. Un ensemble solide est échantillonné à partir de la production et de choses qui ont réellement échoué, environ la plupart des cas routiniers, une tranche de cas limites, et quelques échecs passés documentés. Un ensemble faible est vingt entrées que vous avez inventées à votre bureau, que le prompt gère déjà toutes. Contraste travaillé pour l'exportation des commandes de Maya : une entrée forte est "18 pages d'exportation réelles plus 4 cas limites de pages vides plus les 2 pages où il a une fois inventé un total, enregistrées dans un dossier, jamais éditées." Une entrée faible est "quelques pages d'exemple que j'ai tapées qui semblent à peu près correctes." L'ensemble faible rapportera un score confiant et manquera complètement le bogue de la page vide, car ce cas n'y est pas.

La grille d'évaluation. Une grille d'évaluation est la définition écrite d'une bonne sortie plus un seuil de réussite pour chaque dimension. Le test d'une bonne grille d'évaluation est simple. Deux personnes évaluant la même sortie devraient parvenir au même verdict. Commencez par deux ou trois dimensions qui comptent le plus et n'en ajoutez d'autres que lorsqu'elles prouvent qu'elles attrapent quelque chose. Pour un prompt de résumé, ce sont généralement l'exactitude (chaque nombre se rapporte à la source), le fondé (rien n'est inventé), et le format. Une ligne de grille forte lit "Fondé : aucun ordre, statut ou total n'apparaît qui ne soit pas sur la page source, seuil de réussite 100 %." Une ligne de grille faible lit "devrait être précis." La première est vérifiable par une personne ou un évaluateur de modèle. La seconde est une humeur, et deux évaluateurs ne seront pas d'accord dessus, ce qui signifie que vos scores sont du bruit.

Les conditions d'exécution. Fixez la version du modèle, la température et le prompt système, et écrivez-les. Réglez la température à 0 quand vous le pouvez, pour qu'un changement de score provienne du prompt plutôt que du hasard. Ensuite, évaluez chaque entrée plusieurs fois, 3 à 5 exécutions, pas une seule. C'est l'étape que les gens sautent, et c'est celle qui sépare un vrai résultat d'un coup de chance. Une seule exécution qui obtient un bon score pourrait être la seule bonne réponse sur cinq. Évaluer trois à cinq fois fait ressortir la variance pour que vous puissiez voir si le prompt est systématiquement bon ou occasionnellement bon. Conservez chaque score par cas, pas seulement la moyenne, et comparez le nouveau prompt à l'ancien sur les mêmes entrées lors de la même exécution. Le nombre qui décide des choses est la différence par cas entre les versions, car c'est ce qui annule le bruit que partagent les deux versions.

La façon la plus courante de sentir qu'une évaluation est terminée alors que le travail ne l'est pas, c'est le jeu de données obsolète. Le jeu a été construit il y a six mois, la formulation en production a évolué depuis, et l'évaluation rapporte maintenant un 0,94 impeccable sur des entrées qui ne ressemblent plus à ce que les utilisateurs envoient réellement. Le score est confiant et erroné. Rafraîchissez le jeu selon un calendrier, intégrez les nouvelles erreurs au fur et à mesure qu'elles surviennent, et traitez le fichier d'entrée comme un actif vivant qui est versionné aussi soigneusement que le prompt qu'il teste.

Le deuxième piège est l'évaluation sur une seule exécution. Une exécution vous donne un échantillon d'une distribution. Elle ne vous dit presque rien sur la fiabilité et fait paraître un prompt bruyant comme stable. La solution est de faire l'évaluation 3 à 5 fois par entrée et de regarder la dispersion, pas seulement la moyenne.

Le troisième est se cacher derrière la moyenne. Un changement de prompt qui fait passer la moyenne de 0,81 à 0,85 peut être un changement qui a aidé vingt cas et en a brisé deux, et l'un des deux cas brisés est une régression de sécurité. Conservez les scores par cas. Traitez toute entrée qui réussissait auparavant un test de sécurité ou de refus et qui échoue maintenant comme un problème bloquant, même pour un seul cas, de la même manière que vous bloqueriez un déploiement sur un test échoué. Et lisez réellement les transcriptions à faible score. Une moyenne ne vous dit jamais pourquoi quelque chose a échoué. Les directives d'évaluation d'Anthropic sont claires à ce sujet : vous ne saurez pas si vos évaluateurs fonctionnent à moins de lire vous-même les transcriptions.

Un quatrième piège, plus discret, est faire confiance aveuglément à l'évaluateur du modèle. Un évaluateur basé sur un modèle est rapide et évolutif, mais il est non déterministe et comporte des biais (il a tendance à récompenser les réponses plus longues et plus confiantes). Avant de lui faire confiance, calibrez-le par rapport à votre propre jugement sur un échantillon et vérifiez que ses étiquettes correspondent aux vôtres. Le domaine considère qu'un accord d'environ 75-90 % entre l'évaluateur du modèle et un humain est le seuil pour l'utiliser à grande échelle. En dessous de cela, l'évaluateur ajoute du bruit, pas de la clarté.

En équipe, l'évaluation devient une infrastructure partagée. Le jeu d'entrées et le barème vivent dans le dépôt à côté du prompt, donc quiconque modifie le prompt relance le même jeu et hérite du même seuil. Le travail récent sur le produit montre combien cela vaut : la fonctionnalité Outcomes d'Anthropic, qui relance une tâche lorsqu'un agent d'évaluation distinct la note en dessous d'un barème, a amélioré la qualité de génération de PowerPoint d'environ 10 % sans changer le modèle du tout. Le barème et la boucle de réévaluation ont fait tout le travail, avec le même modèle. C'est le même levier que cette liste de vérification vous offre. Une fois ici, votre prochaine étape s'enchaîne naturellement : un prompt qui passe l'évaluation et alimente les flux de génération de code dans la Liste de vérification de révision des prompts avant chaque envoi, et tout code que ce prompt produit est intégré dans la Révision sécurisée du code IA dans /docs avant sa fusion. Lors de votre prochaine véritable modification de prompt, faites une petite chose : sauvegardez cinq entrées réelles dans un fichier et évaluez l'ancien et le nouveau prompt sur celles-ci avant de passer en production. Cette simple habitude attrape la régression qu'une moyenne aurait cachée.