🤖 machine learning

Automated Modernization of Machine Learning Engineering Notebooks for Reproducibility

Este artículo presenta MLEModernizer, un marco de agentes impulsado por LLM que moderniza automáticamente los cuadernos de ingeniería de aprendizaje automático para superar la erosión ambiental y restaurar la reproducibilidad mediante la ejecución iterativa de código y la aplicación de correcciones específicas, recuperando con éxito más del 40% de los cuadernos previamente no reproducibles.

Autores originales: Bihui Jin, Kaiyuan Wang, Pengyu Nie

Publicado 2026-07-29

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Bihui Jin, Kaiyuan Wang, Pengyu Nie

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 eres un viajero en el tiempo al que le encanta mirar recetas antiguas. Encuentras una famosa receta de pastel de 2015 escrita en un cuaderno especial. La receta dice: "Mezcle harina, azúcar y un ingrediente mágico llamado 'XGBoost' para obtener un pastel perfecto". Intentas hornearlo hoy, pero algo sale mal. El "XGBoost" que compras en la tienda hoy es ligeramente diferente; es más fuerte, funciona de manera distinta y, cuando lo mezclas, la masa explota o sabe a jabón. Este es el problema de la "erosión ambiental". En el mundo de la Ingeniería de Aprendizaje Automático (MLE), los científicos e ingenieros utilizan cuadernos interactivos (como libros de recetas digitales) para construir modelos de IA. Comparten estos cuadernos para que otros puedan aprender de ellos o usar su código. Pero a medida que las computadoras y el software se actualizan rápidamente, muchos cuadernos antiguos se rompen porque los "ingredientes" (librerías de software) de los que dependen han cambiado o desaparecido. Si no puedes ejecutar el código antiguo, no puedes verificar los resultados y el conocimiento se pierde. La gran pregunta es: ¿Podemos arreglar estas recetas viejas y rotas para que funcionen en la cocina de hoy sin tener que reconstruir toda la cocina desde cero?

Este artículo, titulado "Modernización Automatizada de Cuadernos de Ingeniería de Aprendizaje Automático para la Reproducibilidad", profundiza precisamente en este problema. Los autores, Bihui Jin, Kaiyuan Wang y Pengyu Nie, decidieron probar qué tan rotas están realmente estas recetas digitales. Reunieron una colección masiva de 12,106 cuadernos de competencias populares de Kaggle. Cuando intentaron ejecutar estos cuadernos en un entorno moderno, encontraron una realidad cruda: solo el 26% de ellos funcionaba realmente y producía los mismos resultados que hace años. El otro 74% estaba roto, ya fuera fallando con errores o produciendo puntuaciones completamente diferentes.

Podrías pensar que la solución es simple: simplemente retroceder en el tiempo e instalar exactamente las mismas versiones de software para las que se escribió la receta. Esto se llama "backporting de entorno". Los autores intentaron esto degradando todo el software para que coincidiera con la fecha en que el cuaderno fue enviado originalmente. Sorprendentemente, ¡esto empeoró las cosas! En lugar de que el 26% funcionara, solo el 12% se volvió reproducible. Resulta que intentar reconstruir el pasado es una trampa; las versiones antiguas de software suelen faltar, son incompatibles con el hardware moderno o son simplemente demasiado frágiles para ejecutarse. Los autores argumentan que, en lugar de intentar reconstruir la vieja cocina, deberíamos arreglar la receta misma para que funcione en la nueva cocina.

Para resolver esto, el equipo construyó una herramienta llamada MLEModernizer. Piensa en esto como un sous-chef robótico súper inteligente impulsado por un Modelo de Lenguaje Grande (LLM). Este robot no solo lee la receta; de hecho, intenta hornear el pastel. Si el pastel se quema (ocurre un error), el robot observa el humo, descubre qué salió mal y reescribe la receta para solucionarlo. Si el pastel tarda demasiado en hornearse (problemas de tiempo de ejecución), el robot ajusta las instrucciones para acelerarlo. Si el pastel tiene un sabor ligeramente diferente (la puntuación es incorrecta), el robot ajusta los ingredientes para recuperar el sabor del estándar original.

