ResearchEnvBench: Benchmarking Agents on Environment Synthesis for Research Code Execution

Deze paper introduceert ResearchEnvBench, een benchmark die de aanzienlijke beperkingen van huidige autonome agents blootlegt bij het synthetiseren van uitvoeringsomgevingen voor onderzoekscodes, een cruciale stap voor reproduceerbaar wetenschappelijk werk.

De kern

Stel je voor dat je een fantastisch nieuw recept hebt gevonden voor de perfecte taart (een wetenschappelijk onderzoekscijfer). Je wilt het bakken, maar er is een groot probleem: je keuken is nog leeg. Je hebt geen oven, geen mengkom, en je weet niet welke bloemsoort je precies nodig hebt.

Tot nu toe hebben we gekeken of robots (AI-agenten) goed kunnen recepten schrijven of fouten in de tekst van het recept kunnen vinden. Maar dit nieuwe onderzoek, ResearchEnvBench, stelt een veel moeilijkere vraag: Kunnen deze robots ook hun eigen keuken inrichten, de juiste ingrediënten kopen en de oven op de juiste temperatuur zetten, zodat de taart er echt uitkomt?

Hier is wat dit papier in gewone taal vertelt, met een paar creatieve vergelijkingen:

1. Het Probleem: De "Vakantie-Keuken" Illusie

In de wereld van AI-onderzoek gaan we vaak uit van een "vakantie-keuken". We denken: "Oké, de robot mag beginnen met bakken!" Maar in het echt is de keuken een puinhoop.

• De oven (de computer) heeft een specifiek type gas nodig (CUDA-drivers).
• De bloem (software) moet exact passen bij het bakpoeder (de versie van het programma).
• Soms moet je een heel nieuw mengsel maken van metaal en plastic (specifieke hardware-codes) voordat je überhaupt kunt beginnen.

Tot nu toe hebben we dit probleem genegeerd. We hebben gekeken of de robot de tekst van het recept kon lezen, maar niet of hij de keuken kon bouwen.

2. De Oplossing: ResearchEnvBench (De "Keuken-Bouwblokken")

De auteurs hebben een nieuwe test gemaakt, ResearchEnvBench. Dit is als een super-uitdagende "IKEA-bouwpuzzel" voor robots.

• De Taak: Je geeft de robot een doos met onderdelen (een onderzoekscode) en een lijstje met wat er nodig is. De robot moet zelf een werkende omgeving bouwen.
• De Twist: De robot mag niet zomaar zeggen "Ik heb het gedaan". Hij moet het bewijzen.

3. De "Pyramide van Bewijs" (De Test)

De robot moet een trap van 5 treden beklimmen. Als hij op een trede valt, is hij nog niet klaar.

1. Trede 1 (De Lijst): Heeft de robot alle ingrediënten op de lijst? (Zijn er geen woorden in het recept die ontbreken?)
2. Trede 2 (De Ovenschakelaar): Werkt de oven überhaupt? (Kan de computer de code op een simpele manier draaien?)
3. Trede 3 (De Branders): Past de oven bij het gas? (Werkt de software goed met de speciale videokaart?)
4. Trede 4 (De Proeftaart): Kun je de taart echt bakken? (Werkt de code echt op één videokaart?)
5. Trede 5 (Het Grote Feest): Kun je de taart in één keer voor 100 mensen bakken? (Werkt het met meerdere computers tegelijk, wat nodig is voor zware AI?)

4. Wat Vonden Ze? (De Teleurstellende Resultaten)

De auteurs hebben de slimste robots van vandaag (zoals die van Claude, GPT en DeepSeek) op deze test gezet. Het nieuws is niet zo goed:

• Ze kunnen lezen, maar niet bouwen: De robots zijn goed in het installeren van basissoftware (ze halen de ingrediënten uit de supermarkt), maar ze struikelen over de complexe details.
• De "Zichtbare" Valstrik: Veel robots denken dat ze klaar zijn zodra ze de videokaart kunnen "zien" (Trede 3). Maar als ze echt proberen te bakken (Trede 4), mislukt het. Het is alsof je denkt dat je een auto hebt omdat je de sleutel hebt, maar de motor start niet.
• De "Overmoedige" Robot (Hallucinaties): Dit is het grappigste en gevaarlijkste deel. Veel robots zeggen trots: "Taart gebakken! Alles perfect!" terwijl de taart in de oven verbrand is of nog rauw is. Ze liegen niet expres, maar ze denken dat het goed is omdat de installatie-lijstjes er goed uitzagen. Ze vertrouwen op hun eigen gevoel in plaats van het echte bewijs.

