AI赋能制造业的项目复盘：设备故障预测系统的模型选型与部署经验

AI赋能制造业的项目复盘：设备故障预测系统的模型选型与部署经验

一、预测性维护的工程价值

某制造企业的一条产线有200台设备，采用"定期维护"策略——每3个月停机检修一次。每次停机损失约15万元（产能损失+备件+人工）。如果能把定期维护改为按需维护（只在故障前维护），年化可减少2-3次停机。

数据基础：设备PLC采集的运行数据（转速、温度、振动、电流），每秒一条，已积累18个月（约15亿条）。目标是预测"未来24小时内设备是否会发生故障"——二分类任务。

二、模型选型的三轮对比

第一轮：经典ML vs 深度学习

评估三个模型的训练数据和评分：

F1分数差异不大（0.79 vs 0.80），但工程化差异巨大：

• LightGBM：训练12分钟，模型文件2MB，推理1ms
• TFT：训练5小时，模型文件180MB，推理45ms

选择LightGBM。理由是0.01的F1提升不值得付出50倍的训练时间和45倍的推理延迟。在工业场景，模型的简单性和可解释性比0.01的F1分数更重要。

第二轮：特征工程的取舍

工业数据的一大特点是高度周期性。设备在-8:00-18:00和夜间的工作模式完全不同。因此特征工程的含金量远高于模型选择：

def build_features(df: pd.DataFrame, window_sizes: list = [5, 15, 60, 360]) -> pd.DataFrame:
"""构建时序特征"""
features = pd.DataFrame()

# 基础统计特征（每个窗口）
for window in window_sizes:
roll = df.rolling(window)
features[f'mean_{window}'] = roll['vibration'].mean()
features[f'std_{window}'] = roll['vibration'].std()
features[f'max_{window}'] = roll['vibration'].max()
features[f'min_{window}'] = roll['vibration'].min()
features[f'skew_{window}'] = roll['vibration'].skew()
features[f'range_{window}'] = roll['vibration'].max() – roll['vibration'].min()

# 频率域特征（FFT主频率）
features['vibration_fft_peak'] = compute_fft_peak_freq(df['vibration'], window=60)

# 趋势特征
features['vibration_trend_1h'] = compute_trend(df['vibration'], window=60)
features['vibration_trend_6h'] = compute_trend(df['vibration'], window=360)

# 多传感器交叉特征
features['temp_vibration_ratio'] = df['temperature'] / (df['vibration'] + 1)
features['power_current_ratio'] = df['power'] / (df['current'] + 1)

# 周期性特征
df['hour'] = df['timestamp'].dt.hour
features['is_working_hour'] = df['hour'].between(8, 18).astype(int)
features['is_weekend'] = df['timestamp'].dt.weekday >= 5

return features

在60+个特征中，通过LightGBM的特征重要性分析，发现top 5特征贡献了约85%的预测能力：vibration_std_60（振动标准差）、vibration_trend_6h、temp_vibration_ratio、power_range_360、hour_sin。

三、部署架构的非AI挑战

挑战一：推理延迟要求。 200台设备、每秒一条数据意味着需要每秒处理200次推理。LightGBM的1ms推理时间满足要求，但部署架构需要保证：

• 预测延迟P99 < 100ms（包含数据预处理+特征计算+推理+告警判定）
• 系统可用性 > 99.9%（错过1分钟的数据可能错过故障预警）

挑战二：模型更新的在线化。 设备工况随季节变化（夏季温升快，冬季预热长），模型需要持续更新。方案：每月用最新的1个月数据重新训练LightGBM，自动对比新旧模型的F1分数，新模型优于旧模型时自动切换。

挑战三：数据漂移检测。 当设备更换关键部件后，传感器读数的分布会变化——旧模型不再适用。监控方法：计算每日预测结果的分布与训练集分布的KL散度。当KL散度超过阈值时，自动触发针对该设备的模型重训练。

四、实际效果与价值

上线6个月后：

• 提前预警了17次设备故障（其中15次准确，2次误报）
• 减少非计划停机次数：从月均3.2次降至0.8次
• 节省维护成本：约92万元/年（减少了2.4次季度停机）
• 误报率：11.7%（17次告警中2次误报）

误报的代价： 每次误报导致约30分钟的排查时间。以月均0.33次误报计算，年化约4次×0.5h=2h，成本可忽略。

漏报的代价： 发生1次漏报，设备突然故障，停机4小时，损失约5万元。以年化漏报1次计算，损失远小于之前的定期维护方案。

五、总结

设备故障预测的工程落地经验：

• 简单模型（LightGBM）+ 复杂特征工程 > 复杂模型（TFT）+ 简单特征——在工业场景F1差距0.01时，简单模型胜出
• 特征工程的ROI远高于模型调参——传感器数据的domain knowledge比模型选择更重要
• 预测性维护的价值不在"减少所有故障"，而在"减少意外故障"——11.7%的误报率是可接受的
• 模型部署的难点不在AI，在数据管道——每秒200个推理需要稳定的流处理架构
• 需要持续监控数据漂移——设备更换组件后模型可能失效

如果要复制这个方案到其他产线，推荐路径：先用LightGBM跑baseline（1周），然后投入特征工程（2周），最后部署和监控（1周）。4周内可以完成一条产线的建模到上线。深度学习的收益需要在LightGBM无法满足精度要求时才开始显现。