Containing the Reproducibility Gap: Automated Repository-Level Containerization for Scholarly Jupyter Notebooks

1. Problema e Contexto

A reprodutibilidade computacional é fundamental para a ciência confiável, mas permanece difícil de alcançar na prática, especialmente em Jupyter Notebooks publicados junto a artigos científicos. O principal desafio é o "desvio de ambiente" (environment drift), que inclui:

• Dependências não documentadas.
• Assunções implícitas de execução (ordem, dados, credenciais externas).
• Falta de especificação de versões de bibliotecas.

Estudos empíricos mostram que a maioria dos notebooks publicados falha ao ser reexecutada em ambientes limpos. As abordagens existentes são limitadas: estudos diagnósticos identificam falhas, mas não as corrigem; ferramentas de execução (como o Binder) exigem configuração manual ou personalização específica, não escalando bem para grandes repositórios web. Além disso, a reconstrução de ambientes é frequentemente ad hoc e não integrada a fluxos de trabalho automatizados.

2. Metodologia

Os autores propõem um pipeline de engenharia de reprodutibilidade automatizado e orientado à web, focado na gestão de ambientes ao nível do repositório (e não apenas por notebook). O sistema opera em quatro estágios sequenciais:

• Estágio 1: Descoberta e Validação de Repositórios:
  • O sistema rastreia automaticamente repositórios públicos do GitHub referenciados no PubMed Central.
  • Valida a acessibilidade e separa os dados em um esquema relacional normalizado (ID do repositório, notebook e execução) para rastreabilidade.
• Estágio 2: Inferência e Reconstrução Autônoma de Ambiente:
  • Descoberta Explícita: Analisa arquivos como requirements.txt e setup.py.
  • Inferência Implícita (Inovação): Realiza análise estática de todas as instruções de import nos notebooks para inferir dependências não documentadas.
  • Geração de Container: Sintetiza um requirements.txt consolidado e gera um Dockerfile dinamicamente (baseado em python:3.10-slim) para pré-instalar todas as dependências e utilitários necessários.
• Estágio 3: Execução Isolada em Container:
  • Executa os notebooks dentro de contêineres Docker isolados ("clean-room"), garantindo que não haja contaminação de ambientes anteriores.
  • Utiliza o jupyter nbconvert --execute com a flag --allow-errors para garantir que notebooks com falhas parciais ainda gerem artefatos de saída e rastreamento de erros, em vez de falhar silenciosamente.
• Estágio 4: Avaliação Comparativa e Relatórios:
  • Compara a saída original do notebook com a saída reexecutada no container usando a biblioteca nbdime.
  • Calcula métricas granulares ao nível da célula (células idênticas vs. diferentes) e classifica os tipos de falha (dependência, dados, lógica, etc.).

3. Principais Contribuições

1. Pipeline Automatizado de Ponta a Ponta: Infraestrutura de execução centrada no repositório que automatiza a descoberta, inferência de dependências, síntese de containers e avaliação de reprodutibilidade.
2. Reconstrução de Ambiente ao Nível do Repositório: Formalização da reconstrução de ambientes combinando dependências declaradas com inferência baseada em imports e isolamento via container.
3. Avaliação Empírica em Grande Escala: Teste do pipeline em 443 notebooks de 116 repositórios do GitHub (referenciados no PubMed Central), fornecendo evidências quantitativas sobre a robustez da execução.
4. Análise Estruturada de Falhas e "Drift": Criação de uma taxonomia de falhas e métricas de reprodutibilidade que vão além de um simples "sucesso/fracasso", identificando raízes infraestruturais da irreprodutibilidade.

4. Resultados

O estudo comparou o pipeline baseado em containers com uma linha de base anterior (sem containers, baseada apenas em Conda):

• Resolução de Falhas de Dependência: A containerização resolveu 66,7% das falhas relacionadas a dependências que ocorriam na linha de base. Isso demonstra que muitos problemas de reprodutibilidade são, na verdade, problemas de gestão de infraestrutura e dependências, e não de lógica de pesquisa.
• Mudança no Perfil de Erros: Com a containerização, os erros de instalação de dependências diminuíram drasticamente, mas os erros de tempo de execução (runtime) tornaram-se predominantes (ex: ModuleNotFoundError para módulos internos, FileNotFoundError para caminhos de dados hardcoded).
• A Lacuna de Reprodutibilidade (Reproducibility Gap):
  • Embora a execução tenha melhorado, 53,7% dos notebooks apresentaram baixa fidelidade de saída (pontuação de reprodutibilidade entre 0,0 e 0,2).
  • Apenas 3,4% dos notebooks tiveram correspondência perfeita (bit-wise) com o original.
  • Causa Principal: A não-determinismo estocástico (25,7% dos notebooks continham chamadas a random, uuid, time, etc.) e dependências de dados externas não resolvidas.
• Impacto de Especificações Explícitas: Notebooks com requirements.txt explícito tiveram uma pontuação de reprodutibilidade ligeiramente melhor, mas a especificação explícita sozinha não garantiu resultados determinísticos.

5. Significado e Conclusão

O artigo conclui que a containerização padronizada é essencial para a estabilidade computacional, mas insuficiente para a reprodutibilidade total (bit-wise).

• Engenharia de Reprodutibilidade: O trabalho trata a reprodutibilidade como um problema de engenharia, oferecendo uma solução escalável para pesquisadores, editores e arquivistas avaliarem artefatos computacionais sistematicamente.
• Limitações: O sistema não pode resolver problemas de "link rot", chaves de API expiradas, falta de dados externos ou não-determinismo intrínseco. Além disso, a base de imagens modernas de Python pode não suportar artefatos legados (Python 2.7) ou dependências de GPU sem configurações específicas.
• Futuro: Os autores planejam integrar o pipeline em fluxos de submissão de manuscritos (sistema de "Badges de Reprodutibilidade"), usar LLMs para prever dependências e corrigir erros automaticamente, e expandir para ambientes de HPC (GPU).

Em suma, o sistema transforma a reprodutibilidade de um processo manual e falho em um fluxo de trabalho automatizado que isola e diagnostica com precisão onde e por que a pesquisa computacional falha ao ser reexecutada.