5. De Les voor de Toekomst

Deze studie zegt ons dat we niet zomaar kunnen vertrouwen op robots om wetenschappelijk onderzoek te doen. Ze moeten eerst leren hoe ze een werkende "laboratorium-keuken" bouwen.

De kernboodschap in één zin:
Het is niet genoeg voor een AI om slimme code te schrijven; hij moet ook de vaardigheid hebben om de hele computeromgeving zo in te stellen dat die code écht werkt, zonder dat een mens hoeft in te grijpen. Zolang ze dat niet kunnen, blijven hun "wonderen" vaak alleen maar theorie.

Kortom: We hebben robots nodig die niet alleen recepten kunnen lezen, maar ook echte keukens kunnen bouwen.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "ResearchEnvBench: Benchmarking Agents on Environment Synthesis for Research Code Execution" in het Nederlands.

Probleemstelling

Hoewel autonome agents steeds bekwaamer worden in het repareren van code en het uitvoeren van experimenten, vertonen huidige evaluaties een fundamentele tekortkoming: ze veronderstellen een reeds geconfigureerde uitvoeringsomgeving. In de praktijk van wetenschappelijk onderzoek, met name binnen Deep Learning (DL) en High-Performance Computing (HPC), is dit zelden het geval.

Het opzetten van een werkende omgeving voor onderzoekscode is een beruchte bottleneck vanwege:

• Complexe software-afhankelijkheden (Python-bibliotheken).
• Het afstemmen van hardware- en framework-versies (bijv. CUDA-drivers versus PyTorch-versies).
• Het configureren van gedistribueerde uitvoering (multi-GPU).
• Het compileren van aangepaste C++/CUDA-kernels.

Bestaande benchmarks (zoals EnvBench of SWE-bench) focussen vaak op statische analyse (bijv. ontbrekende imports) of het slagen van Docker-builds, maar testen niet of de omgeving daadwerkelijk kan rekenen op hardware-versnellers. Dit leidt tot een "illusie van gereedheid": agents rapporteren succes, maar de code faalt bij de eerste echte uitvoering.

Methodologie: ResearchEnvBench

Om deze kloof te dichten, stellen de auteurs ResearchEnvBench voor, een benchmark specifiek ontworpen voor het evalueren van de synthese van onderzoeksomgevingen.

1. Dataset:

• Bestaat uit 44 hoogwaardige onderzoeksrepositories die na 1 januari 2024 zijn gepubliceerd.
• De repositories zijn geselecteerd op complexiteit: ze bevatten zware hardware-afhankelijkheden, aangepaste CUDA-kernels en vereisten voor gedistribueerd trainen.
• De dataset dekt acht domeinen af, waaronder generatieve visie, dieptebepaling, audio, LLM-inferentie en trainingsframeworks.

2. Taakformulering:

• De agent moet een "blote" Docker-container (met alleen basis-CUDA-drivers) transformeren naar een "Research-Readiness"-staat.
• De agent mag shell-opdrachten uitvoeren, bestanden lezen en hulpbestanden aanmaken, maar mag de broncode van de repository niet wijzigen.
• Het doel is een Docker-image creëren waarin de trainings- of inferentie-entrypoints succesvol kunnen draaien zonder verdere handmatige configuratie.

3. Evaluatieprotocol: De Piramide van Runtime-verificatie
In plaats van alleen te kijken of een installatie lukt, gebruiken de auteurs een hiërarchisch verificatieproces (C0–C4):

