03
—
AI+BI的实施挑战
虽然将LLM与BI系统结合可以极大地提升数据分析和报告的智能化程度,对用户体验有着不言而喻的好处。但是,就当前的技术进展和结合情况来看,可能会遇到以下挑战:
数据理解的准确性
由于LLM主要通过训练数据学习,如果训练数据不包含足够的行业特定知识或上下文信息,模型可能难以准确理解复杂的业务数据。因此,LLM可能在理解复杂数据集、特定行业术语或上下文中的细微差别方面存在挑战。这可能导致数据分析结果的误解或错误解释。
幻觉问题(Hallucination)
数据隐私和安全性
模型的通用性与定制化需求
用户交互体验
我们需要确保LLM能够提供自然、流畅的交互体验,同时能准确理解用户的查询意图和需求,这可能存在挑战。因为不同用户的查询方式和习惯多样性,对应地表现为自然语言理解的复杂性,可能会影响交互的准确性和用户满意度。
实时性和性能
在需要快速响应的BI应用中,确保LLM提供的解决方案能够满足性能和实时性要求可能是一个挑战。原因在于大型模型可能需要显著的计算资源和处理时间,特别是在处理大型数据集或复杂查询时。(不过就我个人目前的体验而言,这个问题不大,反而是BI系统本身可能存在这个瓶颈需要解决)
在不断地妥协之后,我们感觉在 AI 应用落地中存在一个不可能三角,效率-准确-智能的不可能三角。希望能够快速且准确地解决问题,就会对复杂问题束手无策;需要准确地解决复杂问题,就会需要漫长的时间来思考、拆解、处理;希望能够快速地解决复杂问题,就会无可避免地面临幻觉的产生。
04
—
(部分)产品实践
网易有数ChatBI
网易数帆团队于2023年推出了基于网易自研大模型的对话式数据智能助手——有数ChatBI,它融合了前沿的AIGC技术,通过自然语言理解与专业数据分析能力,用户只需通过日常对话的方式即可获得可信的数据,极大降低数据消费门槛。
图:网易数帆的产品全景图
京东ChatBI
图:京东chatBI实现的基本结构图
百度SugarBI
SugarBI是百度智能云推出的敏捷BI和数据可视化平台,解决报表和大屏的数据BI分析和可视化问题,通过不断将AI能力融合进自身产品中,推出「文心问数Sugar Bot」功能,大幅度提升用户的数据分析效率。
图:百度SugarBI中所融入的智能化功能
基于 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、内部测试或小范围试用的阶段,部分进行了推广但基本上都尚未大规模商用。
相信随着用户反馈+持续优化完善,再加上大模型能力的进化,更加成熟、稳定、可用的新版本产品将在今年内到来。