Évaluation par modèle

Notre pipeline exécute les cas de test et collecte les sorties ; il lui manque son juge. Un évaluateur prend la sortie du modèle et renvoie un retour mesurable — typiquement un score de 1 à 10. C’est la pièce qui transforme des réponses en données : sans elle, pas de moyenne, pas de comparaison entre versions, pas d’ingénierie mesurée.

Trois types d’évaluateurs

Trois familles d’évaluateurs existent, aux forces complémentaires :

• Évaluateurs par code : vérification programmatique (longueur, syntaxe, mots interdits)
• Évaluateurs par modèle : un autre appel IA pour évaluer la qualité
• Évaluateurs humains : revue manuelle (flexible mais lente et coûteuse)

Le code est rapide, gratuit et parfaitement reproductible, mais il ne juge que le vérifiable mécaniquement. L’humain juge tout, mais à un coût qui interdit les grandes itérations. L’évaluateur par modèle occupe le milieu : il apprécie des qualités subjectives — pertinence, clarté, respect de la consigne — à un coût qui permet de noter des centaines de sorties. C’est lui que cette leçon implémente.

Critères d’évaluation

Pour notre prompt de génération de code AWS, on pourrait évaluer :

1. Format : la sortie ne contient que du Python, JSON ou Regex, sans explication
2. Syntaxe valide : le code produit a une syntaxe correcte
3. Suivi de la tâche : la réponse correspond bien à la demande

Le partage se fait naturellement : les deux premiers critères conviennent aux évaluateurs par code — un parseur tranche mieux qu’un jugement —, le troisième aux évaluateurs par modèle, car « la réponse traite-t-elle la demande ? » exige de comprendre les deux. Ce découpage par critère, plutôt qu’un choix global, est la marque des pipelines matures.

Implémentation d’un évaluateur par modèle

L’évaluateur est lui-même un appel à Claude — avec les techniques d’extraction que nous connaissons :

def grade_by_model(test_case, output):
    messages = []
    add_user_message(messages, eval_prompt)
    add_assistant_message(messages, "```json")
    eval_text = chat(messages, stop_sequences=["```"])
    return json.loads(eval_text)

Le pré-remplissage et la séquence d’arrêt garantissent un JSON nu, immédiatement parsable. Toute la qualité de l’évaluation repose alors sur eval_prompt, qui doit inclure quatre éléments : le rôle de l’évaluateur, la tâche originale, la solution générée, et le format de sortie attendu. Un conseil issu de la pratique : demandez des forces, des faiblesses et une justification en plus du score. Un modèle sommé de noter sec produit des notes médiocres par défaut — un 7 prudent, quoi qu’il lise ; obligé d’argumenter d’abord, il fonde sa note sur son analyse, et la distribution des scores devient réellement discriminante.

Intégration dans le pipeline

Reste à brancher le juge dans la chaîne :

def run_test_case(test_case):
    output = run_prompt(test_case)
    model_grade = grade_by_model(test_case, output)
    return {
        "output": output,
        "test_case": test_case,
        "score": model_grade["score"],
        "reasoning": model_grade["reasoning"]
    }

Chaque cas de test produit désormais un enregistrement complet : l’entrée, la sortie, le score — et le raisonnement de l’évaluateur, précieux au moment d’analyser les échecs. Calculez la moyenne des scores sur l’ensemble du jeu de données, et vous tenez la métrique objective qui pilotera toute la section suivante : chaque technique d’ingénierie de prompt devra faire monter ce chiffre.

Points clés à retenir

• L’évaluateur convertit chaque sortie en score : c’est lui qui rend l’amélioration mesurable
• Trois familles : code (rapide, objectif, limité), modèle (juge la qualité à grande échelle), humain (riche mais coûteux)
• Affectez chaque critère au bon évaluateur : format et syntaxe au code, pertinence au modèle
• Exigez justification, forces et faiblesses avec la note — un juge qui argumente note mieux
• Sortie JSON via pré-remplissage + stop sequence, moyenne des scores = métrique du prompt