🤖 machine learning

Automated Modernization of Machine Learning Engineering Notebooks for Reproducibility

Este artigo apresenta o MLEModernizer, um framework de agentes impulsionado por LLM que moderniza automaticamente notebooks de engenharia de aprendizado de máquina para superar a erosão ambiental e restaurar a reprodutibilidade através da execução iterativa de código e aplicação de correções direcionadas, recuperando com sucesso mais de 40% dos notebooks anteriormente não reprodutíveis.

Autores originais: Bihui Jin, Kaiyuan Wang, Pengyu Nie

Publicado 2026-07-29

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Bihui Jin, Kaiyuan Wang, Pengyu Nie

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você é um viajante do tempo que adora olhar receitas antigas. Você encontra uma famosa receita de bolo de 2015 escrita em um caderno especial. A receita diz: "Misture farinha, açúcar e um ingrediente mágico chamado 'XGBoost' para obter um bolo perfeito". Você tenta assar esse bolo hoje, mas algo dá errado. O "XGBoost" que você compra na loja hoje é ligeiramente diferente; é mais forte, funciona de forma diferente e, quando você o mistura, a massa explode ou tem gosto de sabão. Este é o problema da "erosão ambiental". No mundo da Engenharia de Aprendizado de Máquina (MLE), cientistas e engenheiros usam cadernos interativos (como livros de receitas digitais) para construir modelos de IA. Eles compartilham esses cadernos para que outros possam aprender com eles ou usar seu código. Mas, à medida que computadores e softwares se atualizam rapidamente, os cadernos antigos muitas vezes quebram porque os "ingredientes" (bibliotecas de software) dos quais dependem mudaram ou desapareceram. Se você não consegue executar o código antigo, não pode verificar os resultados, e o conhecimento se perde. A grande questão é: Podemos consertar essas receitas antigas e quebradas para que funcionem na cozinha de hoje sem ter que reconstruir toda a cozinha do zero?

Este artigo, intitulado "Modernização Automatizada de Cadernos de Engenharia de Aprendizado de Máquina para Reprodutibilidade", mergulha exatamente neste problema. Os autores, Bihui Jin, Kaiyuan Wang e Pengyu Nie, decidiram testar o quão quebradas essas receitas digitais realmente estão. Eles reuniram uma coleção massiva de 12.106 cadernos de competições populares de aprendizado de máquina no Kaggle. Quando tentaram executar esses cadernos em um ambiente moderno, descobriram uma realidade dura: apenas 26% deles realmente funcionaram e produziram os mesmos resultados que produziam anos atrás. Os outros 74% estavam quebrados, ou travando com erros ou produzindo pontuações completamente diferentes.

Você pode pensar que a solução é simples: basta voltar no tempo e instalar exatamente as versões antigas do software para as quais a receita foi escrita. Isso é chamado de "retroportabilidade de ambiente" (environment backporting). Os autores tentaram isso ao fazer o downgrade de todo o software para corresponder à data em que o caderno foi originalmente enviado. Surpreendentemente, isso tornou as coisas piores! Em vez de 26% funcionando, apenas 12% tornaram-se reproduzíveis. Acontece que tentar reconstruir o passado é uma armadilha; as versões antigas do software são frequentemente inexistentes, incompatíveis com o hardware moderno ou simplesmente muito frágeis para rodar. Os autores argumentam que, em vez de tentar reconstruir a antiga cozinha, devemos consertar a própria receita para que funcione na nova cozinha.

Para resolver isso, a equipe construiu uma ferramenta chamada MLEModernizer. Pense nisso como um subchefe robótico super inteligente movido por um Modelo de Linguagem Grande (LLM). Este robô não apenas lê a receita; ele realmente tenta assar o bolo. Se o bolo queimar (ocorre um erro), o robô observa a fumaça, entende o que deu errado e reescreve a receita para consertá-la. Se o bolo demorar muito para assar (problemas de tempo de execução), o robô ajusta as instruções para acelerar o processo. Se o bolo tiver um sabor ligeiramente diferente (a pontuação está errada), o robô ajusta os ingredientes para recuperar o sabor do padrão original.

