Exécuter l'évaluation

Le jeu de données est prêt ; il est temps de construire le pipeline d’évaluation lui-même. Le processus : prendre chaque cas de test, le fusionner avec le prompt, l’envoyer à Claude, puis noter les résultats. Trois petites fonctions suffisent, chacune avec une responsabilité nette — et cette architecture en couches nous servira jusqu’à la fin de la section.

Les trois fonctions du pipeline

run_prompt : exécution d’un prompt

Cette fonction prend un cas de test et le fusionne avec le modèle de prompt :

def run_prompt(test_case):
    """Fusionne le prompt et l'entrée du cas de test, puis renvoie le résultat"""
    prompt = f"""
Veuillez resoudre la tache suivante :

{test_case["task"]}
"""

    messages = []
    add_user_message(messages, prompt)
    output = chat(messages)
    return output

C’est la seule fonction qui connaisse le contenu du prompt — si vous voulez tester une nouvelle version, c’est ici et seulement ici qu’on la modifie. Le prompt est volontairement minimaliste pour l’instant : sans instructions de formatage, Claude renverra probablement des sorties plus verbeuses que nécessaire — et c’est très bien ainsi, puisque le but est justement de mesurer ce point de départ avant de l’améliorer.

run_test_case : orchestration d’un cas

Cette fonction orchestre l’exécution d’un seul cas de test et la notation du résultat :

def run_test_case(test_case):
    """Appelle run_prompt, puis note le résultat"""
    output = run_prompt(test_case)

    # TODO - Notation
    score = 10

    return {
        "output": output,
        "test_case": test_case,
        "score": score
    }

Le score est fixé à 10 pour l’instant — un bouchon assumé : la logique de notation sera développée dans les leçons suivantes, et l’architecture lui réserve déjà sa place. Remarquez la valeur de retour : un enregistrement complet qui conserve l’entrée, la sortie et le score ensemble — c’est ce format qui rendra les rapports d’évaluation exploitables.

run_eval : orchestrateur principal

Cette fonction traite l’ensemble du jeu de données :

def run_eval(dataset):
    """Charge le jeu de données et appelle run_test_case pour chaque cas"""
    results = []

    for test_case in dataset:
        result = run_test_case(test_case)
        results.append(result)

    return results

Une boucle sans mystère — et c’est sa qualité : chaque étage du pipeline reste simple parce qu’il ne fait qu’une chose. Prompt, cas, jeu de données : trois niveaux, trois fonctions.

Lancer l’évaluation

with open("dataset.json", "r") as f:
    dataset = json.load(f)

results = run_eval(dataset)
print(json.dumps(results, indent=2))

La première exécution prend du temps : même avec Claude Haiku, traiter un jeu de données complet peut nécessiter 30 secondes ou plus — chaque cas de test est un appel API séquentiel. Gardez ce coût en tête : il explique pourquoi on choisit souvent un modèle rapide pour les évaluations, et pourquoi les jeux de données de développement restent de taille raisonnable.

Ce que nous avons accompli

À ce stade, le pipeline de base fonctionne de bout en bout :

• Prendre des cas de test du jeu de données
• Les fusionner avec des modèles de prompts
• Obtenir des réponses de Claude
• Collecter et organiser tous les résultats

La pièce manquante est la notation intelligente — ce score = 10 provisoire qui ne mesure encore rien. C’est là que la sophistication des systèmes d’évaluation entre en jeu : les prochaines leçons construisent les évaluateurs, par modèle puis par code.

Points clés à retenir

• Trois fonctions, trois responsabilités : run_prompt (le prompt), run_test_case (un cas), run_eval (le jeu complet)
• Le prompt de départ est volontairement minimal : on mesure la base avant de l’améliorer
• Chaque résultat conserve entrée + sortie + score — le format des futurs rapports
• Une évaluation coûte du temps et des appels API : modèle rapide et jeu de données raisonnable en développement
• Le score fixe est un bouchon : la notation réelle arrive dans les prochaines leçons