💻 computer science

Learned or Memorized ? Quantifying Memorization Advantage in Code LLMs

Deze studie introduceert een verstoring-gebaseerde methode om het memorisatievoordeel in code-LLMs te kwantificeren en onthult dat dit risico sterk afhankelijk is van het model en de taak, waarbij veelgebruikte benchmarks zoals CVEFixes en Defects4J juist een lage memorisatie tonen die wijst op generalisatie in plaats van directe opslag.

Oorspronkelijke auteurs: Djiré Albérick Euraste, Kaboré Abdoul Kader, Jordan Samhi, Earl T. Barr, Jacques Klein, Tegawendé F. Bissyandé

Gepubliceerd 2026-04-16

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Djiré Albérick Euraste, Kaboré Abdoul Kader, Jordan Samhi, Earl T. Barr, Jacques Klein, Tegawendé F. Bissyandé

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

🧠 De Grote Vraag: Leren of Leren?

Stel je voor dat je een student hebt die een examen moet maken.

Leren (Generalization): De student begrijpt de regels van wiskunde. Als de leraar een nieuw soort som geeft, kan de student het oplossen omdat hij het principe snapt.
Leren (Memorization): De student heeft de antwoorden van het oude examen uit zijn hoofd geleerd. Als de leraar de vraag net iets anders stelt (bijvoorbeeld "3 + 4" in plaats van "4 + 3"), raakt de student in paniek en faalt hij, omdat hij alleen het specifieke antwoord uit zijn hoofd kent.

Dit onderzoek kijkt naar AI-modellen voor programmeren (zoals die van Google, Meta of Microsoft). De grote vraag is: Bouwen deze AI's echt een begrip van code op, of hebben ze gewoon de antwoorden van hun "huiswerk" (de trainingsdata) uit hun hoofd geleerd?

🕵️‍♂️ De Oplossing: De "Knikker-test"

Omdat we niet kunnen zien wat er in de computer van de AI zit, hebben de onderzoekers een slimme truc bedacht: de "Knikker-test" (Perturbation).

Stel je voor dat je een AI een programmeertaak geeft.

De originele vraag: "Schrijf een functie die getallen optelt."
De knikker-test: De onderzoekers veranderen de vraag heel klein beetje, maar de betekenis blijft hetzelfde. Bijvoorbeeld: "Schrijf een functie die de som berekent van de getallen." Of ze hernoemen variabelen in de code.

Als de AI het echt begrijpt: Hij geeft het juiste antwoord, ongeacht hoe de vraag net iets anders is gesteld. Hij is robuust.
Als de AI het uit zijn hoofd heeft geleerd: Hij raakt in de war door de kleine verandering en geeft een fout antwoord. Hij is gevoelig.

De onderzoekers noemen dit de "Memorization Advantage" (het voordeel van het uit het hoofd leren). Als de AI veel beter presteert op de originele vraag dan op de "knikker-versie", betekent dit dat hij waarschijnlijk heeft gememoriseerd.

🔍 Wat hebben ze ontdekt?

De onderzoekers hebben 8 populaire AI-modellen getest op 19 verschillende taken (zoals het schrijven van code, het vinden van fouten, of het vinden van beveiligingslekken). Hier zijn de belangrijkste resultaten:

1. Niet alle AI's zijn hetzelfde

Sommige modellen (zoals StarCoder) reageerden heel gevoelig op kleine veranderingen op bepaalde tests. Het was alsof ze de antwoorden van dat specifieke examen uit hun hoofd hadden geleerd. Andere modellen (zoals QwenCoder en CodeLlama) waren veel stabieler; ze begrepen de regels en gaven het juiste antwoord, zelfs als de vraag net iets anders klonk.

2. De "Veiligheidstest" was verrassend goed

Er was veel paniek in de wereld dat populaire testsets voor beveiligingslekken (zoals CVEFixes) misschien al in de trainingsdata zaten, waardoor de AI's alleen maar de antwoorden uit hun hoofd hadden geleerd.
Het verrassende nieuws: De AI's waren hier juist heel goed in! Ze gaven het juiste antwoord, zelfs als de vraag veranderde. Dit betekent dat ze waarschijnlijk de principes van beveiligingslekken hebben geleerd, en niet alleen de specifieke antwoorden. Ze hebben echt iets begrepen.

3. Sommige taken zijn gewoon moeilijker

