大模型在工业数据分析过程中的典型用例

来源: | 作者:pmod6d781 | 发布时间: 2024-10-09 | 1432 次浏览 | 分享到:

数据分析挖掘作为一个知识密集型的研发活动，大模型应该可以充分发挥辅助作用，将一些繁琐的工作自动化，提升数据分析效率。本文按照CRISP-DM（CRoss Industry Standard Process for Data Mining,跨行业数据挖掘标准流程）分析阶段，分别探索不同阶段大模型可能的应用场景。基于这些分析，可以发现有可能开发出一些列交互式小工具（甚至整合到集成开发环境中），加速工业数据分析过程。同时也发现，在这些知识富集过程中，大模型需要和规则模型结合，这些工具应该定位为助手，自动化工具目前仍不现实。

一、业务理解阶段

大模型可以帮助分析师更好地理解业务需求，通过自然语言处理能力解析业务文档、会议记录等，提取关键信息，从而更准确地定义项目目标和成功指标。特别如下系统运行机理机理、领域概念理解两个方面，可以提高业务理解效率。

1、系统动力学模型的自动生成

系统动力学以图形化的方式刻画了业务问题背后的机理过程，是辅助业务理解的一种模型。以磨煤机为例，系统动力学刻画了状态量、控制量、外生变量、目标量，以及这些变量间的关系。

系统动力学模型通常是业务分析师在业务访谈中逐步形成，或则资深数据分析师在大量相关文献阅读后手工形成，消耗资深人员的时间，在时间存在滞后。有了大模型的支撑，这样的工作可以在业务理解之前半自动化完成，让业务访谈更有针对性。

2、领域模型的自动生成

系统动力学是从驱动关系或决策逻辑的角度理解变量或要素间的动力学关系，目的是为了分析建模和数据收集；而领域模型是从数据的角度理解业务问题的相关概念（本体）、关联关系和约束，目的是为了数据关联和数据质量审查。领域模型的生成有如下表所示的2种方式，

①领域文档驱动：包括论文、报告、书籍、记录等，这些内容以文本形式存在，大模型可以从中抽取关键的概念（本地）、事件、约束及其关系；也可以将给定领域的参考模型作为上下文进行分析；

②数据驱动：样例数据及其数据库说明文档，可以基于规则的形式提取表对象关系，作为大模型的上下文。

如下图所示，领域模型有3条生成路径，

1）文档驱动；

2）样例数据驱动；

3）数据库E-R图转化得来（部分参考样例数据统计结果）。

在文档驱动的方式中，针对工业大数据分析问题，可以参考工业领域或特定领域的元数据行程提示词，例如物理实体构成、物理世界过程（要素及其关系）、量程活动、操控行为等。针对常见的问题，通常存在有很多参考模型，例如离散制造过程有ISA-95模型，这些元模型可以作为大模型的上下文信息，大模型进一步细化，形成领域概念列表。领域概念间的关系也可以通过文档提取。

在数据驱动的方式中，业务字段识别可以采用启发式规则，包括识别数据表中的枚举字段、类别字段（唯一值的数量远远小于记录条数）、时间字段。这些业务字段，通过人工修订后的概念-数据表的映射关系，可以在数据表中校核概念间的关系是否符合实际业务。业务字段间（包括业务字段组合）的关系可以基于样例数据统计去归纳。

E-R图转化为领域模型中，主要的规则包括：

1）将物理主键（或称为代理主键）替换为业务主键，例如稠油井转轮周期表，每口井每个小层有一套连续的转轮周期编号，但在数据库中用一个物理主键而不是3个业务主键的组合来标识记录的唯一性，在面向数据分析的领域模型中，应该用业务主键来表达唯一性，这样更容易业务概念理解；

