当前国内制造、风电、水泥等领域的设备预判需求爆发，大量AI模型停留在实验室测试阶段，落地现场就翻车。我经手过五个百亿级项目的AI故障预判落地，踩过的坑比你见过的现场还多。今天就把实际工程里的核心要点掏出来，给同行做个参考。
工业现场数据才是卡脖子的地方，不是模型
很多人上来就调大模型、堆参数，开口就是多少亿参数量准确率多少。没用。你去工厂转一圈就懂了。
振动传感器装歪1度，采集到的时域数据就能偏五个标准差，对吧？更头疼的是故障样本少——谁没事拆了好设备让它坏，就为了给你攒数据？我之前在北方某风场做主轴故障预判项目，一百台在线监测的风机，三年才攒到17例主轴失效的完整数据，就这，还有三例是刮风断网漏采了一半数据。
处理不平衡样本，不是拉个开源的SMOTE跑一遍就完事了。按照GB/T 33982-2017 机械故障诊断数据处理规范，工业时序故障数据必须用时域约束的SMOTE-Tomek链接方法，才能保证生成的少数类故障数据符合设备劣化的物理规律。
刚入行做第一个项目的时候我不懂，直接用了GitHub上开源的普通SMOTE，模型在测试集准确率冲到96%，高高兴兴交差，结果现场跑了一个月，误报率32%。被甲方项目负责人骂得狗血淋头，现在想起来都懊恼。
说实话，90%的预判模型落地失败，问题根本不在算法本身，在数据。数据脏，特征选不对，再牛的模型也白搭。
常用模型选型：不是越复杂精度越高
现在网上到处都是网红模型，Transformer时间序列、大模型微调，什么都往故障预判上堆。堆对了吗？未必。
我去年带团队做过一组对比测试，同一份滚动轴承全生命周期故障数据，针对边缘部署场景，改进型LSTM-Transformer混合模型，参数总量只有纯Transformer模型的1/12，推理速度快6倍，误报率只高0.8个百分点。你想想工业现场的边缘网关，大部分也就512M到1G的运行内存，你塞个几个G的大模型进去，十秒才出一次推理结果，等预警发出来，轴承都已经磨坏了。
我现在选型只看部署场景，从来不追新潮。如果是厂区核心大型机组，有专属云端集群算力，那可以用全深度模型，故障分级按照ISO 13373-1:2002的振动故障标准来卡，没问题。如果是分散在车间的几百台上千台小型设备，边缘网关资源有限，直接用CNN提特征加LightGBM分类就够了，准确率掉不了两个点，推理能做到百毫秒级，够香了。
之前有个合作的高校团队，非要给我们推一个十亿参数的通用大模型，说准确率比我们在用的小模型高两个百分点，结果一测，边缘设备根本跑不起来，要把数据传到云端推理，厂区网络一波动就延迟三五分钟，预警变成事后通报，最后还是换成了我们的轻量化方案。
不过话说回来，如果能做好模型蒸馏，把大模型的泛化能力蒸馏到小模型上，确实能降一个点左右的误报，这个方法我试过，性价比很高，值得试。
预警阈值怎么设？别只看模型输出
很多人做模型，最后阈值就是模型输出大于0.5就报警，这纯纯是实验室做法。工业设备的故障都是渐变的，从正常到劣化，到预警，到告警，再到失效，是一个连续过程，哪来这么一刀切的阈值？
我前年做水泥厂辊压机滚动轴承的预判项目，一开始图省事，就用0.5做阈值，结果一个月出了十三次误报，大部分都是辊压机进料不均导致的瞬时振动偏大，根本不是部件劣化。后来我们改了方案，把设备实时运行负荷也作为模型输入特征，不同负荷段设不同的阈值：满负荷运行时，模型输出超过0.35触发预预警，超过0.6触发紧急告警；半负荷运行时，阈值分别调到0.45和0.7，就这一下，误报率直接降了80%多。
还有个很容易踩的坑：一次异常就触发报警。工业现场什么干扰没有？路过一个叉车，电网跳一下电压，都可能导致传感器数据跳变。一定要加连续验证规则，连续三个采集周期都超过阈值，再发预警，能滤掉90%以上的瞬时干扰。
最后，一定要留人工调整阈值的接口。现场盯设备的老师傅，对自己管的设备脾气门清，他们说这个阈值不对，你就得给人留出调整的空间，别把阈值锁死在模型推理逻辑里。这个细节，救过我好几个项目。
现在很多人吹AI能搞定一切故障预判，其实哪有那么神。把数据搞干净，模型选对适配场景，阈值贴合现场工艺，就能解决80%的实际问题，花里胡哨的概念，看看就好，落地的时候别乱碰。
