企业官网建设流程全解析

干PHM这行最难受的事，很多时候不是算法收敛慢，也不是设备掉线了，而是你的故障样本根本不够用。我做重大装备健康管理这几年，风电齿轮箱、压缩机、大轴承试验台挨个伺候过，最常见的局面是：健康数据一天就能灌好几个G，故障样本攒了半年还是只有那几十个窗口。设备长时间不出故障，本来是该庆祝的事，但机器学习不这么想——它只会把多的一类学到滚瓜烂熟，然后在真正出故障的时候，用健康模式的参数给你一个"看起来正常"的预测。这就是PHM场景里最经典、也最扎心的数据不平衡问题。Feature-level SMOTE，就是我在这个背景下试了一圈之后最终留用的方案：把原始信号先抽成特征，再在特征空间里做SMOTE合成少数类样本。这套流程把故障识别率从勉强及格拉到了能上线部署的水平，今天就把完整的思路、步骤和踩过的坑一次说清楚。

1. 为什么PHM场景一定要先解决样本失衡

1.1 故障数据稀缺，不是算法懒，是行业结构决定的

重大装备的正常运行时间天然远大于故障时间。一台风机齿轮箱设计寿命二十年，大部分时间都在平稳运行；液压系统、轴承、齿轮这些部件，从出现轻微退化到彻底失效，往往只有几天甚至几小时的可观测窗口。加上现场普遍采用定期维护策略，很多设备还在"轻度异常"阶段就被直接换掉了，根本没有记录到完整的故障演化过程。

这带来的数据分布就是极度偏斜：健康样本可能占99%以上，故障样本不到0.2%。更麻烦的是故障类型之间也不均衡，比如外圈故障样本有三十个窗口，滚动体故障只有五个窗口，内圈故障勉强够用但早期弱故障样本几乎没有。这种情况下，一个二分类器只需要做一件事——把所有样本都判成健康，准确率就能到99%以上。听上去很离谱，但这就是PHM模型上线后最常见的"假健康"问题：训练指标好看，现场却漏报。

1.2 传统手段为什么在装备健康管理里不够用

既然不平衡，很多人第一反应是改样本比例。随机过采样就是把少数类样本复制几遍，模型反复看同一批故障样本，很快会把某些噪声当成特征，过拟合非常严重。随机欠采样直接把多数类丢掉，实验室数据可以这么玩，在装备现场你舍不得——健康样本本身就包含了大量工况变化、转速波动、载荷变化的信息，全扔了等于把设备的"正常行为边界"也扔了。

代价敏感学习是给故障样本加权重，在树模型里效果不错，但遇到深网络或者梯度类模型，权重太大容易把损失函数搞到震荡，训练不稳定。还有一类做法是完全绕开故障样本，用异常检测模型，只看健康数据建模，偏离就报警。这个思路在"零故障样本"场景下是不得不用的备选方案，但实际部署下来误报率偏高的现象很普遍，现场人员每天被无关报警轰炸几次之后，就会对系统失去信任，真正出问题的时候反而不看了。

所以，要解决PHM的数据不平衡，合成数据基本是绕不开的路。而在所有合成方法里，SMOTE又是工程上最成熟、最容易解释的一条路线。问题只在于：SMOTE到底该用在哪个层面。

1.3 既然都用SMOTE，为什么强调Feature-level

传统SMOTE直接在原始样本空间里插值。对表格数据没问题，但对振动信号这种时间序列，直接在波形层面做样本平均，会生成一种没有物理意义的"合成怪波形"。两个真实故障窗口的相位完全不同，冲击发生的时刻一个在波峰一个在波谷，逐点平均之后，冲击特征被抹平，幅值变得软绵绵，频域成分也被搅乱。用这种信号去训模型，等于往训练集里掺伪样本，模型学到的是"故障=一段模糊的波形"，真实故障来的时候反而认不出来。

而Feature-level的含义，是把信号先映射到特征空间，再做插值。一段振动信号经过刻画，变成一组带物理语义的特征向量，比如峭度、峰值因子、边频带能量、包络谱特征频率幅值等。两个故障特征向量之间插值，生成的实际上是"故障形态的中间状态"，在物理上是讲得通的——早期故障的峭度介于健康和明显故障之间，这才是我们真正想要合成的样本。特征空间把原始信号的相位、噪声、幅值随机性都过滤掉了，留下的信息更平滑、更连续，SMOTE在里面做插值，天然比在原始信号里做插值稳得多。

