💻 computer science

JunoBench: A Benchmark Dataset of Crashes in Python Machine Learning Jupyter Notebooks

Dit artikel introduceert JunoBench, de eerste benchmarkdataset die bestaat uit 111 gecureerde, reproduceerbare crashes uit de echte wereld en hun oplossingen uit openbare Kaggle-notebooks, ontworpen om onderzoek naar het debuggen en repareren van machine learning-code in Jupyter-omgevingen te bevorderen.

Oorspronkelijke auteurs: Yiran Wang, José Antonio Hernández López, Ulf Nilsson, Dániel Varró

Gepubliceerd 2026-05-01

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Yiran Wang, José Antonio Hernández López, Ulf Nilsson, Dániel Varró

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je probeert een complexe taart te bakken met een receptenboek waarin je nieuwe notities kunt schrijven, stappen kunt overslaan of de volgorde van instructies kunt wijzigen terwijl je bezig bent. Dit is wat datawetenschappers doen wanneer ze Jupyter Notebooks gebruiken om Machine Learning (AI)-programma's te bouwen. Het is flexibel en leuk, maar omdat je de volgorde van stappen kunt door elkaar halen, gaan dingen vaak mis. De taart kan verbranden, de oven kan ontploffen, of het beslag kan veranderen in lijm. Dit worden "crashes" genoemd.

Het probleem is dat wanneer deze crashes gebeuren, het voor computerprogramma's (of zelfs mensen) zeer moeilijk is om uit te zoeken waarom ze gebeurd zijn en hoe ze opgelost moeten worden. Waarom? Omdat er geen goede "oefentoets" beschikbaar was om debugging-tools aan te leren hoe ze deze specifieke fouten moeten opsporen.

Dan komt JunoBench in beeld. Denk aan JunoBench als een grote, georganiseerde trainingsgym voor robots die crashes repareren.

Hier is wat het paper zegt over dit nieuwe hulpmiddel, eenvoudig uitgewerkt:

1. De Collectie (De "Crash-bibliotheek")

De onderzoekers gingen op zoek en vonden 111 echte voorbeelden van deze "ontplofte taarten" uit openbare receptenboeken (Kaggle-notebooks).

Niet zomaar fouten: Ze zochten specifiek naar crashes die het programma volledig tot stilstand brengen.
Het "Voor en Na": Voor elke crash lieten ze het niet gewoon kapot. Ze repareerden het handmatig. Dus voor elke 111 kapotte notebooks is er nu een bijpassende "Gerepareerde" versie.
De Ingrediënten: Ze zorgden ervoor dat de crashes afkomstig waren van alle populaire tools die datawetenschappers gebruiken, zoals TensorFlow, PyTorch en Scikit-learn, evenals fouten die specifiek zijn voor de notebook-stijl (zoals het uitvoeren van een stap voordat de ingrediënten zelfs gemengd waren).

2. Het Lab (De "Reproduceerbare Keuken")

Een van de grootste hoofdpijndossiers bij het repareren van computerbugs is dat een crash op de ene computer kan gebeuren maar niet op een andere, vanwege verschillende softwareversies.

De Oplossing: JunoBench wordt geleverd met een Docker-image. Stel je dit voor als een verzegelde, zelfstandige keukenbox. Wat er ook gebeurt, de oven, de mixer en de ingrediënten zijn precies hetzelfde. Dit zorgt ervoor dat als een crash in de box gebeurt, het elke keer gebeurt voor elke onderzoeker. Dit maakt testen eerlijk en betrouwbaar.

3. De Labels (De "Diagnosekaarten")

Je kunt niet zomaar zeggen "het is kapot". Je moet weten hoe het kapot is gegaan. De onderzoekers deden het als expertartsen en gaven elke crash een gedetailleerd medisch rapport:

Wie heeft het veroorzaakt? (Was het de TensorFlow-bibliotheek? Of het Pandas-datahulpmiddel?)
Wat was het symptoom? (Kregen de getallen de verkeerde vorm? Verdween een variabele?)
Waarom gebeurde het? (Typde de gebruiker de verkeerde opdracht? Vergeten ze eerst de data te laden?)
Waar in het proces? (Gebeurde het tijdens het bouwen van het model, het trainen ervan, of het bekijken van de resultaten?)

4. Waarom Dit Belangrijk Is (Het "Trainingsveld")

Voordat JunoBench bestond, moesten onderzoekers die een hulpmiddel wilden bouwen om deze crashes automatisch te repareren, gokken of gebruikmaken van rommelige, inconsistente voorbeelden.

