基于指标+标签的经营分析 Agent 创新实践

发布日期：2025-01-13 14:50:14 浏览次数： 3157

作者：DataFunTalk

微信搜一搜，关注“DataFunTalk”

导读数势科技研发的数据资产和数据分析相关产品，主要面向零售和金融企业，帮助其进行业务语义层资产构建，为企业提供基于大模型增强的数据分析 AI Agent、智能指标平台、智能标签平台及智能营销平台，从而助力企业提升数字化决策能力，推动企业数字化升级。本文将分享如何基于大模型能力，叠加指标和标签平台能力，构建企业内智能数据分析产品。

主要分为以下五部分：

1. 企业经营分析的难点和挑战

2. 智能分析的路线选择

3. 如何设计经营分析 Agent

4. 企业经营分析的展望和思考

5. 问答环节

分享嘉宾｜李飞博士数势科技 AI 负责人

编辑整理｜王丽燕

内容校对｜李瑶

出品社区｜DataFun

企业经营分析的难点和挑战

企业内部的数据分析涉及到诸多方面，包括：加工制作报表；基于数据发现异常因素，开发人员需要通过 SQL 或算法去做多维异常检测；进一步挖掘异常背后的原因，又需要因果推断或者归因洞察等算法；分析之后还需要撰写数据分析报告。

早期的企业经营分析主要是基于数据库进行开发，通过写 SQL 或者 Python 等编码方式实现，开发门槛很高，企业内部受众大约只有 1% 左右。随着 BI 时代的到来，利用无代码化平台，可以在平台上拖拉拽，通过业务规则和业务逻辑配置的方式，快速生成报表和可视化展示，得到想要的结论。然而使用 BI 的人要有业务分析思维，同时熟悉产品和配置，这些要求也无法推广到一线业务人员，因此受众人群在企业内部大概仅有 15% 到 20%。企业内部其余的人想看数据做决策就需要提需求，经过层层传递，最后通过业务分析师帮助得到想要的结果。

因此，业务团队的痛点是在洞察数据时需要在一系列的链路层层传递需求，看到数据和结论需要很长时间的等待。而数据开发人员的痛点则是需要每天把时间和精力投入到开发无限的报表之中。因此我们希望利用智能分析相关产品来解决这些痛点。

智能分析需求大概可以总结为 5 个范式，面临诸多挑战：

最近 7 天 XX 产品的订单总量多少？这种需求需要找到时间范围、维度以及指标字段，比如订单总量。
XX 产品今年累计卖了多少？人通过语言提问有时会语义模糊，“卖了多少”可能指销售量、订单量、销售额，大模型对这句话进行翻译时，很难找到背后的字段和含义。
今年 XX 品牌在国内和海外的整体销量是多少？这个需求可能涉及多表查询，比如国内和国外分别有一张数据表，就需要通过 join 关联关系把两个销量字段取出来。如何通过语言去实现跨表的关联是一个挑战。
XX 品牌最近 3 个月国内销量最好的产品哪一款？每个产品平均每月销量多少？用户一句话的需求可能会有多个任务，这个示例是两段式的任务，第一个要先找到国内前三个月销量最好的产品，然后再找到这个产品平均每个月销量是多少。
华北地区 XX 的销量月环比为什么下降了？这个需求是一个隐含性假设任务，要先找到华北地区 XX 的销量的月环比，再判断月环比下降值，再基于下降值，通过归因算法去做一些维度归因。用户可能还会需要根据历史销量值生成折线图等图表生成任务。这些任务单纯通过 NLP2SQL 是难以实现的。

用户的一句话需求任务具有多样性，利用大模型，可以把用户的需求任务拆成多个子任务，再让每个子任务根据对应的能力需求做串行或者并行的调用。Agent 的工作就是将任务拆解，拆解后的每个任务是一个最简单的原子任务，再调用具有对应能力的 function 或 API，返回执行结果，再根据结果反思是否需要做进一步的拆解，或者重新规划求解。这就是 Agent 为数据分析领域带来的帮助。

智能分析的路线选择

智能分析有不同的实现路线：

