Un enseignant a créé un bot pour corriger l’EGE : le modèle annote, le code calcule les points

Que se passe-t-il si l’on confie à un modèle de langage la notation de la réponse longue d’un élève ? Il se montrera généreux : « dans l’ensemble, il comprend les sciences sociales », alors que les critères du FIPI sont stricts. Un exemple portant sur un « État Z » au lieu de la Russie vaut zéro, et un plan auquel il manque trois éléments obligatoires perd tous les points du critère. Un enseignant et expert de l’EGE explique comment il a consacré deux ans à construire un bot qui tient compte de ces contraintes.

Le modèle annote, le code calcule

Le principe central : le modèle n’écrit pas « j’attribue 2 points parce que… ». Il remplit un schéma JSON via tool_use : quels exemples sont concrets, quels jugements sont corrects et quels éléments du plan sont essentiels. Ensuite, du code classique prend le relais : il recalcule les points selon les critères, vérifie tout ce qui peut l’être sans modèle et lance des contre-vérifications qui ne peuvent que réduire la note.

Chaque exercice possède son propre plugin : un gestionnaire, un évaluateur et une spécification. Il n’existe pas de prompt universel. Le volume de code le montre bien : l’exercice 17 occupe 942 lignes, tandis que les exercices 24 et 25 en comptent chacun entre 6 800 et 7 200. Plus les critères sont complexes, plus il faut de code autour du modèle, et non un prompt plus long.

Comment ne pas pénaliser un innocent

Dans l’exercice 19, le modèle considérait la reformulation de la fonction d’un organisme comme un exemple de son action. L’auteur a ajouté un second appel avec un schéma distinct, mais la première version se déclenchait partout et retirait des points dans les réponses sur les familles et les citoyens, alors qu’aucun organisme ne figurait dans l’énoncé. Désormais, la contre-vérification ne s’active qu’en présence de marqueurs explicites dans le texte de l’exercice. En outre, un exemple n’est rejeté que si au moins deux des quatre indicateurs négatifs concordent. Leçon : une protection contre la surévaluation peut elle-même provoquer une sous-évaluation, et son périmètre d’activation est aussi important que la vérification elle-même.

Dans l’exercice 24, les points des premier et deuxième critères sont entièrement calculés par le code : lemmatisation avec pymorphy2 et comparaison avec 185 plans de référence. Les synonymes utilisés dans les titres, comme « caractéristiques » et « particularités », sont normalisés sous une même forme. Le test est simple : tous les plans de référence doivent obtenir le maximum. Avant la correction des synonymes, c’était le cas pour 147 plans sur 185 ; désormais, ils réussissent tous.

Un point pour erreur factuelle ne peut être retiré qu’après le passage de quatre filtres : une liste fermée de types d’erreurs, une citation littérale d’au moins 8 caractères, deux exécutions indépendantes et un vérificateur séparé. Ce dernier est nécessaire parce que deux réponses identiques d’un même modèle ne constituent pas deux avis indépendants : sur les plans de référence, les deux exécutions détectaient systématiquement la même erreur inexistante.

Un refus honnête plutôt qu’un zéro inventé

L’erreur la plus insidieuse est le zéro silencieux : le modèle ne répond pas, le code insère un zéro et l’élève voit une analyse apparemment normale. Dans l’exercice 25, 16 zéros de ce type ont été relevés sur 110 cas ; la moitié correspondait à la référence et était donc comptabilisée dans les métriques comme une prédiction exacte. Désormais, toute panne déclenche le drapeau ai_unavailable : la note n’est pas affichée, la tentative n’est pas débitée et l’administrateur reçoit une alerte. La tentative gratuite n’est débitée qu’après la remise du résultat.

L’auteur reconnaît franchement les lacunes restantes : dans les exercices 21 et 23, une note simplifiée est encore attribuée en cas de panne, tandis que le modèle de secours YandexGPT doit être activé manuellement.

Coût et conclusion pratique

L’exécution de novembre sur 393 réponses a généré 497 appels pour un coût de 8,87 dollars : en moyenne, 1,26 appel, 2,3 cents et 9 secondes par correction. Les opérations les plus coûteuses ne sont pas les longues évaluations, mais les contre-vérifications. Le cache de prompt couvre jusqu’à 66 % de l’entrée, mais il ne s’active pas sur les prompts courts des exercices 17, 21 et 22.

Pour ceux qui conçoivent une évaluation fondée sur un LLM : imposez au modèle une réponse structurée avec des indicateurs explicites, conservez l’arithmétique dans le code, rendez les contre-vérifications unidirectionnelles, exigez l’indépendance des exécutions et distinguez une panne d’un zéro. Sur les nouvelles versions de Claude, un tool_choice forcé renvoie une erreur 400 ; utilisez donc auto et demandez au modèle d’appeler l’outil à la fin du prompt.