Samenvatten van code: Dit ging overal heel goed. De AI's konden code heel goed vertalen naar menselijke taal, zelfs als de code net iets anders was. Dit lijkt een taak te zijn waar ze echt goed in zijn geworden.
Het schrijven van tests: Dit was de moeilijkste taak. Hier faalden de AI's het snelst bij kleine veranderingen. Het lijkt erop dat het schrijven van testcases voor code nog te complex is voor de huidige AI's om volledig te "begrijpen" zonder te memoriseren.

💡 Waarom is dit belangrijk?

Stel je voor dat je een AI gebruikt om beveiligingslekken in banksoftware te vinden.

Als de AI alleen maar antwoorden uit zijn hoofd heeft geleerd, denk je dat hij veilig is, maar als er een nieuw type lek is dat hij nog niet heeft gezien, faalt hij. Dat is gevaarlijk.
Als de AI echt begrijpt hoe code werkt, kan hij ook nieuwe, onbekende lekken vinden.

Deze studie zegt ons: "Kijk niet alleen naar hoe goed een AI scoort op een test, maar kijk ook hoe hij reageert als je de vraag net iets verandert."

🏁 Conclusie in één zin

Deze AI's zijn niet allemaal "leerlingen" die alleen antwoorden uit hun hoofd hebben geleerd; sommigen zijn echte "ingenieurs" die de regels begrijpen, maar we moeten ze blijven testen met slimme trucjes om zeker te weten dat ze niet alleen maar het antwoordboekje hebben gelezen.

Probleemstelling

De transparantie rondom de datasets die worden gebruikt voor het trainen van Large Language Models (LLMs) ontbreekt vaak, wat grote uitdagingen creëert voor het detecteren en evalueren van datalekken (data leakage). Er bestaat een wijdverbreid vermoeden dat de hoge prestaties van code-LLMs op standaard benchmarks niet voortkomen uit echte generalisatie, maar uit het memoriseren van de evaluatiegegevens tijdens het trainingsproces. Zonder inzicht in de trainingsdata is het moeilijk om te bepalen of een model een taak echt begrijpt of dat het slechts voorbeelden uit het geheugen ophaalt. Bestaande methoden om memorisatie te detecteren vereisen vaak toegang tot interne modeldetails of specifieke trainingsdata, wat in de praktijk vaak onmogelijk is.

Methodologie

De auteurs introduceren een perturbatie-gebaseerde aanpak om het "memorization advantage" (het voordeel van memorisatie) te kwantificeren. De kern van deze methode is gebaseerd op de Perturbation Sensitivity Hypothesis (PSH):

