🤖 machine learning

Deep4ge: DNN Training Trajectories for Fault Detection and Diagnosis

This paper introduces Deep4ge, a comprehensive benchmark dataset comprising over 14,000 per-epoch training runs from 59 deep neural network programs with injected faults, designed to support research in detecting and diagnosing subtle implementation errors in deep learning systems.

Original authors: Sigma Jahan

Published 2026-07-15

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Sigma Jahan

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you're watching a student try to learn a new skill, like juggling. Sometimes, they fail not because they are lazy, but because they are holding the balls the wrong way, or the room is too dark, or they are trying to learn the wrong trick entirely. In the world of artificial intelligence, these "students" are Deep Neural Networks (DNNs), and when they fail, they often don't crash and burn with a loud error message. Instead, they just get really bad at juggling, or they start spinning in circles, or they give up halfway through.

This is the problem the paper Deep4ge tackles. The researchers realized that while we have lots of tools to check if a student's final score is good, we don't have a big, public library of "training diaries" that show exactly how they failed during the learning process. To fix this, they built Deep4ge, a massive, controlled experiment that acts like a giant simulation lab for AI training failures.

The Great AI Training Simulation

The team started by grabbing 59 real-world code snippets from Stack Overflow (a website where programmers ask and answer questions). They cleaned these up to make sure they ran perfectly, like tuning a race car before a test drive. Then, they played a game of "Mad Libs" with the code.

They used 27 different "mutation operators"—think of these as mischievous gremlins that sneak into the code and change one tiny thing. Maybe they swap the learning speed, change the type of math used, or mess up how the AI starts its brain. They applied these gremlins to create 9,845 "faulty" training runs. To make sure the comparison was fair, they also ran 4,382 "correct" versions without any gremlins.

In total, they watched 14,227 different training sessions. For every single session, they didn't just look at the final grade; they recorded a diary entry for every single "epoch" (a round of learning). They logged 26 different clues, like how heavy the AI's "thoughts" (weights) were, how fast the signals were moving (gradients), and even how much computer memory the AI was using. This resulted in 719,560 individual data points, creating a detailed map of what goes wrong and when.

The Big Discovery: Don't Just Look at the Finish Line

The most exciting part of the paper is what they found when they tried to use this data to predict failures. Imagine you are a coach trying to spot a student who is struggling.

The researchers tested two ways to spot the problem:

The "Final Exam" Method: Looking only at the very last day of training to see if the student failed.
The "Training Diary" Method: Looking at the whole history of how the student learned, step-by-step.

The results were clear: The "Final Exam" method wasn't very good. If you only looked at the last day, a computer program could barely tell the difference between a student who was trying hard but failing, and one who was just confused. The "Final Exam" approach gave a score (called MCC) of about 0.150 for the best computer model.

However, when they used the "Training Diary" method—looking at the trends, the ups and downs, and the whole journey—the computer got much better at spotting the trouble. The score jumped to 0.227. It's like realizing that a student who starts strong but slowly gets worse is different from one who starts slow but gets better. The paper suggests that to really understand why an AI is failing, you have to watch the whole movie, not just the ending.

