Testez vos connaissances : evaluation de prompts
Question 1 : Les etapes du workflow d’evaluation
Quelles sont les 5 etapes du workflow d’evaluation de prompts, dans le bon ordre ?
Voir la reponse
- Definir le but — Qu’est-ce que le prompt doit accomplir ?
- Ecrire le prompt — La premiere version (baseline)
- Creer le jeu de donnees de test — Cas representatifs avec les resultats attendus
- Executer l’evaluation — Passer chaque cas de test dans le pipeline
- Analyser les resultats et iterer — Identifier les faiblesses, modifier le prompt, re-evaluer
Question 2 : Pourquoi un pipeline d’evaluation ?
Parmi ces trois approches, laquelle est la meilleure pour ameliorer un prompt de maniere fiable ?
- Option 1 : Tester manuellement avec 2-3 exemples et ajuster au feeling
- Option 2 : Demander a un collegue de relire les sorties
- Option 3 : Construire un pipeline d’evaluation automatise avec des metriques chiffrees
Voir la reponse
Option 3 est la bonne approche. Un pipeline automatise permet de :
- Tester de maniere reproductible (memes cas de test a chaque fois)
- Quantifier les ameliorations avec des scores precis
- Detecter les regressions quand on modifie le prompt
- Evaluer sur un nombre suffisant de cas pour etre representatif
Les options 1 et 2 sont subjectives et ne permettent pas de mesurer les progres de maniere fiable.
Question 3 : Les trois types de notateurs
Quels sont les trois types de notateurs (graders) et quand utiliser chacun ?
Voir la reponse
-
Notateur par code (code grader) — Validation programmatique (syntaxe JSON, Python, regex). Utiliser quand la sortie doit respecter un format strict et verifiable automatiquement. Deterministe et gratuit.
-
Notateur par modele (model grader) — Un LLM evalue la qualite de la reponse selon des criteres definis. Utiliser pour les aspects subjectifs : pertinence, ton, completude, exactitude du contenu. Necessite un appel API supplementaire.
-
Notateur humain (human grader) — Un humain evalue manuellement les reponses. Utiliser pour les cas complexes ou ambigus, ou quand les enjeux sont critiques. Le plus fiable mais le plus lent et le plus couteux.
Question 4 : Que peut evaluer un notateur par modele ?
Un notateur par modele est-il adapte pour evaluer les elements suivants ? Repondez oui ou non pour chacun.
- a) La pertinence d’une reponse par rapport a la question posee
- b) Si une sortie est du JSON syntaxiquement valide
- c) Le ton et le style d’ecriture
- d) Si une expression reguliere compile sans erreur
- e) La completude d’un resume
Voir la reponse
- a) Oui — La pertinence est un critere qualitatif, ideal pour un notateur par modele
- b) Non — La validation JSON doit etre faite par code (
json.loads), c’est deterministe - c) Oui — Le ton et le style sont subjectifs, un modele est bien place pour les evaluer
- d) Non — La compilation regex doit etre verifiee par code (
re.compile), pas par un modele - e) Oui — Evaluer si un resume couvre les points importants est un jugement qualitatif
Regle simple : si c’est verifiable par du code de maniere deterministe, utilisez un notateur par code. Sinon, utilisez un notateur par modele.
Question 5 : Notation par code pour la validation syntaxique
Quelle fonction Python utiliseriez-vous pour valider chacun de ces formats ?
- a) Verifier qu’une sortie est du JSON valide
- b) Verifier qu’une sortie est du code Python syntaxiquement correct
- c) Verifier qu’une sortie est une expression reguliere valide
Voir la reponse
- a)
json.loads(output)— Si ca ne leve pas deJSONDecodeError, le JSON est valide - b)
ast.parse(output)— Si ca ne leve pas deSyntaxError, le Python est syntaxiquement correct - c)
re.compile(output)— Si ca ne leve pas dere.error, la regex est valide
Dans les trois cas, le pattern est le meme : on tente le parsing dans un bloc try/except. Succes = score 10, echec = score 0.
Question 6 : Combiner les scores
Vous avez un notateur par code qui donne 10/10 (le JSON est valide) et un notateur par modele qui donne 4/10 (le contenu du JSON est incorrect). Quel est le score combine et que signifie-t-il ?
Voir la reponse
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 probleme (le contenu n’est pas ce qui etait 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 modele seul aurait donne 4/10 (tout va mal). La combinaison donne une vue equilibree.
Pour ameliorer ce score, il faut travailler le prompt pour ameliorer la qualite du contenu, sans casser le format JSON.