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

1. 破题：这个框架到底在解决什么问题

先说结论：这不是一个纯算法项目，也不是一个纯工程项目，而是一套把"物理机理、数据治理、模型训练、边缘部署"串成一条完整流水线的工业智能诊断方案。四个关键词里，"物理约束"管的是模型学得对不对，"不平衡样本"管的是数据本身好不好，"工业故障诊断"是业务目标，"实时部署框架"是最后能不能落地的生死线。少了任何一个，另外三个都玩不转。

我见过太多搞工业AI的团队，拿到一批轴承振动数据，跑个CNN准确率98%，觉得自己已经无敌了。结果到现场一部署，要么误报率高到现场工人把系统直接断电，要么一台设备上能用的模型换到另一台设备上就废掉，要么推理延迟达不到安全联锁的要求。问题出在哪？就出在模型在实验室里学到的东西，根本没有贴合设备的真实物理规律，也根本没有考虑工业现场的苛刻约束。

这个框架适合三类人看：一是做工业AI算法开发的工程师，想知道怎么把物理知识嵌进深度学习模型里；二是做智能制造平台建设的技术负责人，想知道怎么设计一套能复用的故障诊断流水线；三是刚入行、想搞明白"工业AI到底怎么落地"的算法工程师。我按从思路到实操的顺序讲，把每个环节的关键决策和踩坑经验都摊开说清楚。

2. 框架的设计主线：四个关键词背后的因果链

2.1 为什么纯数据驱动的诊断模型在工业现场会失灵

在公开数据集上，故障诊断模型的精度普遍能做到99%以上。为什么？因为公开数据集都清洗过，样本均衡，工况单一，连信噪比都是理想状态。工业现场完全是另一回事。

第一个坑是工况漂移。同一台电机，转速从3000转降到500转，振动特征完全变了。模型在3000转的数据上训练，拿到500转的工况下推理，准确率直接跳水到及格线以下。第二个坑是样本偏差。故障数据本来就少，采集到的那些故障样本往往来自特定负载、特定劣化阶段，根本代表不了全部故障形态。第三个坑是噪声和干扰。现场的电磁干扰、管道振动、邻近设备的机械耦合，都会在信号里叠加出模型没见过的"伪特征"。纯数据驱动模型会把环境噪声当成故障特征——因为它们确实在统计上有区分度。

这时候物理约束的价值就出来了。它不是替代数据驱动，而是给数据驱动加上一套"世界观"。设备有自己的运行规律——轴承的故障特征频率由几何尺寸和转速决定，齿轮箱的啮合频率由齿数和转速决定，电机的转子断条特征由极对数决定。这些规律写死在物理公式里，不以数据分布为转移。把物理公式嵌进模型训练，本质上是告诉模型："你可以学任何特征，但你不能违背这些基本规律。"

我自己的经验是，加了物理约束的模型，最大的提升不在训练集上的精度，而在跨工况迁移时的稳定性。同一套电机故障诊断模型，从试验台迁到产线，纯数据驱动模型的F1掉20个百分点都很正常，物理约束模型最多掉5到8个点。这是物理知识带来的泛化能力，是纯数据驱动很难学出来的。

2.2 不平衡样本为什么会成为工业故障诊断的拦路虎

工业现场的正常样本和故障样本比例，轻松超过1000比1。这还不是最麻烦的，最麻烦的是故障样本内部也是不均匀的——内圈故障可能采到了200条，外圈故障只有30条，滚动体故障只有8条，而且每一条的工况还不一样。

传统机器学习在不平衡数据上会死得很难看。因为模型天然倾向于把样本归到多数类，这样整体的loss最小。你会发现训练完之后，模型把所有样本都判成"正常"，准确率照样99.5%。这个准确率是骗人的，因为少数类的错误全部被多数类的正确掩盖了。

怎么破？常规路线有三条：数据层面的重采样、算法层面的代价敏感学习、评价指标层面换成F1或G-mean。但工业场景比学术场景多了一层约束——合成样本不能违背物理规律。用SMOTE在原始波形上直接插值合成故障样本，产出的结果拿去做FFT，频谱形态跟真实故障完全不搭。这种样本喂给模型，等于教模型学错误的东西。后面我会细讲怎么把重采样和物理规律结合起来做，这是整条数据处理链路里最容易踩坑的地方。

