基于Transformer的多模态异常检测：从原理到实战的完整落地指南

简介：面向异常检测与深度学习实践者，这份资源以Transformer为核心，演示如何对多模态数据进行异常检测，适用于工业监控、系统运维等需要融合多种信号识别异常的场景。包内共314个文件，以npy数据、txt说明、csv数据集和md教程为主，另有py脚本与json配置，整体体积107.6MB，便于离线学习与实际调试。其中csv数据覆盖机器温度、CPU利用率、网络请求延迟等典型异常样例，npy多为预处理后的多模态特征，教程文档则从环境配置到模型训练逐步拆解，降低了上手门槛。资源内置真实与合成两类数据集，配合源码可直观对比注意力机制在跨模态特征融合中的效果，并完整覆盖数据预处理、模型训练与评估环节，适合想通过完整项目快速掌握异常检测流程的学习者。已有256人学习，也可为相关课题设计提供参考。

1. 基于 transformer 的多模态 anomaly detection（异常检测）：这个资源包帮你把落地时间从两周压到两天

基于 transformer 的多模态 anomaly detection（异常检测）乍看像把 transformer、多模态、异常检测三个热词拼在一起，真做起来才知道它解决的是单一模态模型反复吃亏的硬问题：图像拍出来一切正常，同一个时间窗里的日志却全是异常语义；传感器每个通道都没超阈值，几个通道的组合值却早就离群。这类异常天然定义在多模态的联合分布上，单看任何一个输入都抓不住。标题里的资源包把数据集和教程一起给了，省掉的是最费时间的“数据怎么组织、代码怎么对齐、阈值怎么定”。它适合正在做工业质检、服务器日志监控、金融反欺诈特征工程的工程师，也适合拿公开数据做开题验证的研究生：要的不是再读一篇论文，而是当天能跑出第一个异常分数。

2. 为什么是 Transformer：多模态异常检测的建模逻辑与选型理由

2.1 异常检测为什么需要多模态：单模态的盲区

先看一个我实际遇到过的场景。某条业务链路里 CPU、内存、网络吞吐的曲线都平稳，告警规则一个没触发，但同一时间窗口的登录日志里出现了大量“认证失败”，而且失败来源 IP 分布异常。单看指标，系统一切正常；单看日志，也只是“失败次数偏多”。把两者放到一起看，才能发现是撞库行为：认证失败频率和网络请求突发在时间上高度重合，组合分布明显偏离正常模式。这就是单模态模型反复翻车的地方。

统计学上说得更直白：单模态异常检测捕捉的是单个变量边际分布上的离群点，比如某个指标超过 3 倍标准差；而真正的早期异常往往发生在联合分布上。某个特征的边缘分布完全正常，但 P(x1, x2, ..., xM) 已经落到极小值。你单独建模 sensor、单独建模 log、单独建模 image，每一路都说“正常”，组合起来却早就异常了。多模态异常检测要抓的就是这种联合分布偏移。

在实际工程里，多模态的数据来源通常逃不出这三类：数值型时序（传感器、服务器指标）、非结构化语义（日志文本、工单描述）、视觉内容（监控截图、质检图像）。它们的采样频率不同、特征空间不同、缺失模式也不同。这意味着多模态异常检测的第一道坎不是模型，而是把这三类数据组织成一组可比较的 token 序列。Transformer 恰好提供了统一的序列建模框架，这也是为什么近两年这个方向的实现大多收敛到 transformer 上，而不是传统的 GBDT 加手工特征。

另一个容易被忽略的原因是：工业场景里异常样本极其稀缺。多模态特征加到一起后，即便没有异常标签，也能通过重建误差或密度估计做出有效的无监督异常检测。这对 anomaly detection 的落地非常重要，因为很多系统上线时根本没有标注好的异常数据。你把多模态建模和 Transformer 结合，本质上是在用更丰富的信息做无监督密度估计，而不是在赌某一条规则能覆盖所有故障模式。

2.2 Transformer 注意力机制在跨模态特征融合上的三个关键设计

聊到 Transformer，很多人第一反应是那篇Attention Is All You Need，但直接拿完整编码器-解码器结构做异常检测并不划算。常见做法是只取编码器部分，因为异常检测的任务是“描述正常分布”而不是“生成文本”。在编码器内部，有三个设计直接决定了多模态融合的效果。

