Evaluating LLMs in the Context of a Functional Programming Course: A Comprehensive Study

Each language version is independently generated for its own context, not a direct translation.

Stel je voor dat je een nieuwe taal leert, zoals een vreemde taal of een instrument. Vroeger moest je dit alleen doen met een boek, een leraar en veel oefening. Vandaag de dag hebben we echter een nieuwe, slimme assistent: een LLM (een "Groot Taalmodel"). Dit is een supercomputer die alles heeft gelezen wat er op internet staat en nu lijkt te kunnen praten, schrijven en zelfs coderen in bijna elke taal.

Maar hoe goed is deze assistent echt? En kan hij helpen als je een moeilijke, specifieke taal leert, zoals OCaml (een programmeertaal die veel gebruikt wordt in de academische wereld, maar die minder bekend is dan Python of Java)?

Dit is precies wat drie onderzoekers van de universiteiten McGill en Toronto hebben onderzocht in hun paper. Ze hebben een soort "proefexamen" opgezet om te zien of deze slimme computers echt kunnen helpen bij het leren van functioneel programmeren, of dat ze alleen maar mooie, maar foutieve antwoorden geven.

Hier is een samenvatting van hun onderzoek, vertaald naar alledaagse taal:

1. De Drie Proefexamens (De "Benchmarks")

De onderzoekers hebben drie verschillende soorten taken bedacht om de AI te testen, net als een leraar die een student op verschillende manieren wil beoordelen:

λCodeGen (De Bouwopdracht): Hierbij kreeg de AI een opdracht in gewone taal (bijvoorbeeld: "Schrijf een functie die een boomstructuur doorzoekt") en moest het de code schrijven.
- De analogie: Het is alsof je de AI vraagt: "Bouw me een huis" en je kijkt of het een stevig huis bouwt of een kartonnen doos.
λRepair (De Reparatieklus): De AI kreeg stukken code die fout waren (met fouten in de spelling, de logica of de structuur) en moest ze fixen.
- De analogie: Je geeft de AI een kapotte auto en vraagt: "Maak deze weer rijvaardig."
λExplain (De Theorieles): De AI moest vragen beantwoorden over de theorie achter het programmeren (bijvoorbeeld: "Wat is het verschil tussen 'call-by-value' en 'call-by-name'?").
- De analogie: Je vraagt de AI: "Leg uit waarom de lucht blauw is," zonder dat je een auto of huis hoeft te bouwen.

2. De Resultaten: Een Slimme, maar Onvolmaakte Hulp

De onderzoekers testten 9 verschillende AI-modellen (zoals GPT-4o, Claude 3.7, en open-source modellen). Hier zijn de belangrijkste bevindingen:

De Top 3 zijn sterk, maar niet perfect

De allerbeste modellen (zoals GPT-4o en o3-mini) deden het verrassend goed. Ze konden ongeveer 70% van de programmeeropdrachten perfect maken.

Maar: In de populaire talen Python en Java scoren ze vaak 90% of meer. In deze moeilijkere, minder bekende taal (OCaml) zakken ze iets. Het is alsof een topkok die perfect Italiaans pasta kan maken, moeite heeft met een heel specifiek, regionaal gerecht dat hij minder vaak heeft geoefend.

Repareren is makkelijker dan Bouwen

Het bleek dat de AI's veel beter zijn in het repareren van bestaande code dan in het bouwen van nieuwe code van nul af.

De analogie: Als je een auto hebt die niet start, kan de AI vaak snel zien dat de bougie los zit en die vastdraaien. Maar als je vraagt om een nieuwe auto te ontwerpen, maakt hij soms fouten in het ontwerp.
Ze zijn vooral goed in het oplossen van simpele fouten (zoals een vergeten puntkomma of een typefout). Bij complexe, logische fouten (waar de code wel werkt, maar het niet doet wat je wilt) hebben ze meer moeite.

De Theorie is lastig

Bij het uitleggen van abstracte theorieën (het "waarom" achter de code) deed het het goed, maar niet perfect.

Het probleem: De AI's zijn vaak erg luidruchtig. Ze geven het juiste antwoord, maar dan met een heel lang verhaal eromheen dat niet nodig is.
De analogie: Het is alsof je vraagt: "Hoeveel is 2+2?" en de AI antwoordt: "Nou, laten we eerst kijken naar de geschiedenis van de wiskunde, dan de betekenis van het getal 2, en uiteindelijk zeggen we dat het 4 is." Het antwoord is goed, maar het is vermoeiend om te lezen.

Kleine modellen zakken door het ijs

De kleinere, gratis modellen (zoals Llama 3.1 8B) deden het veel slechter. Vaak gaven ze code die niet eens werkte (het "huis" viel in elkaar).