2.3 实时部署为什么要单独当成一个模块来设计

很多算法工程师对"部署"的理解就是"把模型保存下来，用Flask包个API，能调通就行"。工业现场不是这个玩法。产线上的安全联锁逻辑要求"采集到信号、完成推理、输出控制指令"的端到端延迟在100毫秒以内，有的严格场合是50毫秒。训练时用的ResNet152在GPU上跑一次前向要几十毫秒，再加上数据预处理、传输、反序列化，整个链路轻松超时。

更隐蔽的问题是时序确定性。深度学习推理在GPU上不是确定性的，同样的输入，两次推理的时间可能差好几毫秒。工业安全回路不接受这种抖动——它要求的是一个硬上界。所以部署框架必须在软件架构层面做缓冲和同步，而不是指望模型推理本身变快。

实时部署框架要解决的不只是"模型跑得快"，还包括：模型用什么格式封装、量化到什么精度、推理线程怎么调度、结果怎么传给PLC、误报怎么处理、模型版本怎么更新。这些问题如果不在设计阶段就想清楚，到了现场全都会变成事故现场。

2.4 "框架"二字的含义：不是代码堆叠，而是流程的固化

标题里用了"框架"而不是"系统"或者"方案"，说明作者想强调的东西是可复用的方法论。同一套架构，换一台设备、换一种故障类型、甚至换一个行业，都能用最短的时间重新组合起来，而不是每次从零开始写代码。

我理解的框架包含五个层次：数据采集层、样本治理层、模型训练层、物理约束注入层、实时部署层。每一层都定义清楚标准的输入输出接口和数据格式。比如数据采集层输出的是一套统一的振动波形格式加工况参数（转速、负载、温度），样本治理层消费的就是这个格式，模型训练层消费的是样本治理层产出的"已经平衡且带物理标签"的数据集。层与层之间解耦，任何一层内部更换算法，不影响其他层的接口。

这个设计思路的价值，等你要维护十条产线、二十类设备的时候就体会到了。没有框架，每个设备都有一套独立的脚本，数据格式不统一、模型结构不统一、部署方式不统一，维护成本直接爆炸。有框架的人，新设备接入只需要做两件事：配置数据采集参数、标注少量故障样本，剩下的流程全都走既有管线。

3. 物理约束的工程化落地：从公式到Loss的完整路径

3.1 最基础的做法：故障特征频率到底怎么算

物理约束不是玄学，第一步是把设备的故障特征频率算清楚。以滚动轴承为例，当内圈滚道局部损伤时，滚动体经过损伤点会产生周期性冲击，这个冲击的频率叫BPFI（内圈故障特征频率）。计算公式是：

BPFI = (n/2) × fr × (1 + (d/D) × cosα)

其中n是滚动体个数，fr是转频，d是滚动体直径，D是节圆直径，α是接触角。外圈故障特征频率BPFO等于(n/2) × fr × (1 - (d/D) × cosα)，滚动体故障特征频率BSF等于(D/(2d)) × fr × (1 - (d/D)^2 × cos²α)。这些公式的推导在机械设计手册里都有，拿来直接用就行。

关键问题是这些参数怎么来。现场设备铭牌上通常只有转速和功率，没有轴承型号对应的几何参数。这就要靠经验了——拆过轴承包的工程师，一眼能从轴承代号里翻出节圆直径和滚动体直径。没有条件拆的，用转速和特征频率反推：在健康数据里找到峰值，结合已知故障数据里的谐波间隔，反解出d/D的比值。

以一台四极电机为例，额定转速1470转每分钟，转频就是24.5Hz。如果BPFI实测是119Hz左右，而4倍转频是98Hz，说明这不是转频谐波的不平衡故障，而是真正的轴承内圈故障。这个判断过程本身就是最朴素的物理约束——人是拿着物理规律去解读频谱数据的。

3.2 物理约束注入模型训练的三种主流方式

