💻 computer science

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

Dieser Beitrag stellt JunoBench vor, den ersten Benchmark-Datensatz, der 111 kuratierte, reproduzierbare reale Abstürze und deren Behebungen aus öffentlichen Kaggle-Notebooks umfasst und entwickelt wurde, um die Forschung zur Fehlersuche und Reparatur von Machine-Learning-Code in Jupyter-Umgebungen voranzutreiben.

Ursprüngliche Autoren: Yiran Wang, José Antonio Hernández López, Ulf Nilsson, Dániel Varró

Veröffentlicht 2026-05-01

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Yiran Wang, José Antonio Hernández López, Ulf Nilsson, Dániel Varró

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie versuchen, einen komplexen Kuchen nach einem Rezeptbuch zu backen, in dem Sie während des Backens neue Notizen hinzufügen, Schritte überspringen oder die Reihenfolge der Anweisungen ändern können. Genau das tun Datenwissenschaftler, wenn sie Jupyter Notebooks verwenden, um Machine-Learning-(KI-)Programme zu erstellen. Es ist flexibel und macht Spaß, aber da Sie die Reihenfolge der Schritte durcheinanderbringen können, gehen Dinge oft schief. Der Kuchen könnte verbrennen, der Ofen könnte explodieren oder der Teig könnte zu Leim werden. Diese werden „Abstürze" genannt.

Das Problem ist, dass es bei solchen Abstürzen sehr schwierig ist, für Computerprogramme (oder sogar für Menschen) herauszufinden, warum sie passiert sind und wie man sie behebt. Warum? Weil es keinen guten „Praxistest" gab, der Debugging-Tools beibringen konnte, diese spezifischen Fehler zu erkennen.

Dann kommt JunoBench ins Spiel. Betrachten Sie JunoBench als einen riesigen, organisierten Trainingsraum für Absturz-Reparatur-Roboter.

Hier ist, was die Studie über dieses neue Werkzeug sagt, einfach aufgeschlüsselt:

1. Die Sammlung (Die „Absturz-Bibliothek")

Die Forscher haben 111 reale Beispiele dieser „explodierenden Kuchen" aus öffentlichen Rezeptbüchern (Kaggle-Notebooks) gesammelt.

Nur irgendeine Fehler: Sie suchten speziell nach Abstürzen, die das Programm sofort zum Stillstand bringen.
Das „Vorher und Nachher": Bei jedem einzelnen Absturz ließen sie ihn nicht einfach kaputt. Sie reparierten ihn manuell. Also gibt es zu jedem der 111 defekten Notebooks nun eine passende „Reparierte"-Version.
Die Zutaten: Sie stellten sicher, dass die Abstürze von allen beliebten Werkzeugen stammten, die Datenwissenschaftler nutzen, wie TensorFlow, PyTorch und Scikit-learn, sowie von Fehlern, die spezifisch für den Notebook-Stil sind (wie das Ausführen eines Schritts, bevor die Zutaten überhaupt gemischt wurden).

2. Das Labor (Die „reproduzierbare Küche")

Eines der größten Ärgernisse beim Beheben von Computerfehlern ist, dass ein Absturz auf einem Computer passieren kann, aber auf einem anderen nicht, wegen unterschiedlicher Softwareversionen.

Die Lösung: JunoBench kommt mit einem Docker-Image. Stellen Sie sich dies als eine versiegelte, in sich geschlossene Küchenbox vor. Egal wer sie öffnet, der Ofen, der Mixer und die Zutaten sind exakt gleich. Dies stellt sicher, dass, wenn ein Absturz in der Box passiert, er jedes einzelne Mal für jeden Forscher passiert. Das macht Tests fair und zuverlässig.

3. Die Etiketten (Die „Diagnose-Karten")

Man kann nicht einfach sagen „es ist kaputt". Man muss wissen, wie es kaputtgegangen ist. Die Forscher agierten wie erfahrene Ärzte und gaben jedem Absturz einen detaillierten medizinischen Bericht:

Wer hat ihn verursacht? (War es die TensorFlow-Bibliothek? Oder das Pandas-Datentool?)
Was war das Symptom? (Haben die Zahlen die falsche Form angenommen? Ist eine Variable verschwunden?)
Warum ist es passiert? (Hat der Benutzer den falschen Befehl eingegeben? Haben sie vergessen, die Daten zuerst zu laden?)
Wo im Prozess? (Passierte es beim Erstellen des Modells, beim Training oder beim Betrachten der Ergebnisse?)

4. Warum das wichtig ist (Das „Trainingsgelände")

Vor JunoBench mussten Forscher, die ein Werkzeug bauen wollten, um diese Abstürze automatisch zu beheben, raten oder unordentliche, inkonsistente Beispiele verwenden.

Der neue Standard: Jetzt können Forscher ihre neuen „Reparatur"-Werkzeuge nehmen und gegen JunoBench laufen lassen. Sie können sehen: „Hat Ihr Werkzeug den Absturz gefunden? Wusste es, welche Bibliothek ihn verursacht hat? Hat es ihn korrekt repariert?"
Spezifische Herausforderungen: Die Studie hebt hervor, dass Notebook-Abstürze tückisch sind, weil der Computer Dinge aus vorherigen Schritten „erinnert" (wie eine Variable, die in Zelle #1 definiert und in Zelle #10 verwendet wird). JunoBench hilft zu testen, ob neue Tools dieses „Gedächtnis" und die Reihenfolge der Ereignisse verstehen können.

Was JunoBench NICHT ist (Basierend streng auf der Studie)

Es ist kein Werkzeug, um Ihren eigenen Code sofort zu reparieren.
Es ist keine Sammlung von jedem möglichen Fehler der Welt; es ist eine kuratierte, ausgewogene Stichprobe von 111 spezifischen Fehlern.
Es enthält keine „stille" Fehler, bei denen der Code läuft, aber die falsche Antwort liefert; es enthält nur „laut" Abstürze, die das Programm stoppen.

Kurz gesagt: JunoBench ist eine standardisierte, reproduzierbare und gut etikettierte Sammlung von 111 defekten KI-Notebooks und deren Reparaturen. Sie ist als „Abschlussprüfung" für neue Softwarewerkzeuge konzipiert, die Entwicklern versprechen, diese spezifischen Fehlertypen schneller und besser zu finden und zu beheben.

1. Problemstellung

Jupyter-Notebooks sind die vorherrschende Umgebung für das Prototyping und Experimentieren mit Machine Learning (ML) und Deep Learning (DL) in Python. Die Debugging-Unterstützung für die notebook-basierte ML-Entwicklung ist jedoch begrenzt. Diese Einschränkung resultiert aus dem Mangel an realistischen, ausführbaren Benchmark-Datensätzen, die speziell für diese Umgebung entwickelt wurden.

Bestehende Fehler-Benchmarks für ML (z. B. Defect4ML, gDefects4DL) konzentrieren sich hauptsächlich auf:

Skriptbasierte Artefakte (.py-Dateien): Sie ignorieren die einzigartigen Semantiken von Notebooks (.ipynb), wie etwa einen persistenten Ausführungszustand und eine nicht-lineare (nicht in der Reihenfolge erfolgende) Zellenausführung.
Heterogene Symptome: Sie vermischen oft Abstürze mit Leistungsminderungen oder fehlerhafter Funktionalität, was die Bewertung absturzspezifischer Debugging-Tools erschwert.
Reproduzierbarkeitsprobleme: Viele fehlen standardisierte Ausführungsumgebungen, was es schwierig macht, Fehler über verschiedene Systeme hinweg zuverlässig zu reproduzieren.

Die Autoren argumentieren, dass Abstürze (Programmbeendigungen) das störendste und am leichtesten beobachtbare Symptom in ML-Programmen sind und somit das ideale Ziel für die Evaluierung automatisierter Debugging-, Diagnose- und Reparaturtechniken darstellen.

2. Methodik

Der Aufbau von JunoBench folgte einem rigorosen, mehrstufigen Pipeline-Prozess (dargestellt in Abbildung 1 des Papiers), um Reproduzierbarkeit, Ausgewogenheit und Validität sicherzustellen.

A. Datensammlung und Filterung

Quelle: Abgeleitet aus einer früheren empirischen Studie, die 64.031 Notebooks (GitHub und Kaggle) analysierte.
Auswahlkriterien:
1. Plattform: Beschränkung auf Kaggle-Notebooks, um Zugang zu öffentlichen Datensätzen und eine kontrollierte Umgebung zu gewährleisten.
2. Relevanz: Fokus auf Abstürze, die mit ML-Bibliotheken (z. B. TensorFlow, PyTorch) oder notebookspezifischen Problemen (z. B. nicht in der Reihenfolge erfolgende Ausführung) zusammenhängen.
3. Ausschluss: Entfernung hardwareabhängiger Abstürze (z. B. GPU-Speicherlimits) oder umgebungsspezifischer Fehler, die nicht deterministisch reproduziert werden können.
Resampling: Um eine ungleiche Verteilung über Bibliotheken hinweg auszugleichen, haben die Autoren aus einem ungelabelten Pool von 3.519 Abstürzen neu gesampelt. Sie nutzten ein heuristisches Werkzeug, um Notebooks basierend auf Bibliotheksimporten und Analyse von Fehlermeldungen (Traceback) zu priorisieren, um eine ausgewogene Abdeckung anzustreben.

B. Benchmark-Einbeziehung und Reproduktion

Isolation: Jede Benchmark-Instanz ist ein unabhängiges Notebook, das einen einzelnen, isolierten Absturz enthält.
Drei Versionen pro Instanz:
1. Original: Wie gesammelt.
2. Reproduziert: Minimale Anpassungen (z. B. Ausführungsreihenfolge, Pfade), um sicherzustellen, dass der Absturz exakt wie im Original auftritt.
3. Behoben: Eine manuell reparierte Version, bei der der Absturz behoben ist, während die ursprüngliche Absicht erhalten bleibt.
Datenverarbeitung: Eingabedatensätze wurden heruntergesampelt (z. B. Reduzierung eines 2,5 GB großen Bilddatensatzes auf 94 MB), wenn das Absturzverhalten erhalten blieb, um Speicher- und Ausführungsaufwand zu reduzieren. Für restriktive Lizenzen wurden synthetische Daten verwendet.

C. Kennzeichnung und Annotation

Kategorisierung: Mithilfe der Grounded Theory haben Annotatoren jeden Absturz über vier Dimensionen hinweg gelabelt:
1. Bibliotheksursache: Welche Bibliothek den Absturz ausgelöst hat (z. B. NumPy, Pandas, PyTorch).
2. Absturztyp: Spezifische Fehlermanifestation (z. B. Tensor-Größenmismatch, Variable nicht gefunden).
3. Grundursache: Der zugrunde liegende Entwicklerfehler (z. B. Missbrauch der API, Datenverwechslung).
4. ML-Pipeline-Stadium: Wo der Absturz aufgetreten ist (z. B. Datenvorbereitung, Training, Evaluation).
Diagnose-Labels: Natürlichsprachige Zusammenfassungen, die den Fehlermechanismus und die Lokalisierung erklären, validiert durch einen zweiten Annotator.
Qualitätssicherung: Die Übereinstimmung zwischen den Annotatoren war hoch (Cohens $\kappa > 0,9$ ).

D. Ausführungsumgebung

Einheitliches Docker-Image: JunoBench stellt ein einzelnes Docker-Image bereit, das alle notwendigen Abhängigkeiten enthält, um sicherzustellen, dass Abstürze auf verschiedenen Maschinen konsistent reproduziert werden.
CLI-Tool: Ein automatisiertes Kommandozeilen-Tool verifiziert, dass die „reproduzierte" Version abstürzt und die „behobene" Version erfolgreich ausgeführt wird.

3. Hauptbeiträge

Erster ausführbarer Benchmark für ML-Notebooks: JunoBench ist der erste Datensatz, der 111 kuratierte, reproduzierbare reale Abstürze speziell aus Python-ML-Jupyter-Notebooks bereitstellt, gepaart mit verifizierten Reparaturen.
Umfassende Abdeckung:
- Bibliotheken: Deckt wichtige DL/ML-Bibliotheken (TensorFlow/Keras, PyTorch, Scikit-learn) und Data-Science-Bibliotheken (Pandas, NumPy, Matplotlib, Seaborn) ab.
- Notebook-Semantik: Beinhaltet 20 Abstürze, die spezifisch durch nicht in der Reihenfolge erfolgende Ausführung und Zustandsinkonsistenzen verursacht werden, eine einzigartige Herausforderung in Notebooks.
Strukturierte Ground Truth: Jeder Absturz enthält menschlich validierte Labels für Bibliotheksursache, Absturztyp, Grundursache, Pipeline-Stadium und natürliche sprachliche Diagnosezusammenfassungen.
Reproduzierbarkeits-Infrastruktur: Eine einheitliche Docker-Umgebung und ein CLI-Tool, die es Forschern ermöglichen, alle 111 Fälle mit einem einzigen Befehl zu reproduzieren und so Barrieren bei der Umgebungskonfiguration zu beseitigen.

4. Ergebnisse und Datensatzmerkmale

Der endgültige Datensatz umfasst 111 reproduzierbare Abstürze mit folgender Verteilung:

Bibliotheksursache: Ausgewogene Verteilung mit jeweils ca. 15 Abstürzen für TensorFlow/Keras, PyTorch, Scikit-learn, NumPy und Pandas. Beinhaltet 20 notebookspezifische Abstürze und 16, die Visualisierung oder kleinere Bibliotheken betreffen.
Grundursache:
- Missbrauch der API: 45 Fälle (am häufigsten, z. B. ungültige Argumente).
- Datenverwechslung: 25 Fälle (Größen-/Typenmismatches).
- Implementierungsfehler: 18 Fälle (Logikfehler).
- Notebookspezifisch: 20 Fälle (Zustandsprobleme).
Absturztypen: Beinhaltet ungültige Argumente (21), Tensor-Größenmismatches (16), Variable nicht gefunden (10) und nicht unterstützte Broadcasts (5).
Pipeline-Stadium: Abstürze treten über den gesamten ML-Lebenszyklus hinweg auf, mit der höchsten Frequenz im Modelltraining (31) und der Datenvorbereitung (30).

5. Bedeutung und Forschungsmöglichkeiten

JunoBench ermöglicht die systematische Evaluierung von Debugging-Techniken, die zuvor aufgrund fehlender Daten nicht bewertet werden konnten. Wichtige Forschungsrichtungen, die es unterstützt, umfassen:

Absturzerkennung und automatische Reparatur: Evaluierung von Tools, die Abstürze über mehrere Zellen hinweg identifizieren und Reparaturen vorschlagen können, die den persistenten Kernelzustand berücksichtigen.
Pipeline-bewusstes Debugging: Untersuchung, wie Abstürze von Datenvorbereitungsstufen zum Modelltraining propagieren, was ein bibliotheksübergreifendes Verständnis erfordert.
LLM-basierte Analyse: Bereitstellung eines Testfelds für Large Language Models (LLMs), um über zustandsbehaftete Ausführung und zellenübergreifende Abhängigkeiten zu reasoning. Das Papier stellt fest, dass aktuelle LLMs hier Schwierigkeiten haben und F1-Scores zwischen 57,7 % und 64,6 % erreichen.
Agentenbasiertes Debugging: Unterstützung der Entwicklung autonomer Agenten, die Variablen iterativ inspizieren, Zellen erneut ausführen und Reparaturen innerhalb einer Notebook-Umgebung vorschlagen können.

Fazit

JunoBench schließt eine kritische Lücke in der Forschung zur ML-Softwaretechnik, indem es den ersten standardisierten, ausführbaren Benchmark für Notebook-Abstürze bereitstellt. Durch die Kombination realistischer Daten, verifizierter Reparaturen, strukturierter Annotationen und einer reproduzierbaren Umgebung dient es als grundlegende Ressource für die Weiterentwicklung automatisierter Debugging-, Diagnose- und Reparaturtools für den interaktiven ML-Entwicklungsworkflow.