Hypothese: Modellen die een specifieke code hebben gememoriseerd, vertonen een drastische prestatiedaling bij zelfs kleine, semantisch neutrale wijzigingen (perturbaties) in de input. Modellen die echter echte generalisatie hebben bereikt (interpolatie), behouden hun prestaties beter onder dergelijke verstoringen.
Definitie: Het "memorization advantage" ($ma$) wordt gedefinieerd als het verschil in prestatie tussen de verwerking van bekende data ( $x$ ) en een vergelijkbare, maar onbekende, geperturbeerde versie ( $x'$ ).
Perturbatietechnieken:
- Voor NL2Code-taken (bijv. code generatie): Gebruik van BART voor gecontroleerde parafrasing van de prompt, waarbij de syntaxis wordt gewijzigd maar de betekenis behouden blijft.
- Voor Code2Code/Code2NL-taken (bijv. program repair): Systematische hernoeming van variabelen naar willekeurige identifiers (alpha-renaming).
Evaluatie: Voor elke input worden meerdere perturbatieniveaus gegenereerd. De sensitiviteit wordt gemeten als de maximale prestatiedaling tussen opeenvolgende perturbatieniveaus. Een hoge sensitiviteit wijst op memorisatie, terwijl een lage sensitiviteit wijst op robuuste generalisatie.

Experimentele Opzet

Modellen: 8 open-source code-LLMs met verschillende architecturen en trainingsmethodieken (o.a. StarCoder, CodeLlama, DeepSeek-Coder, QwenCoder, WizardCoder).
Benchmarks: 19 datasets verdeeld over 5 software-engineering taken:
1. Code Generatie (NL2Code)
2. Test Generatie (Code2Code)
3. Program Repair (Code2Code)
4. Kwetsbaarheidsdetectie (Code2NL)
5. Code Samenvatting (Code2NL)

Belangrijkste Resultaten

Variatie tussen Modellen: Er zijn aanzienlijke verschillen in sensitiviteitspatronen tussen modellen met vergelijkbare parametergroottes.
- StarCoder vertoont op bepaalde benchmarks (zoals APPS) zeer hoge sensitiviteitsscores (tot 0.8), wat sterk wijst op memorisatie.
- QwenCoder en CodeLlama tonen over het algemeen lagere scores (<0.4), wat suggereert dat ze beter generaliseren.
Takenspecifieke Patronen:
- Code Samenvatting: Toont de laagste sensitiviteit (<0.3) over alle modellen heen, wat wijst op zeer sterke generalisatiecapaciteiten voor deze taak.
- Test Generatie: Toont de hoogste sensitiviteit (0.4-0.7), wat aangeeft dat dit een van de moeilijkste generalisatietaken is voor huidige modellen.
- Program Repair: Context-afhankelijke bugs (ConDefect) zijn moeilijker te generaliseren dan standaard bugs.
Uitdaging van Bestaande Aannames (CVEFixes & Defects4J):
- Een van de meest opvallende bevindingen is dat benchmarks die vaak worden verdacht van datalekken, zoals CVEFixes en Defects4J, verrassend lage memorization advantage-scores vertonen (CVEFixes < 0.1, Defects4J 0.2-0.4).
- Dit weerlegt het idee dat hoge prestaties op deze benchmarks noodzakelijk het gevolg zijn van memorisatie. Het suggereert dat modellen deze patronen daadwerkelijk hebben geleerd en generaliseren, in plaats van ze uit het geheugen op te halen.
Veiligheidsdomein: Het domein van kwetsbaarheidsdetectie vertoont de breedste spreiding in sensitiviteit (van <0.1 tot >0.8), wat wijst op variabele generalisatie-uitdagingen afhankelijk van het specifieke type kwetsbaarheid.

Bijdragen

Empirisch Framework: Toepassing van prompt-perturbatie-analyse om memorisatie te onderscheiden van generalisatie in code-LLMs.
Uitgebreide Evaluatie: Een systematische studie van 8 state-of-the-art modellen over 19 benchmarks.
Herdefiniëring van Benchmarks: Statistische analyse die de prevalentie van datalekken in veelgebruikte benchmarks (zoals CVEFixes) betwist en aantoont dat modellen daar vaak echt generaliseren.
Architecturale Impact: Bewijs dat architecturale keuzes en trainingsmethodieken een grotere impact hebben op generalisatie dan alleen het verhogen van het aantal parameters.
Inzicht in Generalisatiegrenzen: Identificatie dat code-samenvatting de meest robuuste generalisatie toont, terwijl testgeneratie en context-afhankelijke reparatie de grootste uitdagingen vormen.

Significantie en Implicaties

De bevindingen van dit paper hebben belangrijke gevolgen voor de evaluatie van code-LLMs:

Nieuwe Evaluatiestandaard: Het is cruciaal om niet alleen naar absolute prestaties te kijken, maar ook naar perturbatie-robustheid. Een model dat goed presteert op een statische benchmark maar zeer gevoelig is voor kleine wijzigingen, levert mogelijk geen betrouwbare resultaten in de praktijk.
Dynamische Benchmarks: Static benchmarks lopen het risico verouderd te worden of in trainingsdata te belanden. De auteurs pleiten voor dynamische benchmarks die regelmatig worden vernieuwd of procedurally gegenereerd.
Vertrouwen in Veiligheid: De bevinding dat modellen kwetsbaarheden in benchmarks zoals CVEFixes lijken te generaliseren (en niet te memoriseren), is positief voor de toepassing van LLMs in security-critical domeinen, hoewel de hoge sensitiviteit op andere security-benchmarks waarschuwt voor nog steeds bestaande beperkingen.
Toekomstige Ontwikkeling: Het onderzoek suggereert dat het simpelweg schalen van modellen minder effectief is dan het optimaliseren van trainingsmethodieken en architectuur om echte generalisatie te bevorderen.

Kortom, dit paper biedt een methodologische doorbraak om te onderscheiden of een code-LLM "leert" of "leert", en daagt de gemeenschap uit om evaluatieframeworks te herzien die rekening houden met deze nuance.