物理信息损失（PINN式约束）是最常见的做法。在原有分类损失（比如交叉熵）后面加一个物理一致性损失项，专门惩罚那些违背物理规律的预测结果。拿轴承诊断举例子：模型输出的故障类型是"内圈故障"，但输入信号的频谱峰值频率和BPFI的偏差超出了容差范围，说明这个预测"物理不合理"，要加惩罚。

物理约束也可以做在数据增强上。根据特征频率公式，已知转速和轴承参数，理论上可以合成一个"标准的"内圈故障波形，把它混入训练数据，相当于把已知的物理规律直接编码进了样本分布。这里有个细节：很难直接合成一个完全逼真的故障波形，因为真实系统的传递路径、共振调制、噪声形态太复杂了。但合成波形并不需要和真实故障一模一样——它的作用是教模型"内圈故障的冲击周期应该是多少"，剩下的形态差异交给真实故障样本去补。实测下来，混入20%左右的物理合成样本，模型对故障周期的敏感性提升明显。

还有一种做法是直接在模型结构里嵌入物理特征提取层。模型不做端到端盲学，而是先计算出频谱包络、特征频率幅值比、谐波能量占比这些已有物理定义的统计量，把这些统计量拼上时域原始信息后一起送入分类器。这样做的可解释性最强——现场工程师查看推理结果时，能看到"BPFI幅值0.87、能量占比0.42、判定为内圈故障"，而不是"Tensor输出0.92"这样的黑盒数字。

3.3 物理约束合入Loss时的坑：尺度匹配和多目标平衡

加物理约束不是简单地把两项loss加起来就完事。我用过的最常见组合是：L = L_classification + λ × L_physics，其中L_physics负责衡量输出与物理规律的偏离程度，λ是加权系数。这个λ极其敏感，调得太小约束等于没有，调得太大模型直接崩掉。

为什么？因为分类损失的数值通常比较小，训练后期能降到0.1以下，而物理一致性损失如果算的是频率偏差的百分比，数值可能落在0.01到0.001的量级，两者天然差了一个数量级。直接相加，物理损失的梯度几乎被淹没。我的建议是把物理损失也改造成无量纲的百分比损失，比如规定频谱峰值频率偏离理论值5%以上算"违约"，正常范围则损失为0，这样和分类损失的数值范围就对得上。

还有时间窗口对齐的问题。分类模型的输入是固定长度的采样片段，比如1秒的数据。物理特征频率的频谱分辨率取决于采样长度：fs=25600Hz，采样1秒，频率分辨率就是1Hz；采样0.25秒，分辨率变成4Hz。如果片段的FFT分辨率和理论故障特征频率的偏差量级接近，物理约束失真了。实际处理时要在信号切分阶段就算好每个片段对应的特征频率容差，而不是指望模型自己消化一切。在训练环节就把窗口长度（如4096或8192点）和一个FIFO型滑窗策略固化下来，部署时直接复用同一套逻辑，训练与部署就完全对齐。

3.4 物理约束的另一种形态：工况归一化与迁移对齐

同类设备在不同转速、不同负载下，振动特征形态差异巨大。按传统做法，你得分别给每个工况训练一个模型。这会带来一个非常现实的问题：故障样本本来就少，分到各个工况下，每个工况的样本量不足个位数。

物理约束能帮上大忙：转速归一化和幅值归一化。把时域波形按照转频做角度域重采样（阶比跟踪），把等时间间隔采样变成等角度间隔采样。这样处理之后，同一类故障在不同转速下的波形形态就变得相似了，原有故障特征频率的阶次成分保持恒定，模型可以跨转速复用。这一步的物理依据正是阶比分析理论——它在发动机和旋转机械诊断里已经用了三十年，深度模型时代之前，老工程师们就是靠这套办法在纯硬件处理器上做检测的。

再配合工况参数（转速、负载、温度）作为条件输入，让模型按工况门控自己的特征提取过程。实测下来，对跨工况迁移有质的帮助。

4. 不平衡样本治理：在"喂饱模型"和"不造假"之间找平衡

4.1 工业不平衡问题的真实画像：99.5%正常、0.3%已知故障、0.2%未知异常