NLP2SQL：本质是取数，大模型通过微调或 SQL 训练集生成 SQL。当前更多地会结合 RAG，把生成式的任务改成填充式的任务，在生产中发现大模型做填空要比做生成稳定性更高，其生成稳定性会受到多方面影响，固定住 temperature 或随机种子，模型在生成 100 个 token 之后随机性会增加，大模型网络间的梯度传递也会有随机性波动，导致生成的 token 波动。在 SQL 生成时也会面临一些问题，如何结合一系列衍生的能力，比如基于指标的归因洞察、异常检测以及制作可视化报告和图表，还需要给到大模型各表描述，让大模型去找到多表之间的关联关系，大模型在判断表之间关系方面的稳定性会相对不足。
NLP2API：把数据语义化封装到 API。其本质也是做填空题，确定 k 值之后根据 k 的描述去填充其对应的 value，API 能把产品功能里复杂的逻辑封装到 API，大模型只需要把用户的语句 NLP2API，这种方式稳定性会更高。
NLP2Python：开发时用 code 的灵活性很高，code 可以突破 SQL 本身的一些局限性，通过 Python 代码可以生成算法预测和归因的模块，但同时也会带来稳定性的不足。但随着大模型代码生成能力的增强，这种方式的能力也会逐步增强。

上图示例是 NLP2SQL 的实现路径，左边是来自 OpenAI 的一个标准的生成 SQL 的示例，但是在实际生产过程中并非如此简单。先指定一个系统指令 system prompt，还要告诉模型拥有的数据库以及数据库中表的具体描述，再基于标准的 SQL 拼接规范，生成 SQL。

同时，还要根据问题去设计 prompt 模板，并且要对 NLP2SQL 模型微调、评测和训练。评测也存在挑战，如何定义 SQL 生成的准确度，如何评估 SQL 的可执行性？SQL 的可执行性还需要考虑性能，不能只是可以执行出结果，也要评估执行出结果的耗时，才能达到企业级应用的标准。

NLP2API 是先定义好数据分析相关 API，比如 BI 系统和指标平台的 API 和算法 API 等很多 API 池子，这样就能通过 API 路径实现搜索，通过搜索，找到合适的 API，再把用户的语句翻译成 API 参数完成对 API 的调用。这种方式的好处是 API 自带校验性，并且通过工程化而不是通过大模型生成的方式可以实现性能较好的 SQL 结果生成。

如何定义 Semantic API？数据本身没有语义，我们要通过工具和手段对已有数据定义出其语义。

语义统一：大模型对语义理解相对比较好，但是模型学不到在企业内部的行业黑话和术语，所以需要增加企业内部的同义词，帮助大模型去理解。
口径统一：需要统一数据字段在企业内部的技术口径和业务口径，保证字段和描述之间的口径统一。
权限统一：企业内部每个人或者不同部门能看到的数据应该不一样，因为数据权限不一样，在企业内部做数据要考虑权限统一问题并融合到语义层。

为什么要基于指标和标签去做 NLP2API？

面向对象理解：指标和标签中封装了业务逻辑和口径，其分层结构设计包含了很多过滤条件和表达式，模型不需要理解具体内容，而是将指标和标签视为对象，面向对象去理解。
指标和标签体系化设计：体系化设计增加了大模型召回命中率，因为每个指标层级下指标维度是少数的几个，天然会有助于进行语义上的过滤，使召回的范围少且准，进而生成效果就比较准，所以指标体系辅助了语义理解召回的效果。
可解释性高：解析结果可以通过要素反显给用户，相较于 SQL 更易被非技术人员理解。
衍生能力：通过指标体系可以衍生很多 API 或者 function 等分析能力（如归因，预警，趋势预测等），被大模型合理并无缝地衔接和调用。

上图是上述三种实现路径的优劣势对比，在实际场景中需要根据具体情况去选择。在表不是特别多逻辑不复杂的时候，可以采用 NLP2Code 和 NLP2SQL。当业务逻辑复杂时或表多时，要通过一种底座和手段把数据在工程层面上提前做聚合，再让大模型更好地去理解。

如何设计经营分析 Agent

上图展示了 SwiftAgent 的流转链路。在用户提出请求时，没有完全抛弃 NLP2SQL 和 NLP2Code 的方式，我们通过一套意图路由机制，在用户 query 进来的每个节点做意图判断和路由，判断是否能通过指标和标签解决问题，在 Agent 机制下去做技能的采样、元数据采样、记忆采样，即围绕指标和标签有哪些方式和 API 技能，元数据，以及历史记忆。如果是指标和标签之外的问题，我们会通过开放性的分析生成 SQL 的方式去做兜底。

