---
title: 半导体设备预测性维护：从规则违反到渐进恶化检测
author: 朱奕樟
date: 2026-04-09
summary: 传统二值关联规则在半导体故障数据上完全失效。通过系统性 DOE，重新定义异常为渐进恶化趋势，最终实现 AUC=0.925 的严格预测性能。
canonical: https://blog.sysu-sam.com/@zhuyizhang/semiconductor-pdm-gradual-deterioration
---

# 半导体设备预测性维护：从规则违反到渐进恶化检测

> **TL;DR**: 我们在一个真实半导体封装工厂数据集上，经历了方法失败、数据审计、系统性实验设计等完整研究过程，最终发现：将异常从"高停机时间"重新定义为"渐进恶化趋势"，并用子系统级时序特征预测，能在严格 rolling-origin 评估下达到 **AUC=0.925 [0.880, 0.962]**，超过所有简单基线 5-16 个百分点。

---

## 1. 问题背景

半导体封装工厂的设备（如 die bonder、wire bonder）会产生各种故障，导致停机。停机一小时可能造成上百万美元损失。我们的目标是：

1. **提前发现**设备正在恶化
2. **告诉工程师**是哪个子系统出了问题
3. 用**可解释的方法**，不是黑箱

数据来自泰国一家半导体封装工厂，涵盖 335 天 × 155 种故障类型的停机记录。

## 2. 最初的想法：关联规则违反（RVAD）

我们最初的方法叫 **RVAD（Rule-Violation Anomaly Detection）**，思路很直觉：

- 从正常运行数据中学习"故障 A 出现时，故障 B 也总是出现"这样的**关联规则**
- 如果某天故障 A 出现但 B 没出现——规则被"违反"了——说明设备行为异常
- 每次报警都能指向具体的规则和设备子系统

在全数据交叉验证下，RVAD 看起来效果不错（AUC ≈ 0.926）。但当我们开始严格审查时，问题逐渐浮现。

## 3. 发现问题：一层层揭开真相

### 问题 1：RVAD = 2008 年的老方法

我们发现，由于所有挖掘出的规则 lift 值完全相同（9.24），RVAD 的"加权评分"退化为简单的"违反计数"——这和 2008 年 Narita & Kitagawa 提出的 Outlier Degree 完全等价。

### 问题 2：好结果来自元数据

进一步排查发现，AUC=0.926 **完全来自 5 个元数据列**（Production time, Operation time 等），而不是真正的故障规则。真正的故障关联规则（如 Unloader Lift → Unloader Turn）AUC 只有 **0.455**——比随机还差。

### 问题 3：异常天分布极端不均

34 个"异常天"中，**29 个集中在 2020 年 12 月**（一次持续性设备故障事件），测试期只有 2-3 个正样本。这意味着全数据 CV 看起来好，只是因为模型记住了 12 月。

### 根本原因

**这个数据集的异常是由故障持续时间决定的，不是由故障共现模式决定的。** 二值化（有/无）丢失了最关键的"多严重"信息。

## 4. 系统性实验设计（DOE）

我们从头开始，系统搜索什么能 work：

| 维度 | 尝试的变体 |
|------|----------|
| 特征工程 | 原始时长、Z-score、log、rank、百分位 |
| 聚合方式 | 逐故障、逐子系统、PCA |
| 时间建模 | 无 lag、lag 特征、滚动统计、指数衰减 |
| 模型 | 阈值、IsoForest、XGBoost、Autoencoder |
| 规则类型 | 存在规则、严重度规则、残差规则 |

关键发现：所有纯故障级方法在没有 lag 的情况下全部失败。简单的 Rolling Z-score 在原始异常定义下 AUC=0.942——最简单的方法最好。

## 5. 突破：重新定义异常

关键洞察：**问题不在方法，在异常定义。**

| 异常定义 | 含义 | 能预测? | trivial baseline |
|---------|------|---------|-----------------|
| 高停机 (P90) | 今天停机多 | 部分 | total downtime = AUC 1.0 |
| Z-score 突增 | 今天比最近突然多 | 否 | Z-score = AUC 1.0 |
| **渐进恶化** | **连续几天趋势上升** | **是** | **没有 trivial baseline** |

我们选择了 **G2 定义**：3 天滚动均值持续上升且高于历史中位数。

物理含义：工程师关心的不是"今天停了多久"，而是"**设备是不是在持续恶化**"。

这个定义的优势：
- **70 个异常天**均匀分布在 **11 个月**
- 是"趋势"而非"绝对值"，天然需要多天信息
- **可预测**：如果昨天和前天都在恶化，今天大概率继续

## 6. 最终方法：子系统恶化趋势预测

### 三层可解释特征