工业现场的不平衡有"双重性"。第一重是正常和故障之间的巨大悬殊；第二重是故障类型内部的不均匀——某种故障容易采到、某种故障几乎采不到。更扎心的是，真实故障往往是复合故障和渐变故障，不是公开数据集里那种单点损伤的理想故障。

"未知异常"是最容易在学术讨论里被忽略、但在工业现场极其致命的东西。设备劣化、松动、不对中、润滑失效，初期不会产生可以归类的"故障类型"，只会产生统计分布上的偏移。如果模型没见过这种分布，推理时就会出现"高置信度的正常"——这比报一个错更危险，因为现场工人看到系统说正常就放心了，结果设备在半小时后彻底停机。

所以样本治理的第一原则是：不要只盯着少数类，还得定义一个"不确定类"或者"异常类"。模型输出置信度不足以归入任何已知故障类型时，应该触发"待人工检查"的逻辑，而不是硬归到正常或者已知故障。这个机制在数学上很简单——分类器输出softmax概率后加一个阈值门，低置信度进入异常分支。阈值用验证集上的置信度分布来标定。但实际工程中，很多团队会在"收集更多异常样本再训练"这个环节死掉，因为现场标签贵、周期长，所以异常支路在首版落地时一般做成规则叠加：频谱能量突变+重构误差大，先把它当"疑似异常"挂到待办列表，积累几周后，把确认过的子集回流进入训练集。

4.2 重采样技术的神与坑：SMOTE用在时域波形上为什么翻车

SMOTE的核心逻辑是：在少数类的K近邻之间做线性插值，合成新样本。在表格数据上这套方法很有效，但在振动波形上直接操作，产出的样本会变得非常奇怪。原因在于振动信号是高维强周期信号，直接对两个时域样本做逐点插值，等价于把两段不同相位的波形"平均"在一起，冲击成分的周期性和幅值调制关系全部被破坏。合成的样本既不像A，也不像B，喂给模型只会让模型学到一种"四不像"的形态。

类间重叠是另一个问题。欠采样（随机丢掉多数类样本）能快速改善比例，但可能会丢掉携带重要边际信息的正常样本，导致模型把"正常"边界学偏。过采样对少数类反复复制，又会带来严重的过拟合。

4.3 结合物理的样本生成：分段过采样、包络插值、工况变换

在物理约束下，重采样可以做，但不是对原始波形做，而是对"物理成分空间"做。我的推荐路径是：先把振动信号做带通滤波、包络分析、阶比跟踪，把波形分解成"确定性冲击成分+背景噪声成分"。然后在确定性冲击成分的空间里做插值合成，最后再把背景噪声加回去。

这样一个"物理空间过采样"的流程，能保证合成样本的故障周期，和真实故障的物理周期一致。加上转速小幅扰动、噪声强度按实测水平随机注入，合成的样本多样性明显优于SMOTE，也更安全。我做内圈磨损诊断时，用这个方法把故障样本从12条扩到120条，模型在真实故障测试集上的召回率从0.62提升到0.89，且没有伤害到正常样本的误报率。

如果设备有多工况运行记录，工况变换生成法也是一个很强的办法：同一段真实故障样本，按物理模型把转速段按角度域重采样，模拟低转速下的故障形态。效果比完全人工合成更贴近真实，因为这其实是"物理约束的知识迁移"。

4.4 代价敏感学习：给少数类更高的错误代价

代价敏感学习不改数据分布，只改损失函数。它的核心调整公式，是把交叉熵损失中的每个样本的权重从1改成类别相关的代价系数：w_i = N_total / (N_class × K)，其中N_class是该类别样本数，K是总类别数。这样多数类权重会被压低，少数类被抬高。但权重拉得太高，模型会把所有边界样本都判成少数类，导致误报爆炸。

工业现场对"虚报"的容忍度比对"漏报"要高——漏报意味着设备带病运行直至报废甚至安全事故；误报意味着产线停车、人工复核、损失产量。不同的行业甚至不同的工序段，对二者的容忍度都不同。这不该是拍脑袋决定的，建议把代价矩阵直接做成配置文件，方便现场按成本结构调整。每次调整完，固定一组代表性样本集做回归校验，防止新模型把旧故障判丢。

