历史数据库数据（与ML）

工厂里的一切ML雄心都绕不开一个不起眼的资产：历史数据库。OSIsoft PI、Wonderware、GE Proficy或自建SQL库——它存着模型所需的确切数据的多年积累，而且已经在那里了。从历史数据库起步的工厂数天拿到首批结果；先建数据湖的工厂往往要到下个财年。

模型需要它的什么

三件事，按痛感排序。分辨率：历史数据库会压缩（死区、旋转门算法）；激进的压缩可能恰好抹掉模型需要的瞬态。对照故障模式的要求核查实际存储的分辨率。标签语义：模型不在乎标签叫TT4711，但要依据归因行动的工程师在乎——认真做的部署都包含一轮标签映射。上下文：产品代码、批号、班次和换产标记把匿名时间序列变成工况感知的训练数据；没有它们，模型会把换产当成漂移。

实用顺序

以只读方式接入历史数据库、回填6–24个月、映射关键标签、补上上下文数据流（来自MES/ERP的产品和批号），然后让平台训练。各厂商在自动化程度上差异巨大——这比任何关于算法的问题都更值得在演示时问。

常见问题

ML平台需要多少历史数据库数据？

足以覆盖真实工况的正常生产——通常回填6–24个月。产品越多、季节性越强越靠上限；稳定的单一产品产线用更少也能起步。

要先清洗数据吗？

不必穷尽——现代平台容忍空洞和噪声。修那些会改变结论的：存储分辨率、关键变量的标签映射、工况上下文（产品/批号/班次）。追求完美的清洗工程就是项目势头的葬身之地。