当前位置：首页 > 随笔复盘 > 正文内容

半导体时序数据异常检测：Transformer实战调参

叶志辉5天前随笔复盘1

[公开] 半导体时序数据异常检测：Transformer实战调参

【摘要】把Transformer用到刻蚀腔体时序异常检测上，第一版效果还不如三倍标准差。本文完整复盘从事件级F1零点四一到零点七八的调参过程，讲清窗口长度、patch划分、RevIN归一化、关联差异损失与阈值确认策略的选择依据，并给出可直接复用的超参数配置表与评估口径。

分类：半导体AI融合 | 发布：2026-08-16 | 首发：半导体智能制造博客

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

去年我们启动了一个刻蚀腔体异常预警项目，目标是在腔体状态劣化到影响良率之前提前发现。数据条件不错：八台刻蚀机、每台三十七个传感器通道、采样率一秒一次、六个月的历史数据，加上工程师人工确认过的一百四十七个异常事件标签。团队一致认为这是深度学习的理想场景，直接上了Anomaly Transformer。

第一版结果非常打脸。在事件级评估口径下F1只有零点四一，而作为基线的三倍标准差加连续三点规则跑出来是零点五三。也就是说，一个上世纪的统计规则打败了当时最热的深度模型。评审会上有人直接问，那我们为什么要花两个月做这个。

这个问题问得对。后来我们花了三个月做系统性的调参和方法改造，最终把事件级F1做到零点七八，平均提前预警时间二十二分钟。这篇文章不讲论文里那些漂亮的公式，只讲我们踩过的坑和每一次调整背后的判断依据，包括那些试了之后发现没用的方向。

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

Transformer做时序异常检测的主流思路是重构式，即让模型学会重建正常数据的模式，重构误差大的片段判为异常。Anomaly Transformer在此基础上加了一个关键设计，叫关联差异。它的假设是：正常点的注意力会广泛分布在整个序列上，形成所谓的序列关联；而异常点因为与周围的相似度更高、与远处的关联更弱，注意力会集中在邻域，形成先验关联。两者的KL散度就是异常判据，与重构误差组合成最终分数。

这里有个容易被忽略的前提：上述假设成立的条件是异常足够稀疏且局部。半导体设备的时序异常有很大一部分是缓慢漂移型的，比如腔体壁沉积物累积导致的压力基线逐周上移。这类异常在任何一个窗口内看都是正常的，跨越几十个窗口才能看出趋势。用窗口级重构的思路去抓漂移型异常，本质上是方法与问题不匹配，调参调不出来。这是我们第一版失败的根本原因之一。

另一个必须理解的机制是归一化。设备时序数据存在明显的非平稳性，PM之后基线会跳变，换气瓶、换靶材、换腔体件都会造成分布漂移。如果直接用全局均值方差做标准化，训练集和推理时的分布不一致，模型会把正常的基线切换判成异常。可逆实例归一化是针对这个问题的常用解法，做法是对每个输入窗口单独做归一化，把统计量记下来，输出时再逆变换回去。它相当于让模型专注学习形状而不是绝对水平，对我们这类数据帮助很大。

最后是评估口径。时序异常检测领域有一个长期被诟病的做法叫点调整，简单说就是只要一个异常段里有任意一个点被检出，整段都算检出成功。这个口径会把指标虚高到离谱，很多论文里零点九以上的F1用严格口径重算会掉到零点四以下。我们从一开始就规定用事件级F1，即一个连续异常段算一个事件，检出时刻必须落在事件起点之后、结束之前，且允许的提前窗口单独统计。口径必须先定死，否则调参就是自欺欺人。

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

目前工厂里做设备时序异常检测大致有三档做法。第一档是统计规则，三倍标准差、EWMA、CUSUM加上Western Electric那套判异准则，优点是可解释、免训练、工程师信任度高，缺点是只能看单变量，无法捕捉多传感器之间的关系异常。我们厂在项目之前用的就是这一档，覆盖了大约六十个关键通道。

第二档是传统机器学习，孤立森林、单类支持向量机、主成分分析残差这些方法能处理多变量，计算开销小，在中等维度下效果稳定。它的短板是对时序结构的建模能力弱，本质上是把窗口拍平成特征向量，顺序信息大量丢失。对于那些依赖时间形态的异常，比如升压曲线的斜率变化，这一档识别不出来。

