Development of an LLM-Based System for Automatic Code Generation from HEP Publications

Deze studie presenteert een proof-of-concept systeem dat grote taalmodellen gebruikt om analyseprocedures uit HEP-publicaties te extraheren en uitvoerbare code te genereren voor het reproduceren van resultaten, waarbij de huidige prestaties en beperkingen van open-weight modellen worden geëvalueerd aan de hand van de ATLAS H→ZZ*→4ℓ-analyse.

De kern

De Digitale Kookmeester: Hoe AI HEP-wetenschappers helpt bij het kopiëren van recepten

Stel je voor dat je een heel complex recept hebt gelezen in een kookboek van een beroemde chef-kok (een wetenschappelijk artikel over deeltjesfysica). Je wilt precies hetzelfde gerecht maken, maar het recept staat niet als een duidelijke lijst met ingrediënten en stappen. Het staat verspreid over de tekst, soms in voetnoten, en soms moet je kijken naar andere boeken die de chef heeft genoemd.

Dit is precies het probleem waar natuurkundigen in de Hoge-Energie Fysica (HEP) mee worstelen. Ze willen hun experimenten kunnen herhalen (reproduceren) om te bewijzen dat hun resultaten kloppen, maar het "recept" om de data te analyseren is vaak zo ingewikkeld en verspreid dat het bijna onmogelijk is om het handmatig na te bouwen zonder fouten.

In dit artikel vertellen Masahiko Saito en zijn collega's over een slimme AI-assistent (een Large Language Model of LLM) die ze hebben gebouwd om dit probleem op te lossen. Ze noemen het een "proof-of-concept", wat eigenlijk betekent: "een proefversie om te zien of het idee werkt."

Hier is hoe hun systeem werkt, vertaald naar alledaagse taal:

Stap 1: De Recept-Vertaler (Het Uitlezen)

Stel je voor dat de AI als een superleeskrachtige kok werkt die een hele bibliotheek moet doorzoeken.

• Het doel: De AI moet het recept uit het paper halen. Maar omdat het recept vaak in andere boeken (referenties) staat, moet de AI ook die boeken lezen.
• De methode: De AI werkt in twee fases. Eerst "leest" hij het paper en de bijbehorende boeken. Hij probeert niet zomaar een tekst te kopiëren, maar maakt een gestructureerde lijst van de regels.
  • Voorbeeld: In plaats van "We keken naar deeltjes die snel waren," schrijft de AI: "Regel 1: Deeltjes moeten sneller zijn dan 50 km/u."
• Het probleem: Net als bij een mens die een heel lang verhaal leest, kan de AI soms dingen vergeten of dingen verzinnen die er niet stonden (dit noemen ze "hallucinaties"). Soms denkt de AI dat hij iets heeft gelezen, terwijl het er niet was.
• De oplossing: Ze hebben de AI een "menselijke controle" gegeven. De AI maakt een lijst, en een mens (of een andere AI) kijkt na of de lijst klopt voordat het verder gaat.

Stap 2: De Recept-Vertaler naar Code (Het Koken)

Nu de AI een duidelijke lijst met regels heeft, moet hij die omzetten in een computerprogramma (code) dat het echte werk doet.

• Het doel: De AI schrijft de instructies voor de computer, zodat deze precies hetzelfde doet als de oorspronkelijke wetenschappers.
• De methode: Dit is als een kookmeester die een recept omzet in een instructie voor een robotarm. De AI schrijft de code, de computer probeert het uit te voeren, en als het mislukt (bijvoorbeeld: "Ik heb geen boter gevonden"), krijgt de AI de foutmelding en probeert hij het opnieuw.
• De uitdaging: De AI is soms te zelfverzekend. Hij schrijft code die lijkt te werken (geen foutmeldingen), maar die toch het verkeerde gerecht oplevert. Het is alsof de robotarm de pan wel op het vuur zet, maar vergeet de suiker toe te voegen. Het gerecht ziet er goed uit, maar smaakt niet hetzelfde.

Wat hebben ze ontdekt?

Ze hebben dit getest met een beroemd "recept" van de ATLAS-collectie (een groot experiment in CERN).

