服务器 频道

阿里巴巴技术实践:BI+AI技术的融合与应用

  在商业智能走向成熟的今天,大模型技术的融入正在引发技术革新,为企业决策赋能。近日,阿里云智能集团瓴羊高级技术专家王璟尧,分享了BI与AI技术融合及其实践:BI+AI技术爆炸下的发展趋势、BI领域大模型在Quick BI的应用实践,以及面向AI的技术架构设计和实现。

  一、BI+AI技术爆炸下的发展趋势

  1、BI 市场演进趋势

  商业智能(BI)技术的演进从传统BI到敏捷BI,再迈入当前的智能化BI时期,历经多重转变。Quick BI作为中国领先的BI产品,已连续四年跻身Gartner魔力象限,显著地代表了这一趋势。敏捷BI时代要求用户通过直观的交互如点击和拖拽进行操作,而智能BI旨在进一步简化操作,通过引入类似智能助手的工具,以降低操作难度,提升用户体验。  

(BI分析市场演进趋势)

  智能BI的发展正在被自然语言查询(NLQ)、自然语言生成(NLG)、生成式分析和可解释的人工智能等技术所驱动,预计在接下来的2-5年中,这些技术将成熟并加速智能BI的发展。特别是大模型技术在理解、归纳和生成自然语言方面的进展为BI引入了革新性的生成式分析体验。正如Gartner所预测,到2025年,由于消费者体验的改进,ABI的市场采用率有望首次突破50%,从而在更广泛的业务流程和决策中起到决定性影响。

  2、大模型发展现状

  过去一年多,大模型技术广受业界关注,并展现了显著的三大特点:更高的可控性、更广的应用场景以及模型数量和质量的迅猛增长。

  如ChatGPT之类,不仅改变了人们与机器的交互方式,还通过向量化数据、代码和语言,重新定义了产品的使用和计算形态,使用户能够采用自然语言或代码与产品进行交互,减少对传统鼠标操作的依赖。这些大模型的使用目的超越了简单的文本生成,关键在于利用这些模型推动BI基础设施的根本重构。

  然而,大模型技术也不是无所不能,它们具有一定的局限性,比如未经训练的大模型缺乏适应性,无法深层次理解业务逻辑变化,更不用说代替人类在业务理解和风险控制方面的复杂作用。

  此外,大模型难免存在着一定的幻觉和恶意行为诱导风险。因此,当将大模型应用于BI领域时,特别需要关注模型在行业知识和产品知识方面的训练,确保模型能够基于特定客户的行业场景语料数据加强对行业的理解,并与BI产品深度融合,如在报表配置、操作控件的选择、数据的选择等方面。

  3、BI 领域产品形态探索

  在商业智能(BI)领域的新时代,Quick BI积极开展对大模型技术的探索和 应用,推出了创新性的产品——智能小Q。它能够通过理解用户通过文字形式提交的分析需求,在掌握用户上下文的基础上自动识别意图、分解任务并逐一执行。

  智能小Q的开发利用了成熟的大模型技术,结合Quick BI对于BI业务的深刻理解,完成了针对BI场景的大模型训练,并将其与强大的产品功能相结合,实现了BI与AI技术的有效融合。此外,智能小Q通过支持多轮问答和融入用户反馈及企业知识库的方式,不断增强其智能化程度。  

(BI领域产品形态探索)

  在产品和技术设计上,Quick BI的创新体现在两个主要方向。首先,面向AI的产品链路方面注重于提供自由灵活的搭建方式、基于自然语言的数据洞察探索和卡片式的消费体验。

  其次,在面向AI的技术架构设计中,重点放在了开发以Agent为中心和全面采用指令化架构的技术体系上,这些设计不仅优化了产品的操作体验,也极大地提高了业务流程的效率和智能化水平。通过这样的探索和实践,Quick BI展现了BI与AI结合的广阔前景和深远影响。

  二、BI 领域大模型在Quick BI的应用实践

  从应用角度去看,Quick BI大模型应用分为三层。  

