物理约束下不平衡样本的工业故障诊断与实时部署框架

做工业故障诊断的同行应该都有同感：模型在实验室里跑得风生水起，一上产线就拉胯。不是算法不够新，而是故障样本太少、太偏，正常样本多到溢出，故障样本却稀稀拉拉，模型很容易“躺平”成只报正常的复读机；另一个更隐蔽的问题是，模型诊断结果经常违反物理常识——温度还没升就先报过热，振动明明平稳却给出轴承严重磨损。这两件事放在一起，就逼着人去做一个能落地的框架：物理约束下基于不平衡样本的工业故障诊断与实时部署框架。这篇文章不聊虚的，就拆解这个框架从数据、模型、约束到线上服务的完整链路，说说我实际踩过的坑和能直接抄作业的配置，适合正在做设备预测性维护、质量异常检测和边缘智能诊断的工程师参考。

1. 先搞清楚：这个框架到底解决什么问题

1.1 工业故障诊断场景里，数据为什么总是“偏科”

工业现场的数据偏科不是偶然，是必然。一台压缩机正常运行几个月，可能只发生一次阀片断裂；一条包装线成千上万的合格品里，偶发一次卡料。于是收集到的数据集里，正常样本占比可能超过99%，故障样本不到1%，典型的不平衡分类问题。更麻烦的是，故障类型不是只有一种：轴承内圈磨损、外圈点蚀、保持架断裂、转子不对中、齿轮断齿……每一类故障样本可能只有几十条，彼此之间特征差异又很小。

直接用这种数据训练分类器，损失函数会被多数类主导。模型学会了“猜正常”就能拿到很高的准确率，但故障漏报率可能高得吓人。工业场景最怕的不是误报，误报顶多停机检查浪费一点时间；漏报才是真的危险，设备继续带病运行，轻则产线停摆，重则安全事故。所以这个框架的第一目标不是刷准确率，而是在极少数故障样本下把漏报率压下来。

偏科还来自工况漂移。同一台设备，转速不同、负载不同、环境温度不同，振动和电流特征分布完全不同。一种工况下学到的故障特征，在另一种工况下可能完全失效。如果做数据增强时不考虑工况边界，很容易合成出物理上根本不可能出现的“虚拟样本”，模型在测试集上看着还行，一上现场就崩。

1.2 只靠准确率远远不够，物理约束是安全底线

纯数据驱动的模型有个通病：外推能力差。训练数据覆盖的区间内，模型拟合得不错；一旦输入落到没见过的区域，它就会根据学习到的表面相关性做出离谱预测。工业诊断里，这种离谱预测是不能接受的。比如冷却系统明明在正常运转，模型却因为某个传感器数值的偶然组合报出“过热”，操作员会怎么想？第一次信了，第二次怀疑，第三次直接把系统停用。模型失去信任，比模型准确率低更致命。

物理约束做的就是给模型套上“常识护栏”。旋转机械的振动幅值随转速变化的范围是有限的，轴承温度的变化率不可能瞬间跳变，电机电流和转矩之间要满足基本的力学关系。这些先验知识不依赖样本分布，是设备工作原理本身就决定的。把这种约束加进模型，哪怕数据没覆盖到，模型也不至于说出违反基本物理规律的判断。

另一种情况是诊断结果用于闭环控制。模型说“轴承严重磨损”，系统就自动降速甚至停机。如果这个判断没有物理合理性兜底，误触发带来的生产损失由谁承担？所以物理约束不是锦上添花，是工业部署的刚需。它解决的不只是“准不准”，而是“能不能被现场信任和接受”。

1.3 从离线训练到实时部署的框架选型

把物理约束和不平衡样本处理放进同一个项目，很多人第一反应是：又要搞算法又要搞工程，干脆全用一套代码写完拉倒。真这么做，后面会非常痛苦。训练脚本里耦合了数据加载、模型结构、可视化、调参逻辑，部署时又要从里面抠模型出来，再写一套推理服务，中间任何一环改动都可能引发连锁问题。