2. Feature-level SMOTE的思路拆解：三个核心设计点

2.1 特征空间到底选哪个空间

Feature-level听起来简单，但"特征"这个说法其实可以有很多层。我在实际项目里用过三种，效果和应用场景完全不同。

第一种是手工统计特征，这是工程上最常用、上线最快的方案。从时域、频域、时频域三个维度各取一批特征，拼成一个特征向量。优点是可解释性极强，特征出了问题你能一眼看出是哪个物理量不对，和老师傅聊故障机理时也说得清楚。缺点是特征工程的水平和经验直接决定性能上限，特征选得不好，后面再怎么插值也没用。

第二种是自编码器中间层特征。用健康的和故障的窗口训练一个自编码器，取中间层的低维表示作为特征。这个方案的好处是特征信息密度高，能自动捕捉非线性关系，不需要人为设计太多特征。缺点是计算成本高，且需要一定量的数据才能把自编码器训起来，样本太少或者工况太杂时容易过拟合。我个人的使用经验是，当单类样本达到几千个窗口以上时，自编码器特征才明显优于手工特征，否则还是手工特征更稳。

第三种是频域和包络谱特征。对轴承和齿轮这类带有明确故障特征频率的部件，直接在频谱或包络谱上取特征。比如包络谱中轴承外圈故障特征频率处的幅值、转频谐波的能量分布等。这类特征对早期微弱故障最敏感。如果现场物理机理清楚，我强烈建议在特征组合里加上包络谱特征，并在这些特征上做SMOTE插值，生成的样本比在时域统计特征上插值更接近真实故障的演化路径。

2.2 插值的坐标维度：先降维还是原特征空间直接插值

在特征空间做SMOTE，还有一个隐藏选项：是直接在几十维特征空间里插值，还是先把特征降维到某个低维流形再插值。这个选择直接影响生成样本的质量。

直接在高维特征空间插值的问题是，特征之间往往存在强相关性和冗余。比如峭度和峰值因子在趋势上经常同步上升，如果直接逐维插值，生成的特征向量可能在单维上看着合理，但组合起来破坏了特征间的先验关系。虽然SMOTE只在同类样本间插值，不太会出现跨维度的剧烈冲突，但在高维空间里，欧氏距离的度量会变得不均匀，近邻选取容易被大量弱相关特征干扰。

降维后的做法是先用PCA在主成分空间做插值，再把生成的样本映射回原特征空间。这样做的好处是插值发生在去相关后的坐标系里，主成分的各个维度相对独立，插值过程不会破坏特征间的整体协方差结构。我实测下来，PCA保留90%方差后再插值，生成的样本在后续分类器上的表现比原空间直接插值普遍好两到三个百分点，尤其是当特征维度超过三十维的时候，这个差距会更明显。

2.3 超参数选型：k近邻、生成倍率和变体，怎么定才对PHM的胃口

SMOTE的几个核心参数，在PHM场景下的取值逻辑和常规表格分类完全不一样。先说k_neighbors，默认值是5，这是通用场景的经验值。但在PHM里，如果你某个故障类型的样本量只有十几个窗口，k=5意味着近邻半径很大，每个生成样本几乎都是"整类样本的大杂烩"，多样性很差。我建议的规矩是：少数类样本数在50个以上用k=5，20到50个用k=3，少于20个就不要硬用标准SMOTE了，考虑换成Borderline-SMOTE或者SVM-SMOTE。这两种变体会优先在边界区域合成样本，对少量样本的场景更有针对性。

生成倍率是另一个容易踩坑的地方。很多人一上来就追求1:1完全平衡，少数类生成到和多数类一样多。这在PHM里往往是有害的。因为装备健康管理对误报的容忍度很低，把故障类权重拉得太高，决策边界会向健康类偏移，结果就是无故障时频繁报警，运维人员被迫停设备检查，反而造成不必要的损失。我的实践经验是，先把比例设在0.3到0.8之间，即合成后的少数类数量是多数类的三到八成，然后结合误报代价去调。没必要追求绝对平衡，找到"故障召回率够用、误报可接受"的那个平衡点才是关键。

3. 实操：从振动信号到特征级SMOTE的完整落地流程

3.1 数据准备与窗口切分

