[粉丝专享] 时序异常检测：滑动窗口与统计阈值

【摘要】在上深度学习之前，先把统计方法用到位。本文系统讲解滑动窗口、EWMA、MAD鲁棒阈值、CUSUM在半导体设备时序数据上的适用边界与参数选择，给出误报率与漏报率的量化对比，以及一套可直接落地的Python实现思路。

分类：数据工具 | 发布：2026-08-16 | 首发：半导体智能制造博客

一、背景故事：一次真实的产线事件

两年前我们上过一套设备异常检测系统，供应商方案是LSTM自编码器，宣传材料上的准确率是96%。上线三个月后，工程师们把告警全部静音了。原因很简单：每天推送127条告警，其中真正需要处理的不到8条，误报率超过93%。再好的模型，误报率高到这个程度就等于没有。

后来我们推倒重来，第一版方案没有用任何机器学习，就是滑动窗口加上鲁棒统计阈值，两周开发完成。上线后日均告警14条，真阳性9条，误报率降到36%。工程师开始愿意看告警了。半年后我们才在这个基础上叠加模型，而那时候我们已经积累了足够多的标注样本，模型效果比第一次好得多。

这篇文章讲的就是那套"没有模型的异常检测"到底怎么做。它不炫技，但它是所有时序异常检测项目应该走的第一步。如果统计方法都做不好，直接上深度学习基本上只是把问题包装得更复杂。

二、技术原理：把机制讲清楚

时序异常检测的第一个基本概念是异常的三种类型。点异常（point anomaly）是单个时刻的值明显偏离，比如温度突然跳变；上下文异常（contextual anomaly）是值本身在正常范围内，但在当前上下文中不合理，比如设备在idle状态时射频功率却有输出；集体异常（collective anomaly）是一段连续序列整体偏离，比如腔体压力缓慢漂移了两小时。三种类型需要不同的检测方法，用一种方法通吃是很多项目失败的根源。

滑动窗口的作用是把无限长的时间序列切成有限长的片段，在每个片段内计算统计量。窗口长度是最关键的参数：窗口太短，统计量本身噪声大，容易误报；窗口太长，对突变的响应滞后，而且会把缓慢漂移当成正常基线吸收掉。经验规则是窗口长度取被监控现象特征时间尺度的3到5倍。检测秒级突变用30到60秒窗口，检测小时级漂移用4到6小时窗口。

统计阈值方面，最简单的是均值加减3倍标准差，但它有个致命缺点：均值和标准差本身对异常点极度敏感。一个极端值就能把标准差拉大，导致后续真正的异常反而落在阈值内，这叫掩蔽效应（masking）。解决办法是用鲁棒统计量：中位数代替均值，MAD（中位数绝对偏差）代替标准差。MAD乘以1.4826可以得到与标准差可比的尺度估计，这个系数来自正态分布下的一致性修正。

EWMA（指数加权移动平均）适合检测缓慢漂移。它对新数据赋予更高权重，权重按lambda指数衰减。lambda取0.2到0.3适合检测中等幅度的持续偏移，lambda取0.05到0.1对小幅漂移更敏感但响应更慢。CUSUM（累积和）则是检测微小持续偏移的最优方法之一，它累积每个点与目标值的偏差，当累积量超过决策区间h时报警，对0.5到1倍标准差量级的偏移检测能力远超单点判定。

三、现状分析：多数工厂现在是怎么做的

我们调研过同行的做法，大致三种。第一种是完全依赖设备自带的报警，即设备厂商在控制器里设定的硬阈值。这类阈值通常设得很宽，只在设备要损坏时才报，对工艺质量问题几乎没有预警能力。

第二种是把SPC规则直接套到设备时序数据上。西电规则那八条判异准则本来是为独立同分布的抽样数据设计的，而设备时序数据有强自相关性，采样间隔一秒的温度数据前后相关系数可能超过0.95。直接套用的结果是"连续9点在中心线同侧"这条规则几乎每分钟都会触发，完全失去意义。这是最常见也最容易被忽略的错误。

第三种是直接上深度学习。LSTM、自编码器、最近两年是Transformer。这些方法在有充足标注数据、且异常模式确实复杂时是有价值的，但在多数工厂的实际情况下，问题不是模型不够强，而是数据质量差、标注缺失、以及最基本的统计方法都没用对。跳过统计方法直奔深度学习，通常会在误报率上栽跟头。