2）对于存在父类、子类的关系，如果层次关系不是重点，可以将父类的属性分别合并到子类，在领域模型中，消除父类，自己用子类，这样更方便后续数据集关联操作。例如，人工功图是抽油井生产测试的一种，测试任务号、测试类型、井名、测试日期等所有测试任务的公共属性存在生产测试表中，人工功图数据表中仅有测试任务号和人工功图的特定属性，在功图诊断课题中，只需要人工功图一种生产测试，没有必要保留生产测试这一层对象，可以将井名、测试日期等属性加入人工功图中；

3）根据领域问题，有些对象根据类别变量可以转为两个类。例如，SAGD生产数据库中，I井与P井在同一张数据表中，只不过注汽日报表中只有I井的记录，生产日报中大部分是P井的记录，但在SAGD注汽分析中，I井与P井是两个独立的领域模型。

读者可能疑问：E-R图等数据库模型本身也是一种模型，为什么不能直接作为领域模型呢？这是因为数据分析关注点与数据库、应用开发不同。在领域模型上，数据分析与应用开发的关注点不同。数据分析并不关心对象行为，只关注对象属性或状态，从某种程度上来说，属于贫血模型。但与一般贫血模型不同，数据分析关注的是关联，即如何将不同数据对象组合为机器学习模型所需的宽表，因而更关注维度、颗粒度和更新周期。在数据模型方面，数据分析也不像关系数据库那样关注存储/访问效率、一致性，因而数据分析课题的领域模型不一定要符合三范式。

最后补充说明一下，很多具体做法（或企业特定约定做法）没有在文档中体现，这是文档驱动方式缺陷的本质原因之一。例如，SAGD生产中，生产日报数据表（主要是每日的产液量等信息）是否包括循环预热阶段的数据？这是后续SAGD分析数据集筛选与加工的必要的信息，但无论在公共文献、内部文献还是数据库设计文档中都没有描述，这些信息只有通过样例数据统计回答。

二、数据理解阶段

在数据理解阶段，一方面是根据业务理解去理解数据，识别数据质量问题，明确数据准备的内容；另外一方面是通过数据探索，发现业务理解中的不足，进一步加深数据理解。数据理解是一个数据操作与业务假设双轮驱动的过程，大模型在本阶段应用中也需要与基于规则的数据操作过程融合。

1、数据源的智能识别

业务理解阶段从业务、机理角度，将数据分析课题的相关变量，这些变量在数据系统的确切位置有时候也成为数据收集活动时的重点任务。有时候一个业务变量在多张表中存在，需要确定不同表中数据的完整度、更新度，以确定应该采用哪张表。例如，抽油机的理论最大、最小载荷是功图诊断的重要参考量，二者在井下作业、人工功图等表中都存在，但经过历史数据统计，井下作业数据表记录只覆盖了50%的井，并且该数据是设计阶段还是完工阶段填写的尚不确定，而人工功图数据表几乎覆盖了所有井，该数据是经过专家审核的，具有较高的可信度。

如果存在大量应用设计文档语料、数据库字典文档，大模型可以自动发现业务理解阶段变量所在数据库表和字段。这些问题在很多类似的分析或应用开发中都会碰到，可以通过大模型或自然语言处理技术发现类似的情形。

另外，数据层面的启发式统计分析也有很大帮助。根据数据字段、数据表内容，确定待寻找业务变量对应的数据表和字段名。很多数据库文档不能反映实际运行状态。例如在某个使用阶段后，一些静态信息表不再更新（例如，测量装置的更换信息），很多字段的业务意义发生了变化（例如，油井层位字段原来填写大层，后面填写到小层颗粒度）。根据数据表的数据的新鲜度、覆盖度统计可以辅助数据分析师选择合适的数据表。

2、假设的自动检验

