3、异常检测基础：异常类型、挑战与评估指标
在TinyML多变量时序异常检测项目中，我们面对的是来自多个传感器（如加速度计、陀螺仪、温湿度、电流等）的连续数据流。这些数据在时间维度上相互关联，共同刻画设备的运行状态。异常检测的核心任务，就是从这些看似正常但实则复杂多变的数据中，识别出那些“不寻常”的模式。本章将系统梳理异常检测的三大基石：异常的基本类型、工程落地中的核心挑战，以及衡量检测器性能的关键指标。理解这些基础概念，是后续设计特征工程、选择模型架构（如Autoencoder、TinyLSTM）以及部署到MCU（微控制器）前的必要前提。
3.1 异常类型：从点到集合的粒度划分
3.1.1 核心原理：三种异常粒度的定义
在时序异常检测中，根据异常发生的“粒度”和“上下文”，我们将异常划分为三种基本类型。理解它们的区别，直接决定了我们采用滑动窗口的大小、特征提取的方式以及模型输出的解释逻辑。
- 点异常（Point Anomaly）：指某个单一时间戳上的观测值显著偏离整体分布。例如，振动传感器突然出现一个极高的尖峰，随后立即恢复正常。在TinyML场景中，点异常往往对应瞬时冲击、电磁干扰或传感器读数错误。
- 上下文异常（Contextual Anomaly）：指某个观测值在全局范围内可能正常，但在特定的时间上下文（如季节、周期、前序序列）中却显得异常。例如，电机在低速运转时的电流值为2A是正常的，但在高速运转时出现2A则属于异常。这类异常必须结合时间窗口内的前后数据才能判断。
- 集合异常（Collective Anomaly）：指一系列连续的数据点作为一个整体，其行为模式与正常序列不符，但其中单个点可能看起来完全正常。例如，传感器输出从正弦波变为方波，虽然每个点的幅值都在正常范围内，但波形形态的突变属于集合异常。
3.1.2 判断方法：如何识别不同异常类型
在实际项目中，我们通常通过以下步骤来区分异常类型：
- 单点分布检验：计算每个时间戳的残差或Z-score，若超过阈值（如±3σ），标记为候选点异常。
- 上下文窗口分析：对候选点，提取其前后各N个时间步的数据，计算局部均值、方差或频谱特征。若该点偏离局部模式，则判定为上下文异常。
- 序列模式对比：对一段连续序列（如一个完整工作周期），使用动态时间规整（DTW）或形状相似度与正常模板比对，若整体相似度低，则判定为集合异常。
3.1.3 案例拆解：工业泵的三种异常表现
假设我们监测一台工业水泵，传感器包括：振动（Hz）、出口压力（Bar）、电机电流（A）。下表展示了同一台泵在不同故障下的异常类型表现：
| 故障场景 | 振动 | 压力 | 电流 | 异常类型 |
|---|---|---|---|---|
| 轴承局部剥落 | 单次尖峰（12mm/s） | 正常 | 正常 | 点异常 |
| 入口阀门部分堵塞 | 正常波动 | 持续偏低（1.8Bar） | 略升（4.2A） | 上下文异常（压力在低流量工况下异常） |
| 气蚀现象 | 高频噪声叠加 | 剧烈波动 | 波动 | 集合异常（波形形态整体改变） |
从这个案例可以看出，同一设备的不同故障，其异常粒度完全不同。如果我们在模型设计时只针对点异常，就会漏掉气蚀这种集合异常；如果只关注上下文异常，又可能对轴承剥落不敏感。因此，一个实用的TinyML系统通常采用多尺度特征融合：既提取单点的瞬时统计量，也提取短窗口的形态特征。
3.1.4 常见误区与总结
总结：异常类型的选择不是非此即彼，而是根据业务风险和数据特性进行组合。在TinyML项目中，建议先通过可视化或统计检验明确主要异常类型，再针对性地设计特征窗口和模型结构。
3.2 异常检测的挑战：从数据到部署的鸿沟
3.2.1 核心原理：为什么异常检测如此困难
与常规分类任务不同，异常检测本质上是一个极度不平衡的学习问题。正常样本占据绝大多数（通常>99%），而异常样本稀少且形态多样。更棘手的是，异常的定义往往随时间变化——今天认为正常的工况，明天可能因为设备老化而变成异常。在TinyML约束下，这些挑战被进一步放大。
3.2.2 主要挑战清单
| 挑战维度 | 具体描述 | 对TinyML的影响 |
|---|---|---|
| 标签稀缺 | 异常样本难以获取，且标注成本极高 | 无法直接训练监督模型，需用无监督/半监督方法 |
| 非平稳性 | 数据分布随时间漂移（如季节变化、设备磨损） | 模型需要在线自适应或定期更新，但MCU难以承载复杂更新算法 |
| 多变量耦合 | 变量间存在复杂相关性，单变量检测失效 | 需要计算协方差或相关性矩阵，增加内存和计算量 |
| 噪声与缺失 | 传感器本身存在噪声，通信可能丢包 | 需要滤波和插值，但会引入额外延迟 |
| 实时性要求 | 异常发生后需在毫秒级响应 | 模型推理时间必须极短，特征计算不能过于复杂 |
3.2.3 实战场景：部署中的权衡
假设我们要在STM32L4系列MCU（主频80MHz，RAM 64KB）上部署一个振动异常检测模型。初始方案采用LSTM-Autoencoder，输入窗口为128个时间步，每步3个特征。经估算，模型参数量约50K，RAM占用约30KB（含中间激活值），单次推理时间约120ms。这在实验室环境下表现良好，但实际部署时发现两个问题：
- 内存瓶颈：当系统同时运行RTOS任务和通信协议栈时，可用RAM仅剩20KB，导致模型无法加载。
- 实时性不足：设备要求每50ms完成一次检测，120ms的推理时间无法满足。
解决方案：我们进行了以下调整——将LSTM替换为1D-CNN（参数量降至8K，RAM占用8KB，推理时间25ms）；将窗口从128步缩减至64步；将异常判定从“重建误差”改为“特征空间距离”。虽然检测精度略有下降（F1从0.92降至0.87），但满足了部署约束。这个案例说明，在TinyML中，模型性能的取舍必须服从硬件约束。
3.2.4 常见误区与应对策略
3.3 评估指标：精确率、召回率与F1-score
3.3.1 核心原理：混淆矩阵与指标定义
在异常检测中，我们通常将“异常”视为正类（Positive），“正常”视为负类（Negative）。基于预测结果与真实标签，可以得到混淆矩阵：TP（真正例）、FP（假正例）、TN（真负例）、FN（假负例）。由此定义三个核心指标：
- 精确率（Precision） = TP / (TP + FP)，衡量所有被预测为异常的样本中，真正异常的比例。精确率高意味着误报少。
- 召回率（Recall） = TP / (TP + FN)，衡量所有真实异常样本中，被成功检测出的比例。召回率高意味着漏报少。
- F1-score = 2 × (Precision × Recall) / (Precision + Recall)，是精确率和召回率的调和平均，用于综合评估。
3.3.2 判断方法：如何选择评估指标
在TinyML项目中，指标的选择取决于业务场景的代价权衡：
- 高精确率优先：当误报代价高时（如频繁的误报警导致维护人员麻木），应优先提高精确率。例如，数据中心服务器异常检测，误报会导致不必要的停机检查。
- 高召回率优先：当漏报代价极高时（如设备损坏导致安全事故），应优先提高召回率。例如，矿井瓦斯浓度监测，漏报一次可能造成灾难。
- F1-score平衡：当误报和漏报代价相近时，使用F1-score作为综合指标。
3.3.3 案例拆解：阈值调整的完整闭环
我们为一个旋转机械的轴承故障检测系统设定评估流程。初始模型输出一个0~1的异常分数，默认阈值为0.5。在验证集（包含1000个正常样本和50个异常样本）上测试，得到：TP=40，FP=10，FN=10，TN=990。计算得：精确率=80%，召回率=80%，F1=80%。
考虑到该设备停机损失巨大，我们决定提高召回率。将阈值降至0.3后，重新测试：TP=47，FP=35，FN=3，TN=965。此时精确率=57.3%，召回率=94%，F1=71.2%。虽然F1下降了，但漏报从10次降至3次，满足了安全要求。
复盘：这个案例展示了阈值调整的代价。在实际部署中，我们建议绘制精确率-召回率曲线（PR曲线），选择曲线上的“肘部”作为阈值点。同时，要意识到在TinyML中，由于模型输出分数可能不够平滑，阈值调整的粒度需要更精细。
3.3.4 常见误区与总结
总结：评估指标是连接模型开发与业务价值的桥梁。在TinyML多变量时序异常检测中，我们不仅要关注指标数值，更要理解指标背后的物理意义和业务代价。建议在项目启动时，就与业务方明确误报和漏报的代价比，并据此设定评估基准。