欢迎来到AI产品经理从0到1研习之旅。
在之前的文章中,我们研习了AI大模型在电商购物和在线会议、网盘工具几种不同场景的产品实际应用情况:
电商:Shopify、淘宝问问
工具:腾讯会议、百度网盘
(点击可查看对应文章)
本文将继续这个系列,研习我本人非常感兴趣的:AI大模型在BI(商业智能)领域的实践应用。
预警:文章内容较长!全文约1.2万字:
引言:BI是什么、AI大语言模型结合BI有什么优势
AI+BI的不同模式:主要关注在数据查询分析&可视化呈现环节
AI+BI的实施挑战
产品实践:包括网易、百度、京东、腾讯以及观远数据、神策数据在AI+BI上的不同尝试
百度Sugar BI 智能问数上手初体验
思考与延伸
01
—
引言
图:阿里云Quick BI产品架构
- 自然语言处理与理解:大模型的强大自然语言处理能力使用户能够用自己熟悉的语言来查询和分析数据,这大大降低了数据分析的学习曲线,使非技术用户也能轻松上手。此外,大模型能够处理和分析非结构化数据,如客户评价和媒体内容,从而提取出有价值的信息和洞察,为企业提供全面的数据视角。
- 智能推理与预测:大模型不仅能够处理当前的数据,还能够基于现有数据进行推理和预测。这意味着它可以帮助用户识别数据中的异常点、趋势以及潜在的问题和机会,从而为决策提供支持。这种能力对于企业来说极其宝贵,因为它可以帮助企业预测市场变化,提前做好准备。
- 代码生成与自动化:大模型还能够通过自然语言指令生成Python、R等编程语言的代码,这极大地降低了技术门槛,使得即使是没有编程背景的用户也能够完成复杂的数据分析任务。这种自动化的代码生成功能,不仅提高了数据分析的效率,也拓宽了数据分析的应用范围。
- 新的交互形式:大模型引入了基于语言的交互方式,这种交互方式更加直观和自然,用户无需学习复杂的软件操作,只需通过自然语言表达自己的查询需求。这种交互方式不仅提升了用户体验,也使得数据分析工具能够更好地融入用户的工作流程中。
接下来就请随我一起探索一番。
02
—
AI+BI的不同模式
LLM在BI产品领域,适合作为现有数据分析手段的有效补充,特别是在即席数据查询、传统BI工具能力提升、简单数据挖掘与洞察等方面。
就目前来看,在自然语言的对话式BI数据分析有3种可行的实现模式:
text-to-API:即根据用户输入的自然语言,进行意图理解,并匹配调用对应的API;
text-to-SQL:即根据用户输入的自然语言,进行意图理解,直接生成SQL语句对关系型数据库(如MySQL)执行查询;
text-to-Code:即根据用户输入的自然语言,结合大模型自己对相关数据的“理解”,直接生成代码并执行分析(可以理解为ChatGPT中的代码解释器Code Interpreter)。
当然这些模式并不全面。比如说还有text-to-JSON等。
—
AI+BI的实施挑战
虽然将LLM与BI系统结合可以极大地提升数据分析和报告的智能化程度,对用户体验有着不言而喻的好处。但是,就当前的技术进展和结合情况来看,可能会遇到以下挑战:
数据理解的准确性
由于LLM主要通过训练数据学习,如果训练数据不包含足够的行业特定知识或上下文信息,模型可能难以准确理解复杂的业务数据。因此,LLM可能在理解复杂数据集、特定行业术语或上下文中的细微差别方面存在挑战。这可能导致数据分析结果的误解或错误解释。
幻觉问题(Hallucination)
数据隐私和安全性
模型的通用性与定制化需求
用户交互体验
我们需要确保LLM能够提供自然、流畅的交互体验,同时能准确理解用户的查询意图和需求,这可能存在挑战。因为不同用户的查询方式和习惯多样性,对应地表现为自然语言理解的复杂性,可能会影响交互的准确性和用户满意度。
实时性和性能
在需要快速响应的BI应用中,确保LLM提供的解决方案能够满足性能和实时性要求可能是一个挑战。原因在于大型模型可能需要显著的计算资源和处理时间,特别是在处理大型数据集或复杂查询时。(不过就我个人目前的体验而言,这个问题不大,反而是BI系统本身可能存在这个瓶颈需要解决)
在不断地妥协之后,我们感觉在 AI 应用落地中存在一个不可能三角,效率-准确-智能的不可能三角。希望能够快速且准确地解决问题,就会对复杂问题束手无策;需要准确地解决复杂问题,就会需要漫长的时间来思考、拆解、处理;希望能够快速地解决复杂问题,就会无可避免地面临幻觉的产生。
腾讯技术工程团队,benze
04
—
(部分)产品实践
网易有数ChatBI
网易数帆团队于2023年推出了基于网易自研大模型的对话式数据智能助手——有数ChatBI,它融合了前沿的AIGC技术,通过自然语言理解与专业数据分析能力,用户只需通过日常对话的方式即可获得可信的数据,极大降低数据消费门槛。
图:网易数帆的产品全景图
京东ChatBI
图:京东chatBI实现的基本结构图
百度SugarBI
SugarBI是百度智能云推出的敏捷BI和数据可视化平台,解决报表和大屏的数据BI分析和可视化问题,通过不断将AI能力融合进自身产品中,推出「文心问数Sugar Bot」功能,大幅度提升用户的数据分析效率。
图:百度SugarBI中所融入的智能化功能
- AI问答:数据可视化Sugar BI接入了百度自然语言处理(NLP)技术,通过对用户输入问题的理解,直接展现Sugar BI智能推荐的合适的可视化形式,根据拖入控制面板的数据字段为您自动推荐图表
- 自动分析:您准备数据,我生成报表。数据可视化Sugar BI 省去拖拽创建报表的过程,系统在几秒钟内,将明细数据自动制作成交互式报表,让您对数据进行快速彻底的智能分析对应地,智能问数适用的场景分别是:
- 场景1——智能问数页面,常用于业务最新情况的数据洞察。用户可以在相应页面以问答的交互形式,向Sugar BI 提出业务问题,Sugar BI 将以图表的形式返回答案及业务结论。
- 场景2——辅助用户在报表/大屏的编辑页面进行页面编辑。用户可以通过问答交互得到想要的图表类型后,直接「采用图表」将其一键固定至报表/大屏中,Sugar BI 会自动帮您进行图表的数据配置。这也是一种新的报表/大屏制作方式,同时也为编辑者提供了更丰富的制作灵感。
基于 NL-to-JSON 等能力,文心问数 Sugar Bot 帮助用户基于对话来直接完成数据探索,并完成一部分报表制作功能。同时,该团队还在进一步研发意图理解、指令拆解、图像生成等 AIGC 能力,基于对话直接满足用户对报表、大屏的生成需求,其愿景是实现大部分内容的直接生成,也就是 NL-to-X 。这样,可以通过生成式 AI 直接满足更多用户业务目标,逐步实现业务与技术重构。
(1)AI问数
图:SugarBI AI问答的整体技术架构
(2)自动分析
图:SugarBI 自助分析的整体技术架构
腾讯DataBrain chatBI
腾讯的DataBrain团队在GPT4发布之后,尝试结合其能力构建了一个服务于 DataBrain 系统的统一语言智能助手Demo——chatBI,能够让用户在统一的语言交互界面完成数据分析的全过程。和京东的chatBI一样,该产品目前仅供内部使用。
观远数据BI Copilot
BI Copilot 是观远BI利用大语言模型的能力构建的最新模块,接入了微软Azure OpenAI 商用服务权限(大家理解为就是ChatGPT背后的技术即可):
Chat2Answer利用知识库构建,可以帮助业务用户理解数据的含义,并提供智能解读。当用户提出数据相关的问题时,Chat2Answer会解释数据背后的原因,并给出针对性的建议和可操作的方案。
这个功能早期的时候叫“chat2SQL”(也就是我们前面提到的text-to-SQL模式),通过自然语言交互协助生成 SQL 查询语句。以实际工作流程为例:
用户在遇到问题时可以直接向Chat2Help寻求帮助。当遇到报错或问题时,只需将报错信息复制粘贴到对话框中与Chat2Help进行问答,它将直接告诉用户报错的含义,并指导一步步排除报错、提供解决方案。
神策数据Copilot
神策数据的产品主要是CDP(客户数据平台)领域的,和我们前面所提及的“BI”不是一个概念。不过在研习过程中发现它也利用大模型技术推出了神策分析 Copilot(另外还支持用于运营Copilot),同样支持自然语言的交互,自助式地进行数据分析与查询,因此还是纳入本文中。
从目前的Demo介绍来看,其支持的一些场景如下:
(1)智能分析:应用大模型技术理解用户问题,自动配置分析模型
以事件分析场景为例,在输入框中用自然语言输入要获取的数据指标,比如最近7天搜索点击的用户数,GPT 模型将自然语言转化为请求查询JSON 并发起查询,并进行图形化展示。
在这里,神策团队采用了text-to-json而不是 text-to-SQL的模式,其考虑有二:一方面更容易理解,便于业务人员判断查询;另一方面更容易进行人为干预,比如生成的査询 JSON 不对,想换种计算方式或查询条件看看指标怎么样,可快速调整。
其实现过程大致为:
首先,把schema(简单理解为是关于数据如何存储、数据之间的关系以及数据应该如何解释的信息)传给GPT,让GPT理解数据的schema以及任务。考虑到存在长度限制,需要优化设计,从报表的上千个字段中筛选出进入到 prompt的字段、以缩短prompt。
其次,筛选出来的 schema 会有很多的字段,字段多了也会影响 GPT 的正确率和精准度,因此需要跟 GPT 进行交互,让它挑选出哪些字段与需求有关。
最后,通过 GPT进行 JSON 的生成。对于复杂的查询,可以先让它生成一个结构,在这个结构下再把内容填充进去。
(2)指标搜索:自然语言查询例行指标
应用大模型技术构建指标搜索能力,帮助业务人员快速定位到当下关注的指标和经营概览,或深入探索特定业务的相关指标。支持用户口语化输入,业务人员无需输入专业术语或确切的指标名称,也能获得相关的数据指标。
例如在零售行业中,若用户想知道近期的商品销售数据,直接对Copilot 提问“卖得最好的商品”,它便会推送“当天 Top 商品”“热门访问商品”“商品销售数量”等指标查询结果,无需依赖分析师进行查询。
(3)数据门户融合:数仓对话插件
当然啦,除了这些产品,其实还有很多其他的AI+BI实践,但时间和精力有限,我们就不继续拓展了。
就我本人所掌握的情况来看,包括但不限于以上提及的经过大模型加持的AI+BI产品,大多都还处于Demo、内部测试或小范围试用的阶段,部分进行了推广但基本上都尚未大规模商用。
相信随着用户反馈+持续优化完善,再加上大模型能力的进化,更加成熟、稳定、可用的新版本产品将在今年内到来。
05
—
SugarBI问数上手初体验
上面所提到的产品大多没有机会上手(例如内部产品或仍在测试阶段)体验,但总算在2月初申请到了百度SugarBI文心问数的体验权限。
参照官方指引,基于示例数据,我进行了简单的探索:
(1)数据模型准备
在数据模型的设置页面,可以选择对应的数据表并建立关系:
在编辑页面可以将字段名称设置为可读性较高的中文别名:
对于原子指标(度量),我们可以设置AI问答的同义词(也就是帮助大模型理解专业术语,可能用户会有不同的问法)作为其“知识库”:
我们也可以新建度量(指标加工),这就是常规的BI功能了:
对于AI问答功能,需要开启并等待模型训练完成才能使用(不过我没有权限):
我们还可以配置AI问答的推荐问题,这个如果在ChatGPT中自定义过自己的GPTs的小伙伴应该很熟悉:
然后我们就可以通过智能问数Sugar Bot和系统进行交互了:
当我点击上图中的“需要结论”时,系统会自动总结如下:
并且还能发现数据的不合理之处(确实如此):
整体上来说还是蛮有意思的,确实是一种全新的体验、并且是已经实际落地到现有产品中了。感兴趣的小伙伴可以自行申请体验。
值得注意的是,SugarBI有以下限制:
- 用户提出的问题字数限制为 300 字(空格也算做有效字符)——我想这主要是出于性能与成本控制的考虑。通过限制用户输入的字数,可以有效控制后端大模型处理请求的复杂度和资源消耗,同时鼓励用户提出更精炼、更具针对性的问题,提高处理速度和响应质量。因为除了用户输入的问题,如观远数据所说还需要给大模型传数据schema,因此压缩总的prompt是必要的。
- 当生成的图表不符合预期时,可以点击「重生生成」但最多可以点击三次——为什么是3次?这个设计可能是为了防止用户无限制地重新生成结果,从而导致资源浪费和系统压力。限制重生次数可以鼓励用户更加仔细地考虑和优化他们的查询,同时也是一种计算资源的管理策略。此外,这也可能是基于用户行为的统计分析,认为三次重试足以覆盖大多数情况下的需求调整。
- 如果在大屏/报表编辑页面中关闭智能问数页面,Sugar BI将会清空之前会话的全部内容——这一限制可能是出于数据安全和隐私保护的考虑。自动清空会话内容可以防止敏感数据残留在系统中,尤其是在多用户环境下。此外,这也有助于保持系统的高效运行,避免不必要的数据积累影响性能。
06
—
思考与延伸
在前面的研习内容中,我们主要关注支持自然语言交互模式下的BI数据查询、分析和可视化呈现。实际上,在从问题定义、数据接入、处理、可视化展示、交互分析到决策行动的BI数据分析全链路中,AI大语言模型都有结合的机会。
- 问题: 确定分析的焦点,如提升销售额、优化库存等。
- AI赋能: 使用AI模型生成初步的数据分析和决策计划草案,再人工校对修改,以确保方向和目标的准确性。
- 问题: 如何高效处理和分析非结构化数据。
- AI赋能: 利用AI技术直接分析非结构化数据,减少传统的数据清洗步骤,加快从数据到洞察的过程。
- 问题: 简化ETL开发过程,提高数据处理效率。
- AI赋能: 通过自然语言交互生成ETL任务和代码,辅助数据处理,实现多轮交互式构建,提升数据处理的灵活性和准确性。
- 问题: 快速响应业务问题,提供直观的数据结果和结论。
- AI赋能: 自动根据问题生成SQL、JSON,利用AI生成文字结论、可视化图表和行动建议,实现问答式BI。
- 问题: 如何自动化深度分析报告的生成,提供可信的业务分析。
- AI赋能: 基于BI系统能力,结合企业内部数据源和AI生成的数据指标,自动识别异常原因并用自然语言展示,减少认知偏差(例如波动分析、异常分析和预警)。
- 问题: 如何基于数据分析提供具体的未来行动建议。
- AI赋能: 提供辅助性预测和基于历史数据的推荐建议,支持数据驱动的决策过程。
支付宝团队在基于蚂蚁集团基础大模型开发研制数据分析智能助理 Deepinsight copilot的过程中,比较系统化地梳理了结合大模型的数据分析智能助理功能需求,划分了不同的智能化等级,非常值得我们参考和学习:
注:
CoT即思维链(Chain-of-thought),模仿了一个逐步思考的过程来得出答案。
TOT即Tree-of-thoughts,CoT通常只有一条解决问题的路径,ToT等于是CoT的一个拓展,把一条reasoning路径拓展至多条reasong paths,这样模型可以综合多条reasoning path的结果得到最终的结论。
ReAct:即Reason和Action,Reason生成分析步骤,Action生成工具调用请求。是目前最常见和通用的增强式语言模型(Augmented LM)范式,它启发于传统强化学习,通过提示词构造“想法”(Thought),“行动”(Action),“观察”(Observation)的思维链, 逐步启发大语言模型根据当前工具的输出产生观察,从而进一步产生下次推理。这种范式被广泛应用在近期爆火的 Auto-GPT 和 LangChain 等项目中。
ReWOO 即Reasoning WithOut Observation,通过模块化解耦(Decouple)大语言模型的“预见性推理”(Foreseeable Reasoning) 和工具的执行,从而实现在HotpotQA等任务上数倍的词元效率(Token Efficiency), 并且提高了模型表现以及复杂环境下的鲁棒性。在ReAct中, 指令微调不可避免的会导致小模型“背住”训练集中的工具输出。然而,ReWOO由于将显式的工具输出跟模型的推理步骤分离, 可以因此借由指令微调使其学会具有泛化性的“预见性推理”能力。
DAL我没有查到,我估计应该是DSL,即将自然语言转化为特定领域的语言(Domain-Specific Language),也就是我们前面提到的text-to-code。
KG即知识图谱,在上一篇文章中正好进行了比较深入的研习。
AI+BI的融合为商业智能领域带来了前所未有的机遇,通过大语言模型的应用,可以极大地提升数据分析的效率、深度和准确性,同时改善用户体验。
作为AI产品经理,理解并把握AI技术在BI产品中的应用,不仅需要技术和业务的深入理解,还需要持续的创新和优化。通过有效地结合AI和BI,我们可以更好地解锁数据的潜力,支持数据驱动的决策,推动企业的智能化转型。
以上,就是关于AI大语言模型在BI领域的应用研习分享。
本期到此结束。
再见
本文地址:http://sicmodule.glev.cn/quote/8278.html 歌乐夫 http://sicmodule.glev.cn/ , 查看更多