随着大模型技术的快速更迭,企业内的落地场景逐渐丰富,智能数据分析则是重点关注和落地的场景之一。本次专家将会从数据分析的痛点与挑战、GenBI的落地路径、真实客户落地案例分享三方面进行展开。
分享嘉宾|于涛 亚马逊云科技解决方案架构师
内容已做精简,如需获取专家完整版视频实录和课件,请扫码领取。
01
数据分析痛点与挑战
基于零售行业的数据分析场景,有7个典型的分析阶段,首先是业务仪表盘的呈现,基本上是每个企业都会做的智慧大屏或智慧报表,用来体现业务发展概况。接下来就是数据的洞察和挖掘阶段,也是每个企业最难做的部分。例如每个不同区域、不同行业的绩效分析,每个不同的 BU 、业务线下的 SKU 如何进行合理有效的定位及产品未来走向的分析等等。同时在这个基础上还可以增加行业化的建模,包括数据血缘、数据打通等等,利用外部的数据进行整合,或者通过 what-if 模拟情况进行分析和预测。
而实际公司需要的 BI 不仅是仪表盘或者报表。
传统的 BI 分析有非常多的问题和挑战,比如 BI 报表和仪表盘,虽然是可视化呈现,但本质反馈的是静态数据,缺少灵活性和归因。
而对于数据的应用,则需要 IT 团队和业务团队紧密地配合,比如在进行数据集成的时候,数据运维工程师会通过 ETL 工具进行数据抓取,数据分析师会通过数仓、数据湖的工具进行数据血缘关系的建立,以及建立整个公司的数据网格,业务端也需要基于 SQL 生成后的结果进行最后的归因分析和统计。
所以对企业而言,面临着如何快速进行数据清洗和数据分析?如何编写企业周报/日报?如何在尽可能少的人手实现业务洞察和决策?对于员工而言,每个人的专业水平参差不齐,如何在不了解 SQL 的情况下进行数据分析?如何在没有专业能力的前提下进行数据解读?不少企业尝试在数据平台中,加入大模型能力,实现自然语言的问数和数据的编辑处理。
02
落地路径与关键技术分享
没有大模型能力之前,大部分企业会使用 BI 工具进行数据的可视化和数据分析,往往需要通过数据分析师来生成相应的 SQL 语句,实现内容的查找、归因、可视化仪表盘的建立。
有了大模型能力后,不再要求数据需求人员会写 SQL ,现在可以利用生成式 AI 能力进行对话式的 BI 分析。比如举三个数据分析常见的例子:“上个月的浏览量有多少?”“同比/环比增长是多少?”“浏览量上升或者下降的原因是什么?”按照传统的 BI 分析方式,这三个问题就需要用到一些复杂的 SQL 才能实现,对于数据分析人员有一定的要求。如何实现对话式的大模型数据分析呢?关于建设路径中,最重要的是准备好原始的数据和原始的信息,这部分和最后的查询结果息息相关。
从上图中可以看到,在最上层需要数据分析师进行前置的输入,包括标准数据分析思路、归因推理思路、 SQL 书写规范等等,能更好的衔接每家企业的技术基础和分析要求。
再是大语言模型,它的底层的能力随着国内外各种模型的加速迭代,模型的参数逐渐更高和模型回答的结果逐渐更好,大模型的选择和模型的适配必须要考虑因地适宜。
最后再通过用户的输入,实现自然语言的方式进行 SQL 的生成、运营诊断、数据规律总结、运营建议。这就是整体的构建结构和路径。
从数据分析实践的角度来看,通过自然语言的方式,可以很轻松的实现 SQL 查询语句的生成,但随着企业数据越来越多,企业数据表关联的信息越来越多,很难通过一句简单的自然语句实现较好的查询效果。
所以在大模型实际落地中也正面临着一些挑战。
在实际经验中我们总结发现,利用大模型的推理能力和通用的知识理解,辅以外部的知识体系(RAG)和执行规则来达到比较好的生成效果。
对于元数据过于庞大复杂:可以通过数据 ETL 的清洗,把多表拼接成单表来减少表的数量,进一步提升效果。
大模型缺少数据库表结构和表字段的理解:可以通过提示词工程,对表结构和字段的含义做详细说明。
大模型对专业名词缺乏理解:比如苹果是指 iPhone 还是 Apple ,可以添加实体识别功能,增加实体的检索,来补充对应的知识。
关于大模型训练语料不全:可以在大模型中加入 SQL 样本检索,增加学习样本,来激活模型的迁移学习能力。
大模型没有反馈机制:可以在使用中加入反馈的机制,通过点赞、点踩的方式来提高系统生成的准确率。
针对思维链问题,如果没有业务知识无法直接生成 SQL:可以在大模型中加入意图识别,或者 Agent 功能,实现对思维链问题进行任务拆分,通过设置不同的步骤,帮助大模型进行理解。
如何根据 SQL 快速生成数据看板指标:可以通过 API 与 Metabase 集成,生成对应的 SQL 之后,就可以快速生成看板指标。
最后再看下整体的框架,分为数据预处理、业务知识库搭建、Query 改写、意图识别与实体识别、知识召回、 SQL 生成、数据总结和可视化 7 个环节。
接下来会从如何落地的角度,详细展开几个关键步骤。
步骤一:数据 ETL
关于数据 ETL 处理层,我们会对数据的表格进行清洗,构建指标层,这能很好的提高 SQL 的生成效率。例如在真实的数仓或数据库中,会有非常多的订单表、订单库和订单信息,如果把对应的表进行 join ,来生成对应的产品数据统计表和产品订单表,就从 5 个表变成了 2 个表,就能减少不同表 join 的情况。对于前期的数据处理和数据准备是非常重要的一环。
步骤二:提示词工程
提示词工程也是非常重要的一个环节。对于大模型来说,它并不知道企业实际的数据是什么,也不知道表的信息是什么,所以需要提前把数据和字段进行定义和配置。
步骤三:知识检索-实体识别与实体检索
通过识别 Query 中的实体,增加实体信息,可以提高大模型对专业名词的理解能力,提升生成 SQL 的准确率。
以查询产品 A 在 2023 年 12 月份订单环比增长为例,首先会进行实体的识别,识别到【产品 A】【订单量】【环比】三个信息,此时触发下一个流程- embedding ,再进行一些向量检索就可以找到对应的表信息、列信息、实体信息等,最后拼接成对应对 prompt ,进行 SQL 语句生成,这就是背后的原理。
步骤四:知识检索- SQL样本检索
通过增加样本,提高大模型推理能力和大模型对SQL任务生成的理解能力。
以上图为例,最右侧匹配到【 0.67688006 0.10631783】对应的信息是“产品 B 今年 1 月北美的环比增长?”,它其实已经有预置的 slack 的条件语句或 SQL 语句,如果其他的运营人员在问相似问题的时候,大模型其实会检索对应的一些样本实现生成,这样也会提高 SQL 生成的准确度。
步骤五:负反馈机制
在知识库检索的时候,针对生成的 badcase,可以在前端或在应用里面加入点赞和点踩的反馈机制。通过点赞的方式把 goodcase 的权重拉高,通过点踩的方式把 badcase 记录对应的表里,帮助数据分析师来进行后续的迭代和优化,所以在生成式 BI 的项目里面,并不是一次性的项目,需要按照飞轮的方式进行快速的迭代。
步骤六:意图识别
关于意图识别,比如用户在提问的时候,大模型需要去识别对应的意图,并区分不同的意图是什么含义。比如拒绝意图,如果用户提出“帮我删除对应表里所有的数据”,这个操作对于整个系统和数据的安全是致命的打击,所以需要对于一些意图进行有效的判断。
还有思维链的查询意图,需要调用多个 Agent ,进行任务拆分,比如说“ 5 月份的订单量为什么下降了?”可以拆分到用户维度、城市维度,最后将对应的内容进行综合的思考。
03
客户案例分享
德比软件主要是针对旅游业做营销系统的技术服务,他们在数据分析场景的痛点有三个。
第一是面对业务决策人的数据分析及查询需求,可能在月初或月末时,对于需求的响应不够及时。
第二是很难通过报表以外的地方,准确地查询到对应的订单、销售数据等等。
第三是每个部门的数据结构不一样,不能很好的理解数据,通过执行 、Chat BI 或 GenBI 的项目也可以很好地进行数据规范和数据结构化的打通,实现跨平台或跨资产或跨产品的数据查询。
ChatBI用户端操作演示
这是在亚马逊云科技 ECS 容器化服务里面构建的一个应用,对于用户操作端的使用界面。右侧可以选择集成不同的大模型,底部的输入框可以进行提问。在亚马逊云科技与德比软件的合作案例中,实现了打通 AI 和 BI 平台数据隔离,可以更好的利用企业知识,快速地进行经验的赋能,通过自然语言进行对话分析,生成对应的结果,同时有效进行降本增效。
特别福利:亚马逊云科技 GenBI 支持开源,扫码获取开源项目文档。
负责亚马逊云科技云计算方案咨询和设计。目前主要专注在现代化应用改造和机器学习领域的技术研究和实践。加入 亚马逊云科技之前曾服务于大型运营商及 IT 解决方案供应商,积累了丰富的跨境电商/快消行业项目经验。
热门跟贴