四、瓶颈问题：卡在哪里

第一个瓶颈是自相关性。前面提到设备时序数据高度自相关，这会让所有基于独立性假设的方法失效。误报率会远高于理论值，比如名义上3σ对应0.27%的误报率，在强自相关数据上实际可能达到5%以上。这也是很多团队"按教科书做但效果很差"的根本原因。

第二个瓶颈是非平稳性。设备参数会随PM周期、季节温度、耗材寿命而系统性变化。用固定的历史窗口算基线，在PM后立刻会大量误报，因为PM改变了基线水平。这需要方法本身能够自适应基线漂移，或者显式地把PM事件作为分段点。

第三个瓶颈是多变量耦合。一台刻蚀机同时采集上百个参数，单独看每个参数都在正常范围，但它们的组合关系可能已经异常。比如射频功率正常、气体流量正常，但两者的比值偏离了历史模式。单变量方法完全看不到这类异常，需要引入马氏距离或者主成分分析这类多变量方法。

第四个瓶颈是缺乏标注。工厂里真正被记录下来的异常事件很少，而且记录质量参差不齐。没有标注就无法客观评估方法的召回率，只能靠工程师主观判断"这条告警有没有用"。这个问题的现实解法是建立轻量标注机制：每条告警推送时附带三个按钮（有效/无效/待观察），工程师点一下就完成标注，三个月就能积累几百条样本。

五、解决方案：可落地的完整做法

我们的方案是一套分层检测框架。第一层是数据预处理：按设备状态过滤，只保留Run状态下的数据（避免idle期间的无意义波动）；按PM事件分段，每次PM后重置基线；对缺失值做前向填充但限制最大填充长度（超过5个采样点的缺失标记为数据缺失而非填充）。

第二层是单变量检测，针对不同异常类型用不同方法。点异常用MAD鲁棒阈值，阈值取中位数加减3.5倍MAD乘1.4826，这里用3.5而不是3是因为自相关性的补偿。渐变漂移用EWMA，lambda取0.2，控制限取加减2.7倍sigma_EWMA。微小持续偏移用CUSUM，参考值k取0.5倍标准差，决策区间h取4到5倍标准差。三种方法并行跑，任一触发即产生候选告警。

第三层是多变量检测。对每台设备的关键参数组（通常8到15个）做主成分分析，保留累计方差贡献85%以上的主成分，监控两个统计量：Hotelling T方（主成分空间内的偏离）和SPE平方预测误差（主成分空间外的偏离）。SPE往往比T方更敏感，因为新出现的异常模式通常无法被历史主成分描述，会直接体现为残差增大。

第四层是告警融合与抑制。这一层是把误报率压下来的关键。规则包括：同一参数在30分钟内重复触发只推送一次；单一方法触发标记为低置信度、两种以上方法同时触发标记为高置信度；触发后自动查询该设备近期的PM记录和recipe变更记录，如果有对应事件则降级为提示而非告警。这三条规则合起来把日均告警从原始的68条压到14条。

第五层是反馈闭环。每条告警带标注按钮，工程师的反馈写回数据库。每月统计各方法的精确率和召回率，对精确率长期低于40%的规则做参数调整或者下线。这个闭环让系统能够持续改进，而不是上线即巅峰然后逐渐被弃用。

六、实战案例：一个完整的改造过程

讲一个具体案例。2025年3月，CVD-04的SPE统计量在凌晨2点17分开始持续上升，3点05分超过控制限触发高置信度告警（同时MAD和SPE两个方法触发）。系统自动查询发现该设备在前一天下午做过PM，但PM后已经正常跑了11小时，不属于PM后正常波动窗口，因此保留为高优先级告警。

值班工程师收到告警后调取主成分载荷分析，发现SPE增大的主要贡献来自射频反射功率和腔体压力两个参数的关系异常：压力读数正常，反射功率也在规格内，但两者的相关模式偏离了历史。这是典型的单变量方法看不到的耦合异常。

现场检查发现是腔体内的一块shield出现了轻微松动，导致等离子体分布改变。如果不处理，按经验大约再跑6到8小时就会出现明显的膜厚均匀性劣化，影响的批次可能达到120片以上。实际因为提前发现，只停机1.5小时做了紧固处理，没有产生任何不良品。