第三档是深度学习，LSTM自编码器、TranAD、Anomaly Transformer、以及近两年被反复讨论的线性模型基线。这一档理论上限最高，但对数据量、标签质量、工程能力的要求也最高。需要特别提醒的是，学术界已经有多篇工作指出，在多个公开数据集上简单的线性模型能打平甚至超过复杂Transformer，这说明深度方法的收益高度依赖数据特性，不能默认它一定更好。

公开数据集与Fab真实数据的差异也值得一说。常用的服务器监控和航天遥测数据集，异常占比通常在百分之四到百分之十，而我们的产线数据异常占比低于千分之三。异常越稀疏，评估指标的方差越大，随机波动就可能造成零点零五以上的F1差异。这意味着调参时如果只跑一次实验就下结论，很可能是在拟合噪声。

四、瓶颈问题：卡在哪里

第一个瓶颈是标签稀缺且不精确。六个月数据里只有一百四十七个确认事件，而且工程师标注的时间戳通常是发现异常的时刻，不是异常真正开始的时刻，两者可能差几十分钟。我们抽查了二十个事件，回溯波形发现平均有十八分钟的标注滞后。用这样的标签直接算F1，会系统性低估模型的提前发现能力。

第二个瓶颈是窗口长度与工艺步长不匹配。刻蚀recipe通常由五到十二个step组成，每个step的时长从八秒到一百二十秒不等。我们第一版直接用了论文里的默认窗口长度五百一十二个采样点，相当于横跨了整个recipe甚至跨到了下一片晶圆。模型在这么长的窗口里同时看到了多个完全不同的工艺阶段，重构任务变得极难，误差自然一直很大，导致阈值必须放得很宽，漏报大量增加。

第三个瓶颈是概念漂移。PM之后腔体状态刷新，各通道基线整体偏移，模型在PM后的头两天误报率会飙升到平时的四到六倍。工程师被这批误报折腾了两周之后就开始忽略告警，这几乎是所有预测性维护项目的死法。

第四个瓶颈是多通道量纲与噪声水平差异巨大。压力通道单位是毫托，数值在几到几百之间；射频反射功率单位是瓦，数值在零到几十；温度通道变化极慢且平滑。直接把三十七个通道拼在一起送进模型，损失函数会被数值大、噪声大的通道主导，那些真正有预警价值的平缓通道贡献几乎为零。

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

针对窗口问题，我们改成按工艺step切分而不是固定长度滑窗。从设备日志里解析出step边界，对每个step单独建窗口，窗口长度取该step典型时长的一点五倍，不足的补齐、超出的截断。这样模型面对的每个窗口内部工艺条件一致，重构任务难度大幅下降。实际配置上，主力step的窗口落在一百八十个采样点，patch长度设为十六，即每个窗口划分成十二个patch送入注意力层。这一项改动单独带来了零点一一的F1提升，是所有改动里收益最大的。

针对非平稳与漂移，我们加了可逆实例归一化，并且把PM事件作为显式特征输入。具体做法是增加一个距离上次PM的小时数通道，做对数变换后拼接到输入里。同时在训练集构造上，刻意保留PM后头两天的数据作为正常样本参与训练，让模型见过基线切换的形态。这两项组合下来，PM后误报率从平时的四到六倍降到一点三倍，基本可以接受。

针对通道差异，我们做了分组建模而不是全部堆一起。按物理意义把三十七个通道分成压力气流组、射频功率组、温度组、位置与阀门组四组，每组单独训练一个模型，最后在分数层做加权融合。分组之后每个模型的输入维度降到八到十二，训练更稳定，而且可解释性大幅提升，告警时可以直接告诉工程师是哪一组出了问题。权重我们用验证集上各组的单独F1做归一化后确定，压力气流组权重最高。

模型超参数最终配置如下：模型维度六十四，注意力头四个，编码层两层，前馈维度一百二十八，dropout零点一，批大小一百二十八，学习率一乘以十的负四次方配合余弦退火，训练一百轮但用早停策略，耐心值十轮。损失函数是重构均方误差加上关联差异项，权重系数取三。这里要说明的是，我们试过把模型维度提到二百五十六、层数提到四层，验证集F1不升反降零点零六，典型的小数据集过拟合。深度模型在工业场景往往需要往小了调，这与很多人的直觉相反。

