🤖 machine learning

Deep4ge: DNN Training Trajectories for Fault Detection and Diagnosis

Este artículo presenta Deep4ge, un conjunto de datos de referencia exhaustivo que comprende más de 14.000 ejecuciones de entrenamiento por época de 59 programas de redes neuronales profundas con fallos inyectados, diseñado para apoyar la investigación en la detección y el diagnóstico de errores de implementación sutiles en sistemas de aprendizaje profundo.

Autores originales: Sigma Jahan

Publicado 2026-07-15

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Sigma Jahan

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 estás observando a un estudiante intentar aprender una nueva habilidad, como hacer malabares. A veces, fallan no porque sean perezosos, sino porque están sujetando las pelotas de la forma incorrecta, o porque la habitación está demasiado oscura, o porque están intentando aprender el truco equivocado por completo. En el mundo de la inteligencia artificial, estos "estudiantes" son las Redes Neuronales Profundas (DNN, por sus siglas en inglés), y cuando fallan, a menudo no colapsan con un mensaje de error estruendoso. En su lugar, simplemente se vuelven muy malos haciendo malabares, o empiezan a dar vueltas en círculos, o se rinden a mitad del camino.

Este es el problema que aborda el artículo Deep4ge. Los investigadores se dieron cuenta de que, si bien tenemos muchas herramientas para comprobar si la calificación final de un estudiante es buena, no tenemos una gran biblioteca pública de "diarios de entrenamiento" que muestren exactamente cómo fallaron durante el proceso de aprendizaje. Para solucionar esto, construyeron Deep4ge, un experimento masivo y controlado que actúa como un gigantesco laboratorio de simulación para los fallos de entrenamiento de la IA.

El Gran Simulador de Entrenamiento de IA

El equipo comenzó tomando 59 fragmentos de código reales de Stack Overflow (un sitio web donde los programadores hacen y responden preguntas). Los limpiaron para asegurarse de que funcionaran perfectamente, como quien pone a punto un coche de carreras antes de una prueba de conducción. Luego, jugaron al "Mad Libs" con el código.

Utilizaron 27 diferentes "operadores de mutación"—piensa en ellos como duendes traviesos que se cuelan en el código y cambian una cosita mínima. Tal vez cambian la velocidad de aprendizaje, cambian el tipo de matemáticas utilizadas o arruinan la forma en que la IA inicia su cerebro. Aplicaron estos duendes para crear 9.845 ejecuciones de entrenamiento "defectuosas". Para asegurar que la comparación fuera justa, también ejecutaron 4.382 versiones "correctas" sin ningún duende.

En total, observaron 14.227 diferentes sesiones de entrenamiento. Para cada una de las sesiones, no solo miraron la nota final; registraron una entrada de diario para cada "época" (una ronda de aprendizaje). Registraron 26 pistas diferentes, como qué tan pesados eran los "pensamientos" (pesos) de la IA, qué tan rápido se movían las señales (gradientes) e incluso cuánta memoria de computadora estaba utilizando la IA. Esto resultó en 719.560 puntos de datos individuales, creando un mapa detallado de qué sale mal y cuándo.

El Gran Descubrimiento: No te limites a mirar la línea de meta

La parte más emocionante del artículo es lo que descubrieron cuando intentaron usar estos datos para predecir fallos. Imagina que eres un entrenador tratando de detectar a un estudiante que tiene dificultades.

Los investigadores probaron dos formas de detectar el problema:

El Método del "Examen Final": Mirar solo el último día de entrenamiento para ver si el estudiante falló.
El Método del "Diario de Entrenamiento": Mirar todo el historial de cómo aprendió el estudiante, paso a paso.

Los resultados fueron claros: El método del "Examen Final" no fue muy bueno. Si solo mirabas el último día, un programa informático apenas podía distinguir entre un estudiante que se estaba esforzando pero fallaba, y uno que simplemente estaba confundido. El enfoque del "Examen Final" dio una puntuación (llamada MCC) de aproximadamente 0.150 para el mejor modelo informático.

Sin embargo, cuando utilizaron el método del "Diario de Entrenamiento" —mirando las tendencias, los altibajos y todo el viaje— la computadora mejoró mucho en la detección de problemas. La puntuación saltó a 0.227. Es como darse cuenta de que un estudiante que empieza fuerte pero empeora lentamente es diferente de uno que empieza lento pero mejora. El artículo sugiere que para entender realmente por qué una IA está fallando, tienes que ver toda la película, no solo el final.

Lo que Pueden (y No Pueden) Hacer

El equipo también intentó adivinar qué tipo de error cometió la IA (como: "¿Arruinaron la velocidad de aprendizaje?" o "¿Eligieron las matemáticas equivocadas?"). Descubrieron que algunos errores son fáciles de detectar, como los errores de "Peso", que la computadora acertó el 70% de las veces. Pero otros errores, como los de "Activación" (donde la IA deja de pensar por completo), fueron muy difíciles de diagnosticar, con la computadora acertando el 0% de ellos en algunas pruebas.

