新闻动态
大模型技术在工业行业的应用探讨
来源: | 作者:pmod6d781 | 发布时间: 2024-10-09 | 316 次浏览 | 分享到:

一、关于大模型的认知



大模型,相对小模型(如更贴合具体业务场景的数据分析模型)而言,有四个特点:第一,参数规模特别大,动辄千亿、万亿级,榜单还在不断刷新;第二,训练的数据集特别大,可能互联网上质量比较好的一些数据都被爬下来用作训练了;第三,训练或运行对计算资源的需求特别大,目前主流的大模型只是运行起来就需要至少200GB左右的显存,微调和训练的需求更大,这么大的GPU的硬件支持;第四,最厉害的是能力强大,更接近通用人工智能。

大语言模型,天然匹配写代码写文档等需求。许多工业企业也对新技术非常感兴趣,希望在大模型中找到特殊应用场景。

二、什么样的场景适合工业企业着手做第一个基于大模型的项目?

大模型擅长处理大量文本类型的语料,工业领域正好有海量的文本语料知识(如标准、论文、专家报告、操作规范等),可以通过大模型的方式去做整体的归纳整理和学习。有如下几类场景:

第一类,智能问答。例如,在很多条件严苛的工业现场,构建工业领域的智能问答运维系统,可以提高工业领域的知识查询效率,便于及时采取行动。还有,水、电、燃气等工业领域面向大量终端用户的客户服务系统。

第二类,文本处理。例如,将大模型应用于设备缺陷分析、事故过程处理等各类报告的学习中,有了特定格式特定风格的文本基础,再人为输入数据和少量信息,就可以自动生成报告,以减轻人力负担。

第三类,数据分析,大模型对数据的处理更接近人脑的处理方式,不会刻意区分是时序数据还是文本数据,都会从海量数据中提取出有用信息。例如,自动获取设备运行数据,生成设备运行的指标分析,来判断这个设备的健康趋势,并能够根据数据结果匹配既往的最佳处理方案。再如通用图像识别等,用于工业现场的自动化巡检和问题诊断。

在常见的运维领域之外,在研发设计领域,文档体量也不小,也可以考虑利用大模型的技术加速方案快速生成,并结合专家经验和行业知识进行细化迭代。还有更多潜在的场景仍在探索定义当中。


三、如何将大模型技术应用于实际工作中?

首先要确定一个具体的业务场景,找到对应的文本类数据、非结构化类数据等。接着,将这些数据与企业的工单、规程、案例、专家总结报告等进行整合,建立相应的知识逻辑体系,随后确定合适的交互方式,以便更好地发挥大模型的优势。

四、如何选择合适的技术路线构建大模型?

第一步是底层通用模型的选型。首先考虑选择公有云版本还是私有部署版。目前地球上最牛的大模型还是ChatGPT,但只能在公有云上,且中国境内使用受限。即使不管制,工业企业一般也很少会把自己的语料喂给ChatGPT,会有数据泄露的风险。所以第一步是找一个可以做私有化部署的开源大模型。

其次需要对大模型的技术评价有一系列的指标体系,从实际应用的角度,通过测评报告做一轮初筛,然后考虑它的license是否可以开源商用,比如说同样是某品牌的大模型,1.5版本之前可以商用,最新的版本不可以,需要留意。再次,对中文的支持是否友好。

市面上很多大模型的研发企业在不断的快速更新版本,但对于行业企业应用,没必要对底层技术的发展追踪太紧,更没必要从底层开始研发。

接下来,第二步,以此为基础,将现有的通用模型与特定领域的需求相结合,训练特定语料,通过调整参数和技术路由来实现目标。当然在这一步,有很多的技术路线可选,从浅到深,从易到难,从效果差到效果好。


比较浅层次的调优或者客制化方式是提示工程,是通过改变问题的描述方式去影响模型内部的运行,从而改变它的输出。提示工程并没有改变模型本身,或者挖掘模型里蕴含的知识,本质上没有改变模型知识的边界。

