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

1. Declaração do Problema

Os notebooks Jupyter são o ambiente dominante para prototipagem e experimentação com Aprendizado de Máquina (ML) e Aprendizado Profundo (DL) em Python. No entanto, o suporte à depuração para o desenvolvimento de ML baseado em notebooks é limitado. Essa limitação decorre da falta de conjuntos de dados de benchmark realistas e executáveis projetados especificamente para este ambiente.

Os benchmarks de bugs existentes para ML (por exemplo, Defect4ML, gDefects4DL) focam principalmente em:

• Artefatos baseados em scripts (.py files): Ignoram as semânticas únicas dos notebooks (.ipynb), como estado de execução persistente e execução de células não linear (fora de ordem).
• Sintomas heterogêneos: Frequentemente misturam falhas (crashes) com degradação de desempenho ou funcionalidade incorreta, dificultando a avaliação de ferramentas de depuração específicas para falhas.
• Problemas de reprodutibilidade: Muitos carecem de ambientes de execução padronizados, tornando difícil reproduzir bugs de forma confiável em diferentes sistemas.

Os autores argumentam que falhas (terminações de programa) são o sintoma mais disruptivo e observável em programas de ML, tornando-as o alvo ideal para avaliar técnicas automatizadas de depuração, diagnóstico e reparo.

2. Metodologia

A construção do JunoBench seguiu um pipeline rigoroso e multifásico (ilustrado na Figura 1 do artigo) para garantir reprodutibilidade, equilíbrio e validade.

A. Coleta e Filtragem de Dados

• Fonte: Derivado de um estudo empírico anterior que analisou 64.031 notebooks (GitHub e Kaggle).
• Critérios de Seleção:
  1. Plataforma: Restrito a notebooks do Kaggle para garantir acesso a conjuntos de dados públicos e um ambiente controlado.
  2. Relevância: Focado em falhas relacionadas a bibliotecas de ML (por exemplo, TensorFlow, PyTorch) ou problemas específicos de notebooks (por exemplo, execução fora de ordem).
  3. Exclusão: Removidas falhas dependentes de hardware (por exemplo, limites de memória de GPU) ou bugs específicos de ambiente que não podem ser reproduzidos deterministicamente.
• Reamostragem: Para abordar a distribuição desigual entre bibliotecas, os autores reamostraram de um conjunto não rotulado de 3.519 falhas. Utilizaram uma ferramenta heurística para priorizar notebooks com base em imports de bibliotecas e análise de rastreamento de exceção (traceback), visando uma cobertura equilibrada.

B. Inclusão e Reprodução do Benchmark

• Isolamento: Cada instância do benchmark é um notebook independente contendo uma única falha isolada.
• Três Versões por Instância:
  1. Original: Como coletado.
  2. Reproduzida: Ajustes mínimos (por exemplo, ordem de execução, caminhos) para garantir que a falha ocorra exatamente como no original.
  3. Corrigida: Uma versão reparada manualmente onde a falha é resolvida, preservando a intenção original.
• Tratamento de Dados: Conjuntos de dados de entrada foram subamostrados (por exemplo, reduzindo um conjunto de dados de imagens de 2,5 GB para 94 MB) se o comportamento da falha fosse preservado, para reduzir sobrecarga de armazenamento e execução. Dados sintéticos foram usados para licenças restritivas.

C. Rotulagem e Anotação

• Categorização: Usando teoria fundamentada, os anotadores rotularam cada falha em quatro dimensões:
  1. Causa da Biblioteca: Qual biblioteca desencadeou a falha (por exemplo, NumPy, Pandas, PyTorch).
  2. Tipo de Falha: Manifestação específica do erro (por exemplo, incompatibilidade de forma de tensor, variável não encontrada).
  3. Causa Raiz: O erro subjacente do desenvolvedor (por exemplo, uso indevido de API, confusão de dados).
  4. Estágio do Pipeline de ML: Onde a falha ocorreu (por exemplo, preparação de dados, treinamento, avaliação).
• Rótulos de Diagnóstico: Resumos em linguagem natural explicando o mecanismo de falha e a localização, validados por um segundo anotador.
• Controle de Qualidade: O acordo entre anotadores foi alto ($\kappa$ de Cohen > 0,9).