De les: Je kunt niet zomaar elke AI gebruiken voor complexe taken. Je hebt een "zware" versie nodig voor zware klussen.

3. Wat betekent dit voor studenten en leraren?

Voor studenten: Gebruik de AI als een tutor, niet als een krabbel. Als je de code van de AI direct overneemt zonder te kijken, loop je het risico dat je een fout leert. Je moet kritisch blijven: "Begrijp ik dit antwoord echt, of is het gewoon een mooi verhaal?"
Voor leraren: De AI is een krachtig hulpmiddel, maar het is geen toverstaf. Leraren moeten studenten leren om de AI te controleren. Misschien is het een betere opdracht om de AI te vragen om een fout te maken, zodat de student die moet vinden?
Voor de toekomst: De AI's worden steeds beter, maar voor moeilijke, specifieke vakken (zoals deze programmeertaal) zijn ze nog niet 100% betrouwbaar. Ze zijn handig als "one-stop shop" voor veel talen, maar voor de allerbeste resultaten in een specifieke taal zijn er soms nog speciale tools nodig.

Conclusie in één zin

Deze slimme computers zijn als een zeer intelligente, maar soms overenthousiaste assistent: ze kunnen je enorm helpen met het oplossen van problemen en het uitleggen van concepten, maar je moet ze nooit blindelings vertrouwen, vooral niet als je een moeilijke, specifieke taal leert. Je bent nog steeds de kapitein van je eigen schip; de AI is slechts de navigatiecomputer.

Each language version is independently generated for its own context, not a direct translation.

Hier is een gedetailleerde technische samenvatting van het artikel "Evaluating LLMs in the Context of a Functional Programming Course: A Comprehensive Study", geschreven in het Nederlands.

Probleemstelling

Grote Taalmodellen (LLMs) worden steeds vaker gebruikt door studenten om code te schrijven, fouten op te lossen en concepten te verklaren. Eerdere studies hebben aangetoond dat LLMs redelijk effectief zijn voor korte en simpele vragen in inleidende computerwetenschapscursussen, voornamelijk met hoge-resource programmeertalen zoals Python en Java.

Er is echter een kritiek gat in de kennis over de prestaties van LLMs in functionele programmeertalen (zoals OCaml) en in lage-resource omgevingen. Deze talen hebben minder trainingsdata en vereisen vaak dieper theoretisch inzicht (bijv. type-inferentie, continuaties, semantiek). De auteurs stellen de vraag of LLMs betrouwbaar genoeg zijn voor studenten in geavanceerde functionele programmeercursussen, of ze fouten correct kunnen repareren, en of ze theoretische concepten accuraat kunnen uitleggen zonder hallucinaties of onnodige verbaaliteit.

Methodologie

De studie is uitgevoerd in de context van een tweedejaars functionele programmeercursus aan de McGill University, met OCaml als voertaal. De auteurs hebben drie specifieke benchmarks ontwikkeld om negen state-of-the-art LLMs (waaronder GPT-4o, o3-mini, Claude 3.7 Sonnet, Llama 3.1, en Qwen2.5) te evalueren.

De Benchmarks:

$\lambda$ CodeGen: Bestaat uit 10 huiswerkopdrachten met in totaal 53 taken. Deze variëren van basisconcepten (patroonmatching, recursie) tot geavanceerde technieken (continuatie-passende stijl, lazy programming) en theorie van programmeertalen (interpreteren, typechecking).
- Evaluatie: Code wordt automatisch getest via een compiler en autograder, gevolgd door een handmatige beoordeling door ervaren teaching assistants op drie criteria: correctheid, algoritme-ontwerp en leesbaarheid.
$\lambda$ Repair: Bestaat uit 150 defecte programma's afkomstig van echte studentenindieningen. Deze zijn onderverdeeld in drie categorieën: syntaxisfouten, typefouten en logische fouten.
- Evaluatie: De modellen krijgen de defecte code en de bijbehorende compiler-foutmelding (zero-shot setting). De prestaties worden gemeten op het vermogen om de code te repareren zonder nieuwe fouten in te voeren.
$\lambda$ Explain: Bestaat uit 50 conceptuele vragen over theoretische onderwerpen (bijv. scope, substitutie, evaluatiestrategieën).
- Evaluatie: Handmatige beoordeling op begrip van het probleem, strategie en duidelijkheid van de uitleg.

Beoordelingsframework:
De auteurs gebruiken een hiërarchische beoordelingsschaal: Mastery (Meesterschap), Proficient, Developing, Beginning, en Non-gradable. Correctheid is een voorwaarde voor de andere criteria. De resultaten worden omgezet in een lettergrade (A t/m F) om vergelijkingen mogelijk te maken.