整个过程的第一步是数据准备。以工业振动信号为例，采集设备通常是加速度传感器加采集卡，采样率常见的有12.8kHz、25.6kHz甚至更高。拿到原始连续信号后，不能直接整段丢给模型，得先切窗口。窗口长度一般取信号长度内包含足够多的转频周期，比如50毫秒到100毫秒。在25.6kHz采样率下，1280点或者2560点是一个合理选择。

关于是否重叠，我踩过坑。重叠切窗可以把样本量放大，对于深度学习训练确实友好，但代价是窗口之间的相关性极高。如果后续评估时不做严格的按时间段分组，很容易出现模型在测试集上"偷看"训练集的情况，指标虚高得一塌糊涂。如果特征级SMOTE这个实验的目的是做横向对比，建议先用非重叠切窗，等方案定型后再考虑是否重叠来扩充样本。

切窗完成后，每个窗口要打上标签。健康窗口打0，故障窗口按故障类型打1、2、3等。这部分工作最耗人力，但千万别偷懒直接用设备报警时刻前后一刀切，因为故障从萌芽到报警往往有一个过程，早期窗口中混合了大量过渡态。我建议请现场工程师帮你把故障发展曲线的起始点标注出来，只把明显进入故障状态的窗口标为故障样本，这比多标几个样本重要得多。

3.2 特征提取的特征清单与代码示例

窗口切好之后就是特征提取。这里给出一个我常用的基础特征清单，足够覆盖大多数旋转机械的故障识别需求。

时域特征包括：均方根值RMS、峰值、峰值因子、峭度、偏度、波形因子、脉冲因子、裕度因子。这些特征对冲击类故障特别敏感，比如轴承点蚀、齿轮局部断齿。频域特征包括：主频幅值、主频附近边频带的总能量、频谱重心频率、频率方差。针对齿轮箱和轴承，还需要加上包络谱中故障特征频率处的幅值。时频域特征可以用小波包能量比例，对瞬态冲击也有帮助。

把这些特征组合起来，每个窗口大概能得到20到30维的特征向量。下面是一段我在项目里反复使用的特征提取代码骨架，基于Python和常用的科学计算库。

import numpy as np from scipy import stats, signal def extract_features(window, fs=25600): feats = [] # 时域基本统计 feats.append(np.sqrt(np.mean(window ** 2))) # RMS feats.append(np.max(np.abs(window))) # 峰值 feats.append(np.max(np.abs(window)) / (np.sqrt(np.mean(window ** 2)) + 1e-8)) # 峰值因子 feats.append(stats.kurtosis(window)) # 峭度 feats.append(stats.skew(window)) # 偏度 feats.append(np.sqrt(np.mean(window ** 2)) / (np.mean(np.abs(window)) + 1e-8)) # 波形因子 # 频域特征 freq = np.fft.rfftfreq(len(window), d=1.0 / fs) mag = np.abs(np.fft.rfft(window)) idx_main = np.argmax(mag[1:]) + 1 feats.append(freq[idx_main]) # 主频率 feats.append(mag[idx_main] / (sum(mag) + 1e-8)) # 主频占比 # 可以继续加入包络谱特征、小波包能量等 return np.array(feats)

实际工程中，我还会把这套特征提取封装成类，并把采样率、窗口长度、特征列表写进一个配置文件。这个习惯后面帮了我大忙，训练端和部署端只要读同一个配置，特征口径就永远一致。

3.3 特征预处理与数据集划分的顺序问题

特征向量提取出来后，不能直接喂给SMOTE，先得做一轮质量控制。首先是剔除常数特征，比如某个特征在所有窗口里都是同一个值，说明它没有区分能力，留在里面只会干扰插值和模型训练。其次是处理异常值，传感器断线、通信丢包产生的坏数据，特征值往往是极端离群点，直接用当前窗口的均值替换或者丢弃这一行。

接下来做标准化。这里我特别强调一点：不建议默认用StandardScaler。因为故障特征往往在正常区间很聚集、在异常区间有大尾巴，StandardScaler用均值和方差做归一化，容易被少数离群点带偏。我更推荐RobustScaler，它基于中位数和四分位距，对离群点有天然的鲁棒性，非常契合PHM这么个"故障本来就稀少、但故障样本又能拉高方差"的场景。

