Accelerating Accurate Assignment Authoring Using Solution-Generated Autograders

Imaginez que vous soyez un professeur essayant d'apprendre à une classe de milliers d'élèves comment cuisiner le gâteau au chocolat parfait. Autrefois, pour noter le gâteau de chaque élève, vous deviez les goûter un par un. Mais avec des milliers d'élèves, c'est impossible. Alors, vous construisez un robot cuisinier pour goûter les gâteaux à votre place. Ce robot est un « correcteur automatique ». Habituellement, pour apprendre à ce robot à quoi ressemble un « bon » gâteau, vous devez écrire une liste de règles massive et fastidieuse : « Si le gâteau est trop sec, échouez. S'il est trop sucré, échouez. Si le glaçage est bleu, échouez. » Vous devez deviner chaque erreur possible qu'un élève pourrait commettre et écrire une règle pour elle. Si vous en oubliez une seule, le robot pourrait laisser passer un mauvais gâteau ou, pire, rejeter un gâteau parfait parce que vous avez oublié de lui dire que le glaçage bleu est en fait acceptable pour un gâteau « aux bleuets ». Ce processus d'écriture de règles est lent, ennuyeux et conduit souvent à un robot qui n'est pas très intelligent.

Cet article traite d'une nouvelle façon de construire ce robot cuisinier. Au lieu d'écrire une longue liste de règles, l'enseignant montre simplement au robot le gâteau parfait qu'il a lui-même cuisiné. Le robot utilise ensuite ce gâteau parfait pour comprendre par lui-même ce qu'est un « bon » gâteau. Pour ce faire, il essaie de cuisiner le gâteau de mille façons légèrement « mauvaises » pour voir s'il peut faire la différence entre une vraie erreur et un gâteau parfait. Cette méthode est appelée « correction automatique générée par la solution ». Elle transforme le travail ennuyeux d'écriture de règles en un jeu amusant de « cherche l'erreur », ce qui permet de créer beaucoup plus rapidement de vastes bibliothèques de problèmes d'entraînement pour les étudiants apprenant la programmation.

Le Problème : Le Piège de l'« Écriture de Règles »

Lorsque les étudiants apprennent la programmation, ils doivent s'exercer à résoudre des centaines de puzzles différents. Pour que cela fonctionne, les enseignants ont besoin d'un moyen de vérifier le code des étudiants instantanément. C'est là qu'interviennent les correcteurs automatiques. Traditionnellement, créer un correcteur automatique revient à construire un garde de sécurité qui ne sait repérer que des intrus spécifiques. L'enseignant doit écrire manuellement une liste de cas de test : « Si le code produit 5 quand l'entrée est 2, c'est bien. S'il produit 6, c'est mal. »

Cette approche présente trois grands problèmes. Premièrement, c'est incroyablement fastidieux. Vous devez deviner chaque façon dont un étudiant pourrait se tromper, ce qui revient à essayer de lister chaque façon possible dont quelqu'un pourrait trébucher dans un couloir. Deuxièmement, il est difficile de savoir si votre liste est suffisante. Avez-vous manqué une erreur subtile ? Si vous ne le savez pas, votre correcteur automatique pourrait être imprécis, laissant passer du mauvais code ou échouant sur du bon code. Troisièmement, ces listes de tests sont souvent déroutantes pour les étudiants. Si un test échoue, l'étudiant peut ne pas savoir si c'est son code qui est faux ou si la liste de tests de l'enseignant était simplement mal écrite.

La Solution : La Stratégie du « Gâteau Parfait »

Les auteurs, Geoffrey Challen et Ben Nordick, proposent un tournant ingénieux. Au lieu d'écrire une liste de règles, l'enseignant fournit simplement la solution — le code parfait qui résout le problème. Ils appellent leur outil Questioner.

Voici comment fonctionne Questioner, en utilisant une analogie ludique : Imaginez que l'enseignant remette au robot un gâteau parfait, doré et appétissant (la solution de référence). Le robot ne se contente pas de le regarder ; il commence par essayer de le casser. Il utilise un outil de « mutation » spécial pour introduire de petites erreurs stupides au gâteau parfait. Peut-être qu'il remplace le sucre par du sel, ou change la température du four d'un degré, ou oublie de mélanger les œufs. Ce sont les « mutants ».

