Évaluation par code

Parmi toutes les façons de noter une réponse, l’évaluation par code est la plus fiable et la moins chère : un test écrit en Python donne le même verdict à chaque exécution, instantanément, sans consommer un seul token. Sa limite est tout aussi nette — elle ne peut juger que ce qui se vérifie mécaniquement. Pour notre prompt générateur de code AWS, cela tombe bien : « la sortie est-elle du Python, du JSON ou une regex syntaxiquement valide ? » est une question qu’un programme tranche parfaitement.

Fonctions de validation syntaxique

Le principe est le même pour les trois formats : tenter de parser la sortie avec l’outil standard du langage, et convertir le succès ou l’échec en score.

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:
        return 0

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

Remarquez le choix des outils : ast.parse analyse la syntaxe Python sans exécuter le code — indispensable quand on valide du code généré par un modèle, qu’on ne veut jamais lancer aveuglément. json.loads et re.compile jouent le même rôle pour leurs formats. Le barème binaire — 10 si ça parse, 0 sinon — est assumé : la syntaxe ne connaît pas de demi-mesure, un JSON presque valide est un JSON invalide. Le strip() avant parsing absorbe les sauts de ligne parasites en tête ou en queue de sortie, cause classique de faux échecs.

Format du jeu de données

Pour router chaque sortie vers le bon validateur, le jeu de données doit dire quel format chaque tâche attend. On enrichit donc les cas de test d’un champ format :

{
    "task": "Créer une fonction Python pour valider un username IAM AWS",
    "format": "python"
}

Ce petit champ transforme le validateur en aiguillage : grade_syntax lit test_case["format"] et appelle la fonction correspondante. Si vous avez généré votre jeu de données avec Claude (leçon précédente), il suffit d’ajouter cette exigence au prompt de génération — le générateur remplira le champ lui-même.

Améliorer le prompt

Première leçon concrète de l’évaluation : dès que vous exécutez le pipeline avec ces validateurs, les scores révèlent un problème que la lecture manuelle laissait passer. Claude entoure volontiers son code d’explications — « Voici la fonction demandée : » — et ce texte fait échouer le parsing même quand le code est parfait. La solution se joue dans le prompt évalué, sur deux plans. D’abord des instructions explicites :

* Reponds uniquement avec du Python, du JSON ou une Regex
* N'ajoute aucun commentaire ni explication

Ensuite le pré-remplissage, plus contraignant qu’une consigne :

add_assistant_message(messages, "```code")

En ouvrant nous-mêmes le bloc de code dans le message assistant, on force la réponse à commencer directement par du code. C’est un bel exemple de ce que l’évaluation apporte réellement : le score n’est pas une fin, c’est un révélateur qui oriente les corrections du prompt.

Combiner les scores

La validation syntaxique ne dit rien de la pertinence : une fonction Python parfaitement valide peut résoudre le mauvais problème. C’est pourquoi on la combine avec l’évaluation par modèle vue dans la leçon précédente :

model_score = grade_by_model(test_case, output)["score"]
syntax_score = grade_syntax(output, test_case)

score = (model_score + syntax_score) / 2

La moyenne simple donne un poids égal à la qualité du contenu (jugée par le modèle) et à la correction technique (vérifiée par le code) — un point de départ raisonnable, à ajuster selon vos priorités. Si votre application plante sur toute sortie non parsable, la syntaxe mérite peut-être un poids double, voire un droit de veto : score final nul si le parsing échoue, quelle que soit la qualité du contenu. L’important est que la pondération reflète ce qui compte réellement en production, pas une symétrie esthétique.

Points clés à retenir

• L’évaluation par code est déterministe, instantanée et gratuite — mais ne juge que le vérifiable mécaniquement
• ast.parse, json.loads et re.compile valident la syntaxe sans exécuter le code généré
• Le champ format du jeu de données route chaque sortie vers le bon validateur
• Les échecs de parsing révèlent souvent un problème de prompt — corrigez avec instructions explicites + pré-remplissage
• Combinez score syntaxique et score par modèle avec une pondération qui reflète vos priorités de production