Notation par code

Après l’évaluateur par modèle, voici son complément mécanique : la notation par code. Elle vérifie que la réponse respecte le format attendu et que sa syntaxe est valide. Le verdict est déterministe, instantané et gratuit, là où l’évaluateur par modèle coûte un appel par note. C’est l’outil idéal quand on demande du code, du JSON ou des expressions régulières : exactement notre projet AWS.

Deux critères, un barème binaire

1. Format : la sortie contient-elle seulement le format demandé, sans explication ?
2. Syntaxe : la sortie se laisse-t-elle analyser ou compiler sans erreur ?

Si l’analyse réussit, la note est 10 ; si elle échoue, 0. Le barème binaire est assumé : un JSON « presque valide » est un JSON invalide, qui plantera un parseur exactement comme du charabia.

Les fonctions de validation

import ast
import json
import re


def validate_json(text):
    try:
        json.loads(text.strip())
        return 10
    except json.JSONDecodeError:
        return 0


def validate_python(text):
    try:
        ast.parse(text.strip())
        return 10
    except (SyntaxError, ValueError):
        return 0


def validate_regex(text):
    try:
        re.compile(text.strip())
        return 10
    except re.error:
        return 0

Le même motif trois fois : tenter d’analyser, convertir le succès ou l’échec en note. json.loads valide le JSON, ast.parse construit l’arbre syntaxique d’un code Python, re.compile compile une expression régulière. Un point mérite d’être souligné : ast.parse analyse le code sans l’exécuter, indispensable quand on valide du code généré, qu’on ne lance jamais à l’aveugle. Il lève SyntaxError sur une syntaxe fausse ; depuis Python 3.12, c’est aussi le cas pour un octet nul, qui levait ValueError auparavant, d’où les deux exceptions attrapées. La documentation de Python rappelle toutefois qu’une analyse réussie ne garantit pas que le code se compile et s’exécute. strip() retire les sauts de ligne en bordure, cause classique de faux échecs.

Le format attendu dans le jeu de données

Pour aiguiller chaque réponse vers le bon validateur, chaque cas de test doit indiquer son format. On l’ajoute au schéma de génération de la leçon 13, avec une liste fermée de valeurs :

SCHEMA_DATASET = {
    "type": "object",
    "properties": {
        "taches": {
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "task": {"type": "string"},
                    "format": {"type": "string", "enum": ["python", "json", "regex"]},
                },
                "required": ["task", "format"],
                "additionalProperties": False,
            },
        }
    },
    "required": ["taches"],
    "additionalProperties": False,
}

Régénérez le jeu de données avec ce schéma. L’aiguillage tient alors en un dictionnaire, une fonction que le cours officiel utilise sans la montrer :

VALIDATORS = {"json": validate_json, "python": validate_python, "regex": validate_regex}


def grade_syntax(output, test_case):
    return VALIDATORS[test_case["format"]](output)

Améliorer le prompt

Dès la première exécution, cet évaluateur révèle un défaut : Claude entoure volontiers son code d’explications ou de balises de bloc Markdown, et ce texte fait échouer l’analyse même quand le code est parfait. Le remède : des consignes précises, dans un prompt système.

SYSTEM_CODE = """Réponds uniquement avec du Python, du JSON ou une expression régulière brute.
N'ajoute ni commentaire, ni explication, ni balises de bloc de code."""


def run_prompt(test_case):
    prompt = f"""
Résous la tâche suivante :

{test_case["task"]}
"""
    messages = []
    add_user_message(messages, prompt)
    return chat(messages, system=SYSTEM_CODE)

Le cours officiel suggère aussi le pré-remplissage avec séquence d’arrêt, que Haiku 5.5 refuse. Si une explication se glisse malgré la consigne, faites porter le code par un champ d’une sortie structurée, par exemple {"code": "..."}, et validez ce champ.

Combiner les notes

La validation syntaxique ne dit rien de la pertinence : une fonction Python valide peut résoudre le mauvais problème. On combine donc les deux évaluateurs :

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

La moyenne simple donne un poids égal au fond (le modèle) et à la forme (le code). Ajustez la pondération à votre cas : si une sortie illisible plante votre application, la syntaxe mérite peut-être un droit de veto, une note de 0 quoi que dise le modèle. Et gardez la perspective : une note isolée dit peu de chose, c’est la comparaison entre versions qui compte.

À vous de jouer

Avant, après. Lancez l’évaluation sans SYSTEM_CODE, puis avec. Comparez la note syntaxique moyenne des deux versions et lisez une réponse qui échouait : qu’est-ce qui faisait échouer l’analyse ?

Un droit de veto. Modifiez run_test_case pour que la note finale soit 0 dès que la syntaxe échoue. Comment évolue la moyenne ?

Sources officielles : Code based grading (Claude Academy) · Define success criteria and build evaluations (documentation Claude) · ast, Abstract Syntax Trees (documentation Python)

Points clés à retenir

• La notation par code est déterministe et gratuite, mais ne juge que ce qui se vérifie mécaniquement.
• json.loads, ast.parse, re.compile : l’analyseur natif sert de validateur ; ast.parse n’exécute jamais le code.
• Le champ format du jeu de données aiguille chaque réponse vers son validateur.
• Les consignes de format vont dans le prompt système ; le pré-remplissage du cours officiel est refusé par Haiku 5.5.
• Combinez fond (modèle) et forme (code) avec une pondération qui reflète votre production.