第一个是 token 化。图像不是天然的序列，文本也不是。Vision Transformer 的做法是把图像切成 patch，每个 patch 拉平后过一个线性映射变成 token；文本走子词切分器变成 token；传感器时序则按时间窗口切段，每段映射成 token。经过这一步，三个模态变成三个 token 序列，共享同一个 embedding 空间，后面的注意力机制才能跨模态交互。patch size 选多大，直接决定 token 数量，也就决定了注意力计算的规模，这个参数后面会展开讲。

第二个是跨模态注意力。自注意力是序列自己 attend 自己，跨模态注意力则是让一个模态的 query 去 attend 另一个模态的 key-value。具体实现可以是让图像 token 作为 query，日志 token 作为 key/value，让模型自己学习“当前图像区域是否与某条日志语义相关”。和早期拼接相比，注意力的权重是逐样本动态计算的，不是每个模态固定一套系数。这对异常检测尤其关键，因为正常情况下的跨模态关联和异常情况下的跨模态关联往往是不同的，固定权重无法表达这种变化。

第三个是位置编码。传感器数据的时间顺序、图像 patch 的空间位置、日志句子里的词序，这些信息如果不注入 embedding，注意力机制会把所有 token 当成无序集合，模型就丢了时间上下文。对异常检测来说，时间上下文往往比内容本身更重要：某个日志消息在凌晨三点出现和白天出现，含义完全不同。Transformer 里常见的位置编码有正弦绝对位置编码和可学习相对位置编码，多模态场景建议用可学习的，因为不同模态的“位置”语义并不完全相同，让模型自己学比手工设计靠谱得多。

2.3 早期、晚期、中间融合：代码复杂度的分水岭

多模态融合算法在工程上大体分三种：早期融合、晚期融合、中间融合。选型不只影响效果，更直接决定代码结构。

早期融合最简单，把三个模态的特征向量在输入端拼成一个长向量，后面走同一个网络。实现成本最低，但要求各模态特征维度匹配、时间对齐良好，否则某个模态的噪声会被一起灌进模型。晚期融合则是每个模态先独立过一个编码器，最后把编码结果拼接起来做分类或重建。各模态编码器可以完全异构，比如传感器用 1D CNN，日志用 BERT，图像用 ViT，最后融合的只有高层语义。中间融合是在 Transformer 层内部做跨模态注意力，每个模态的序列在每一层都能交换信息，表达能力强，但实现最复杂，调参也最费时间。

我的建议是：从资源包起步时先跑晚期融合，别一上来就上中间融合。因为跨模态注意力一旦效果不好，很难判断是数据对齐问题、还是模型收敛问题、还是学习率设置问题。晚期融合的每一路编码器相对独立，出问题可以先定位到具体模态；等整个 pipeline 跑通、数据验证没问题了，再升级成交叉注意力结构去刷精度。

3. 把数据集和教程包跑通：从解压到第一个多模态异常分数

3.1 先看懂资源包的目录结构：数据、预处理、模型、教程各放哪里

拿到这类 zip，我一般不会急着打开 train.py，而是先把目录结构过一遍。大部分基于 transformer 的多模态 anomaly detection 资源包会按数据、预处理、模型、配置、教程五个方向组织，这样做的原因是异常检测项目里数据预处理代码往往比模型代码更耗时，单独分开能让你快速判断哪部分可以直接复用。

# 解压并查看顶层目录结构 unzip 基于transformer的多模态anomaly_detection.zip -d ./mmad cd ./mmad tree -L 2

常见结构大概会看到：

data/ # 原始数据集：CSV 特征、日志文本、图像目录 preprocess/ # 多模态对齐、切窗、embedding 的脚本 models/ # transformer 模型定义 configs/ # 训练参数和模型参数 yaml tutorials/ # 教程文档或 notebook

先读tutorials而不是先读models，这是很多人的教训。代码里的注释往往是写代码那一刻的理解，教程则通常跟着当前代码更新，能帮你避开 README 不更新导致的“照着跑就报错”问题。数据目录里看到的应当是已经切好的窗口样本，或者带原始时间戳的未切分数据。如果是后者，下一步就要用preprocess里的脚本做对齐和切窗，这是整个流程里最容易被低估的一步。

3.2 最小复现：把多模态数据组织成窗口并训练重建型 Transformer