评价指标也要跟着换掉。Accuracy在极度不平衡的数据上是骗局，F1-score和G-mean才能反映真实性能。G-mean = sqrt(正常类召回率 × 故障类召回率)，直观解释是"正常和故障都不能太差"。

4.5 对比学习加持：无监督异常表征的兜底玩法

有标签的故障样本太少，但正常样本特别多。这正好可以利用起来做对比学习（Contrastive Learning），核心思路是构造正负样本对，让模型学会"同类样本特征靠近、异类样本特征远离"。

对比学习在工业诊断里的用途不是直接做分类，而是学一个特征空间。在这个空间里，正常样本因为数据量大、形态多样，会被压缩在一个紧凑的区域内；故障样本因为物理上根本不属于这个区域，自然会偏离出去。然后设一个距离阈值，超阈值就触发"疑似异常"。这种方法不需要故障样本参与训练，只拿正常样本做自监督学习，选好增广策略是关键——工业信号上的裁剪、加噪、缩放都要保证不破坏物理周期。单独的对比学习模型也能兜底：把它的输出置信度与规则式异常检测、物理统计量计算做投票，形成"三防"兜底。

5. 实时部署框架：精度之外的硬骨头

5.1 部署路线的选型：边缘盒子、工控机还是嵌入式板卡

选择部署硬件时，算力只是最表面的约束。很多时候瓶颈在IO、在中间层传输、在兼容性上。三条路线的优缺点如下表所示：

以8通道振动采集、每通道25600Hz采样率、实时诊断为例：8×25600×2字节≈400KB/s的数据量，算力需求其实并不高，INT8量化后的一个小型CNN就能在嵌入式平台跑得很稳。所以大多数工业场景真正卡脖子的不是推理算力，而是确定性、接口协议和模型更新流程。

5.2 模型轻量化实战：量化、裁剪和蒸馏的三板斧

质量好的模型拿到部署阶段，首先考虑的是TensorRT（英伟达GPU路线）或OpenVINO（Intel CPU路线）进行量化。INT8量化掉几个点的精度，换来两倍以上吞吐和更低的功耗，在工业场景通常值得做。精度回退明显的场景，试一下混合量化：只把卷积层和全连接层量化到INT8，把BN层和残差连接保持FP32，通常能恢复大部分精度损失。

如无GPU条件，就用分层裁剪和知识蒸馏。大模型（教师网络）在离线环境中进行细致的物理约束训练，小模型（学生网络）拿大模型输出的软标签（soft label）去学习。蒸馏的关键是温度参数T：T太高，软标签变得过于平滑；T太低，几乎退化成硬标签。实测T=3到5之间效果更好。对于工业诊断模型，输入维度往往已经在预处理阶段大幅压缩，模型本身不需要太大，过参数化反而带来过拟合加部署双重负担。

5.3 推理的时序确定性与血流式处理

实时诊断链路完全是流式处理：采集板卡获取新数据，送入预处理模块（带通滤波、FFT、特征频率提取），再送入模型推理，最后逻辑解析模块输出诊断结论。任何一环卡顿，整个链路就失去实时性。

最怕的是推理时延抖动。一次推理的平均耗时50ms，不代表每次都50ms——细节上，CPU的缓存热不热、GPU频率升降、共享内存的竞争，都能让单次推理跑到70ms、80ms。安全联锁要的是"绝不超时"，这单靠模型优化做不到，得用软件架构顶住。

可行的做法是双缓冲加定时触发推理线程：采集线程持续写数据，推理线程以固定周期（比如50ms）从缓冲队列取最新一帧做推理，不做快照运算，也就是说永远先处理时序上"如果超过阈值就告警"的脚步。同时，把待处理数据帧打上时间戳，输出时带上推理延迟统计。一旦发现延迟末尾的延迟（tail latency）超过阈值，就实时调整执行策略（比如暂缓日志输出频度），确保告警路径永远是最高优先级。