我通常把整个项目拆成三个相对独立的子框架：数据框架负责样本重平衡、特征工程和数据版本管理；训练框架负责模型结构、物理约束损失和训练调度；推理部署框架负责模型转换、服务封装、监控告警。三者之间通过固定的模型产物（ONNX文件）和配置接口（YAML）衔接，而不是通过代码互相调用。PyTorch基础框架作为训练侧的主干，FastAPI作为服务侧的主干，pytest串起整个自动化测试流程，这套组合已经在我好几个项目里稳定运行。后面每一章，我都会按这个拆分方式展开。

2. 核心模块拆解：数据、约束、模型训练怎么捏在一起

2.1 数据侧：先做样本重平衡，还是先做特征工程

很多教程上来就叫你跑SMOTE，我建议反过来：先做特征工程和数据清洗，再做样本重平衡。工业传感器数据里噪声多、缺失多、时间戳不对齐，如果原始数据还没洗干净就合成新样本，等于把噪声也放大一遍。我遇到过有人对原始振动波形直接做SMOTE插值，生成了大量高频毛刺，模型学到的全是插值痕迹，到真实数据上立刻露馅。

推荐的处理顺序是：原始数据清洗（去野点、去停机段、按工况切分）→ 特征提取（时域均值、峰值、峭度；频域重心、边频带能量；小波包分解后的各频带能量）→ 特征标准化 → 样本重平衡 → 划分训练验证集。特征层面做重平衡比原始波形层面更容易控制风险，因为特征已经相对平滑，合成样本不至于出现离谱波形。

重采样方法的选择也看数据类型。随机过采样简单但容易过拟合；SMOTE在特征空间线性插值，适合特征维数不高且分布相对紧凑的情况；ADASYN能根据样本密度自适应决定生成数量，但对离群点敏感；Mixup则把两个样本按比例混合，相当于一种正则化。我的经验是：不要只依赖采样，要把采样和损失函数配合起来用。采样负责改变样本比例，损失函数负责让模型难例过得更好。

数据版本管理也得提上日程。工业现场的数据是持续回流的，今天训练的数据可能和三个月后的数据分布不一样。没有版本管理，模型复现就是空谈。我在项目里用DVC管理特征数据集，每次重采样、清洗都生成独立版本，模型训练时记录数据版本的哈希值。这样现场反馈模型效果变差时，能快速定位是数据变了还是模型衰减。

2.2 约束侧：软约束损失和硬约束后处理的边界

物理约束怎么进模型，核心问题是选软约束还是硬约束。软约束是把物理规律写成残差项，加到训练损失函数里，让模型预测结果“尽量”满足物理关系；硬约束则是在模型结构或推理后处理上直接限定输出范围，物理规律是绝对成立的。

举个旋转机械的例子。如果我们要预测轴承温度随时间的变化，一个很基本的热力学近似是：温度变化率与环境温差成正比，即：

[ \hat{T}{t+1} = T_t + \alpha (T{\text{ambient}} - T_t) \Delta t ]

这就是一个物理先验。软约束做法是把模型输出的温度预测值和这个物理递推式算出来的值做MSE，作为额外loss项：

[ L_{\text{phys}} = \text{MSE}(\hat{T}{t+1}, T_t + \alpha(T{\text{ambient}} - T_t)\Delta t) ]

这样模型在拟合数据的同时，输出也会被物理关系“拽”着走。软约束的优点是实现简单、梯度传播平滑，缺点是只能保证大致满足，不能保证绝对不违反。它适合那些物理模型本身就有误差的场景，比如热对流系数α需要辨识，硬约束反而不现实。

硬约束更直接：在模型最后一层加上变换，让输出永远落在物理允许范围内。比如诊断“轴承磨损等级”，物理上磨损等级不可能为负，那就用ReLU或者Softplus保证输出非负；再比如模型输出温度和真实传感器温度的关系，可以加一致性校验层，预测值不能偏离上一时刻真值超过物理允许的最大变化率。工业场景里，安全边界类的约束我用硬约束，机理动态类的约束我用软约束，两者分工明确。

千万别做反了。如果把不完全准确的机理模型变成硬约束，模型预测会被错误先验卡死，数据里正确的模式反而学不到。我见过一个项目，把简化的能量守恒公式当成硬约束加入模型，结果故障初期能量变化本来就不满足简化公式，模型永远报不出早期故障，漏报率反而上升。物理约束不是越多越好，而是越准越好。

