赞
踩
大模型应用的领域越来越广泛,以BI为代表的数据分析,是大模型在企业用户内部最先落地的应用场景之一。
为了更好应对海量数据和高复杂度决策的挑战,越来越多企业开始寻求将大模型与BI相结合的应用方案,实现对海量数据的深度挖掘和分析,从而更好地理解客户需求、市场趋势和业务运营情况。
本次分享将会把重点放在介绍对大模型和BI相互结合时的落地方式,以及针对企业侧具体实践落地案例进行解读。深度干货,建议收藏!
首先,我们需要了解传统BI工具和大模型之间有哪些可以结合的地方。传统BI工具通常分为数据接入层、分析工具层和基于该工具平台的各种行业应用层面,大模型可以在这些环节发挥作用。
在数据处理层面,大模型可以帮助传统的ETL过程简化难度,提高实时交互效率。在数据分析层面,大模型可以替代拖拽交互方式,让业务用户用更简单、更高效的方式以自然语言形式与底层数据交互,来构建需要的报表和看板。
在行业应用层面,大模型可以真正发挥对行业知识的理解能力,与具体数据结合,形成具针对客户、特定项目、指标体系的输出,再加上数据准备,可能直接输出标准化的项目成果。接下来会这三个层面依次展开,分别对大模型能力进行讲解。
数据处理主要会通过三个方面使用大模型的能力。
第一,通过对话式的交互方式生成ETL,降低难度。 同时在ETL过程中,可能会有许多SQL、Python节点。在这些节点上我们同样可以调用大模型的能力,让其生成对应的SQL或Python代码。
第二,大模型可以辅助生成专属派生指标和计算指标,即一些SQL代码片段,以及MDX表达式。 在传统ETL工具中,我们可以通过类似于聊天的交互方式让大模型帮我们选择最合适的节点,从而对数据进行处理,辅助生成DAG图。
第三,在数据模型模型或指标模型中辅助生成计算字段的SQL或者MDX。 在ETL过程中会涉及到一些传统的SQL节点,包括Python代码等节点。在这个层面上,我们可以借助大模型的能力去生成。
目前阶段,我们仍然难以直接将底层数据库交给大规模模型处理。首先,我们主要是通过接口调用大模型来使用,而大部分大模型没有进行私有化部署,也无法传输整个数据库,只能处理元数据定义和部分模式,输出也基于该提示词的处理,因此生成的SQL质量取决于信息传递和提示词生成的质量。
据目前看,这部分看似技术难度相对较低,实现也相对容易。但是在处理该项时,最大的问题是很难控制分支对象的质量。因此通过大屏幕能力构建模型的许多环节,可能会借助这种界面入口生成SQL片段或者使用MDX表达式。
比如,我们通常在模型构建过程中通过人工调用许多表达式函数来生成,这对于大多数用户而言具有一定的学习和掌握难度。如果我们能够通过学习和微调使大型语言模型掌握此能力,则可以帮助我们完成此项工作。
接下来再聊聊数据分析层面大模型能力的使用。
在这个环节中,直接与最终业务用户或需要使用数据的用户交互的形式,是通过自然语言对话形式进行数据的查询、分析和利用。从技术上来看,这个环节成熟度相对较高,因为商业用户自主分析工具已经发展了很多年,尤其是这种交互方式不断落到底层,接口越发完备。
我们只要让大型语言模型本身去帮忙理解这种语义,并与传统能力相结合,就可以让使用过程相对简单易懂。我们知道,此前数据分析大部分能力都是通过传统的NL2SQL方式来实现的,那么这其中大语言模型矩阵的哪些环节发生了作用呢?我总结出了以下两点。
我们期望让大型自然语言处理模型可以更精确地理解用户的输入,特别是针对那些常识性的问题。以传统的NL2SQL举例,它难以解决像“作为一家公司,我想查询公司内部有多少本科以上学历的员工”的这种问题。
虽然该模型可以准确地识别“本科”这个词,但对于“本科以上”这四个字的理解就有困难了,因为它代表的是一个字符串类型的字段,而无法简单地通过大于等于号等操作符进行筛选。
然而,一旦引入了大语言模型,就能够很好地解决这个问题。它可以准确地告诉我们“本科以上”代表的是本硕博学历,只要将该信息带入生成的查询语句的过滤条件中,就能够得到我们所需的结果。
以上只是一个小例子,我们期望大语言模型能够帮助我们处理,与特定行业领域知识相关的常识性问题,这样将其与传统的NL2SQL相结合,将有助于提升其语言理解能力,同时也能提高数据结构返回的准确性。在大语言模型出现之前,我们也可以解决类似的问题。
然而,过去的项目实施通常需要依靠项目化的方法,通过不断的配置和人工微调的方式来解决查询模板无法处理问句或需求的问题,导致项目实时交付的周期长、功能投入大,长期需要运维人员持续维护。而现在,大语言模型具有自适应学习能力,可以缩短实时交付周期,以最终降低成本。
如果能够将底层的数据库,特别是数仓或大数据平台直接开放给大语言模型进行学习或微调,那么是否就能够准确地处理用户的智能问句,并获得用户所需的答案呢?实际上,这可能不太现实。在传统项目实施过程中,即使是最熟悉数据库结构的人,也会发现对底层数据库的处理过程存在困难。
首先,语言对于同一个指标本身的理解其实不是技术问题,而是一种业务决策。 为此需要业务协助去确认数据处理口径和结果的正确性,这个过程很难完全通过技术手段解决,因此我们必须在原始底层数据库之上构建智能模型。只有在最终业务用户确认数据指标和对应维度的情况下,才能将这个模型交给大语言模型,以便查询所需的结果。如果没有进行这些工作,那么直接开放底层数据规则将会得到缺乏解释性和不准确的结果,用户会很难理解。
其次,在底层关系数据库上很难进行一些复杂的派生指标计算。 例如,同比和环比的始点值、期末值,以及全年累计等指标的计算都无法通过SQL的能力进行计算。在这种情况下,大型语言模型也无法满足这些需求,因此需要在模型层面具备此类能力。通常会倾向于建立多位数值的模型,并利用其计算能力来处理这些复杂的派生指标。只有在具备这个前提下,我们才能使数据处理变得更加顺畅。
最后,我们最渴望的是让大语言模型本身去帮助我们准确理解用户意图,并进行一层中间处理最终与模型综合起来。 固定的模型需要特定的模型查询语言,只需要让大语言模型理解我们的大模型查询语言即可。
如需实现对用户的支持,必须有某些自然语言方式的交互和底层数据交互的先决条件,以下几个条件满足才能确保最终权威可靠的结果,并获得最终用户的认可。
1、需要对底层数据进行建模,确保模型的输出结果是准确无误的。
2、通过模型本身提供的复杂指标计算能力解决大模型难以处理的需求。
3、利用大模型自身精确理解一些常识问题以及我们学习模型查询语言的过程,输出高质量的查询语句,获取数据,并利用BI工具自身的图形展示功能呈现数据。
在大量的项目实时交付过程中,我们发现不同行业都有自己的指标体系,而用户常看的指标质检体系目前只有少数行业专家能够完全理解。实际上,现在这些知识被认为是行业通用知识,大语言模型也对它有一定的了解,GPT-4通过对行业指标体系的理解,输出的结果已接近于行业专家的水平。
将这种能力与客户需求相结合,我们可以做些什么呢?最理想的目标,我们可以通过利用大模型对行业通用知识和指标体系的理解,结合与客户项目的数据,输出针对当前项目的指标信息。结合具体的数据再利用基于指标体系的实时方案或实时工具,可以输出一个直接被当前项目使用的指标模型。
指标模型做出后,下一步主要工作就是往指标库里灌输数据,在这个层面利用大模型的助力,就能让这项工作高效完成。据我们的研究,如果这种实施方式落地,将会缩短项目建设周期从现在的三个月到半年的时间,缩短至一两个月甚至更短。虽然输出的结果可能不会完全满足客户的要求,但至少可以作为项目实施的一个起点。这在很大程度上缩短了项目实施周期并有效地降低了成本。
前面提到的是技术结合的若干要点,下面我们来探讨一下如何在具体项目中将大模型和BI结合,实现路径中都有哪些。在我们理解中,实践应用大致有三种不同的目标,分别是短期、中期和长期的。
就短期目标而言,我们希望通过智能问答的方式与传统的数据分析应用相结合,以及自然语言对话的方式,使普通业务用户能够更简单、更高效地与底层数据交互查询,获取所需结果。中期目标是将其变成面向技术人员的数据处理工具,通过对话交互的方式加快数据梳理流程。至于长期目标,则是通过自然语言引导式实现BI系统的完整构建。
实际上,在当前阶段短期目标是最容易实现的,因为我们在之前已经有了很好的数据技术基础。对于许多企业而言,最差的情况仍然是已经拥有自己的数据仓库或大数据平台,并且有一部分已经构建了指标体系。此外,刚才提到的技术本身也已经非常成熟,比如NL2SQL技术已经出现多年,并且早期已经有大量的项目实施。
结合大语言模型后,它本身输出结果的质量也会更上一层楼。它可以有效地支持项目开发周期,快速看到成效,特别是适用于这种项目的快速优化和迭代。实际上这种能力相对基础,本身不仅可以集成嵌入以前的工具,还有许多其他的应用。例如,它甚至可以作为一个完全独立的应用,比如市面上许多厂商推出的面向普通业务用户的个人数字助理。只要与企业内部的标准数据模型和指标模型连接,用户就可以随时随地以各种方式交互数据。
而中期目标的实现主要是通过自然语言进行自助式的数据探索。这种能力可以集成到任何第三方应用程序中,并将其应用于第三方系统。例如,我们期望将该大矩阵模型直接引入传统的数据处理过程中,利用类似现有界面或传统编辑方式进行多轮对话,基于之前的查询结果进行一些子查询,同时对查询结果本身进行一些归因预测机制学习建模,从而创造更丰富的数据处理能力并降低数据处理难度。
而最后的长期目标当前处于行业探索阶段,需要等待技术进步和突破。
接下来将通过两个项目案例介绍来进行详细说明。
第一个案例客户是一家国内规模较大的保险公司。当时该公司为高层领导制作了大量的手动移动端报表,大约有150张左右,但对方表示报表数量太多,在手机上很难找到对应报表。
因此客户当时的需求是:
第一,能否通过自然语言指令的方式,直接进入现有的报表中并且可以通过语音指令方式去切换报表里面参数,这也是他们最核心的需求。
第二,即便C端报表已经做了一两百张,但仍有很多需求没有得到满足。在以往的模式下,需要将数据发送给IT同事开发相应的报告。
但是,针对需要的数据,能否随时随地自动生成报告呢?针对这两个需求,我们可以对上海分公司的新业务单价值总和、订单价值排名前五的子公司表格进行对比,以及比较上海分公司和北京分公司近五年的新业务单价值情况。
就像刚才简单的三轮查询一样,其中可能已经有现成的报表了。如果我们按照当时的匹配原则,优先匹配已有的报表,如果这些查询不能命中现有的报表,我们就去尝试创建新的报表。
项目推进过程中我们发现,所涉及的保险行业具有许多专有术语,如前述“新单”一词,这些术语的底层定义可能并不具有特定的维度,那么如何应对这个问题呢?我们需要在旧的模型训练界面上进行人工微调,将这些术语全部定义好,甚至在出现同义词时,也需要处理这些同义词。随着大语言模型的引入,我们现在可以针对保险业这个领域训练出大模型,然后进行微调,从而在较短时间内交付此类项目,并对项目进行优化,从而使效果更佳。
第二个案例客户是国内比较大的证券公司。在大模型受到广泛关注后,年初时有非常多的金融机构都开始尝试要引入相关技术。我们发现,这类金融机构最大的特点是数据质量相对较高,其所需的模型和指标早已建成并具备完整性,只要把我们的产品与现有模型结合对接,让这种能力直接集成到企业内部的App中,最终这个项目也是在短时间内迅速上线。客户员工日常的工作主要通过语音对话方式查询获取数据,摆脱了传统的报表或敏捷BI的查询方式。通过拓展方式生成图表,最大的改变是让交互方式变得更加简单、查询更加高效。
由于新岗位的生产效率,要优于被取代岗位的生产效率,所以实际上整个社会的生产效率是提升的。
但是具体到个人,只能说是:
“最先掌握AI的人,将会比较晚掌握AI的人有竞争优势”。
这句话,放在计算机、互联网、移动互联网的开局时期,都是一样的道理。
我在一线互联网企业工作十余年里,指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
-END-
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。