También probaron si sus hallazgos funcionarían en diferentes tipos de "estudiantes" de IA (como los que procesan imágenes frente a los que procesan lenguaje). Descubrieron que las habilidades se transferían bastante bien, pero hubo una pequeña caída, especialmente en los modelos de procesamiento de lenguaje, lo que sugiere que diferentes tipos de IA aprenden de maneras ligeramente distintas.

Los Límites del Laboratorio

Es importante recordar que esto fue una simulación controlada. Los investigadores crearon los fallos ellos mismos usando sus herramientas de "duendes". Ellos sugieren que esto nos ayuda a comprender los problemas del mundo real, pero admiten que no han demostrado que estos fallos exactos de los "duendes" ocurran exactamente de la misma manera en el software industrial real y desordenado. Además, solo analizaron tres tipos específicos de arquitecturas de IA (FNN, CNN y RNN) y no incluyeron los modelos "Transformer", que son más nuevos y tendencia.

La Conclusión

Deep4ge es un regalo para la comunidad científica. Es una biblioteca pública de 14.227 historias de entrenamiento, completas con el "diario" de cada paso. La lección principal es que si quieres atrapar una IA que falla a tiempo, no puedes limitarte a esperar el informe de calificaciones final. Tienes que observar el proceso de entrenamiento desarrollarse, porque las pistas del fallo están ocultas en el viaje, no solo en el destino. Los autores han publicado todos sus datos y herramientas para que cualquiera pueda intentar construir mejores detectores, demostrando que, a veces, la mejor manera de arreglar un robot roto es verlo tropezar una y otra vez.

Resumen Técnico: Deep4ge – Trayectorias de Entrenamiento de DNN para la Detección y el Diagnóstico de Fallos

Planteamiento del Problema

Los sistemas de aprendizaje profundo sufren frecuentemente fallos de implementación sutiles que alteran el comportamiento del entrenamiento sin producir errores de ejecución explícitos. A diferencia de los fallos de software tradicionales, los fallos de las Redes Neuronales Profundas (DNN) suelen manifestarse como "síntomas silenciosos", tales como una optimización inestable, gradientes que desaparecen o explotan, o una pobre generalización. La depuración de estos problemas requiere observar la evolución del entrenamiento a lo largo del tiempo en lugar de inspeccionar únicamente el código fuente o los resultados finales.

A pesar de las propuestas recientes de herramientas de depuración para DNN (por ejemplo, AutoTrainer, DeepLocalize, DeepFD), la comunidad de la ingeniería de software carece de un conjunto de datos público y reutilizable que contenga ejecuciones de entrenamiento por época con historiales de fallos documentados. Los marcos de mutación existentes (por ejemplo, DeepCrime) se centran principalmente en la evaluación de operadores en lugar de proporcionar trayectorias de entrenamiento integrales. Además, muchos estudios actuales dependen de fallos inyectados limitados y específicos de cada estudio, donde los datos de entrenamiento correspondientes no se liberan para una reevaluación sistemática.

Metodología

Los autores presentan Deep4ge, un benchmark controlado diseñado para llenar este vacío mediante la generación de un conjunto de datos a gran escala de trayectorias de entrenamiento de DNN con categorías de fallos conocidas.

1. Construcción del Conjunto de Datos

Programas de Origen: Los autores recopilaron 59 programas de DNN de TensorFlow/Keras de Stack Overflow. Estos fueron seleccionados basándose en su completitud (que contuvieran definición de modelo, carga de datos y entrenamiento), capacidad de reparación (para asegurar la ejecución determinista) y alcance arquitectónico (Redes Neuronales Feedforward, Convolucionales y Recurrentes).
Determinismo: Para minimizar la variabilidad no determinista, las semillas aleatorias se fijaron a nivel de framework y de operador, y las divisiones de los conjuntos de datos y los ajustes de inicialización se estandarizaron.
Inyección de Fallos: Partiendo de programas base corregidos, los autores aplicaron 27 operadores de mutación a nivel de fuente para generar variantes con fallos. Estos operadores se agruparon en siete categorías de fallos:
1. Hiperparámetro
2. Pérdida (Loss)
3. Peso (inicialización/sesgo)
4. Capa (elecciones estructurales)
5. Optimización
6. Activación
7. Regularización
  Nota: El conjunto de operadores combina un subconjunto de los operadores de DeepCrime con nuevos operadores de nivel de capa introducidos en este trabajo. Se excluyeron los operadores que modifican los datos de entrenamiento o el control del proceso.
