Evaluating LLM-generated code for domain-specific languages: molecular dynamics with LAMMPS

Dit paper introduceert een evaluatieprocedure waarmee domeinexperts de validiteit van door grote taalmodellen gegenereerde invoerbestanden voor de domeinspecifieke taal LAMMPS kunnen beoordelen, waardoor veelvoorkomende fouten efficiënt kunnen worden geïdentificeerd zonder kostbare computertests.

De kern

De AI-architect die de verkeerde blauwdrukken tekent: Hoe we LAMMPS en AI laten samenwerken

Stel je voor dat je een zeer ervaren bouwmeester hebt (de AI) die fantastisch kan praten en ideeën heeft. Je vraagt hem: "Bouw een huis dat bestand is tegen een orkaan." De AI schrijft direct een gedetailleerd bouwplan. Het ziet er prachtig uit, de zinnen kloppen, en het klinkt heel logisch. Maar als je het plan goed bekijkt, zie je dat de deuren op de verkeerde plek zitten, de fundering te zwak is, of dat er een muur is getekend die eigenlijk een raam moet zijn.

Dit is precies wat onderzoekers van de Purdue Universiteit hebben ontdekt met Large Language Models (LLM's) – de slimme AI's zoals GPT-4 of Claude – wanneer ze proberen code te schrijven voor moleculaire dynamica (het simuleren van atomen).

Hier is een simpele uitleg van hun onderzoek, vertaald naar alledaags taal:

1. Het Probleem: De "Taal van de Atomen"

Wetenschappers gebruiken speciale software (zoals LAMMPS) om te kijken hoe atomen zich gedragen. Om dit te doen, moeten ze een heel specifiek, streng taalgebruik gebruiken. Dit is geen normaal Engels of Nederlands; het is een DSL (Domain Specific Language).

• De Analogie: Stel je voor dat LAMMPS een zeer strenge chef-kok is. Als je zegt: "Maak een soep," en je gebruikt de verkeerde ingrediënten of de verkeerde volgorde, krijg je geen soep, maar een onsmakelijke brij of de keuken vliegt op.
• De AI is goed in het schrijven van "soep" (normale code), maar deze specifieke "chef" (LAMMPS) heeft een heel eigen, koddig recept. Als de AI één klein woordje verkeerd zet of de volgorde van de instructies door elkaar haalt, faalt de hele simulatie.

2. De Oplossing: De "AI-Inspecteur"

De onderzoekers wilden weten: "Kan de AI dit recept wel goed schrijven?" En belangrijker: "Hoe vinden we de fouten voordat we de hele keuken in brand steken?"

Ze ontwikkelden een drie-stappenplan om de AI te testen, als een strenge bouwkundige inspecteur:

• Stap 1: De Vertaler (Normalisatie)
  De AI schrijft soms rommelig, met commentaar of variabele namen. De onderzoekers gebruikten een tool die de tekst "opruimt" en omzet in een standaardformaat. Het is alsof je een handgeschreven brief van de AI overtypet in een strak, digitaal document zodat iedereen het precies hetzelfde leest.
• Stap 2: De Grammatica-check (Parser)
  Ze gebruikten een speciale computerprogramma (een 'parser') dat de code leest als een boomstructuur. Het kijkt niet of de zin mooi klinkt, maar of de grammatica klopt.
  • Voorbeeld: Als de AI zegt "Voeg atomen toe aan groep A", maar groep A bestaat niet, vangt deze tool dat direct op. Dit kost weinig tijd en rekenkracht.
• Stap 3: De Proefbak (Korte Simulatie)
  Als de code grammaticaal klopt, laten ze het programma draaien, maar dan heel kort (slechts 10 stappen in plaats van duizenden).
  • De truc: Ze vervingen soms de dure "atoom-krachten" door een simpele "nul-kracht". Waarom? Om te zien of de code technisch werkt, zonder dat je duizenden euro's aan rekenkracht verbrandt. Als het dan nog steeds crasht, zit er een fundamenteel probleem in de structuur.

3. Wat Vonden Ze? (De Resultaten)

De resultaten waren een mix van hoop en realiteit:

• De AI is slim, maar niet perfect: De AI kon vaak een goed begin maken. Voor simpele taken (zoals een blokje aluminium opwarmen) lukte het vaak.
• Hoe complexer, hoe slechter: Zodra de taak moeilijker werd (bijvoorbeeld: een projectiel dat met hoge snelheid op een doelwit botst), viel de AI flink uit elkaar.
  • De fouten: De AI koos vaak het verkeerde type "atoom-kracht" (zoals een verkeerd soort cement kiezen), vergat eenheden om te rekenen (zoals meters in plaats van nanometers), of bedacht commando's die niet bestaan (hallucinaties).
• De "One-Shot" score: Slechts een klein percentage van de scripts (ongeveer 23% tot 33%, afhankelijk van de AI) was direct perfect zonder dat de mens er iets aan hoefde te wijzigen.

4. De Grote Les: De AI is een Assistent, geen Baas

De belangrijkste conclusie van het onderzoek is dit: Vertrouw de AI niet blindelings.

De AI is niet in staat om zelfstandig een compleet wetenschappelijk experiment te ontwerpen. Ze mist het diepe inzicht in de natuurkunde en de strenge regels van de software.

• De Metafoor: De AI is als een zeer getalenteerde stagiair die snel kan typen en mooie zinnen maakt. Maar je moet als senior chef (de menselijke expert) altijd controleren of de ingrediënten kloppen en of het recept veilig is.

5. Wat is de Toekomst?

De onderzoekers tonen aan dat we AI wel kunnen gebruiken, maar dan op een slimme manier:

1. Gebruik de AI voor het ruwe werk: Laat de AI het basisplan maken.
2. Gebruik de "Inspecteur": Laat de speciale tools (zoals de parser die ze maakten) direct controleren of het plan logisch is.
3. De mens houdt het toezicht: Pas de fouten aan en voer de simulatie uit.

Kortom: AI kan de wetenschap versnellen door de eerste stap te zetten, maar we hebben nog steeds menselijke experts nodig om te zorgen dat de atomen niet in de verkeerde richting vliegen. Het is een samenwerking tussen de snelle AI en de waakzame mens.

Technische samenvatting

Titel: Evaluatie van door LLM gegenereerde code voor domeinspecifieke talen: moleculaire dynamica met LAMMPS

Auteurs: Ethan W. Holbrook, Juan C. Verduzco en Alejandro Strachan (Purdue University).

---

1. Het Probleem

Fysisch gebaseerde simulaties, zoals moleculaire dynamica (MD) met softwarepakketten als LAMMPS, zijn essentieel voor modern wetenschappelijk onderzoek. Deze tools vereisen echter het gebruik van domeinspecifieke talen (DSL's) die vaak syntactisch complex en kwetsbaar zijn.

• Uitdaging: Kleine fouten in de volgorde van commando's, het gebruik van standaardwaarden of onvolledige scriptbeschrijvingen kunnen simulaties ongeldig maken of leiden tot wetenschappelijk onjuiste resultaten.
• Rol van LLM's: Grote Taalmodellen (LLM's) beloven de drempel te verlagen door natuurlijke taalbeschrijvingen om te zetten in geldige input-scripts. Echter, de effectiviteit van LLM's bij het genereren van wetenschappelijk valide code voor DSL's is nog onvoldoende onderzocht.
• Gevolg: Er ontbreekt een gestructureerde procedure om door LLM's gegenereerde scripts te valideren, fouten te identificeren en de prestaties van modellen te beoordelen zonder kostbare computertijd te verspillen aan het uitvoeren van volledige simulaties.

2. Methodologie

De auteurs hebben een meervoudige evaluatieprocedure ontwikkeld om de kwaliteit van door LLM's gegenereerde LAMMPS-scripts te beoordelen. De workflow bestaat uit de volgende fasen:

1. Generatie:

   • Vijf state-of-the-art LLM's (GPT-4o, GPT-4.1, GPT-o3, GPT-5, en Claude 4 Opus) kregen drie prompts van toenemende complexiteit:
     • Prompt 1: Eenvoudige evenwichtsberekening van een aluminium kristal (NPT ensemble).
     • Prompt 2: Verhitting van een nikkelkristal van 300K naar 2500K.
     • Prompt 3: Complexe "spall"-simulatie (impact) met een projectiel en een doelwit in niobium.
   • Voor elke combinatie werden 10 onafhankelijke generaties gegenereerd (totaal 150 scripts).

2. Normalisatie:

   • Een Python-pakket (lammps-ast) verwijdert commentaar, voegt regels samen en lost variabelen op.
   • Dit creëert "canonieke" bestanden om variabiliteit te elimineren en zorgt ervoor dat scripts met dezelfde numerieke waarden identiek worden weergegeven voor analyse.

3. Statische Parsing (Syntax Validatie):

   • Een aangepaste parser (gebaseerd op Lark) converteert het script naar een Abstract Syntax Tree (AST).
   • Dit stelt de auteurs in staat om syntactische fouten, ongeldige argumenten en inconsistenties in commando's te detecteren voordat een simulatie wordt uitgevoerd.

4. Executie en Foutisolatie:

   • Scripts worden uitgevoerd met een beperkt aantal stappen (10 stappen) om computerkosten te minimaliseren.
   • Pair Style Zero (PSZ) substitutie: Om fouten gerelateerd aan atomaire potentiaaldefinities (pair styles) te scheiden van syntaxisfouten, worden alle pair_style commando's tijdelijk vervangen door een neutrale versie (pair_style zero). Dit laat zien of het script syntactisch correct is, ongeacht de fysieke parameters.

5. Fysieke Nauwkeurigheid:

   • Scripts die zonder fouten draaien, worden gecontroleerd op basis van een checklist met fysieke criteria (roosterparameters, randvoorwaarden, temperatuur, druk, tijdstappen, etc.) om te zien of ze voldoen aan de oorspronkelijke prompt.

3. Belangrijkste Bijdragen

• Evaluatiekader: Een reproduceerbaar framework voor het beoordelen van LLM-prestaties in wetenschappelijke DSL's zonder domeinspecifiek fine-tuning.
• Normalisatie- en Parser-tooling: De introductie van een AST-gebaseerde parser en normalisatiestap die specifiek is ontworpen voor LAMMPS, wat een zeldzame infrastructuur is voor wetenschappelijke DSL's.
• Foutanalyse: Een diepgaande analyse van veelvoorkomende foutpatronen, variërend van syntaxis tot semantische redenering.
• Praktische Richtlijn: Een aanpak die domeinexperts toelaat om LLM's te integreren in hun workflow met behoud van betrouwbaarheid en reproduceerbaarheid.

4. Resultaten

De evaluatie van 150 scripts leverde de volgende inzichten op:

• Algemene Prestaties:

  • Ongeveer 74% van de scripts slaagde de syntactische parser.
  • Slechts 32% draaide zonder fouten bij de eerste poging.
  • Slechts 27,3% voldeed volledig aan alle fysieke criteria (one-shot accuracy).
  • De prestaties daalden drastisch naarmate de taak complexer werd (van 66% nauwkeurigheid bij Prompt 1 naar slechts 2% bij Prompt 3).

• Modelvergelijking:

  • Claude 4 Opus presteerde het meest consistent met de hoogste parser-succesratio (97%) en een sterke uitvoeringsscore.
  • GPT-5 had de hoogste "one-shot accuracy" (33%) voor de meest complexe taak, maar vertoonde meer variabiliteit in de eerdere stappen.
  • GPT-o3 had de zwakste prestaties over het algemeen.

• Veelvoorkomende Fouten:

  1. Verkeerde pair_style definities: Bijna een derde van de scripts koos de verkeerde variant van het EAM-potentieel (bijv. eam in plaats van eam/alloy), vaak omdat dit als impliciete domeinkennis werd beschouwd.
  2. Unit- en Schaalproblemen: Modellen faalden bij het converteren van eenheden (bijv. m/s naar Å/ps) of gebruikten generieke waarden (zoals een roosterconstante van 1 Å) in plaats van materiaalspecifieke waarden.
  3. Hallucinaties: Het genereren van niet-bestaande commando's of argumentcombinaties die syntactisch plausibel lijken maar niet in de LAMMPS-documentatie staan.
  4. Geometrische Redenering: Bij complexe prompts (Prompt 3) faalden modellen in het coördineren van ruimtelijke relaties, randvoorwaarden en de volgorde van commando's.

5. Betekenis en Conclusie

• Beperkingen van LLM's: LLM's zijn in hun basisconfiguratie nog niet autonoom genoeg om complexe wetenschappelijke simulaties volledig te ontwerpen. Ze kunnen de hoge-level structuur goed vastleggen, maar falen vaak bij de strikte syntaxis, eenheidsconversies en multi-stap fysieke redenering die nodig is voor reproduceerbare resultaten.
• Rol van Validatie: De studie benadrukt dat LLM's het beste worden ingezet als assistenten binnen een workflow die gestructureerde validatie omvat. De door de auteurs ontwikkelde AST-parser is cruciaal om fouten vroeg te detecteren voordat kostbare simulatieressourcen worden besteed.
• Toekomstperspectief: Voor een betrouwbare automatisering zijn systemen nodig die model-aannames expliciet valideren, mogelijk door middel van retrieval-augmented generation (RAG) met documentatie en integratie van AST-structuren in het trainingsproces van de modellen.

Conclusie: Hoewel LLM's veelbelovende startpunten bieden voor wetenschappelijke scripting, is een menselijke expert of een robuust validatiekader onmisbaar om de wetenschappelijke geldigheid van de gegenereerde code te garanderen.