O robô trabalha em um ciclo: ele executa o código, verifica os resultados e, se algo estiver errado, pede à IA para escrever um "patch" (uma correção) para todo o caderno. Ele continua fazendo isso até 16 vezes, até que o caderno funcione. Os resultados foram bastante promissores. Quando testaram isso em 8.210 cadernos quebrados, a ferramenta conseguiu consertar cerca de 40% a 45% deles, tornando-os reproduzíveis novamente. Especificamente, usando um modelo de IA poderoso (GPT-5.2), eles consertaram 3.292 cadernos e, com um modelo de código aberto ligeiramente diferente (GPT-OSS-120b), consertaram 3.683.

No entanto, o artigo é cuidadoso ao não chamar isso de varinha mágica. Os autores descobriram que, embora a ferramenta pudesse acertar os números (a "pontuação"), às vezes o código subjacente mudava de formas que não eram exatamente iguais ao original. Por exemplo, a IA pode mudar a forma como um modelo é treinado apenas o suficiente para obter a pontuação correta, mas o "sabor" do código é diferente. Eles também descobriram que alguns erros são simplesmente teimosos demais para serem corrigidos automaticamente; a ferramenta era ótima para corrigir erros simples de "ingrediente faltando" (como esquecer de importar uma biblioteca), mas tinha dificuldade com erros complexos de "interação de ingredientes estranhos" (como erros de atributo onde um objeto não possui as propriedades corretas).

O custo deste chef robótico também é um fator. Os autores calcularam que consertar um caderno custa cerca de US$ 0,65 em média usando o modelo poderoso, o que eles sugerem ser barato o suficiente para uso em larga escala. Mas também observaram que o modelo de código aberto era muito mais barato (cerca de US$ 0,0074 por caderno), mas não mantinha o código tão fiel ao original.

No fim, o artigo sugere que, embora não possamos recriar perfeitamente o passado, podemos usar agentes de IA inteligentes para modernizar códigos antigos e salvar valioso trabalho científico. Não é um conserto perfeito para cada um dos cadernos quebrados, mas oferece uma maneira de "melhor esforço" para resgatar uma parte significativa da história do aprendizado de máquina que, de outra forma, seria perdida para o tempo. Os autores concluem que esta abordagem ajuda os profissionais a validar e reutilizar antigos fluxos de trabalho à medida que a tecnologia continua a evoluir, transformando receitas antigas e empoeiradas em algo que pode ser cozinhado na cozinha de hoje.

Resumo Técnico: Modernização Automatizada de Notebooks de Engenharia de Machine Learning para Reprodutibilidade

1. Declaração do Problema

Notebooks computacionais interativos (ex: Jupyter) são os artefatos primários para documentar e compartilhar pipelines de Engenharia de Machine Learning (MLE) de ponta a ponta. No entanto, esses notebooks sofrem de erosão ambiental: a rápida evolução dos ecossistemas de hardware e software torna muitos notebooks publicados não reprodutíveis em ambientes contemporâneos.

Os autores identificam uma lacuna crítica na reprodutibilidade atual:

A Lacuna: Um estudo em larga escala de 12.106 notebooks de 75 competições do Kaggle revelou que apenas 26% permanecem reprodutíveis em um ambiente moderno.
A Falha do Backporting: A prática padrão da indústria de "backporting de ambiente" (reduzir as dependências para corresponder ao timestamp de submissão do notebook) foi testada e considerada contraproducente. Em vez de melhorar a reprodutibilidade, o backporting reduziu a taxa de sucesso para 12% e introduziu modos de falha adicionais (ex: conflitos de dependências, rodas/wheels históricas indisponíveis).
O Desafio Central: Simplesmente executar o código em um ambiente histórico reconstruído é frequentemente inviável ou insuficiente. O próprio código deve ser modernizado para rodar e reproduzir pontuações na atual infraestrutura. Crucialmente, a "reprodutibilidade" em MLE não trata apenas de execução (ausência de erros); ela exige calibração de pontuação, onde o desempenho do modelo reproduzido permanece dentro de uma banda aceitável da pontuação originalmente reportada.