跑通这套方案的核心是把三个模态的数据组织成一组对齐的窗口，然后喂给一个重建型 Transformer。所谓重建型，就是模型输入一段多模态窗口，输出对这段输入的预测；正常样本因为训练时见过，重建误差小；异常样本因为分布不在训练数据里，重建误差显著变大。这个误差就是 anomaly score。

# dataset.py 的核心逻辑：按窗口长度切分三种模态 import numpy as np import pandas as pd from torch.utils.data import Dataset class MultimodalWindowDataset(Dataset): def __init__(self, data_dir, modalities, window_length=100): # 每个模态都是时间对齐后的序列，长度均为 T self.sensor = pd.read_csv(f"{data_dir}/sensor.csv").values # [T, C_s] self.log_emb = np.load(f"{data_dir}/log_embeddings.npy") # [T, C_l] self.image = np.load(f"{data_dir}/image_features.npy") # [T, C_i] self.window_length = window_length def __len__(self): # 滑窗总数 return len(self.sensor) - self.window_length def __getitem__(self, idx): s = self.sensor[idx: idx + self.window_length] # [100, C_s] log = self.log_emb[idx: idx + self.window_length] # [100, C_l] img = self.image[idx: idx + self.window_length] # [100, C_i] return s, log, img

这段代码里，三个模态在时间上已经对齐，每个窗口长度固定为 100。窗口太长，token 序列膨胀，显存压力大；窗口太短，模型看不到完整的跨模态关联。资源包教程里如果给了推荐窗口长度，先用推荐值跑，不要自己拍脑袋改大。C_s、C_l、C_i分别是三个模态的特征维度，在模型内部会统一投影到d_model维。

模型部分，只需要聚焦在 forward 里的融合逻辑：

# model.py 的简化实现：三个模态分别投影后拼接，再过 transformer encoder import torch.nn as nn from transformers import AutoModelForSequenceClassification # 仅作示例占位 class MultimodalTransformer(nn.Module): def __init__(self, d_model, num_heads, num_layers, dropout=0.1): super().__init__() self.proj_sensor = nn.Linear(sensor_dim, d_model) self.proj_log = nn.Linear(log_dim, d_model) self.proj_image = nn.Linear(image_dim, d_model) encoder_layer = nn.TransformerEncoderLayer( d_model=d_model, nhead=num_heads, dropout=dropout, batch_first=True ) self.encoder = nn.TransformerEncoder(encoder_layer, num_layers=num_layers) def forward(self, sensor, log, image): # 把三个模态投影到同一维度，然后拼成 token 序列 tokens = torch.cat([ self.proj_sensor(sensor), self.proj_log(log), self.proj_image(image), ], dim=1) # [B, L, d_model] out = self.encoder(tokens) # 重建型损失：常用做法是预测传感器原始值 return out

d_model是统一隐藏维度，所有模态投影到这里之后才能互相注意力。num_heads一般建议 8 或 12，并且保证d_model能被num_heads整除。num_layers不要一上来就搭一层，异常检测数据量通常不大，层数太深容易过拟合到正常样本的细节噪声上，反而降低泛化能力。训练循环和普通 Transformer 分类任务基本一致，只是损失函数从交叉熵换成了重建误差。

3.3 三个必调参数：patch size、d_model、threshold

跑通不等于跑好，跑好需要调三个参数：patch size、d_model、异常阈值。这三个参数在代码里位置不同，但共同决定最终能不能用。

先看 patch size。它控制的是单个模态切分成多少个 token。图像切成 patch 时，patch size 越大，token 数越少，计算量越小，但空间细节丢失越多。传感器和日志一般不做 patch，而是整段映射成一个 token，但如果你把窗口长度设得很长，也可以把窗口内部再分段，每段一个 token。这个参数和窗口长度是联动的，总 token 数大约等于三个模态的段数之和。显存不够时优先增大 patch size，而不是缩小窗口长度，因为窗口太短会破坏跨模态关联的时间上下文。

再看 d_model。d_model 太小，模型表达力不足以捕捉跨模态交互；d_model 太大，在小数据上几乎必然过拟合。工业场景常见的多模态数据集，样本量通常只有几万到几十万条窗口，d_model 从 128 到 512 之间做网格搜索即可。每轮训练后看一眼验证集的重建误差分布，如果正常样本和异常样本的分数分布完全重叠，先不要动模型结构，回头检查数据有没有对齐。

异常阈值是最后一道关卡。这里给一个在验证集上自动选阈值的脚本：

