前情回顾：上一期，我们从工业人的视角，看当前类GPT技术对职业发展的冲击和可能带来的变革。其中提到，简单重复的体力劳动会慢慢被机器人和自动化技术替代，而简单重复的脑力劳动则可能面临人工智能带来的挑战。更准确地说，积极使用和熟练使用这些新工具的人，未来的竞争力和能产生的价值会更大，会慢慢替代不会使用新工具的人。经过一段时间的过渡，将会形成新的经济社会分工，直到下一次变革到来。
本期摘要：当前工业数智化进程中，要应用人工智能技术，到底应该怎么做？有哪些可以做，有哪些能出成绩？有哪些坑需要避免？
Q1：人工智能模型=算法+算力+数据，如果说通用人工智能领域慢慢进入算力时代，那工业领域模型的发展进程如何？
通用人工智能，比如像文本、图像等处理，已经慢慢从数据时代往算力时代演进。大模型的训练已经不是一般个人玩家，或小型组织玩得起的了。有个隐性前提是，这个领域的算法和数据足够成熟，可以支撑暴力求解，算力的爆发力就显现出来了。而当一个瓶颈被突破了，优势被无限放大之后，肯定又会出现下一个瓶颈。
工业数据的应用具有隔离性、专业性和有限性。由于数据条件的制约，目前工业领域人工智能的应用相对通用领域来说，要滞后一些，还不到比拼算力的阶段。工业数据的信息密度比较低，比如大部分设备的运行状态都相对稳定，或是长期稳定在某个点，或是在一组开关机状态间循环。虽然数据量比较大，例如一个小时3600个点，也可能只在一个点附近有轻微噪声波动。真正能提取出来的有效数据并不多，远没有到需要算力去大力出奇迹的程度。
在数据问题解决之前，算力本身不会是瓶颈。随着数据的积累，也许会朝着（算力）这个方向发展。但我们还需要看到，工业数据背后产生的机制是物理定律，甚至很多时候可以用仿真模型很大程度上去逼近它，这也算是工业里面的一种优势。融入这些先验机理，能够很大程度弥补数据信息不足。
Q2:工业领域智能模型与通用智能模型之间有什么区别？工业领域模型当前的工作重点是什么？
工业领域模型和通用领域模型的形态不一样。工业场景中，语言处理类的模型相对比较少。类ChatGPT等语言模型跟面向生产运行过程的工业数据挖掘相比，不论从数据类型、支撑算法还是最终要解决的业务问题都不一样，也就不具有可比性。
如果说通用智能处于算力时代，那工业数字化当前还是处于数据时代。但这个数据时代，不是停留在数据收集，而是数据的可理解、可消费、可使用。
让数据智能成为工业企业的创新管道和价值管道，最费时间精力也最关键的一环就是业务解析和数据探索的匹配。需要理解底层的基本原理、其背后的业务逻辑，需要结合着前期调研、业务专家的分享，再对比数据去理解和相互印证。这个阶段的心智负担往往非常重，而这个环节打通之后，模型设计、模型开发也就相对轻松。
Q3：做业务解析和数据探索的匹配到底有没有必要性？
我们在数据理解阶段，就已经有意无意在梳理业务流程。比如生产制造领域，先理解工序，每一步都做了什么动作，大概是什么原理，过程中有非常多专业壁垒。再结合到每个工厂现场，还有特定的一些管理流程和管理特色。工序和管理流程交融到一起，往往会让数据很难理解。但是为什么非要费很大劲去理解这些东西呢？因为这些业务流程是那些数据产生的上下文。
某种程度上讲，数据不是我们的研究对象，其实我们研究的是数据背后相关的，比如设备、产线、生产过程甚至是操作的人，而数据是这些信息的载体，所以看数据其实是要透过数据，对相关的研究对象构建模型。
在这个行业从业多年的专家去看这些数据的时候，也要基于一些专业认知和上下文。但设备、工艺、排产和安全、环保，不同的人可能是从不同的角度去看。
当一个问题发生了，到底是属于哪一类问题，是什么原因导致的？哪怕是这个行业里的专家，也不可能面面俱到，什么因素都能穷举。且不同专业壁垒造成的隔离性比想象中更严重，不同领域的专家看同一套数据的方式和视角完全不同。
将数据基于不同的专业认知进行组合和关联，形成对物理对象的完整认知，是培养企业内部数据创新的基石。工业数字化的终极目标是全局优化。将集体智慧的专业认知基于数据进行重新融合的过程，就是领域数据建模。
领域数据是结合了工业行业的特定业务背景和业务知识的数据集，后续的数据价值挖掘和应用都以此为基础去展开。
领域模型一词不是起源于数据工程领域或者数据分析领域，而是起源于Eric Evans讲程序设计的书——《领域驱动设计》，其核心思想是使用共同业务语言构建开发者和业务专家之间的桥梁，并且让软件代码直观的表达业务逻辑，使得软件系统更加可维护、可理解、可扩展。
在领域驱动设计之前，很多程序员会陷入一个写程序的误区。比如要实现一个功能，他马上就会想到数据库表，先把表建出来，然后写很多handler来处理业务逻辑，再写一个很长的sql来体现业务逻辑。后面一旦需求变了，业务逻辑变了，通常他会把sql改一下。这种就叫做database加script编程模式。这种程序会非常难于理解，难以维护。因为很多业务逻辑隐藏在了那个可以执行但是一点儿表达力也没有的“贫血模型”里。
而领域模型是跟它相对的，它提倡使用程序设计的一些基本元素，比如实体对象，通过它的结构、标准的属性和命名，它的运行方法以及方法里简单直接的代码等等，把我想表达的业务规则直观呈现出来，而不是依赖于一些特定的数据库技术或者中间件。
我们借鉴了领域驱动设计的思想做数据工程，在数据治理的过程中，有意识地去做透彻的业务分析，使用标准业务术语，以数据模型的方式描述一些关键的业务规则。而不是看见一堆数据就加工一下，有新的需求就重复造轮子或者打补丁，这会导致整个数据驱动的应用程序变得非常混乱，越来越越难以理解，最终会阻碍数据应用创新。
将数据按某一类结构做存储和管理，能让各个方面各个专业的人，都很方便拿到他想要看的维度，去做他想要做的分析，是一件复杂的事。
有了领域数据模型做基石，针对特定业务问题的数据分析建模就会事半功倍。因为很多模型都有一些共性的业务逻辑要表达。如果直接从原始数据里取数，得先把数据取出来，有哪些是业务上的异常值，有哪些基本过程需要识别出来，在这个过程中把数据有序组织起来，再进行后面的分析。前面这一大段数据治理工作至少在某些专业领域内，很大程度是可以通用的。
领域数据建模一方面能减少很多重复性的工作，让分析师做更多有创造力的工作；另一方面还能在多维度数据参考下，找出问题背后隐藏的关联关系。
单点问题，通常来说比较容易好发现和好解决。但现实情况下，某个单一参数异常，通常并不具有现实含义，还需要结合设备正在什么工况下运行，正常温度应该是什么范围内，影响温度的其他参数数据如何表征等等，通过数据间的相互关系去判断问题所在。在面对长流程复杂工艺的数万个测点时，一旦出现异常，靠人工排查非常慢且很难锁定问题根因。以产线为物理对象，建立交叉融合的领域数据模型，可以对设备乃至操作设备的人有更客观准确的认知和评价。
领域模型的本质是一个思维模型，其关联的数据逻辑上是紧密联系的，实际上却从属于不同的系统。那么模型上线运行的时候，怎么去访问这些数据呢？可以写一段能够体现模型数据关联的数据访问程序，也有一些比较先进做法，比如数据联邦，可以跨库做数据查询。在数据联邦技术下，领域模型可以被翻译成联邦查询的一些元数据，使其帮助处理数据访问。
将领域模型变成一个可持续运行的系统，需要考虑到，底层的领域模型有一个好的设计思路以及灵活的技术架构，能支持系统和系统之间的解耦，模型和系统之间的解耦，支持各个不同的系统之间统一与协作，再去做应用维护、分析模型开发，这样在后续面临业务变更、产线迭代、设备升级等等情况时，才不至于大动干戈。
比如某电子制造案例中，有一个数据字段叫EL不良，代表电致发光，这个不良类型有17种。这一个字段背后就承载了很多业务逻辑。再往大了说，如果要去刻画一个产线的生产过程，有一个很经典的领域模型——生产制造运营系统里面的ISA-95模型。虽然它是为了支撑生产过程，但它其实刻画了加工能力跟设备是什么关系，有的时候是一对多，有的时候是多对多，取决于现场设备是单一能力还是复合能力。
再以煤矿综采系统为例，采煤机和支架要相互配合。首先将基本的运行过程做工况切分，每个循环过程下，采煤机有它自己的一套动作流程和一个周期的数据，支架又有它自己的周期数据，这两个结构之间相互配合，所以采煤机的周期和支架周期之间有一定的关联关系。在这个结构之上，再提取出支架在每个循环里面做了什么，跟采煤机配合做了什么，采煤机的特定动作跟支架的动作之间建立一个关联关系，就能够看出两者的配合关系。在这里案例里，领域模型就是从业务上描述数据，再从数据还原业务基本单元和单元之间协同关系的结构。
有些人拿着领域模型去写支撑这个业务动作过程的代码和系统，就是信息化系统；我们拿着业务模型去做数据挖掘，就是领域驱动的数据模型。
Q8：如果不计较技术实现难度，从数据价值挖掘的角度来畅想一下，一个好的领域模型应该能达成什么目标？
从分析的角度来说，我们希望通过用业务语言描述的方式拿到想要的数据，例如今天第几个加工周期里面设备的温度、电压和电流，它们之间的相关关系数据，然后平台就能把这个数据集给返回来，包含三列数据，一个叫温度、一个叫电压、一个叫电流。
现在一般要从数据库的那些表里取数据，过程有时候会很繁琐，也不那么直观，会花很多时间。在数据治理、数据工程建设中，还有很多工作可以完善。有时候，很多企业计划搭建一个数据系统，技术服务商会突出底层提供什么增删改查的功能，支持哪些通用的数据库。但其实都回避了或忽视了，针对特定行业、特定产线、特定设备、特定的工业对象，怎么去构建数据模型呢？这导致后续的数据价值挖掘工作非常难以开展。
假设设备坏了，不要告诉我这个平台的数据质量、数据完整度，我就想知道这个设备它发生故障前后有没有运行数据，有没有振动数据？这个设备有以前没有发生过类似的故障？当时是什么情况？当时是谁修的，用的什么件儿？那批件儿当有没有用到其他设备上去？其他的维修率有多高……这些是我们去研究一个对象，面向良率、故障、异常去做数据分析的时候，希望看到的。我们希望数据是按照这样的方式去组织，这也是今天讲的领域模型背后表达的实质。
当然，这是一个循序渐进的过程，技术手段实践可以由浅入深的去做。首先在领域模型概念层面达成共识，才能够在今天的基础之上无限去逼近刚才提到的愿景。