阈值策略上，我们没有用固定阈值，而是用验证集上正常样本分数的百分之九十九点五分位数作为基础阈值，并要求连续三个窗口超阈值才触发告警。连续确认这一条把误报量压掉了六成以上，代价是平均延迟增加约四十秒，这个代价在预测性维护场景完全可以接受。此外每台机台单独维护自己的阈值，每两周用最近数据滚动重算一次，重算结果需要人工确认后生效。

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

完整的迭代过程我们留了记录，这里按版本列一遍。v1是论文默认配置，窗口五百一十二、模型维度五百一十二、三层编码器，事件级F1零点四一，训练一轮要十七分钟，调参效率极低。v2把模型维度降到一百二十八、层数降到两层，F1提升到零点四九，训练时间降到五分钟，这一步说明模型容量过剩是真实存在的问题。

v3引入可逆实例归一化，F1到零点五六，首次超过三倍标准差基线的零点五三。v4改成按step切窗口，窗口长度一百八十，F1跳到零点六七，是单项收益最大的改动。v5做通道分组建模加分数融合，F1到零点七三。v6引入连续三点确认与分位数阈值，F1到零点七八，同时误报量下降六成。v7我们尝试加入跨机台迁移学习，用其他七台的数据预训练再在目标机台微调，F1只提升零点零一，考虑到工程复杂度，最终没有采用。

还有几个试过但没效果的方向也值得记录，免得后来人重复踩坑。一是加入更长的历史上下文，试过把前一片晶圆的统计量作为条件输入，F1无明显变化，推测是相邻片之间的相关性已经被基线归一化吸收了。二是用对抗训练增强鲁棒性，训练不稳定且收益不明显。三是把标签直接用于有监督微调，因为标签只有一百四十七个且时间戳有偏差，微调之后模型学到了标注习惯而不是物理异常，验证集表现反而下降。

工程落地上，推理服务部署在产线侧的一台GPU服务器上，单次推理延迟约十二毫秒，八台机台三十七通道全量跑一遍不到两秒，完全满足一分钟一次的调度频率。告警通过消息队列推送到现有的设备管理平台，与既有的统计规则告警合并展示，并标注来源模型与置信度，让工程师可以对比两套判据。

七、实施效果：数据说话

上线运行五个月，共触发有效预警六十三次，其中四十九次经工程师确认为真实的腔体状态劣化，误报十四次，事件级精确率零点七八，召回率零点七七。相比原来的统计规则，召回率提升了二十六个百分点，而告警总量只增加了不到两成，这个投入产出比是可以接受的。

预警提前量是这个项目最有价值的产出。四十九次真实预警中，有三十七次是在良率或者关键参数出现可见偏移之前发出的，平均提前二十二分钟，最长的一次提前了一小时四十分钟。按我们厂的节拍，二十二分钟大约相当于四到六片晶圆，如果异常持续到被常规量测发现，损失通常在十五片以上。五个月累计减少的报废估算在两百二十片左右。

还有一个附加收益是知识沉淀。分组建模让告警具备了初步的定位能力，五个月里压力气流组占了告警的百分之五十一，射频功率组占百分之二十九。设备团队据此重新评估了腔体清洗周期，把原来固定的两百片一清改成按压力组异常分数动态触发，平均清洗间隔从两百片延长到两百六十片，同时异常次数没有增加，等于额外省下了一部分停机时间。

八、常见问题答疑

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

A：经验值是单机台至少两个月的连续数据，且要覆盖至少两个完整的PM周期，否则模型没见过基线切换。异常标签不需要多，因为主流方法是无监督重构，标签只用于阈值标定和评估。

Q：为什么不直接用有监督分类？

A：异常占比低于千分之三，正负样本极度不平衡，而且异常形态五花八门，有监督模型只能学到训练集里出现过的那几类。无监督重构学的是正常模式，对未见过的新异常有泛化能力。

Q：模型上线后需要多久重训一次？

A：我们的做法是阈值每两周滚动重算，模型每季度重训一次，另外在腔体大修、换关键部件、recipe重大变更之后强制触发重训。重训后必须先影子运行两周再切换。

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

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

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

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

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

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

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

十、配图：数据可视化

图1：刻蚀腔体压力时序与异常检测阈值

图2：时序异常检测数据处理与推理流程

十一、Transformer时序异常检测关键超参数配置表

十二、模型迭代版本与效果对比表

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

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

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

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

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

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

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