基于指标+标签的经营分析 Agent 创新实践
导读 数势科技研发的数据资产和数据分析相关产品，主要面向零售和金融企业，帮助其进行业务语义层资产构建，为企业提供基于大模型增强的数据分析 AI Agent、智能指标平台、智能标签平台及智能营销平台，从而助力企业提升数字化决策能力，推动企业数字化升级。下文会分享如何基于大模型能力，叠加指标和标签平台能力，构建企业内智能数据分析产品。
主要分为以下五部分：1. 企业经营分析的难点和挑战
2. 智能分析的路线选择3. 如何设计经营分析 Agent4. 企业经营分析的展望和思考5. 问答环节分享嘉宾｜李飞博士 数势科技 AI 负责人
编辑整理｜王丽燕
内容校对｜李瑶
出品社区｜DataFun01企业经营分析的难点和挑战
企业内部的数据分析涉及到诸多方面，包括：加工制作报表；基于数据发现异常因素，开发人员需要通过 SQL 或算法去做多维异常检测；进一步挖掘异常背后的原因，又需要因果推断或者归因洞察等算法；分析之后还需要撰写数据分析报告。早期的企业经营分析主要是基于数据库进行开发，通过写 SQL 或者 Python 等编码方式实现，开发门槛很高，企业内部受众大约只有 1% 左右。随着 BI 时代的到来，利用无代码化平台，可以在平台上拖拉拽，通过业务规则和业务逻辑配置的方式，快速生成报表和可视化展示，得到想要的结论。然而使用 BI 的人要有业务分析思维，同时熟悉产品和配置，这些要求也无法推广到一线业务人员，因此受众人群在企业内部大概仅有 15% 到 20%。企业内部其余的人想看数据做决策就需要提需求，经过层层传递，最后通过业务分析师帮助得到想要的结果。因此，业务团队的痛点是在洞察数据时需要在一系列的链路层层传递需求，看到数据和结论需要很长时间的等待。而数据开发人员的痛点则是需要每天把时间和精力投入到开发无限的报表之中。因此我们希望利用智能分析相关产品来解决这些痛点。
最近 7 天 XX 产品的订单总量多少？这种需求需要找到时间范围、维度以及指标字段，比如订单总量。
XX 产品今年累计卖了多少？人通过语言提问有时会语义模糊，“卖了多少”可能指销售量、订单量、销售额，大模型对这句话进行翻译时，很难找到背后的字段和含义。
今年 XX 品牌在国内和海外的整体销量是多少？这个需求可能涉及多表查询，比如国内和国外分别有一张数据表，就需要通过 join 关联关系把两个销量字段取出来。如何通过语言去实现跨表的关联是一个挑战。
XX 品牌最近 3 个月国内销量最好的产品哪一款？每个产品平均每月销量多少？用户一句话的需求可能会有多个任务，这个示例是两段式的任务，第一个要先找到国内前三个月销量最好的产品，然后再找到这个产品平均每个月销量是多少。
华北地区 XX 的销量月环比为什么下降了？这个需求是一个隐含性假设任务，要先找到华北地区 XX 的销量的月环比，再判断月环比下降值，再基于下降值，通过归因算法去做一些维度归因。用户可能还会需要根据历史销量值生成折线图等图表生成任务。这些任务单纯通过 NLP2SQL 是难以实现的。
智能分析的路线选择
NLP2SQL：本质是取数，大模型通过微调或 SQL 训练集生成 SQL。当前更多地会结合 RAG，把生成式的任务改成填充式的任务，在生产中发现大模型做填空要比做生成稳定性更高，其生成稳定性会受到多方面影响，固定住 temperature 或随机种子，模型在生成 100 个 token 之后随机性会增加，大模型网络间的梯度传递也会有随机性波动，导致生成的 token 波动。在 SQL 生成时也会面临一些问题，如何结合一系列衍生的能力，比如基于指标的归因洞察、异常检测以及制作可视化报告和图表，还需要给到大模型各表描述，让大模型去找到多表之间的关联关系，大模型在判断表之间关系方面的稳定性会相对不足。
NLP2API：把数据语义化封装到 API。其本质也是做填空题，确定 k 值之后根据 k 的描述去填充其对应的 value，API 能把产品功能里复杂的逻辑封装到 API，大模型只需要把用户的语句 NLP2API，这种方式稳定性会更高。
NLP2Python：开发时用 code 的灵活性很高，code 可以突破 SQL 本身的一些局限性，通过 Python 代码可以生成算法预测和归因的模块，但同时也会带来稳定性的不足。但随着大模型代码生成能力的增强，这种方式的能力也会逐步增强。
语义统一：大模型对语义理解相对比较好，但是模型学不到在企业内部的行业黑话和术语，所以需要增加企业内部的同义词，帮助大模型去理解。
口径统一：需要统一数据字段在企业内部的技术口径和业务口径，保证字段和描述之间的口径统一。
权限统一：企业内部每个人或者不同部门能看到的数据应该不一样，因为数据权限不一样，在企业内部做数据要考虑权限统一问题并融合到语义层。
面向对象理解：指标和标签中封装了业务逻辑和口径，其分层结构设计包含了很多过滤条件和表达式，模型不需要理解具体内容，而是将指标和标签视为对象，面向对象去理解。
指标和标签体系化设计：体系化设计增加了大模型召回命中率，因为每个指标层级下指标维度是少数的几个，天然会有助于进行语义上的过滤，使召回的范围少且准，进而生成效果就比较准，所以指标体系辅助了语义理解召回的效果。
可解释性高：解析结果可以通过要素反显给用户，相较于 SQL 更易被非技术人员理解。
衍生能力：通过指标体系可以衍生很多 API 或者 function 等分析能力（如归因，预警，趋势预测等），被大模型合理并无缝地衔接和调用。
如何设计经营分析 Agent
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 号。
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：Checksystem 是我们内部的一个重试机制，针对于不同的情况，比如当它发现找不到对应的指标，或者用指标的 API 逻辑回答的结果是错的，或者和用户提问的要素不匹配的时候，我们会通过 SQL 的方式直接侵入到底层模型表以下，通过 SQL 生成的方式，去检索出来相应的结果。其中，判断用户的 query 和解析的要素是否一致，是由大模型来完成的。此外，还有很多工程化手段，比如 API 底层引擎里直接有代码报错，此时也需要重试的机制。对于 retrysystem，一部分会到 Agent 重试，还有一部分会到 SQLgenerate。因为 Agent 部分融合了标签和指标，而生成 SQL 是一种兜底，它是一个单独的线路和技能，SQL 本身生成效果也有不稳定，一般也会让它重试，但是会设置最大重试次数。Q8：用户对数据的信任问题，除了用数据治理去解决一些事情之外，还有什么其他方式解决吗？A8：这个只能保证底层数据的准确，数据治理是必不可少的。Q9：产品的优势之一是用户可干预，在哪些环节是用户比较适合介入干预的？干扰和辅助提问的临界点应该怎么把握？A9：其实是召回和生成的平衡。比如大模型召回的字段生成的结果，你判断它生成的结果在你之前的候选集里分数排得并不是特别靠前，但是大模型选择了它，那你就要反问，同时要附上分数较高那几个，这个是要根据具体的业务场景去做一个抉择。出现冲突矛盾的时候，就需要去做反问。除了反问，还有对结果的赞和踩也可视为一种用户干预，但其实是对结果的校准。
