A framework for assessing the capabilities of code generation of constraint domain-specific languages with large language models

Dit artikel introduceert een generiek raamwerk om de prestaties van grote taalmodellen bij het genereren van code voor domeinspecifieke taalvarianten, zoals OCL en Alloy, te evalueren en vergelijkt deze met die voor Python, waarbij wordt geconcludeerd dat de prestaties lager zijn en dat strategieën zoals codeherstel en meerdere pogingen de kwaliteit kunnen verbeteren.

De kern

Stel je voor dat je een zeer slimme, maar soms wat ongeduldige assistent hebt die je helpt met schrijven. Deze assistent is een Groot Taalmodel (LLM), zoals de technologie achter ChatGPT. Hij kan heel goed Python of Java schrijven omdat hij miljarden voorbeelden heeft gelezen. Maar wat gebeurt er als je vraagt om code te schrijven in een heel specifieke, obscure taal die alleen maar door een paar experts wordt gebruikt? Dan wordt de assistent vaak verward.

Dit artikel van David Delgado en zijn collega's is als het ware een testcursus om te kijken hoe goed deze slimme assistenten zijn in het schrijven van code voor die specifieke, moeilijke talen.

Hier is de samenvatting in simpele taal, met een paar creatieve vergelijkingen:

1. Het Probleem: De "Allesweter" die vastloopt

