导读 本文将分享数势科技在数据分析这一智能化赛道中的一些思考与实践。
1. 引言：大模型技术对于数据分析领域能够解决哪些痛点
2. 解决方案：智能分析产品常见设计思路以及优化路径
3. 技术架构：Agent架构结合数据语义层 （Semantic Layer）如何实现产品落地
4. 应用场景：某零售连锁行业智能分析助手落地案例
5. 产品设计理念与挑战：LUI+GUI 融合的产品设计理念与挑战
6. 未来展望：智能数据分析产品演进展望
7. 问答环节
分享嘉宾｜岑润哲 数势科技 数据智能产品总经理
编辑整理｜小宁
内容校对｜李瑶
出品社区｜DataFun
引言：大模型技术对于数据分析领域能够解决哪些痛点
第一部分，将剖析金融、制造、零售等行业客户所面临的痛点，以及大模型技术能为数据分析领域解决哪些问题。
首先，从管理团队视角来看，很多企业耗费大量精力建设了很多数据仓库、数据湖，包括一些大屏、驾驶舱，这些工具确实在一定程度上解决了领导层面看数据的问题，但是很多数据产品是固化形式的看板，对于决策层而言，data 并不代表 insight，当需要对某些细分的业绩指标做洞察分析时，还是要给分析团队提需求，这个时候就需要漫长的等待。
同时，领导层通常更关注 why 的问题，比如为什么公司业绩出现了下滑，为什么某一个门店的销量不好等等。而可视化、驾驶舱等工具只能给出 what 的解答，并没有触及到数据背后关键的 why。所以这个时候很多领导希望能够直接对着大屏，通过自然语言提问，比如为什么指标下降，由系统给出一个结论，这是很多领导层希望通过大模型加数据得到的。
第二，从业务人员视角来看，主要痛点是没有一个好的工具，他们只能自己去学习 SQL 语言，或学习使用一些复杂的 BI 工具，来做数据的可视化和分析。拿到数据之后，他们还要从大量的数据里面去挖掘一些洞见，需要手动导出 Excel，做透视表来获取结论。很多团队希望通过自然语言交互的形式，更快地从海量数据中直接获取到一些 insight，来辅助日常决策。
另一个重要团队是技术团队，包括数据开发，数仓工程师等。面临的痛点是，数据仓库虽然已经搭好了，但是业务方总有很多临时性需求，这就会导致数据仓库集市层建立了大量临时 ADS 表，维护了一些临时性的口径，使得数据分散、指标口径不一致。
针对上述痛点，我们希望利用大模型 Agent 架构去改变原有范式。
如上图所示，原有模式为业务方提需求，技术团队采买 BI 工具供业务方使用，但是工具太复杂，业务方不会用。数据分析师虽然会用 BI 工具，但相比需求数量，人员严重不足。
因此，我们提出了 Agent 架构加语义层的新范式，旨在降低业务团队的看数门槛，让大模型参与到整个环节中。
解决方案：智能分析产品常见设计思路以及优化路径
我们提出的关键概念之一，是在数据和业务之间添加语义层，作为连接业务语言和技术语言的桥梁。
如上图所示，构建数据语义层包括 7 个核心要素，首先把数据集成进来，然后构建语义模型，通过数据虚拟化、OLAP 计算等方式，供大模型去消费。
很多企业目前在尝试的是称为仓内语义层的一套范式。在这一范式下，会将整个数据语义口径层构建在数据仓库内部，包括指标对应的是哪些表的哪个字段，加工逻辑等。
- 数据语义层都是由数据工程师在数仓构建加工，业务方很难去修改这些 ETL 作业，而看数分析口径确实有可能发生变化，所以这种方式对业务方不够友好。
- 虽然数仓内部数据语义层做了统一，然而一旦把数据集市的结果表同步给了终端，比如 BI 工具、大屏、Data Agent，数据团队很难在终端维护指标口径。因为不同数据应用的负责人不一样，他们可能自己修改口径，就会导致两边看到的数据、指标不一致。数据本身的指标口径都不一致，想让大模型理解就更难了。
基于仓内语义这套机制，很多团队也在尝试直接把数据中台内部的指标语义交给大模型，直接去生成 SQL。这种方式仍存在问题：
- 首先，即使用现在最强的 GPT-o1，也会存在一些准确性的问题。
- 第二，大模型生成的 SQL，可能没有经过优化，没有一个很好的 OLAP 引擎优化机制，这会导致查数非常慢，作为自然语言交互工具，这种等待会造成用户体验很差。
- 第三，大模型缺少直接对数据查询、数据权限的管控，这会导致不同用户问同样一个问题时，大模型不知道以什么样的口径、什么样的权限输出给客户，因此存在数据安全的问题。
在维护原有的数据仓库、数据中台表不变的情况下，增加一个称为建模右移的指标语义层，其本质就是前文中提到的 7 要素。可以直接让业务团队、产品经理把指标、维度的一些核心要素做拼接，比如一个指标叫借款人数，它是原子指标，是一个最小颗粒度的指标，基于这个指标，会有一些分析维度，如机构、产品、时间要素等。这些指标、分析维度原子化之后，就对大模型比较友好了。
举个例子，这时候业务方提问大模型：帮我看一下最近 30 天的借款人数的增速如何？大模型首先会把这段中文的自然语义解析为：这句话里包含哪些原子指标，哪些要素，哪些时间，哪些高级算子。这层转化逻辑，是通过大模型本身的意图理解，对于自然语言的识别而实现的。
当大模型把这段自然语义解析为这些要素之后，就可以通过指标语义层的程序把这些指标、维度、时间要素解析为对应的 SQL，用于 OLAP 引擎查询。这个例子中，大模型做的不是 SQL 生成，而是只做用户语义的识别，对 SQL 片段进行拼接，这样能够避免大模型直接生成 SQL 产生的幻觉。
同时，这个过程是以低代码的方式去构建的，业务方也可以参与到数据编织、指标口径的调整优化中。这是仓外语义相比仓内语义的最大优势。
这样一来，指标语义层的产品定位，就变成由数据人员和业务人员共建的模式。这时候数据团队、数据管理员可以更多地聚焦于如何把数据仓库建好，而上层更加灵活的指标、口径定义和拼接可以由业务团队来设计。最终交给大模型理解的，其实是由业务团队设计好的指标语义、维度语义，避免了大模型幻觉的问题。
在这套范式下，整个流程变为，用户用自然语言提出一个分析需求，通过大语言模型进行意图识别，把需求理解为对应的指标、维度，这个意图识别的过程叫 Natural Language to Semantics to API。这些非结构化的自然语言，大模型只要解析到半结构化的 JSON，解析出自然语言里的指标、维度、时间、高级算子就可以，不需要穿透到每一个具体的 SQL 片段。然后由指标语义层，通过数据虚拟化技术生成 SQL 片段后，再由 OLAP 引擎做查询，并把结果同步给用户。通过这种方式，结合了数据语言跟业务语言，让大模型发挥更擅长的思考、意图识别和解析的能力，而让数据语义层发挥标准化的查询能力。
同时数据的安全性也有了保障。比如北京、上海、深圳三地的业务人员都要求：看一下近 7 天的销售额，虽然三个人的自然语言是一样的，但是可以通过识别每个人的角色、对应的权限级别划分等，保证不同人问同一个问题时，拿到的数据是不一样的。这是 NL2SQL 很难实现的。这种基于指标语义、基于 API 的方式，能够更精细化地考虑到指标的行列权限，并通过 Agent 架构覆盖到更多的场景。
上图展示了某客户实测 NL2SQL 和我们的 NL2Semantics 的效果对比。
当查询请求是比较简单的单表查询时，NL2SQL 可以通过直接读表实现。但是当难度上升到 3 星以上时，如果没有刚才提到的 Semantic Layer，没有一个多任务规划机制，直接 NL2SQL 就会有不准确的问题。以第四个问题为例，业务方既要看这个品牌在最近三个月销量 TOP3 的商品是哪些，又要看这三个商品的好评率，同时还要做一个数据报告。这其实需要多个任务的衔接，不仅仅是数据分析，还要做排序、解读，甚至归因。所以这时候，直接采用直接生成 SQL 的模式，很难满足业务方的特定需求。
通过我们引入的 Agent 架构，先把一个复杂请求做拆解，拆解成一个个原子能力，然后再结合指标语义层做解析。最终大模型看到的所有指令，都会映射到上图底部的这些不同颜色的要素，比如时间维度、地域维度、公司维度等。还是以第四个问题为例，对于大模型而言，只需要把这句话里的最近三个月识别为时间，商品识别为产品维度，好评率识别为指标，把这些映射关系 mapping 出来就够了。这些指标维度对应的 SQL 片段的逻辑，是在数据语义层 Semantic Layer 去维护的。
所以这种 Agent 架构加上 Semantic Layer 的方式，能够更好地满足用户在一些特定复杂场景下的查询请求。
技术架构：Agent 架构结合数据语义层（Semantic Layer）如何实现产品落地
为了把 Data Agent 做好，除了语义层，还有一个很重要的技术点就是 Agent 架构。接下来将介绍如何将 Agent 架构与语义层相结合，来实现产品落地。
上图是某金融机构的一个例子，业务方的问题是：看一下最近 7 天基金申购人数，哪个渠道跌得最多，再帮我做个总结。
我们如果是从 Agent 的角度思考，在底层上会分为四个环节来完成这个任务，即专家雇佣、协同决策、动作执行和结果评估。
专家雇佣机制可以理解为，有一个小组，小组中每个角色都有自己擅长的能力，比如有些专门做数据提取，有些专门做可视化，有些专门做异常归因或写报告，这些都是独立的 Agent。我们希望针对任务，把这些 Multi Agent 做grouping。针对上述用户问题，需要三个专家一起参与：先取到数据，然后做数据的异常归因，最后基于结果写报告。这三位专家，或者说这三个 API 作为一个小组，一起协作把问题解决。
在协同决策流程中，大模型会生成一个调度任务。这个任务的编排，类似于现在很多 Agent builder 里面的流程图，把每一步的逻辑同步或是异步地自动化编排出来。这时候，大模型扮演了一个规划者或者协调者的角色。它会把这三个专家按照执行的顺序做串联，最终再由每一个 Agent 执行，拿到对应的结果或者报告给用户。大模型的 Agent 架构，其实像一个交响乐团的指挥，指挥并不一定会所有乐器，但是他能够去协调每一个声部、每一个乐器如何配合。这个时候其实就是一个大小模型协同的机制，大模型扮演的是一个思考者、协调者，把这些原子能力做编排，并且最终把用户的任务集成解决。这就是我们希望能够结合指标语义层和 Agent 实现的能力。
语义层需要确保取的数是准确的；而 Agent 架构则确保数据分析子任务能够被有机地编排起来，并且形成一个能让业务方看懂的结论或者报告。这就是我们的指标语义层与 Agent 的协作关系。
Agent 架构能够在一些复杂场景帮助用户完成一些高阶的回答。从图中可以看到，当一个用户提问时，首先让大模型做一个感知，如果问的问题不是数据分析类，把这些任务路由到其他 Agent，比如知识库或文生图的 Agent 等等。
当发现这个意图确实是数据分析的时候，会通过一个 planning 规划的机制，对任务进行拆解，并反思设计的这一套 planning 的流程是否合理；同时还要考虑上下文，比如用户之前是不是问过类似的问题，是不是可以做一些动态 few-shot，实现更快的召回，用户上文提到的内容是不是对下文有帮助，会做一些记忆的获取。
在用户把复杂问题交给大模型，大模型做了合适的 planning 之后，下一步通过工具调用实现具体任务，比如取数，取到数据之后做归因分析，然后生成详细的报告。
这就是一个从大模型理解用户意图，再到编排，获取记忆，再去做实际的 function 执行的全流程。
第一步，数据语义层，要能够在获取数据时保证数据是准确的，这是最重要的。第二步，对复杂任务，通过 Agent 机制，将原子能力以合适的顺序、合适的时间点做编排，并且最后做回传。这里的工具调用，可能是同步的，也有可能是异步的，比如取数、图像生成比较快，就是一些同步的任务；当做一些数据解读，或者产出分析报告的时候，可能大模型用的时间很长，就变为一个异步的任务。
这就是一个由 Agent 架构出发，结合指标语义层的数据智能分析助手的实现逻辑。
应用场景：某零售连锁行业智能分析助手落地案例
接下来将分享一个零售连锁行业客户落地智能分析助手的案例，展示如何通过语义层加 Agent 架构来解决企业内部日常看数、用数的问题。
这个客户是一个加盟连锁形态的零售商，希望赋能的群体是一些领导和线下门店经理。原来所有的看数、取数、指标分析全依靠于总部专业的 BI 分析师去做，提需求的有上千人，而数据分析师只有十几人，这就会遇到效率问题。
我们帮助其在已有数据中台之上构建了 Semantic Layer，先让大模型明白公司内部有哪些指标和维度。这层叫统一的数据语言，财务指标、门店指标、商品指标、供应链、外卖、毛利指标等所有指标的数据编织要先管理好，不仅人能看懂，大模型也明白该怎么取数。
这里对其原有数据仓库、数据湖建设没有任何侵入，而是在仓外构建了一个专门的数据语义层，去做数据的集成、数据的加速。这里最关键的就是 Semantic Layer 的环节，它是数据语言和业务语言之间的桥梁，使大模型能够理解用户所说的业务名词、黑话。在此之上，通过 Agent 架构、规划器的机制去串联不同的场景，比如查门店的业绩表现，看门店的客群画像，或者对一些财务指标做洞察。我们会先让大模型对用户的自然语言做一个意图识别，这里也适配了很多国产大模型，比如百川、智谱、千问等等。第一步大模型意图识别和 planning，第二步把对应的指标标签、客群或者对应的维度通过加速引擎查询出来。
其中最关键的就是语义层。上图是一个示意。当时有几百个指标，之前都是在每一个专业分析师的脑子里，分析师离职后，就再也不知道口径怎么取了。当我们把指标语义、指标血缘存起来后，想知道某个指标，就可以路由到对应的指标的结构或语义。
在构建智能分析助手之前，每个门店经理在做月度复盘、技术复盘时都是依靠专业分析师在 BI 或 Excel 里面做分析，成本、门槛很高。落地我们的一套系统之后，实现了让门店经理、不太懂数据的人可以直接通过自然语言的输入，去做一些指标洞察跟分析。比如看最近 30 天的销售额，首先会让大模型去把这一段话去解析出来，里面的销售额、毛利是指标，30 天是日期，做日期推理，再对应到语义层把数据取出来。取到之后，还可以通过快速地点选，让大模型生成一些可视化的图表。当发现指标异常时，可以让大模型去调度一些归因小模型，来做一些维度或者因子分析，实现快速洞察。针对维度特别多的问题，我们会通过一个维度归因的算法，快速定位到因子维度。
原来一个门店经理可能要花 4 个小时才能够知道，这一天毛利为什么跌了，是什么商品跌了，谁负责的门店跌了。现在通过自然语言交互即可直接生成结论。
一方面指标语义层告诉大模型指标体系怎么构建，另一方面通过 AIGC 技术，可以更加快速地把数据结论以报告或者文本的形式呈现出来，业务方不用自己去做 ETL 作业的编排。语义层也对一些黑话做了配置和映射。
这其中很重要的一个基础就是构建指标体系，明确指标血缘关系后，才能够做归因分析。
智能分析助手在准确性、人效、用户满意度等方面都带来了显著提升，同时通过强化学习机制，从点赞点踩中让大模型更好地了解用户应用的逻辑。
产品设计理念与挑战：LUI+GUI 融合的产品设计理念与挑战
接下来分享我们的产品设计理念，以及在设计 Data Agent 过程中遇到的一些挑战。
对于 B 端应用，大模型参数等配置非常复杂。我们建议，产品形式不要像C 端一样只是一个对话框，而是采用 GUI 跟 LUI 结合的形式。LUI 的好处在于门槛低，GUI 的好处是一些参数、按钮、追问以图形化的形式呈现。
常见挑战 1：当用户提问模糊的时候，怎么提升交互体验
一个常见的挑战是，用户很多时候不明白自己的请求是否清晰。举个例子，一个用户作为门店经理，他的问题是：帮我看一下最近按照渠道的订单量，并对比一下去年同期。这个时候大模型不知道最近是 7 天还是 30 天，口径也不明确，也不知道需要怎样的对比。当用户的请求模糊时，我们希望大模型能够自己去思考，做一些反问提示。
比如，用户提问：最近的资产情况。大模型应该思考这个指标常用的时间维度是什么，给用户做一个推荐。又如，用户想要查看利润，那么用到的指标到底是前台毛利还是综合毛利，还是商品毛利？大模型应结合指标语义层进行反思，然后反问用户。这样才能够解决用户语意不清楚情况下的查询准确率问题。
第二点就是前文提到的，用户在表述自然语言时可能很相似。比如用户运营部门、活动运营部门、经营分析或者财务部门，他们在表述需求时提出“看一下昨天某个门店的数据表现”。但实际上，每个人对于“数据表现”这四个字的理解是完全不一样的。运营人员可能想要看的是首单、复购、召回；经营分析部门则可能指的是营收、成本、利润、损耗。而大模型并不知道提问者是谁，因此需要把角色考虑进去，让大模型先知道你是谁，你对“数据表现”这四个字的理解是什么。
我们通过在后台，对企业专有名词（黑话）进行配置，并且把场景、角色考虑进去，去解决这个问题。这里会有一个冷启动的机制，我们需要去教大模型，用户是谁，用户关注的是什么，这样才能够让大模型逐渐理解到“黑话”到底映射的是什么样的指标。
应用场景 3：用户不仅需要提取数据，更需要分析思路
还有一个比较大的挑战是，对于业务方而言，数据的获取只是一个过程，不是结果，业务方要的不是数据，而是结论，是动作，是建议，所以不能只把数据表给用户。
在数据的基础上，需要帮助用户做一些快速的归因解读。通过持续反思，让大模型形成追问机制，能够更加快速地帮用户解决特定场景的问题。
未来展望：智能数据分析产品演进展望
最后总结一下对数据智能分析产品未来演进方向的展望。
在 GPT-o1 推出之后，我们发现它的基础能力变得更加强大，已具备了在某些特定垂直领域的专业能力。而我们现在大部分的工具，不管是 Data Agent 还是其他 Agent，还是以 listening 的方式为主，还是以 chat box 的形式，回答用户问题。更好的模式应该是大模型在理解了用户分析历史，理解用户角色之后，来帮用户提问。比如一个面向财务人员，大模型每天帮他自动跑他关心的几个指标，生成报告。把分析的范式，从 listen 变成 speak，这样才更加符合数字员工的真实体验。大模型作为一个员工，能够主动思考，主动帮你想问题，主动帮你去分担一些任务。
同时，当有了一些 data 的结论之后，更好的一个形式是这个系统能够串联这些决策，能够从 conclusion 到 decision。比如发现某个指标不好，建议动作是哪些。这样才能够连接企业内部更多的决策体系，充分发挥数据的价值。
从 listen 到 speak，从 basic planning 到 expert strategy，从 conclusion 到 decision，这三个层次的演进是我对未来 Data Agent 的期望，这种形式才更加符合 Data Agent 作为主动化、智能化的数字员工的定位。
粤ICP备17114055号
支持私有云部署