再往前一步,做Embedding,就是在问问题的同时,将私有语料当做问题的上下文,一起发送给大模型,大模型基于这些上下文材料回答问题。这种方式也不会扩展基础模型的知识边界。

再往前一步,进入微调的阶段,对于一般企业来讲就稍微有点深了。类似于知识载体的回炉再造,在具备通识的基础上,将专业领域的语料大量输入,做小型的模型训练。从微调这一步开始,就需要GPU资源做数据处理了。

再往前一步,大多数企业就已经达不到了,几乎重建,这个在资源投入和技术难度身上要求太高。所以从应用层面,一般前面三步相对更实用。

五、考虑到实用性和竞技性,以技术路线二为例,继续推进,有哪些进一步的建议吗?

走第二种路线,科学道理很简单,但真正上手做的时候,会发现这是一个巨大的工程问题。除了刚才提到的底层大模型的选择,还有几个问题:

首先,准备语料。一般语料都是一个整体,为了能够把语料变成问题能参考的上下文,就要将语料做预处理,放到向量数据库,把它向量化,成为行业数据模型。这里就涉及语料怎么切分整理。各种word文档中,有一些文字语义相近,有一些语义关联较远,并不能通过一种完全自动化的方式去做,所以预处理的过程中,人的参与度还是很高。特别在梳理的过程中,会碰到以前的一些周边技术和老技术融到一起,会消耗非常多的精力。当然,全靠人工去做也做不完,还是有相应的一些工具和能力去辅助专家。语料本身质量的高低也会对工作量有一定的影响。

其次,刚才说的底层大模型是一种引擎,向量数据库也是一种数据存储引擎,那么还需要一个框架,把技术整合到一起,把分词的预处理结果管起来,然后基于一定的词库,给向量化存下来。这一步,基本上工程问题会大于科学问题。

当向量的语料库准备好,工作基本上算完成了。最后还需要测试一下,如果效果不好,还要从两方面去考虑,就是提示词工程和上下文工程。
在提问的过程中,就会出现一些提示词,去向量数据库中做检索,找到相关的上下文信息后,再调用大模型的API,把提示词和它的相关上下文信息作为输入,底层的大模型会结合这些信息,最终给出反馈结果作为回答。

如果涉及追问,那还会有一些上下文工程的工作,工程量的大小取决于选取的大模型本身记忆的长短。如果大模型相对健忘,那可能就要自己去做一些上下文的工程,让交流更自然或者延续性更好,最终找到一个解决方案。如果模型相对记忆性比较好,理解能力又很强,那相对来说就会简单一些。

六、大模型不会反向推理,这个模型的缺陷会导致在设备故障预测等场景中不能很好的落地吗?

大模型本质上还是一个概率模型,并不具备我们认为的推理能力。从实践角度来说,确实会限制大模型的一些使用场景。它能够作为一个好的辅助角色,顾问或者助手,帮助你来厘清思路,但如果期待它自己来做反控,就不现实。

工业系统是一个精确的系统,而大模型会犯错,就是ChatGPT,通过几个误导性的问题,回答也会完全不一样。不排除以后大模型具备复杂的推理能力,但现在还不适合这种场景。

当前比较理想的情况是,在故障诊断场景下,大模型以一个辅助的方式,把定性的规程的标准的信息和曾经实在发生过的历史档案,以及已经加工处理好的特征、KPI等指标类的信息调取出来,工程师自己再做判断。让大模型用编程语言去操作一个数据系统,在技术上是可行的,比自然语言要更精确一些。

工业企业应用大模型,在完成前述基本框架后,进一步工程化演进,可以考虑:第一,怎么让分词分得更好,可以尝试进一步丰富语义库;第二,提示词工程,怎么能够让提示工程的质量更高,让答案的反馈效率和准确性更好;第三,能不能去做多模态融合,把大模型的输出和一些其他信息化数字化系统的输出融合起来,给用户一个标准化的答案。这三步做到一定程度,对于企业应用大模型的投入产出比,就具有一定可行性了。