一、关于大模型的认知
大模型，相对小模型（如更贴合具体业务场景的数据分析模型）而言，有四个特点：第一，参数规模特别大，动辄千亿、万亿级，榜单还在不断刷新；第二，训练的数据集特别大，可能互联网上质量比较好的一些数据都被爬下来用作训练了；第三，训练或运行对计算资源的需求特别大，目前主流的大模型只是运行起来就需要至少200GB左右的显存，微调和训练的需求更大，这么大的GPU的硬件支持；第四，最厉害的是能力强大，更接近通用人工智能。
大语言模型，天然匹配写代码写文档等需求。许多工业企业也对新技术非常感兴趣，希望在大模型中找到特殊应用场景。
二、什么样的场景适合工业企业着手做第一个基于大模型的项目？
大模型擅长处理大量文本类型的语料，工业领域正好有海量的文本语料知识（如标准、论文、专家报告、操作规范等），可以通过大模型的方式去做整体的归纳整理和学习。有如下几类场景：
第一类，智能问答。例如，在很多条件严苛的工业现场，构建工业领域的智能问答运维系统，可以提高工业领域的知识查询效率，便于及时采取行动。还有，水、电、燃气等工业领域面向大量终端用户的客户服务系统。
第二类，文本处理。例如，将大模型应用于设备缺陷分析、事故过程处理等各类报告的学习中，有了特定格式特定风格的文本基础，再人为输入数据和少量信息，就可以自动生成报告，以减轻人力负担。
第三类，数据分析，大模型对数据的处理更接近人脑的处理方式，不会刻意区分是时序数据还是文本数据，都会从海量数据中提取出有用信息。例如，自动获取设备运行数据，生成设备运行的指标分析，来判断这个设备的健康趋势，并能够根据数据结果匹配既往的最佳处理方案。再如通用图像识别等，用于工业现场的自动化巡检和问题诊断。
在常见的运维领域之外，在研发设计领域，文档体量也不小，也可以考虑利用大模型的技术加速方案快速生成，并结合专家经验和行业知识进行细化迭代。还有更多潜在的场景仍在探索定义当中。
三、如何将大模型技术应用于实际工作中？
首先要确定一个具体的业务场景，找到对应的文本类数据、非结构化类数据等。接着，将这些数据与企业的工单、规程、案例、专家总结报告等进行整合，建立相应的知识逻辑体系，随后确定合适的交互方式，以便更好地发挥大模型的优势。
第一步是底层通用模型的选型。首先考虑选择公有云版本还是私有部署版。目前地球上最牛的大模型还是ChatGPT，但只能在公有云上，且中国境内使用受限。即使不管制，工业企业一般也很少会把自己的语料喂给ChatGPT，会有数据泄露的风险。所以第一步是找一个可以做私有化部署的开源大模型。
其次需要对大模型的技术评价有一系列的指标体系，从实际应用的角度，通过测评报告做一轮初筛，然后考虑它的license是否可以开源商用，比如说同样是某品牌的大模型，1.5版本之前可以商用，最新的版本不可以，需要留意。再次，对中文的支持是否友好。
市面上很多大模型的研发企业在不断的快速更新版本，但对于行业企业应用，没必要对底层技术的发展追踪太紧，更没必要从底层开始研发。
接下来，第二步，以此为基础，将现有的通用模型与特定领域的需求相结合，训练特定语料，通过调整参数和技术路由来实现目标。当然在这一步，有很多的技术路线可选，从浅到深，从易到难，从效果差到效果好。
比较浅层次的调优或者客制化方式是提示工程，是通过改变问题的描述方式去影响模型内部的运行，从而改变它的输出。提示工程并没有改变模型本身，或者挖掘模型里蕴含的知识，本质上没有改变模型知识的边界。
再往前一步，做Embedding，就是在问问题的同时，将私有语料当做问题的上下文，一起发送给大模型，大模型基于这些上下文材料回答问题。这种方式也不会扩展基础模型的知识边界。
再往前一步，进入微调的阶段，对于一般企业来讲就稍微有点深了。类似于知识载体的回炉再造，在具备通识的基础上，将专业领域的语料大量输入，做小型的模型训练。从微调这一步开始，就需要GPU资源做数据处理了。
再往前一步，大多数企业就已经达不到了，几乎重建，这个在资源投入和技术难度身上要求太高。所以从应用层面，一般前面三步相对更实用。
五、考虑到实用性和竞技性，以技术路线二为例，继续推进，有哪些进一步的建议吗？
走第二种路线，科学道理很简单，但真正上手做的时候，会发现这是一个巨大的工程问题。除了刚才提到的底层大模型的选择，还有几个问题：
首先，准备语料。一般语料都是一个整体，为了能够把语料变成问题能参考的上下文，就要将语料做预处理，放到向量数据库，把它向量化，成为行业数据模型。这里就涉及语料怎么切分整理。各种word文档中，有一些文字语义相近，有一些语义关联较远，并不能通过一种完全自动化的方式去做，所以预处理的过程中，人的参与度还是很高。特别在梳理的过程中，会碰到以前的一些周边技术和老技术融到一起，会消耗非常多的精力。当然，全靠人工去做也做不完，还是有相应的一些工具和能力去辅助专家。语料本身质量的高低也会对工作量有一定的影响。
其次，刚才说的底层大模型是一种引擎，向量数据库也是一种数据存储引擎，那么还需要一个框架，把技术整合到一起，把分词的预处理结果管起来，然后基于一定的词库，给向量化存下来。这一步，基本上工程问题会大于科学问题。
当向量的语料库准备好，工作基本上算完成了。最后还需要测试一下，如果效果不好，还要从两方面去考虑，就是提示词工程和上下文工程。在提问的过程中，就会出现一些提示词，去向量数据库中做检索，找到相关的上下文信息后，再调用大模型的API，把提示词和它的相关上下文信息作为输入，底层的大模型会结合这些信息，最终给出反馈结果作为回答。
如果涉及追问，那还会有一些上下文工程的工作，工程量的大小取决于选取的大模型本身记忆的长短。如果大模型相对健忘，那可能就要自己去做一些上下文的工程，让交流更自然或者延续性更好，最终找到一个解决方案。如果模型相对记忆性比较好，理解能力又很强，那相对来说就会简单一些。
六、大模型不会反向推理，这个模型的缺陷会导致在设备故障预测等场景中不能很好的落地吗？
大模型本质上还是一个概率模型，并不具备我们认为的推理能力。从实践角度来说，确实会限制大模型的一些使用场景。它能够作为一个好的辅助角色，顾问或者助手，帮助你来厘清思路，但如果期待它自己来做反控，就不现实。
工业系统是一个精确的系统，而大模型会犯错，就是ChatGPT，通过几个误导性的问题，回答也会完全不一样。不排除以后大模型具备复杂的推理能力，但现在还不适合这种场景。
当前比较理想的情况是，在故障诊断场景下，大模型以一个辅助的方式，把定性的规程的标准的信息和曾经实在发生过的历史档案，以及已经加工处理好的特征、KPI等指标类的信息调取出来，工程师自己再做判断。让大模型用编程语言去操作一个数据系统，在技术上是可行的，比自然语言要更精确一些。
工业企业应用大模型，在完成前述基本框架后，进一步工程化演进，可以考虑：第一，怎么让分词分得更好，可以尝试进一步丰富语义库；第二，提示词工程，怎么能够让提示工程的质量更高，让答案的反馈效率和准确性更好；第三，能不能去做多模态融合，把大模型的输出和一些其他信息化数字化系统的输出融合起来，给用户一个标准化的答案。这三步做到一定程度，对于企业应用大模型的投入产出比，就具有一定可行性了。
