Notation par modèle

Notre pipeline tourne, mais son score = 10 ne mesure rien. Place au juge. Un évaluateur prend la réponse du modèle et renvoie un signal mesurable, en général une note de 1 à 10. C’est la pièce qui transforme des réponses collectées en métrique.

Trois types d’évaluateurs

La documentation d’Anthropic classe ces méthodes ainsi. Le code est le plus rapide et le plus fiable, mais il ne juge que ce qui se vérifie mécaniquement. L’humain juge tout, lentement et cher : à éviter si possible. Le modèle est rapide, souple et adapté aux jugements complexes, à condition de vérifier d’abord qu’il note de façon fiable.

Définir les critères

Avant d’écrire un évaluateur, fixez des critères clairs. Pour notre prompt de code AWS :

• Format : seulement du Python, du JSON ou une regex, sans explication.
• Syntaxe valide : le code produit se lit sans erreur.
• Respect de la tâche : la réponse traite directement la demande, avec un code juste.

Le partage se dessine : les deux premiers critères conviennent à un évaluateur par code, le troisième à un évaluateur par modèle, car juger si une réponse traite la demande exige de comprendre les deux.

Écrire l’évaluateur par modèle

L’évaluateur est lui-même un appel à Claude, avec un verdict garanti par les sorties structurées :

SCHEMA_EVAL = {
    "type": "object",
    "properties": {
        "strengths": {"type": "array", "items": {"type": "string"}},
        "weaknesses": {"type": "array", "items": {"type": "string"}},
        "reasoning": {"type": "string", "description": "Courte justification de la note, en une ou deux phrases"},
        "score": {"type": "integer", "description": "Note de 1 à 10"},
    },
    "required": ["strengths", "weaknesses", "reasoning", "score"],
    "additionalProperties": False,
}


def grade_by_model(test_case, output):
    eval_prompt = f"""
Tu es un expert en revue de code. Évalue cette solution générée par une IA.

<tache>
{test_case["task"]}
</tache>

<solution>
{output}
</solution>

Donne 1 à 3 points forts, 1 à 3 points faibles, une courte justification et une note de 1 à 10.
"""
    messages = []
    add_user_message(messages, eval_prompt)
    eval_text = chat(messages, output_schema=SCHEMA_EVAL)
    return json.loads(eval_text)

Un piège à éviter : dans le code du cours officiel, le prompt d’évaluation contient les marqueurs {task} et {solution}, mais ce n’est pas une f-string. L’évaluateur reçoit donc des accolades au lieu de la tâche et de la solution. Ici, la f-string insère le texte réel, et les balises XML séparent clairement la tâche de la solution (la section 3 y revient).

Pourquoi demander des points forts, des points faibles et une justification en plus de la note ? Selon le cours officiel, sans ce contexte, un modèle a tendance à donner des notes moyennes, autour de 6, quoi qu’il lise. Deux précisions pour les modèles actuels. La documentation d’Anthropic conseille de laisser l’évaluateur réfléchir avant de noter, et Haiku 5.5 le fait par défaut. Et sur plusieurs modèles récents (Fable 5 et 5.1, Opus 5 et 5.5, Sonnet 5.5), exiger dans la sortie la reproduction détaillée du raisonnement peut provoquer un refus : demandez une courte justification, comme ici.

Les bornes 1 et 10 sont écrites dans la description du champ et non par minimum et maximum, que les sorties structurées de Bedrock ne prennent pas en charge (leçon 10). Vérifiez-les dans votre code si vous en dépendez.

Brancher l’évaluateur

Le bouchon score = 10 cède sa place :

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 enregistrement garde la justification du juge à côté de la note, précieuse pour analyser les échecs : la note dit « 4 », la justification dit pourquoi.

La note moyenne

from statistics import mean


def run_eval(dataset):
    results = [run_test_case(test_case) for test_case in dataset]
    average_score = mean(result["score"] for result in results)
    print(f"Note moyenne : {average_score:.2f}")
    return results

Cette moyenne est votre métrique de suivi : chaque version du prompt reçoit son chiffre, chaque modification se compare à la précédente. Les évaluateurs par modèle ne sont pas parfaitement constants ; lancez l’évaluation plusieurs fois avant de conclure sur un petit écart.

À vous de jouer

Juger le juge. Prenez trois réponses de votre évaluation : une bonne, une moyenne, une mauvaise. Notez-les vous-même, puis comparez avec grade_by_model. Lancez l’évaluateur trois fois sur la même réponse : la note varie-t-elle ? De combien ?

Sources officielles : Model based grading (Claude Academy) · Define success criteria and build evaluations et Refusals and fallback (documentation Claude)

Points clés à retenir

• Trois familles d’évaluateurs : par code (rapide, fiable, mécanique), par modèle (souple, à valider), humain (riche, lent).
• Chaque critère va au bon évaluateur : format et syntaxe au code, respect de la tâche au modèle.
• Insérez vraiment la tâche et la réponse dans le prompt d’évaluation : une f-string, pas des accolades nues.
• Demandez points forts, points faibles et une courte justification : le juge note mieux quand il argumente.
• La note moyenne suit vos itérations ; un petit écart se confirme par plusieurs exécutions.