• Het goede nieuws: De slimste AI-modellen (de "grote breinen" met veel geheugen) kunnen de regels uit de tekst halen en soms zelfs code schrijven die exact hetzelfde resultaat geeft als de originele wetenschappers.
• Het slechte nieuws: De AI is nog niet betrouwbaar genoeg om dit alleen te doen. Soms verzint hij regels, soms lukt het niet om de code te draaien, en soms werkt het wel, maar is het resultaat verkeerd.

De Conclusie: De AI is een Chef-kok, geen Chef

De belangrijkste boodschap van dit artikel is dat we de AI niet moeten zien als een robot die alles voor ons doet. In plaats daarvan is de AI een superkrachtige assistent.

• Huidige situatie: De AI kan het recept voor je uitschrijven en de eerste schepjes doen, maar een menselijke chef (de natuurkundige) moet blijven kijken, controleren of de ingrediënten kloppen, en de laatste handtekening zetten.
• Toekomst: Als we dit systeem blijven verbeteren, kunnen we in de toekomst papers schrijven die zo duidelijk zijn dat de AI ze direct kan omzetten in werkende code. Dit zou de wetenschap veel transparanter en betrouwbaarder maken.

Kortom: Ze hebben een digitale assistent gebouwd die helpt bij het vertalen van moeilijke wetenschappelijke teksten naar werkende computerprogramma's. Het werkt al aardig, maar we moeten nog steeds goed opletten dat de assistent niet gaat dromen in plaats van werken.

Technische samenvatting

Probleemstelling

