技术干货 | 大模型在工业数据分析过程中的典型用例(上)

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

图1 CRISP-DM过程方法

一、业务理解阶段

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

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

系统动力学以图形化的方式刻画了业务问题背后的机理过程,是辅助业务理解的一种模型。以磨煤机为例,系统动力学刻画了状态量、控制量、外生变量、目标量,以及这些变量间的关系。
图2 CRISP-DM过程方法
系统动力学模型通常是业务分析师在业务访谈中逐步形成,或则资深数据分析师在大量相关文献阅读后手工形成,消耗资深人员的时间,在时间存在滞后。有了大模型的支撑,这样的工作可以在业务理解之前半自动化完成,让业务访谈更有针对性。
图3 大模型辅助的系统动力学模型构建过程

2、领域模型的自动生成

系统动力学是从驱动关系或决策逻辑的角度理解变量或要素间的动力学关系,目的是为了分析建模和数据收集;而领域模型是从数据的角度理解业务问题的相关概念(本体)、关联关系和约束,目的是为了数据关联和数据质量审查。
领域模型的生成有如下表所示的2种方式,
①领域文档驱动:包括论文、报告、书籍、记录等,这些内容以文本形式存在,大模型可以从中抽取关键的概念(本地)、事件、约束及其关系;也可以将给定领域的参考模型作为上下文进行分析;
②数据驱动:样例数据及其数据库说明文档,可以基于规则的形式提取表对象关系,作为大模型的上下文。
表1 领域模型的生成方式
整体过程如下图所示,领域模型有3条生成路径,
1)文档驱动;
2)样例数据驱动;
3)数据库E-R图转化得来(部分参考样例数据统计结果)。
图4 大模型辅助的领域模型的构建过程
在文档驱动的方式中,针对工业大数据分析问题,可以参考工业领域或特定领域的元数据行程提示词,例如物理实体构成、物理世界过程(要素及其关系)、量程活动、操控行为等。针对常见的问题,通常存在有很多参考模型,例如离散制造过程有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文件。

(未完待续,数据准备、模型建立、模型评价、模型部署敬请期待!

昆仑数据K2Data
昆仑数据是工业互联网领域的领军企业,蝉联“中国大数据企业50强”,受邀参与制订《中国制造2025》工业大数据技术路线图,发起成立并主导运营工业大数据制造业创新中心,致力于用大数据和人工智能技术,推动中国工业智慧升级。
 最新文章