2. Metodologia: MLEModernizer

Para enfrentar a erosão ambiental, os autores projetaram e implementaram o MLEModernizer, um framework agêntico baseado em LLM. Diferente das ferramentas de reparo tradicionais que tratam o ambiente como uma variável a ser reconstruída, o MLEModernizer trata o ambiente contemporâneo como uma restrição fixa e moderniza iterativamente o código do notebook.

Fluxo de Trabalho Agêntico

O framework opera em um loop iterativo com um máximo de 16 iterações por notebook:

Execução e Feedback: O notebook é executado em um ambiente conteinerizado (alinhado com o modelo de execução do Kaggle). O sistema coleta feedback de execução, incluindo:
- Duração da execução (runtime).
- Tracebacks de erro (se houver).
- Pontuação reproduzida ( $s_r$ ) comparada à pontuação alvo ( $s_t$ ).
Detecção de Problemas: O sistema classifica a falha em uma das três categorias:
- Timeout: A execução excede o limite de 600 segundos.
- Erro: O notebook levanta exceções.
- Desvio de Pontuação: O notebook executa sem erros, mas a pontuação desvia significativamente do alvo.
Correção Direcionada por LLM: Com base no problema detectado, o MLEModernizer constrói um prompt específico para um Modelo de Linguagem Grande (LLM) para gerar um patch. O framework suporta três tipos distintos de correção:
- Reparo de Erro (Error-Repair): Corrige erros de execução (ex: mudanças de quebra de API, importações ausentes).
- Redução de Tempo de Execução (Runtime-Reduction): Otimiza o código para evitar timeouts (ex: habilitando aceleração por GPU, reduzindo subconjuntos de dados).
- Calibração de Pontuação (Score-Calibration): Ajusta o código para alinhar a pontuação reproduzida com o alvo (ex: lidando com desvios de rótulos, ajuste de hiperparâmetros) quando não existem erros.
Aplicação de Patch: O LLM retorna um plano e um patch de arquivo completo (o notebook inteiro). O MLEModernizer aplica este patch e repete o loop até que o notebook seja reprodutível ou o limite de iteração seja atingido.

Configuração de Avaliação

Dataset: 8.210 notebooks não reprodutíveis (filtrados dos 12.106 iniciais) foram selecionados para modernização.
Modelos: O sistema foi avaliado usando GPT-5.2 (proprietário) e GPT-OSS-120b (open-weight).
Métricas: A reprodutibilidade foi definida por um teste $t$ de uma amostra ( $p \ge 0,05$ ) ou um limiar heurístico ( $\tau = 10\%$ ) se as pontuações fossem determinísticas. A equivalência funcional foi avaliada via inspeção manual de uma subamostra estatística.

3. Resultados Principais

Recuperação de Reprodutibilidade

Taxas de Sucesso: O MLEModernizer restaurou com sucesso a reprodutibilidade para 40,1% dos notebooks não reprodutíveis usando GPT-5.2 (3.292 notebooks) e 44,9% usando GPT-OSS-120b (3.683 notebooks).
Livre de Erros vs. Contendo Erros:
- Com GPT-5.2, 2.397 notebooks tornaram-se "Reprodutíveis Livres de Erros", enquanto 895 foram "Reprodutíveis com Erros" (reprodutíveis apesar de erros residuais).
- Com GPT-OSS-120b, 2.877 tornaram-se "Reprodutíveis Livres de Erros", e 806 foram "Reprodutíveis com Erros".
Equivalência Funcional: Embora o GPT-OSS-120b tenha alcançado uma taxa bruta de reprodutibilidade maior, o GPT-5.2 produziu significativamente mais modernizações funcionalmente equivalentes (71,5% vs. 52,7%). Isso sugere um compromisso onde o modelo aberto alcança pontuações de forma mais agressiva, potencialmente alterando a semântica, enquanto o modelo proprietário preserva melhor a lógica original.

