💻 computer science

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

Este artículo presenta JunoBench, el primer conjunto de datos de referencia que comprende 111 fallos reales curados y reproducibles y sus correcciones extraídos de cuadernos públicos de Kaggle, diseñado para avanzar en la investigación sobre la depuración y reparación de código de aprendizaje automático en entornos Jupyter.

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

Publicado 2026-05-01

📖 4 min de lectura☕ Lectura para el café

CC BY 4.0

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

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás intentando hornear un pastel complejo usando un libro de recetas donde puedes escribir nuevas notas, saltar pasos o cambiar el orden de las instrucciones a medida que avanzas. Esto es lo que hacen los científicos de datos cuando utilizan Jupyter Notebooks para construir programas de Aprendizaje Automático (IA). Es flexible y divertido, pero como puedes mezclar el orden de los pasos, las cosas a menudo salen mal. El pastel podría quemarse, el horno podría explotar o la masa podría convertirse en pegamento. A esto se le llama "fallos".

El problema es que, cuando ocurren estos fallos, es muy difícil para los programas informáticos (o incluso para los humanos) averiguar por qué ocurrieron y cómo solucionarlos. ¿Por qué? Porque no había un buen "examen de práctica" disponible para enseñar a las herramientas de depuración cómo detectar estos errores específicos.

Aquí entra JunoBench. Piensa en JunoBench como un gimnasio de entrenamiento gigante y organizado para robots reparadores de fallos.

Aquí está lo que el artículo dice sobre esta nueva herramienta, desglosado de forma sencilla:

1. La Colección (La "Biblioteca de Fallos")

Los investigadores salieron y encontraron 111 ejemplos reales de estos "pasteles que explotan" en libros de recetas públicos (cuadernos de Kaggle).

No cualquier error: Buscaron específicamente fallos que detienen el programa en seco.
El "Antes y Después": Para cada fallo individual, no solo lo dejaron roto. Lo repararon manualmente. Así, para cada uno de los 111 cuadernos rotos, ahora existe una versión correspondiente "Reparada".
Los Ingredientes: Se aseguraron de que los fallos provinieran de todas las herramientas populares que usan los científicos de datos, como TensorFlow, PyTorch y Scikit-learn, así como de errores específicos del estilo de cuaderno (como ejecutar un paso antes de que los ingredientes estuvieran incluso mezclados).

2. El Laboratorio (La "Cocina Reproducible")

Uno de los mayores dolores de cabeza al corregir errores informáticos es que un fallo puede ocurrir en una computadora pero no en otra debido a diferentes versiones de software.

La Solución: JunoBench viene con una imagen de Docker. Imagina esto como una caja de cocina sellada y autocontenida. Sin importar quién la abra, el horno, la batidora y los ingredientes son exactamente los mismos. Esto asegura que si un fallo ocurre dentro de la caja, ocurrirá cada vez que para cada investigador. Esto hace que las pruebas sean justas y fiables.

3. Las Etiquetas (Las "Tarjetas de Diagnóstico")

No puedes simplemente decir "se rompió". Necesitas saber cómo se rompió. Los investigadores actuaron como médicos expertos y dieron a cada fallo un informe médico detallado:

¿Quién lo causó? (¿Fue la biblioteca TensorFlow? ¿O la herramienta de datos Pandas?)
¿Cuál fue el síntoma? (¿Los números tomaron la forma incorrecta? ¿Desapareció una variable?)
¿Por qué ocurrió? (¿El usuario escribió el comando incorrecto? ¿Olvidaron cargar los datos primero?)
¿En qué parte del proceso? (¿Ocurrió mientras se construía el modelo, se entrenaba o se analizaban los resultados?)

4. Por qué esto es importante (El "Campo de Entrenamiento")

Antes de JunoBench, si un investigador quería construir una herramienta para corregir automáticamente estos fallos, tenía que adivinar o usar ejemplos desordenados e inconsistentes.

