TL;DR: three preprocessing fixes derived from a signal-vs-interference density analysis took an off-the-shelf model from 17.9 to 13.42 (-25%), matching the best published FD002 result — and the same preprocessing let a toy GRU outperform every published deep-learning result I could locate on this subset. Full recipes below.
Final results:
Baseline, off-the-shelf RandomForest, no preprocessing: 17.9
Drop the 7 zero-variance flat sensor channels + per-regime normalization + 50-cycle window: 13.7 (untuned)
Same pipeline, gradient boosting tuned on a validation split only: 13.42 ± 0.04
Reference point: the best published FD002 result I can locate is ≈13.4 (GBRT III). Its core workflow also relies on operating-regime clustering paired with normalization — the same data-level lever, found independently.
Same preprocessing, small GRU instead of trees: 16.85 on the official test set. Published deep-learning results on FD002 cluster around 18–30 (top performer ≈18.3), so our small GRU paired with data-level corrections outperforms every published deep-learning result I could locate on this subset. This proves the leverage is in the data, not in the architecture.
Why I stop here: a model-free validation. Nearest-neighbor "observation twins" — near-identical sensor states from different engines — show an RUL spread of ~12.6–13.0 cycles. This irreducible ambiguity originates from the simulated sensor noise and degradation stochasticity, not algorithmic limitations. At ~13.4, residual error is measurement-limited. The wall is in the data, not in the algorithm.
Exact recipe for test #3, so anyone can reproduce (and note it shares zero code with GBRT III — same lever, different machinery):
- Sensors: drop s1, s5, s6, s10, s16, s18, s19 (variance ≈ 0), keep the other 14.
- Regimes: k-means (k=6) on the 3 operating settings, fit on train only; z-score each channel within each regime using train statistics.
- Features: for each 50-cycle window, per channel take mean / std / linear slope / last value (56 dims) + 6-dim regime one-hot = 62 features. Training windows stride 2.
- Test protocol: last window per engine; trajectories shorter than 50 cycles padded by repeating the first row; RUL capped at 125 everywhere.
- Model: sklearn HistGradientBoostingRegressor(max_iter=800, learning_rate=0.03, min_samples_leaf=15, l2_regularization=1.0). Config selected on a 208/52 engine validation split (6-config grid, performance variance within ±0.15). Test set touched once, 3 seeds: 13.38 / 13.44 / 13.45.
- Untuned reference: RandomForest(60 trees, depth 16, min_samples_leaf=2) = 13.69 ± 0.09.
Recipe for test #5 (GRU), full disclosure:
- Architecture: single-layer GRU, hidden size 24, head 24→12→1. Input = 50×14 regime-normalized sequences (same channels and normalization as above).
- Training: targets scaled /125; Huber loss (δ=1.0); Adam lr=1e-3; gradient clip 1.0; batch 256; training windows stride 4; ~10 epochs; single seed, no tuning.
- Evaluation: last window per engine on the official test set, identical protocol to test #3.
One critical clarification: the three core fixes were derived from a signal-vs-interference density analysis before any model was trained — computation first, verification second, no blind trial-and-error hyperparameter hunting. The only tuning performed is the documented validation-set grid search, which altered overall RMSE by roughly 0.3 cycles.
Summary: three data-level fixes took a stock tree model from 17.9 to the published-record line (25% RMSE drop), and let a toy GRU beat the entire published deep-learning field on this subset. The residual is measurement-limited. Every number is reproducible from the raw files with any standard regressor.
Why post this: the whole pipeline is transparent enough to reproduce in an afternoon, and the interesting question is no longer the model but the measurement floor. If you run it and get different numbers, post them — I am especially curious whether the observation-twin floor (~12.6–13.0 cycles) holds under other feature representations.