El robot trabaja en un bucle: ejecuta el código, verifica los resultados y, si algo está mal, le pide a la IA que escriba un parche (una corrección) para todo el cuaderno. Continúa haciendo esto hasta 16 veces hasta que el cuaderno funciona. Los resultados fueron bastante prometedores. Cuando probaron esto en 8,210 cuadernos rotos, la herramienta logró arreglar aproximadamente el 40% a 45% de ellos, haciéndolos reproducibles nuevamente. Específicamente, usando un modelo de IA potente (GPT-5.2), arreglaron 3,292 cuadernos, y con un modelo de código abierto ligeramente diferente (GPT-OSS-120b), arreglaron 3,683.

Sin embargo, el artículo tiene cuidado de no llamar a esto una varita mágica. Los autores descubrieron que, aunque la herramienta podía lograr que los números fueran correctos (la "puntuación"), a veces el código subyacente cambiaba de formas que no eran exactamente iguales al original. Por ejemplo, la IA podría cambiar la forma en que se entrena un modelo lo suficiente como para obtener la puntuación correcta, pero el "sabor" del código es diferente. También descubrieron que algunos errores son simplemente demasiado obstinados para arreglarlos automáticamente; la herramienta era excelente para arreglar errores simples de "falta de ingredientes" (como olvidar importar una librería), pero tenía dificultades con errores complejos de "interacción de ingredientes extraños" (como errores de atributo donde un objeto no tiene las propiedades adecuadas).

El costo de este chef robótico también es un factor. Los autores calcularon que arreglar un cuaderno cuesta en promedio $0.65 usando el modelo potente, lo que sugieren que es lo suficientemente barato para un uso a gran escala. Pero también señalaron que el modelo de código abierto era mucho más barato (alrededor de $0.0074 por cuaderno) pero no mantenía el código tan fiel al original.

Al final, el artículo sugiere que, aunque no podemos recrear perfectamente el pasado, podemos usar agentes de IA inteligentes para modernizar el código antiguo y salvar valioso trabajo científico. No es una solución perfecta para cada uno de los cuadernos rotos, pero ofrece una forma de "mejor esfuerzo" para rescatar una parte significativa de la historia del aprendizaje automático que de otro modo se perdería en el tiempo. Los autores concluyen que este enfoque ayuda a los profesionales a validar y reutilizar viejos procesos a medida que la tecnología continúa evolucionando, convirtiendo recetas viejas y polvorientas en algo que puede cocinarse en la cocina de hoy.

Resumen Técnico: Modernización Automatizada de Notebooks de Ingeniería de Aprendizaje Automático para la Reproducibilidad

1. Planteamiento del Problema

Los notebooks computacionales interactivos (por ejemplo, Jupyter) son los artefactos primordiales para documentar y compartir flujos de trabajo (pipelines) de Ingeniería de Aprendizaje Automático (MLE) de extremo a extremo. Sin embargo, estos notebooks sufren de erosión ambiental: la rápida evolución de los ecosistemas de hardware y software hace que muchos notebooks publicados no sean reproducibles en entornos contemporáneos.

Los autores identifican una brecha crítica en el estado actual de la reproducibilidad:

La Brecha: Un estudio a gran escala de 12,106 notebooks de 75 competiciones de Kaggle reveló que solo el 26% permanece reproducible en un entorno moderno.
El Fraclo del "Backporting": La práctica estándar de la industria del "backporting de entorno" (reducir las dependencias para que coincidan con la marca de tiempo de la entrega del notebook) fue probada y resultó ser contraproducente. En lugar de mejorar la reproducibilidad, el backporting redujo la tasa de éxito al 12% e introdujo modos de fallo adicionales (por ejemplo, conflictos de dependencias, ruedas/wheels históricas no disponibles).
El Desafío Central: Simplemente ejecutar el código en un entorno histórico reconstruido suele ser inviable o insuficiente. El código mismo debe modernizarse para ejecutarse y reproducir puntuaciones en el entorno actual. Crucialmente, la "reproducibilidad" en MLE no se trata solo de la ejecución (que no haya errores); requiere una calibración de la puntuación, donde el rendimiento del modelo reproducido se mantenga dentro de una banda aceptable de la puntuación originalmente reportada.