5.4 告警联动与解释性输出：现场运维人员凭什么信你

一个跑在实验室里的模型，输出"内圈故障，置信度0.93"，算法团队会觉得很好。到了现场如果也是这样呈现，运维老师傅会把鼠标一扔："你给我看这个轴承怎么坏了？"

部署框架里必须包含一个"运维可解释层"。告警输出至少要有三块内容：故障类型、物理依据（特征频率计算过程、频谱图上圈出的关键峰值）、置信度/风险等级。有条件的话配上时域冲击波形和同型号设备的历史对比曲线。用大白话说就是：告警不只是"盒子亮了"，而是像老诊断工程师一样把证据链列出来。

证据链的形式可以是：故障特征频率计算为118.7Hz，FFT显示峰值在119.2Hz（偏差0.4%），包络谱中在2倍频处有明显谐波，主轴转速24.5Hz无异常波动，据此判断为轴承内圈早期损伤。置信等级：中。这一套下来，老师傅就知道"这系统是真的懂轴承"，才会愿意配合你迭代优化。

5.5 部署后运维：模型版本回退与样本回流闭环

部署框架要点是"可回退、可观测、可持续迭代"。每一个新模型上线前，本地必须保留上一个版本的完整配置和权重。上线后至少跑一周的"影子模式"：模型推理照常执行，但结果只做记录不参与控制逻辑，这样能积累一批新旧模型行为的比对结果，避免新模型在某个罕见工况上直接误动作。

样本回流闭环更是决定框架使用寿命的部分。诊断系统上线后，每天都会产生大量的推理结果和原始波形，一般建议把"置信度介于0.4到0.8之间"的样本自动挑出来做半自动标注池，每周定期由设备工程师人工复核并打标签，回流到训练集，形成"数据越用越多、模型越用越准"的正循环。这种机制比任何离线训练的模型都要可靠得多。

6. 端到端框架组装：把四件事拧成一条流水线

6.1 框架总体数据流与模块职责划分

整个框架从数据到决策可以拆成七个模块，每个模块职责独立、接口清晰：

• 采集模块：PLC/DAQ数据接入，统一时钟源，原始数据缓存（一周以上），原始波形本地落盘
• 预处理模块：数字滤波、解调、FFT、阶比跟踪，输出固定格式的特征矩阵
• 物理基准模块：根据设备参数计算特征频率、正常工况基线、故障物理规则
• 样本治理模块：自动标注合并、不平衡处理、物理合成样本生成、版本管理
• 训练模块：模型自动训练、基于验证机群的超参搜索、物理Loss注入、模型仓库记录
• 推理模块：量化模型加载、确定性调度、推理延迟统计、影子模式切换
• 联动与反馈模块：告警输出、PLC联动、误报标注、样本回流

数据流从采集到预处理到推理是前向的单向链路；样本回流和模型更新则是反馈链路，从部署侧回到训练侧。治理模块出来的每一批新数据集都对应一个有版本编号的模型包，训练和治理全程可追溯。

6.2 一次典型接入流程：新设备上线需要几步

以一台新泵组接入框架为例，全部流程做下来大概一周到两周：

1. 采集设备挂上，确定采样率（25600Hz）、传感器安装位置（尽量靠近轴承座、刚性固定）
2. 空载/健康状态下运行一天，采集基线数据，建立正常工况模型
3. 输入轴承型号与转速，计算出特征频率，配置物理基准
4. 在运行数据上按自监督方式训练正常表征模型，建立阈值基线
5. 找同类设备的历史维修记录，整理出可用的故障标签数据（哪怕只有十几条）
6. 治理模块合成并增强故障样本，训练诊断模型，在影子模式下与规则引擎并行
7. 影子模式运行两周，人工复核告警质量，确认误报率可接受后切换为主动告警

这套流程走完一遍之后，接入第二台新设备的时间能压缩到3天以内，大部分工作在配置层：改采集参数、改特征频率、改阈值，而不是重新写代码。

6.3 模型可解释性的工程化实现