What They Can (and Can't) Do

The team also tried to guess what kind of mistake the AI made (like, "Did they mess up the learning speed?" or "Did they pick the wrong math?"). They found that some mistakes are easy to spot, like "Weight" errors, which the computer got right 70% of the time. But other mistakes, like "Activation" errors (where the AI stops thinking entirely), were very hard to diagnose, with the computer getting 0% of them right in some tests.

They also tested if their findings would work on different types of AI "students" (like those that process images vs. those that process language). They found that the skills transferred pretty well, but there was a tiny bit of drop-off, especially for the language-processing models, suggesting that different types of AI learn in slightly different ways.

The Limits of the Lab

It's important to remember that this was a controlled simulation. The researchers created the faults themselves using their "gremlin" tools. They are suggesting that this helps us understand real-world problems, but they admit they haven't proven that these exact "gremlin" faults happen exactly the same way in real, messy industrial software. Also, they only looked at three specific types of AI architectures (FNN, CNN, and RNN) and did not include the newer, trendier "Transformer" models.

The Takeaway

Deep4ge is a gift to the scientific community. It's a public library of 14,227 training stories, complete with the "diary" of every single step. The main lesson is that if you want to catch a failing AI early, you can't just wait for the final report card. You have to watch the training process unfold, because the clues to the failure are hidden in the journey, not just the destination. The authors have released all their data and tools so anyone can try to build better detectors, proving that sometimes, the best way to fix a broken robot is to watch it stumble over and over again.

Technical Summary: Deep4ge – DNN Training Trajectories for Fault Detection and Diagnosis

Problem Statement

Deep learning systems frequently suffer from subtle implementation faults that alter training behavior without producing explicit runtime errors. Unlike traditional software faults, Deep Neural Network (DNN) failures often manifest as "silent symptoms" such as unstable optimization, vanishing/exploding gradients, or poor generalization. Debugging these issues requires observing the evolution of training over time rather than inspecting only source code or final outputs.

Despite recent proposals for DNN debugging tools (e.g., AutoTrainer, DeepLocalize, DeepFD), the software engineering community lacks a public, reusable dataset containing per-epoch training runs with documented fault histories. Existing mutation frameworks (e.g., DeepCrime) focus primarily on operator evaluation rather than providing comprehensive training trajectories. Furthermore, many existing studies rely on limited, study-specific injected faults where the corresponding training data is not released for systematic re-evaluation.

Methodology

The authors present Deep4ge, a controlled benchmark designed to fill this gap by generating a large-scale dataset of DNN training trajectories with known fault categories.

1. Dataset Construction

Source Programs: The authors collected 59 TensorFlow/Keras DNN programs from Stack Overflow. These were selected based on completeness (containing model definition, data loading, and training), repairability (to ensure deterministic execution), and architectural scope (Feedforward, Convolutional, and Recurrent Neural Networks).
Determinism: To minimize non-deterministic variability, random seeds were fixed at the framework and operator levels, and dataset splits and initialization settings were standardized.
Fault Injection: Starting from corrected baseline programs, the authors applied 27 source-level mutation operators to generate faulty variants. These operators were grouped into seven fault categories:
1. Hyperparameter
2. Loss
3. Weight (initialization/bias)
4. Layer (structural choices)
5. Optimization
6. Activation
7. Regularization
  Note: The operator set combines a subset of DeepCrime operators with new layer-level operators introduced in this work. Operators modifying training data or process control were excluded.
Mutation Validation: The authors employed the "killing criterion" from DeepCrime, which relies on statistical significance (Cohen's $d \ge 0.5$ , $p < 0.05$ ) between the accuracy distributions of the original and mutant networks over 15 retrainings. Mutants not statistically distinguishable from the original were discarded. The resulting mutation scores were 0.85 (FNN), 0.87 (CNN), and 0.83 (RNN).

2. Feature Extraction

For every training run (both correct and faulty), the system logs data at every epoch. Each run records:

4 Evaluation Metrics: Training/validation loss and accuracy.
26 Dynamic Features:
- Weights: Large-weight count, unchanged-mean/std flags, NaN count.
- Trends: Gap, oscillation, decrease, and increase in accuracy/loss.
- Activations: Dying ReLU, saturation, mean, and standard deviation.
- Gradients: Vanishing/exploding flags, NaN count, mean, std, min, max, median layer norms, and per-weight statistics.
- Hardware: Learning rate, CPU usage, peak GPU memory, and system memory usage.

3. Benchmark Tasks

The dataset supports three primary tasks:

Binary Fault Detection: Classifying a run as faulty or correct.
Multiclass Fault Diagnosis: Assigning one of the seven fault categories to a faulty run.
Early Fault Prediction: Predicting faults from partial training runs (single epoch or trajectory subsets).

Key Contributions

Deep4ge Dataset: A labeled dataset comprising 14,227 training runs (9,845 faulty, 4,382 correct baselines) spanning 719,560 epoch records. The data covers 59 unique Stack Overflow programs across three architecture families and seven fault categories.
Open-Source Framework: A fault-injection framework that applies AST-based transformations, logs per-epoch features, and includes validation scripts. The framework allows practitioners to regenerate the dataset or extend it with new transformations.
Proof-of-Concept Baselines: The authors provide baseline performance metrics for fault detection and diagnosis using Logistic Regression and Random Forest models, comparing "final-epoch" features against full "trajectory" features.

Results and Findings

The authors evaluated detection and diagnosis performance using 5-fold group-aware cross-validation (grouping by source program to prevent data leakage).

Trajectory vs. Final-Epoch: Using full training trajectories significantly outperforms using only final-epoch features.
- For Fault Detection, Random Forest (RF) using trajectory features achieved a Matthews Correlation Coefficient (MCC) of 0.227, compared to 0.150 for final-epoch features.
- For Fault Diagnosis, RF Macro-F1 improved from 0.355 (final-epoch) to 0.381 (trajectory), with MCC rising from 0.346 to 0.401.
Fault Category Performance: Diagnosis performance varies by category. Weight-related faults were the easiest to diagnose (F1 = 0.700), followed by Hyperparameter and Loss. Optimization and Activation faults were the most difficult (F1 = 0.075 and 0.000, respectively). Confusion matrices indicate that Activation faults are often misclassified as Optimization, and Optimization faults as Layer.
Cross-Architecture Transfer: Models trained on two architecture families and tested on the third showed a small but non-zero performance drop (MCC dropped from 0.227 to ~0.20), suggesting that while some features transfer, others remain architecture-specific.
Early Detection: Single-epoch detection (using features from epoch $k$ ) yielded lower performance (MCC 0.14–0.19) compared to full-trajectory models, indicating that observing the evolution of training is necessary for robust detection.

Significance and Claims

The paper claims that Deep4ge is the first public dataset that links adapted DNN programs with mutation-derived fault categories and corresponding per-epoch training trajectories. Its significance lies in:

Standardization: Providing a controlled benchmark that supports systematic re-evaluation and comparison of fault detection and diagnosis techniques.
Methodological Shift: Enabling research that focuses on training dynamics (trajectories) rather than static code analysis or final outputs.
Reproducibility: Offering a versioned, open-source artifact (CC BY 4.0 for data, MIT for code) that allows the community to replicate results, extend the fault taxonomy, and test new architectures.

The authors maintain a modest scope, acknowledging that the dataset is limited to TensorFlow/Keras FNN, CNN, and RNN architectures (excluding Transformers) and that Stack Overflow programs may not fully reflect industrial practices. They do not claim that mutation-derived faults perfectly represent naturally occurring industrial faults, but rather that the dataset serves as a foundational resource for studying training-time fault behaviors.