# 在验证集上扫描阈值，而不是拍脑袋选 import numpy as np from sklearn.metrics import f1_score scores = np.array(val_scores) # 模型在验证集每个窗口上的重建误差 labels = np.array(val_labels) # 0/1 标签 p95 = np.percentile(scores, 95) # 无标签情况下用 95 分位兜底 for k in [0.8, 0.9, 1.0, 1.1, 1.2, 1.5]: threshold = p95 * k preds = (scores > threshold).astype(int) f1 = f1_score(labels, preds) print(f"threshold={threshold:.4f}, F1={f1:.4f}")

核心逻辑是先取 95 分位作为初值，再乘一组系数扫描。注意阈值不是一个“正常的 95 分位点就万事大吉”的值，因为异常分数受窗口内容影响很大，不同时段分数分布可能整体偏移。更好的做法是取一段最近时间的验证数据重新计算分位数，而不是沿用一个月前的阈值。

提示：异常检测里“AUC 高但线上不可用”的翻车九成出在阈值选择上，这个脚本值得放进你的预测流程。

4. 多模态 anomaly detection 避坑指南：数据对齐、阈值玄学与训练退化

4.1 时间戳没对齐，多模态只是多列数据

现象：训练 loss 正常下降，验证集 AUC 却始终在 0.5 附近徘徊，和随机猜测差不多。折线图看着每天跑得更稳，但异常一个都抓不到。

原因：多模态数据来源不同，采样频率天然不一致。传感器 1Hz 采集，图像 0.2Hz 抓拍，日志是非均匀事件流。多数资源包给的预处理脚本能处理频率问题，但如果你替换成自己的数据集，最容易漏掉的一步就是时间对齐。直接按“第 i 行”拼接三个模态的数据，本质上是按行号对齐而不是按时间对齐，一旦丢包或延迟，行号对齐就全是错位。

解决：把每个模态都重采样到统一频率，然后用时间戳做对齐，而不是行号。日志这类非均匀数据可以用 pandas 的merge_asof取最近一条：

import pandas as pd # sensor 先重采样到固定频率 sensor = sensor.set_index("timestamp").resample("1S").ffill() # 每条日志匹配最近一条传感器读数，direction="backward" 表示取之前最近一条 aligned = pd.merge_asof( logs, sensor, on="timestamp", direction="backward" )

对齐完成后，再按窗口切片才有意义。判断是否对齐成功的快速方法：抽样检查几个异常时间点，看日志时间戳对应的传感器值是否在合理范围。这个检查花五分钟，能省掉后面调试模型的好几天。

4.2 阈值玄学：验证集 AUC 0.95，上线 F1 只有 0.3

现象：模型在验证集上的 AUC 做到了 0.95，看起来完美，但实际运行时的 F1 只有 0.3 左右，误报率被客户直接打回来两次。

原因：AUC 只衡量排序能力，不衡量阈值位置。模型确实把异常窗口排到了前面，但你定的阈值太靠前，导致大量正常窗口被误判为异常。另一个隐蔽原因是数据偏移：线上新数据的正常模式会缓慢变化，三个月前调的阈值放到今天，原来 95 分位的位置已经落到 80 分位。多模态场景下分数分布偏移更明显，因为任何一路模态的分布变化都会被放大到融合分数里。

解决：阈值必须在验证集上按当前数据分布重算，而且每次模型更新后都要重跑一遍，不能沿用上一次部署的阈值。一个工程上务实的方法是保留最近两周的正常样本作为“阈值校准集”，每次发版前重新计算分位数。注意校准集不能和测试集重叠，否则会高估真实效果。

4.3 训练退化：loss 降不动，注意力全落在单一模态上

现象：训练到第 20 轮左右，loss 从 0.01 降到 0.003 后就完全不动了。把注意力权重可视化出来，发现几乎所有 head 都在 attend 图像模态，传感器和日志的 token 几乎没人关注。

原因：这就是网络“偷懒”的典型表现。某个模态信噪比高、重建容易，模型只要把这一路拟合好，整体 loss 就能压得很低，于是它放弃了对其他模态的学习。更麻烦的是传感器这类低信噪比模态正是异常检测最敏感的部分，模型主动忽略它，等于把最重要的信号扔掉了。

解决：给模态 embedding 加随机 dropout，也叫 modality dropout，是这条路线上对抗模态懒惰最常见的做法。训练时以一定概率把整个模态的 token 置零，迫使模型在没有图像信息时也能用日志和传感器完成重建。实现很简单：

