AI知识库 AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


AI+BI第二弹:QuickBI已支持智能搭建&智能问数
浏览次数: 1551

欢迎来到AI产品经理从0到1研习之旅。
AI大模型在BI(商业智能)领域的实践应用是本人非常感兴趣且持续在关注、研习的方向。
更多相关信息请移步阅读前文《AI+BI:结合大语言模型实现对话式的智能报表系统》。很多思考和探索在该篇文章中已经有所披露。
本文继续延续该系列,重点学习和分享来自阿里旗下的瓴羊Quick BI,并结合自己的认知给出一些思考、建议。
声明:这不是广告,我都是自带干粮,出于个人兴趣进行的探索。

01
引言
Quick BI是阿里云旗下的大数据分析与展现平台,最初起源于阿里巴巴2011年开发的内部自助分析产品,Gartner发布的商业智能和分析平台魔力象限报告(Magic Quadrant for Analytics and Business Intelligence Platforms)中属于难得入选的来自中国的企业产品(目前处于挑战者象限),可见总体的产品竞争力还是不错的:
Quick BI在2021年就尝试推出基于传统算法的智能问答功能,但由于后台配置较为复杂且对用户输入有一定要求,效果并不理想。随着LLM的出现和发展,Quick BI在2023年底推出了基于LLM的专属助手——智能小Q截止笔者写下本文之际,尚处于邀请测试阶段,并未正式商用)
Quick BI在其多年积累的已有基础功能上,
融合了阿里的通义千问大模型+经验微调后的BI领域大模型,目前已支持【智能搭建】+【智能问数】2项功能:
接下来,让我们通过对产品现状的研习和体验,以便更具体地了解大模型在BI领域的落地思路、表现和挑战。
02
智能问数
和所有的BI产品一样,在进行数据分析和报表搭建之前,Quick BI也需要连接数据源,这一点无需赘述:

 问数配置

尽管相比早期基于传统算法的智能问答式报表系统,智能小Q已经不需要操作各种指标字段的口径、数据之间的连接关系等繁杂的后台配置,但是一些基础的配置依然不可避免。
如下图所示,需要对指定的数据集开启问数配置(这个在体验百度SugarBI时也能看到类似的操作)用户才能通过自然语言对话的方式,获取分析数据集中的数据:
在开启问数配置后,用户需要进一步完成字段配置和数据集配置才能完成准备工作。
规范字段命名:为了让大模型更好地理解数据,我们应该确保字段名称简单易懂。这样,模型就能更准确地理解我们的问题,并找到正确的数据来回答。清晰的字段名称还可以帮助避免误解,尤其是当数据中有多个相关字段时,例如:
这种数据准备工作是少不了的。通过对数据的整理、格式化和优化,有助于更好地支撑基于大模型的数据分析需求,从而提升前端用户的查询体验和准确性。例如:
  • 字段名应该符合用户的提问方式,保持清晰、规范的同时避免重复(否则大模型区分不了)
  • 字段类型需要争取标注,例如日期/时间类型的数据,否则将影响识别
  • 字段聚合的默认方式,如“转化率”默认选择按平均值计算,而“累计XX”默认选择平均值或最大值而非汇总。这样一来,当用户没有表达具体的聚合方式要求时,模型可参考这一配置来取数
配置字段描述:为了让模型更懂我们的数据,给它提供字段的具体解释和背景信息,这样模型分析数据时,就能更准确定位并使用正确的信息。同时,如果用户用专业术语提问,这些描述可以帮助模型更好地理解,给出更准确的答案。
然后让大模型对该数据集进行“学习”,本质上是进行知识的吸收和理解,包括识别关键的字段、数据类型和任何潜在的关联等,找到将预训练模型的知识应用到这些数据上的最佳方式:
学习完成之后,即可通过权限配置将其授权给对应的角色/用户:

 知识库配置