Le robot se demande alors : « Puis-je voir la différence entre mon gâteau cassé et le gâteau parfait ? » Il génère des milliers d'ingrédients aléatoires (entrées) pour tester les gâteaux. Si le robot peut percevoir la différence entre le gâteau parfait et le gâteau cassé grâce à ces ingrédients aléatoires, il sait qu'il dispose d'un bon test. S'il ne peut pas voir la différence, il continue de générer des ingrédients aléatoires jusqu'à ce qu'il le puisse.

C'est là toute la magie : le robot utilise la solution parfaite pour s'apprendre à lui-même ce qu'il ne doit pas accepter. Il n'a pas besoin que l'enseignant écrive une liste de « ne pas faire ». Il découvre les limites de la correction en essayant de briser la solution parfaite et en observant ce qui se passe.

Ce Qu'Ils Ont Découvert

L'équipe a construit Questioner pour Java et Kotlin et l'a utilisé pendant quatre ans dans un cours massif d'introduction à l'informatique à l'Université de l'Illinois. Ils ont créé près de 800 questions de programmation qui ont été utilisées par des milliers d'étudiants pour évaluer des millions de soumissions.

Voici les points clés de leur expérience :

• Rapidité et Plaisir : Écrire des questions avec Questioner était beaucoup plus rapide et agréable qu'écrire des suites de tests traditionnelles. Un instructeur a pu écrire environ une nouvelle question par jour de travail pendant trois années consécutives, construisant ainsi une banque de 771 questions.
• Précision : Comme le robot teste par rapport à la solution parfaite réelle, il est très doué pour distinguer le vrai du faux. Lors de leurs quiz, ils n'ont jamais eu à abandonner une question parce que le correcteur automatique était imprécis.
• Feedback Riche : Le système ne se contente pas de dire « Juste » ou « Faux ». Il peut également vérifier la qualité du code. Par exemple, il peut dire si le code d'un étudiant est beaucoup trop complexe (utilisant trop d'étapes) par rapport à la solution simple et élégante. Il peut même vérifier si un étudiant a utilisé une technique spécifique, comme la récursion, si tel était l'objectif de la leçon.
• Gérer les Cas Difficiles : Parfois, les ingrédients aléatoires ne suffisent pas. Par exemple, si un problème nécessite un nombre spécifique comme « 88 » pour fonctionner, le robot pourrait ne jamais le deviner par hasard. Dans ces cas, l'enseignant peut donner au robot une petite liste d'« ingrédients spéciaux » à essayer. Mais même dans ce cas, le robot utilise toujours la solution parfaite pour effectuer la correction, de sorte que l'enseignant n'a pas à rédiger une suite de tests complète.

Pourquoi Cela Importe

Cet article suggère que nous n'avons pas besoin d'être des « énumérateurs de cas de test » pour construire de bons correcteurs automatiques. En laissant la solution elle-même générer les tests, nous pouvons construire des banques de problèmes d'entraînement beaucoup plus rapidement. Cela signifie que davantage d'étudiants peuvent obtenir un feedback immédiat et précis sur leur code, ce qui les aide à apprendre sans rester bloqués par des erreurs déroutantes.

Les auteurs notent également que cela ne concerne pas seulement Java ; ils développent déjà une version pour Python appelée Snapact, et ils explorent même comment utiliser l'IA pour aider à écrire les solutions parfaites initiales. Bien qu'ils admettent qu'aucun système n'est parfait (un étudiant pourrait toujours tenter de contourner le système avec un hack de type « force brute »), leur méthode rend cela beaucoup plus difficile à contourner et beaucoup plus facile pour les enseignants de créer des supports d'apprentissage de haute qualité.

En résumé, au lieu d'écrire un million de règles pour attraper chaque erreur, l'enseignant montre simplement la bonne réponse au robot, et laisse le robot découvrir le reste. C'est une façon plus rapide, plus intelligente et moins frustrante d'enseigner la programmation à la prochaine génération.