深度学习在剩余寿命预测（RUL）中的应用综述

2024年5月的时候，我在给一家做空压机的厂商做售后预测系统，销售总监提了个需求："能不能告诉客户，这台机器还能转多久？"

一句话问到我肺管子上了。剩余寿命预测（RUL, Remaining Useful Life）是预测性维护金字塔尖上的能力，比"有没有异常"难一个量级。今天我就把这两年在这个方向上摸爬滚打的东西捋一遍。

先说数据：RUL的标签是个大坑

学术界做RUL基本绕不开NASA的C-MAPPS涡扇发动机数据集（FD001到FD004）。每个单元从健康状态跑到失效，从失效点往回数，就是RUL标签。听起来很美好，对吧？

但真实产线上根本不是这么回事。设备不会"跑到死"------维护人员会修它，工况会切换，有时候设备中途就被换走了。我们的空压机数据里，真正"从健康自然劣化到失效"的完整记录，两年只攒了37台。37个样本训练深度学习模型，你猜会怎么样？

业内的常见处理是给RUL标签加个上限（piece-wise linear labeling），比如C-MAPPS上普遍取125-130小时封顶。原因是设备在健康期的退化很缓慢，模型容易学成"恒等预测"。

python 复制代码

# 分段线性标签，业界标准操作
def piecewise_rul(true_rul, cap=125):
    # 健康早期不区分，超过cap一律截断
    # 别小看这一步，不加cap的LSTM训练误差能差30%
    return min(true_rul, cap)

注意这里有个细节：cap的取值很影响结果，太大退化趋势被稀释，太小有效标签变少。我在空压机数据上扫参发现cap取整个寿命的40%左右最稳。

三条主流技术路线

1. CNN路线：把信号当"图片"看

有个思路很巧妙：把滑动窗口内的传感器序列转成时频图（小波变换或者递归图），然后用ResNet这类现成的图像网络做回归。我2024年底用PyTorch 2.1复现过，把振动窗口转成64x64的递归图，喂进一个ResNet-18，在FD001上测试集RMSE能到13.8左右。

优点是迁移视觉领域的成熟架构很省事；缺点是时频转换本身有计算开销，边缘端部署不友好。

2. LSTM路线：时序建模的正统

滑窗序列直接进LSTM，是最经典的玩法。两层LSTM、隐藏层128维，接全连接回归RUL。

python 复制代码

class RulNet(nn.Module):
    def __init__(self, n_features=14):
        super().__init__()
        # 14个传感器通道，窗口50步
        self.lstm = nn.LSTM(n_features, 128, num_layers=2,
                            batch_first=True, dropout=0.2)
        self.head = nn.Linear(128, 1)  # 回归输出RUL

    def forward(self, x):
        out, _ = self.lstm(x)
        return self.head(out[:, -1, :])  # 只取最后一步

踩坑提醒：别用双向LSTM。有篇高引论文用了BiLSTM刷了点数，但双向结构在"预测未来"这件事上属于作弊------推理时未来的数据你根本没有。我们团队内部复现时发现BiLSTM在流式推理下性能直接崩，这种"纸面SOTA"看看就好。

3. CNN-LSTM混合：目前工业界的主流选择

先用一维卷积提局部特征（卷积核感受野捕捉局部退化模式），再进LSTM建模长期趋势。我们空压机项目最后上的就是这套，FD001上RMSE 11.2，实机验证误差中位数大概在真实寿命的8%以内。

至于Transformer？说实话，我持保留态度。注意力机制对长序列确实有优势，但工业数据的样本量撑不起它的参数量，C-MAPPS上一堆Transformer变种的提升都在1-2个RMSE以内，换来的训练成本和过拟合风险不划算。

争议点：RUL到底该回归还是分类

这是我最想聊的。主流做法是回归一个连续值，但我们的空压机项目最后改成了分类：把剩余寿命切成桶，比如0-7天、7-30天、30-90天、90天以上，四分类。

为什么？因为维修决策是分段的。客户只关心"这周要不要停机检修"，没人关心RUL是47天还是52天。回归模型拼命优化RMSE，最后优化的是一个没人用的数字。改成分类后，模型的输出直接对应维修窗口，现场接受度反而高了。

反对的人会说分类损失了精度信息。但反过来想，你的标签本身就是回数出来的粗估，误差几十个小时的情况下，追求连续值的精度有点自欺欺人。

写在最后

RUL这块，学术界热火朝天，工业界冷静得多的核心原因就一个：完整退化数据太稀缺。如果你手头有run-to-failure数据，恭喜你，先把它当宝贝存好；如果没有，老老实实从异常检测做起，别一上来就挑战RUL。

对了，那个销售总监最后拿到了他想要的功能，不过是"7天内需要关注"的分级预警。有些需求，换个形式就能落地。