2. Metodología: MLEModernizer

Para abordar la erosión ambiental, los autores diseñaron e implementaron MLEModernizer, un marco de agentes impulsado por LLM. A diferencia de las herramientas de reparación tradicionales que tratan el entorno como una variable a ser reconstruida, MLEModernizer trata el entorno contemporáneo como una restricción fija y moderniza iterativamente el código del notebook.

Flujo de Trabajo Agéntico

El marco opera en un bucle iterativo con un máximo de 16 iteraciones por notebook:

Ejecución y Retroalimentación: El notebook se ejecuta en un entorno contenedorizado (alineado con el modelo de ejecución de Kaggle). El sistema recopila la retroalimentación de la ejecución, incluyendo:
- Duración de la ejecución.
- Rastros de error (tracebacks) (si existen).
- Puntuación reproducida ( $s_r$ ) comparada con la puntuación objetivo ( $s_t$ ).
Detección de Problemas: El sistema clasifica el fallo en una de tres categorías:
- Timeout: La ejecución excede el límite de 600 segundos.
- Error: El notebook genera excepciones.
- Desviación de Puntuación: El notebook se ejecuta sin errores, pero la puntuación se desvía significativamente de la objetivo.
Reparación Dirigida por LLM: Basándose en el problema detectado, MLEModernizer construye un prompt específico para un Modelo de Lenguaje Grande (LLM) para generar un parche. El marco soporta tres tipos distintos de corrección:
- Reparación de Errores (Error-Repair): Corrige errores de ejecución (por ejemplo, cambios disruptivos en la API, importaciones faltantes).
- Reducción de Tiempo de Ejecución (Runtime-Reduction): Optimiza el código para prevenir tiempos de espera excesivos (por ejemplo, habilitando aceleración por GPU, reduciendo subconjuntos de datos).
- Calibración de Puntuación (Score-Calibration): Ajusta el código para alinear la puntuación reproducida con la objetivo (por ejemplo, manejo de desplazamientos de etiquetas, ajuste de hiperparámetros) cuando no existen errores.
Aplicación de Parches: El LLM devuelve un plan y un parche de archivo completo (el notebook entero). MLEModernizer aplica este parche y repite el bucle hasta que el notebook es reproducible o se alcanza el límite de iteraciones.

Configuración de Evaluación

Conjunto de Datos: Se seleccionaron 8,210 notebooks no reproducibles (filtrados del 12,106 inicial) para la modernización.
Modelos: El sistema fue evaluado utilizando GPT-5.2 (propietario) y GPT-OSS-120b (de pesos abiertos).
Métricas: La reproducibilidad se definió mediante una prueba $t$ de una muestra ( $p \ge 0.05$ ) o un umbral heurístico ( $\tau = 10\%$ ) si las puntuaciones eran deterministas. La equivalencia funcional se evaluó mediante inspección manual de un subconjunto muestreado estadísticamente.

3. Resultados Clave

Recuperación de la Reproducibilidad

Tasas de Éxito: MLEModernizer restauró con éxito la reproducibilidad al 40.1% de los notebooks no reproducibles usando GPT-5.2 (3,292 notebooks) y al 44.9% usando GPT-OSS-120b (3,683 notebooks).
Libre de Errores vs. Con Errores:
- Con GPT-5.2, 2,397 notebooks se volvieron "Reproducibles Libres de Errores", mientras que 895 fueron "Reproducibles con Errores" (reproducibles a pesar de errores residuales).
- Con GPT-OSS-120b, 2,877 se volvieron "Reproducibles Libres de Errores", y 806 fueron "Reproducibles con Errores".
Equivalencia Funcional: Aunque GPT-OSS-120b logró una tasa de reproducibilidad bruta más alta, GPT-5.2 produjo significativamente más modernizaciones funcionalmente equivalentes (71.5% vs. 52.7%). Esto sugiere un compromiso donde el modelo abierto logra las puntuaciones de forma más agresiva, potencialmente alterando la semántica, mientras que el modelo propietario preserva mejor la lógica original.