还有一个细节值得写明白：数据集的划分顺序一定要放在SMOTE之前。标准流程是，先全量的特征矩阵做train_test_split，用分层采样保证测试集里健康类和故障类的比例和原始一致。然后只在训练集上fit标准化器，再转换训练集和测试集。同样，SMOTE也只允许作用在训练集上。绝对不能先对全量数据做标准化、做SMOTE、再做划分，那样会有信息泄漏，最终得到的评估指标不具备任何参考意义。这个错误我见过很多同行犯，后面在问题章节里详细展开。

3.4 Feature-level SMOTE的代码实现与模型评估

到这一步，核心代码就非常简洁了。下面给出完整的训练流程示例，包含SMOTE、分类器训练和评估。

from imblearn.over_sampling import SMOTE from sklearn.preprocessing import RobustScaler from sklearn.ensemble import RandomForestClassifier from sklearn.model_selection import train_test_split from sklearn.metrics import f1_score, confusion_matrix # X_features: (n_samples, n_features) # y: 0=健康, 1=故障 X_train, X_test, y_train, y_test = train_test_split( X_features, y, test_size=0.3, stratify=y, random_state=42 ) scaler = RobustScaler().fit(X_train) X_train_scaled = scaler.transform(X_train) X_test_scaled = scaler.transform(X_test) # Feature-level SMOTE，合成比例设为多数类的0.5倍 smote = SMOTE(sampling_strategy=0.5, k_neighbors=5, random_state=42) X_train_aug, y_train_aug = smote.fit_resample(X_train_scaled, y_train) clf = RandomForestClassifier(n_estimators=300, random_state=42) clf.fit(X_train_aug, y_train_aug) y_pred = clf.predict(X_test_scaled) print(confusion_matrix(y_test, y_pred)) print("F1:", f1_score(y_test, y_pred))

这里面的关键细节，一是sampling_strategy的语义。当它是一个小数时，表示合成后样本量是多数类样本量的比例；当它是0时表示不做任何过采样。二是k_neighbors的数值，如果你只有几十个故障窗口，我建议改成3，具体原因前面提过。三是随机种子必须固定，否则每次跑出来的生成样本不同，算法对比时没法定位到底是模型改进还是随机扰动带来的提升。

评估阶段，万万不要用准确率做主要指标。健康样本数量碾压一切，准确率随便就是99%加。要重点看少数类层面的混淆矩阵。比如下面这张就是我习惯的展示形式：

对应的两个关键指标：故障召回率TPR = TP / (TP + FN)，健康误报率FPR = FP / (FP + TN)。做PHM项目时，我和客户汇报从来只报这两个数，外加一个F1。F1是召回率和精确率的调和平均，比准确率诚实得多。还有一个指标是G-mean，即两类召回率的几何平均，对不平衡数据也很敏感。多个指标交叉着看，才能判断SMOTE带来的提升到底是真实的，还是仅仅把决策边界往多数类方向推了推。

4. 效果差强人意？大概率是这些坑

4.1 数据泄漏，PHM里的头号杀手

Feature-level SMOTE做得好好的，测试集F1跑出来0.95，一上线现场就拉胯，大概率是数据泄漏。最典型的一种泄漏方式就是先对全量数据做标准化或者做SMOTE，然后再划分训练测试集。这样一来，测试样本的分布信息已经通过标准化器的均值中位数、或者通过SMOTE生成的邻域样本，间接溜进了训练过程，评测结果当然好看，但那是对"已知答案"的成绩。

更隐蔽的泄漏来自特征提取环节。特征提取本身不涉及目标变量，但如果特征提取时用了全序列的统计信息去做归一化，比如用整个信号的最大值做幅值归一化，那么每个窗口都会携带未来信息。这种事在时序数据里太容易发生了，排查起来又极难。我给自己的规矩是：所有涉及全局统计的操作，要么在训练集内完成，要么就完全不归一化，只做逐序列的标准化。

4.2 特征插值生成"物理上不可能"的组合

SMOTE在特征空间插值，虽然比原始信号插值安全得多，但还是可能生成一些物理上说不通的组合。举个例子，某类故障的特征A和特征B在真实样本里基本是正相关，但SMOTE是逐维独立插值，可能在某个合成样本里出现A很高、B却很低的反常组合。这种样本混进训练集，模型就会被灌入错误的先验知识。