import random def apply_modality_dropout(sensor, log, image, p=0.15): if random.random() < p: sensor = torch.zeros_like(sensor) if random.random() < p: log = torch.zeros_like(log) if random.random() < p: image = torch.zeros_like(image) return sensor, log, image

p取 0.15 到 0.2 之间比较稳妥，太大影响正常收敛，太小起不到强迫学习的作用。另一个辅助手段是分模态计算重建损失，三个损失加权相加，权重手工设成接近相等，避免某一个模态的 loss 主导梯度。

4.4 类别不平衡：99% 正常样本，1% 异常样本，模型只会说“正常”

现象：训练完成后把所有测试样本都判为正常，异常召回率为零。看 loss 也很低，模型没什么明显的崩溃迹象，但实际就是全程哑火。

原因：异常检出里标签天然极端不平衡。重建型模型学到的是正常样本的分布主体，异常样本数量太少，对 loss 的贡献微乎其微，模型根本没有动力去为它们留出空间。这不是实现 bug，而是问题本身的特性。

解决：不要直接用原始重建误差当分数，改成标准化残差。先统计验证集正常样本分数的均值和标准差，再把每个测试样本的分数减去均值除标准差，得到类似 z-score 的标准化分数。这样即使绝对分数不高，只要它偏离正常分布足够远，也能被阈值捕获。如果资源包里带了少量异常标注样本，还可以用对比学习的方式做微调：让正常窗口的表示相互靠近，异常窗口的表示彼此远离，这比单纯调阈值有效得多。

5. 进阶用法：用预训练视觉编码器压缩图像模态，把注意力留给跨模态交互

5.1 用 CLIP 或 ViT 预训练编码器提取图像特征，替代大 patch 切图

跑通基础流程后，最值得做的优化是替换图像模态的编码方式。直接把图像大 patch 切进 transformer 会让 token 数量爆炸，图像相关的注意力计算占了几乎全部显存。一个成熟的做法是用预训练视觉编码器把整张图像压成一个固定长度的语义向量，再投影成单个 token 参与跨模态融合。

# 用预训练 CLIP 视觉编码器把图像压缩成 [B, 512] 特征 import torch from PIL import Image from transformers import CLIPModel, CLIPProcessor clip = CLIPModel.from_pretrained("openai/clip-vit-base-patch32") processor = CLIPProcessor.from_pretrained("openai/clip-vit-base-patch32") def encode_image_batch(images): inputs = processor(images=images, return_tensors="pt") with torch.no_grad(): feats = clip.get_image_features(**inputs) # [B, 512] return feats

得到 512 维特征后，过一层线性投影变成d_model维度，然后unsqueeze(1)让每个图像样本变成一个 token。这样整张图像的视觉信息被压缩到一个 token 里，序列长度大幅缩减，跨模态注意力才能真正把计算资源花在“图像语义和日志语义的关联”上，而不是花在图像内部 patch 之间的自注意力上。预训练特征还带了通用视觉先验，这对工业场景中训练数据量少的情况尤其友好。

5.2 快速验证这套流程是否有效：看分数分布、看漏报、看稳定性

最后给你一个我常用的验证习惯。拿到训练好的模型，我不先看单次 AUC，而是看三件事。

第一，画出验证集正常样本和异常样本的异常分数直方图。如果两个分布能分开，说明模型确实学到了多模态信号的判别信息；如果完全重叠，再调参数都是白费，先回去查数据对齐。

第二，统计漏报率，而不是只盯 F1。异常检测最怕漏报，多模态再准，只要漏掉一次关键故障，前面所有工作都会被否定。计算验证集里有多少真实异常窗口被阈值漏掉，漏报率目标控制在 5% 以下。

第三，用最近一周的数据重新校准阈值，对比 F1 变化。如果分数分布整体偏移明显，说明当前窗口长度或特征选择没有跟上数据变化，需要回退到预处理环节调整。

我自己的血泪经验是：这类方案里最容易出问题的永远是数据对齐和阈值选择，模型结构反而是最不需要折腾的部分。拿到任何基于 transformer 的多模态 anomaly detection 资源包，先花半天把数据 pipeline 理清楚、把阈值校准脚本写好，再花半天跑通模型，剩下时间全部留在验证和调参上。希望帮到你。

本文还有配套的精品资源，点击获取