Belangrijkste Bijdragen

Specifieke Benchmarks voor Functionele Programmeertalen: De eerste uitgebreide evaluatie van LLMs specifiek gericht op OCaml en functionele paradigma's, in tegenstelling tot de gebruikelijke benchmarks voor imperatieve talen.
Combinatie van Automatische en Handmatige Beoordeling: In tegenstelling tot veel eerdere studies die zich puur richten op "pass@k" (doorgaan van testcases), voegen de auteurs een kwalitatieve, handmatige beoordeling toe om algoritme-ontwerp, leesbaarheid en verbaaliteit te evalueren.
Uitgebreide Vergelijking: Een vergelijking van 9 verschillende modellen (zowel gesloten als open-source, variërend in grootte) over drie verschillende taaktypes (genereren, repareren, uitleggen).
Vergelijking met Gespecialiseerde Tools: De studie vergelijkt LLMs met gespecialiseerde code-synthesetools (zoals BURST voor OCaml) om de trade-offs tussen flexibiliteit en garanties te onderzoeken.

Resultaten

Algemene Prestaties:

De top-3 modellen (o3-mini, Claude 3.7 Sonnet, en GPT-4o) presteren consistent goed, maar bereiken zelden een perfect score. Ze halen ongeveer 70% "Mastery" bij codegeneratie, wat aanzienlijk lager is dan de >90% die vaak wordt gezien in Python/Java benchmarks.
Kleinere modellen (zoals Llama 3.1 8B en Qwen2.5 7B) presteren aanzienlijk slechter, met vaak meer dan 50% van de antwoorden die als "Non-gradable" (niet compileerbaar) worden beoordeeld.

Per Taaktype:

Code Generatie ( $\lambda$ CodeGen): Dit is de moeilijkste taak. Zelfs de beste modellen scoren gemiddeld een B. Ze worstelen met complexe taken zoals continuaties en multi-stap redenering. Gespecialiseerde tools (BURST) presteren hier slechter (11,3% correct) omdat ze minder flexibel zijn, maar wel betrouwbaarder zijn binnen hun beperkte domein.
Code Reparatie ( $\lambda$ Repair):
- Syntaxisfouten: LLMs zijn zeer effectief (>78% Mastery voor topmodellen), vaak beter dan gespecialiseerde tools.
- Typefouten: Prestaties dalen iets, maar topmodellen blijven sterk. Open-source modellen tonen hier een grotere daling.
- Logische Fouten: Dit is het lastigst. Topmodellen halen ~60-70% Mastery, maar lagere modellen worstelen hier sterk.
- One-shot learning: Het toevoegen van één voorbeeld verbeterde de prestaties lichtelijk, vooral voor de kleinere modellen.
Conceptuele Uitleg ( $\lambda$ Explain):
- Er is een groot verschil tussen modellen. o3-mini scoort hier het beste (A-), maar veel andere modellen struggle met theoretische concepten.
- Een veelvoorkomend probleem is overmatige verbaaliteit (te lange, onnodige uitleg), zelfs wanneer expliciet om beknopte antwoorden wordt gevraagd.
- Studenten kunnen de correctheid van deze uitleg vaak niet verifiëren, wat een risico vormt.

Invloed van Moeilijkheidsgraad:
Modellen presteren beter op basisvragen dan op geavanceerde theoretische vragen (zoals type-inferentie en substitutie). Bij theorievragen daalt de "Mastery"-rate voor zwakkere modellen naar 0%.

Betekenis en Implicaties

Voor Studenten: LLMs zijn nuttige hulpmiddelen voor basisconcepten en het oplossen van syntaxis/typefouten, maar ze zijn niet betrouwbaar genoeg voor complexe logische problemen of theoretische uitleg zonder kritische evaluatie. Studenten moeten leren om de output te verifiëren en niet blindelings te vertrouwen.
Voor Docenten: De benchmarks bieden een concrete manier om studenten bewust te maken van de beperkingen van AI. Assessments kunnen worden aangepast om meer focus te leggen op het kritisch beoordelen, debuggen en verifiëren van AI-generaties in plaats van alleen het schrijven van code.
Voor Onderzoekers: De studie toont aan dat er ruimte is voor verbetering in het integreren van domeinspecifiek redeneren (zoals type-theorie) in LLMs. Het suggereert dat gespecialiseerde tools en LLMs complementair kunnen zijn: gespecialiseerde tools voor garanties in kleine domeinen, en LLMs voor flexibiliteit in bredere, open-ended taken.

Concluderend tonen de auteurs aan dat LLMs een grote stap voorwaarts zijn, maar in de context van functioneel programmeren nog niet volledig betrouwbaar zijn voor geavanceerde taken, vooral in lage-resource talen.