(Quick BI大模型应用分层)

  第一层是领域模型层,相当于树根。我们基于通义千问的基础模型,经过BI专业知识微调,形成了自研的BI领域大模型。BI领域大模型实际上是在通用大模型的基础上进行训练的,从头开始训练并生成基础大模型不仅需要消耗大量GPU算力资源,还需要大量通用数据,这对BI应用场景来说是不必要的,因此,Quick BI选择基于通用千问的版本进行训练,而不是从头开始。在这个过程中,我们进行了哪些训练,增强了哪些能力,将在模型架构层进行介绍。

  第二层是Agent任务层,相当于树叶的大枝干。智能小Q作为用户和BI系统的交互入口,用于理解和处理用户意图,然后分发到具体的垂直智能任务中。最常见的场景是搭建编辑报表,包括问答、闲聊和推荐。例如,用户询问2023年浙江省的签单金额情况,系统可以识别出这是查询类任务;如果用户要求将图表类型改为线图,那么这就是报表搭建类问题。

  最里层是垂直任务层,相当于树叶的枝条,是应用层面的原子Agent任务。这些原子任务已经涵盖了之前QBI已经具备的能力,如传统的机器学习能力、洞察归因、异常检测、智能搜索,以及为适配大模型而新接入的一些任务,如生成图表、生成报表、配置修改和样式美化。

  下面将简要介绍其中的四项:

  1、辅助搭建

  在创新的报表搭建实践中,Quick BI已经从传统的鼠标拖拽操作模式转型为便捷的自然语言指令输入模式。用户现在能够简单地通过文字输入向系统下达创建图表、编辑标题、甚至添加条件格式的指令。这一进步的驱动力来自于三大核心技术突破:精确定义的指令集,面向AI的指令化架构升级,以及灵活高效的agent编排。

  指令集的定义为模型提供了与BI系统交互的明确语法规则,指令化架构的改造让开发者得以实现深层次的集成,确保BI工程系统准确解读模型的输出。而agent的编排则保障了算子的有序执行,这些算子是构建大模型应用时的基石,涵盖角色设定、prompt改写、指令解析等任务。完成这些任务后,系统不仅能够确定执行流程,还能够基于用户互动提供智能化的问题推荐。这样的技术融合使得BI报表搭建变得更加智能化、直观和用户友好。

  2、一键美化

  “一键美化”功能致力于将报表的视觉呈现提升至全新水准,为用户带来既简易又高效的视觉设计体验。通过对仪表板进行巧妙的层次设计,分为负责色彩搭配的图表层和处理背景及装饰元素的氛围层,使得每份报表都能在视觉上脱颖而出。

  该技术能力主要包括四部分:

  首先,智能配色系统能从选定图片中抽取主色调,并运用先进的色彩聚类与匹配技术以及可视化算法,为用户量身定制多样化的色彩方案,既提速了配色流程,又确保了视觉的吸引力;

  其次,立足于用户体验专家长年累月的实战经验,Quick BI总结了一系列图表配置的优秀实践,帮助用户像搭配衣服一样自由组合各种图形配置;

  第三,应用LCH色彩模型而非传统HSV模型,做到在色彩转换时更精准地保持亮度和对比度,以实现整体配色的和谐与高质感;

  最后,Quick BI精准解读字段数据的语义含义,从而智能匹配到最合适的图标修饰,确保每个细节都凸显智能化技术的精巧与细腻。  

(一键美化技术实现)

  3、智能问数

  第三项创新功能,智能问数,本质上体现了NL(自然语言)到SQL(结构化查询语言)的技术转换。这一功能赋予系统以自然口语的方式提出问题的能力,激发了在数据可视化、高级运算和灵活数据挖掘方面的潜力。

  该过程紧凑且高效,包括四个步骤:

  首先是精准的意图识别,配合细致的安全过滤;

  紧接着根据元数据及部分数据特征对数据实体进行提取和召回;

  之后是知识库信息召回和模型prompt改写,进而生成领域特定语言(Domain-Specific Language, DSL);

  最后实现BI系统对DSL的逻辑处理及数据源SQL方言的精准转译和图表的动态渲染,以此完整地实现从用户查询到数据可视化的流畅转换。

  4、数据洞察

  在探寻进一步的数据分析时,Quick BI结合了传统统计算法和大模型来完成任务。数据洞察的真实力量在于其深度解读图表和补全信息的能力,从而揭示数据背后的故事,并最终形成有力的数据驱动结论以指导实践中的决策过程。它是一种基于历史数据、行业内洞见和一系列相关数据集为参考,专注于识别和解析那些最具显著性、对业务目标波动最具解释力或提供深刻洞见的关键数据变动。

  三、面向AI的技术架构设计和实现

  1、面向AI的架构设计

  系统架构设计的核心在于将用户的自然语言指令转化为机器可执行的代码和技术逻辑,最终显现为直观的前端产品体验。随着大模型的突破性增长,自然语言的指令能够无缝转化为代码,进而与底层技术逻辑相连通。这整个流程的关键在于AI中间层的加入,它引入了一套标准化的结构化语言—领域特定语言(DSL)。这项创新确保了在BI领域中模型应用编程的精确性和效率。

  系统基于Quick BI已有的产品能力开发,具有许多优势,我们屏蔽了底层数据源的SQL方言,使得模型不需要关心三十多种语言的SQL类型;同时,它本身对接的是BI已有的能力,可以快速响应用户的提问,支持高级分析和BI本身的意图表达,比如年同比、环比,分组排序等;此外,还对接了强大的数据可视化能力,能够展示各种图表类型。

  在工程架构上,进行了面向AI的指令化架构升级,包括会话层、指令系统、算子拆解、API层、渲染引擎和服务层。这里复用了BI系统内成熟的基座,在能力层面将大模型的意图理解与BI系统底层的渲染引擎、分析引擎进行编排和处理。

  在开放层面,我们将系统内部的执行指令、流程控制、消息模型、取数逻辑等关键步骤拆解成原子API,供各个引擎组合式调用。QBI定义的这套架构标准不仅满足系统内部需求,未来在合适的时机也具备开放出去的能力、被更多AI、甚至是外部系统调用。  