这个案例后来被我们做成了标准教材，因为它完整展示了分层框架的价值：单变量MAD捕捉到了初步信号，多变量SPE确认了异常模式，告警融合规则排除了PM干扰并提升了置信度，最后主成分载荷分析直接指向了根因参数组合。整个链路从异常发生到现场处置只用了1小时52分钟。

七、实施效果：数据说话

系统上线一年的统计数据：日均告警14.3条，其中高置信度4.8条，低置信度9.5条。基于工程师反馈标注，高置信度告警的精确率为81.2%，低置信度告警的精确率为29.4%。整体误报率从最初LSTM方案的93%降到36%，工程师对告警的响应率（即收到告警后30分钟内有操作记录的比例）从11%提升到76%。

业务效果方面，一年内通过异常检测提前拦截的设备问题共47起，按每起平均避免80片晶圆受影响、单片综合成本1200元估算，年化避免损失约450万元。系统本身的开发投入是两个人三个月，加上服务器资源，总成本不到60万元。

半年后我们在这个框架上叠加了机器学习。做法不是替换统计方法，而是把统计方法的输出作为特征，加上工程师的标注做有监督学习，训练一个告警优先级排序模型。这个模型的作用不是判断"是不是异常"，而是判断"这条异常值不值得工程师现在去看"。上线后高优先级告警的精确率从81.2%提升到89.7%。

回头看，最重要的经验是顺序：先把数据质量做好，再把统计方法用对，再叠加模型。这个顺序反过来做，就会重蹈我们第一次的覆辙——一个准确率96%但没人看的系统。异常检测系统的成功指标不是模型指标，而是工程师愿不愿意点开告警。

八、常见问题答疑

Q：滑动窗口长度到底怎么定？

A：先画自相关图看数据的特征时间尺度，窗口取该尺度的3到5倍作为起点，然后用历史已知异常做回溯测试，在召回率和误报率之间找平衡点。不要凭直觉定，也不要所有参数用同一个窗口，温度和压力的响应时间常数完全不同。

Q：自相关性强的数据能用SPC吗？

A：不能直接用。两种处理方式：一是降采样到自相关系数小于0.3的间隔再套SPC，二是先用时间序列模型（如ARIMA）拟合，对残差做SPC。后者信息损失更小，是我们推荐的做法，但需要定期重新拟合模型参数。

Q：多少数据量才够训练检测模型？

A：统计方法只要两到四周的正常运行数据就能建立基线。深度学习方法通常需要至少三到六个月的数据，而且必须覆盖各种正常工况（不同产品、不同班次、PM前后）。数据量不足时，模型会把没见过的正常工况判为异常。

九、工程落地经验：路线图、分工与验证

角色分工上，数据分析工程师负责规则与阈值的定义和维护，设备工程师负责机台侧数据质量与现场确认，IT/数字化团队负责设备数据采集平台的接口稳定性与性能，生产主管负责处置时限的考核。四方职责必须写进流程文件，否则出现异常时最常见的场景就是三方在群里互相@，而设备参数异常还在继续产出不良。我们的做法是在流程文件里对每类事件写明第一响应人和升级路径，30分钟未响应自动升级到主管。

关于投入产出的测算，很多团队做时序异常检测项目时说不清收益，导致预算被砍。可以用一个简单口径：先统计过去12个月因设备参数异常导致的损失片数与返工工时，折算成金额；再估算改造后可挽回的比例（保守取40%到60%）；投入侧算清人力工时、软硬件采购与后续维护。用这三组数字做一页纸的测算表，比任何技术PPT都更容易通过评审。

数据治理是时序异常检测绕不开的前置条件。半导体产线的数据有三个典型问题：一是同一个异常检出率在不同系统里有不同定义，二是时间戳精度不一致导致跨系统对齐困难，三是设备维护后计数器重置造成数据断层。建议建立一份字段字典，对每个关键字段写明来源系统、采集频率、单位、有效范围和责任人，新人接手时按字典对照，可以少走两三个月弯路。

很多工厂在推时序异常检测时会陷入工具崇拜，认为买了设备数据采集平台或者上了某个平台，问题就自动解决。实际情况是工具只提供了容器，真正决定效果的是工艺知识如何被结构化。我们见过同样一套系统，在A厂三个月出效果，在B厂一年还在调参，差别就在于A厂把老工程师的判断逻辑逐条写成了可验证的规则，而B厂只是把数据搬进了新界面。

