Runtime-Augmented LLMs for Crash Detection and Diagnosis in ML Notebooks

1. El Problema

El desarrollo de Machine Learning (ML) se realiza frecuentemente en entornos interactivos como Jupyter Notebooks. Estos entornos permiten una experimentación iterativa mediante la ejecución de celdas de código que mantienen un estado persistente en el kernel (memoria). Sin embargo, esta flexibilidad introduce desafíos críticos:

• Fragilidad del Estado: Las celdas pueden ejecutarse en cualquier orden, creando dependencias ocultas y objetos con estado.
• Corrupción Irreversible: Cuando una celda provoca un fallo (crash) en un notebook, el kernel queda en un estado inconsistente o parcialmente actualizado. A diferencia de los scripts tradicionales, no existe un mecanismo nativo para guardar/restaurar el estado del kernel de forma fiable.
• Costo de Recuperación: Tras un fallo, los desarrolladores deben reiniciar el kernel y reejecutar todas las celdas previas (incluyendo pasos costosos como el preprocesamiento de datos o el entrenamiento de modelos), lo que consume tiempo valioso.
• Limitaciones de las Técnicas Actuales: Los detectores de errores estáticos no pueden predecir fallos dependientes de datos de tiempo de ejecución (como formas de tensores o valores específicos), y los enfoques dinámicos tradicionales solo detectan errores después de que ocurren, ya no previenen la corrupción del estado.

El objetivo es detectar y diagnosticar fallos antes de ejecutar la celda objetivo, evitando así la corrupción del kernel.

2. Metodología: CRANE-LLM

Los autores proponen CRANE-LLM, un marco de trabajo que aumenta a los Modelos de Lenguaje Grande (LLMs) con información estructurada extraída del estado de tiempo de ejecución del kernel del notebook.

A. Extracción de Información de Tiempo de Ejecución (Runtime Information)

En lugar de enviar todo el estado del kernel (lo cual sería demasiado grande y ruidoso), el sistema filtra y resume la información relevante para la celda objetivo:

1. Análisis AST: Se analiza el Árbol de Sintaxis Abstracta (AST) de la celda objetivo para identificar variables y llamadas a funciones referenciadas.
2. Resumen Estructurado: Se extraen atributos específicos de objetos comunes en ML (TensorFlow/Keras, PyTorch, Scikit-learn, Pandas, NumPy):
   • Estructura (S): Formas de tensores, dimensiones de conjuntos de datos, conteo de muestras.
   • Semántica de Representación y Tipos (R): Tipos de objetos, dtypes (float32, int64), esquemas de datos.
   • Semántica de Valores (V): Rangos de valores, presencia de NaNs, número de clases, estado del objeto (ej. si un modelo ya fue entrenado).
3. Extracción No Intrusiva: Se evita la iteración sobre datos grandes para no consumir recursos; se extraen metadatos (ej. shape, dtype, n_classes).

B. Prompting y Detección con LLM

Se construye un prompt que combina:

1. La secuencia ordenada de celdas ejecutadas exitosamente (contexto estático).
2. La celda objetivo a analizar.
3. La información de tiempo de ejecución extraída y resumida.

El LLM (Gemini, Qwen o GPT-5) recibe instrucciones para razonar paso a paso (Chain-of-Thought) y predecir si la celda fallará, proporcionando una explicación diagnóstica en formato JSON estructurado.

C. Configuraciones

El sistema permite configuraciones para estudiar el impacto de diferentes fuentes de información:

• Sin Runtime (-RT): Solo código estático.
• Con Runtime (+RT): Código + información extraída.
• Ablación: Eliminación de categorías específicas (S, R, V) para medir su contribución.
• Grounding con API: Inclusión opcional de documentación de API (que resultó ser contraproducente en los experimentos).

3. Contribuciones Clave