El Nuevo Estándar: Ahora, los investigadores pueden tomar sus nuevas herramientas de "reparación" y ejecutarlas contra JunoBench. Pueden ver: "¿Tu herramienta encontró el fallo? ¿Sabió qué biblioteca lo causó? ¿Lo reparó correctamente?"
Desafíos Específicos: El artículo destaca que los fallos en cuadernos son complicados porque la computadora "recuerda" cosas de pasos anteriores (como una variable definida en la celda #1 siendo usada en la celda #10). JunoBench ayuda a probar si las nuevas herramientas pueden entender esta "memoria" y el orden de los eventos.

Lo que JunoBench NO es (Basado estrictamente en el artículo)

No es una herramienta para arreglar tu propio código ahora mismo.
No es una colección de cada error posible en el mundo; es una muestra curada y equilibrada de 111 errores específicos.
No incluye errores "silenciosos" donde el código se ejecuta pero da la respuesta incorrecta; solo incluye fallos "ruidosos" que detienen el programa.

En resumen: JunoBench es una colección estandarizada, reproducible y bien etiquetada de 111 cuadernos de IA rotos y sus soluciones. Está diseñada para ser el "examen final" para nuevas herramientas de software que prometen ayudar a los desarrolladores a encontrar y corregir estos tipos específicos de errores más rápido y mejor.

A continuación se presenta un resumen técnico detallado del artículo "JunoBench: A Benchmark Dataset of Crashes in Python Machine Learning Jupyter Notebooks".

1. Enunciado del Problema

Los cuadernos Jupyter son el entorno dominante para la prototipación y experimentación con Aprendizaje Automático (ML) y Aprendizaje Profundo (DL) en Python. Sin embargo, el soporte para la depuración en el desarrollo de ML basado en cuadernos es limitado. Esta limitación surge de la falta de conjuntos de datos de referencia realistas y ejecutables diseñados específicamente para este entorno.

Los conjuntos de datos de referencia de errores existentes para ML (por ejemplo, Defect4ML, gDefects4DL) se centran principalmente en:

Artefactos basados en scripts (archivos .py): Ignoran la semántica única de los cuadernos (.ipynb), como el estado de ejecución persistente y la ejecución de celdas no lineal (fuera de orden).
Síntomas heterogéneos: A menudo mezclan fallos (crashes) con degradación del rendimiento o funcionalidad incorrecta, lo que dificulta evaluar herramientas de depuración específicas para fallos.
Problemas de reproducibilidad: Muchos carecen de entornos de ejecución estandarizados, lo que dificulta reproducir errores de manera fiable en diferentes sistemas.

Los autores argumentan que los fallos (terminaciones del programa) son el síntoma más disruptivo y observable en los programas de ML, lo que los convierte en el objetivo ideal para evaluar técnicas automatizadas de depuración, diagnóstico y reparación.

2. Metodología

La construcción de JunoBench siguió una tubería rigurosa y multietapa (ilustrada en la Figura 1 del artículo) para garantizar la reproducibilidad, el equilibrio y la validez.

A. Recopilación y Filtrado de Datos

Fuente: Derivado de un estudio empírico previo que analizó 64,031 cuadernos (GitHub y Kaggle).
Criterios de Selección:
1. Plataforma: Restringido a cuadernos de Kaggle para garantizar el acceso a conjuntos de datos públicos y un entorno controlado.
2. Relevancia: Enfocado en fallos relacionados con bibliotecas de ML (por ejemplo, TensorFlow, PyTorch) o problemas específicos de cuadernos (por ejemplo, ejecución fuera de orden).
3. Exclusión: Se eliminaron fallos dependientes del hardware (por ejemplo, límites de memoria de la GPU) o errores específicos del entorno que no pueden reproducirse de manera determinista.
Remuestreo: Para abordar la distribución desigual entre bibliotecas, los autores realizaron un remuestreo de un conjunto no etiquetado de 3,519 fallos. Utilizaron una herramienta heurística para priorizar cuadernos basándose en las importaciones de bibliotecas y el análisis de trazas de seguimiento, con el objetivo de lograr una cobertura equilibrada.

B. Inclusión y Reproducción del Conjunto de Referencia

Aislamiento: Cada instancia del conjunto de referencia es un cuaderno independiente que contiene un único fallo aislado.
Tres Versiones por Instancia:
1. Original: Tal como se recopiló.
2. Reproducida: Ajustes mínimos (por ejemplo, orden de ejecución, rutas) para garantizar que el fallo ocurra exactamente como en el original.
3. Corregida: Una versión reparada manualmente donde el fallo se resuelve preservando la intención original.
Manejo de Datos: Los conjuntos de datos de entrada se submuestrearon (por ejemplo, reduciendo un conjunto de datos de imágenes de 2.5 GB a 94 MB) si se conservaba el comportamiento del fallo, para reducir la sobrecarga de almacenamiento y ejecución. Se utilizaron datos sintéticos para licencias restrictivas.

C. Etiquetado y Anotación

Categorización: Utilizando teoría fundamentada, los anotadores etiquetaron cada fallo en cuatro dimensiones:
1. Causa de la Biblioteca: Qué biblioteca desencadenó el fallo (por ejemplo, NumPy, Pandas, PyTorch).
2. Tipo de Fallo: Manifestación específica del error (por ejemplo, desajuste de forma de tensor, variable no encontrada).
3. Causa Raíz: El error subyacente del desarrollador (por ejemplo, mal uso de la API, confusión de datos).
4. Etapa del Pipeline de ML: Dónde ocurrió el fallo (por ejemplo, preparación de datos, entrenamiento, evaluación).
Etiquetas de Diagnóstico: Resúmenes en lenguaje natural que explican el mecanismo de fallo y la localización, validados por un segundo anotador.
Control de Calidad: El acuerdo entre anotadores fue alto (Cohen's $\kappa > 0.9$ ).

D. Entorno de Ejecución

Imagen Docker Unificada: JunoBench proporciona una única imagen Docker que contiene todas las dependencias necesarias para garantizar que los fallos se reproduzcan de manera consistente en diferentes máquinas.
Herramienta CLI: Una herramienta automatizada de línea de comandos verifica que la versión "reproducida" falle y que la versión "corregida" se ejecute con éxito.

3. Contribuciones Clave

Primer Conjunto de Referencia Ejecutable para Cuadernos de ML: JunoBench es el primer conjunto de datos que proporciona 111 fallos reales curados y reproducibles específicamente de cuadernos Jupyter de ML en Python, junto con correcciones verificadas.
Cobertura Exhaustiva:
- Bibliotecas: Cubre las principales bibliotecas de DL/ML (TensorFlow/Keras, PyTorch, Scikit-learn) y bibliotecas de ciencia de datos (Pandas, NumPy, Matplotlib, Seaborn).
- Semántica de Cuadernos: Incluye 20 fallos causados específicamente por ejecución fuera de orden e inconsistencias de estado, un desafío único en los cuadernos.
Verdad Terrenal Estructurada: Cada fallo incluye etiquetas validadas por humanos para la causa de la biblioteca, tipo de fallo, causa raíz, etapa del pipeline y resúmenes de diagnóstico en lenguaje natural.
Infraestructura de Reproducibilidad: Un entorno Docker unificado y una herramienta CLI que permiten a los investigadores reproducir los 111 casos con un solo comando, eliminando las barreras de configuración del entorno.

4. Resultados y Características del Conjunto de Datos

El conjunto de datos final comprende 111 fallos reproducibles con la siguiente distribución:

Causa de la Biblioteca: Distribución equilibrada con aproximadamente 15 fallos cada uno para TensorFlow/Keras, PyTorch, Scikit-learn, NumPy y Pandas. Incluye 20 fallos específicos de cuadernos y 16 que involucran visualización o bibliotecas menores.
Causa Raíz:
- Mal Uso de la API: 45 casos (el más frecuente, por ejemplo, argumentos inválidos).
- Confusión de Datos: 25 casos (desajustes de forma/tipo).
- Errores de Implementación: 18 casos (fallos de lógica).
- Específicos de Cuadernos: 20 casos (problemas de estado).
Tipos de Fallo: Incluye argumentos inválidos (21), desajustes de forma de tensor (16), variable no encontrada (10) y transmisiones no soportadas (5).
Etapa del Pipeline: Los fallos ocurren a lo largo de todo el ciclo de vida de ML, con la mayor frecuencia en Entrenamiento de Modelos (31) y Preparación de Datos (30).

5. Significado y Oportunidades de Investigación

JunoBench permite la evaluación sistemática de técnicas de depuración que anteriormente era imposible evaluar debido a la falta de datos. Las direcciones de investigación clave que respalda incluyen:

Detección de Fallos y Reparación Automatizada: Evaluar herramientas que puedan identificar fallos a través de múltiples celdas y sugerir correcciones que tengan en cuenta el estado persistente del kernel.
Depuración Consciente del Pipeline: Estudiar cómo los fallos se propagan desde las etapas de preparación de datos hasta el entrenamiento del modelo, requiriendo una comprensión transversal de bibliotecas.
Análisis Basado en LLM: Proporcionar un campo de pruebas para Modelos de Lenguaje Grande (LLM) para razonar sobre la ejecución con estado y las dependencias entre celdas. El artículo señala que los LLM actuales tienen dificultades con esto, logrando puntuaciones F1 entre el 57.7% y el 64.6%.
Depuración Basada en Agentes: Apoyar el desarrollo de agentes autónomos que puedan inspeccionar iterativamente variables, reejecutar celdas y proponer correcciones dentro de un entorno de cuadernos.

Conclusión

JunoBench llena una brecha crítica en la investigación de ingeniería de software de ML al proporcionar el primer conjunto de referencia estandarizado y ejecutable para fallos en cuadernos. Al combinar datos realistas, correcciones verificadas, anotaciones estructuradas y un entorno reproducible, sirve como un recurso fundamental para avanzar en las herramientas automatizadas de depuración, diagnóstico y reparación para el flujo de trabajo de desarrollo interactivo de ML.