Évaluation de prompts

Écrire un bon prompt n’est que le début. Pour construire une application fiable, il faut maîtriser deux disciplines complémentaires : l’ingénierie de prompt et l’évaluation de prompt. Cette section construit la seconde, et l’ordre est voulu : améliorer sans mesurer, c’est naviguer sans instruments.

Ingénierie et évaluation

L’ingénierie de prompt est votre boîte à outils pour écrire et améliorer un prompt : consignes claires, exemples, structure en balises XML, et les autres techniques de la section 3.

L’évaluation de prompt est la mesure. C’est un test automatisé qui donne des chiffres objectifs sur l’efficacité réelle d’un prompt. Au lieu de deviner, vous pouvez :

• comparer les réponses à des réponses attendues ;
• comparer plusieurs versions d’un même prompt ;
• repérer les erreurs dans les sorties.

Le parallèle avec le logiciel est exact : l’ingénierie écrit le code, l’évaluation est la suite de tests. Personne ne retouche un système critique sans tests ; personne ne devrait retoucher un prompt de production sans évaluation.

Trois chemins après l’écriture d’un prompt

Une fois le prompt écrit, trois options s’offrent à vous :

1. Le tester une fois et le déclarer suffisant. C’est un pari : un essai ne dit rien des entrées imprévues que la production apportera.
2. Le tester quelques fois et l’ajuster pour un ou deux cas limites. Mieux, mais l’échantillon reste minuscule et choisi par vous, avec vos angles morts.
3. Le passer dans un pipeline d’évaluation qui le note, puis itérer sur des chiffres. Plus de travail au départ, beaucoup plus de confiance ensuite : chaque version reçoit une note, chaque modification prouve son gain ou révèle sa régression.

Le piège des deux premières options

Les options 1 et 2 sont des pièges où tombent tous les développeurs, y compris les plus expérimentés, parce qu’elles semblent raisonnables sur le moment. On teste avec les entrées qui nous paraissent évidentes ; les vrais utilisateurs, eux, arrivent avec d’autres formulations, d’autres langues, des cas tordus qu’on n’imagine pas depuis son bureau.

La solution est l’option 3. La documentation d’Anthropic donne trois principes pour la mettre en œuvre : des tests qui ressemblent à la vraie distribution des demandes, cas limites compris ; une notation automatisée dès que possible ; et le volume plutôt que la perfection, car beaucoup de cas notés automatiquement valent mieux que quelques cas notés à la main. Les leçons suivantes construisent ce pipeline pièce par pièce : le déroulé d’ensemble, le jeu de test, l’exécution, puis la notation.

À vous de jouer

Votre prompt le plus risqué. Choisissez un prompt que vous utilisez déjà, au travail ou dans un projet. Écrivez cinq entrées qu’un vrai utilisateur pourrait envoyer et qui vous surprendraient : formulation inattendue, autre langue, demande hors sujet, texte très long, entrée vide. Gardez cette liste : elle nourrira votre premier jeu de test.

Sources officielles : Prompt evaluation (Claude Academy) · Define success criteria and build evaluations (documentation Claude)

Points clés à retenir

• L’ingénierie de prompt écrit et améliore ; l’évaluation mesure.
• L’évaluation est aux prompts ce que les tests sont au code.
• Tester une ou quelques fois ne couvre que vos intuitions, pas la variété des vrais utilisateurs.
• Des tests représentatifs, notés automatiquement, en nombre : c’est la base d’un pipeline utile.