上图是 Agent 的简要框架，不是每个问题需要通过 Agent 去做规划和任务拆解，用户的问题既有简单又有复杂，而交互时效性要求较高，所以前期通过意图识别机制，判断问题类型是简单还是复杂。针对简单问题，就直接调用相关的技能做参数的 mapping 和解析。对于复杂问题，则通过 planner 机制，包括 ReAct 和 P&E，P&E 是做分步执行，没有反思，而 ReAct 时间较长，每步做反思，通过之前任务的结果去做校正。此外，还利用 RAG 去做动态的 embedding 嵌入，以及做历史的上下文反馈，告诉大模型 goodcase 和 badcase。

总结来说，它具有规划反思能力、意图路由能力、垂直领域调优能力。每个技能都要定义好描述，包括出参和入参，才能解析，之后拼接各项技能串行或者并行执行，汇总最终的结果，再通过 reward 分数判断是否需要重新规划路径，如果是完成状态，将结果发回给前端。

我们在设计 Agent 时遇到了以下难点：

1. 静态规划思路无法解决所有个性化提问方式

Planner 机制无法满足千人千面的用户个性化 query 实现。规划方式有很多种，包括逐步思考分解法、P&E、批判法、假设法等。我们把每种方式形成原子 module，当用户 query 请求时，通过判断对应 query 应该选择的思考 module，然后让大模型基于选择的思考方式组件，形成 planner 的 prompt，实现通过不同的思考方式执行任务的链路。因此，对应的解决方法是首先进行思考方式的选择，然后基于用户的 query 和思考方式对 prompt 做修正，最后基于修正后的 prompt 让大模型做解析。另外，还引入动态的 Few-Shot 的方式引导大模型持续执行。

2. 任务规划“穿越性”问题

指标分为原子指标、派生指标和衍生指标。比如用户想要查询过去一个月的累计销售额，数据库里可能既有原子指标销售额，也有派生指标月累计销售额，那么大模型如何生成规划呢？如果只有月累计销售指标，那只能生成上图中第二种方式的规划。如果两个指标都有，可以规划成两个方式的任务，第一个是先查询过去一个月每天的原子指标销售额，然后再基于时间窗口累计求和，第二个是直接查询最新时间一个月的月累计销售额，这种情况下应该选择哪种路径去解决？有以下两种解法，当前我们也在对比其效果：

第一种方式是基于指标树关系设计，我们编排一个 DSL 模板，里面有 SUM 算子。当指标识别到月累积销售额，口径包含 SUM，就把 DSL 模板里的 SUM 算子去掉；而如果指标是销售额就要用到 DSL 里的 SUM 算子。
第二种方式是在规划时提前把已有的指标告诉大模型，它通过向量和关键词召回等方式，返回相关的候选指标，再根据候选指标生成规划路径，一条规划路径是不稳定的，我们会生成多条规划路径，从中选择最短可执行路径，再拆分成具体的任务分步执行。

3. 提升工具调用的效果

接下来探讨如何提高 API 的调用能力。如果每次通过语言去解析到对应的参数，难以保证稳定性。我们的基座模型是针对一些 case 去生成相应的结果，下一次它能够遵循相应的结果去解析，这种方法稳定性会比较高。告诉大模型工具的 description 和出参、入参，生成 query，再基于这些 query 正向解析去调用工具得到对应的结果，这样就会产生很多正负样例，存到数据库里，下一次调用相应的工具时，可以索引到对应工具的样例，把样例动态去引入到 prompt 里，再通过 prompt 调优的方式学习，从而保证执行的准确性。

4. 时间推理效果不稳定

大模型时间推理效果极其不稳定，主要原因包括：

语义割裂问题：比如“帮我看一下去年的销售额是多少，按月呈现”，大模型理解时间实体时可能会忽略掉后面“按月呈现”的描述，而解析成 2023 年。
时间推理判断：比如“6 月第 3 周”，大模型可能先去推理 6 月第 3 周是哪一周，具体是几号之间，经常会存在解析的日期不准的情况。
陈述模糊：比如“帮我看一下最近几天的销售额”，最近几天表述模糊，大模型可能今天返回最近三天，明天又会返回最近 7 天，回答结果不稳定。
歧义冲突：比如“帮我查看一下 6 月前两天的销售额是多少”，大模型可能有三种理解结果：6 月 1 号和 6 月 2 号，5 月 30 号和 5 月 31 号，或者是 5 月 31 号和 6 月 1 号。

