预测性维护中的时间序列异常检测:从3sigma到Transformer

上个月整理公司代码库,翻出来一个2019年写的监控脚本,就十几行:读PLC采集的温度序列,算均值和标准差,超3sigma就报警。让我有点感慨的是,这个脚本至今还在一家建材厂的窑炉车间里跑着,没出过大问题。

而同一个代码库里,还躺着一个2023年写的Anomaly Transformer实验代码,训练了几百个epoch,最后没有上线。

从3sigma到Transformer,中间踩过的坑比写过的论文都多。这篇文章就把这几代方法的演进、各自的适用边界和翻车现场捋一遍。

第一代:3sigma不是垃圾,是基线

先给3sigma正个名。它假设数据近似正态分布,超过μ±3σ判为异常,就这三行逻辑,覆盖了工业现场一大批慢变量场景:储罐液位、环境温度、油箱油温------变化平滑、物理上不可能突变的信号。

它真正的死穴是非平稳。转速变化的电机电流、负载波动的轧机力矩,μ和σ本身在漂移,固定阈值天天误报。我们2019年就在风机功率数据上翻过车:白天负荷高、夜里负荷低,用全局3sigma,每天下午四点准时"异常",其实是负荷爬坡。

所以我的观点一直很明确:3sigma不是被淘汰的方法,是用错场景的方法。任何新传感器信号上手,我都会先跑一遍3sigma看分布,它是最快的健全性检查。

第二代:滑动窗口统计,让阈值"活"起来

要处理非平稳,最直接的思路是让统计量跟着数据走。EWMA(指数加权移动平均)和CUSUM(累积和)是这一代的代表,本质都是"用近期数据定义正常"。

EWMA对缓慢漂移特别敏感。轴承磨损引起的温度逐月爬升,全局统计可能永远追不上,EWMA窗口内几周就能拉响。CUSUM专门抓持续性小偏移,在过程工业用得多。

这一代的坑在窗口和灵敏度的调参。窗口太短,正常工况切换(开机、换产)被误报;太长,故障响应又慢半拍。那时候调一套参数要跑好几天的历史回放,没有捷径,就是笨功夫。但现在回头看,这套笨功夫打下的"对数据的体感",比后来学任何算法都有用。

第三代:机器学习入场,Isolation Forest和自编码器

测点数量上来之后,统计方法不够用了。300个测点互相耦合,谁跟谁正常、谁跟谁不正常,人眼看不过来。这一代我们主力用两个东西。

Isolation Forest,scikit-learn 1.3.x里几行代码,适合多维特征联合判断"这个工况点有多孤立",训练快、内存友好,我们常拿它做设备运行工况的粗筛。

真正的主力是LSTM自编码器:模型只学正常数据,重构误差大就是异常。它最大的好处是不需要故障样本------工业现场本来就凑不出多少故障标签,这个现实约束比任何算法偏好都硬。

最小可用的实现大概是这个样子(PyTorch 2.1):

python 复制代码
import torch
import torch.nn as nn

class LSTMAE(nn.Module):
    def __init__(self, n_feat=8, hidden=64):
        super().__init__()
        self.encoder = nn.LSTM(n_feat, hidden, batch_first=True)
        self.decoder = nn.LSTM(hidden, n_feat, batch_first=True)

    def forward(self, x):
        # x: [batch, seq_len, n_feat]
        # 窗口长度建议取一个工况周期的整数倍,不然重构误差有周期性起伏
        _, (h, c) = self.encoder(x)
        h_last = h[-1]                                     # [batch, hidden]
        dec_in = h_last.unsqueeze(1).repeat(1, x.size(1), 1)
        out, _ = self.decoder(dec_in, (h, c))
        return out

注意这里有两个容易翻车的细节:训练集只用正常段数据,验证集里要故意混一点已知故障段,用F1分数找重构误差阈值------别用最大误差当阈值,那是对异常值的过拟合;另外一定要做滑动窗口重构,不要单点重构,单点的重构误差抖动太大,误报根本压不下去。

