💻 computer science

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

本文介绍了JunoBench，这是首个基准数据集，包含来自公开Kaggle笔记本的111个精心策划、可复现的真实世界崩溃案例及其修复方案，旨在推动Jupyter环境中机器学习代码调试与修复的研究。

原作者： Yiran Wang, José Antonio Hernández López, Ulf Nilsson, Dániel Varró

发布于 2026-05-01

📖 1 分钟阅读☕ 轻松阅读

原作者： Yiran Wang, José Antonio Hernández López, Ulf Nilsson, Dániel Varró

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正试图根据一本食谱书烘焙一款复杂的蛋糕，而在这本书中，你可以随时写下新笔记、跳过步骤，或者在操作过程中更改指令的顺序。数据科学家使用Jupyter Notebook构建机器学习（AI）程序时，情况正是如此。这种方式既灵活又有趣，但正因为你可以打乱步骤顺序，事情往往容易出错。蛋糕可能会烤焦，烤箱可能会爆炸，或者面糊可能会变成胶水。这些情况被称为“崩溃”。

问题在于，当这些崩溃发生时，计算机程序（甚至人类）很难弄清楚它们为什么会发生，以及如何修复。为什么？因为缺乏一个良好的“实战测试”来教导调试工具如何识别这些特定的错误。

现在，JunoBench登场了。将 JunoBench 想象成一个为修复崩溃的机器人准备的大型、有组织的训练健身房。

以下是该论文关于这一新工具的简要解读：

1. 数据集（“崩溃图书馆”）

研究人员从公开的食谱书（Kaggle Notebook）中搜集了111 个真实的“爆炸蛋糕”案例。

并非任意错误：他们专门寻找那些导致程序完全停止运行的崩溃。
“修复前”与“修复后”：对于每一个崩溃，他们并没有将其留作未修复状态，而是手动进行了修复。因此，对于这 111 个损坏的 Notebook，现在都对应着一个“已修复”版本。
成分构成：他们确保这些崩溃源自数据科学家常用的各种流行工具，如 TensorFlow、PyTorch 和 Scikit-learn，同时也包含了 Notebook 特有的错误（例如在混合原料之前就执行了某一步骤）。

2. 实验室（“可复现的厨房”）

修复计算机错误时最大的头疼问题之一是，崩溃可能在一台计算机上发生，而在另一台上却不发生，这往往是由于软件版本不同所致。

解决方案：JunoBench 附带了一个Docker 镜像。你可以将其想象为一个密封的、自包含的厨房盒子。无论谁打开它，其中的烤箱、搅拌机和原料都完全一致。这确保了如果在盒子内发生崩溃，那么对于每一位研究人员来说，它都会每一次都发生。这使得测试既公平又可靠。

3. 标签（“诊断卡”）

你不能只说“它坏了”。你需要知道它是如何坏的。研究人员像专家医生一样，为每一次崩溃提供了一份详细的“医疗报告”：

是谁造成的？（是 TensorFlow 库？还是 Pandas 数据工具？）
症状是什么？（数值形状是否出错？变量是否消失？）
为什么会发生？（用户是否输入了错误的命令？是否忘记先加载数据？）
发生在过程的哪个阶段？（是在构建模型时、训练时，还是在查看结果时？）

4. 为何这很重要（“训练场”）

在 JunoBench 出现之前，如果研究人员想要构建一种能够自动修复这些崩溃的工具，他们不得不进行猜测，或者使用杂乱无章、不一致的示例。

新标准：现在，研究人员可以将他们新的“修复”工具在 JunoBench 上进行测试。他们可以观察：“你的工具是否发现了崩溃？它是否知道是哪个库导致的？它是否正确修复了它？”
特定挑战：论文强调，Notebook 崩溃之所以棘手，是因为计算机“记住”了先前步骤中的内容（例如，在第 1 个单元格中定义的变量在第 10 个单元格中被使用）。JunoBench 有助于测试新工具是否能理解这种“记忆”以及事件的顺序。

JunoBench 不是什么（严格基于论文内容）

它不是一个能立即修复你个人代码的工具。
它不是世界上所有可能错误的集合；它是一个经过策划、平衡的 111 个特定错误的样本。
它不包含“静默”错误（即代码运行但给出错误答案的情况）；它仅包含导致程序停止的“响亮”崩溃。

简而言之：JunoBench 是一个标准化、可复现且标注完善的集合，包含 111 个损坏的 AI Notebook 及其修复方案。它旨在成为那些承诺帮助开发者更快、更好地发现并修复此类特定错误的新型软件工具的“期末考试”。

以下是论文《JunoBench：Python 机器学习 Jupyter 笔记本崩溃基准数据集》的详细技术总结。

1. 问题陈述

Jupyter 笔记本是 Python 中进行机器学习（ML）和深度学习（DL）原型设计与实验的主导环境。然而，基于笔记本的 ML 开发在调试支持方面存在局限。这一局限源于缺乏专为该环境设计的真实、可执行的基准数据集。

现有的 ML 缺陷基准（如 Defect4ML、gDefects4DL）主要侧重于：

基于脚本的工件（.py 文件）： 它们忽略了笔记本（.ipynb）的独特语义，例如持久化的执行状态和非线性（乱序）的单元格执行。
异质症状： 它们通常将崩溃与性能下降或功能错误混合在一起，使得评估专门针对崩溃的调试工具变得困难。
可复现性问题： 许多基准缺乏标准化的执行环境，导致在不同系统上可靠地复现缺陷变得困难。