• C0 (Statische Integriteit): Controle op ontbrekende imports (via pyright).
• C1 (CPU-uitvoering): De entrypoint moet kunnen draaien op CPU (validatie van de afhankelijkheidsgrafiek).
• C2 (Hardware-afstemming): Het framework (bijv. PyTorch) moet correct gekoppeld zijn aan de onderliggende NVIDIA-drivers.
• C3 (Single-GPU-berekening): Daadwerkelijke uitvoering van kernels op één GPU.
• C4 (Gedistribueerde Bereidheid): Configuratie voor multi-GPU Distributed Data Parallel (DDP) uitvoering (via NCCL).
• C5 (Hallucinatiemeting): Een nieuwe metriek die de discrepantie meet tussen wat de agent rapporteert (zelfverklaring) en de werkelijke, verborgen verificatieprobes.

Belangrijkste Bijdragen

1. Een geharde benchmark: De eerste dataset die specifiek gericht is op de lange staart van complexe, hardware-gevoelige AI-researchcode, in plaats van algemene softwareprojecten.
2. De Piramide van Runtime-verificatie: Een strikt protocol dat agents dwingt om van statische checks door te groeien naar multi-GPU gedistribueerde uitvoering, waardoor de echte reproduceerbaarheid wordt getest.
3. Metriek voor Capabiliteit-Hallucinatie (C5): Een kwantitatieve maatstaf voor het "overmoedige" gedrag van agents die succes melden zonder de daadwerkelijke runtime te verifiëren.

Resultaten

De auteurs hebben vier state-of-the-art agent-sets geëvalueerd (o.a. gebaseerd op GLM-4.7, Sonnet 4.5, GPT-5.1-Codex en DeepSeek-V3.1). De resultaten tonen een aanzienlijke kloof aan:

• Daling in succes: Er is een scherpe daling in succespercentages naarmate de verificatie dieper gaat.
  • C2 (Hardware-afstemming): Hoog succes (79,5% - 93,2%). Agents kunnen vaak drivers en frameworks afstemmen.
  • C3 (Single-GPU): Daling naar 41,9% - 48,8%.
  • C4 (Multi-GPU DDP): Laagste succes, met een maximum van 37,5%.
• Statistische integriteit is onvoldoende: Een lage hoeveelheid ontbrekende imports (C0) garandeert geen werkende GPU-omgeving. Veel failures komen door ABI-mismatches of ontbrekende native extensies die niet in requirements.txt staan.
• Hallucinatiegedrag: Agents rapporteren vaak succes waar er geen is.
  • Agents zoals Codex zijn conservatiever en melden vaker "onbekend" (wat leidt tot minder false positives).
  • Andere agents (zoals Claude Code varianten) melden vaker "ok" zonder de probe te draaien, wat leidt tot hoge hallucinatie-scores (tot 20 hallucinaties per agent).
• Efficiëntie: Meer tokens of tijd leiden niet noodzakelijk tot beter resultaat. De agent NexAU verbruikte bijvoorbeeld 20x meer tokens dan Codex, maar behaalde hetzelfde lage succespercentage op C4.

Oorzaken van falen:
De meeste fouten worden veroorzaakt door:

1. Native extensies: Aangepaste CUDA/C++ operators die gecompileerd moeten worden (bijv. flash_attn, mmcv._ext), niet alleen geïnstalleerd.
2. Hulpmiddelen: Afhankelijkheden van tools zoals wandb of tensorboard die vaak over het hoofd worden gezien.
3. Gemengde frameworks: Repositories die meerdere frameworks combineren, wat agents vaak niet correct oplossen.

Betekenis en Conclusie

ResearchEnvBench blootlegt dat huidige LLM-agents nog niet betrouwbaar zijn voor het autonoom opzetten van wetenschappelijke experimenten in de echte wereld. Hoewel ze goed zijn in het installeren van pakketten, falen ze bij het oplossen van subtiele, hardware-specifieke en compileer-gebonden afhankelijkheden.

De benchmark biedt een realistische testomgeving om agents te trainen en te evalueren op reproduceerbaarheid. De auteurs concluderen dat toekomstige agents niet alleen moeten kunnen installeren, maar ook moeten kunnen verifiëren of de omgeving daadwerkelijk werkt (via smoke-tests) en eerlijk moeten rapporteren over hun capaciteiten om hallucinaties te voorkomen. Dit is een cruciale stap richting volledig autonome wetenschappelijke ontdekking.