Estadísticas de Corrección y Costos

Eficiencia de Iteración: La mayoría de las modernizaciones exitosas requirieron pocas correcciones (mediana de 2). Sin embargo, lograr el estado "Libre de Errores" típicamente requirió más iteraciones (media de 4.35) que lograr el estado "Reproducible con Errores" (media de 2.56).
Tipos de Corrección: La Calibración de Puntuación fue el tipo de corrección más frecuente aplicado (39,226 veces), seguida de la Reparación de Errores (27,765) y la Reducción de Tiempo de Ejecución (15,718). La Calibración de Puntuación fue el principal motor de los resultados "Libres de Errores".
Costo: El proceso es económicamente viable para uso a gran escala.
- GPT-5.2: Costo promedio de $0.65 USD por notebook.
- GPT-OSS-120b: Costo promedio de $0.0074 USD por notebook.
Modificación de Código: Aunque las correcciones individuales suelen ser incrementales (alta similitud de edición con la versión anterior), las modificaciones acumulativas pueden ser sustanciales. Los notebooks que inicialmente sufrían de tiempo de espera excedido (timeout) experimentaron la divergencia de código más significativa respecto a la línea base.

Análisis de Errores

Reducción de Errores: El sistema redujo el conteo total de errores de >92,000 en la línea base a ~4,000 después de 16 correcciones.
Tipos de Errores: El NameError (nombres no definidos/importaciones faltantes) se redujo efectivamente. Sin embargo, el AttributeError (atributos faltantes o inválidos) resultó ser el más persistente, siendo el tipo de error dominante tanto en los notebooks reproducibles como en los no reproducibles tras la modernización. Esto indica que la deriva de la API y los cambios de atributos específicos de las librerías son más difíciles de automatizar que las simples correcciones de sintaxis o importaciones.

4. Significado y Reivindicaciones

El artículo posiciona a MLEModernizer como una técnica de recuperación y modernización automatizada de "mejor esfuerzo" (best-effort). Los autores realizan las siguientes afirmaciones sobre su importancia:

Cambio de Paradigma: El trabajo desafía el paradigma prevaleciente de la "reconstrucción de entorno" (backporting). Demuestra que tratar el entorno como una restricción fija y modernizar el código es una estrategia más efectiva para restaurar la reproducibilidad en ecosistemas de ML que evolucionan rápidamente.
Utilidad Práctica: Al permitir la modernización automatizada de los notebooks de MLE, la herramienta facilita la validación y el reuso de pipelines de ML heredados (legacy). Esto es crítico tanto para investigadores (transferencia de conocimiento de prototipos antiguos) como para ingenieros (mantenimiento de la usabilidad a largo plazo de pipelines de producción).
Limitaciones y Alcance: Los autores son modestos sobre las capacidades de la herramienta. Reconocen que:
- La reproducción exacta puede ser imposible debido a los entornos evolucionados; la herramienta proporciona un punto de partida para el refinamiento manual.
- La reproducibilidad basada en puntuación no garantiza la equivalencia funcional (aunque la herramienta intenta preservarla).
- Ciertos tipos de errores (específicamente los AttributeError complejos) siguen siendo difíciles de resolver automáticamente.
- La evaluación depende de una calificación offline (MLE-Bench) que aproxima, pero no replica perfectamente, el leaderboard privado de Kaggle.

En conclusión, el artículo afirma que, si bien la modernización de código no es una solución definitiva, ofrece un camino viable y escalable para restaurar la reproducibilidad para un subconjunto significativo de artefactos de MLE heredados, cerrando la brecha entre el código histórico y la infraestructura contemporánea.