简介这是一份面向AIOps异常检测竞赛的完整工程包基于LSTM对26个互联网KPIs时序指标进行异常识别源码、数据集与文档齐全。适合人工智能、计科等专业学生作为毕设或课设参考也便于竞赛入门者复现比赛思路。压缩包共14个文件以3个Python脚本预处理、训练、预测和4个CSV数据集为核心另含6张效果图与1份说明文档整体56.41MB结构紧凑便于按模块对照学习。数据集覆盖5家互联网公司的26个KPIs训练集带标记、测试集无标记可直接运行训练与预测脚本README和可视化图表展示异常检测效果与评分指标可用于复盘阈值设定等关键细节。目前已有94人学习下载既可当作完整赛题方案也可作为深度学习时序应用的入门案例在此基础上修改还能拓展到其他异常检测场景。1. 为什么异常检测要交给 LSTM一个反直觉的开场凌晨两点某厂压缩机的振动信号画出一条几乎平直的曲线均值只比前一小时抬高了 0.3%。固定阈值静悄悄LSTM 却在第 31 步报了警维修人员拆开轴承后发现点蚀已经出现。这就是基于 LSTM 的异常检测 python 源码类项目最典型的应用场景故障不是断崖式崩溃而是波形形态的细微漂移。这类大赛作品通常打包了三样东西——可运行的 python 源码、一册写清数据格式和调参位置的文档说明、一份带时间戳的传感器数据集。它要解决的核心问题不是分类而是在训练数据几乎全部正常、异常样本极度稀缺的条件下靠序列重建或预测误差把偏离正常形态的时间点揪出来。适合的人群很明确做工控数据分析比赛的学生、做设备预测性维护的工程师、以及所有手里有一堆时间序列但苦于没有异常标签的从业者。2. 源码与文档先读什么文件骨架、数据格式和异常标签的盘点拿到任何基于 LSTM 的异常检测 python 源码包第一件事不是打开 IDE 双击train.py而是先做盘点。一个规范的大赛项目通常按职责拆文件模型定义、数据加载、训练入口、评估脚本四者是分开的。文档说明里最值得读的不是算法原理——那部分是给评委看的而是三处数据每一列的含义、数据集里是否自带异常标签、超参数在哪个文件里改。见过太多人花两小时读算法背景结果跑起来才发现数据格式和代码假设不一致。2.1 项目文件骨架一眼定位训练入口和参数配置常见的大赛项目布局大致长这样我建议你对着自己的包核一遍文件/目录常见职责你最该看什么train.py训练入口读取数据并启动训练循环超参数写在哪里、是否有命令行参数model.pyLSTM 网络结构定义输入维度是不是和特征列数量一致data_loader.py数据读取、滑窗、归一化窗口长度和步长的默认值evaluate.py加载模型并输出检测结果阈值怎么算、输出是分数还是 0/1config.py或.yaml/.json集中管理超参数seq_len、hidden_size、lr 是否已预调data/目录训练集、测试集的时间序列文件是否有标签列、缺失值用什么填充README.md或说明文档运行步骤与依赖Python 版本、库依赖清单、运行顺序拿到包以后我一般会先看model.py的__init__里的参数默认值再看data_loader.py怎么切窗口。这两个文件对不上后面全是玄学。看文档说明时重点确认三件事采样频率是多少、训练段是不是纯正常数据、测试段的异常时刻是否公开。很多比赛为了公平训练段故意只放正常数据测试段才混入故障你要根据这一点决定阈值的标定方式。2.2 数据集加载与滑窗切分把时间序列变成 LSTM 能吃的形状时间序列喂给 LSTM 之前必须切成固定长度的窗口形状是(样本数, seq_len, 特征数)。下面的代码是一个最小可用的滑窗实现逻辑和大多数源码包一致import numpy as np import pandas as pd from sklearn.preprocessing import StandardScaler # 读取传感器数据时间列解析成真实时间顺序 df pd.read_csv(data/train.csv, parse_dates[timestamp]) # 假设有两列传感特征振动和温度 values df[[vibration, temperature]].values.astype(np.float32) def make_windows(data, seq_len64, stride16): 把一维数组切成语义重叠的滑窗序列。 windows [] for start in range(0, len(data) - seq_len 1, stride): windows.append(data[start:start seq_len]) return np.stack(windows) # shape: (样本数, seq_len, 特征数) # 时间序列的归一化必须只在训练段上 fit n_train int(len(values) * 0.8) scaler StandardScaler() scaler.fit(values[:n_train]) # 只学训练段的均值和方差 normed scaler.transform(values) # 用同一组参数变换全部数据 # 切分数据训练段和测试段各切各的避免窗口横跨两段 train_norm normed[:n_train] test_norm normed[n_train:] X_train make_windows(train_norm, seq_len64, stride16) X_test make_windows(test_norm, seq_len64, stride16)这段代码有几个设计点值得看清楚。第一stride16意味着窗口之间有 48 个点的重叠重叠让样本数量约为不重叠切分的 4 倍训练更充分但显存开销也同步放大。第二归一化只 fit 训练段这是为了阻止测试段的分布信息泄漏进模型——后面避坑章会细化这条。第三切分时训练段和测试段是分开切的否则窗口会横跨正常段和异常段模型在训练时就已经见过了待检测的故障形态。2.3 三个数据集格式变体拿到数据先确认是哪种不同大赛包的 CSV 格式差异很大处理方式完全不同数据格式典型结构处理方法单文件长表每行一个时间戳多列特征可带 label 列按时间排序确认终点无逆序多文件分段normal.csv和test.csv分开分别加载训练只用 normal 段宽表转置每列是一条传感器的完整时间序列先melt或按列转置成(time, feature)最隐蔽的坑是 label 列。有些数据集的 label 列是样例标签不是时间点标签——比如一整段传感器记录标记为“故障”但故障具体从第几秒开始不告诉你。文档说明里如果写了“segment-level label”而不是“timestamp-level label”异常检测的评估就要以段为单位而不是逐点计算。我建议拿到数据后先画一条 min-max 归一化的曲线图肉眼扫一遍训练段里有没有异常尖峰再决定要不要清洗。3. 模型原理与核心代码LSTM 门控、预测范式和训练循环LSTM 在时间序列异常检测里成为常客不是因为它听上去高级而是因为普通循环神经网络在反传时梯度容易指数衰减超过几十步之前的信息基本记不住。LSTM 在记忆单元上加了输入门、遗忘门、输出门三个门控把“该记多少”和“该忘多少”变成可学习的参数从而能在几十甚至几百步的跨度上保持对正常波形形态的记忆。对异常检测来说这意味着模型能捕捉到“这个位置的温度曲线形状不符合前两天同时段的走势”这类长程规律。3.1 两种主流范式预测未来 vs 重建当前基于 LSTM 的异常检测 python 源码里模型设计通常分两派。第一派是预测范式用前 64 个点预测下一个点或者未来几个点训练时让预测值和真实值算 MSE模型学会了“正常数据的下一步长什么样”检测时如果某一步的预测误差远超训练时的水平就认为是异常。第二派是重建范式把整个窗口喂进 LSTM要求输出还原这个窗口本身等价于一个序列自编码器模型没见过故障形态所以遇到故障窗口时重建误差会明显变大。两种范式在代码实现上的差别主要在标签构造。预测范式的训练样本是(x[:-1], x[1:])重建范式是(x, x)。大赛源码里最常见的是预测范式因为它不需要 decoder 结构模型更轻训练更快也更容易在设备寿命预测的场景里迁移。但如果你的数据是强周期性的重建范式往往效果更好因为周期性让重建任务变得简单模型可以把精力集中在捕捉细微形变上。我的建议是先用预测范式跑通全流程再在同一个model.py里把输出改成重建目标做对比实验。3.2 模型代码拆解一个能跑通的最小 LSTM 检测器下面用 PyTorch 定义了一个最小可用的 LSTM 异常检测模型结构和多数大赛源码的model.py等价import torch import torch.nn as nn class LSTMDetector(nn.Module): 基于 LSTM 的序列预测/重建模型输入输出形状一致。 def __init__(self, input_size, hidden_size64, num_layers2, dropout0.2): super().__init__() self.lstm nn.LSTM( input_sizeinput_size, hidden_sizehidden_size, num_layersnum_layers, batch_firstTrue, # 输入形状 (batch, seq_len, features) dropoutdropout, ) # 把每一时刻的隐状态映射回原始特征维数 self.predictor nn.Linear(hidden_size, input_size) def forward(self, x): # x 形状: (batch, seq_len, input_size) out, _ self.lstm(x) # out 形状: (batch, seq_len, hidden_size) pred self.predictor(out) # pred 形状: (batch, seq_len, input_size) return pred这里predictor作用在每个时间步的隐状态上输出和输入逐点对齐。如果用预测范式训练时把输入右移一位作为目标如果用重建范式目标就是输入本身。num_layers2是大赛项目的常见默认值两层堆叠足够捕捉中等复杂度的波形规律三层以上在小数据集上很容易过拟合。dropout0.2加在 LSTM 层之间如果你发现训练 loss 下降很慢但验证误差纹丝不动可以试着调低。3.3 训练循环与必调参数区间无监督异常检测的训练循环比分类任务简单因为不需要标签def train_one_epoch(model, loader, optimizer, criterion, device): model.train() total_loss 0.0 for x_batch in loader: # 每个 batch 已经是滑窗切好的序列 x_batch x_batch.to(device) # 预测范式前 seq_len-1 步预测后一步目标右移一位 pred model(x_batch[:, :-1, :]) target x_batch[:, 1:, :] loss criterion(pred, target) optimizer.zero_grad() loss.backward() optimizer.step() total_loss loss.item() * x_batch.size(0) return total_loss / len(loader.dataset)注意x_batch[:, :-1, :]和x_batch[:, 1:, :]的对齐方式用前 63 步预测第 64 步整个窗口滑过一遍每个位置都参与训练。损失函数用nn.MSELoss()最稳妥因为它对小幅漂移敏感这正是异常检测要捕捉的信号。优化器常见选择是 Adam学习率从 1e-3 起步。下面这张参数表是我在多个设备监测项目里跑过的经验区间比直接照抄源码默认值更值得参考参数推荐区间偏大时的表现偏小时的表现seq_len约为信号主周期的 1~2 倍显存暴涨训练慢梯度易衰减学不到周期形态漏报增多strideseq_len // 4左右样本数少模型欠拟合样本冗余高训练耗时翻倍hidden_size32~128过拟合训练 loss 降不下去表达能力不足误差下探困难num_layers1~3小数据集上严重过拟合捕捉不到多层抽象特征dropout0.1~0.3欠拟合loss 高过拟合验证误差与训练误差差距大lr1e-4~1e-3loss 震荡模型不收敛收敛缓慢浪费 epochbatch_size64~256显存溢出batch 间 loss 抖动训练太慢梯度方向不稳3.4 设备寿命预测场景里的参数调整经验把这段代码挪到设备寿命预测实战场景时参数逻辑要跟着采样率走。比如振动传感器 2kHz 采样轴承故障特征频率通常在 30~100Hz 之间主周期约为 20~60 个采样点seq_len取 64 或 128 就能覆盖一个完整周期还留余量。但如果是温度监测这类缓变信号五分钟采一次主周期是按小时算的强行把seq_len拉到几百上千步LSTM 也学不动——这时反而应该降低采样频率或缩短窗口让每个窗口里包含足够的变化而不是大量平直段。判断seq_len是否合理有一个很土但有效的办法把一条正常曲线切成窗口窗口内的数据如果大部分是接近水平的直线说明窗口太大或者特征太缓如果窗口里能明显看到两个以上的波形起伏说明长度合适。训练时盯着 loss 曲线正常情况是前几个 epoch 快速下降之后进入平缓期如果 loss 从头到尾不动先查归一化再查学习率最后才考虑换模型结构。4. 误差转异常分数阈值、迟报漏报和评价指标模型训练完只算完成了前半程。LSTM 的输出是预测值不是异常分数。要把“预测错了多少”变成“此刻是否异常”中间还隔着一条完整流水线计算误差、还原到时间轴、平滑、设阈值。这一章是比赛项目从能跑到能用的分水岭也是新手和熟手拉开差距的地方。4.1 把逐点误差还原到原始时间轴滑窗切分带来的一个麻烦是同一个时间点会出现在多个窗口里比如stride16, seq_len64时一个点最多属于 4 个窗口。每个窗口都会对那个点产生一个预测误差最终该点的异常分数要综合这些误差。直接取最大值会放大偶然尖峰取平均值则更稳健。下面是还原逻辑的参考实现def compute_anomaly_score(model, normed, seq_len64, stride16, devicecpu): 逐窗口预测并计算每个时间点的平均重建/预测误差。 model.eval() timesteps len(normed) score np.zeros(timesteps, dtypenp.float32) count np.zeros(timesteps, dtypenp.int32) with torch.no_grad(): for start in range(0, timesteps - seq_len, stride): window normed[start:start seq_len] x torch.from_numpy(window).unsqueeze(0).to(device) # (1, seq_len, features) # 预测范式用前 seq_len-1 步预测最后一个点 pred model(x[:, :-1, :]) # 只取最后一步的预测误差归属到 startseq_len 这个时间点 err torch.mean((pred[0, -1] - x[0, -1]) ** 2).item() pos start seq_len - 1 score[pos] err count[pos] 1 # 对重叠覆盖的位置取平均未被覆盖的位置保留 0 valid count 0 score[valid] / count[valid] return score这段代码和训练时的对齐方式要保持一致否则误差归属会错位。训练时用前 63 步预测第 64 步推理时就得同样用前 63 步预测第 64 步把误差记在第 64 步头上。有些源码包图省事对窗口内每一步都算误差再取平均这在重建范式下没问题但预测范式下会模糊“哪一步预测错了”的信息。我见过最大的翻车点就在这里预测和误差归属的偏移没对齐导致报警时刻整体晚了一个窗口的长度。4.2 阈值标定的两种方法分位数与三西格玛拿到全时间轴的误差分数后需要定一个阈值。主流做法有两种。第一种是固定分位数取训练段误差分布的 99% 或 99.5% 分位数作为阈值超过就报警第二种是拉依达准则用均值加 3 倍标准差。工程上我更推荐分位数因为异常分数往往严重右偏均值加三倍标准差容易受极端值影响阈值被拉得过高漏报率直线上升。下面是分位数标定的示意train_score compute_anomaly_score(model, normed[:n_train], ...) test_score compute_anomaly_score(model, normed[n_train:], ...) # 选训练段 99 分位作为阈值 threshold np.percentile(train_score, 99) alarm test_score threshold99%分位意味着训练时每 100 个点允许 1 个误报。如果你的测试段有两万个点这就是 200 个误报点数量不小。所以很多成熟项目不会直接逐点报警而是要求连续 N 个点超过阈值才触发一次事件N一般取 3 到 5能滤掉绝大多数孤立尖峰。4.3 评价指标不能只看准确率一个 99% 的陷阱异常检测和普通分类的评价逻辑完全不同。假设测试集里只有 0.5% 的点是异常一个把所有点都判为正常的模型准确率高达 99.5%但它毫无用处。比赛源码包里如果只给了准确率曲线这项目基本没做扎实。真正要关心的是这三个指标指标计算方式在异常检测里的含义召回率TP / (TP FN)真实异常里有多少被报了出来漏报的代价往往很高精确率TP / (TP FP)报警里有多少是真的异常误报太多会导致现场人员不再信任系统检测延迟首次报警点 - 真实异常起点提前多少步发现问题比 F1 更贴合预测性维护F1 是召回率和精确率的调和平均但比赛和实际工程里检测延迟经常比 F1 更值钱。因为“晚报警 40 步”可能意味着设备已经发生实质损伤而“误报 20 次”只是让维护人员多点几次鼠标。当我拿到一份异常检测源码时会先看评估脚本里有没有延迟这个指标——有说明作者真的思考过落地没有就得自己补上。4.4 阈值调整的玄学与几个土办法阈值这东西有点玄学。同一个模型同一个数据集换一台设备跑99% 分位阈值就可能频繁误报。原因是不同设备的基础振动水平不同误差分数分布也跟着平移。一个土办法是把测试段最前面的 500 个点当作校准基线用这 500 个点的误差分布去重新标定阈值再往后检测。这个技巧在很多比赛代码里不写但实际效果立竿见影。另一个土办法是把异常分数做一次滑动平均窗口长度取 5~10 个点。滑动平均会牺牲几个点的报警速度但能换回肉眼可见的误报率下降对最终得分往往是划算的。5. 复现与迁移中的五个坑数据、模型、阈值哪里最容易翻车以下五条全是实际跑基于 LSTM 的异常检测项目时的血泪经验每一条都按现象、原因、解决来写。在把源码跑通之前读一遍能省掉不少调试时间。5.1 训练数据污染与归一化泄漏现象训练 loss 降得很漂亮但测试时异常分数普遍偏低或者偏高报警行为完全不符合直觉。回看代码发现训练段里包含了测试段的归一化统计量。原因两种源头一种是数据切分时没有按时间点切开窗口横跨了训练和测试两个段导致模型在训练时就见过异常片段。另一种是StandardScaler直接在全量数据上fit_transform测试段的均值和方差提前泄漏给了训练过程模型学到的“正常”边界是掺了测试信息的假边界。解决先用绘图工具把整条时间序列画出来标注出训练段和测试段的边界肉眼确认边界上没有异常形态。然后严格按顺序执行先切段再在训练段上fitscaler用同一个 scaler 去transform测试段。我在自己的流水线里把这三步写成三个独立变量防止顺序被误改。5.2 滑窗长度拍脑袋与误差时间错位现象模型训练完成后报警时间整体偏移有时早一个窗口有时晚一个窗口和真实异常起点对不上。还有人把seq_len从 64 改成 256 后loss 反而上升。原因滑窗长度既决定模型能看到的上下文长度也决定误差归属的位置。seq_len远超信号主周期时窗口里包含大量重复的周期信息LSTM 的遗忘门会主动丢掉部分早期信息序列太长反而增加噪声。误差错位则是因为训练目标和推理时误差归属点不一致——训练用 63 步预测 64 步推理却把误差平均到整个窗口偏差就累积出来了。解决先用快速傅里叶变换估计信号主周期seq_len设为信号主周期的 1~2 倍。然后统一训练和推理的误差归属约定预测范式下误差只属于被预测的那个点重建范式下误差属于窗口中心点。代码里写个简短的单元测试给模型喂一条有明确脉冲的信号检查报警点是否出现在脉冲之后而不是之前就能暴露错位。5.3 固定阈值在不同设备之间失效现象在 A 设备上标定好阈值直接套到 B 设备上B 设备从头报警到尾或者一个都不报。原因不同工况下的设备传感器量程、安装位置、运行转速都不同误差分数的绝对分布差异极大。固定阈值是全局标定的迁移时必然失配。解决对每台设备单独用它的历史正常数据重新标定阈值。如果设备刚上线没有历史数据就用行业经验先设一个保守阈值然后随着数据积累每 24 小时重标一次。阈值重标定这段代码要写成独立函数和训练流程解耦否则每次重训模型都很痛苦。5.4 训练 loss 不降排查的三个顺序现象模型训练了 50 个 epochloss 曲线几乎水平误差分数和随机噪声没有区别。原因多半不是 LSTM 结构有问题而是数据管道坏了。常见原因包括输入没有归一化、DataLoader 的 shuffle 破坏了时间顺序、学习率过大导致梯度震荡、窗口切分后数据形状是(seq_len, features)却忘了加 batch 维度。解决按固定顺序排查。先打印一个 batch 的x_batch.shape和数据取值范围确认形状是(batch, seq_len, features)且数值在 0 附近。再检查 DataLoader 是否把shuffleTrue用在了跨窗口维度——窗口内部顺序绝对不能打乱但窗口之间的顺序打乱是可以的。最后把优化器换成 Adam、学习率降到 1e-4 重跑一次如果还不降去检查损失函数输入和目标的错位。5.5 报警事件和真实故障对不上时先查什么现象测试集里明明标了两个故障段模型报警也报了两段但报警段比真实故障段短了一半或者一个故障报了三次。原因故障形态存在渐变过程模型在故障刚萌芽时就开始报警但数据集的标签只标注了故障恶化的中段反过来一个长故障段中间偶尔有正常振动模型也会在中间短暂停止报警导致一个故障被拆成多个事件。解决用“事件级”评估代替“逐点级”评估。定义只要报警区间与真实故障区间有任意重叠就算正确检出连续两个报警区间间距小于 50 个点则合并为一个事件。这个逻辑是比赛评分里最常见的设定源码包里如果没实现建议自己补上。6. 从比赛代码到真实设备异常注入验证与寿命预测的进阶方向比赛跑通只是起点。把这份源码迁移到真实设备健康管理时有两个方向最值得做先用异常注入验证检测器的有效性再把“检测异常”升级为“预测剩余寿命”。异常注入验证法真实故障样本稀少你无法确认模型学的“正常形态”是否足够鲁棒。常见做法是在正常测试序列上人工注入异常模式——比如在第 100 到 105 个点叠加一个 3 倍幅值的脉冲或者在 20 个点的区间内把信号斜率加倍——再看异常分数是否显著抬升。这个验证能暴露很多隐蔽问题窗口太长时短脉冲会被周围正常点稀释误差分数抬升不明显窗口太短时脉冲直接污染输入模型可能把异常也“预测”出来了。def inject_anomaly(window, start10, length5, strength3.0, seed0): 在正常窗口上注入异常脉冲返回注入后的窗口和异常区间。 import numpy as np rng np.random.default_rng(seed) injected window.copy() injected[start:start length] strength * np.std(window) * rng.randn(length, window.shape[1]) return injected, (start, start length)运行注入验证时目标不是让每个注入都报警而是观察异常分数相对阈值的倍率。倍率稳定在 1.5 以上说明模型对这类异常有区分度倍率在 1 附近波动说明检测能力不可靠需要回头调窗口或加特征。从异常检测到剩余寿命预测真正的设备预测性维护不会停在“报警”而是想回答“还能撑多久”。这一步的改动比想象中小把模型输出的nn.Linear(hidden_size, input_size)换成nn.Linear(hidden_size, 1)训练标签从“重建输入”换成“距故障剩余时间”损失函数改用平滑的 Huber Loss。换句话说同一个 LSTM 编码器换一个输出头就从异常检测器变成了寿命预测器。设备寿命预测实战中这个迁移路线被验证过很多次比赛代码的滑窗、归一化、数据管道全部可以复用省掉的不只是开发时间还有重新踩坑的成本。我曾为了一套设备监测系统的上线把比赛项目里的检测延迟从 40 步压到 8 步代价是误报率涨了三个百分点。后来发现真正该做的不是逼模型而是把报警后的人工确认流程做轻让现场人员 10 秒内判断是误报还是真故障。这套调整思路是我用实际翻车换来的教训希望能帮到你。本文还有配套的精品资源点击获取