大模型这种解析结果的不稳定，会使用户感觉效果不好，不利于用户的使用体验。

针对上述问题，我们的解决思路是，先以规则去保障稳定性，开发一系列包括农历日和公历日日期识别的相关算子，通过规则性实体抽取，把实体通过规则解析成具体的年月日。抽取时间实体时，让大模型去判断规则抽取的实体是否能够去满足用户的 query。经测试，这样做能使准确性达到 98% 以上。大模型判断能满足时，用时间解析 Parser 解析成具体的时间，对于剩下 2% 的 badcase，大模型先去抽取时间的实体，再基于实体去解析成对应的时间，而不是让大模型直接端到端地把用户的 query 去解析成具体日期。

5. Agent 记忆缓存和命中较难

大模型每次做新题不会保证答案的稳定，而旧题可以参考历史答案。Agent 是产品里的一个机制，并不是算法的能力。所以我们通过用户以往问询的一些样例，去解析正确要素，然后复用到相似的样例上。除了历史问询记忆，我们还有知识库里的记忆，通过记忆对用户的 query 做标准化的改写。实验发现如果 query 改写成标准化的版本大模型会理解得非常准确，实现标准问询，标准出结果，从而保证稳定性。Query 改写同样也遵循通用公式：最近性、相关性和重要性。

上图是我们产品的架构，核心优势包括：

统一语义层的构建：即指标和标签，确保数据分析准确可靠。
用户可干预：用户的每一次的干预都是对模型的一种反馈，对大模型的迭代和微调，以及产品逻辑和业务规则的迭代都有帮助。
多源异构数据链接：分析不仅需要结构化的数据分析，还需要知道分析之后的决策和行动，可搭配知识库，把结构和非结构化数据串联起来，通过企业内部的知识文档，在分析洞察完数据产生的原因后告诉业务人员下一步的行动。
持续反思学习：让系统更懂用户。
数据计算加速引擎：在 API 内部通过工程化手段做 SQL 的底层优化，让查询性能得到极大的提升。

企业经营分析的展望和思考

对经营分析 Agent 的未来发展有如下一些展望和思考：

大模型从能听懂人话升级为帮人说话：我们当前对 chatbot 是被动式使用，我问你答的模式。在未来，我们希望大模型能够主动去帮人，构思业务分析的场景，根据使用者用户画像，以往的提问历史，角色部门权限，可以每天生成目标和任务，用户点击确认，整个 Agent 到后台自动运行，最终跑出来用户需要的分析报告，还能帮助用户额外产出其它有洞见的分析报告和结论。
能和人一样总结归纳升级为总结之后自动决策：数据分析是为了发现数据背后的本质和原因，再进行下一步的行动。Agent 的本质是连接，Agent 的方式，能够把企业内部的系统工具和产品连接起来，做到整体互联互通，进行各种决策和行动。
能像人一样规划升级为像业务专家一样规划：Agent 初期阶段，还无法达到专家的规划能力，未来希望它能够像专家一样去帮助用户解决问题。

未来通过上述三个方向的升级，能够让产品基于大模型的工具和能力更有价值。

问答环节

Q1：企业用到您介绍的分析产品之后，数据分析人员的职业定位会有什么改变？

A1：产品并不是替代分析人员，而是作为一个助手，帮助其完成日常大量枯燥的、没有技术含量的报表开发工作，而分析人只需要聚焦于更复杂的工作，比如像专家一样做更深度的洞察和分析。

Q2：医疗行业的企业使用你们的产品，怎么确保数据的安全性？

A2：首先该产品并非为医疗行业订制，而是用于企业经营分析。从产品本身来看，可私有化部署，所以数据可以不出企业，也就不存在数据出域的安全性问题。

Q3：Agent 应用开发是定制化的，还是依据几个主要的成熟的 Agent 开发框架来开发，您更倾向于哪种方式？