D. Ambiente de Execução

• Imagem Docker Unificada: O JunoBench fornece uma única imagem Docker contendo todas as dependências necessárias para garantir que as falhas se reproduzam consistentemente em diferentes máquinas.
• Ferramenta de CLI: Uma ferramenta automatizada de linha de comando verifica se a versão "reproduzida" falha e se a versão "corrigida" executa com sucesso.

3. Principais Contribuições

1. Primeiro Benchmark Executável para Notebooks de ML: O JunoBench é o primeiro conjunto de dados fornecendo 111 falhas reais curadas e reproduzíveis especificamente de notebooks Jupyter de ML em Python, acompanhadas de correções verificadas.
2. Cobertura Abrangente:
   • Bibliotecas: Cobre principais bibliotecas de DL/ML (TensorFlow/Keras, PyTorch, Scikit-learn) e bibliotecas de ciência de dados (Pandas, NumPy, Matplotlib, Seaborn).
   • Semântica de Notebook: Inclui 20 falhas causadas especificamente por execução fora de ordem e inconsistências de estado, um desafio único em notebooks.
3. Verdade Terrestre Estruturada: Cada falha inclui rótulos validados por humanos para causa da biblioteca, tipo de falha, causa raiz, estágio do pipeline e resumos de diagnóstico em linguagem natural.
4. Infraestrutura de Reprodutibilidade: Um ambiente Docker unificado e uma ferramenta de CLI que permitem aos pesquisadores reproduzir todos os 111 casos com um único comando, eliminando barreiras de configuração de ambiente.

4. Resultados e Características do Conjunto de Dados

O conjunto de dados final compreende 111 falhas reproduzíveis com a seguinte distribuição:

• Causa da Biblioteca: Distribuição equilibrada com ~15 falhas cada para TensorFlow/Keras, PyTorch, Scikit-learn, NumPy e Pandas. Inclui 20 falhas específicas de notebook e 16 envolvendo visualização ou bibliotecas menores.
• Causa Raiz:
  • Uso Indevido de API: 45 casos (mais frequente, por exemplo, argumentos inválidos).
  • Confusão de Dados: 25 casos (incompatibilidades de forma/tipo).
  • Erros de Implementação: 18 casos (falhas de lógica).
  • Específicos de Notebook: 20 casos (problemas de estado).
• Tipos de Falha: Inclui argumentos inválidos (21), incompatibilidades de forma de tensor (16), variável não encontrada (10) e transmissões não suportadas (5).
• Estágio do Pipeline: As falhas ocorrem em todo o ciclo de vida de ML, com a maior frequência em Treinamento de Modelo (31) e Preparação de Dados (30).

5. Significado e Oportunidades de Pesquisa

O JunoBench permite a avaliação sistemática de técnicas de depuração que anteriormente eram impossíveis de avaliar devido à falta de dados. As principais direções de pesquisa que ele suporta incluem:

• Detecção de Falhas e Reparo Automatizado: Avaliar ferramentas que podem identificar falhas em múltiplas células e sugerir correções que levam em conta o estado persistente do kernel.
• Depuração Consciente do Pipeline: Estudar como as falhas se propagam dos estágios de preparação de dados para o treinamento de modelos, exigindo compreensão entre bibliotecas.
• Análise Baseada em LLMs: Fornecer um campo de testes para Modelos de Linguagem de Grande Escala (LLMs) raciocinarem sobre execução com estado e dependências entre células. O artigo observa que os LLMs atuais lutam com isso, alcançando pontuações F1 entre 57,7% e 64,6%.
• Depuração Baseada em Agentes: Suportar o desenvolvimento de agentes autônomos que podem inspecionar iterativamente variáveis, reexecutar células e propor correções dentro de um ambiente de notebook.

Conclusão

O JunoBench preenche uma lacuna crítica na pesquisa de engenharia de software de ML ao fornecer o primeiro benchmark padronizado e executável para falhas em notebooks. Ao combinar dados realistas, correções verificadas, anotações estruturadas e um ambiente reproduzível, ele serve como um recurso fundamental para avançar ferramentas automatizadas de depuração, diagnóstico e reparo para o fluxo de trabalho de desenvolvimento interativo de ML.