博客 大模型在数据分析场景下的实现路径

大模型在数据分析场景下的实现路径

   数栈君   发表于 2024-04-11 09:49  69  0
下一步将讲解如何实现这两个方面的需求,即经营决策的应用场景以及实现路径。
3.1 大模型+指标平台的实现路径
http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user1/article/8d44ee40b92e17acf155cd04c6827ada..jpg
从目前看到的情况来看,决策首先需要的是确保准确性,要确保每次交互获取的数据是准确的,因此不能让大模型过于天马行空地查询数据。因此,我们通常采用的实现路径之一是直接调用GPT,结合用户输入的自然语言,使用大型模型的通用算法和功能来识别和理解用户意图,以更精准地命中关键词。
当命中关键词后会在指标平台上进行查询,这个查询过程非常严格,只能在指标平台上进行,这可以确保最终的结果一定会与指标平台中的具体指标相关。查询完成后,大模型会自动生成一段分析报告的语句,而不仅仅是简单地提供数据结果或表格,这样做可以让用户体验更加顺畅。
与此同时,大模型本身也可以解读这些数据,并给出初步的一些建议。例如,哪些指标在最近两个月内显著增长或发生了变化,需要特别关注哪些指标,而且当使用GPT3.5或GPT4时这个过程就会非常简单,不需要进行预训练。
我们现在看到,通过fine-tuning微调可以很好地发挥模型的理解能力。根据我们的调研结果,这种微调所需的数据量最多不超过1万条,通常只需要几千条就足够好训练出结果了,这是一类使用GPT的方法。
如果需要进行私有部署,使用6B、7B或13B的模型就可以很好地实现以上效果。无论是进行fine-tuning还是进行简单的预训练,都可以实现接近GPT3.5的效果。因为最终的查询是针对指标进行限定,这是一个相对较小的范围,而且整个推理的成本也不高。
根据我们的调研,使用两张3090显卡在几周的时间内进行微调是可以很好地实现结果的,这也是目前可以使用的比较好的实现方式。其优势在于,可以显著增强对话式交互能力,降低 BI 使用门槛,让管理层和经营分析部门能够快速获取所需数据
当然缺点也同时存在,即非常依赖于所关注的指标范围,如果指标涵盖的范围非常准确,那么它就可以很好地回答和解答相关的问题,可一旦超出了这个指标平台的范围之后,它的回答准确率和各方面就会有非常显著的下降。
另外,所有指标平台里面的指标是提前开发好,要做好开发就需要基于你的数据源,或者你的层面的宽表或数仓。因此当你的指标快速变化,比如说你每个月或者每几个月你的指标都会调整一次,那就意味着你的开发成本整体是相对较高的。
以上我们目前看到的大模型+指标平台的较多使用的场景以及实际的路径。
3.2 大模型+知识库+数据虚拟化的业务探索路径
http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user1/article/a70f441b82c867b70335e352e9fc80c9..jpg
在业务探索层面,目前我们看到的比较常见的方式是生成SQL,但传统的NLP to SQL的准确率相对较低,现在真正能够将准确率提高的就是GPT4,能做到约90%的准确率。同时,国内的其他大模型目前在这方面能力上相对较有限,所以,直接生成SQL是现在的一个比较大的挑战。
这一块实现路径是在提出需求后直接查询宽表,不只是通过指标平台去查,而是去查底层的宽表。对于生成SQL的准确度的要求而言,现在国内的大模型能力都不能达到。许多大型企业要做私有部署,如果使用了百亿级别的模型尺寸,它本身的理解能力和交互能力与通用模型的差距会更大。
因此,我们目前看到的一种较好的方式是使用GPT4,但其中有一种方式是并不一定要将所有数据都挂进去,只需提供与GP4相关的一些Schema,就能帮你自动生成。如果只需要做这一层,它实际上可以很好地满足你的需求。
但如果下一步计划是进行更多的归因分析,并进行一些有关预测的深入挖掘分析时,就需要使用到知识库。这其中会存在以下两点问题:
第一,数据跨境合规风险。针对跨境输送,国内政策对于数据出境方面有严格的要求,其中有提到,数据量超过一定限制时可能会引发法律风险,甚至可能涉及刑事风险。因此,合规是一个相当大的问题。
第二,企业数据泄露。对于一些头部企业,因为GPT4不断基于一些优质语料进行重新训练,一些回答和最佳实践可能被用于GPT4内部语料的训练。虽然Open AI还是公开表示不会去动数据,但是如果想要不断优化模型,他们必然需要大量高价值的语料,这些语料大量来自用户的交互场景。
因此,如果使用GPT4的方法去做外挂的话,这两点仍然存在较大的风险。而要解决以上问题,当前阶段最大的挑战是受制于模型的能力,无论是通用国产大模型还是未来的私有化部署模型,这两种能力现在都不足够。
此外,在查找宽表时仍然会受到本身的限制,也就是说当业务部门希望进行更多更灵活的自助式分析时,可能需要的数据不在单个宽表中,或者需要通过连接多个宽表来获得数据。在这种情况下,我们认为这条路可能并不可行,因为仍然需要依赖于宽表之间的连接。因此,未来的另一个方向是基于数据化虚拟化引擎。
数据虚拟化引擎本质上是在数据湖之上通过物理引擎形成的逻辑性数仓,通过数据虚拟化引擎实现整个数据资产管理后,再进行SQL的生成。然而,我们目前看到的案例相对较少,有大型银行在做POC和相关尝试,但目前没有走通的。不过我们认为,数据虚拟化引擎在未来会是一个比较好地去解决业务探索问题的方向。

免责申明:
本文系转载,版权归原作者所有,如若侵权请联系我们进行删除!


《数据治理行业实践白皮书》下载地址:https://fs80.cn/4w2atu
《数栈V6.0产品白皮书》下载地址:https://fs80.cn/cw0iw1
想了解或咨询更多有关袋鼠云大数据产品、行业解决方案、客户案例的朋友,浏览袋鼠云官网:https://www.dtstack.com/?src=bbs
同时,欢迎对大数据开源项目有兴趣的同学加入「袋鼠云开源框架钉钉技术群」,交流最新开源技术信息,群号码:30537511,项目地址:https://github.com/DTStack

0条评论
社区公告
  • 大数据领域最专业的产品&技术交流社区,专注于探讨与分享大数据领域有趣又火热的信息,专业又专注的数据人园地

最新活动更多
微信扫码获取数字化转型资料
钉钉扫码加入技术交流群