(面向AI的架构设计)

  2、BI领域大模型架构

  在探讨BI领域大模型架构的过程中,我们不断强调大模型的重要性。这里产生了一个疑问:

  为何我们必须开发BI领域的大模型?当前的通用大模型,例如GPT或通义千问等,真的无法掌握所有零散的知识吗?

  对此,我的回答是肯定的。系统运转并非完全取决于模型本身,其效果的好坏是有一定边界和合理性的限制。通用模型无法全面了解Quick BI内部系统的实现逻辑,即便它们对某些通用能力有一定了解,一旦系统更新至新版本,它们仍然无法掌握新的逻辑变化。

  此外,通用模型也无法了解数据流转的具体方式,更不会掌握客户所在行业特有的知识。例如,对于“财年”这一概念,不同公司或行业有着不同的定义。这些特定的知识是大型通用模型所不了解的。

  因此,为了使我们的模型能够快速适应复杂的BI系统,并确保更优效果,引入领域模型层是必要的。在针对特定场景执行任务时,我们并不需要模型具备过多的泛化推理能力,而只需它以最低成本确定性地完成某一类特定任务。这时,AI Agent的架构应运而生。

  这里可以将此比喻为生产线上的工人,他们不需要深究公司的战略蓝图,而只需专注高效完成分配给他们的具体任务;这里的AI命令就类似于指派任务的监工。在实践应用中,我们已经在内部实现了高效且稳定的大模型推理服务系列,并通过不断的优化和自动化微调框架的构建,极大提升了数据训练的效率。这种快速迭代的模式让我们的产品保持领先,搭建意图识别准确率已达到90%左右,而在调优之后,推理吞吐较调优前提高了至少200%,显著增强了系统的整体性能。

  3、架构分层和部署能力

  物理部署架构主要分为两部分:智能服务 和 BI基础服务。

  这两个服务均支持作为SaaS(软件即服务)提供,同时还可以在阿里云的VPC(虚拟私有云)进行独立部署,或在本地环境单独部署。借助这种灵活的架构,用户可以享受到算法训练的便捷性,这部分工作完全由我们内部管理,用户可以实现即开即用的产品体验。此外,部署成本相对较低,在线推理的任务可以运行在A10显卡上,而基础的BI服务只需使用常规的ECS(弹性计算服务)即可。

  在调用链路过程中,系统首先会对用户的问题进行内容安全审查和过滤(该服务目前仅限于公共云环境,若为独立部署则需要用户自行管理)。在大模型完成意图识别、问题拆解和关键信息召回等几个关键步骤后,通过规划路由到不同的Agent任务。以问数为例,路由至NL2DSL链路后,系统会对维度值、知识库、元数据等数据召回,通过子agent生成DSL后解析成对应数据逻辑和渲染配置。

  上面最重要的步骤是将用户的语言通过BI领域模型,转化成Quick BI分析服务可以理解的逻辑语言,并由分析引擎翻译成对应的SQL方言和内置高级计算的算子执行,结果返回后将通过多种图表类型和丰富的配置展示,与使用BI工具的传统拖拽操作无异。

  内置的向量存储系统会作为意图理解的重要辅助会缓存必要关键信息,包括知识库设置、报表配置信息、数据集元数据、关键维度枚举值抽样及操作上下文信息等。举个例子来说明使用上下文信息的场景:例如在修改报表时,若用户意图将“销售金额”字段修改为“全年销售金额”,系统会先在用户正在操作的图表内寻找对应的字段进行修改。若定位不明,范围可能扩大至整个画布。存储用户上下文信息有助于在整个指令解析过程中提高准确度,尤其是当某字段含有枚举值时。如果大模型对这些枚举值不熟悉,那么在处理相关查询时,准确率将受到影响,例如用户询问“圆珠笔的销量”,如果模型不清楚“圆珠笔”属于“产品”字段中的一个枚举值,则会对结果准确性产生负面影响。

  写在最后

  引入AI和大模型技术到BI领域并非盲目跟风,而是经过深思熟虑的策略。目前,瓴羊Quick BI成功将自然语言处理融入数据分析的全过程,提高了数据处理的智能化水平,使企业能够以更低的成本和更高的效率获得有价值的洞察,从而作出更加精准的业务决策。当我们继续在这条智能化的道路上前进时,期待未来能够解锁更多的可能性,为用户带来更多创新的解决方案和服务,最终实现数据的最大价值转化。

0
相关文章