Stel je voor dat je een kok bent die gewend is om Italiaanse pasta te koken (dat is Python, een populaire taal). Je vraagt hem nu om een heel specifiek, oud recept te maken voor een lokale streektaal die maar door 10 mensen in de wereld wordt gesproken (dat zijn DSL's zoals OCL en Alloy).

De kok heeft het recept nog nooit gezien. Hij probeert het te raden, maar omdat hij geen voorbeelden heeft, maakt hij vaak fouten. Hij gebruikt de verkeerde ingrediënten of de zinnen kloppen niet. In de programmeerwereld noemen we dit "low-resource talen": er is te weinig data om de AI goed te laten leren.

2. De Oplossing: Een Nieuwe Testmethode

De auteurs hebben een flexibel testraamwerk (een soort keukentest) bedacht. Ze willen niet alleen kijken of de code werkt, maar ze willen ook weten waarom het wel of niet werkt. Ze testen drie dingen:

• Is het goed gebouwd? (Well-formedness): Is de code grammaticaal correct? (Bijvoorbeeld: zijn er wel haakjes en puntkomma's op de juiste plek?)
• Doet het wat het moet doen? (Correctness): Als je de code draait, lost het het probleem op?
• Hoe kunnen we het verbeteren? Door de AI te vragen het opnieuw te proberen of door de fouten te laten repareren.

3. De Experimenten: De "Keukentest"

Ze hebben de assistenten (verschillende AI-modellen) een opdracht gegeven: "Schrijf een regel die controleert of een auto-ongeval precies twee auto's betreft." Ze hebben dit gedaan in drie talen:

• Python (De populaire taal, de "Italiaanse pasta").
• OCL en Alloy (De specifieke talen, de "streektaal").

Wat bleek?

• Python: De AI was fantastisch. Net als een kok die elke dag pasta maakt, deed hij dit moeiteloos.
• OCL en Alloy: Hier ging het vaak mis. De AI verloor de draad. Het was alsof je de kok vraagt om een recept te bedenken voor een taal die hij niet kent; hij begint dan dingen te verzinnen die er niet bestaan (hallucinaties).

4. De Leerpunten: Hoe krijg je de beste resultaten?

De auteurs hebben ontdekt wat er nodig is om de AI op zijn best te krijgen:

• De juiste kok kiezen: Als je een specifieke taal nodig hebt, moet je een AI kiezen die die taal al kent. Kleine, gratis AI-modellen (zoals een stagiair) faalden vaak omdat ze te weinig "kennis" hadden. Grote, dure modellen (zoals een meesterkok) deden het veel beter.
• Meer kans op succes: Als je de AI één keer vraagt, lukt het soms niet. Vraag je het drie keer, dan is de kans groot dat er één keer een goed antwoord tussen zit. Dit noemen ze "meerdere pogingen".
• Reparatie werkt: Als de AI een fout maakt, kun je zeggen: "Hé, dit klopt niet, probeer het nog eens." Dit helpt vaak, maar kost wel extra tijd en geld.
• De vraagstelling (Prompt): Je zou denken dat de manier waarop je de vraag stelt (de "prompt") superbelangrijk is. Maar verrassend genoeg maakt het niet zoveel uit of je heel precies of wat losjes vraagt. De AI is vaak net zo goed (of slecht) ongeacht hoe je het vraagt, zolang je maar de juiste "kok" (AI-model) kiest.
• Alles in één keer: Het is beter om de AI te vragen om alle regels voor een systeem in één keer te schrijven, dan om ze één voor één te vragen. Als je ze één voor één vraagt, kan de AI vergeten wat hij in de eerste vraag heeft bedacht, waardoor de regels tegen elkaar in werken.

5. De Conclusie: Een Praktische Gids

De auteurs zeggen: "Gebruik niet zomaar elke AI voor elke taal."

• Voor populaire talen (Python) kun je bijna elke AI gebruiken.
• Voor specifieke, moeilijke talen (zoals in wetenschappelijke of industriële systemen) moet je een krachtige AI kiezen en meerdere pogingen doen.
• Het is slim om de AI te laten repareren als hij een fout maakt.

Kortom:
Dit artikel is als een handleiding voor chef-koks (ontwikkelaars) die AI willen inzetten. Het zegt: "Kies je kok wijs, geef hem genoeg tijd en kans om het opnieuw te proberen, en zorg dat hij niet vergeten is wat hij eerder heeft gezegd." Zo kun je voorkomen dat je een rommelige maaltijd (slechte code) krijgt, zelfs als je een heel specifiek recept (een moeilijke taal) probeert te maken.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "A framework for assessing the capabilities of code generation of constraint domain-specific languages with large language models" in het Nederlands.

1. Probleemstelling

Grote Taalmodellen (LLM's) hebben de softwareontwikkeling getransformeerd door code te kunnen genereren op basis van tekstuele specificaties. Echter, de effectiviteit van LLM's neemt aanzienlijk af bij Domain Specific Languages (DSL's), en dan met name bij constraint-talen (zoals OCL en Alloy) in vergelijking met populaire algemene programmeertalen (GPL's) zoals Python.

De specifieke uitdagingen voor constraint-talen zijn:

• Laag-resource omgeving: Er zijn weinig trainingsdata beschikbaar in vergelijking met GPL's, wat leidt tot minder nauwkeurige kennis van de syntaxis en semantiek.
• Twee taken tegelijk: Code genereren vereist het beheer van zowel het domeinmodel (het schema) als de constraints die daarop worden gedefinieerd.
• Declaratief karakter: Constraints zijn vaak declaratief en niet uitvoerbaar in de traditionele zin; ze moeten worden geverifieerd tegen voorbeelden.
• Globaliteit: Constraints zijn vaak globaal en kunnen onderling interageren, wat het moeilijk maakt om ze geïsoleerd te evalueren.

Er ontbreekt momenteel een gestructureerd kader om de kwaliteit van door LLM's gegenereerde code voor deze specifieke talen systematisch te beoordelen.

2. Methodologie

De auteurs presenteren een modulair evaluatiekader om de code-generatiecapaciteiten van LLM's te testen. Dit kader is flexibel en kan worden toegepast op zowel GPL's als DSL's.

Het Kader (Workflow):
Het proces bestaat uit vier hoofdstappen (zoals afgebeeld in Figuur 1 van het paper):

1. Prompt Bouwen: Het creëren van prompts met verschillende strategieën (bijv. Chain of Thought, Few-shot) en verrijking met context (domeinbeschrijving, domeinmodel). Er worden negen verschillende prompt-sjablonen (PT1-PT9) getest.
2. Code Generatie: Het sturen van de prompts naar de LLM. Het kader ondersteunt meerdere pogingen (k-attempts) en verschillende leveringsstrategieën (batch vs. geïsoleerd).
3. Well-formedness Check: Controle of de gegenereerde code syntactisch correct is (geparsd kan worden) en semantisch geldig binnen de taal.
   • Herstel: Als de code faalt, wordt er één ronde "code repair" uitgevoerd waarbij de foutmelding terug naar de LLM wordt gestuurd voor correctie.
4. Correctness Check: Controle of de code de bedoelde specificatie correct implementeert.
   • Methode: Gebruik van een "LLM-as-a-judge" (waarbij een LLM de correctheid beoordeelt) en handmatige validatie via tools (zoals USE voor OCL en Alloy Analyzer).
   • Metrics: Gebruik van Accuracy (succes bij de eerste poging) en pass@k (kans dat ten minste één van de k pogingen correct is).

Experimentele Opzet:

• Talen: OCL, Alloy (DSL's) en Python (GPL als referentie).
• LLM's: DeepSeek-coder 6.7B, GPT-4o, GPT-4o-mini en Llama 3.1.
• Datasets: Twee bestaande datasets met domeinmodellen en constraints, aangevuld met synthetische domeinbeschrijvingen.
• Omvang: In totaal zijn ongeveer 98.397 code-generatietaken geëvalueerd.

3. Belangrijkste Bijdragen

1. Een flexibel, configureerbaar evaluatiekader: Een modulair systeem waarin alle aspecten van het generatieproces (prompt, LLM, herstelstrategieën, etc.) geparameteriseerd kunnen worden om de impact van elke beslissing te meten.
2. Gedetailleerde studie van constraint-talen: Een vergelijking van de prestaties van LLM's voor OCL en Alloy versus Python, inclusief het aanmaken van synthetische data om bestaande datasets te verrijken.
3. Uitgebreide experimenten: Een systematische evaluatie van meer dan 90.000 configuraties om de beste strategieën voor code-generatie te identificeren.

4. Resultaten

De experimenten leverden de volgende cruciale inzichten op:

• Invloed van de Doeltaal: Python presteert aanzienlijk beter dan OCL en Alloy. Bijna 100% van de Python-code is wel-formed, terwijl dit bij DSL's lager ligt. Correctheid is ook hoger voor Python.
  • Oorzaak: LLM's hebben minder trainingdata voor DSL's. Specifieke operatoren (zoals set-operatoren in Alloy) en het ontbreken van standaardbibliotheken (bijv. voor datums) leiden tot fouten.
• Invloed van het LLM: Propriëtaire modellen (GPT-4o) presteerden het beste. Open-source modellen (DeepSeek, Llama 3.1) hadden grote moeite met het genereren van zelfs wel-formed code voor constraint-talen en zijn in de praktijk vaak onbruikbaar voor deze specifieke taak zonder fijnafstelling.
• Prompt Engineering: Er is geen enkele "beste" prompt-sjabloon die voor alle scenario's werkt. De verschillen tussen sjablonen zijn vaak niet significant. Voor OCL en GPT-4o-mini waren er significante verschillen, maar over het algemeen heeft de keuze van de prompt minder invloed dan de keuze van het model en de taal.
• Leveringsstrategie: Het genereren van meerdere constraints in één prompt (batch) werkt over het algemeen beter dan geïsoleerde generatie, omdat dit inconsistenties in het domeinmodel (bijv. namen van relaties) voorkomt.
• Meerdere pogingen en Herstel:
  • Het verhogen van het aantal pogingen (pass@k) verbetert de kwaliteit lineair, maar met afnemende meerwaarde.
  • Code repair (het laten corrigeren van fouten door de LLM) levert een significante stijging op (10-20% meer correcte code).
  • De combinatie van meerdere pogingen én code repair levert de beste resultaten op, hoewel dit de kosten (aantal API-calls) verhoogt.

5. Betekenis en Conclusie

Dit paper biedt een robuust kader om de prestaties van LLM's voor code-generatie in niche-domeinen te evalueren. De belangrijkste conclusies voor de praktijk zijn:

1. Modelkeuze is cruciaal: Voor low-resource talen (DSL's) is het kiezen van een model dat bekend is met de taal (zoals GPT-4o) belangrijker dan het optimaliseren van prompts.
2. Strategie voor verbetering: Als de taal goed wordt ondersteund, levert uitgebreide prompt engineering weinig extra winst op. In plaats daarvan moeten ontwikkelaars vertrouwen op meerdere generatiepogingen en automatische code-repair.
3. Batch-verwerking: Het is efficiënter en betrouwbaarder om gerelateerde constraints in één prompt te behandelen om inconsistenties te voorkomen.

Het paper benadrukt dat hoewel LLM's krachtig zijn, er voor constraint-talen nog veel ruimte is voor verbetering, en dat automatische evaluatie (via LLM-as-a-judge) een noodzakelijke en betrouwbare methode is om de kwaliteit van code-generatie op grote schaal te meten. De auteurs hebben hun framework en datasets open-source beschikbaar gesteld voor reproduceerbaarheid.