知识库用于配置企业内知识和用词偏好,配置后,模型会学习该知识并将其用于数据获取和分析——这本质上是为了缩小“通用大模型”VS“企业大模型”之间专业知识差距(参见《浅谈大模型私有化+精调:面向垂直行业与特定场景之需》),让小Q更懂“你”:
比如“近期”则默认取最近30天的数据,“流失客户”默认取超过90天没有交易记录的客户:
看到这里我们就已经能推断出,智能问数采用的是LLM+RAG的方式来打造的,这也是目前chatBI类产品实现的基础模式(当然还有其他的更多增强手段可以一起采用,例如多Agents分工与协作)。
特别地,官方文档表示知识库暂不进行模糊识别与推理,提问内容中须提到业务定义或近义词,才可生效——这虽然可以减少模糊性、使得智能小Q提供的答案更加准确和可靠,但无疑也增加了用户的使用门槛、和用户期望差距较大。

 智能问数操作

在Quick BI首页点击智能问数即可进入智能问数对话页面:
在对话页面中用户可以看到有权限的数据集,用户可选择预览数据集或直接基于该数据集进行提问:
在预览界面,可以查看数据集的字段详情及数据预览,并支持进行快捷提问(由大模型自动生成):
过程中可根据需要在权限范围内切换数据集进行对话:
这是我尝试用体验账号开启的对话:
我们可以直接输入问题,也可以通过快捷提问或最近提问发起对话。
然后小Q就会开始执行分析&呈现。在查看数据的同时,支持以下功能:
查看AI取数过程
这是将取数的思路进行了透明化的呈现,以便有需要的用户可以校验结果是否符合诉求
图表切换
小Q默认生成了一种可视化的图表展示形态,不过从实际体验而言我觉得做得不够好(当然这可能和个人习惯有关,非全面测评),即模型默认选用的图表形态,和我心目中“期望”的形态未必相符。
毕竟准确使用图表,也是合理传递(展示)分析结果的重要影响因素:
不过用户可以自行切换以更符合查看习惯(基于不同的数据,可切换的范围会有所变化)
全屏查看分享数据⑤导出数据不算什么个性化的特色功能,我们就不展开介绍了。
进一步洞察
指标看板支持归因:
线图和柱图则支持预测:
除此之外,还支持追加提问功能:对上一个问题的结果继续提问,从而以更加精准的角度了解数据。
不过目前一个问题仅支持追加 1 次提问。
至于对话列表、移动端的支持,在目前使用的对话式chatBot产品中都属于常规功能了,诸位看官应该都很熟悉:
对于产品经理而言,我们如果是自己在设计类似的产品时别忘了考虑这些点就行:



初步上手体验

从我的粗略体验来看,简单的问数还是很OK的:
这里因为我没有配置默认规则,所以“全国平均”取的是所有年份的平均值,因此我有重新指明了是2022年的平均值:
需要做一些简单加工的也是OK的:
不过,如果问法复杂一些,就很明显应对不来了:
而这也正是对基于大模型的chatBI类产品的较大挑战。简单的查询,如“今年的总销售额是多少?”,AI可以轻松处理,因为它直接映射到数据库中的一个或几个字段上。对于复杂问题,例如“哪些产品线因为营销活动而在上个季度销量增加?”则需要AI模型理解多个维度的关系,执行复杂的数据操作,并可能需要结合外部信息源。
对于复杂查询,在业界目前有不同的尝试,后续有机会再深入研习和分享。
预测也可能出现明显的不合理:
200%的GDP年环比增长率预测,不知从何而来。。。是谁给的大模型信心和勇气?
结合官方指南中的提问注意事项来看,这提醒了我们在智能问数在现实落地中可能遇到的问题和挑战,尤其是对于那些不太懂专业数据分析和SQL的业务人员而言,“问法”上的要求还是比较高的,例如:
  1. “各地区购买的产品排行”,按照产品名、销售额、销售量什么对象排名,目前语义补足不佳,系统会出现返回错误或空,所以建议明确指定:“各地区购买的产品,按销售额排行”
  2. “各地区销售额2023年增速为多少”、“各地区销售额2023年比2022年增长多少”,目前需要改写为“各地区销售额2023年年环比”、“2023年,各地区销售额年环比
  3. “各区域的销售额及占比”,需要改写为各区域销售额占比”、然后再切换图形为“柱图、表格等
  4. “各地区销售额近3年年环比为多少”、“各地区销售额2020年至2023年年环比为多少”,目前需要改写为近3年,各地区销售额年环比”、“2020年至2023年,各地区销售额年环比”。
  5. “浙江、江苏的哪个月卖得最好”、“浙江、江苏的哪个产品卖得最好”,目前需要改写为“浙江销售量最高的月份”、“各省份销量最高的月份”、“浙江销售额最大的产品”、“各省份销售额最大的产品”