Estatísticas de Correção e Custos

Eficiência de Iteração: A maioria das modernizações bem-sucedidas exigiu poucas correções (mediana de 2). No entanto, alcançar o status de "Livre de Erros" tipicamente exigiu mais iterações (média de 4,35) do que alcançar o status de "Reprodutível com Erros" (média de 2,56).
Tipos de Correção: A Calibração de Pontuação foi o tipo de correção mais frequente aplicado (39.226 vezes), seguida por Reparo de Erro (27.765) e Redução de Tempo de Execução (15.718). A Calibração de Pontuação foi o principal motor para os resultados de "Reprodutível Livre de Erros".
Custo: O processo é economicamente viável para uso em larga escala.
- GPT-5.2: Custo médio de $0,65 USD por notebook.
- GPT-OSS-120b: Custo médio de $0,0074 USD por notebook.
Modificação de Código: Embora as correções individuais sejam frequentemente incrementais (alta similaridade de edição com a versão anterior), as modificações cumulativas podem ser substanciais. Notebooks que inicialmente sofreram timeout passaram pela maior divergência de código em relação à linha de base.

Análise de Erros

Redução de Erros: O sistema reduziu o total de erros de >92.000 na linha de base para ~4.000 após 16 correções.
Tipos de Erro: O NameError (nomes indefinidos/importações ausentes) foi efetivamente reduzido. No entanto, o AttributeError (atributos ausentes/inválidos) provou ser o mais persistente, permanecendo como o tipo de erro dominante tanto nos notebooks reprodutíveis quanto nos não reprodutíveis após a modernização. Isso indica que o drift de API e mudanças de atributos específicos de biblioteca são mais difíceis de automatizar do que simples correções de sintaxe ou importação.

4. Significância e Alegações

O artigo posiciona o MLEModernizer como uma técnica de recuperação e modernização automatizada de esforço máximo (best-effort). Os autores fazem as seguintes alegações sobre sua significância:

Mudança de Paradigma: O trabalho desafia o paradigma predominante de "reconstrução de ambiente" (backporting). Demonstra que tratar o ambiente como uma restrição fixa e modernizar o código é uma estratégia mais eficaz para restaurar a reprodutibilidade em ecossistemas de ML que evoluem rapidamente.
Utilidade Prática: Ao permitir a modernização automatizada de notebooks de MLE, a ferramenta facilita a validação e o reuso de pipelines de ML legados. Isso é crítico tanto para pesquisadores (transferindo conhecimento de protótipos legados) quanto para engenheiros (mantendo a usabilidade de longo prazo de pipelines de produção).
Limitações e Escopo: Os autores são modestos quanto às capacidades da ferramenta. Eles reconhecem que:
- A reprodução exata pode ser impossível devido aos ambientes evoluídos; a ferramenta fornece um ponto de partida para refinamento manual.
- A reprodutibilidade baseada em pontuação não garante equivalência funcional (embora a ferramenta tente preservá-la).
- Certos tipos de erro (especificamente AttributeError complexos) permanecem difíceis de resolver automaticamente.
- A avaliação depende de graduação offline (MLE-Bench), que aproxima, mas não replica perfeitamente, o leaderboard privado do Kaggle.

Em conclusão, o artigo afirma que, embora a modernização de código não seja uma solução definitiva, ela oferece um caminho viável e escalável para restaurar a reprodutibilidade para um subconjunto significativo de artefatos de MLE legados, preenchendo a lacuna entre o código histórico e a infraestrutura contemporânea.