我在项目里用了两招来应对。第一招是前面提到的PCA后再插值。主成分空间里的各个维度相关性低，插值不会破坏原有特征间的协方差关系。第二招是插值后做一轮特征合理性筛查。对每个特征，统计少数类真实样本的最小值和最大值，插值生成的样本如果超出这个范围超过一定比例，就把它剔除。这个逻辑相当于在SMOTE后面加了一道"物理过滤器"，虽然会损失一些样本，但剩下的样本质量高得多。做故障识别这种安全敏感任务时，宁可样本少一点，也不能用明显违反物理规律的伪样本。

4.3 故障样本不足10个时，SMOTE也救不了你

这部分要泼点冷水。如果某个故障类型的样本窗口只有五个或者八个，Feature-level SMOTE的效果会非常有限。原因很简单：SMOTE的核心是找近邻插值，五个样本组成的特征空间太稀疏，近邻关系极不稳定，合成样本实际上就是在原始五个点之间反复横跳，多样性几乎没有提升。

遇到这种情况，我的建议是几条腿同时走。第一条，把相似工况、相似结构设备上的故障样本合并。比如同一个风场的多台机组，如果型号一致、转频接近，可以把它们的故障窗口合并起来作为少数类集，但前提是特征分布经过可视化确认没有出现分簇。第二条，在特征提取端下功夫，用无监督预训练加半监督标签传播，把健康样本里那些离群程度极高的窗口筛选出来，由专家确认后补充为弱故障样本。第三条，也是最务实的，别硬上纯数据驱动方案，把SMOTE合成的样本当作初始候选，再由故障机理专家做一轮筛选。人工在十几个候选样本里挑出几个真实的，效果比自动生成三五十个还是要好。

4.4 评估结果被窗口相关性骗了

这个坑我栽过跟头。用重叠切窗把数据量扩大了三倍之后，简单随机划分训练集和测试集，F1飙到0.93，我当时还挺高兴。后来一查，发现同一个故障事件下相邻窗口高度相似，这些窗口被随机分配到了训练集和测试集两边，模型在测试时等于看到了训练样本的"近亲"。实际部署中每个新窗口都是来自未知的故障事件，根本没有这种相关性可以依赖。

正确的评估方式是按事件分组。同一个故障事件产生的所有窗口只能进训练集或者测试集，不能两边都有。在sklearn里可以用GroupKFold，将分组ID设为"故障事件编号"或者"机组编号"。用分组划分重新评估后，同一个项目F1从0.93掉到了0.71。这个差距让我意识到，Feature-level SMOTE要在PHM里真正可信，评估协议先要过关，否则一切方法对比都是空中楼阁。

4.5 决策阈值也要跟着调，不只是调模型

很多人做完SMOTE和分类器训练之后，直接用默认的0.5作为分类阈值。这对PHM场景可能不是最优解。因为SMOTE改变了训练数据的类别分布，模型输出的概率分布会被整体抬高或压低。默认阈值0.5常常导致故障召回率不够，或者健康误报率偏高。

正确做法是用验证集画出精确率-召回率曲线，找到曲线上离右上角最近的点，或者更工程化一点，根据漏报和误报的实际代价找出最佳阈值。比如一次漏报可能带来几十万的停机加维修成本，而一次误报只是几千块的人工检查费用，那么阈值就该往低靠，宁可多报几次也要把漏报压下去。这个决策过程应该在SMOTE合成比例确定之后做，因为不同合成比例下模型输出的概率分布也完全不一样。合成比例、阈值、模型参数，这三者是联动关系，需要一起调。

4.6 多故障类型时，SMOTE的各类别处理策略

装备故障往往不是单一类型。轴承外圈故障、内圈故障、滚动体故障、保持架故障，齿轮的断齿、磨损、点蚀，每种类型样本量各不相同，而且都可能极少。这时候如果直接用多分类SMOTE默认配置，很容易出现某些类别之间的近邻关系混乱。

我的做法是针对每个故障类别单独设置合成策略。样本量足够的类别，用标准SMOTE，k=5；样本量特别少的类别，用Borderline-SMOTE，k=3。生成比例设定上，也不是所有类别统一0.5，而是以"合成后每类样本量达到多数类样本量的60%"为目标，以此来保证决策边界不会过于偏向某一个少数类。多类别场景下，分类器的评估除了用宏平均F1，还要逐个类别看混淆矩阵，防止个别难分类别的提升掩盖其他类别变差的问题。

5. 从"能用"到"好用"：几条压箱底的工程经验

5.1 如何验证SMOTE生成的样本真的有效

