Testez vos connaissances : évaluation de prompts
Sur cette page
Ce quiz clôt la section sur l’évaluation de prompts. Il porte sur le workflow, le jeu de test, les trois types de notateurs, leur combinaison, et les précautions propres aux modèles actuels. Répondez de tête avant d’ouvrir chaque réponse.
À vous de jouer
1. Quelles sont les cinq étapes du workflow d'évaluation, dans l'ordre ?
Rédiger un premier prompt ; constituer un jeu d’évaluation ; faire passer chaque entrée par Claude ; noter chaque réponse avec un notateur ; modifier le prompt et recommencer, sur le même jeu et avec le même notateur.
2. Pourquoi tester un prompt une fois, ou quelques fois à la main, ne suffit-il pas ?
Parce que les utilisateurs réels envoient des entrées imprévues, et qu’on teste inconsciemment les cas que le prompt gère bien. Un pipeline d’évaluation mesure le prompt sur un jeu représentatif, détecte les régressions et permet de comparer deux versions par des chiffres.
3. Pourquoi générer les cas de test avec Haiku, et pourquoi en écrire aussi à la main ?
Haiku est le modèle le plus rapide et le moins cher : il fournit le volume et la diversité à petit prix. Les cas écrits à la main apportent ce qu’aucun modèle n’inventera : les bugs déjà rencontrés et les demandes réelles qui ont posé problème.
4. Quels critères confier à un notateur par code, et lesquels à un notateur par modèle ?
Au code, tout ce qui se vérifie de façon déterministe : JSON valide (json.loads), Python valide (ast.parse), expression régulière valide (re.compile), longueur, présence d’un mot. Au modèle, ce qui demande du jugement : pertinence, respect de la tâche, ton, complétude. Les personnes gardent les cas à fort enjeu et le contrôle par échantillon.
5. Pourquoi demander au notateur par modèle des forces, des faiblesses et un raisonnement, et pas seulement une note ?
Sans ce contexte, les modèles ont tendance à donner des notes moyennes, autour de 6. Le raisonnement rend aussi la note vérifiable : on lit pourquoi un cas a échoué.
6. Un notateur par code donne 10 (JSON valide), un notateur par modèle donne 4 (contenu faux). Que vaut la note combinée, et que signifie-t-elle ?
Avec une moyenne simple, (10 + 4) / 2 = 7. La forme est respectée, le fond ne l’est pas : il faut travailler le prompt sur le contenu sans casser le format. Les poids peuvent être ajustés selon ce qui compte le plus pour vous.
7. Pourquoi un notateur qui doit rendre « uniquement un nombre » avec `max_tokens=10` échoue-t-il sur les modèles actuels ?
Parce que les modèles actuels réfléchissent avant de répondre et que la réflexion compte dans max_tokens : les dix tokens partent dans la réflexion et le texte arrive vide. On demande la note dans une sortie structurée, avec un plafond raisonnable, et une notation impossible est comptée à part, jamais remplacée par une note inventée.
8. Comment rendre une comparaison entre deux versions de prompt honnête, maintenant qu'on ne peut plus fixer `temperature` à 0 ?
Même jeu de test, même notateur, même modèle, une seule variable : le prompt. Et plusieurs exécutions par version, en comparant les moyennes et leur dispersion plutôt que deux scores isolés.
Pour la suite
La section suivante passe à l’ingénierie de prompts : clarté, précision, balises XML, exemples. Chaque technique s’y mesure avec le pipeline que vous venez de construire.
Sources officielles : Building with the Claude API (Claude Academy, section « Prompt evaluation ») · Define success criteria and build evaluations et Structured outputs (documentation Claude)
Points clés à retenir
- Cinq étapes, un jeu et un notateur constants, le prompt comme seule variable.
- Haiku pour générer le volume, la main pour les cas qui comptent.
- Le code pour la forme, le modèle pour le fond, une personne pour vérifier le juge.
- Verdicts structurés, plafonds suffisants, exécutions répétées.