In de hoge-energie fysica (HEP) wordt data-analyse steeds complexer, wat een hoge drempel creëert voor studenten en nieuwe onderzoekers vanwege de vereiste rekenkundige expertise en de tijd die nodig is voor het opzetten van omgevingen en het schrijven van code. Een van de grootste uitdagingen in dit veld is het waarborgen van de reproduceerbaarheid van fysica-resultaten. Hoewel Large Language Models (LLM's) potentieel bieden om onderzoekers te ondersteunen bij het coderen, zijn volledig geautomatiseerde analyses nog niet betrouwbaar genoeg vanwege stochastische variatie en hallucinaties (het genereren van onjuiste informatie). Er is behoefte aan een systeem dat niet alleen code genereert, maar dit doet op een verifieerbare manier, waarbij de mens als controleur in het proces blijft (human-in-the-loop).

Methodologie

De auteurs hebben een proof-of-concept (PoC) systeem ontwikkeld dat gebruikmaakt van open-weight LLM's om analyseprocedures uit HEP-publicaties te extraheren en uitvoerbare analysecode te genereren. Het systeem bestaat uit twee hoofdtrappen, geïmplementeerd met frameworks zoals LangChain en LangGraph:

1. Stap 1: Extractie van Selectiecriteria

   • Doel: Het extraheren van gebeurtenisselectiecriteria, objectdefinities en andere relevante informatie uit het doelwit-papier en de daaruit voortvloeiende referenties.
   • Workflow: Een iteratief proces met vier componenten:
     • Planner: Bepaalt welke referentie als volgende moet worden gelezen en formuleert een specifiek leesdoel.
     • Loader: Converteert PDF's naar Markdown, isoleert relevante tekst en koppelt citaties aan arXiv-ID's.
     • Reader: Extrahert de criteria (in "Bulk"-modus voor volledige tekst of "Chunk"-modus voor modellen met beperkt contextvenster).
     • Merger: Integreert nieuwe resultaten in een gestructureerde lijst, waarbij referenties als aanvullend worden behandeld om primaire informatie niet onnodig te overschrijven.
   • Output: Een gestructureerde, mensleesbare representatie met commentaar en herkomst van referenties, in plaats van een simpele numerieke lijst.

2. Stap 2: Code Generatie

   • Doel: Het genereren van analysecode op basis van de gestructureerde selectielijst uit Stap 1.
   • Workflow: Een iteratieve LangGraph-workflow:
     • Planner: Deelt de taak op in subtaken.
     • Generator: Schrijft code voor de huidige subtaak, gebruikmakend van feedback van eerdere validaties en runtime-fouten.
     • Executor: Voert de code veilig uit in een geïsoleerde Singularity-container (voorgeconfigureerd met tools zoals ROOT, numpy, uproot).
     • Validator: Evalueert zowel de uitvoeringsresultaten als de code zelf tegen de criteria.
   • Beperking: Het systeem gebruikt momenteel geen RAG (Retrieval-Augmented Generation) voor domeinspecifieke kennis; alle noodzakelijke specificaties (variabelen, constraints) worden expliciet in de prompt gegeven.

Benchmarks en Evaluatie

Als benchmark werd de ATLAS $H \to ZZ^* \to 4\ell$ analyse gebruikt, gebaseerd op proton-proton botsingsdata uit 2015 en 2016 (ATLAS Open Data).

• Ground Truth: Een handmatig gereproduceerde implementatie en een lijst van 27 expliciet identificeerbare selectiecriteria.
• Evaluatiemetrics:
  • Stap 1: Aantal correct geëxtraheerde criteria en het aantal hallucinaties (tegenstrijdige informatie).
  • Stap 2: Vergelijking op gebeurtenisniveau (event-level) met de baseline. Categorieën: "Exact Match" (identieke lijst van gebeurtenissen), "Not Matched" (geldige uitvoering maar verschillende gebeurtenissen), of "Execution Failed".
• Modellen: Er werden diverse open-weight modellen getest (o.a. Qwen3-reeks, GPT-OSS) en commerciële modellen (Gemini 2.5) als baseline.

Belangrijkste Resultaten

• Selectie-extractie (Stap 1):
  • Modellen met $\ge$ 30 miljard parameters (zoals Qwen3:235B en Gemini 2.5 Flash) slaagden er in sommige runs in om alle 27 criteria correct te extraheren.
  • Kleinere modellen (4B) presteerden slecht.
  • Stochastische variatie was aanzienlijk; zelfs grote modellen produceerden in verschillende runs verschillende resultaten.
  • De "Chunk"-modus (verwerking in segmenten) verbeterde de extractie voor kleine modellen, maar verhoogde drastisch het aantal hallucinaties en mislukte workflows.
• Code Generatie (Stap 2):
  • De beste modellen (Qwen3-Coder-Next:80B en GPT-OSS:120B) slaagden er in respectievelijk 3/10 en 2/10 runs in om code te genereren die exact overeenkwam met de baseline (235 van de 1000 gebeurtenissen geselecteerd).
  • Het model Qwen3-Coder:30B slaagde in geen enkele run in een exacte match.
  • Een groot aantal runs resulteerde in "Execution Failed" of "Not Matched".
  • Kritieke bevinding: Het bestaan van uitvoerbare code die fysisch onjuiste resultaten oplevert, benadrukt dat succesvolle uitvoering geen garantie is voor fysieke correctheid.

Bijdragen en Betekenis

• Primaire Bijdragen:
  1. Implementatie van een werkstroom die gestructureerde selectiecriteria uit papieren haalt en iteratief code genereert, uitvoert en valideert.
  2. Een kwantitatieve evaluatie van open-weight LLM's voor HEP-reproduceerbaarheid, waarbij documentbegrip en codegeneratie gescheiden worden beoordeeld.
• Significantie:
  • Het onderzoek toont aan dat LLM's veelbelovend zijn als collaboratieve hulpmiddelen (human-in-the-loop) voor reproduceerbaarheid, maar nog niet betrouwbaar genoeg zijn als volledig autonome agenten.
  • Het systeem fungeert als een raamwerk om de reproduceerbaarheid van publicaties te beoordelen: succesvolle reproductie suggereert voldoende documentatie, terwijl falen kan wijzen op ontbrekende of ambiguïteiten in de beschrijving.
  • Het benadrukt de noodzaak van menselijke verificatie en gestructureerde tussenliggende representaties om hallucinaties te mitigeren.

Toekomstperspectief

De auteurs plannen om de workflow uit te breiden naar een end-to-end evaluatie om te zien hoe fouten in Stap 1 zich voortplanten naar Stap 2. Verdere verbeteringen zullen focussen op het integreren van RAG voor domeinspecifieke kennis (zoals ROOT-API's) en het uitbreiden van de benchmarks naar andere analyses om de generalisatie te testen. Het uiteindelijke doel is een collaboratief framework dat niet alleen tekst naar code vertaalt, maar ook expliciet ambiguïteiten in gepubliceerde procedures identificeert.