03
智能搭建
智能搭建可以简单理解为在对话模式下,基于大模型快速第搭建BI可视化报表/看板的功能,能大大降低BI的学习成本、使用门槛。
依我之见,相比于“智能问数”的普适性,“智能搭建”会更偏向于数据分析师、高级业务管理人员等日常就会进行仪表板制作/专题数据分析&汇报的用户。

创建单一图表

智能小Q可以识别用户的自然语言输入,按需求自动创建图表。
① 选择要使用的数据集
用户可以在列表中选择,也可以直接输入数据集名称进行搜索:
② 描述数据分析需求
选择数据集后,小Q会自动学习数据集,并生成推荐问题。用户可以选择推荐问题进行数据探索,也可以直接输入自定义的分析诉求:
确定之后,小Q就会自动进行数据获取,并生成对应的图表:
图表标题将默认使用用户输入的分析需求,图表类型由模型自动确定。用户可以通过对话进行修改,例如:
  • “帮我修改图表类型为排行榜
  • “帮我把所有柱图切换为线图
  • “显示组件标题”
  • “帮我修改图表标题为客户来源渠道分析
  • “帮我把所有指标看板的标题都隐藏吧”

创建复合报表

相比单一报表,复合性的多图表看板创建更加简单,只需要选择好目标数据集,即可自动创建。
就这种自动化效果而言,还是蛮惊艳的:
如果对模型自动生成的报表内容不满意,可以点击“重新生成”,更换分析思路;或点击撤销,放弃该内容。
用也可以点击选择需要的快捷指令,填写补充信息,进行创建:

调整和分析数据

对于已经生成的报表,用户可以选中要编辑的图表,然后通过对话的方式向小Q发送指令,快速进行图表配置、增加分析元素
例如调整数据:
  • 修改图表字段:帮我把签单金额替换为销售金额
  • 修改字段展示名称:帮我把联系方式计数重命名为线索量
  • 修改字段聚合方式:帮我把商机线索量的计算方式改为去重计数
  • 修改字段排序:帮我将销量设置为按降序展示
  • 修改数据格式:帮我把所有图表的数据展示格式设置为两位小数
这本质上就是在将图表展示内容和格式的手动编辑变成了“口头编辑”
又例如辅助分析:
  • 条件格式:帮我给销售额字段增加条形展示,大于1000的绿色,小于1000的红色
  • 辅助线:帮我加一条均值辅助线吧
  • 趋势线:帮我加一条趋势线,查看未来三个月的变化
  • 联动:帮我打开图表的自动联动
以及查询控件的设置,例如:
  • 添加查询控件,查询各渠道的数据
  • 查询控件保持在报表最上方

美化报表样式

可视化报表的样式设置,就见仁见智啦。用户可以直接让小Q“帮我美化下报表”,既可以自动对整体报表进行快速的美化:
也可以选定特定的图表进行美化:
这些本质上就是将BI平台已有的功能,通过对话这种新的交互形式来实现操作的“自动化”。
例如:
  • 帮我把仪表板背景设置为浅蓝色
  • 帮我把仪表板字体设置为宋体
  • 帮我修改客户来源渠道分析这张图表的配色
  • 帮我把所有线图的数据标签隐藏
  • 帮我把所有柱图的柱宽调一点吧

智能洞察数据