2.3 训练侧：PyTorch基础框架下的Loss组合技巧

模型结构我建议从轻量级开始，不要一上来就堆Transformer。工业故障诊断样本量普遍不大，复杂的模型容易过拟合，而且部署时推理延迟受不了。我常用1D-ResNet或者带注意力机制的1D-CNN作为骨干，配合自适应池化，结构简单、训练稳定。

训练时的核心是把多个loss组合起来。一个通用形式是：

total_loss = (w1 * ce_loss + w2 * focal_loss + w3 * physics_loss)

交叉熵保证基础的分类能力，Focal Loss让模型更关注少数类故障样本，physics_loss负责物理合理性约束。三个loss的量纲差别很大，不能简单相加。必须做归一化，否则量级大的loss会主导梯度。我的做法是先分别跑几次训练，统计三个loss的初始量级，然后按初始量级反比设定权重，之后在训练中逐渐调整。

Focal Loss的参数也要调。默认gamma=2，但在工业数据上我经常发现gamma=1.5效果更好，因为gamma太大会把大量简单样本的梯度压得太狠，导致正常样本的基本判别能力下降。alpha参数用来平衡正负样本，一般设在0.25到0.5之间，具体要看少数类占比，可以按类别频率的倒数做初值，再手动微调。

样本采样的实现细节容易被忽略。很多人在PyTorch里用WeightedRandomSampler给少数类提高采样概率，但要注意采样器可能让同一个故障样本在同一个epoch里出现很多次，模型很容易记住这些样本。我的做法是给采样器加max_subsample_limit，限制少数类单个样本的最大重复次数，同时配合数据增强（加噪、时间偏移、小幅缩放）来增加多样性。这样既增加了少数类出现频率，又不至于让模型死记硬背。

优化器方面，工业数据集的训练规模通常不大，AdamW加上CosineAnnealing学习率调度就够用了。AMP混合精度训练在提升训练速度的同时，还能减少显存占用，但BatchNorm层在混合精度下有时会出现波动，建议训练初期先关闭AMP，等到loss稳定后再开启。

3. 实时部署：从训练脚本到线上服务的完整链路

3.1 模型转换：TorchScript、ONNX还是TensorRT

实验室里训练好的PyTorch模型不能直接扔到生产环境。不是不能跑，而是性能、依赖、版本管理都不可控。我习惯先把模型导出为中间格式，再根据部署平台的算力情况做优化。目前三个常见选择是TorchScript、ONNX Runtime和TensorRT。

TorchScript是PyTorch原生的方案，胜在兼容性，PyTorch里能跑的网络基本都能导出。缺点是优化深度有限，CPU上推理延迟改善不明显。ONNX Runtime是跨平台、跨框架的标准中间层，部署时不需要装PyTorch，模型体积也更小，CPU上的优化效果明显，是目前最稳的选择。TensorRT只支持NVIDIA GPU，优化最激进，可以把FP16推理延迟压到毫秒级，但是算子兼容性最差，很多自定义层需要手动处理甚至重写。

我的默认路径是PyTorch → ONNX，再用onnx-simplifier做一次图优化。如果现场是GPU工控机，再尝试转TensorRT，但不是直接转，而是先在ONNX Runtime上跑一遍基线，确认算子都能正常执行，再转TensorRT。转变文件时开启动态shape要小心，RNN或者带有固定长度滑窗的模型，动态shape会引入额外复杂度，能用固定shape就尽量用固定shape。

导出的模型要做前向对比验证。不能只看输出shape对不对，要把同一批样本分别用PyTorch和ONNX Runtime跑一遍，比较输出分布。我一般要求两者的差异尽量控制在1e-4以内，如果差异明显，优先检查数据预处理是否一致，尤其是标准化参数是否被错误地写死在模型里。

3.2 服务化：FastAPI + 独立推理进程的架构

