点击上方蓝字 关注寄云科技！
作者：寄云科技CEO 时培昕
系统孤岛
阻碍了大模型获得有效数据
大模型之所以能够给出准确的答案，前提是获得了很多互联网、文献、专利的高质量数据，并通过一系列蒸馏和微调形成高质量的答案。但是在工业企业中，按专业建设的大量系统孤岛造成了大模型举步维艰的局面。
工业信息化数十年的演进轨迹，本质上是一部系统分裂史。在效率优先的时代逻辑下，企业为每个业务环节量身定制信息系统：ERP处理订单，MES管理生产，SCADA监控设备，DCS来实现自动化控制，每个系统都是独立王国的数字映射。这些系统使用不同的通信协议，就像使用不同方言的族群，虽然共同维系着工厂运转，但彼此间的对话需要复杂的"翻译"机制。原先大家都是自成体系、需要人来去中间充当翻译者的时代，虽然损失了很多效率，但是运转良好；但是当大模型试图穿透这些系统获取数据时，首先遭遇的是物理接口的封闭性和数据协议的排他性。
对于自动化系统来说，每个自动化系统往往都是由不同自动化厂家来实现垂直集成，很少能跟第三方兼容，即使有ModBus、OPC UA和SECS/GEM这种标准化通信协议，也只能在有限范围内发挥作用。因此企业很难从一个更广泛的维度来获取所有自动化系统的数据，形成统一的监控、分析和决策能力，更不具备将多个自动化系统的数据进行汇总来实现跨自动化系统的工艺、质量、能耗、安全等方面的分析能力。
而对于按照部门或者专业建设的每一套业务系统，也并不是从跨部门协同的角度出发，不仅难以给出标准的API接口实现数据共享和交换，甚至在包括设备编码、物料编号、人员代码等跨系统的数据，在不同系统中也有着千差万别的定义方式。这就造成了企业决策者如果要从多个生产管理系统、ERP系统、供应链管理、销售系统中获得实时准确的数据，来跨系统、跨部门的实现实时的产能、效率、成本、交期的分析变得极其困难，而被迫采用了依赖人的理解去抄录不同系统中的数据，通过Excel表格计算，再填写到独立的商业智能系统中。
如果要让大模型真正进入工业企业发挥大范围，而不是仅在单独一个系统的作用发挥作用，那么需要将不同的IT和OT系统的隔阂打开，提供便捷的接口，方便大模型获得有效的数据，这不仅仅是企业基础IT架构的变革，更涉及到部门数据共享的文化问题。
多模态的历史数据难以处理
工业数据的多样性远超常人想象。一条普通产线每日产生的数据包含设备状态、设备振动频谱、红外热成像、金属应力波形、量检测结果等数十种模态，这些数据以结构化或者非结构化的多模态形式分散在MES、ERP、SCADA、QMS等异构系统中。
对于工业企业来说，非结构化数据的处理尤为棘手。当大模型面对化工行业P&ID设计图纸时，不只是需要解析出结构化的图元并建立它们之间的上下连接关系，还往往需要借助OCR技术提取图纸中关于设备编号、测点编号的信息，以便于将其关联到DCS的点表信息进行查询。同时，还有海量需要经过扫描才能录入的质检记录、运维记录、故障报修记录，基于震动分析的高频CMS数据，以及大量现场采集的基于安全生产的视频记录，都需要处理成可以被大模型识别的数据。
这些历史的、多模态的数据资产，如果没有加以转换、关联和映射，一定会产生大模型训练难以逾越的障碍。
舍本逐末，忽视数据的基础作用
工业企业的决策者从多年前不相信人工智能的一个极端，经过这两年的人工智能的知识爆炸，往往又进入了另一个极端，即将大模型理解为包治百病的工具，而忽视了底层的基本逻辑，即无论是小模型还是大模型，都高度依赖高质量和全面的数据治理能力。
同其他行业相比，工业数据不仅多样化、封闭，还具有如下的特点：
1
上下文的关联：
工业数据从来都不是独立的，都是上下文强相关的。如果不做好相关的数据映射，很难让大模型发挥作用。
一个设备的编码和使用手册可能存在EAM系统中，而实时数据的点表信息可能保存在DCS里面，如果用户需要检查某某设备的出口压力是否越界，需要先在EAM里面查询某某设备对应的设备编号，通过设备编号获得出口压力的实时数据，再把实时数据与EAM中的手册进行比对看看是否落在手册规定的工作范围以内。如果让大模型来完成这样“帮我检查某某设备的出口压力是否正常”的查询，在没有做好设备名称、设备编码、实时点位信息这些的映射之前，大模型没有办法理解用户的输入，更不可能给出准确的答案。
再比如，一个工艺参数的合理性或者一个设备的能耗，往往需要结合当前设备的状态、物料的属性、配方的版本以及前序工艺的完成情况来判断，而这些判定的数据往往来自不同的MES、RMS、QMS、TPM等系统，必须依赖人的手动查询和分析才能理解，在这种功能情况下很难让一个通用的大模型给出准确的工艺或者能耗优化的答案。
对于大模型来说，它面临的挑战在于，它必须从离散的数据片段中重建这种隐性关联网络，并且与企业确定的工艺流程、生产流程以及相应的数据结构匹配起来。当尝试分析设备故障时，大模型不仅需要读取SCADA系统的实时数据，还要理解维修记录中的文本描述，追溯工艺文档中的参数标准，甚至解析设备图纸中的结构特征。这种跨系统、跨模态的关联推理，相当于要求机器具备人类工程师二十年积累的领域直觉，当前的技术路径尚无法实现这种认知跃迁。
2
数据标准：
工业数据呈现出独特的"布朗运动"的不规则、随意特征。
在设备编码系统中，既有遵循ISO标准的规范编码，也有维修人员随手标注的临时编号；工艺参数记录可能混合了自动采集的数值与人工估算的近似值；设备日志中的故障描述更是充满了个性化表达。这种数据混沌状态的形成，源自工业化进程中人与机器长期共生的特殊生态——系统需要保持对人为干预的包容性，却因此牺牲了机器可读的精确性。
举一个例子。同一台设备在维护系统被称为"离心机-03"，在能源管理系统中变成"动力单元A-7"，在工艺文档里可能简化为"分离装置"。人类工程师凭借经验和上下文能理解这些符号的映射关系，但对大模型而言，这相当于要求它同时掌握多种方言的俚语体系。这种命名体系的随意性，在绝大部分工业企业中都普遍存在，不仅暴露了工业数据标准化的原始状态，也揭示了大模型落地必须跨越的第一道认知门槛。
3
数据质量：
数据质量的参差更形成致命制约。工业自动化系统的时序数据，往往会存在设备之间时间戳不同步的情况，很多时候还会出现由于传感器、网络的问题造成的数据缺失。同时，工业现场的温度漂移、设备震动、电磁干扰，使得传感器数据普遍存在5%-15%的噪声。这种数据源头的不可控性，迫使企业不得不建立投入巨大的人力和物理来实现数据清洗，而该系统的建设成本往往超过模型开发本身。
对于大模型来说，数据质量的参差直接导致大模型训练的"认知扭曲"。当大模型试图从设备历史数据中学习故障规律时，同一物理量在不同系统中的计量单位差异、同一事件在不同日志中的描述偏差，都会在让大模型在分析中产生误判，给出错误的答案。更隐蔽的风险在于，某些关键参数可能因为人为习惯被系统性忽略或误标，这种偏差会随着数据规模的扩大被算法强化，最终导致"垃圾进，垃圾出"的智能化悖论。
叶公好龙，过分追逐
大模型而忽视了小模型的作用
OpenAI和DeepSeek在文字、图像和视频等数据上所展示出来的卓越的理解、推理和分析能力，让很多客户自然会希望不只是将其简单应用在一些文档的分析和生成上，而是将其应用在工业的生产场景上，通过数据分析来解决历史遗留的设备可靠性、工艺稳定性、计划排程、质量诊断和预测以及能耗优化等方面。
但是，上面提到的任何一个场景，在大模型出现之前，都是需要将专业知识和数据分析紧密结合才能实现的，即所谓的“小模型”，并且很难有通用的解决方案。
比如，针对保温炉能耗的分析优化，我们不仅需要知道当前设备的工作状态，还需要获得设备的当前生产的产品类型、设置的温度检测范围以及温控系统高低档的参数，并且筛选出合格品批次对应的所有能耗数据，才能知道生产合格品需要的最高和最低能耗，才能将多个最低能耗产品对应的参数固化下来，调整温度检测和高低档的控制参数。
可以想象，在这种场景下，如果只是简单的咨询大模型关于保温炉的能耗优化方案，大模型也只是在自己的知识库里面检索相应的文献和行业知识，给出通用的建议。
那能否把这些需要的数据给到大模型，让大模型模拟人的分析行为来给出准确的建议呢？
首先，大模型理论上是大语言模型，如果人希望大模型来做数据分析，大模型会根据用户的输入推理出用户需要解决的问题，同时查询海量知识库来获得相应的分析方法，并自动生成相应的算法和程序，执行程序来实现模型的训练和评价，并挑选出满足预期准确值的答案组合给客户。这里的分析算法，仍然还是常规工程师分析的回归、SVM、随机森林等算法，并不是大模型发明的新的算法。因此，大模型的效果并不会比人工分析要更准确，只是它的效率通过自动化的工作流得到了提升。
其次，大模型的分析结果，如果没有要求其使用特定的分析方法，那么大模型每次可能都会采用不同的算法（比如第一次用线性而第二次用非线性）来获得高质量的结果，但是一旦更换了训练的数据集就会造成完全不一样、甚至错误的结果，不仅对于持续使用固定的分析模型非常不利，也需要人员的大量干预才能判定其准确性。
因此，大模型核心在于文字的理解、任务分解和自动化执行，真正解决问题还得依赖针对不同场景下的、碎片化的、无法用通用算法来实现的小模型。
工业智能应用开发：
遥不可及的愿望
工业企业对应用的开发需求，从来都是提出需求、寻找合适的乙方再进行定制开发，很少有自行高效开发的能力。而基于用户需求、利用Cursor、MGX这样的大模型自动生成代码工具的能力，曾让工业界期待大模型能自动生成高质量应用。
但现实远比设想复杂：当用户提出"开发设备健康评估系统"的需求时，大模型不仅需要根据知识库设计出页面的前端原型并生成代码，还需要理解这个需求背后隐含的数十个数据源、上百个关联参数、多个分析模型的组合逻辑，并且自动生成功能模块之间的数据结构。不仅如此，代码生成的记忆能力限制，经常会让使用者哭笑不得，往往修改了一个功能，又把前面修改过的功能改回去了。
大模型在工业应用代码生成中表现出的"表面智能"，恰恰暴露了其对工业系统深层逻辑的无知。它可能完美实现用户描述的功能页面，却忽略数据接入的实时性要求，无视控制系统的安全约束，甚至混淆不同的数据结构。这种"正确但不可用"的解决方案，反映出当前大模型技术对工业系统复杂性认知的结构性缺失。
组织进化的文化阻碍
从提高效率、解决历史遗留问题并走向智能化的角度出发，工业企业决策者对大模型的态度一定是积极拥抱的，但是这种初衷必须与企业的文化和实际基础紧密结合起来。
首先，恐惧心理带来的阻力一定会出现。大部分的执行者在AI时代到来的时候，首先想到的是“我会不会被AI所代替”，而不是去主动思考如何将AI用于新的应用场景来提高工作效率和解决问题，进而抵制企业决策者在AI方面的推广策略。
其次，工业体系百年形成的"确定文化"——强调流程规范、风险规避、线性思维，与AI时代的"试错文化"——主张快速迭代、容错机制、非线性创新，产生激烈碰撞。如果没有好的技术评价体系和激励机制，没有人愿意承担由于AI的不确定性带来的责任。
第三，同数字化转型类似，AI转型也是一个自顶向下的推动过程，如果企业决策者只是将工作交给IT部门，而不理解AI本身的内在逻辑和适用范围、不去积极组织各个部门的负责人深入思考AI如何与各个部门的业务结合、不去学习行业优秀案例，那么最后一定会演变成企业采购了一堆无用的算力、做了一堆无用的工作流的局面。
总结
站在工业文明与智能文明交汇的转折点，企业需要抛弃叶公好龙的想法，需要清醒认识到，大模型不是包治百病的灵丹妙药，而是需要精心适配的新型生产工具。
唯有正视现实鸿沟，重构技术、数据、方法、组织的底层基础，才能让工业智能化突破理想主义的迷雾，真正驶向价值创造的彼岸。
往期推荐