智能小Q支持自动生成报表摘要、分析波动原因、进行异常点检测及归因。这是我心目中大模型能力在数据智能领域的更加“正经”且“普适”的用途:
报表摘要的自动生成,能够节省用户手动分析数据的时间,尤其是对于那些不熟悉复杂数据操作的用户来说,通过自然语言命令简化了分析过程;自动生成的报表摘要能快速提供关键信息,使得即使是非技术背景的用户也能轻松理解数据的主要变化点。
波动原因分析能够帮助业务人员进行更深层次的数据洞察,他们可以据此进行更有针对性的业务调整和决策。
自动检测异常点能够帮助用户揭示可能被忽视的数据模式,这些模式可能是业务问题或机会的指标。
虽然效果仍然有待进一步观察,但这类功能反映了AI大模型在帮助用户进行数据分析和洞察方面的巨大潜力。这不仅提高了数据处理的效率和质量,也为用户提供了更加便捷的数据分析工具。

04
总结与思考
QuickBI推出的智能小Q,是大语言模型(LLM)在商业智能(BI)领域的具体落地实践,展示了一些非常好的、值得为之努力的前景和探索:
  • 用户体验的革新:通过智能小Q这样的助手/工具,BI平台能够提供更加直观、互动的用户体验,使非技术用户也能轻松进行复杂的数据分析和报告生成
  • 分析效率的提升:自动化的数据波动检测和摘要生成大幅度提高了分析效率,节省了业务用户和数据分析师的时间
  • 决策支持的强化:为决策者提供更快速、更准确的数据洞察,从而增强了数据驱动决策的能力
  • 数据民主化:大模型的应用在BI中促进了数据民主化,使得更广泛的员工群体能够接触和利用数据
不过,如果真的要让这些场景的变化看起来正面、可靠,我个人的感觉是还有较大的差距。
因为面对AI助手“问数”结果,我们能相信它的输出吗?我们如何验证其准确性?面对不确定性,我们可以采取哪些措施来确保可靠性?这些都是业界在持续探索和检验中的难题。
我想可能这也是智能小Q至今仍然处于“测试”阶段的重要原因吧。从初步的体验而言,依然可以「理想很丰满,现实很骨感」来概括:
在此,我结合目前的认知,也“斗胆”指出智能小Q的一些值得重点改进的方向&思路(仅供参考,不喜请轻喷)
1. 实施“反思”机制——reflection
  • 模型自评:在LLM输出结果后,引入自我评估环节,模型应能评估自身的响应置信度,对不确定或风险较高的答案进行标注。
  • 结果修正:发展模型的自我修正机制,当模型识别到可能的错误时,应能主动调整逻辑或请求更多信息。
从模型本身的角度,也许也可以考虑通过持续训练,加入具有自我评估和修正的实例,使模型在类似情况下能够自我改进。
2. 多智能体协同——multi-Agents
  • 定义不同的角色划分:设计不同的智能体角色(如取数专家、可视化专家等),并在内置的prompt中明确它们的职责和工作流程,例如一个 Agent 可能负责收集数据,另一个 Agent 负责分析数据,再有一个 Agent 负责做出决策
  • 上下文感知:设计智能体间的沟通机制,能够根据上下文选择合适的智能体协作,优化问题的处理过程。
每个智能体都有自己的工作SOP,并能根据其他智能体提供的输入进行调整,从而优化整体工作效果。
例如,
当有用户询问“去年第二季度的销售收入比去年第一季度增加了多少”,智能小Q可以将问题拆解成以下任务,并调用相应的智能体来处理:
  • 查询历史数据 Agent负责获取过去特定时间范围内的销售数据。
在该问题中,它查询并获取去年第一季度和第二季度的销售收入数据。
  • 数据分析 Agent负责分析和比较不同时间段的数据变化。
在该问题中,它比较去年第一季度和第二季度的销售收入,计算增长率。
  • 可视化 Agent负责将分析结果转换为易于理解的图表或报告。
在该问题中,它创建一个展示销售增长的图表或仪表盘。
  • 交互优化 Agent:负责优化用户查询体验,根据用户的查询习惯提供个性化的可视化方案。
在该问题中,可以根据用户偏好自动选择图表类型和展示样式(因为不同的用户有切换图表类型的历史可以记录下来,系统可以作为大模型的输入识别其偏好——当然这只是我的假设)
  • 报告生成 Agent:负责生成详细的分析报告,包含关键数据点和洞察。
