What Bugs Do Prolog Students Write? An Empirical Taxonomy and Data-Driven Mutation Framework
Dit artikel presenteert LogMorph, een datagestuurd mutatiekader voor Prolog dat een empirische taxonomie van 7.201 studenteninzendingen benut om realistische synthetische fouten te genereren met foutdistributies die nauw aansluiten bij werkelijke fouten in de klas, waardoor de effectiviteit van geautomatiseerde feedbacktools in het onderwijs in logisch programmeren wordt verbeterd.
Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
Stel je voor dat je een robot probeert te leren om te denken als een menselijke detective. Je vertelt hem niet alleen "los de misdaad op"; je moet hem de specifieke, eigenzinnige regels van de logica leren die bepalen hoe aanwijzingen in elkaar passen. Dit is de wereld van Logische Programmering, een manier om computercode te schrijven waarbij je beschrijft wat waar is, in plaats van hoe je het stap voor stap doet. Het is alsoal een kaart van een stad geven in plaats van rijinstructies bocht voor bocht. Maar hier komt de crux: mensen zijn slordig. Wanneer we deze regels proberen te leren, maken we zeer specifieke, voorspelbare fouten. We kunnen een regel vergeten, twee aanwijzingen door elkaar halen, of een "stopbord" op de verkeerde plek plaatsen.
Om een behulpzame robot-tutor te bouwen die onze code kan corrigeren, moeten we precies weten wat voor soort fouten wij maken. Als de robot alleen oefent met willekeurige, verzonnen fouten, zal hij in de war raken wanneer hij een echte student ontmoet. Het is als een rijinstructeur die alleen oefent met auto's met een lekke band, om vervolgens verrast te worden wanneer een leerling vergeet de gordel om te doen. Dit artikel duikt in de rommelige realiteit van studentenfouten om een betere trainingsgrond te creëren voor deze AI-tutors.
De Grote Prolog Bug Hunt
In een recente studie besloten onderzoekers detective te spelen, maar in plaats van naar criminelen te zoeken, waren ze op zoek naar bugs in computercode. Ze bekeken 7.201 code-inzendingen van 265 bachelorstudenten die een taal genaamd Prolog leerden. Denk aan Prolog als een taal waarbij je een lijst met feiten en regels schrijft, en de computer de antwoorden uitrekent. De studenten losten puzzels op, van eenvoudige logische spellen tot een eindproject waarbij ze een solver bouwden voor een complex bordspel genaamd "Star Battle".
Het team telde niet alleen hoeveel programma's faalden; ze wilden weten waarom. Ze kozen 200 inzendingen waarbij studenten een fout hadden hersteld en sorteerden de fouten handmatig in een "taxonomie", wat gewoon een chic woord is voor een gedetailleerd archiefsysteem. Ze ontdekten dat de meest voorkomende fout geen ingewikkelde logische fout was, maar simpelweg onvolledig werk. Ongeveer 37,5% van de tijd vergat een student een volledig deel van de puzzel te schrijven, zoals een ontbrekend hoofdstuk in een verhaal. De volgende meest voorkomende fouten waren het gebruik van de verkeerde ingrediënten (20,5%) of het door elkaar halen van de doelen in een regel (13,0%). Interessant genoeg merkten ze op dat studenten zelang de soort "slordige" typfouten maakten die mensen in andere talen maken; hun fouten waren vaak diepgaande misverstanden over hoe de logica werkte.
Het Bouwen van de "Bug Fabriek" (LOGMORPH)
Weten welke fouten studenten maken is geweldig, maar hoe leer je een computer die te herkennen? De onderzoekers bouwden een tool genaamd LOGMORPH. Stel je een fabriek voor die een perfect, werkend stuk code neemt en het opzettelijk kapot maakt.
Oude fabrieken probeerden dingen willekeurig kapot te maken, zoals pijltjes gooien op een bord. Ze gingen ervan uit dat elk type breuk even waarschijnlijk was. Maar LOGMORPH is anders. Het is een data-gestuurde fabriek. Het kijkt naar de "archiefkast" van echte studentenfouten die de onderzoekers eerder hebben gebouwd en zegt: "Oké, aangezien studenten 37,5% van de tijd vergeten hun code af te maken, laten we de code op die manier 37,5% van de tijd breken."
De tool werkt in vier stappen:
- Scannen: Het leest de perfecte code en vindt elke plek waar een fout zou kunnen optreden.
- Steekproef (Sampling): Het kiest een plek om te breken, maar doet dit op basis van de echte studentenstatistieken. Als "het vergeten van een clausule" veel voorkomt, wordt dat ook vaak gekozen.
- Injecteren: Het breekt de code daadwerkelijk. Soms is dit makkelijk, zoals het omwisselen van twee getallen. Andere keren moet het een nieuw stuk code verzinnen om in te voegen. Hiervoor gebruikt het een slimme "synthesizer" (een type AI) om een nieuwe regel code te genereren die binnen de regels past.
- Testen: Het controleert of de kapotte code daadwerkelijk faalt bij de tests. Als de "kapotte" code nog steeds perfect werkt, gooit de fabriek het weg en probeert het opnieuw.
De Resultaten: Een Bijna Perfecte Spiegel
Het team draaide deze fabriek om 16.000 nep, buggy programma's te maken. Ze vergeleken het "foutprofiel" van deze nep-programma's vervolgens met de echte studentendata. De resultaten waren verrassend dichtbij. Voor de meeste categorieën van fouten kwamen de nep-programma's binnen twee procentpunten overeen met de echte programma's. Het was alsocht kijken in een spiegel en zien dat je reflectie exact dezelfde manier beweegt.
De spiegel was echter niet perfect. De onderzoekers merkten twee belangrijke defecten op:
- Het "Cut"-probleem: In Prolog is er een speciaal symbool genaamd een "cut" (geschreven als
!) dat de computer vertelt te stoppen met het zoeken naar andere antwoorden. Studenten maken dit vaak fout. Maar in de nep-programma's kwamen deze fouten zelden voor. Waarom? Omdat de "test"-stap van de fabriek te streng was. Als een nep-cut de testresultaten niet veranderde, gooide de fabriek het weg. Echte studenten kunnen een fout maken met een cut die de test niet breekt, maar de logica wel in de war stuurt, maar de fabriek filterde die eruit. - De "Robot"-code: Wanneer de fabriek nieuwe code moest verzinnen (zoals het toevoegen van een willekeurig doel), schreef de "synthesizer" soms dingen die technisch correct waren, maar klonken als onzin. Het vergeleek bijvoorbeeld een lege lijst met een variabele met behulp van een wiskundig symbool. Geen menselijke student zou dat ooit schrijven; het leek op een robot die probeert mens te spreken. De onderzoekers vermoeden dat als ze de synthesizer zouden vervangen door een geavanceerdere AI die getraind is op studentenschrijfwijzen, de nep-code veel natuurlijker zou klinken.
Wat dit betekent
Het artikel beweert niet dat het alle problemen van het onderwijzen van logische programmering heeft opgelost. In plaats daarvan biedt het een nieuwe, veel betere manier om studentenfouten te simuleren. Door echte data te gebruiken om de fouten te wegen, creëert LOGMORPH een realistische trainingsgrond voor geautomatiseerde tutoring-systemen. De onderzoekers suggereren dat het in de toekomst combineren van deze data-gestuurde aanpak met slimmere AI-taalmodellen deze trainingsinstrumenten nog levendiger kan maken, waardoor robots niet alleen begrijpen dat een student fout zit, maar ook waarom ze die specifieke, menselijke fout hebben gemaakt.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.