1. Enfoque Preventivo: Es el primer trabajo que aborda la detección temprana de fallos en notebooks de ML antes de la ejecución, utilizando el estado del kernel para prevenir la corrupción irreversible.
2. Marco CRANE-LLM: Una arquitectura que integra dinámicamente información de tiempo de ejecución estructurada en prompts de LLMs para tareas de depuración.
3. Benchmarks y Evaluación Rigurosa: Evaluación en JunoBench, un conjunto de datos de 111 notebooks con fallos reproducibles (222 notebooks en total, incluyendo versiones corregidas), cubriendo múltiples bibliotecas (PyTorch, TensorFlow, Scikit-learn, etc.).
4. Análisis de Causas: Estudio detallado de cómo diferentes tipos de información (estructural, de tipo, de valor) afectan a distintos LLMs y tipos de fallos.

4. Resultados Principales

La evaluación se realizó sobre tres LLMs de vanguardia: Gemini-2.5-Flash, GPT-5 y Qwen-2.5-Coder-32B.

• Mejora General: La incorporación de información de tiempo de ejecución (+RT) mejoró consistentemente el rendimiento en todos los modelos.
  • Precisión: Aumento de 7 a 10 puntos porcentuales (pp).
  • Puntuación F1: Aumento de 8 a 11 pp.
  • Precisión vs. Recall: Los modelos mejoraron tanto en la detección de fallos reales (recall) como en la reducción de falsos positivos (precisión), aunque el equilibrio varía según el modelo (Qwen mejoró más en precisión, Gemini/GPT-5 en recall).
• Diagnóstico vs. Detección: La mejora fue más significativa cuando se requería diagnóstico (explicar la causa) que solo detección. Esto indica que el contexto de tiempo de ejecución es crucial para el razonamiento causal.
• Impacto por Biblioteca y Causa:
  • Las mejoras fueron más notables en PyTorch, Scikit-learn y Pandas.
  • Los fallos por confusión de datos, mal uso de API y errores de implementación se beneficiaron más del contexto de tiempo de ejecución.
  • Los fallos específicos de notebooks (ej. celdas no ejecutadas) mostraron menos mejora, ya que son detectables estáticamente.
• Estudio de Ablación (RQ3.1):
  • Qwen dependió fuertemente de la información estructural (formas de tensores) y de representación.
  • GPT-5 fue más sensible a la semántica de valores (datos concretos).
  • Gemini mostró cambios menores, sugiriendo una capacidad de razonamiento más robusta o diferente.
  • Conclusión: Ninguna categoría única es suficiente; se requiere una combinación balanceada.
• Grounding con API (RQ3.2): Contrariamente a la intuición, añadir documentación de API no mejoró el rendimiento y aumentó significativamente el costo de tokens (hasta un 198% en algunos casos), sugiriendo que la información de tiempo de ejecución ya es suficiente y que la documentación añade ruido o redundancia.

5. Significado e Impacto

• Eficiencia en el Desarrollo: CRANE-LLM permite identificar errores en segundos (latencia promedio de ~1.6s con GPT-5), evitando horas de reejecución de celdas y reinicios de kernel. El ahorro de tiempo estimado en el benchmark fue de ~18 minutos por notebook, superando con creces el costo de la inferencia del LLM.
• Nueva Paradigma de Depuración: Cambia el enfoque de "ejecutar y ver qué falla" a "analizar el estado y predecir el fallo", lo cual es vital para flujos de trabajo de ML donde el estado es mutable y costoso de reconstruir.
• Validación de LLMs en ML: Demuestra que los LLMs, cuando se les proporciona el contexto de ejecución correcto, pueden razonar efectivamente sobre problemas complejos de ML que las herramientas estáticas tradicionales no pueden resolver.
• Reproducibilidad: El código y los datos están disponibles en GitHub, facilitando la extensión futura de la investigación.

En resumen, el paper establece que enriquecer a los LLMs con información estructurada del estado de ejecución es una estrategia práctica y efectiva para prevenir fallos catastróficos en el desarrollo de ML, superando las limitaciones del análisis estático y mejorando significativamente la productividad del desarrollador.