作者认为，崩溃（程序终止）是 ML 程序中最具破坏性和可观察性的症状，因此是评估自动化调试、诊断和修复技术的理想目标。

2. 方法论

JunoBench 的构建遵循了严格的、多阶段的流程（如论文图 1 所示），以确保可复现性、平衡性和有效性。

A. 数据收集与过滤

来源： 源自先前的一项实证研究，该研究分析了 64,031 个笔记本（来自 GitHub 和 Kaggle）。
选择标准：
1. 平台： 限制为Kaggle 笔记本，以确保能够访问公共数据集并拥有受控环境。
2. 相关性： 聚焦于与 ML 库（如 TensorFlow、PyTorch）相关的崩溃，或笔记本特有的问题（如乱序执行）。
3. 排除： 移除了依赖硬件的崩溃（如 GPU 内存限制）或无法确定性复现的特定环境缺陷。
重采样： 为解决库之间分布不均的问题，作者从未标记的 3,519 个崩溃池中进行了重采样。他们使用启发式工具，根据库导入和回溯分析对笔记本进行优先级排序，旨在实现均衡覆盖。

B. 基准包含与复现

隔离： 每个基准实例都是一个独立的笔记本，包含单个、隔离的崩溃。
每个实例的三个版本：
1. 原始版： 按收集时的样子。
2. 复现版： 进行最小调整（如执行顺序、路径），以确保崩溃的发生与原始情况完全一致。
3. 修复版： 手动修复的版本，在保留原始意图的同时解决了崩溃问题。
数据处理： 如果崩溃行为得以保留，输入数据集会被下采样（例如，将 2.5GB 的图像数据集减少到 94MB），以减少存储和执行开销。对于许可受限的数据，则使用合成数据。

C. 标注与注释

分类： 使用扎根理论，标注人员对每个崩溃按四个维度进行标注：
1. 库原因： 触发崩溃的库（如 NumPy、Pandas、PyTorch）。
2. 崩溃类型： 具体的错误表现（如张量形状不匹配、变量未找到）。
3. 根本原因： 开发者的底层错误（如 API 误用、数据混淆）。
4. ML 流水线阶段： 崩溃发生的阶段（如数据准备、训练、评估）。
诊断标签： 用自然语言总结解释故障机制和定位，并由第二位标注人员验证。
质量控制： 标注者间的一致性很高（Cohen's $\kappa > 0.9$ ）。

D. 执行环境

统一 Docker 镜像： JunoBench 提供了一个包含所有必要依赖项的单一 Docker 镜像，以确保崩溃在不同机器上能够一致复现。
CLI 工具： 一个自动化的命令行工具，用于验证“复现版”是否崩溃，以及“修复版”是否成功运行。

3. 主要贡献

首个 ML 笔记本可执行基准： JunoBench 是首个提供111 个精心策划、可复现的真实世界崩溃的数据集，这些崩溃专门来自 Python ML Jupyter 笔记本，并配有经过验证的修复方案。
全面覆盖：
- 库：涵盖主要 DL/ML 库（TensorFlow/Keras、PyTorch、Scikit-learn）和数据科学库（Pandas、NumPy、Matplotlib、Seaborn）。
- 笔记本语义： 包含 20 个专门由乱序执行和状态不一致引起的崩溃，这是笔记本特有的挑战。
结构化的真实数据： 每个崩溃都包含经人工验证的标签，涵盖库原因、崩溃类型、根本原因、流水线阶段以及自然语言诊断摘要。
可复现性基础设施： 统一的 Docker 环境和 CLI 工具，允许研究人员通过单条命令复现所有 111 个案例，消除了环境配置的障碍。

4. 结果与数据集特征

最终数据集包含111 个可复现的崩溃，其分布如下：

库原因： 分布均衡，TensorFlow/Keras、PyTorch、Scikit-learn、NumPy 和 Pandas 各有约 15 个崩溃。包括 20 个笔记本特有崩溃和 16 个涉及可视化或小型库的崩溃。
根本原因：
- API 误用： 45 例（最常见，如无效参数）。
- 数据混淆： 25 例（形状/类型不匹配）。
- 实现错误： 18 例（逻辑缺陷）。
- 笔记本特有： 20 例（状态问题）。
崩溃类型： 包括无效参数（21 例）、张量形状不匹配（16 例）、变量未找到（10 例）和不受支持的广播（5 例）。
流水线阶段： 崩溃发生在整个 ML 生命周期中，其中模型训练（31 例）和数据准备（30 例）的频率最高。

5. 意义与研究机会

JunoBench 使得系统性地评估调试技术成为可能，而此前由于缺乏数据，这些评估无法进行。它支持的关键研究方向包括：

崩溃检测与自动修复： 评估能够跨多个单元格识别崩溃并提出修复方案的工具，这些方案需考虑持久化的内核状态。
流水线感知调试： 研究崩溃如何从数据准备阶段传播到模型训练，这需要跨库的理解能力。
基于大语言模型（LLM）的分析： 为大型语言模型（LLM）提供测试平台，使其能够推理状态化执行和跨单元格依赖关系。论文指出，当前的 LLM 在此方面表现挣扎，F1 分数介于 57.7% 到 64.6% 之间。
基于代理的调试： 支持开发自主代理，使其能够在笔记本环境中迭代检查变量、重新执行单元格并提出修复方案。

结论

JunoBench 通过提供首个标准化的、可执行的笔记本崩溃基准，填补了 ML 软件工程研究中的关键空白。通过结合真实数据、经过验证的修复方案、结构化注释和可复现的环境，它成为推动交互式 ML 开发工作流自动化调试、诊断和修复工具发展的基础性资源。