部署架构上踩过的最大的坑，是把模型推理直接写在FastAPI进程里。模型推理是CPU密集操作，FastAPI是异步框架，如果在异步函数里直接跑同步模型推理，事件循环会被阻塞，接口响应时间会随机飙升。更合理的做法是把推理进程和服务进程分开，服务进程负责接收请求和返回响应，推理进程负责加载模型和计算，两者通过队列或者共享内存通信。

FastAPI在这个架构里非常合适。它的异步支持好、自动生成OpenAPI文档、Pydantic校验让接口契约清晰。一个最小可用的推理服务大概长这样：

from fastapi import FastAPI, HTTPException from pydantic import BaseModel import numpy as np app = FastAPI(title="fault-diagnosis-service") class SensorInput(BaseModel): features: list[float] rpm: float = None class DiagnosisOutput(BaseModel): fault_label: str confidence: float physics_valid: bool @app.post("/v1/diagnose", response_model=DiagnosisOutput) def diagnose(data: SensorInput): # 这里只做参数校验和结果拼装 result = inference_queue.predict(np.array(data.features)) if result is None: raise HTTPException(status_code=503, detail="inference queue overloaded") return result

请求进来后，接口把特征推给独立的推理Worker进程，Worker从队列中取数据、跑模型、返回结果。这样就算某个推理超时，也不会卡住整个服务进程。Worker进程内部可以做模型预热，启动时先跑几条随机样本，把显存和内存分配好，避免第一个请求延迟过高。

批量推理可以显著提高吞吐。单个请求一次只推一条特征，模型推理的并行度上不来。我在Worker里做了一个简单的batch聚合器：把100毫秒窗口内的请求聚合在一起，组成一个batch，一次性前向传播，再拆开返回。实测在GPU上吞吐量能提升4到8倍，延迟也只增加一点点。CPU环境收益没那么大，但也可以减少框架调度的开销。

3.3 配置管理与接口契约

模型上线还牵涉到大量配置参数：物理约束系数、Focal Loss阈值、报警置信度阈值、特征标准化参数、模型文件路径。这些如果写在代码里，每次调参都要重新发布服务，很容易出事故。我建议单独用一个YAML文件管理，服务启动时加载，运行时只读。后续现场需要调整阈值，运维改配置文件再重启服务即可，不需要动代码。

接口契约要版本化。工业现场设备端和平台端的对接周期很长，如果没有版本控制，后端的模型升级可能会压坏旧的设备端协议。我的做法是接口路径带版本号，v1接口返回原始诊断结果，v2接口增加了物理校验标志和置信度阈值参数，两个版本可以并存一段时间，等现场全部升级后再下线v1。

这里可以跟现有的Java后台系统打通。很多工厂的MES、EAM系统本身就是基于若依框架（ruoyi）这类快速开发平台搭建的，他们不需要重新开发一套诊断后台，直接把诊断服务注册成OpenAPI接口，在若依后台的菜单和权限体系里接入即可。数据驱动的诊断结果再配上若依的工作流引擎，可以自动生成维修工单，整体闭环就完整了。工业项目里“框架”的意义从来不只是算法框架，还包括业务系统的对接方式。

4. 工程化与测试：不能只在实验环境能跑

4.1 数据管线和模型测试：pytest怎么用起来

模型上线前最容易被忽视的是自动化测试。很多团队只在实验环境里跑一下准确率，就直接把模型放到生产环境，出了问题才发现连基本的数据格式校验都没有。我在项目里用pytest搭了一套自动化测试，每次训练完模型、每次更新数据管线，都会跑一遍回归测试。测试不是只测模型准确率，而是把整个数据管道、推理输出、物理约束校验都纳入测试范围。

最基本的测试用例包括：输入特征维度是否和模型输入层匹配；标准化参数是否和训练时一致；ONNX模型能否正常加载并完成一次前向推理；推理结果是否在合法的标签范围内；物理约束标志是否正确触发。这些用例看起来简单，但能在模型迭代时挡住大量低级问题。比如有人换了特征提取函数，维度从128变成了120，如果没有维度检查，模型加载后直接报错，但报错信息只会在推理时出现，测试阶段就能挡住。

