制造 AI — 工厂数据对模型的要求
制造 AI 的难点不在模型，而在数据本身的特性。 工厂信号几乎没有标签，其分布会随运行条件变化，缺失值与 0 值的含义也不同。此外，错误答案的代价并不对称——漏掉一次故障和产生一百次误报，会以不同方式破坏工厂运行。
本文从这些特性出发，梳理由此需要采用怎样的设计。示例取自 PlantPulse AI 的实际实现，但其中的观点并不局限于产品，而是适用于一般的制造 AI。
数据科学家、设备工程师以及评估引入 AI 的技术负责人。本文会直接使用时序、嵌入、RAG 等术语，不再另行解释。产品功能列表请参阅 AI 功能一览，模型本身请参阅 AURA 技术白皮书。
1. 工厂信号有何不同
常规机器学习教材中的假设——独立同分布、充足的标签、正常的缺失值处理——在工厂中大多不成立。
| 特性 | 含义 | 对设计的影响 |
|---|---|---|
| 没有标签 | 故障很少发生，即使发生故障，也极少会记录到具体原因 | 与监督学习分类器相比，以学习正常状态并测量偏离程度为基础的方法（重构误差、预测误差）更为适用 |
| 运行条件会变化 | «正常» 状态的形态会随负载、产品、季节和班次变化 | 固定阈值会在条件变化时产生大量误报。必须单独处理困难正常样本（看似异常的高负载区间） |
| 0 与 «未知» 不同 | 「工单 0 条」是测量结果，而「CMMS 连接中断」并不是测量结果 | 一旦用 0 填充缺失值，从未被观测的设备就会被报告为 «正常» |
| 信号依附于层级结构 | 单个标签隶属于设备、产线、区域和站点 | 将「3 号产线压缩机」转换为层级节点的步骤，会成为所有查询的第一步 |
| 原因存在于先后顺序中 | 即使是相同的两个信号，哪一方先上升，也可能对应不同的故障 | 只看相关性的模型无法区分故障。必须识别领先与滞后 |
| 错误答案的代价不对称 | 漏检会损失设备，误报则会失去人的信任 | 必须将误报与漏检分开统计，并在产品中提供抑制报警的途径 |
最后一点往往被低估。误报不断累积后，操作人员最终会关闭异常检测。关闭的检测器无法发现任何问题——准确率达到 99% 的模型，一旦被关闭，效果就是 0%。
2. 分层处理——不依赖一个大模型解决所有问题
如果把制造 AI 设计成 «把传感器数据交给大语言模型»，三个问题会同时出现。秒级波形转换为 token 后过于冗长，语言模型并不擅长从数值模式中发现异常，更重要的是，它会煞有介事地编造从未测量过的值。
因此，需要按照任务性质进行分层。
질문 「3라인 압축기 요즘 어때?」
│
┌──────────────────────────────▼──────────────────────────────┐
│ ④ 설명 — 언어모델 │
│ 도구를 골라 부르고, 결과와 문서를 읽고, 근거와 함께 답한다 │
└───────┬──────────────────────┬──────────────────────┬───────┘
│ 도구 호출 │ 도구 호출 │ 검색
┌───────▼────────┐ ┌────────▼────────┐ ┌────────▼────────┐
│ ③ 시계열 모델 │ │ ② 통계 · 규칙 │ │ 문서 검색 (RAG) │
│ 이상 · 예측 │ │ 기준선 편차 · 공식 │ │ 절차서 · 이력 │
└───────┬────────┘ └────────┬────────┘ └─────────────────┘
└──────────┬───────────┘
┌───────▼────────┐
│ ① 데이터 원장 │ 시계열 · 알람 · 작업지시 · 설비 계층
└────────────────┘
| 层 | 擅长什么 | 不负责什么 |
|---|---|---|
| ② 统计与规则 | 相对设备日常基线的偏差、工程公式（OEE、MTBF、轴承故障频率） | 多变量模式 |
| ③ 时序模型 | 多个通道共同形成的异常 «形态»、短期趋势 | 原因说明、文档比对 |
| ④ 语言模型 | 选择工具、汇总结果、与规程进行比对、用自然语言解释 | 生成数值 |
下层可以解决的问题，不交给上层。 实际案例中，仅凭相对基线的偏差就能区分异常区间；这类区间不需要使用模型。计算由公式完成，语言模型只读取并解释计算结果——一旦让语言模型 «估算» L10 寿命，就无法再验证答案。
3. 异常检测——学习正常状态并测量偏离程度
由于没有标签，无法训练 «故障分类器»。因此，可以使用重构正常信号的模型，并以重构偏差作为异常分数。PlantPulse 使用 IBM Granite TSPulse。
同时考察两类误差
| 分数模式 | 测量什么 | 检测什么 |
|---|---|---|
| 时域重构 | 原始信号与重构结果之间的差异 | 突变、尖峰、水平漂移 |
| 频域重构 | 频谱差异 | 振动形态变化——平均值不变，但 «抖动» 发生变化的情况 |
旋转设备的早期故障通常首先出现在频域中。振幅仍然正常，但特定频段开始增长。只观察时域就会漏掉这种变化。
某些时序库只要支持模式列表中的任意一种就会通过验证，并且会无异常、无警告地丢弃不支持的模式。系统可能一直以「已启用水平偏差分数」的配置运行，实际上却什么也没有启用——这是经实测确认的问题（2026-09）。
PlantPulse 会将模式逐一提交给库检查；只要其中混入任何模型不会计算的模式，就拒绝加载。不同模型支持的模式集合不同（重构模型与预测模型并不重叠），因此更换模型后，相同配置可能具有不同含义。
上下文长度与短历史数据
TSPulse 以 512 步窗口作为输入。设备刚接入或历史数据较短时，窗口长度会不足。此时有两种选择。
- 拒绝处理——新设备在一段时间内无法获得任何判定
- 填充左侧——重复最早的值以填满窗口（edge padding）
PlantPulse 在数据至少有 32 行时采用后一种方式，少于 32 行则拒绝处理。填充后虽然可以生成判定，但填充越多，判定依据越薄弱——不要将短历史设备的异常分数与长历史设备的异常分数等同看待。
«提供抑制途径» 比阈值更重要
无论阈值设置得多好，现场仍会存在一些频繁出现但并非问题的情况。解决方法不是进一步收紧阈值，而是让操作人员能够抑制这些报警。
- 将频繁出现的项目连同次数和最近发生时间列出，并建议「提高阈值 / 评估静默」或「继续观察」
- 静默只停止通知和事件升级，不删除检测记录。 不能丢失后续追溯所需的依据
- 确认操作只能执行一次，并记录最先确认的人员和时间
相关界面请参阅 TimeSeries-Insight。
4. 预测——没有区间就不是真正的预测
趋势预测使用 TinyTimeMixer(TTM)。上下文长度为 512 步，单次最多预测未来 96 步——由于模型按该长度训练，因此超出范围的请求会被拒绝，而不是被静默截断。如果历史数据不足 512 步，则根据实际可用的上下文长度缩短输入，并在响应中一并返回缩短后的值。
使用区间，而不是点预测
「下周轴承温度为 78℃」的实用价值不大。操作人员真正需要的是「10～90% 分位区间为 72～84℃，且上限将触及报警线」（默认分位数为 0.1 和 0.9）。PlantPulse 在预测之后执行 conformal 校准来生成区间。
- 在历史数据中滑动窗口，生成 «如果当时进行预测» 所得到的预测值
- 收集这些预测值与实际发生值之间的残差
- 根据残差分位数确定当前预测的上限和下限
这种方法不是让模型自行描述不确定性，而是依据该模型在这台设备上实际产生过多大误差来确定区间。由于不需要分布假设，因此适合工业信号这类厚尾数据。
如果平均值为 1500 kPa 的压力标签存在缺失值，并用 0 进行填充，该窗口的残差就会变成 |1500 − 0|。此时，分位数反映的将不是预测误差，而是缺失值的幅度，区间会变得极其宽泛——但系统仍然会显示「区间计算成功」。
PlantPulse 会从校准集中排除包含缺失值的窗口，以及末尾尚无实测值的窗口。如果剩余窗口数量不足，则不输出区间，并在响应中说明原因（「请提供更多历史数据」）。没有区间，也比错误区间更好。
5. 静默失败——制造 AI 中代价最高的缺陷
制造 AI 事故通常发生在没有报错的一侧。服务返回 200，健康检查显示绿色，数值看起来也很合理，但生成这些数值的并不是模型。
以下是实际遇到过的三种形式。
| 形式 | 发生了什么 | 如何防止 |
|---|---|---|
| 回退结果冒充模型结果 | 数据不足导致模型无法运行时，系统降级为简单外推（drift、seasonal-naive），但响应仍为 200 | 在响应中返回 model_used 和 fallback_reason。调用方必须读取并记录这些字段——NAIVE 比例上升本身就是一个信号 |
| 随机权重挂上模型名称 | 预测模型的两个代际（R2、R3）之间没有任何权重键重叠，却可以无异常地读取对方的检查点。结果是一个全部 445 个参数均被随机初始化的模型，挂着 TTM 的名称返回答案 | 加载时，只要发现任何检查点中不存在而新建的参数，就拒绝加载 |
| 配置错误被当作临时失败吸收 | 上述配置错误被回退机制吸收，系统以 «健康状态正常、预测返回 200、所有结果均为简单外推» 的状态运行 | 将失败分为两类。重试也无法恢复的问题（配置错误、GPU 故障）返回 500 或 503；只有临时问题（数据不足）才允许回退 |
概括起来，规则只有一条——所有输出都必须附带 «由什么生成» 的信息。 是模型还是回退机制，区间已计算还是被跳过，判定使用了多少行数据。如果缺少这些信息，就没有人能够确认正在运行的 AI 是否真的使用了 AI。
即使预测配置错误，同一进程仍会继续提供异常检测服务，因此 /health 仍然正常。健康检查无法进一步保证 «答案正确»。因此，需要在启动日志中用一行记录模型加载结果（[MODEL_LOAD]、[MODEL_LOAD_FAIL]、[MODEL_WARMUP_FAIL]），并对该日志行进行监控。
6. 原因存在于先后顺序中——故障机制
「温度升高」可能有多种原因：轴承磨损、润滑不足、冷却异常、电气故障、污垢沉积。区分这些原因的依据不是数值大小，而是什么先变化、什么同时变化。
| 故障 | 先出现的信号 | 随后出现的信号 |
|---|---|---|
| 轴承磨损 | 振动上升 | 温度随之上升、故障频率谐波 |
| 润滑不足 | 润滑油流量下降 | 摩擦热导致温度急剧上升 |
| 冷却异常 | 冷却水流量下降 | 只有温度上升（振动正常） |
| 电气故障 | 电流不平衡 | 功耗与温度同时上升 |
| 空化 | 宽带噪声急剧增加 | 排出量下降 → 功率下降 |
判断规则如下：如果振动同时上升，更可能是机械原因；如果只有温度上升，更可能是冷却或污垢沉积问题；如果润滑油流量先下降，那么温度急剧上升是结果，而不是原因。此外，其他故障模式都会使功率上升，而只有空化会导致功率下降，因此可以据此区分。完整映射（11 类故障 × 18 类设备）请参阅 AURA 技术白皮书 第 5、6 章。
关键在于，仅靠同期相关性无法完成这种区分——相关性是对称的，而故障是非对称的。因此，需要同时采用以下两种方法。
- 时滞互相关。 标签关系分析会针对同期相关性较高的标签对，向前后移动时滞（最多 ±10 个样本），查找相关性达到最大值时的时滞；如果该时滞不为 0，则输出为领先—滞后标签对
- 教授故障机制的结构。 不向模型提供「症状 → 答案」形式的数据，而是提供带有时间轴的演化轨迹，并让模型在判定时输出「温度在 D+11 先上升，振动在 D+19 随后上升——热学原因在先」这类包含数值和时间范围的依据说明，因为结果必须能够由人验证
如果在选择分析列之前就将整张表转换为数值，时间戳会被转换成纳秒整数，并像标签一样混入分析。由于其单调递增，与任何信号的相关性都接近 1，最终诊断中甚至出现了「timestamp 领先于温度」的结果（2026-07）。必须先排除时间列和标识符列，同时排除无变化的列——其相关系数没有定义。
历史案例也用于同样的目的：检查过去是否出现过相同形态的异常（相似异常搜索）、同类设备中是否有某台设备表现不同（设备群异常值）、故障前出现过的信号现在是否再次出现（征兆巡检）。这三种方法都以 «该设备的历史» 和 «相邻设备的当前状态» 为基线。
7. 解释——只依据证据回答
语言模型的职责是读取、选择和解释。一次查询大致按以下流程执行。
① 이름을 ID 로 「3라인 압축기」 → 설비 계층의 노드
② 도구를 고른다 분석 · 이력 · 알람 · 문서 · 사진 중 무엇이 필요한가
③ 데이터를 가져온다 이상 점수 · 건강 지수 · 태그 이력
④ 문서를 더 본다 절차서 · 고장 이력 · 규격
⑤ 모아서 답한다 근거를 붙여서
②～④ 并不会一次完成。智能体会根据工具结果反复选择下一个工具。在这种结构中，决定质量的因素有三个。
① 工具 schema。 模型能否正确选择工具并填写正确参数，直接决定答案质量。工具默认关闭，只有启用的工具才会对智能体可见。无关工具越多，选择准确率越低。此外，实测发现，提示词越长，模型调用工具的次数反而越少——增加说明并不总能带来收益。
② 检索质量决定答案上限。 工业文档中既包含标签名、零件号、规范条款等必须精确匹配的字符串，也包含「更换周期」与「维护间隔」这类含义相同但表达不同的内容。因此，需要同时使用关键词搜索（BM25）和语义搜索（嵌入），再由重排器从候选结果中选出真正能够回答问题的段落。嵌入维度应作为契约固定下来，这样即使更换模型，也不需要重建向量索引。完整流程请参阅 RAG 算法。
③ 明确回答不知道。 不将未采集的值报告为 «正常»，也不使用上下文中不存在的信息。这不是在提示词中增加一句话就能实现的——必须在训练数据中加入以暂缓判断为正确答案的问题，模型才会学会这样回答。这也是 AURA 训练数据中有三分之一为不作确定结论的原因。
8. 如何衡量——不使用裁判模型
工业 AI 没有排行榜。而且，如果让另一个语言模型负责评分，看似合理的错误答案往往会得到高分。因此，需要将评分过程机械化。
| 评估什么 | 以什么为标准 | 注意事项 |
|---|---|---|
| 工业计算 | 公式（30 类工程公式） | 将部分类型完全排除在训练之外，以区分模型只是记住了答案，还是确实掌握了方法 |
| 工具调用 | 生产系统中的实际 schema | 分别评估工具选择、参数以及多步骤连接 |
| 遵守依据 | 给定上下文 | 如果出现上下文中没有的事实，就是错误 |
| 现场诊断 | 实测数据和已记录故障 | 唯一由系统外部提供正确答案的维度。混入困难正常样本，并分别统计误报和漏检 |
另外还有两项原则。
- 验收标准必须在测量 «之前» 确定。 看完结果再制定标准，就不能称为标准
- 审核人员必须能够自行确认评估数据是否泄漏到训练数据中。 与其要求对方相信数字，不如提供重新测量的方法
9. 在哪里运行——为何默认采用本地部署
制造数据通常不能离开工厂。 工艺条件本身就是商业机密，而且很多工厂使用隔离网络。因此，系统应采用以下设计。
- 让模型靠近数据。 语言模型以量化检查点（NVFP4）的形式部署在单张 GPU 上，并运行在 OpenAI 兼容端点之后。即使配置中写着
gpt-4o，也只是内部模型使用的兼容名称 - 用小模型处理波形。 百万参数级时序模型无需 GPU 即可运行，因此可以部署在 Edge；即使针对每台设备单独调优，成本也几乎可以忽略——其规模足以支持 1 万台设备对应 1 万个模型（仍在研究中，尚未进入产品路径）
- 分离推理与入口。 将轻量 API 与使用 GPU 的推理服务器分开后，即使把推理迁移到其他设备或进行扩容，调用方使用的地址也不需要改变
- AI 不建立自己的数据库。 时序、关系型和缓存数据共用平台的数据源。如果数据保存为两份，«AI 看到的值» 就会与 «界面显示的值» 不一致
部署结构请参阅 AI 架构，四个产品之间的协作方式请参阅 整体架构。
引入前需要确认的事项
评估制造 AI 时，无论具体产品是什么，都值得提出以下问题。
| 问题 | 理想答案 |
|---|---|
| 如何处理缺失值 | 不使用 0 填充，而是单独报告「未测量」 |
| 模型无法运行时会输出什么 | 可以回退，但必须在响应中明确标注发生了回退 |
| 如何统计误报 | 与漏检分开统计。操作人员可以进行抑制，抑制后仍保留记录 |
| 预测是否包含区间 | 包含，而且区间来源于实测残差 |
| 语言模型是否生成数值 | 不生成。数值由公式和工具计算，语言模型只负责读取 |
| 性能指标如何测量 | 不使用裁判模型，预先确定标准，并让审核人员能够重新测量 |
| 数据是否会传到外部 | 不会。在隔离网络中也能以相同配置运行 |
延伸阅读
AURA 技术白皮书 — 如何构建和评估模型 · TimeSeries-Insight — 异常检测与预测的界面和工具 · RAG 算法 — 文档检索流程 · 数据湖技术白皮书 — 承载模型的数据基础设施 · 下载资料