A3：我倾向于第 2 种，做 Agent 开始要参考一些开源的 Agent 框架，现在已经公布了十几种 Agent 开源框架，一定会有一种是适合你当前场景的，然后基于这种框架的思路，再去做针对性的业务的嵌套和开发。我们会参考多种框架，因为每个开源框架都有各自的优劣势。AutoGPT 是大模型 Agent 鼻祖，但存在不稳定的问题。单 Agent 可以参考 ReAct 的方式，多 Agent 可以参考阿里的通义千问 Agent，或者国外的一些开源框架。需要根据具体的场景去选最适合的。

Q4：在产品和技术上怎么去引导用户更高质量地提问？

A4：内部技术层面，query 改写让用户无感知是最好的，但是难度比较高。产品引导层面其实也包含很多技术，比如搜索联想，提供一些标准问题供用户参考；又比如要素的联想，用户问“卖了多少”，产品可以给出销售额、订单量等选择，让用户去选一个。搜索联想的方式可能效果会更好，因为给出的是一个完整的问题，而不会像要素联想那样打断用户输入思路。

Q5：怎么能让用户相信返回的数据是准确的？

A5：这里包括两层，第一层是相信大模型翻译出来的是准确的，第二层是基于翻译出来的取的数字结果是准确的。第一层是通过要素的反写，让用户知道把他的提问翻译成了哪些要素的组合，从而增加可信度。第二层在做指标和标签开发的时候，从数仓到平台里的数据核准和校验要做准确，这是和大模型本身没有关系的基础工作。

Q6：Agent 现在是内部自己训练，还是外面公共的大模型。在一些解决方案上发现对大模型本身的能力是要有一定要求的。如果想要在一个私有环境中使用，是需要自己部署一个大模型，还是可以配其他大模型。

A6：有两方面考虑，第一个是在部署时需要考虑企业内部可承担的算力成本，百亿左右的模型成本相对来说比较低，但超过 500 亿以上的成本相对来说就会比较高，这要看企业的选择。根据我们的经验，300 亿以下要靠微调，300 亿尤其 500 亿以上，靠 prompt 微调就可以。500 亿以上通过 prompt 和工程的方式能够避免很多错误的情况。但是在 500 亿以下，可能有很多情况是工程手段无法避免的，这种情况下需要靠调，而部署方式要看客户对资源的要求。

Q7：SwiftAgent 流转框架里有 check system 和 retry system，它们都有最终的 output 分支，其执行标准是什么？

A7：Check system 是我们内部的一个重试机制，针对于不同的情况，比如当它发现找不到对应的指标，或者用指标的 API 逻辑回答的结果是错的，或者和用户提问的要素不匹配的时候，我们会通过 SQL 的方式直接侵入到底层模型表以下，通过 SQL 生成的方式，去检索出来相应的结果。其中，判断用户的 query 和解析的要素是否一致，是由大模型来完成的。此外，还有很多工程化手段，比如 API 底层引擎里直接有代码报错，此时也需要重试的机制。

对于 retry system，一部分会到 Agent 重试，还有一部分会到 SQL generate。因为 Agent 部分融合了标签和指标，而生成 SQL 是一种兜底，它是一个单独的线路和技能，SQL 本身生成效果也有不稳定，一般也会让它重试，但是会设置最大重试次数。

Q8：用户对数据的信任问题，除了用数据治理去解决一些事情之外，还有什么其他方式解决吗？

A8：这个只能保证底层数据的准确，数据治理是必不可少的。

Q9：产品的优势之一是用户可干预，在哪些环节是用户比较适合介入干预的？干扰和辅助提问的临界点应该怎么把握？

A9：其实是召回和生成的平衡。比如大模型召回的字段生成的结果，你判断它生成的结果在你之前的候选集里分数排得并不是特别靠前，但是大模型选择了它，那你就要反问，同时要附上分数较高那几个，这个是要根据具体的业务场景去做一个抉择。出现冲突矛盾的时候，就需要去做反问。除了反问，还有对结果的赞和踩也可视为一种用户干预，但其实是对结果的校准。

53AI，企业落地大模型首选服务商

产品：场景落地咨询+大模型应用平台+行业解决方案

承诺：免费POC验证，效果达标后再合作。零风险落地应用大模型，已交付160+中大型企业