一个小技巧，在特征空间用t-SNE把真实样本和SMOTE生成样本一起可视化。如果生成样本和真实样本在降维后混在一起，说明合成样本确实落在真实的少数类分布区域里；如果生成样本聚成一团、明显脱离真实样本的领域，那说明特征空间选得有问题，或者插值策略不合适。

我在三个项目里观察过一个规律：t-SNE重叠度好的情况下，SMOTE引入后在真实测试集上的提升基本都在十个点以上；重叠度差的时候，不仅没提升，甚至会把模型搞晕。这个方法成本很低，却能提前暴露问题，我强烈建议大家在做Feature-level SMOTE之后、训练模型之前，花十分钟看看这张图。

另外，验证时一定要用真实的测试样本，绝对不能用生成的样本来评估。有些新手在合成样本上计算混淆矩阵，得到的结果毫无意义，因为合成样本本来就是从训练集插值得到的，模型见过它们的老祖宗。

5.2 这套方案在剩余寿命预测里怎么延伸

故障分类只是PHM的一部分。重大装备健康管理的另一个大目标是剩余寿命（RUL）预测，这是回归任务，表面上看没有类别信息，SMOTE好像用不上。但实际工程里，我更愿意把RUL预测转成分级健康状态识别来做。

把剩余寿命划分成几个区间，比如健康期、退化初期、退化加速期、失效前。每个区间就是一个类别，退化期和失效前的样本量通常远小于健康期，这正好是Feature-level SMOTE发挥作用的场景。先对RUL区间样本做过采样，再训练多分类器，预测出设备当前处于哪个退化阶段，在此基础上再做一个区间内的RUL回归。这种做法在工程上比直接输出一个连续寿命值更稳健，也更容易让现场运维决策人员理解。

5.3 部署环节最容易忽视的口径一致性问题

模型训练完了，指标也验收了，上线时却经常出现一个尴尬的问题：线上实时推理的结果和离线测试对不上。排查下来发现，训练时的特征提取代码和部署端用的特征提取代码在细节上不一致。比如训练时对窗口应用了汉宁窗，部署端却直接用了原始窗口；再比如训练时采样率是25600Hz，部署端实际采集的采样率被某个工程师改成了12800Hz，特征值完全不同。

这个问题在Feature-level SMOTE的方案里尤其致命，因为SMOTE合成样本对特征分布非常敏感，特征口径一变，模型看到的特征空间整个都变了。我的经验是把特征提取逻辑、窗口长度、采样率、特征名称列表全部写进一份配置文件中，训练端和部署端都读同一份配置。只要配置不改，两端就不会差。每次模型更新时，用一段最近现场采集的数据跑一遍离线模型和在线模型的输出对比，偏差大于某个阈值就立即告警排查。

5.4 公开数据集做预验证，再迁移到自家数据

没有条件私测的时候，我习惯先在公开的轴承故障数据集上验证方案，比如各种公开振动数据集。在这类数据集上，不做任何采样处理时，多分类故障识别的宏平均F1大概在0.87左右；加上Feature-level SMOTE，配合理想的特征组合，宏平均F1能到0.94左右。但这个数字听听就好，不同数据集的故障类型、传感器位置、工况差异太大，公开数据集上的提升幅度只能作为方案有效性的参考，不能作为验收标准。

迁到自己的数据平台时，哪怕都是轴承数据，也要考虑到传感器装测点、转速、载荷的区别。最稳妥的办法是先在目标装备上采集少量真实故障样本，用迁移学习的方法微调特征提取网络，然后把Feature-level SMOTE放在微调后的特征空间里做。这一步做好之后，整个方案才真正从"公开数据集中有效"变成"我的装备上有效"。

我个人在实际操作中的体会是，Feature-level SMOTE不是一个让人眼前一亮的炫技算法，它更像一个沉稳的工程方案。它的价值在于把PHM里"故障样本太少"这个最现实的问题，用一套可解释、可复现、可部署的流程化解掉。比起那些动不动就要换成完整生成对抗网络的方案，我觉得工程上更聪明的做法是把特征工程做好，再配一个恰当的SMOTE变体，先拿到一个扎实的基线成绩，然后在这个基线上逐步迭代。如果你也正在被设备健康管理里的样本不均衡折磨，不妨按这个思路先跑通一版。跑通之后你大概率会发现，整套流程连带把你评估口径、数据泄漏、特征一致性这些老毛病一起规范了一遍，这个副作用可能比SMOTE本身的提升更值钱。