模型解释性不再是锦上添花，而是工业部署的硬性要求。当前技术栈下有两个务实手段：一是Grad-CAM类热力图方法，在时域波形和频谱图上标出模型注意力集中的区域，用直观方式让人看到"模型在听哪个频段"；二是构建一个"规则翻译器"，把神经网络输出翻译成人类可读的物理语句——比如把"类别=2、特征频率=119.3Hz"翻译成"疑似轴承内圈故障，置信度中，建议检查润滑脂状态并在轴承座处做测振复核"。第二项很费功夫，但每一个现场认可度高的诊断框架，都有这一层。

6.4 场景扩展与框架的复用边界

这个框架对旋转机械设备诊断（电机、泵、风机、压缩机、齿轮箱、轧机）复用性最强，因为它核心的物理基础是旋转机械的阶次和特征频率理论。延伸到非旋转设备（比如液压系统、电池模组）时，物理基准模块需要重构，但数据流框架和治理模块基本不变。延伸到视觉类缺陷检测时，物理约束模块退化为几何约束和材质先验，整体框架依然适用。

所以它更多是"可复用的方法论"而非写死的程序库。框架中的物理约束核心价值在于：让模型在"见过的数据"和"没见过的工况"之间仍然保持合理行为。

6.5 我从这套流程里提炼的三条核心经验

第一，物理约束不是拖慢进度的学术装饰，而是工业落地最省事的捷径。不做物理约束，模型迁移一次就要重训一次，每次都要重新标注故障数据，时间成本高到无法承受。做了物理约束，跨工况复用一套模型成为可能，后期成本省一大笔。

第二，数据治理和模型训练的工作量配比不合理的话，框架整体会失衡。做了这么多项目，我观察到的靠谱配比是数据治理、物理基准建设和部署工程各占三成，模型训练本身只占一成。算法技术重要，但它只是在成熟流水线上消耗结构化数据的那一层。

第三，部署阶段不能只追求模型的平均精度，要盯住极端样例和最坏时延。工业现场不关心模型的平均表现，它只关心极端时刻的表现：某个罕见工况下会不会误报、某次采样延迟是否超限。把尾部风险管住，系统才算真正能用。

7. 我踩过的一些坑和后来的解法

物理损失调参，有过一次经验教训。某次对齿轮箱做诊断，λ设成0.5，训练初期物理损失就小，但分类损失迟迟不降，后来一查才发现物理项把模型约束死了，迫使模型输出所有故障类别都"物理正确"，但类间的差异没了。后面改成先热身，前几个epoch只跑分类损失，等模型基础收敛之后再加物理约束，效果稳定得多。

过采样环节也栽过跟头。尝试过用GAN生成故障样本，样本多样性是不错，但训练不太稳定，时不时生成出一个频率完全不对的样本。后来把GAN生成的候选样本全部经过"物理过滤器"（自动计算特征频率并核对偏差），不合格的直接丢弃，才在生产环境稳定下来。凡是数据管线和物理约束冲突的地方，标准答案都是让物理当裁判。

部署环节最大的教训在Python推理服务上。最初的实现是Python多线程直接调ONNX Runtime，本质上问题不大，但GIL和跨线程调度最终会在高并发时产生难以解释的推理延迟抖动。改用进程内双缓冲和独立推理线程之后，尾延迟（P99）从85ms降到64ms，安全联锁也终于能驱动现场控制逻辑了。这类问题不是模型的问题，是架构设计的问题，而框架要解决的恰恰就是架构问题。

另外类间阈值始终存在两难。漏报代价大于误报的场景，把告警阈值调低、走"宁可信其有"的路线，并让告警文案明确标注"疑似"，给运维人工复核留时间；对安全性要求极高的设备，甚至可以把"疑似"也加入推动联锁停车逻辑。但这类策略一定要通过配置开关下发，而不是改代码去调整。

最后再分享一个琐碎但影响体验的细节：诊断结果里附带频谱图、包络谱、特征频率标注、同型号设备对比曲线，哪怕是纯文字报告，现场留存和事后追溯都会顺利很多。这种做法不增加模型能力，也不改变任何算法，但能让运维团队对一个无人值守的AI系统产生长期信任。而这，才是这个框架真正想解决的事情。