对于不平衡样本，测试集要特意保留一份少故障类别的真实样本，不能因为数量少就从测试集里删掉。我习惯用分层采样划分训练集和测试集，保证测试集里每一类故障都有一定数量。回归测试时，我还会拿历史现场回流数据做一遍推理，比较新旧模型在真实数据上的预测漂移，如果某类故障的召回率掉了超过3个百分点，测试就失败，模型不能上线。

pytest的fixture机制很适合做这种测试。在fixture里加载ONNX模型、加载标准化参数、加载测试数据，测试函数只需要断言推理结果。跑一次全量回归测试大概两三分钟，完全可以在每次模型训练完成后自动执行。这个流程不复杂，但能挽回的线上事故成本非常可观。

4.2 监控、告警和故障自愈闭环

模型部署上线只是开始，线下的脏数据、传感器漂移、设备工况变化都会让模型性能慢慢退化。所以线上服务一定要有监控。我通常在服务里埋点，记录每分钟的请求量、平均推理延迟、P99延迟、显存/内存占用、各类故障的预测分布、置信度分布。这些指标推到Prometheus，再用Grafana做可视化，超过阈值就告警。

比延迟监控更重要的是预测分布漂移检测。比如过去一周，模型预测“正常”的比例在95%左右，某天突然降到70%，说明输入分布大概率变了，可能是传感器故障、工况切换，也可能是设备真的出了问题。此时不能直接判定模型坏了，但至少要触发告警，让运维去查。

告警之后的自愈流程可以用规则引擎，也可以借鉴Agent框架的思路。现在类似LangChain、Dify、CrewAI这些Agent框架很火，它们可以编排多步任务：收到告警后自动拉取模型日志、检查输入数据分布、对比历史故障案例，生成一份排查报告。我在项目里尝试过用脚本编排一部分这样的逻辑，核心思路是：告警触发 → 自动拉取最近1000条推理日志 → 计算特征分布偏移度 → 匹配已知故障模板 → 生成处置建议。这个流程用不上大模型的Agent框架也能做，但如果你本来就在用Dify这类平台，把它接进来确实能减少运维响应时间。

注意一点：自愈流程不能全自动执行危险动作。比如自动停机、自动修改工艺参数这类影响产线的操作，必须有人工审批环节。自动生成报告和自动隔离异常样本是安全的，可以完全自动化；自动切换模型版本，建议设置一个灰度验证期，验证通过后再全量切换。

4.3 版本管理与回滚机制

模型版本管理不要只靠文件名后面加个“_v3_final”这种野路子。我建议用MLflow或者模型注册中心来管理。每次训练记录模型参数、训练数据版本、评价指标、ONNX文件地址。线上服务启动时从注册中心拉取指定版本的模型，而不是从固定路径读文件。这样回滚就变得非常简单：只需要把配置里的模型版本号改回去，重启服务即可。

版本回滚必须做兼容测试。新版本的输入特征维度、标准化参数、标签映射如果跟旧版本不一致，回滚后可能出现严重错误。所以我在模型注册中心保存的不只是模型文件，还包括一份包含特征清单、标准化参数和标签映射的元数据。回滚前先对比新旧版本的元数据，确定兼容，再执行回滚。

工业现场还经常遇到模型更新的灰度发布问题。比如新的故障模型对A类故障识别更好了，但在B类故障上误报率有所上升。如果直接全量切换，现场可能突然多出一批误报告警，操作员立刻失去信任。我习惯按设备ID灰度发布：先让新模型只处理10%的设备，观察两三天，对比误报率和召回率，再逐步扩大范围。这个过程需要接口层面支持模型版本切换，也就是同一个接口路径下，可以按设备路由到不同版本的模型。

5. 实战中踩过的坑与排查方法

5.1 采样策略导致的假性过拟合

我看过不少项目一上来就对少数类SMOTE，然后训练集AUC刷到0.99，一到现场测试直接崩。原因多半是合成样本跨了工况边界。比如设备转速有800转和3000转两个工况，特征空间里这两个工况本来相距很远，SMOTE线性插值会生成一堆转速位于1500转左右的“混合特征”，而这个转速下设备根本不存在运行数据。模型学到的是一堆不存在的中间态，真实数据里自然匹配不上。