De Nieuwe Standaard: Nu kunnen onderzoekers hun nieuwe "repareer-hulpmiddelen" tegen JunoBench laten draaien. Ze kunnen zien: "Heeft jouw tool de crash gevonden? Wist het welke bibliotheek de oorzaak was? Repareerde het het correct?"
Specifieke Uitdagingen: Het paper benadrukt dat notebook-crashes lastig zijn omdat de computer dingen "onthoudt" uit eerdere stappen (zoals een variabele gedefinieerd in cel #1 die wordt gebruikt in cel #10). JunoBench helpt te testen of nieuwe tools deze "geheugen" en de volgorde van gebeurtenissen kunnen begrijpen.

Wat JunoBench NIET is (Strikt gebaseerd op het paper)

Het is geen hulpmiddel om je eigen code nu direct te repareren.
Het is geen verzameling van elke mogelijke bug in de wereld; het is een gecureerde, gebalanceerde steekproef van 111 specifieke bugs.
Het bevat geen "stille" bugs waarbij de code draait maar het verkeerde antwoord geeft; het bevat alleen "luidruchtige" crashes die het programma stoppen.

In het kort: JunoBench is een gestandaardiseerde, reproduceerbare en goed gelabelde verzameling van 111 kapotte AI-notebooks en hun reparaties. Het is ontworpen om de "eindexamen" te zijn voor nieuwe softwaretools die beloven ontwikkelaars te helpen deze specifieke soorten fouten sneller en beter te vinden en op te lossen.

1. Probleemstelling

Jupyter-notebooks zijn de dominante omgeving voor het prototypen en experimenteren met Machine Learning (ML) en Deep Learning (DL) in Python. De ondersteuning voor het debuggen van ML-ontwikkeling op basis van notebooks is echter beperkt. Deze beperking vloeit voort uit het ontbreken van realistische, uitvoerbare benchmarkdatasets die specifiek voor deze omgeving zijn ontworpen.

Bestaande bug-benchmarks voor ML (zoals Defect4ML, gDefects4DL) richten zich voornamelijk op:

Op scripts gebaseerde artefacten (.py-bestanden): Ze negeren de unieke semantiek van notebooks (.ipynb), zoals een aanhoudende uitvoeringsstatus en niet-lineaire (niet-volgorde) celuitvoering.
Heterogene symptomen: Ze mengen vaak crashes met prestatieverslechtering of onjuiste functionaliteit, waardoor het moeilijk is crash-specifieke debugtools te evalueren.
Reproduceerbaarheidsproblemen: Veel benchmarks missen gestandaardiseerde uitvoeringsomgevingen, waardoor het moeilijk is bugs betrouwbaar te reproduceren op verschillende systemen.

De auteurs betogen dat crashes (programma-afsluitingen) het meest storende en waarneembare symptoom zijn in ML-programma's, waardoor ze het ideale doelwit vormen voor het evalueren van geautomatiseerde technieken voor debuggen, diagnosticeren en repareren.

2. Methodologie

De constructie van JunoBench volgde een rigoureuze, meerstaps-pijplijn (geïllustreerd in Figuur 1 van het artikel) om reproduceerbaarheid, balans en validiteit te waarborgen.

A. Datacollectie en Filtering

Bron: Afgeleid van een eerdere empirische studie waarin 64.031 notebooks (GitHub en Kaggle) werden geanalyseerd.
Selectiecriteria:
1. Platform: Beperkt tot Kaggle-notebooks om toegang te garanderen tot openbare datasets en een gecontroleerde omgeving.
2. Relevantie: Gericht op crashes gerelateerd aan ML-bibliotheken (bijv. TensorFlow, PyTorch) of notebookspecifieke problemen (bijv. uitvoering buiten de volgorde).
3. Uitsluiting: Hardware-afhankelijke crashes (bijv. GPU-geheugengrenzen) of omgevingspecifieke bugs die niet deterministisch reproduceerbaar zijn, zijn verwijderd.
Herverdeling: Om de ongelijke verdeling over bibliotheken aan te pakken, hebben de auteurs een steekproef getrokken uit een niet-gelabelde pool van 3.519 crashes. Ze gebruikten een heuristisch hulpmiddel om notebooks te prioriteren op basis van bibliotheekimporten en traceback-analyse, met als doel een gebalanceerde dekking.

B. Opname in de Benchmark en Reproductie

Isolatie: Elke benchmarkinstantie is een onafhankelijk notebook dat een enkele, geïsoleerde crash bevat.
Drie Versies per Instantie:
1. Origineel: Zoals verzameld.
2. ** gereproduceerd:** Minimale aanpassingen (bijv. uitvoeringsvolgorde, paden) om ervoor te zorgen dat de crash exact zoals in het origineel optreedt.
3. Gerepareerd: Een handmatig gerepareerde versie waarin de crash is opgelost terwijl de oorspronkelijke intentie behouden blijft.
Databehandeling: Invoerdatasets zijn verkleind (bijv. het reduceren van een 2,5 GB grote afbeeldingsdataset naar 94 MB) als het crashgedrag behouden bleef, om opslag- en uitvoeringskosten te verlagen. Synthetische data werd gebruikt voor licenties met restricties.

C. Labeling en Annotatie

Categorisering: Met behulp van grounded theory hebben annotators elke crash gelabeld langs vier dimensies:
1. Bibliotheekoorzaak: Welke bibliotheek de crash veroorzaakte (bijv. NumPy, Pandas, PyTorch).
2. Crashtype: Specifieke foutmanifestatie (bijv. tensorvormmismatch, variabele niet gevonden).
3. Oorzaak: De onderliggende ontwikkelaarsfout (bijv. misbruik van API, data-verwarring).
4. ML-pijplijnfase: Waar de crash optreedt (bijv. data-preparatie, training, evaluatie).
Diagnose-labels: Natuurtaalsamenvattingen die het faalmechanisme en de lokalisatie uitleggen, gevalideerd door een tweede annotator.
Kwaliteitscontrole: De onderlinge overeenstemming tussen annotators was hoog (Cohen's $\kappa > 0,9$ ).

D. Uitvoeringsomgeving

Gecentraliseerde Docker-image: JunoBench biedt één enkele Docker-image met alle benodigde afhankelijkheden om ervoor te zorgen dat crashes consistent reproduceren op verschillende machines.
CLI-hulpmiddel: Een geautomatiseerd command-line hulpmiddel verifieert dat de "gereproduceerde" versie crasht en dat de "gerepareerde" versie succesvol draait.

3. Belangrijkste Bijdragen

Eerste Uitvoerbare Benchmark voor ML-notebooks: JunoBench is de eerste dataset die 111 gecureerde, reproduceerbare real-world crashes biedt, specifiek afkomstig uit Python ML Jupyter-notebooks, gekoppeld aan geverifieerde reparaties.
Uitgebreide Dekking:
- Bibliotheken: Dekking van belangrijke DL/ML-bibliotheken (TensorFlow/Keras, PyTorch, Scikit-learn) en data science-bibliotheken (Pandas, NumPy, Matplotlib, Seaborn).
- Notebook-semantiek: Inclusief 20 crashes die specifiek worden veroorzaakt door uitvoering buiten de volgorde en inconsistenties in de status, een unieke uitdaging in notebooks.
Gestructureerde Ground Truth: Elke crash bevat door mensen gevalideerde labels voor bibliotheekoorzaak, crashtype, oorzaak, pijplijnfase en natuurlijke taaldiagnostische samenvattingen.
Reproduceerbaarheidsinfrastructuur: Een verenigde Docker-omgeving en CLI-hulpmiddel die onderzoekers in staat stellen alle 111 gevallen met één commando te reproduceren, waardoor barrières voor omgevingsconfiguratie worden geëlimineerd.

4. Resultaten en Datasetkenmerken

De definitieve dataset omvat 111 reproduceerbare crashes met de volgende verdeling:

Bibliotheekoorzaak: Gebalanceerde verdeling met ongeveer 15 crashes elk voor TensorFlow/Keras, PyTorch, Scikit-learn, NumPy en Pandas. Inclusief 20 notebookspecifieke crashes en 16 die betrekking hebben op visualisatie of kleinere bibliotheken.
Oorzaak:
- Misbruik van API: 45 gevallen (meest frequent, bijv. ongeldige argumenten).
- Data-verwarring: 25 gevallen (vorm/type-mismatches).
- Implementatiefouten: 18 gevallen (logische fouten).
- Notebookspecifiek: 20 gevallen (statusproblemen).
Crashtypes: Omvat ongeldige argumenten (21), tensorvormmismatches (16), variabele niet gevonden (10) en niet-ondersteunde broadcasts (5).
Pijplijnfase: Crashes treden op gedurende de volledige ML-levenscyclus, met de hoogste frequentie in Modeltraining (31) en Data-preparatie (30).

5. Betekenis en Onderzoeksmogelijkheden

JunoBench maakt een systematische evaluatie van debugtechnieken mogelijk die eerder onmogelijk te beoordelen waren vanwege het gebrek aan data. Belangrijke onderzoeksrichtingen die het ondersteunt, zijn:

Crashdetectie en Geautomatiseerde Reparatie: Het evalueren van tools die crashes over meerdere cellen kunnen identificeren en reparaties kunnen voorstellen die rekening houden met de aanhoudende status van de kernel.
Pijplijnbewust Debuggen: Bestuderen hoe crashes zich voortplanten van data-preparatiefasen naar modeltraining, wat een begrip over bibliotheken heen vereist.
LLM-gebaseerde Analyse: Het bieden van een testomgeving voor Large Language Models (LLM's) om redeneren over stateful-uitvoering en cross-cel-afhankelijkheden. Het artikel merkt op dat huidige LLM's hier moeite mee hebben, met F1-scores tussen 57,7% en 64,6%.
Agent-gebaseerd Debuggen: Het ondersteunen van de ontwikkeling van autonome agents die variabelen iteratief kunnen inspecteren, cellen opnieuw kunnen uitvoeren en reparaties kunnen voorstellen binnen een notebook-omgeving.

Conclusie

JunoBench vult een kritiek gat in het onderzoek naar ML-software-engineering door de eerste gestandaardiseerde, uitvoerbare benchmark voor notebook-crashes te bieden. Door realistische data, geverifieerde reparaties, gestructureerde annotaties en een reproduceerbare omgeving te combineren, dient het als een fundamentele bron voor de doorontwikkeling van geautomatiseerde debug-, diagnose- en reparatietools voor de interactieve ML-ontwikkelworkflow.