Validación de la Mutación: Los autores emplearon el "criterio de eliminación" de DeepCrime, que se basa en la significancia estadística (Cohen's $d \ge 0.5$ , $p < 0.05$ ) entre las distribuciones de precisión de las redes originales y las mutantes tras 15 reentrenamientos. Los mutantes que no eran estadísticamente distinguibles del original fueron descartados. Las puntuaciones de mutación resultantes fueron 0.85 (FNN), 0.87 (CNN) y 0.83 (RNN).

2. Extracción de Características

Para cada ejecución de entrenamiento (tanto correcta como con fallos), el sistema registra datos en cada época. Cada ejecución registra:

4 Métricas de Evaluación: Pérdida y precisión de entrenamiento y de validación.
26 Características Dinámicas:
- Pesos: Conteo de pesos grandes, banderas de media/desviación estándar sin cambios, conteo de NaN.
- Tendencias: Brecha (gap), oscilación, disminución e incremento en la precisión/pérdida.
- Activaciones: ReLU muerta (Dying ReLU), saturación, media y desviación estándar.
- Gradientes: Banderas de desvanecimiento/explosión, conteo de NaN, media, desviación estándar, mínimo, máximo, normas de capa por medio y mediana, y estadísticas por peso.
- Hardware: Tasa de aprendizaje, uso de CPU, pico de memoria de GPU y uso de memoria del sistema.

3. Tareas del Benchmark

El conjunto de datos soporta tres tareas principales:

Detección de Fallos Binaria: Clasificar una ejecución como defectuosa o correcta.
Diagnóstico de Fallos Multiclase: Asignar una de las siete categorías de fallos a una ejecución defectuosa.
Predicción Temprana de Fallos: Predecir fallos a partir de ejecuciones de entrenamiento parciales (una sola época o subconjuntos de la trayectoria).

Principales Contribuciones

Conjunto de Datos Deep4ge: Un conjunto de datos etiquetado que comprende 14,227 ejecuciones de entrenamiento (9,845 defectuosas, 4,382 bases correctas) que abarcan 719,560 registros de épocas. Los datos cubren 59 programas únicos de Stack Overflow a través de tres familias de arquitecturas y siete categorías de fallos.
Marco de Código Abierto: Un marco de inyección de fallos que aplica transformaciones basadas en AST, registra características por época e incluye scripts de validación. El marco permite a los profesionales regenerar el conjunto de datos o extenderlo con nuevas transformaciones.
Baselines de Prueba de Concepto: Los autores proporcionan métricas de rendimiento de referencia para la detección y el diagnóstico de fallos utilizando modelos de Regresión Logística y Random Forest, comparando las características de la "época final" frente a las características de la "trayectoria" completa.

Resultados y Hallazgos

Los autores evaluaron el rendimiento de detección y diagnóstico utilizando una validación cruzada de 5 pliegues sensible al grupo (agrupando por programa de origen para evitar la fuga de datos).

Trayectoria vs. Época Final: El uso de trayectorias de entrenamiento completas supera significativamente al uso de solo las características de la época final.
- Para la Detección de Fallos, el Random Forest (RF) utilizando características de trayectoria alcanzó un Coeficiente de Correlación de Matthews (MCC) de 0.227, comparado con 0.150 para las características de la época final.
- Para el Diagnóstico de Fallos, el F1 Macro de RF mejoró de 0.355 (época final) a 0.381 (trayectoria), con el MCC subiendo de 0.346 a 0.401.
Rendimiento por Categoría de Fallo: El rendimiento del diagnóstico varía según la categoría. Los fallos relacionados con el peso fueron los más fáciles de diagnosticar (F1 = 0.700), seguidos de Hiperparámetro y Pérdida. Los fallos de Optimización y Activación fueron los más difíciles (F1 = 0.075 y 0.000, respectivamente). Las matrices de confusión indican que los fallos de Activación suelen clasificarse erróneamente como de Optimización, y los de Optimización como de Capa.
Transferencia entre Arquitecturas: Los modelos entrenados en dos familias de arquitecturas y probados en la tercera mostraron una caída pequeña pero no nula en el rendimiento (el MCC cayó de 0.227 a ~0.20), lo que sugiere que, si bien algunas características se transfieren, otras siguen siendo específicas de la arquitectura.
Detección Temprana: La detección de una sola época (usando características de la época $k$ ) produjo un rendimiento inferior (MCC 0.14–0.19) en comparación con los modelos de trayectoria completa, lo que indica que observar la evolución del entrenamiento es necesario para una detección robusta.

Significancia y Reivindicaciones

El artículo afirma que Deep4ge es el primer conjunto de datos público que vincula programas de DNN adaptados con categorías de fallos derivadas de mutaciones y sus correspondientes trayectorias de entrenamiento por época. Su significancia radica en:

Estandarización: Proporcionar un benchmark controlado que soporte la reevaluación y comparación sistemática de técnicas de detección y diagnóstico de fallos.
Cambio Metodológico: Permitir la investigación que se centra en la dinámica del entrenamiento (trayectorias) en lugar del análisis de código estático o los resultados finales.
Reproducibilidad: Ofrecer un artefacto de código abierto versionado (CC BY 4.0 para los datos, MIT para el código) que permite a la comunidad replicar resultados, extender la taxonomía de fallos y probar nuevas arquitecturas.

Los autores mantienen un alcance modesto, reconociendo que el conjunto de datos está limitado a arquitecturas FNN, CNN y RNN de TensorFlow/Keras (excluyendo Transformers) y que los programas de Stack Overflow pueden no reflejar plenamente las prácticas industriales. No afirman que los fallos derivados de la mutación representen perfectamente los fallos industriales que ocurren naturalmente, sino que el conjunto de datos sirve como un recurso fundamental para estudiar los comportos de los fallos durante el tiempo de entrenamiento.