导语：大模型爆火之后，很多企业也用大模型做了相关探索和实践，我们发现大模型解决单点问题时效果更好。但同时会产生安全、幻想等相关问题。今天从传统数据分析的痛点，到大模型智能分析的建设方式，并结合相关实践案例，分析AI Agent在智能分析领域的价值与实践。
分享嘉宾｜李飞（博士），数势科技AI负责人
内容已做精简，如需获取专家完整版视频实录和课件，请评论区或私信联系我们，为您发送完整内容。
01 传统数据分析的三大痛点
那么，在与Agent能力结合前，传统的数据分析方式存在哪些问题？首先是管理团队之痛，现有的数据产品无法端到端快速产出深度结论。
在团队管理中，大多企业都有经营驾驶舱，由BI或经营分析团队运维使用。但事实上，当管理团队提出对数据的诉求与本质的洞察，并不单纯只想得到数据的呈现和可视化，更希望得知变化背后的原因，然后采取一系列决策手段。如果通过以往的任务下发链路，需求响应速度往往较长，要先把需求告知分析团队，若数据有缺失，再提给数据团队，当结果返回给管理团队时，往往会带来决策滞后性，影响实时决策。
其次是业务团队之痛，BI产品学习门槛高，数据解读靠人工。
BI 人员是企业内部的宝贵资产。复杂 BI 的学习难度相对较高，业务人员需要非常熟悉什么指标对应哪个数据集、使用什么聚合函数、什么过滤条件等等。而且现在的 BI 产品为了做到足够灵活，功能很复杂，一个产品有几十，甚至上百种功能，若没有经历过完整的培训，就不知道这些功能到底隐藏在哪。BI 产品功能隐藏在水下，使用难度也较高，更多还是通过 BI 产品做数据呈现，对于数据结论的生成，还需要人为地做总结。其实在于最后一公里的问题上，并没有一个很好的解决方式。
另外，数据团队的也有难点痛点，业务需求复杂且跨部门的数据指标口径不统一，很难保证实时响应业务需求变化。
数据团队在面对数仓做很多表的情况下，会遇到某些口径同名不同义，或者同义不同名的问题，或者不同部门对于数据的口径定义不一致，开发数据经常要核对数据问题，以及和不同部门之间串联，去做拉平和一致性的相关校验。
02 智能分析的构建与能力
数据分析针对上述三个不同的角色，都会有一些相关的痛点。智能分析如何解决问题呢？
单纯看取数，基于大模型有三条路线。
1、 Text to SQL
2、 Text to Metrics(API)
3、 Text to Code。
Code 应用于类似 Python 的灵活性分析方式，做小数据量的分析。一旦面临着企业级的分析，往往因为资源压力、计算的复杂性，导致任务是无法顺利执行。
面临企业内部数千张表，怎么做表的标注？不同表之间如何关联？不同表之间是否有口径冲突，或者不统一的问题？以及在生成复杂的 SQL 的情况下，是做硬提交，还是对 SQL 做计算逻辑的优化？这些都面临着问题。
我们选择通过 Agent 的机制，采用 Text to Metrics 的方式去执行的。
上图总结了一些客户真实的问题，大模型基于语言交互的方式，无法限制问题方式。
第一个问题，“最近某几天或者最近某几个月，某产品的订单总量是多少？”
这个问题大模型理解比较轻松，因为是一个单任务，并且对于字段的指标，比如对订单量、某某产品、时间等维度，识别较准确，一个上卷就可以做到。
在第二个问题，大模型可以逐渐开始发挥优势，因为对口语化的理解，尤其语义模糊的理解如何对齐标准化的语义，大模型有较好的对齐能力。通过 NLP 手段，不断学习大量的数据，在解决语义模糊上有较好的对齐能力，这也是大模型对意图理解提升、语义对齐等相关能力的涌现。
第三个问题在数据分析这块，国内外销量，经常存在两张表。两个销量的字段都叫 sales_count，如果对每个 sales_count 都做标注的情况下，针对两张表做 union all 或者做关联的时候，会导致生成的SQL结果不准确。这种情况采取的解决方案，是把所有数据通过数据模型打宽或预打宽，通过语义理解然后对齐到相应的指标字段。
第四个和第五个问题是复杂任务，因为不能限制用户问的问题，用户提了长句子，就会拆解成几个任务。
第四个问题，先查询过去某品牌三个月每个产品的销量，再基于查询的结果找到排序最好的几款产品，根据第二步任务结果，找到排序最好的产品平均计算每月的销量。
这就充分证明了为什么要加持 Agent？因为 Agent 可以把一句话拆解成多个简单子任务，并给出任务之间的依赖关系（串行还是并行）。然后通过每个任务的依次执行，让用户不用关注中间过程。任务执行后，提取出最后一步的结果，返回给用户。
第五个任务更复杂，因为只是一个目标，融合了多种算法能力。比如管理层问，“华北地区上个月环比为什么下降了？”首先，我们不仅要查上个月的数据，还要针对前一个月的环比数据作计算，并且判断是否下降。在此基础上，我们还要调用归因能力，归因的算法能力不是大模型本身所具备的，所以我们要通过插件化的方式让大模型去调度，把之前的结果做参数解析填充到对应插件里，并生成最终的结果 。
除此之外，我们也需要大模型的外延能力，大小模型的协同，形成 Agent 的整体机制，才能满足企业内部不同客户问答的场景和复杂问题。针对以上五个问题，我们分析了每个问题的难度和痛点。总的来说涉及三块。
1、语义对齐，怎么对齐用户口语化的查询和指标字段、维度字段、甚至是其它API的出入参数。
2、任务多样性，用户在提一个复杂问题或者目标时，大模型肯定无法直接执行，但是可以把目标或复杂任务拆解成多个子任务后，每个子任务做协同执行，再完成用户最终的提问需求。
3、计算性能，尤其是对话式分析，用户对于这种计算性能的要求相对比较高。不能一个问题等了很久才有结果返回。计算性能以及查询性能需要较大的提升，才能满足对话式分析的场景，真正实现所问即所得。
三个问题适宜的解决途径是什么呢？
第一块通过语义增强配置的方式，把企业的业务数据做指标语义化相关的生成和配置。要知道指标的名字，业务口径，应用场景是什么。用户在提问时并不一定准确知道什么场景下该问什么指标，他最大的可能是把场景描述出来，基于相似度、索引，找到指标，这也就是指标配置应用场景的目的。另外配置业务的口径，以及指标的名字、别名，帮助大模型理解用户，不管哪种描述，应该对齐到哪个指标，类似于帮助大模型理解用户的query，做语义增强的作用。把所有解析出来的用户指标、维度和时间三要素填充到标准的指标查询 API 里边。然后通过 API 调度，生成后台优化好的SQL，提交到底层的数据库引擎里做查询，这样性能较快。
第二块，针对任务多样性，主要采用了 Agent 机制。在Agent构建方面，我们主要采用了动态的thougt modules, positive example, negivative experience的引入，去提高模型的理解和执行效果。
动态thought modules类似针对不同的问题引入不同的思考方式，比如针对纯计算问题可以采用step by step的方式，针对复杂任务可以用divided in的拆解方式等。
另外，相似query下实现的正例和思考轨迹，以及错例我们也会做动态的引入，让大模型进行反思，既学了正例，又通过难、错例反思，避免生成错误结果，最大限度地保证规划拆解的准确性。
在规划拆解之后，通过插件调用执行子任务，利用大模型把之前以及当轮的结果结合 query ，解析成意图理解后要调用的插件，把参数解析进去，触发插件的执行。比如，基于指标查询会把指标、维度和时间三要素解析出来，填充到标准化的接口。还会用到小模型，比如归因、预测算法，异常检测算法等。当整体结果返回后，我们会通过一个reflection机制去判断是否达到用户query的预期，如果未达成，会重新启动新的规划。
第三块，指标查询背后有我们自研的HME(指标计算引擎)，它基于OLAP数据库(Apache Doris/Starrocks)，将指标预计算抽象成Metric Index（类比数据库索引），即便是复杂的同环比也能提供秒级查询。Metric Index的配置来自内置的行业场景、用户配置、大模型分析，HME通过启发式规则与代价模型结合生成Index。HME允许用户根据自己的情况在性能、成本、灵活性上进行权衡。
数势科技大模型增强的智能分析产品整体架构如上图，数据接入后，基于数势自研能力做性能加速，包括语义管理配置以及计算分析的引擎。
上层完成复杂任务的规划，以及引导和问题下钻。用户对于对话式产品，往往会面临着不知道怎么问的情况，或者上一步分析动作完成后，不知道下一步该做什么。我们会通过分析思维链知识的构建，解决冷启动的问题和问题连续下钻的问题，给出相关任务的可建议动作，帮助用户进行启发式的探索分析。
同时产品还具备其他复杂的分析能力，包括归因、预警、预测仿真等，整体实现用户在该界面的所问即所得。并且支持分析工作结束后的报告生成下载和 IM 的一键触达和转发，在数据分析场景达到整体闭环。
数势科技大模型智能分析产品SwiftAgent的运行架构是多Agent 机制，当用户提问目标时，把分析的技能，拆解成相关的专家机制。大模型在规划环节要理解现在拥有多少技能，规划出前后任务以及首末任务的关系。通过任务的协同，再把任务对齐到技能层的动作执行，每一层的结果之后做汇总，做整体的评估，判断出到底是完成，还是再做新的规划和迭代。最终生成有数据有逻辑，并且结合业务 sense的分析报告，呈现给用户。
在建设产品时也考虑了几点：
1、关于Agent 任务规划，用户怎么对我们的动作和拆解动作达到可信？
我们会把具体任务的拆解步骤呈现出来，告诉用户每一步的做法是什么，以及最终任务是否完成了结果。用户清楚地知道大模型怎么帮助执行的，再基于 current step 任务解析的时候，比如说指标查询，可以把查询出来的指标、维度等，通过口语或文字的方式反馈给客户。
我们在这一层做了些思考，如果把背后的 SQL 反馈给客户，不是所有的客户都懂code 或 SQL，对于客户来说，还是相当于黑盒 。所以，数势科技的产品能呈现更多口语化或文本化的内容，让客户在理解层面更可信。
2、设计图、表的呈现，数势科技采取 LUI 和 GUI 结合的方式。用户也可以实现交互式的图表变换、筛选和过滤等。
3、归因方面，我们不仅通过归因算法的小模型帮助大模型协同解决问题，同时对于结果也会做整体结果的呈现。如给一段文字的相关总结，这样能够避免客户再去查询数据时不知道具体数据的含义和如何下钻。
4、报告解读方面，我们会通过prompt的方式做template learning，让模型能够基于参考模版生成相似的报告总结，呈现给客户，并且可以进行下载和转发。
03 具体案例
某客户在面临数字化升级的时候，多门店的店长和督导人员都有看数或分析数的诉求，却苦于能力不足难以实现。这类企业有数据分析能力的人对一线业务隔得很远，很难根据每家门店做实时数据分析。长此以往，对企业发展数据价值的挖掘难以实现，总部无法把握各门店经营现状，难以实现智能决策；另一方面，BI 产品使用门槛相对比较高，有些数据的字段店长和督导根本无法理解，就会造成看数的难点，更毋庸提有效用数。
针对以上现状和问题，想要实现数字化升级，目前有几个主要的挑战：
1、业务经营有线上和线下两种方式，这导致企业数据不完整，以及加盟店之间的信息相对割裂，分散在各个系统里，数据间口径不统一；
2、针对数据不统一，它的应用情况相对来说比较复杂。因为不同系统之间它会面临着数据、行为、过程、客户画像、标签等数据的丢失，难以形成体系化的分析；
3、在看数、分析数辅助决策时，整体效率较慢，过于人力堆砌，必须有分析人员，才能对帮助做决策支撑，此过程响应效率相对较慢。
在上图解决思路的基础上，我们在指标体系的整体解决思路是：
1、先做指标体系化建设，同时做指标自助开发，包括指标的定义、管理相关功能。
2、预警归因、业务自助分析、报告生成与解读。这部分会集成到对话式分析产品中，让用户通过提问的方式做取数分析以及报告生成。
3、针对底层数据，建立完整的数据管理标准，包括流程以及数仓的整体模型，保证数据的一致性，以及不再面临脏、乱、差相关情况。
指标体系设计阶段，我们在前期为该企业做了咨询服务，通过自上而下的指标体系拆解、梳理，构建整体的指标体系。指标体系也会分为不同域，每个域下都有不同类型的指标，会做整体的设计，让企业内部针对同一个体系的设计达到统一认知，包括看数、取数的一致性。
针对于自上而下的设计，通过对于北极星指标的拆解，我们先判断该企业今年的北极星指标是什么。门店销售额是关注重点，形成纵向有支撑，横向有业务联系的指标体系，再确定业务模式，最后做物理拆解，形成分而治之的方式。
通过自下而上的方式梳理出企业内部的数据资产，让企业内部本身的资产达到不浪费盘活资产的结果。我们会梳理内部已有的数据表、报表、以及通常用到的字段和口径，把这些信息融入到现有的指标体系设计里。
看数只是第一步，进行归因分析以及预判未来增长趋势，帮助企业做决策支撑才是最终想达到的目标。这方面我们帮助企业建立小模型的相关能力，最终会融入到整个产品体系里，以及放到工具池里，让大模型能力在规划时能够进行充分调用。
数势科技为该客户搭建的产品让业务对于执行过程做到了可视化，帮助客户理解任务的执行，最终会输出些复合业务场景语境的数据报告，带核心要素的呈现，帮助相关决策。