解决办法是先把工况聚类，在同一个工况簇内部做重采样。工业数据里工况通常是明确的，可以直接按转速、负载、温度等关键参数划分。如果工况信息不全，可以先对特征做主成分分析，在前几个主成分方向上做聚类，再按簇内插值。合成样本的数量也要控制，我一般把少数类过采样到多数类的30%到50%就够了，补到完全平衡反而不利于模型泛化，因为少数类的真实多样性根本没有那么多。

5.2 物理约束loss不收敛怎么办

物理约束loss加进去后训练loss不降反升，这种情况我遇到得最多。第一个原因是物理残差和分类loss的量纲不匹配。分类loss一般是0到1之间，而物理残差可能是几十上百甚至上万。如果直接相加，梯度完全被物理loss吃掉，模型会疯狂调整输出去满足物理公式，分类任务反而学不好。解决办法是先对物理残差做标准化，让它也落到0到1量级，再用一个可调的系数w3来控制它。

第二个原因是物理约束权重一开始就给得太大。我现在的做法是w3从一个很小的值开始，比如0.01，前几个epoch只让模型学数据分布，后20个epoch再逐渐把w3升高到0.1左右。这叫物理约束warm-up，有点像课程学习的思路。如果一上来就满权重，模型还没有建立基本的数据特征表示，就被物理公式拽进一个局部最优，后面很难跳出来。

第三个原因是物理公式本身就有问题。拿简化的热力学公式去约束真实物理过程，本身就是模型偏差。这种情况需要做残差分析，看训练结束后物理loss还有多少。如果物理loss始终下不去，甚至验证集的物理loss比训练集低很多，说明物理先验和真实过程不一致，需要改物理模型，而不是调权重。

5.3 延迟与吞吐的权衡

实时部署里最常见的矛盾是延迟和吞吐。追求低延迟就单请求推理，模型频繁启动、资源利用率低，可能每秒只能处理几十次请求；追求高吞吐就拼batch，但单次请求要等batch凑满，P99延迟会飙上去。我实测下来，在GPU环境下batch聚合的收益远远大于风险，所以我会把batch窗口设置到100毫秒以内，最多积压64个请求，兼顾两者。CPU环境下，单模型推理延迟本身不高，batch化收益有限，反而可能因为排队增加延迟，建议直接用单请求推理加多进程副本。

还有一类延迟问题是数据预处理阻塞。比如特征提取里用到了小波变换，计算量很大，如果每个请求都现场算小波，延迟自然压不下来。解决办法是把特征提取放到靠近传感器的边缘端完成，服务端只接收已经提好的特征向量。如果必须服务端做，至少要做缓存，对重复的原始序列直接命中特征缓存，别每次都从头算。

5.4 依赖版本和部署环境兼容

最后再特别提醒一下依赖版本的坑。ONNX Runtime不同版本对算子的支持程度不一样，同一个ONNX文件在这个版本能跑，换个版本可能报错。所以部署环境的依赖必须固化，最好直接用requirements.txt或者Docker镜像锁定版本。PyTorch从1.8迭代到2.x，导出的ONNX算子也可能发生变化，模型导出环境和服务端环境尽量保持相近。

线上现场经常还有老旧CPU和GPU驱动不匹配的问题。比如ONNX Runtime需要CUDA 11.8以上的驱动，但工控机上只装了CUDA 11.2，模型怎么都加载不了。遇到这种问题，不要盲目换驱动，先把依赖版本全部列出来，做一次兼容性矩阵测试：PyTorch、CUDA、ONNX Runtime、TensorRT各自版本组合，哪个组合能跑通，固化哪个组合。我在一个项目里就是靠一张固定版本的兼容性表格，才把四台配置各异的现场设备统一起来。

说到底，工业故障诊断框架的价值不在炫技，而在于稳定、可解释、可回滚。物理约束兜住底线，不平衡样本策略兜住漏报，实时部署框架兜住运维。这套东西真正跑起来，线下的故障率才降得下来。我自己最大的体会是：先想清楚哪个环节会出安全事故，再决定怎么设计约束；先看数据到底偏成什么样，再决定怎么重采样。别让框架的复杂度超过了问题本身的复杂度，那才是真正的工程智慧。