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

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

• 最近 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. 提升工具调用的效果

4. 时间推理效果不稳定

• 语义割裂问题：比如“帮我看一下去年的销售额是多少，按月呈现”，大模型理解时间实体时可能会忽略掉后面“按月呈现”的描述，而解析成 2023 年。

  
  

• 时间推理判断：比如“6 月第 3 周”，大模型可能先去推理 6 月第 3 周是哪一周，具体是几号之间，经常会存在解析的日期不准的情况。

  
  

• 陈述模糊：比如“帮我看一下最近几天的销售额”，最近几天表述模糊，大模型可能今天返回最近三天，明天又会返回最近 7 天，回答结果不稳定。

  
  

• 歧义冲突：比如“帮我查看一下 6 月前两天的销售额是多少”，大模型可能有三种理解结果：6 月 1 号和 6 月 2 号，5 月 30 号和 5 月 31 号，或者是 5 月 31 号和 6 月 1 号。

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

• 统一语义层的构建：即指标和标签，确保数据分析准确可靠。

  
  

• 用户可干预：用户的每一次的干预都是对模型的一种反馈，对大模型的迭代和微调，以及产品逻辑和业务规则的迭代都有帮助。

  
  

• 多源异构数据链接：分析不仅需要结构化的数据分析，还需要知道分析之后的决策和行动，可搭配知识库，把结构和非结构化数据串联起来，通过企业内部的知识文档，在分析洞察完数据产生的原因后告诉业务人员下一步的行动。

  
  

• 持续反思学习：让系统更懂用户。

  
  

• 数据计算加速引擎：在 API 内部通过工程化手段做 SQL 的底层优化，让查询性能得到极大的提升。

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

• 大模型从能听懂人话升级为帮人说话：我们当前对 chatbot 是被动式使用，我问你答的模式。在未来，我们希望大模型能够主动去帮人，构思业务分析的场景，根据使用者用户画像，以往的提问历史，角色部门权限，可以每天生成目标和任务，用户点击确认，整个 Agent 到后台自动运行，最终跑出来用户需要的分析报告，还能帮助用户额外产出其它有洞见的分析报告和结论。

  
  

• 能和人一样总结归纳升级为总结之后自动决策：数据分析是为了发现数据背后的本质和原因，再进行下一步的行动。Agent 的本质是连接，Agent 的方式，能够把企业内部的系统工具和产品连接起来，做到整体互联互通，进行各种决策和行动。

  
  

• 能像人一样规划升级为像业务专家一样规划：Agent 初期阶段，还无法达到专家的规划能力，未来希望它能够像专家一样去帮助用户解决问题。

问答环节