简介一份基于Transformer架构的多模态异常检测完整项目资源面向机器学习、深度学习方向的研究者与工程师适合想系统学习异常检测实战、掌握多模态数据处理与Transformer应用的读者。压缩包内共314个文件包含164个npy数据文件、116个txt说明文件、12个csv数据集、4个Python脚本及Markdown文档等涵盖模型源码、预处理函数、多模态数据集与README教程整体大小约107.6MB便于直接复现与二次开发。目前已有256人学习浏览内容热度真实可参考。项目以合成数据与真实系统监控数据为主覆盖图像、序列等多模态输入演示如何利用自注意力机制捕捉跨模态关联并识别异常样本同时提供csv标签文件便于验证模型效果。通过学习可掌握Transformer在多模态学习中的实现细节、无监督异常检测思路以及PyTorch/TensorFlow框架下的模型训练与调试方法是理论与实践结合的高质量入门资料。1. 多模态异常检测资源拆包先用三分钟搞清楚这套 Transformer 方案能解决什么把 Transformer 架构搬到多模态异常检测上这两年几乎是运维监控和时序告警的标配。这份资源不是理论科普而是一套能直接跑起来的最小实现内置十个 CSV 数据集包括机器温度故障、CPU 利用率误配置、EC2 请求延迟、纽约出租车流量这些 NAB 经典监控数据外加合成多模态数据和对应标签配套 PyTorch 源码和教程。方案走的是重建式无监督路线——模型只学正常模式拿 Transformer 重建误差当异常分数。适合做基础设施监控、数据质量校验的工程师拿来当基线。先给结论代码不难跑坑全在数据切分和阈值标定后面我把翻车点提前拆给你。2. 原理先行自注意力机制为什么比 LSTM 更适合找异常2.1 自注意力机制在异常检测上的三个落点网上讲 transformer 模型详解的帖子非常多但绝大多数例子默认你是做 NLP。真正落到异常检测自注意力机制的三个特性正好打在监控数据的痛点上。第一是长程依赖。机器温度故障这类场景异常往往不是单点突变而是长达一两个小时的渐进漂移。LSTM 靠门控机制一步步把信息往下传序列一长早期信息要么被遗忘要么被稀释自注意力则让序列里任意两个时间步直接计算关联信息路径是恒定的。对异常检测来说记住正常模式是最核心的一步长程记忆直接决定漂移型异常能不能被识别。网上关于 transformer 时序预测的帖子很多但直接搬来做异常检测的反而少区别就在这个重建目标上。第二是并行训练。LSTM 按时间步展开Transformer 的所有时间步同时做矩阵运算。这个差异在调参阶段非常现实同样一台普通机器LSTM 跑 NAB 这种几千行数据的全量实验基本要过夜Transformer 因为并行计算半小时能跑完一轮滑窗实验多试几组 window 和 learning rate 就靠这个。第三是跨模态对齐。监控里温度、CPU、延迟往往不同步温度异常可能滞后 CPU 飙高几分钟。LSTM 处理异构时序得靠手动对齐Transformer 的注意力矩阵天然在学“哪个时间步的哪个模态和当前位置最相关”多模态拼接后这个能力尤其明显这也是这份资源敢把多个数据集拼在一起训的理论基础。代价也要说清楚自注意力的计算量随序列长度平方增长所以窗口并不是越长越好。监控数据窗口取 64~128这个规模下完全在承受范围内但如果有人告诉你把整段几万行序列一次性喂进去你该警惕的是显存和训练时间而不是效果。还有个细节常被忽略Transformer 本身没有时序概念窗口里每个时间步的位置全靠位置编码提供。可学习位置编码在异常检测里有个好处——模型能感知“这是刚进入窗口的状态”还是“已经在窗口里待了 40 步”对有趋势型漂移的异常识别有实际帮助。动手实现时第一版就把位置编码加上别省。2.2 多模态融合在监控里的真实含义如果按图像、文本、语音那种公认的多模态定义来套这份资源你会失望——数据全是 CSV 时间序列一张图都没有。但换个口径温度、CPU、网络延迟、按键行为每一条来源就是一个模态多个来源拼在一起就是多模态融合这是运维监控里最接地气的定义。常见做法是在特征维度拼接。三个一维序列各带自己的特征列拼成一个多维 feature 向量模型看到的就是一个 [window, n_features] 的输入矩阵。Transformer 编码器并不关心特征通道来自哪里它只学通道之间的注意力关系。有两个层面必须处理到位一是每个模态先单独归一化再拼接不然量纲差异会压掉小尺度模态的贡献二是如果各模态采样频率不一致必须先重采样到同一个时间戳网格这一步做不好多模态融合就变成数据错位后面所有结论都是错的。资源里这批数据的时间戳已经对齐过但你自己换数据时这一步逃不掉。举个例子EC2 请求延迟那路数据尖刺出现通常伴随 CPU 利用率同步爬升但延迟尖刺往往比 CPU 先出现一两分钟。单看延迟尖刺像噪声单看 CPU趋势模糊。两个模态拼在一起后注意力机制能学到“延迟尖刺之后 CPU 跟着上升”这个组合模式比任何单一模态都稳。这正是多模态融合在异常检测里最大的价值——用模态间的相关性对抗单模态的噪声。2.3 重建误差链路无监督打法的完整闭环异常检测落地时最常见的困境是标签稀少海量正常监控数据带标注的故障样本可能就几十条分类模型根本喂不饱。重建式方案只学正常模式训练时喂正常窗口模型输出逼近输入遇到没见过的异常窗口重建误差显著变大。打分链路是固定的score ((xhat - x) ** 2).mean(dim-1) # [B, window] 逐点重建误差窗口内每个时刻都有误差怎么聚合成逐点分数是个小设计点。资源里教程的做法是取每个窗口最后一个点的误差然后按时间对齐成整条序列的分数。这行代码是整条无监督链路的出口——阈值搜索、PR 计算、跨数据集对比全在这一步。推理打分时注意 batch 大小不影响分数分布但影响显存占用CPU 上推理建议 batch 设 256速度和占用都比较均衡。复现时我建议先用 synthetic_data_with_anomaly-s-1.csv 把链路跑通看异常分数在标注区间上是否明显跳高再去动模型结构否则你很难判断是模型坏了还是评分逻辑错了。另外有个常见误用值得提醒不要用分类准确率来评估重建式异常检测。模型只在正常数据上训练输出天然偏向正常样本用准确率评估会得到虚高的数字。标准的做法是画 PR 曲线、算 F1或者直接看异常分数在标注区间的分布对比这三个指标才算数。3. 数据集拆解十个 CSV 的业务来源、标签与划分规则3.1 文件清单与格式压缩包里的数据文件看起来很多但按业务来源归类后并不复杂。我按 NAB 基准的口径把它们分成三类文件业务来源数据特点machine_temperature_system_failure.csv机器内部温度缓变信号异常是渐进温度上升cpu_utilization_asg_misconfiguration.csvAWS 自动伸缩组 CPU 利用率异常是长段高负载和正常波动难区分nyc_taxi.csv纽约出租车载客数强周期加节假日效应趋势明显ambient_temperature_system_failure.csv机房环境温度小幅持续偏移型异常ec2_request_latency_system_failure.csvEC2 请求延迟尖刺型异常噪声大rogue_agent_key_updown.csv / rogue_agent_key_hold.csv按键行为数据频率型数据按键次数和持续时间synthetic_data_with_anomaly-s-1.csv合成多模态数据多列特征异常模式已知适合算法验证labels.csv合成数据对应标签逐样本标注是否异常labeled_anomalies.csv汇总标签多数据集异常区段统一格式用于整体评估NAB 风格的文件基本是两列timestamp、value时间戳已是标准格式pd.to_datetime 直接解析即可。labeled_anomalies.csv 里的标签时间戳已经和原始文件对齐评估时直接 inner join不用自己再去解析异常边界。拿到数据第一件事不是训练而是跑一份描述性统计看每列均值、标准差、缺失值数量。我见过有人跳过这步直接开训结果某个文件里埋了一个空值段模型学到的是“空值等于正常”换到线上立刻穿帮。3.2 标签怎么读、怎么对齐labels.csv 是逐行布尔标签和合成数据一一对应适合验证模型能不能区分单点异常labeled_anomalies.csv 把多数据集的异常区段统一成区间标注粒度是“某段时间是否异常”更贴近真实告警评估。两者用哪个取决于你要回答什么问题验证模型能力用前者评估业务可用性用后者。对齐的做法是时间戳转成 datetime 索引把异常区段切出来在特征矩阵上打 mask。这个环节最容易出错的是时区。CSV 里如果混用了 UTC 和本地时间排序一错标注全错位模型再好也白搭。我处理陌生数据时会先打印时间戳的头尾和间隔确认采样频率稳定、没有跳变再往下走。标签读进来之后我习惯先画一张全序列图把标注区间用不同颜色叠上去。这一步能筛掉大多数数据质量问题标注对不齐、时间戳乱序、异常区间跨在正常段中间一眼就能看出来。别跳过这个肉眼检查直接进模型后面定位问题会花十倍时间。3.3 划分规则正常窗口进训练异常区间留给评估重建式训练的铁律是训练集只能有正常数据。做法是先把标签为 1 的区段全部挖掉再在剩余的正常段上滑窗def split_normal_anomaly(series, labels, window64, stride8): normal_series series[labels 0] windows [] for start in range(0, max(1, len(normal_series) - window), stride): windows.append(normal_series[start:start window]) return np.stack(windows)逻辑说明normal_series 只保留正常点异常点全部移除后续滑窗生成的窗口天然全是正常样本模型学到的就是正常数据分布。注意别直接在原序列上按窗口滑再过滤标签那样一个窗口里可能同时含正常和异常重建误差被拉平均检测反而变钝。划分比例我按时间切训练段取前面 60% 到 70%验证段和测试段留在后面。为什么按时间而不是随机切监控数据本身有趋势和周期性随机切分会让模型在验证时遇到和训练同分布的趋势段显得性能很好但真实部署是预测未来时间切分才贴近真实场景。另外注意标签极度不平衡。NAB 这类数据异常占比通常不到 5%有的文件甚至不到 1%。阈值搜索时 F1 会被大量正常样本拉向保守方向一个可行的改进是把分数按局部窗口做平滑或者用 PR 曲线的面积做选择标准而不是单看 F1 峰值。提示如果业务数据里正常段太短滑窗样本不够常见做法是降低 stride 增加重叠窗口或者放宽 window 到 32。但训练样本数和窗口重叠度是此消彼长的关系别为了凑样本把 stride 压到 1那样模型见过的是高度重复的数据泛化反而差。4. 最小可跑实现用 PyTorch 搭一个 Reconstruction Transformer4.1 环境与目录依赖只有四个torch、pandas、numpy、scikit-learnPyTorch 2.x 都行CPU 也能把这份资源里所有实验跑完大概半小时一轮。压缩包里的 README 把安装、跑数、出图流程写得很顺按顺序敲命令就行src 目录下是全部源码结构大致是src/ data_loading.py # 数据加载、标准化、滑窗 model.py # Transformer 编码器模型定义 train.py # 训练与打分 evaluate.py # 阈值搜索与评估README 里给的运行顺序是 data_loading 到 train 再到 evaluate命令就三行但别急着全跑——数据这关没检查完后面所有输出都要返工。4.2 数据加载与滑窗生成数据加载模块要做两件事把 CSV 读成统一格式以及完成标准化。标准化的写法有点讲究看下面这段import pandas as pd import numpy as np import torch from torch.utils.data import Dataset, DataLoader def load_monitor_series(path, fit_meanNone, fit_stdNone): df pd.read_csv(path) df.columns [timestamp, value] x df[value].astype(float).values.reshape(-1, 1) if fit_mean is None: # 只在训练段拟合统计量 fit_mean, fit_std x.mean(), x.std() 1e-6 x (x - fit_mean) / fit_std return x, fit_mean, fit_std逻辑说明参数 fit_mean 和 fit_std 默认是 None第一次调用这个函数加载训练数据时会自动算之后加载验证集和测试集时把训练段的统计量传进来保证三段数据用同一套归一化参数。后面 5.2 节会讲这一步做错是整个项目最隐蔽的翻车点。如果数据集是多列的比如 synthetic 数据reshape 那里要把所有特征列一起读进来x.shape 变成 [seq_len, n_features]而不是 [seq_len, 1]。模型对通道数不敏感统一按特征维处理。接着生成滑窗数据集class SlidingWindowDataset(Dataset): def __init__(self, series, window64, stride8): samples [] for start in range(0, max(1, len(series) - window), stride): samples.append(series[start:start window]) self.data torch.FloatTensor(np.stack(samples)) def __len__(self): return len(self.data) def __getitem__(self, idx): return self.data[idx]window 是模型看到的上下文长度stride 是窗口滑动的步长。stride 设小能出更多样本但相邻窗口高度重叠训练变慢且容易过拟合我一般取 window 的 1/8 到 1/4window 64 时 stride 定 8样本量和独立性比较均衡。4.3 轻量 Transformer 编码器模型模型只保留 Transformer 的编码器部分解码器不需要因为任务是重建整个窗口不是生成未来值import torch.nn as nn class ReconstructionTransformer(nn.Module): 多模态重建模型各通道在特征维拼接编码后还原原始输入。 def __init__(self, n_features, d_model64, nhead4, n_layers2, window64): super().__init__() self.proj nn.Linear(n_features, d_model) self.pos nn.Parameter(torch.randn(1, window, d_model)) layer nn.TransformerEncoderLayer( d_modeld_model, nheadnhead, dim_feedforward256, dropout0.1, batch_firstTrue, activationgelu) self.encoder nn.TransformerEncoder(layer, num_layersn_layers) self.head nn.Linear(d_model, n_features) def forward(self, x): # x: [B, window, n_features] h self.proj(x) self.pos # 输入投影 位置编码 h self.encoder(h) # 多层自注意力 return self.head(h) # 逐点重建输出几个参数值得单独说。batch_firstTrue 让输入保持 [batch, seq, feature] 的顺序写 DataLoader 时不用来回转置。位置编码这里用可学习的 nn.Parameter 而不是正弦编码短窗口场景两者差距不大可学习编码在小数据上拟合更快。d_model 和 n_features 的关系也值得展开当 n_features 大于 d_model 时proj 层已经在压缩信息模型被迫保留最主要的模态信息这本身是一种正则化当 n_features 远小于 d_model比如单数据集时 n_features1proj 相当于在升维模型有足够容量把单个序列的不同模式分开表达。两种方向都行关键是 d_model 别两头都不靠。资源里这些几千行的 CSVd_model64、n_layers2 已经够用。4.4 训练循环与逐点打分训练循环不复杂AdamW 配 1e-3 学习率是小数据集的稳妥起点加上一个轻量验证def train_reconstruction(model, train_loader, val_loader, epochs30, lr1e-3): opt torch.optim.AdamW(model.parameters(), lrlr, weight_decay1e-4) criterion nn.MSELoss() model.train() for epoch in range(epochs): total 0.0 for x in train_loader: y model(x) loss criterion(y, x) # 重建损失无标签参与 opt.zero_grad() loss.backward() opt.step() total loss.item() * len(x) val_loss evaluate_loss(model, val_loader, criterion) print(fepoch {epoch} train {total/len(train_loader.dataset):.4f} fval {val_loss:.4f})def evaluate_loss(model, loader, criterion): model.eval() total 0.0 with torch.no_grad(): for x in loader: y model(x) total criterion(y, x).item() * len(x) return total / len(loader.dataset)这里的验证不是选模型的依据而是报警器训练 loss 降、验证 loss 反而升说明过拟合或者验证集混进了模型没见过的分布该停下来检查数据。epoch 数量我一般开到 30 就看效果val loss 在 20 个 epoch 后不再下降就直接停强行多跑只会过拟合到正常样本的细节上。逐点打分用窗口最后一个点的误差来对齐序列def pointwise_score(model, loader): model.eval() scores [] with torch.no_grad(): for x in loader: y model(x) err (y - x).pow(2).mean(dim-1) # [B, window] scores.append(err[:, -1]) # 取窗口最后一点 return torch.cat(scores).numpy()为什么取最后一点而不是全窗口平均窗口有重叠同一个时间点会出现在多个窗口里取平均要维护对齐索引代码变复杂取最后一点让每个窗口只产出一个分数时间上自然连续覆盖序列实现最简单实验下来效果没有明显差别。5. 参数调优与避坑排查五个真实翻车记录5.1 阈值怎么定都别扭F1 始终上不去现象模型训完用 99 分位数定阈值告警铺天盖地F1 惨不忍睹。原因监控数据的异常是区间不是点。一个持续 20 分钟的漂移在逐点对比里被计数成几十个“误报”而且 99 分位数对本身波动大的数据集根本压不住噪声。解决评估口径改成“区间命中”——预测的异常点只要落在真实异常区段内就算一次命中阈值用验证集按 F1 搜索不拍脑袋from sklearn.metrics import f1_score def search_threshold(scores, labels, gridnp.linspace(0.5, 3.0, 200)): best_f1, best_t 0.0, grid[0] for t in grid: pred (scores t).astype(int) f1 f1_score(labels, pred, zero_division0) if f1 best_f1: best_f1, best_t f1, t return best_t, best_f1grid 的上下界按分数分位数定我习惯先画出分数分布再圈范围盲选区间容易把最优阈值漏掉。怎么确认是这个坑而不是模型问题把分数按标注区间切成两组画箱线图两组分布明显分开说明模型没问题纯粹是阈值选得差分布重叠才需要回去改模型。5.2 标准化把未来信息泄进训练现象训练 loss 很低验证集表现也不错一上线就崩异常分数分布和训练时完全对不上。原因加载数据时图省事对整段序列一次性做了 mean/std 标准化。测试段的均值和方差进入了训练上下文模型看到的“正常范围”比真实情况窄一截部署时一遇到新分布全变成异常。解决统计量只从训练段拟合验证和测试沿用同一组参数对应 4.2 代码里 fit_mean/fit_std 的传参方式。checkpoint 保存时把这两个值一起存成 json推理端加载模型的同时加载统计量。排查方法很直接分别用整段标准化的分数分布和只按训练段标准化的分数分布画对比图前者异常分数整体偏高且密集后者更平缓基本坐实了泄漏。5.3 滑窗长度对不上异常持续时间现象温度故障那种渐进漂移window 设 16 完全漏检换到 EC2 尖刺window 设 128 又把异常抹平输出几乎恒等于输入。原因窗口太短学不到慢漂移需要的上下文太长则异常信号被窗口内大量正常段稀释重建误差被平均掉。解决先看业务上异常持续多久取异常中位持续时长的 3 到 5 倍做初值再试 64、96、128 几组值画 PR 曲线对比。怎么判断窗口合不合适跑几个 window 值对比异常区间内分数的峰值和正常区间的均值之差差距最大的那个窗口就是最合适的。我在 NAB 这批数据上实验下来window 64 到 128 是稳的范围再往上收益递减。5.4 多模态拼接后特征尺度打架现象把温度、CPU、延迟拼在一起训loss 很快被温度主导CPU 那路的异常几乎检测不出来。原因温度是几十的量级CPU 是 0 到 100EC2 延迟可能是毫秒级小数MSE 损失天然偏向大数值特征量纲不同的模态没有公平竞争。解决每个模态在拼接前单独标准化更彻底的做法是各模态先过各自的 Linear 投影再合并相当于给每个源头一个特征提取入口。这段代码就是把 4.3 里的 self.proj 拆成每模态一个params 增加不多但对多模态场景的提升很直接资源后续想往真正异构多模态升级也正好留了这个口子。确认方法同样简单把各模态单独跑一遍模型记录每个模态异常区间的分数均值如果拼接后的结果明显不如最好的单模态多半是特征尺度在拼接时把弱势模态压没了。5.5 训练 loss 反复横跳不收敛现象30 个 epoch 的 loss 曲线像心电图偶尔直接 NaN。原因最常见是学习率太大加上位置编码没初始化好前几轮梯度爆炸其次是 dropout 设太高小数据上训练不稳定。解决优化器切 AdamW学习率从 1e-3 往下降给 pos 编码补一个 Xavier 初始化dropout 压到 0.1。排查顺序固定成先把位置编码初始化换成 zeros再看 loss如果立刻稳定问题出在 pos 的初始值上如果还是跳那才去动 lr 和 dropout。先看 loss 有没有单调下降趋势再看验证 PR 曲线最后才碰窗口和阈值别一上来就同时改三个参数。6. 换到自己的监控指标上三步迁移与阈值重标定6.1 复用整条管线的三个改动点这份资源最值钱的地方不是模型结构而是整套管线可以直接当模板。换成你自己的监控指标时我一般只动三个地方load_monitor_series 里的列名映射window 参数按 5.3 的办法估以及数据文件路径。模型结构、训练循环、打分函数一行都不用改。6.2 阈值重标定是必做动作换数据集之后旧阈值必然失效。哪怕新旧指标长得再像也必须在验证集上重新跑一遍 search_threshold把 PR 曲线画出来看。迁移完成后我习惯把每个数据集的最优阈值、F1、PR 分数记成一张基线表下次复现同一场景直接查表省掉重复调参。这个习惯救过我很多次——有次我换了台机器重跑相同实验分数分布整体偏移差点以为是环境问题翻出基线表一对比立刻定位到是标准化代码版本不一致而不是模型坏了。从那以后我每次换数据集都强制走一遍“重标定阈值 记录基线”的流程不跳步。这份资源里已经把所有 CSV、源码和教程一起打包好了直接拿去跑一遍比我讲十遍都管用。希望帮到你。本文还有配套的精品资源点击获取