在该问题中,它根据数据分析结果,生成一份包含关键数据点和商业洞察的报告。
关于反思和多智能体协同的更多信息,推荐阅读我之前的2篇文章:
3. 用户反馈与运营管理后台
  • 用户反馈机制:构建易于使用的用户反馈系统,允许用户对每个查询结果进行评价,并提出改进建议。
  • 后台分析工具:开发运营管理后台,使数据产品经理和分析师可以跟踪用户的问答情况,并基于反馈调整数据集配置和知识库内容。
定期或基于触发机制更新知识库和数据集设置,以反映最新的数据洞察和用户交互模式,才可能提高用户在对话模式下的数据分析支持、报表生成等操作的响应率和正确率。
当然,也许这些功能已经在酝酿中甚至已经实现(只是我从介绍和体验中未能了解到)。
就先到这吧~我还要筹备会议。


以上,就是关于AI大语言模型在BI领域的应用的第2期分享。
本期到此结束。
再见


PS:最后,我已成功召集了一场将于本周四(2024年4月25日)晚8点进行的AI+BI的线上圆桌会——这要感谢相关嘉宾朋友们的鼎力支持。对这个领域有兴趣参会学习和讨论的可以报个名(2024年4月24日18:00截止,仅剩1天,名额有限)
如果你觉得我的分享还不错或者对你有帮助,不妨来个一键N连:点赞+在看+分享+关注。
也欢迎你在留言区与我互动。

参考资料:
  • https://www.aliyun.com/page-source/common/yunqihao/quickbi_gartnerabi_2021
  • https://help.aliyun.com/zh/quick-bi
  • https://mp.weixin.qq.com/s/3nsAuDoJgscL7l0Ahf5GvQ
  • https://echarts.apache.org
  • https://m.huxiu.com/article/2169231.html
  • https://c2.yonyoucloud.com/iuap-hc-client/ucf-wh/client/index.html

推荐新闻
RAG系列04:使用ReRank进行重排序
本文介绍了重排序的原理和两种主流的重排序方法:基于重排模型和基于 LLM。文章指出,重排序是对检索到的上下文进行再次筛选的过程,类似于排序过程中的粗排和精排。在检索增强生成中,精排的术语就叫重排序。文章还介绍了使用 Cohere 提供的在线模型、bge-reranker-base 和 bge-reranker-large 等开源模型以及 LLM 实现重排序的方法。最后,文章得出结论:使用重排模型的方法轻量级、开销较小;而使用 LLM 的方法在多个基准测试上表现良好,但成本较高,且只有在使用 ChatGPT 和 GPT-4 时表现良好,如使用其他开源模型,如 FLAN-T5 和 Vicuna-13B 时,其性能就不那么理想。因此,在实际项目中,需要做出特定的权衡。
LangGPT论文:面向大语言模型的自然语言编程框架(中文版)
大语言模型 (Large Language Models, LLMs) 在不同领域都表现出了优异的性能。然而,对于非AI专家来说,制定高质量的提示来引导 LLMs 是目前AI应用领域的一项重要挑战。
第三篇:要真正入门AI,OpenAI的官方Prompt工程指南肯定还不够,您必须了解的强大方法论和框架!!!
自从ChatGPT(全名:Chat Generative Pre-trained Transformer)于2022年11月30日发布以来,一个新兴的行业突然兴起,那就是提示工程(Prompt engineering),可谓如日冲天。从简单的文章扩写,到RAG,ChatGPT展现了前所未有的惊人能力。
(三)12个RAG痛点及其解决方案
痛点9:结构化数据QA 痛点10:从复杂 PDF 中提取数据 痛点11:后备模型 痛点12:LLM安全
(二)12个RAG痛点及其解决方案
痛点5:格式错误 痛点6:不正确的特异性 痛点7:不完整 痛点8:数据摄取可扩展性

联系我们

售前咨询
186 6662 7370
产品演示
185 8882 0121

微信扫码

与创始人交个朋友

回到顶部

 
扫码咨询