Testez vos connaissances : évaluation de prompts

1. Définir le but — Qu’est-ce que le prompt doit accomplir ?
2. Écrire le prompt — La première version (baseline)
3. Créer le jeu de données de test — Cas représentatifs avec les résultats attendus
4. Exécuter l’évaluation — Passer chaque cas de test dans le pipeline
5. Analyser les résultats et itérer — Identifier les faiblesses, modifier le prompt, re-évaluer

Option 3 est la bonne approche. Un pipeline automatisé permet de :

• Tester de manière reproductible (mêmes cas de test à chaque fois)
• Quantifier les améliorations avec des scores précis
• Détecter les régressions quand on modifie le prompt
• Évaluer sur un nombre suffisant de cas pour être représentatif

Les options 1 et 2 sont subjectives et ne permettent pas de mesurer les progrès de manière fiable.

1. Notateur par code (code grader) — Validation programmatique (syntaxe JSON, Python, regex). Utiliser quand la sortie doit respecter un format strict et vérifiable automatiquement. Déterministe et gratuit.

2. Notateur par modèle (model grader) — Un LLM évalue la qualité de la réponse selon des critères définis. Utiliser pour les aspects subjectifs : pertinence, ton, complétude, exactitude du contenu. Nécessite un appel API supplémentaire.

3. Notateur humain (human grader) — Un humain évalue manuellement les réponses. Utiliser pour les cas complexes ou ambigus, ou quand les enjeux sont critiques. Le plus fiable mais le plus lent et le plus coûteux.

• à) Oui — La pertinence est un critère qualitatif, idéal pour un notateur par modèle
• b) Non — La validation JSON doit être faite par code (json.loads), c’est déterministe
• c) Oui — Le ton et le style sont subjectifs, un modèle est bien place pour les évaluer
• d) Non — La compilation regex doit être vérifiée par code (re.compile), pas par un modèle
• e) Oui — Évaluer si un résumé couvre les points importants est un jugement qualitatif

Règle simple : si c’est vérifiable par du code de manière déterministe, utilisez un notateur par code. Sinon, utilisez un notateur par modèle.

• à) json.loads(output) — Si ça ne lève pas de JSONDecodeError, le JSON est valide
• b) ast.parse(output) — Si ça ne lève pas de SyntaxError, le Python est syntaxiquement correct
• c) re.compile(output) — Si ça ne lève pas de re.error, la regex est valide

Dans les trois cas, le pattern est le même : on tente le parsing dans un bloc try/except. Succès = score 10, échec = score 0.

Le score combine est (10 + 4) / 2 = 7/10.

Ce score signifie que la forme est respectee (la sortie est bien du JSON valide) mais que le fond pose problème (le contenu n’est pas ce qui était attendu).

C’est exactement pour cette raison qu’on combine les deux types de notation : le notateur par code seul aurait donne 10/10 (tout va bien) et le notateur par modèle seul aurait donne 4/10 (tout va mal). La combinaison donne une vue équilibrée.

Pour améliorer ce score, il faut travailler le prompt pour améliorer la qualité du contenu, sans casser le format JSON.