初期的业务理解是比较浅的，背后有大量隐形假设，在数据探索中会逐步暴露出来业务理解的局限性或虚假性。例如，在SAGD（Steam Assisted Gravity Drainage井）井生产偏离预警分析时，初期访谈的理解是：当前采油站1个SAGD井对由1个注汽井（Injection Well，以下简称I井）和生产井(Production Well，简称P井）构成，背后隐形的假设：生产日报数据表（主要是每日的产液量等信息）中只有P井，注汽日报数据表中只有I井。但数据表探索发现生产日报中包括了不少I井，另外有少数I井没有对应的P井。这样的数据与隐形假设的不一致暴露了初期业务访谈中，业务分析师一直缺乏对SAGD井生产阶段逻辑的业务理解，即SAGD井预热阶段、蒸汽腔建立阶段、生产阶段等阶段，而在蒸汽腔建立阶段阶段，产液主要通过I井自喷排出。

业务理解与数据表现的不一致，过去主要靠数据分析师的逻辑思维能力和严谨态度，无法保证执行的统一性。借助大模型能力和领域模型，有可能在如下几个方面提升。

1）领域模型约束关系检查代码的自动生成：根据领域模型中各个对象基数关系和明确的约束条件，转化为对应的数据分析代码，提升业务理解在数据上的验证效率。

2）领域对象基数关系的自动统计：包括业务主键（组合）基数关系的统计（类似上节讨论）或则数据表业务主键分布的统计（例如，生产日报中包括多少口I、P井的记录），数据分析师研判其中的“概念冲突”。

3）隐性假设的明确化：根据过去大量的数据分析报告，总结常见的隐性假设，结合当前的领域模型，生成提示上下文，大模型给出当前领域模型潜在的隐形假设列表。但这一步从技术很难，因为很多隐形假设（例如，上面例子中“生产日报表中只有P井”）假设和冲突没有特定规律，通常是分析师在数据探索中无意发现的。

3、基于领域模型的数据质量检查

文献[3]讨论了基于约束描述的数据质量检查方法，多个表之间检查基数关系、层次性关系、合并前后的记录数，时序数据检查时间或时间间隔(time interval)字段间的关系。这些方法是一些指导原则，仍需要数据分析师分解检查逻辑与代码。

根据领域模型自动生成检查逻辑，对于大模型来说有一定难度。但分析师在列出约束后，大模型可以生成检查代码，在一定程度上也能部分降低分析师的工作量（很多重复性的代码人工编写难度不大，但耗费大量精力）。

4、数据质量案例的智能总结

在数据探索过程中，不时会发现一些异常案例（通常比例比较低），但很多时候没有及时系统性总结。例如，一口井的人工功图测量一般3~6个月进行一次，但在过去10年的5万多条人工功图中，存在一口井在某天存在2条内容不完全重叠的记录。很多这样的处理逻辑分散在不同文档和代码注释中，系统性梳理工作很大。

另外，在探索中发现的数据质量问题后，数据分析师通常会就地写代码解决掉。但后期交流总结时，通常需要给出一些质量问题的案例，数据分析师需要花费一定代价写代码重新查找。有了大模型，在一定的代码注释规范下，数据质量案例可以实现智能抽取，形成合适的文档。

以R语言分析中常用的RMarkdown文件格式为例，探索中发现的异常质量个例，可以在文档中用特别的标记符号标记，将数据存为约定的RData文件，并附加注释文字（大模型可以扩展为完整语句）、图表代码。这样后续程序可以按照约定的规范，从原始RMarkdown抽取案例片段，构成新的RMarkdown文件。

三、数据准备阶段

数据分析通常基于多张数据表的综合分析，有大量数据表连接、聚合的工作，在加上数据质量问题杂多，涉及到大量的边界检查与处理，大模型可以一定程度降低数据准备的工作。

1、数据集的智能整合

以行业数据模型为基础，大数据平台提供基于图搜索技术的语义查询模型，以友好的方式支撑设备管理分析。以风电机组为例，当叶片发生断裂事故后，整机制造商的运维主管想要查看并确认是否为叶片批次问题（即和当前风机使用同一叶片厂商的风机的近期机舱加速度是否正常），查询路径如图1所示。有了图语义模型的支持，应用开发者无须编写复杂的表间关联语句，将大大降低应用开发的工作量。

查询路径有两个来源，1）用户可以给定查询路径，在如下图所示的领域模型中，用户给出查询路径和初始的查询条件，两个实体间关联关系由领域模型实现，用GraphQL等图查询语言表达，2）大模型自动生成查询路径，并转化为图查询语句。

另外，大模型也可以对生成的数据集进行自动描述。从数据源抽取关键业务语义信息（例如，覆盖多少口井，数据的起止日期，有多少有效数据），并抽取关键的数据质量处理函数描述，交由大模型生成数据集的描述，以方便后续利用时更深入了解该数据集。

2、数据处理

流图和说明文档生成

在开发之前通常有数据流图设计。但在开发过程中，数据分析师通常会对数据处理逻辑做更新，造成实际的数据流图与设计图并不完全一致。过去通常在项目验收前要求数据分析师去更新实际的数据流图。

有了大模型之后，有可能结合代码注释，从函数代码提取处理步骤描述，形成一个函数的处理逻辑流程图，撰写算法文档。更宏观一层，从数据库表读写语句中分析每个分析函数的输入和输出的数据表，把多个分析函数的输入、输出和数据表关联起来形成数据流图。

四、模型建立阶段

因为存在大量丰富的机器学习算法库和各种效率工具（例如，AutoML等），模型建立在一般机器学习项目并不是瓶颈，这里不再论述。大模型有可能从类似项目代码中自动生成代码框架，也可以辅助模型试验过程管理（让探索更条理化）。

五、模型评价阶段

针对模型评价，机器学习领域有明确的评价方法、指标和工具，具体项目中通常也有明确的业务角度的评价方法，从而，研发期模型评价阶段对大模型没有特别需求。在部署后的运维阶段，大模型可以对模型的运行性能（计算时间、内存占用量等）、模型指标进行即席解读，降低运维工作量。

六、模型部署阶段

到了“模型部署”阶段，这些信息都明确了，但相对于基于历史数据的批量分析，部署阶段通常采用在线增量分析（流计算、批计算、微批计算），前后执行（以下简称为批次）间存在依赖。

1、在线增量逻辑的修改需求识别

将离线逻辑改成在线逻辑关键在于构建合适的状态量，去有效的表征过去的信息。状态量有3种情况：

1）累积量，例如，大风持续时长，当前的累计量可以作为状态量传给下一次计算。

2）跃变型，通常是类别变量或低频更新的参数，例如磨煤机的负荷状态可以作为状态变量供下次在线迭代计算。抽油机有泵调整时候，会在机采数据表中插入一条记录，在下次更新之前可以一直沿用该参数。

3）事件型（或则Interval变量），例如，修井措施的任务的起止时间，它在选择基准功图、修井效果后评估中是重要的参考量。

在线增量逻辑的修改需求的智能识别有2种途径：

1）根据数据分析程序输出的数据表的说明文档，大模型可以将上面3种情况描述作为提示语，发现潜在需要改写的状态量。

2）针对跃变量和时间型，可以采用基于1.3节数据处理流图的规则检查方式，一般来说这些变量的时间频度比待加工的数据表的要低，例如，合并后的表是每口井的日数据，而输入数据表中的措施、清防蜡等记录是不定期的，通常间隔3个月至上。可以统计实体主键（除时间字段之外其他业务主键）下表的更新频度，更新频度比输出表低的表就是潜在需要修改的表。第两种方法可以结合起来，第一种方法的效果依赖于数据表说明文档的质量，第二种方法受限于数据流图的质量。

2、前端界面与分析模型的关联识别

很多分析模型有对应的应用界面。当应用界面出现异常或疑问后，通常会被问到“该页面或控件的数据来自于哪个分析模型？”。1.3节讨论了如何将分析任务与数据表关联起来，同样的逻辑可以将应用界面与数据表关联起来，基于应用前后端的代码，可以分析数据表-后端Restful API的关系，通过前端与后端API的关系最终将前端界面与数据表关联起来。