只用 t-1 及更早的数据（真正的提前预警）：

| 层 | 特征 | 数量 | 作用 |
|----|------|------|------|
| 时序趋势 | lag、rolling mean/std、delta、trend | ~15 | 捕捉总体趋势 |
| 子系统结构 | 7 子系统的 lag、rolling mean、变化量 | ~35 | 定位哪个子系统在恶化 |
| 跨子系统偏差 | Ridge 残差（预测每个子系统 vs 实际） | ~8 | 检测子系统间关系异常 |

### 子系统聚类

通过 Ward 层次聚类（Jaccard 距离）将 39 个活跃故障类型分成 7 个物理子系统：

| 子系统 | 故障数 | 代表性故障 |
|--------|--------|----------|
| Sub 1 | 13 | Bar Feed Motor, Index Unit |
| Sub 2 | 4 | Bar Feed Drum, Section |
| Sub 3 | 6 | Bar Feed Motor, Image Sense |
| Sub 4 | 2 | Frame Feed Motor M208/M207 |
| Sub 5 | 4 | Bar Feed Drum Drive Motor |
| Sub 6 | 2 | Frame Push Out, LF Unloader |
| Sub 7 | 8 | Leadframe Notch Cut, Frame Jamming |

### 为什么比简单趋势好？

Simple 3-day trend（只看总量趋势）AUC=0.876。我们的方法 AUC=0.925，多出的 **5pp 来自子系统特征**——模型学到了"不只是总量在升，还要看哪些子系统在升"。

## 7. 实验结果

### 严格评估协议

- **Rolling-origin 时间序列评估**：训练到第 t 天，测试第 t+1 到 t+10 天
- **只用 t-1 及更早特征**：不看当天数据
- **所有预处理在 fold 内重建**：无信息泄漏
- **Bootstrap 95% 置信区间**：2000 次重采样

### 主要结果

| 方法 | AUC | 优势 |
|------|-----|------|
| Yesterday's total downtime | 0.761 | baseline |
| Yesterday's Z-score | 0.836 | +7.5pp |
| Simple 3-day trend | 0.876 | +11.5pp |
| **Our method (XGB + 子系统特征)** | **0.925 [0.880, 0.962]** | **+16.4pp** |

### 详细指标

$$\text{AUC} = 0.925, \quad F_1 = 0.719, \quad P = 0.719, \quad R = 0.719$$

- 测试样本：155 天，32 个正样本
- 5 个随机种子的 AUC：0.919 - 0.925（极其稳定）

### 特征重要性

| 排名 | 特征 | 重要性 | 含义 |
|------|------|--------|------|
| 1 | trend3 | 0.183 | 近 3 天总量趋势 |
| 2 | s3_lag1 | 0.082 | 子系统 3 昨天停机 |
| 3 | resid_lag1 | 0.058 | 跨子系统残差 |
| 4 | lag1 | 0.048 | 昨天总停机 |
| 5 | s2_lag2 | 0.030 | 子系统 2 前天停机 |

### Lead-time 分析

| 提前天数 | AUC |
|---------|-----|
| 0（用昨天预测今天） | 0.925 |
| 1（用昨天预测明天） | 0.799 |
| 2 | 0.743 |
| 3 | 0.663 |

## 8. 案例：2020 年 12 月持续性故障事件

2020 年 12 月 2-30 日，工厂经历了一次持续 29 天的设备严重故障事件。停机时间从正常的约 100 分钟/天暴增到 2000-2700 分钟/天。

使用不包含 12 月数据训练的 IsoForest，检测这一事件 **AUC = 0.967**。异常分数在 12 月 3 日（事件第二天）飙升至 z=7.1，实现了一天内报警。

## 9. 研究历程

这个项目的真实过程：

1. 最初：RVAD 看起来 AUC=0.926
2. Codex 审查：发现表格矛盾、评估泄漏
3. 重跑实验：RVAD=OD，好结果来自元数据
4. 尝试改进：多层规则、软严重度——全部失败
5. DOE 搜索：30+ 种方法组合
6. 发现根因：12 月事件主导，异常定义不合理
7. 重新定义异常：从"高停机"到"渐进恶化"——突破
8. 最终验证：严格 rolling-origin，AUC=0.925

**80% 的时间在发现"什么不 work"，20% 在找到"什么 work"。** 但正是这个过程让结果站得住脚。

## 10. 下一步

- 重写论文，目标期刊：**Computers & Industrial Engineering (Elsevier)**
- 补充 SHAP 可视化案例分析
- 与 Phongmoo et al. (2025, C&IE) 直接对比

---

*本文来自 AI Cube Lab 半导体预测性维护项目。数据来源：泰国半导体封装工厂，335 天实际运行记录。*