在一家水泥厂的生料磨上,8个测点、10秒采样,LSTM-AE把误报率从统计方法的每天20多次压到2次以内,还提前40分钟报出了主轴承温度漂移。这是它值得花钱的地方。

第四代:Transformer系,光环之下要冷静

2022年Anomaly Transformer(ICLR 2022)火了之后,我们2023年在两组数据上认真复现过。说实话,结果泼了冷水。

公开的SWaT水处理数据集上,复现指标和论文差距不大,没啥好说的。但换成我们自己的钢厂轧机数据------非平稳、工况切换频繁------它的表现不如调好的LSTM-AE。论文里的"关联差异"机制,在高噪声、强非平稳的工业信号上没有展现出预期优势,训练成本倒是翻了将近十倍:A10显卡上LSTM-AE两小时跑完的训练,它要一天多。

有意思的是,2024年之后时序基础模型(TimesFM、Chronos这类预训练模型)流行起来,零样本异常检测成了新方向。我们在风机数据上试过Chronos的zero-shot打分,效果中规中矩------不如在domain数据上微调过的小模型,但胜在不用训练,适合新设备上线初期的冷启动。这个定位我觉得是合理的,但把它吹成"异常检测的终点"就过了。

我的判断一直没变:80%的预测性维护异常检测场景,滑动窗口统计+Isolation Forest+LSTM-AE这套组合拳足够了;剩下20%里的一半,是数据质量没做好,换什么模型都白搭。Transformer留给真正需要长程依赖建模、且数据质量过硬的场景。

最后说两句

方法演进这些年,我最深的体会是:异常检测的天花板往往不在算法,而在你对"正常"的定义有多清楚。3sigma的μ±3σ是一种正常,LSTM-AE学到的数据流形也是一种正常------前者清楚但粗糙,后者精细但黑盒。

别为了用新模型而用新模型。先把信号的物理意义搞明白,再谈算法,这个顺序不能反。

相关推荐
zxsz_com_cn2 小时前
预测性维护云平台选型:自建还是买SaaS?
saas·工业4.0·预测性维护·云平台选型·自建
zxsz_com_cn6 小时前
皮带输送机的AI巡检:从人工点检到机器听诊
工业4.0·预测性维护·皮带机·声音诊断·巡检数字化
Jsundoku6 小时前
第七章 深度学习 -- Transformer 架构
人工智能·深度学习·transformer·1024程序员节
陈 洪 伟18 小时前
Transformer彻底剖析(9):归一化演进——BatchNorm、LayerNorm、RMSNorm、Post-LN / Pre-LN、DeepNorm
人工智能·深度学习·transformer
布吉岛的石头19 小时前
Java 程序员第 50 阶段3:数据工程:预训练语料清洗与去重
java·开发语言·人工智能·深度学习·transformer
Eyfcom1 天前
〖深度〗物流系统的“自愈”能力:从被动告警到无人干预的闭环工程
预测性维护·自愈系统·物流系统架构
爱听歌的周童鞋1 天前
MIT 6.5940 | TinyML 与高效 AI 计算 | Fall 2026 | 笔记 | Lecture 12:Transformer and LLM
transformer·大语言模型·tinyml·mit 6.5940·高效 ai 计算
EDPJ1 天前
(2026|中科院自动化所,路由冗余,动态分配的价值在激进剪枝,多模态更脆弱)你只需要选定专家的 2/3:细粒度 MoE LLM 中的动态专家剪枝
transformer·剪枝·moe·混合专家模型
前端.火鸡2 天前
参数量、上下文窗口与模型规格怎么看
人工智能·深度学习·transformer
一只废狗狗狗狗狗狗狗狗狗2 天前
Transformer——一个sequence-to-sequence的model
人工智能·自然语言处理·transformer