1. 单棵决策树在现场数据上翻车之后我为什么选择Bagging1.1 故障检测任务里单模型的“高分低能”先说个真实经历。我当时接了一个滚动轴承故障诊断的小项目数据是实验室采集的振动加速度信号分四种状态正常、内圈故障、外圈故障、滚动体故障。一开始我用单棵决策树做分类训练集上准确率轻松到95%以上心里还挺得意。结果把模型拿到另一台设备上实测准确率直接掉到82%而且对“外圈故障”这个类别几乎完全失效——大量误报成正常状态。这个现象太典型了单棵决策树对训练数据的噪声非常敏感稍微换一批数据树的结构就会大改。故障检测场景里振动信号本身噪声大、工况变化多单模型很容易出现过拟合。后来我换成BaggingBootstrap Aggregating同样用决策树做基学习器测试集准确率稳定在93%左右现场表现也远好于单棵树。这就是这篇博文想解决的问题用Matlab实现一个可用于故障检测等场景的Bagging分类预测模型把原理、代码、调参和避坑一次性讲透。适合正在做故障诊断、状态监测、异常分类或者对集成学习感兴趣、想在Matlab里快速上手Bagging的工程师和学生。我用的方法分两层一是直接调用Matlab统计工具箱的fitcensemble适合快速验证二是从零手写一个轻量Bagging框架适合想真正理解机制、或者需要深度定制的人。两套代码我都会给出并说明取舍。1.2 Bagging真正解决的是稳定性问题很多人对Bagging有个误解觉得“不就是训练好几个模型然后投票嘛我多跑几次不就完了”。但这里面有一个关键点Bagging提升的是模型的稳定性而不是单个模型的理论上限。故障检测数据的核心痛点恰恰是稳定性。同一个轴承在不同转速、不同负载下的振动信号差异很大如果模型只看“某一批数据下谁分得最准”到了现场必然水土不服。Bagging的做法是同时训练多个“个性不同”的基模型让它们各自看到不同的数据子集最后用投票把“集体经验”汇合起来。哪怕某些基模型被噪声带偏了少数服从多数也能把错误压下去。从理论上看Bagging降低的是模型的方差。单棵决策树是典型的低偏差高方差模型——它拟合训练数据的能力很强但换个数据集结果波动大。通过自助采样产生多份有差异的训练子集训练出多棵树再平均方差就能被有效摊薄。这个点理解透了后面调参才知道什么该动、什么不该动。2. Bagging的核心机制拆解自助采样、OOB与投票规则2.1 自助采样为什么能降方差Bagging的全称是Bootstrap Aggregating关键在Bootstrap自助采样这一步。假设原始训练集有N个样本每次从里面有放回地随机抽N个出来作为一棵树的训练集。因为有放回同一个样本可能被抽中多次也可能一次都没被抽中。数学上很简单某个样本在一次采样中不被抽中的概率是(1 - 1/N)^NN较大时约等于0.368。也就是说每个基学习器的训练集大约只包含原始数据中63.2%的样本剩下约36.8%的样本就是“袋外数据”Out-of-BagOOB可以免费用来做验证。我最初觉得这就是个数据增广技巧但后来从偏差-方差分解的角度想明白了每个基模型都在略微不同的数据分布上训练它们的误差来源不完全相同。把多个模型的预测结果做平均或投票随机误差会相互抵消系统性偏差则保留下来。这跟“一个人猜三次”完全不是一回事——关键在于数据多样性的引入。2.2 OOB样本是免费的验证集Bagging有个其他集成方法没有的福利每个基模型训练时没用到的那些样本可以直接拿来估计算法的泛化能力完全不需要额外划分验证集。在故障检测项目里现场数据通常来之不易能省一点是一点。OOB错误率的计算方法是对第i个样本找到所有那些在采样时没用到该样本的树用这些树的预测结果投票得到一个样本级别的预测然后和真实标签对比。把所有样本都这样算一遍得到的错误率就是OOB估计。我一般在训练完Bagging后先看OOB错误率再和测试集错误率对照。如果两者差很多说明分布有问题或者过拟合了。在Matlab里fitcensemble训练完成后可以直接用oobLoss和oobPredict得到这个指标非常方便。2.3 手写Bagging的Matlab代码骨架为了让你彻底理解机制我先给一个最小可用的手写版本。这里的基学习器我直接用fitctree也就是Matlab里的单棵决策树。核心逻辑就三步采样、训练、投票。% 手写Bagging核心骨架 function model baggingTrain(X, y, nTrees, seed) N size(X, 1); model.trees cell(nTrees, 1); model.idxUsed false(N, nTrees); % 记录每棵树用了哪些样本用于OOB for t 1:nTrees rng(seed t); % 每棵树用不同的随机种子 idx randi(N, N, 1); % 有放回采样 model.trees{t} fitctree(X(idx, :), y(idx), ... MaxDepth, 10, MinParentSize, 5); model.idxUsed(unique(idx), t) true; end end function pred baggingPredict(model, X) nTrees numel(model.trees); nSamples size(X, 1); votes zeros(nSamples, nTrees); for t 1:nTrees votes(:, t) predict(model.trees{t}, X); end % 简单硬投票返回每一类的得票数 pred mode(votes, 2); end别小看这几十行它把Bagging的精髓都表达出来了。randi(N, N, 1)就是关键每一次抽N个允许重复。预测阶段用mode做多数投票。实际项目里我会把mode改成返回每个类别的得票概率方便后面做阈值移动这个后面章节细说。3. 故障检测数据集的处理特征工程与类别不平衡的实操方案3.1 原始振动数据怎么变成可训练的特征矩阵做故障检测最容易忽视的一步是数据处理很多人的模型效果不行根本原因不在Bagging本身而是喂进去的特征太拉了。我处理轴承振动数据的常规流程是这样的先用滑动窗口把连续信号切成一段一段的样本比如每个窗口256个点相邻窗口重叠50%。然后不是把原始波形直接当特征虽然也能跑但噪声太大、维度太高而是从每个窗口里提取一组统计特征时域特征均值、标准差、峰值、均方根RMS、峰值因子、峭度Kurtosis、偏度Skewness频域特征对窗口做FFT后取频谱的质心、主频幅值、频带能量占比小波包分解后的各频带能量这个我在处理非平稳信号时会用把这些特征拼成一个特征向量比如一行12列。这样原始1万多个信号点就被压缩成了几百个样本×十几个特征的特征矩阵。Bagging在这种中低维特征上表现特别好比直接喂原始波形稳定训练速度也快。有个小坑要提醒特征提取必须在训练集上统一计算参数比如标准化用的均值和标准差只能从训练集里算出来测试集和现场数据都用同一组参数去变换绝不能把测试集也混进来一起算。这是数据泄漏的经典错误很多人栽在这上面。3.2 类别不平衡会让Bagging失效必须这样处理故障检测还有一个绕不开的问题正常样本永远占绝大多数故障样本稀罕得要命。正常状态占了90%以上的情况很常见如果直接训练Bagging里的每棵树看到的都是“大量正常少量故障”投票时正常类天然占优召回率会很难看。我试过几种办法最实用的是这样第一先做类别重采样再进Bagging。对少数类做SMOTE过采样或者对多数类做欠采样把训练集的类别比例拉到一个相对合理的水平比如7:3或6:4。注意只在训练集的内部做验证集和测试集保持原始分布这样评估结果才真实。第二用代价敏感学习。在fitctree里设置Prior参数让少数类的先验概率人为调高。比如实际中故障占5%但建模时把故障类先验设成0.3这就等于人为告诉模型“错分故障样本的代价更高”。我实测下来这个方法比SMOTE更省事效果也不错。第三不要只用准确率做指标。类别不平衡时准确率是骗人的——就算模型把所有样本都判成正常准确率也有90%但这个模型毫无用处。后面会说故障检测真正要看的是G-mean几何平均、F1-score还有误报率和漏报率的组合。3.3 训练集与现场数据分布不一致的问题实验室数据和现场数据永远有差距这是故障检测项目的宿命。我遇到过最典型的情况是实验室数据的采样频率是12kHz现场设备是8kHz训练时候的转速是1800转现场是1500转。模型直接废掉。我的应对思路是在特征层面上尽量保留物理不变性。比如峭度、偏度这类无量纲特征对转速变化没那么敏感频带能量占比也是归一化后的量比绝对幅值稳健得多。另外可以在采集阶段就把运行状态记录下来按不同工况分层采样确保训练集覆盖多个转速和负载条件。如果条件允许还有一个更稳妥的做法把新工况的数据也当成“伪类别”参与训练。比如从转速A来的数据标为类别1~4从转速B来的数据标为类别5~8让模型先学会区分“转速A的内圈故障”和“转速B的内圈故障”这样模型不会把转速差异和故障差异混在一起。这个思路类似于领域自适应里的多源域训练实测效果比单纯堆数据好。4. 完整可跑的Matlab实现工具箱一行代码与手写框架的取舍4.1 基于fitcensemble的最小可用版本如果你装的是Matlab R2013b以上版本统计和机器学习工具箱里已经有现成的集成学习接口不需要自己写循环。最核心的就一行% XTrain: nSamples x nFeaturesYTrain: nSamples x 1 mdl fitcensemble(XTrain, YTrain, ... Method, Bag, ... % Bagging方式 NumLearningCycles, 100, ... % 基学习器个数 Learners, tree, ... % 基学习器用决策树 KFold, 5); % 5折交叉验证这句代码训练完成后mdl本身已经含了交叉验证结果。但注意用了KFold之后返回的是一个ClassificationPartitionedEnsemble对象不是直接用于预测的模型。你需要再拿全量训练数据重新训练一个最终模型或者使用kfoldPredict先看交叉验证表现。我给一个更常用的模板把训练、评估、保存串起来% 主流程 rng(42); % 划分训练测试集 cv cvpartition(YTrain, HoldOut, 0.25); idxTest test(cv); mdl fitcensemble(XTrain(~idxTest, :), YTrain(~idxTest), ... Method, Bag, ... NumLearningCycles, 150, ... Learners, tree, ... ClassNames, [0; 1]); % 明确指定正负类别 % 测试预测 [yHat, score] predict(mdl, XTrain(idxTest, :));这里ClassNames必须显式指定尤其是正负样本都用0/1编码时不指定可能导致预测结果被当成逻辑值或者顺序错乱。我踩过一次这个坑当时类别是1和2没指定ClassNames预测出来全反了排查了很久才发现是类别顺序的问题。4.2 手写框架的模块设计与关键函数工具箱版虽然方便但有两个痛点一是fitcensemble的内部细节不太好改二是没法直观理解每个环节。我在前面的骨架代码基础上扩展出一个完整的手写模块分成了四个函数职责清晰extractFeatures.m从原始信号里提取特征矩阵baggingTrain.m训练Bagging集成内部支持指定基学习器个数、每棵树的深度baggingPredict.m预测支持返回投票概率evaluateModel.m计算混淆矩阵、精确率、召回率、F1、OOB错误率下面是升级版的关键部分重点在预测阶段返回投票概率function [pred, probPos] baggingPredictPro(model, X) nTrees numel(model.trees); nSamples size(X, 1); posVotes zeros(nSamples, 1); for t 1:nTrees classID predict(model.trees{t}, X); posVotes posVotes (classID model.PosClass); end probPos posVotes / nTrees; % 正类投票比例 pred double(probPos 0.5); % 默认阈值0.5 end注意这个阈值0.5不是死的。在故障检测里漏掉一次故障的代价往往比多报一次警更严重我通常会把阈值从0.5降到0.4甚至0.3让模型“敏感”一些宁可多报几次假警也别把真故障漏过去。这个调整在工具箱版本里也有就是predict返回的score第二列取阈值时直接比较分数即可。4.3 故障检测评估指标的完整实现很多初学的人跑完模型只看准确率我要强调故障检测场景下单一准确率没有任何参考价值。我每次必看的是混淆矩阵和一系列衍生指标。function [CM, metrics] evaluateModel(yTrue, yHat) CM confusionmat(yTrue, yHat); TP CM(2,2); TN CM(1,1); FP CM(1,2); FN CM(2,1); precision TP / (TP FP); % 精确率报警里面有多少是真的 recall TP / (TP FN); % 召回率真实故障里有多少被报出来 F1 2 * precision * recall / (precision recall eps); % 误报率正常样本中被误报警的比例 fpr FP / (FP TN); % 漏报率故障样本中未被报警的比例 fnr FN / (FP FN); % G-mean兼顾正常类和故障类 tpr recall; % 真正例率 tnr TN / (TN FP); % 真负例率 gmean sqrt(tpr * tnr); metrics table(precision, recall, F1, fpr, fnr, gmean); end我评估一个故障检测模型是否合格一般看两个标准召回率要大于95%误报率要小于10%。注意不是说越高越好有些项目里报警过于频繁会导致维护人员“狼来了”最后反而不管了。所以调参时我不会一味贪阈值低而是结合误报率一起看找一个可接受的平衡点。5. 调参与避坑实录从训练集95%到测试集同样95%5.1 最容易翻车的五个细节第一随机种子不能乱设。Bagging的结果天然带有随机性如果你不固定随机种子每次跑出来的准确率都不一样。这本身不算错但要命的是你在对比试验时如果种子不固定根本分不清模型改进是真实的还是随机波动。所以我在所有实验里统一rng(42)。第二树的数量不要盲求大。很多人以为NumLearningCycles越大越好其实超过一定数量后准确率就饱和了反而训练时间直线上升。用OOB错误率曲线观察是最好的办法错误率下降开始变缓的位置就是合适的树数量。我做轴承数据时大概50~100棵树就到平台期了。第三决策树的深度要限制。如果每棵树都长到完全纯单个基学习器方差还是大Bagging的稳定性提升有限。我一般在fitctree里设置MaxDepth在5~15之间让每棵树“弱一点”这样集成后效果反而好。太强和太弱之间有一个平衡需要自己用验证集试。第四小心类别顺序出错。前面提到的ClassNames问题我再强调一遍用0/1或者1/2编码时一定要显式指定否则Matlab会按字母序排列类别预测结果可能完全反了。第五不要忽视特征标准化。虽然决策树本身对特征尺度不敏感但如果后续要和SVM、XGBoost这些模型对比必须统一做标准化。我在项目里统一用zscore并且分训练集/测试集计算参数。5.2 误报与漏报的平衡阈值移动故障检测里最真实的场景是模型输出的不是“故障/正常”二值结果而是一个故障概率。生产现场需要一个明确的报警阈值这个阈值怎么定直接影响整个系统的可用性。我通常的做法是画ROC曲线然后根据实际业务成本选阈值。Matlab里可以用perfcurve% 用投票概率画ROC [fpr, tpr, thresholds, auc] perfcurve(yTrue, score(:, 2), 1); figure; plot(fpr, tpr); xlabel(假正例率); ylabel(真正例率); title([ROC曲线, AUC , num2str(auc)]);然后选阈值时我一般不只盯着“离左上角最近”那个点。比如有一个项目客户明确说“我们宁可每周多拆两次设备检查也不能让故障轴承带着隐患转下去”那我就把阈值往低调把召回率干到98%代价是误报率到了15%。反过来如果现场报警太多导致没人信了就得升阈值。这个决策必须和现场业务绑定不能纯靠公式。我还有一个习惯用OOB概率而不是测试集概率来选阈值。因为测试集只有一份反复用同一份数据调阈值会造成对测试集的过拟合。OOB概率对每个训练样本来说都是“见过的树投票”没见过的模型评估更有泛化代表性。5.3 和XGBoost、LSTM等其他模型的实际对比很多同行问我都有XGBoost了还有必要用Bagging吗有LSTM了做时序故障检测不是更好我统一回答各有所长关键看数据规模和业务约束。我自己在同一个轴承数据集上做过一组对比数据量大约是800个训练样本、16个特征任务是四分类故障识别。结果大致如下模型测试集准确率训练时间可解释性备注单棵决策树82%1秒高方差大Bagging决策树基学习器93%8秒较高稳定且够用随机森林94%8秒较高和Bagging接近XGBoost95%20秒较低效果最好但要调参LSTM序列输入87%600秒低样本太少发挥不出来这个结果很能说明问题样本量只有几百时XGBoost的优势并不明显LSTM更是英雄无用武之地而Bagging用很低的成本达到了非常接近最优的表现。LSTM的优势在长序列时间依赖明显的场景但前提是你有足够多的历史数据否则很容易过拟合。需要强调的是这个对比里XGBoost准头略高但实际换一批数据后差距往往就缩小甚至反转了。Bagging对参数不敏感、开箱即用在工业项目里是“最省心的下限保障”。6. 这个框架后续还能怎么扩展6.1 从离线检测到在线监测我最初做的是一次性离线分析后来客户要求做成在线监测每来新的振动数据系统实时判断设备状态。这时Bagging模型面临一个问题——模型是静态的设备状态会漂移。我对策是加一个滑动窗口的在线评估每10分钟产生一批新的特征向量用训练好的Bagging预测如果连续多个窗口报警才触发真正的告警。同时对OOB样本持续监控如果新数据的预测置信度始终很低说明可能出现了模型没见过的工况这时触发“模型更新”信号。这个“报警触发机制”虽然简单但能把误报率再压掉一半。6.2 与时序预测模型结合Bagging处理的是“某个时刻的特征快照”但故障往往是一个发展过程从早期退化到完全失效是有时间规律的。这时候可以考虑把时序信息加进去。我试过的一个思路把连续几个窗口的Bagging预测概率拼成一个时间序列再用一个简单的RNN或LSTM做二次分类判断“当前这段趋势是恶化还是波动”。但如前所述时序模型对样本量要求高如果没有足够的完整故障样本效果反而不如老老实实用Bagging。另一个路子更值得试把时域特征做完之后用Bagging分支处理频段特征用另一个分支处理时序偏移特征最后融合。这种多分支结构在Matlab里用几个独立模型组合就能实现不用深度学习框架也能得到类似效果。6.3 模型更新的低成本方案最后分享一个我最近在用的技巧Bagging模型天然支持滚动更新。因为它的基学习器相互独立当新数据来了时不需要重新训练所有树只需要在现有模型基础上加训练几棵新树或者替换掉表现最差的那几棵树。Matlab里工具箱版的实现是% 用新数据增量更新模型 mdlUpdated resume(mdl, XNew, yNew, NumLearningCycles, 20);手写版更灵活可以自己维护一个树的数组定期用新样本训练新树替换旧树。这样模型能跟着设备状态慢变化走又不会频繁全量训练占用资源。我在实际项目里通常在每天凌晨用当天新积累的数据更新一次模型每次只加10~20棵树更新完自动约束总树数量不超过200。这种模式跑了大半年模型在现场的召回率一直维持在95%以上误报率也比初始版本降低了不少。说到底Bagging这个算法看起来简单但真正用好它功夫都在数据、指标和工程细节上。希望这篇代码和踩坑记录能帮你少走点弯路。后面我会继续整理关于特征自动选择、模型压缩部署的内容。 
长河君 · 2026/10/7 10:55:24 · 阅读 1.2k Matlab实现Bagging集成学习：提升故障检测模型稳定性
1. 单棵决策树在现场数据上翻车之后我为什么选择Bagging1.1 故障检测任务里单模型的“高分低能”先说个真实经历。我当时接了一个滚动轴承故障诊断的小项目数据是实验室采集的振动加速度信号分四种状态正常、内圈故障、外圈故障、滚动体故障。一开始我用单棵决策树做分类训练集上准确率轻松到95%以上心里还挺得意。结果把模型拿到另一台设备上实测准确率直接掉到82%而且对“外圈故障”这个类别几乎完全失效——大量误报成正常状态。这个现象太典型了单棵决策树对训练数据的噪声非常敏感稍微换一批数据树的结构就会大改。故障检测场景里振动信号本身噪声大、工况变化多单模型很容易出现过拟合。后来我换成BaggingBootstrap Aggregating同样用决策树做基学习器测试集准确率稳定在93%左右现场表现也远好于单棵树。这就是这篇博文想解决的问题用Matlab实现一个可用于故障检测等场景的Bagging分类预测模型把原理、代码、调参和避坑一次性讲透。适合正在做故障诊断、状态监测、异常分类或者对集成学习感兴趣、想在Matlab里快速上手Bagging的工程师和学生。我用的方法分两层一是直接调用Matlab统计工具箱的fitcensemble适合快速验证二是从零手写一个轻量Bagging框架适合想真正理解机制、或者需要深度定制的人。两套代码我都会给出并说明取舍。1.2 Bagging真正解决的是稳定性问题很多人对Bagging有个误解觉得“不就是训练好几个模型然后投票嘛我多跑几次不就完了”。但这里面有一个关键点Bagging提升的是模型的稳定性而不是单个模型的理论上限。故障检测数据的核心痛点恰恰是稳定性。同一个轴承在不同转速、不同负载下的振动信号差异很大如果模型只看“某一批数据下谁分得最准”到了现场必然水土不服。Bagging的做法是同时训练多个“个性不同”的基模型让它们各自看到不同的数据子集最后用投票把“集体经验”汇合起来。哪怕某些基模型被噪声带偏了少数服从多数也能把错误压下去。从理论上看Bagging降低的是模型的方差。单棵决策树是典型的低偏差高方差模型——它拟合训练数据的能力很强但换个数据集结果波动大。通过自助采样产生多份有差异的训练子集训练出多棵树再平均方差就能被有效摊薄。这个点理解透了后面调参才知道什么该动、什么不该动。2. Bagging的核心机制拆解自助采样、OOB与投票规则2.1 自助采样为什么能降方差Bagging的全称是Bootstrap Aggregating关键在Bootstrap自助采样这一步。假设原始训练集有N个样本每次从里面有放回地随机抽N个出来作为一棵树的训练集。因为有放回同一个样本可能被抽中多次也可能一次都没被抽中。数学上很简单某个样本在一次采样中不被抽中的概率是(1 - 1/N)^NN较大时约等于0.368。也就是说每个基学习器的训练集大约只包含原始数据中63.2%的样本剩下约36.8%的样本就是“袋外数据”Out-of-BagOOB可以免费用来做验证。我最初觉得这就是个数据增广技巧但后来从偏差-方差分解的角度想明白了每个基模型都在略微不同的数据分布上训练它们的误差来源不完全相同。把多个模型的预测结果做平均或投票随机误差会相互抵消系统性偏差则保留下来。这跟“一个人猜三次”完全不是一回事——关键在于数据多样性的引入。2.2 OOB样本是免费的验证集Bagging有个其他集成方法没有的福利每个基模型训练时没用到的那些样本可以直接拿来估计算法的泛化能力完全不需要额外划分验证集。在故障检测项目里现场数据通常来之不易能省一点是一点。OOB错误率的计算方法是对第i个样本找到所有那些在采样时没用到该样本的树用这些树的预测结果投票得到一个样本级别的预测然后和真实标签对比。把所有样本都这样算一遍得到的错误率就是OOB估计。我一般在训练完Bagging后先看OOB错误率再和测试集错误率对照。如果两者差很多说明分布有问题或者过拟合了。在Matlab里fitcensemble训练完成后可以直接用oobLoss和oobPredict得到这个指标非常方便。2.3 手写Bagging的Matlab代码骨架为了让你彻底理解机制我先给一个最小可用的手写版本。这里的基学习器我直接用fitctree也就是Matlab里的单棵决策树。核心逻辑就三步采样、训练、投票。% 手写Bagging核心骨架 function model baggingTrain(X, y, nTrees, seed) N size(X, 1); model.trees cell(nTrees, 1); model.idxUsed false(N, nTrees); % 记录每棵树用了哪些样本用于OOB for t 1:nTrees rng(seed t); % 每棵树用不同的随机种子 idx randi(N, N, 1); % 有放回采样 model.trees{t} fitctree(X(idx, :), y(idx), ... MaxDepth, 10, MinParentSize, 5); model.idxUsed(unique(idx), t) true; end end function pred baggingPredict(model, X) nTrees numel(model.trees); nSamples size(X, 1); votes zeros(nSamples, nTrees); for t 1:nTrees votes(:, t) predict(model.trees{t}, X); end % 简单硬投票返回每一类的得票数 pred mode(votes, 2); end别小看这几十行它把Bagging的精髓都表达出来了。randi(N, N, 1)就是关键每一次抽N个允许重复。预测阶段用mode做多数投票。实际项目里我会把mode改成返回每个类别的得票概率方便后面做阈值移动这个后面章节细说。3. 故障检测数据集的处理特征工程与类别不平衡的实操方案3.1 原始振动数据怎么变成可训练的特征矩阵做故障检测最容易忽视的一步是数据处理很多人的模型效果不行根本原因不在Bagging本身而是喂进去的特征太拉了。我处理轴承振动数据的常规流程是这样的先用滑动窗口把连续信号切成一段一段的样本比如每个窗口256个点相邻窗口重叠50%。然后不是把原始波形直接当特征虽然也能跑但噪声太大、维度太高而是从每个窗口里提取一组统计特征时域特征均值、标准差、峰值、均方根RMS、峰值因子、峭度Kurtosis、偏度Skewness频域特征对窗口做FFT后取频谱的质心、主频幅值、频带能量占比小波包分解后的各频带能量这个我在处理非平稳信号时会用把这些特征拼成一个特征向量比如一行12列。这样原始1万多个信号点就被压缩成了几百个样本×十几个特征的特征矩阵。Bagging在这种中低维特征上表现特别好比直接喂原始波形稳定训练速度也快。有个小坑要提醒特征提取必须在训练集上统一计算参数比如标准化用的均值和标准差只能从训练集里算出来测试集和现场数据都用同一组参数去变换绝不能把测试集也混进来一起算。这是数据泄漏的经典错误很多人栽在这上面。3.2 类别不平衡会让Bagging失效必须这样处理故障检测还有一个绕不开的问题正常样本永远占绝大多数故障样本稀罕得要命。正常状态占了90%以上的情况很常见如果直接训练Bagging里的每棵树看到的都是“大量正常少量故障”投票时正常类天然占优召回率会很难看。我试过几种办法最实用的是这样第一先做类别重采样再进Bagging。对少数类做SMOTE过采样或者对多数类做欠采样把训练集的类别比例拉到一个相对合理的水平比如7:3或6:4。注意只在训练集的内部做验证集和测试集保持原始分布这样评估结果才真实。第二用代价敏感学习。在fitctree里设置Prior参数让少数类的先验概率人为调高。比如实际中故障占5%但建模时把故障类先验设成0.3这就等于人为告诉模型“错分故障样本的代价更高”。我实测下来这个方法比SMOTE更省事效果也不错。第三不要只用准确率做指标。类别不平衡时准确率是骗人的——就算模型把所有样本都判成正常准确率也有90%但这个模型毫无用处。后面会说故障检测真正要看的是G-mean几何平均、F1-score还有误报率和漏报率的组合。3.3 训练集与现场数据分布不一致的问题实验室数据和现场数据永远有差距这是故障检测项目的宿命。我遇到过最典型的情况是实验室数据的采样频率是12kHz现场设备是8kHz训练时候的转速是1800转现场是1500转。模型直接废掉。我的应对思路是在特征层面上尽量保留物理不变性。比如峭度、偏度这类无量纲特征对转速变化没那么敏感频带能量占比也是归一化后的量比绝对幅值稳健得多。另外可以在采集阶段就把运行状态记录下来按不同工况分层采样确保训练集覆盖多个转速和负载条件。如果条件允许还有一个更稳妥的做法把新工况的数据也当成“伪类别”参与训练。比如从转速A来的数据标为类别1~4从转速B来的数据标为类别5~8让模型先学会区分“转速A的内圈故障”和“转速B的内圈故障”这样模型不会把转速差异和故障差异混在一起。这个思路类似于领域自适应里的多源域训练实测效果比单纯堆数据好。4. 完整可跑的Matlab实现工具箱一行代码与手写框架的取舍4.1 基于fitcensemble的最小可用版本如果你装的是Matlab R2013b以上版本统计和机器学习工具箱里已经有现成的集成学习接口不需要自己写循环。最核心的就一行% XTrain: nSamples x nFeaturesYTrain: nSamples x 1 mdl fitcensemble(XTrain, YTrain, ... Method, Bag, ... % Bagging方式 NumLearningCycles, 100, ... % 基学习器个数 Learners, tree, ... % 基学习器用决策树 KFold, 5); % 5折交叉验证这句代码训练完成后mdl本身已经含了交叉验证结果。但注意用了KFold之后返回的是一个ClassificationPartitionedEnsemble对象不是直接用于预测的模型。你需要再拿全量训练数据重新训练一个最终模型或者使用kfoldPredict先看交叉验证表现。我给一个更常用的模板把训练、评估、保存串起来% 主流程 rng(42); % 划分训练测试集 cv cvpartition(YTrain, HoldOut, 0.25); idxTest test(cv); mdl fitcensemble(XTrain(~idxTest, :), YTrain(~idxTest), ... Method, Bag, ... NumLearningCycles, 150, ... Learners, tree, ... ClassNames, [0; 1]); % 明确指定正负类别 % 测试预测 [yHat, score] predict(mdl, XTrain(idxTest, :));这里ClassNames必须显式指定尤其是正负样本都用0/1编码时不指定可能导致预测结果被当成逻辑值或者顺序错乱。我踩过一次这个坑当时类别是1和2没指定ClassNames预测出来全反了排查了很久才发现是类别顺序的问题。4.2 手写框架的模块设计与关键函数工具箱版虽然方便但有两个痛点一是fitcensemble的内部细节不太好改二是没法直观理解每个环节。我在前面的骨架代码基础上扩展出一个完整的手写模块分成了四个函数职责清晰extractFeatures.m从原始信号里提取特征矩阵baggingTrain.m训练Bagging集成内部支持指定基学习器个数、每棵树的深度baggingPredict.m预测支持返回投票概率evaluateModel.m计算混淆矩阵、精确率、召回率、F1、OOB错误率下面是升级版的关键部分重点在预测阶段返回投票概率function [pred, probPos] baggingPredictPro(model, X) nTrees numel(model.trees); nSamples size(X, 1); posVotes zeros(nSamples, 1); for t 1:nTrees classID predict(model.trees{t}, X); posVotes posVotes (classID model.PosClass); end probPos posVotes / nTrees; % 正类投票比例 pred double(probPos 0.5); % 默认阈值0.5 end注意这个阈值0.5不是死的。在故障检测里漏掉一次故障的代价往往比多报一次警更严重我通常会把阈值从0.5降到0.4甚至0.3让模型“敏感”一些宁可多报几次假警也别把真故障漏过去。这个调整在工具箱版本里也有就是predict返回的score第二列取阈值时直接比较分数即可。4.3 故障检测评估指标的完整实现很多初学的人跑完模型只看准确率我要强调故障检测场景下单一准确率没有任何参考价值。我每次必看的是混淆矩阵和一系列衍生指标。function [CM, metrics] evaluateModel(yTrue, yHat) CM confusionmat(yTrue, yHat); TP CM(2,2); TN CM(1,1); FP CM(1,2); FN CM(2,1); precision TP / (TP FP); % 精确率报警里面有多少是真的 recall TP / (TP FN); % 召回率真实故障里有多少被报出来 F1 2 * precision * recall / (precision recall eps); % 误报率正常样本中被误报警的比例 fpr FP / (FP TN); % 漏报率故障样本中未被报警的比例 fnr FN / (FP FN); % G-mean兼顾正常类和故障类 tpr recall; % 真正例率 tnr TN / (TN FP); % 真负例率 gmean sqrt(tpr * tnr); metrics table(precision, recall, F1, fpr, fnr, gmean); end我评估一个故障检测模型是否合格一般看两个标准召回率要大于95%误报率要小于10%。注意不是说越高越好有些项目里报警过于频繁会导致维护人员“狼来了”最后反而不管了。所以调参时我不会一味贪阈值低而是结合误报率一起看找一个可接受的平衡点。5. 调参与避坑实录从训练集95%到测试集同样95%5.1 最容易翻车的五个细节第一随机种子不能乱设。Bagging的结果天然带有随机性如果你不固定随机种子每次跑出来的准确率都不一样。这本身不算错但要命的是你在对比试验时如果种子不固定根本分不清模型改进是真实的还是随机波动。所以我在所有实验里统一rng(42)。第二树的数量不要盲求大。很多人以为NumLearningCycles越大越好其实超过一定数量后准确率就饱和了反而训练时间直线上升。用OOB错误率曲线观察是最好的办法错误率下降开始变缓的位置就是合适的树数量。我做轴承数据时大概50~100棵树就到平台期了。第三决策树的深度要限制。如果每棵树都长到完全纯单个基学习器方差还是大Bagging的稳定性提升有限。我一般在fitctree里设置MaxDepth在5~15之间让每棵树“弱一点”这样集成后效果反而好。太强和太弱之间有一个平衡需要自己用验证集试。第四小心类别顺序出错。前面提到的ClassNames问题我再强调一遍用0/1或者1/2编码时一定要显式指定否则Matlab会按字母序排列类别预测结果可能完全反了。第五不要忽视特征标准化。虽然决策树本身对特征尺度不敏感但如果后续要和SVM、XGBoost这些模型对比必须统一做标准化。我在项目里统一用zscore并且分训练集/测试集计算参数。5.2 误报与漏报的平衡阈值移动故障检测里最真实的场景是模型输出的不是“故障/正常”二值结果而是一个故障概率。生产现场需要一个明确的报警阈值这个阈值怎么定直接影响整个系统的可用性。我通常的做法是画ROC曲线然后根据实际业务成本选阈值。Matlab里可以用perfcurve% 用投票概率画ROC [fpr, tpr, thresholds, auc] perfcurve(yTrue, score(:, 2), 1); figure; plot(fpr, tpr); xlabel(假正例率); ylabel(真正例率); title([ROC曲线, AUC , num2str(auc)]);然后选阈值时我一般不只盯着“离左上角最近”那个点。比如有一个项目客户明确说“我们宁可每周多拆两次设备检查也不能让故障轴承带着隐患转下去”那我就把阈值往低调把召回率干到98%代价是误报率到了15%。反过来如果现场报警太多导致没人信了就得升阈值。这个决策必须和现场业务绑定不能纯靠公式。我还有一个习惯用OOB概率而不是测试集概率来选阈值。因为测试集只有一份反复用同一份数据调阈值会造成对测试集的过拟合。OOB概率对每个训练样本来说都是“见过的树投票”没见过的模型评估更有泛化代表性。5.3 和XGBoost、LSTM等其他模型的实际对比很多同行问我都有XGBoost了还有必要用Bagging吗有LSTM了做时序故障检测不是更好我统一回答各有所长关键看数据规模和业务约束。我自己在同一个轴承数据集上做过一组对比数据量大约是800个训练样本、16个特征任务是四分类故障识别。结果大致如下模型测试集准确率训练时间可解释性备注单棵决策树82%1秒高方差大Bagging决策树基学习器93%8秒较高稳定且够用随机森林94%8秒较高和Bagging接近XGBoost95%20秒较低效果最好但要调参LSTM序列输入87%600秒低样本太少发挥不出来这个结果很能说明问题样本量只有几百时XGBoost的优势并不明显LSTM更是英雄无用武之地而Bagging用很低的成本达到了非常接近最优的表现。LSTM的优势在长序列时间依赖明显的场景但前提是你有足够多的历史数据否则很容易过拟合。需要强调的是这个对比里XGBoost准头略高但实际换一批数据后差距往往就缩小甚至反转了。Bagging对参数不敏感、开箱即用在工业项目里是“最省心的下限保障”。6. 这个框架后续还能怎么扩展6.1 从离线检测到在线监测我最初做的是一次性离线分析后来客户要求做成在线监测每来新的振动数据系统实时判断设备状态。这时Bagging模型面临一个问题——模型是静态的设备状态会漂移。我对策是加一个滑动窗口的在线评估每10分钟产生一批新的特征向量用训练好的Bagging预测如果连续多个窗口报警才触发真正的告警。同时对OOB样本持续监控如果新数据的预测置信度始终很低说明可能出现了模型没见过的工况这时触发“模型更新”信号。这个“报警触发机制”虽然简单但能把误报率再压掉一半。6.2 与时序预测模型结合Bagging处理的是“某个时刻的特征快照”但故障往往是一个发展过程从早期退化到完全失效是有时间规律的。这时候可以考虑把时序信息加进去。我试过的一个思路把连续几个窗口的Bagging预测概率拼成一个时间序列再用一个简单的RNN或LSTM做二次分类判断“当前这段趋势是恶化还是波动”。但如前所述时序模型对样本量要求高如果没有足够的完整故障样本效果反而不如老老实实用Bagging。另一个路子更值得试把时域特征做完之后用Bagging分支处理频段特征用另一个分支处理时序偏移特征最后融合。这种多分支结构在Matlab里用几个独立模型组合就能实现不用深度学习框架也能得到类似效果。6.3 模型更新的低成本方案最后分享一个我最近在用的技巧Bagging模型天然支持滚动更新。因为它的基学习器相互独立当新数据来了时不需要重新训练所有树只需要在现有模型基础上加训练几棵新树或者替换掉表现最差的那几棵树。Matlab里工具箱版的实现是% 用新数据增量更新模型 mdlUpdated resume(mdl, XNew, yNew, NumLearningCycles, 20);手写版更灵活可以自己维护一个树的数组定期用新样本训练新树替换旧树。这样模型能跟着设备状态慢变化走又不会频繁全量训练占用资源。我在实际项目里通常在每天凌晨用当天新积累的数据更新一次模型每次只加10~20棵树更新完自动约束总树数量不超过200。这种模式跑了大半年模型在现场的召回率一直维持在95%以上误报率也比初始版本降低了不少。说到底Bagging这个算法看起来简单但真正用好它功夫都在数据、指标和工程细节上。希望这篇代码和踩坑记录能帮你少走点弯路。后面我会继续整理关于特征自动选择、模型压缩部署的内容。