验证方法上，建议采用离线回溯加在线影子运行的两段式。先用历史数据回溯，看新方案能否在事后正确识别已知事件，统计召回率与误报率；再在产线上做影子运行，即方案照常输出结果但不触发实际处置，与现有做法并行跑两到四周，对比差异。两段验证都通过后再切换为正式生效，这套流程能把上线风险降到可接受范围。

文档与知识沉淀常被忽略，但它决定了方案能否活过人员变动。建议为时序异常检测建立三份文档：一份是给管理层看的一页纸方案说明，一份是给工程师看的参数与规则手册，一份是给现场操作看的处置卡片。三份文档面向不同读者，语言和详略程度完全不同，不要试图用一份文档覆盖所有人，那通常意味着谁都不看。

与其他系统的接口要提前约定失败语义。设备数据采集平台与MES、SPC、EAP之间的调用，必须明确超时时长、重试次数、幂等键和补偿机制。我们踩过的坑是重试没有幂等保护，网络抖动时同一条设备参数异常记录被写入三次，导致异常检出率统计虚高，追了两天才定位到是接口层重复提交。现在所有写接口都强制带业务唯一键，服务端做去重。

关于阈值的动态化，固定阈值在产品结构单一时够用，但一旦产品组合频繁切换就会失效。做法是按产品族、机台族、班次分层设定，并用滚动窗口定期重算。重算周期建议不短于两周不长于三个月，太短会跟随噪声漂移，太长则跟不上工艺演进。每次重算必须留档，记录重算前后的阈值、依据样本量和批准人，方便后续追溯异常检出率判定口径的变化。

最后是人的因素。时序异常检测的推行本质上是在改变现场的工作习惯，技术方案再完美，如果操作员觉得多了负担就会被绕过。有效的做法是让现场先尝到甜头：优先自动化那些他们最讨厌的重复劳动，比如手工抄表、跨系统复制粘贴、每日报表整理，等信任建立起来，再推进那些需要他们额外配合的环节，阻力会小很多。

落地节奏建议分三个阶段推进。第0到30天是数据打底期，重点是把时序异常检测所依赖的原始数据接通并做质量校验：确认设备数据采集平台侧的数据采集频率、字段口径、时间戳时区是否统一，把异常检出率的历史至少三个月数据导出做基线统计，识别缺失率、异常值占比与采集断点。这个阶段不要急着上模型或上看板，数据口径没对齐前，任何结论都会在评审会上被推翻。

第30到60天是规则固化期。把设备参数异常的判定逻辑从工程师脑子里搬到配置表里，明确每一条规则的触发条件、抑制条件、责任人和处置时限。我们的经验是规则不要一次上太多，先上命中率最高的三到五条，跑两周看误报率，误报率控制在10%以内再逐步扩展。规则一旦泛滥，产线会迅速对告警脱敏，那时候再想恢复信任成本极高。

十、配图：数据可视化

图1：时序异常检测数据处理流水线

图2：滑动窗口统计阈值与超限点识别

十一、时序异常检测方法选型对照表

十二、检测方案迭代效果对比表

十三、配套资料与实战工具

本文配套完整实战工具包，包含文中涉及的测算模板、参数配置表、排查清单与Python脚本，可直接用于工厂落地实施。

点击上方「VIP资源」下载区，免费获取以下五项配套资料（持续更新中）：

产能负荷与瓶颈识别测算表（含机台产能、稼动率、排队时间与节拍分解模板）

洁净室颗粒监控与良率关联分析脚本包（含示例数据与归因模板）

时序异常检测与Transformer调参配置模板（含窗口、阈值、评估口径清单）

SPC自动告警链路配置表与OCAP标准表单（含分级与抑制规则）

MES灾备演练Checklist与工艺窗口margin测算表（含RTO/RPO定级模板）

────────────────────────────────────────

本文首发于博客：半导体智能制造 | MES工程师实战笔记

你遇到过类似的问题吗？是怎么解决的？欢迎在评论区分享你的实战经验，一起交流进步。

标签：数据工具 | 时序异常检测 | 滑动窗口 | EWMA | CUSUM | Python