Helping LLMs Improve Code Generation Using Feedback from Testing and Static Analysis

Dit paper presenteert een framework dat testen en statische analyse gebruikt om open-source LLM's te helpen bij het zelf verbeteren van gegenereerde code, waarbij wordt vastgesteld dat hoewel deze modellen vaak fouten en kwetsbaarheden introduceren en slecht zijn in het detecteren daarvan, ze aanzienlijk beter presteren bij het oplossen van deze problemen wanneer ze feedback krijgen over de fouten.

De kern

Stel je voor dat je een zeer slimme, maar soms wat slordige assistent hebt die je helpt met het bouwen van een auto. Je geeft hem een opdracht: "Bouw een motor die rijdt." Hij bouwt snel een motor, maar soms draait hij de bouten niet goed aan, of hij gebruikt de verkeerde olie.

Dit is precies wat Grote Taalmodellen (LLMs) doen als we ze vragen om computercode te schrijven. Ze zijn razendsnel en kunnen veel, maar de code die ze maken is niet altijd veilig of foutloos.

Deze paper onderzoekt hoe we deze slimme assistenten kunnen helpen om hun werk beter te doen, door hen te laten "leren van hun fouten" met behulp van twee speciale tools: tests en een veiligheidscontrole.

Hier is de uitleg in drie simpele stappen, met een paar creatieve vergelijkingen:

1. De Proef: De "Motorbouwers" (Code Generatie)

De onderzoekers gaven vier verschillende AI-modellen (denk aan Llama, Gemma en Mixtral) een lijst met 100 simpele bouwpakketten (taken) en vroegen hen om C-code te schrijven (een programmeertaal die veel gebruikt wordt voor systemen die veilig moeten werken, zoals in auto's of vliegtuigen).

• Het resultaat: Het was een gemengd pakket. Sommige AI's maakten prachtige motoren, maar veel anderen bouwden rommel.
  • Slechts 46% tot 65% van de code werkte echt zoals bedoeld.
  • De rest had fouten: de motor startte niet, of hij liep vast.
  • Veiligheid: Gelukkig was de code niet gevaarlijk slecht. De meeste motoren lekten niet (geen veiligheidslekken), maar ze waren wel vaak functioneel onzin.

2. De Check: De "Inspecteur" en de "Testbaan"

Nu komt het slimme deel. De onderzoekers lieten de AI's niet alleen werken. Ze gebruikten twee methoden om te kijken wat er mis was:

• De Testbaan (Correctheid): Ze draaiden de code door een reeks van strikte tests. Het is alsof je de motor op een testbaan zet. Als hij niet start of trilt, is hij fout.
• De Inspecteur (Veiligheid): Ze gebruikten een geavanceerde software-tool genaamd Infer. Dit is als een robot-inspecteur die met een vergrootglas door de motor loopt om te kijken of er bouten loszitten of of er brandgevaar is (zoals geheugenlekken).

De verrassende ontdekking:
Toen ze de AI's vroegen om zelf te zeggen of hun eigen werk goed was, faalden ze volledig.

• Het was alsof je de motorbouwer vraagt: "Is je motor goed?" en hij zegt: "Ja, zeker!" terwijl hij eigenlijk een bout heeft vergeten.
• De AI's konden hun eigen fouten bijna niet zien. Ze waren blind voor hun eigen slordigheden.

3. De Oplossing: De "Reparatiewerkplaats" (Self-Repair)

Dit is het belangrijkste deel van het onderzoek. Wat gebeurt er als we de AI niet alleen laten, maar haar de resultaten van de inspectie geven?

De onderzoekers zeiden tegen de AI: "Kijk hier, je motor start niet (foutmelding van de testbaan) en hier zit een losse bout (waarschuwing van de inspecteur). Maak het goed."

• Het resultaat: Het werkte verrassend goed!
  • Toen de AI de foutmeldingen kreeg, kon ze de code vaak repareren.
  • Voor veiligheidsfouten (zoals losse bouten) lukte het in 89% van de gevallen om het probleem op te lossen.
  • Voor functionele fouten (de motor die niet start) lukte het in 62% van de gevallen.

De Grote Les (De Analogie)

Stel je voor dat je een kind leert fietsen.

1. Zonder feedback: Je laat het kind alleen fietsen. Het valt vaak, maar het beseft niet waarom.
2. Met feedback: Je zegt: "Je viel omdat je te hard stuurde naar links."
3. Het resultaat: Het kind leert snel om niet meer naar links te sturen.

Deze paper laat zien dat AI's (zoals LLMs) op zichzelf nog niet perfect zijn in het schrijven van veilige code. Ze zijn vaak zelfverzekerd over hun fouten. Maar, als we hen een duidelijke "reparatie-instructie" geven (de resultaten van tests en veiligheidscontroles), kunnen ze hun eigen werk uitstekend verbeteren.

Conclusie voor de Toekomst

Dit betekent dat we in de toekomst AI-tools kunnen bouwen die niet alleen code schrijven, maar die ook automatisch testen, fouten vinden en zichzelf repareren voordat de code bij een mens terechtkomt. Het is alsof we een onmisbare "kwaliteitscontrole-robot" toevoegen aan het bouwteam, zodat de AI's steeds slimmer en veiliger worden.

Kortom: AI's zijn nog geen perfecte programmeurs, maar met de juiste feedback kunnen ze het wel worden.

Technische samenvatting

Titel: Helpen LLM's bij het verbeteren van codegeneratie met feedback uit testen en statische analyse

Auteurs: Greta Dolcetti, Vincenzo Arceri, Eleonora Iotti, Sergio Maffeis, Agostino Cortesi, en Enea Zaffanella.
Publicatie: arXiv:2412.14841v2 (januari 2025).

---

1. Het Probleem

Grote Taalmodellen (LLM's) worden steeds vaker gebruikt om code te genereren, wat de productiviteit van ontwikkelaars verhoogt. Echter, er zijn aanzienlijke zorgen over de veiligheid, juistheid en betrouwbaarheid van deze gegenereerde code.

• Onjuistheid: Code voldoet vaak niet aan de specificaties of bevat bugs.
• Veiligheidsrisico's: Code bevat kwetsbaarheden (zoals geheugenlekken, bufferoverlopen) die tot security-incidenten kunnen leiden.
• Beperkt zelfbewustzijn: LLM's zijn vaak slecht in het zelf detecteren van fouten in hun eigen output.
• Gebrek aan geautomatiseerde herstelmechanismen: Bestaande methoden gebruiken vaak geen iteratieve feedbackloops met gespecialiseerde tools om de code te corrigeren.

Het doel van dit onderzoek is om een raamwerk te ontwikkelen dat LLM's helpt om veiligere en correctere code te genereren door gebruik te maken van testen en statische analyse als feedbackmechanisme.

---

2. Methodologie

De auteurs hebben een volledig geautomatiseerd experimenteel raamwerk opgezet dat bestaat uit drie hoofdfasen: Codegeneratie, Zelfevaluatie en Reparatie.

A. Experimentele Opzet

• Modellen: Vier open-source instructie-finetuned modellen werden getest:
  • Llama 3 (8B en 70B parameters)
  • Gemma 7B
  • Mixtral 8x7B (Sparse Mixture-of-Experts)
• Dataset: Een aangepaste versie van het MBPP-dataset (Mostly Basic Python Problems), vertaald naar het C-programmeertaal. C werd gekozen vanwege de strikte eisen aan geheugenbeheer en het risico op veiligheidsproblemen.
• Prompt Engineering: Er werden uitgebreide experimenten uitgevoerd met verschillende prompt-configuraties (Vanilla, Voorbeelden, Chain-of-Thought, Combinaties) om de beste prestaties te behalen. De resultaten in het artikel zijn gebaseerd op de best presterende prompts.
• Tools:
  • Compiler: Clang 15.0.0.
  • Statische Analyse: Infer (van Meta), een state-of-the-art tool voor het detecteren van geheugen- en veiligheidsproblemen zonder de code uit te voeren.

B. De Drie Fasen

1. Codegeneratie:

   • De LLM's genereren C-code voor 100 taken.
   • Een automatische schoonmaakstap verwijdert extra tekst, voegt ontbrekende bibliotheken toe en corrigeert opmaakfouten.
   • Correctheidstest: De gegenereerde code wordt uitgevoerd tegen unit-tests (aangepast van MBPP). Resultaten worden gecategoriseerd als: geslaagd, mislukt, uitvoeringsfout (bijv. segfault) of compilatiefout.
   • Veiligheidstest: Code die compileert, wordt geanalyseerd door Infer op kwetsbaarheden (bijv. NULLPTR_DEREFERENCE, BUFFER_OVERRUN, MEMORY_LEAK).

2. Zelfevaluatie:

   • De modellen worden gevraagd om de correctheid en veiligheid van de gegenereerde code te beoordelen (zowel hun eigen code als die van andere modellen).
   • Dit dient om te meten of modellen "zelfvoorkeur" hebben (hun eigen code beter beoordelen) en hoe goed ze fouten kunnen identificeren zonder externe feedback.

3. Reparatie (Self-Healing):

   • Modellen krijgen de incorrecte of onveilige code terug, samen met specifieke feedback:
     • Voor correctheid: De specifieke test die faalde.
     • Voor veiligheid: Het rapport van Infer met het type kwetsbaarheid en de locatie.
   • De LLM moet de code repareren. Dit proces is iteratief (maximaal 6 iteraties) totdat de code correct compileert en de fouten verdwijnen.

---

3. Belangrijkste Bijdragen

• Omvangrijke Evaluatie: Een systematische analyse van de correctheid en veiligheid van code gegenereerd door vier populaire open-source LLM's in C.
• Geautomatiseerd Herstelraamwerk: Een modulaire pipeline die statische analyse en testen koppelt aan LLM's voor iteratieve codeverbetering.
• Analyse van Zelfbewustzijn: Een gedetailleerde studie naar de capaciteit van LLM's om fouten in hun eigen code te detecteren versus code van anderen.
• Prompt Engineering Insights: Demonstratie van hoe cruciale prompt-ontwerp is voor de kwaliteit van output, met name bij reparatietaken.
• Open Data: De volledige dataset, scripts en resultaten zijn openbaar beschikbaar gemaakt.

---

4. Resultaten

A. Codegeneratie (Correctheid & Veiligheid)

• Correctheid: Slechts 46% tot 65% van de gegenereerde code was correct (afhankelijk van het model). llama3-70b-8192 presteerde het beste (65%), gemma-7b-it het slechtst (46%).
• Veiligheid: Volgens Infer bevatte 87% tot 96% van de code geen gedetecteerde kwetsbaarheden. Echter, de auteurs waarschuwen dat statische analyse niet perfect is (false positives/negatives). mixtral-8x7b-32768 had het hoogste aantal gevonden kwetsbaarheden.
• Conclusie: Code is vaker functioneel incorrect dan onveilig.

B. Zelfevaluatie (Detectie van Fouten)

• Prestaties: LLM's presteren zeer slecht bij het zelf detecteren van fouten.
  • Voor correctheid: De F1-scores lagen allemaal onder de 80%. Sommige modellen gaven bijna altijd "YES" (te optimistisch), anderen bijna altijd "NO" (te pessimistisch).
  • Voor veiligheid: De detectie van kwetsbaarheden was extreem laag (F1-scores < 0,3). Modellen misten de meeste echte kwetsbaarheden of rapporteerden veel false positives.
• Zelfvoorkeur: Er werd geen bewijs gevonden dat modellen hun eigen code systematisch beter beoordelen dan die van andere modellen.

C. Reparatie (Self-Healing)

Dit is het meest positieve resultaat van het onderzoek:

• Correctheid: Met feedback over mislukte tests konden modellen de code aanzienlijk verbeteren.
  • llama3-70b-8192 slaagde erin om 62% (96 van 155) van de incorrecte bestanden volledig te repareren.
  • Er was geen duidelijke "zelfvoorkeur" bij reparatie; modellen repareerden code van andere modellen vaak beter dan hun eigen code.
• Veiligheid: Met feedback van Infer konden modellen kwetsbaarheden effectief verhelpen.
  • De beste modellen (llama3-70b-8192 en mixtral-8x7b-32768) repareerden 89% (39 van 44) van de gevonden kwetsbaarheden.
  • Belangrijk: Bij het repareren werden geen nieuwe kwetsbaarheden geïntroduceerd door deze twee modellen.

---

5. Betekenis en Conclusie

Het onderzoek toont aan dat hoewel LLM's op dit moment niet betrouwbaar genoeg zijn om autonoom veilige en correcte code te genereren, ze wel een sterk potentieel hebben om fouten te herstellen wanneer ze worden gevoed met specifieke feedback van gespecialiseerde tools.

• Kritieke Inzicht: LLM's missen het inzicht om fouten zelf te vinden (lage zelfevaluatie), maar kunnen deze fouten wel effectief oplossen als ze worden verteld wat er mis is (hoge reparatiecapaciteit).
• Toekomstperspectief: De auteurs bepleiten de integratie van iteratieve pipelines waarbij statische analyse en testen worden gebruikt als feedbacklus voor LLM's. Dit is een veelbelovende route om de veiligheid van AI-generatie te waarborgen.
• Beperkingen: De studie is beperkt tot C-code. Toekomstig werk moet worden uitgebreid naar andere talen (zoals Rust of Python) en hybridere benaderingen (combinatie van statische en dynamische analyse) om false positives te verminderen.

Samenvattend biedt dit paper een bewezen methode om de kwaliteit van LLM-generatie te verhogen door de "blindheid" van het model te compenseren met externe, formele verificatietools.