在之前的 LLM Agent+DB 的章节我们已经谈论过如何使用大模型接入数据库并获取数据,这一章我们聊聊大模型代理在数据分析领域的应用。数据分析主要是指在获取数据之后的数据清洗,数据处理,数据建模,数据洞察和数据可视化的步骤。可以为经常和数据打交道,但是并不需要太过艰深的数据分析能力的同学提供日常工作的支持,已看到很多 BI 平台在尝试类似的方案。这里我们聊两篇论文:Data-Copilot 和 InsightPilot, 主要参考一些有意思的思路~
数据分析:Data-Copilot
- paper: Data-Copilot: Bridging Billions of Data and Humans with Autonomous Workflow
- github: https://github.com/zwq2018/Data-Copilot
先介绍下浙大提出的已扩展的数据分析框架,支持多种金融数据类型的查询,数据处理,简单建模,和数据可视化。Data-copilot 以金融领域的数据分析为例,提供了一套可以简单基于已有数据进行扩展生成的数据分析框架。
整个框架分成两个部分,基于大模型的 API 生成和基于生成 API 的 llm 任务规划和执行。其实说复杂也不复杂,数据分析任务里面几个核心的要素就是
- 分析啥:提问的实体,股票?债券?基金经理?
- 分析哪段时间:数据的覆盖范围,一季度?今年?
- 用什么指标:股票的收益率?债券利率?基金净值?
- 如何分析:收益对比?价格涨跌?排名?
- 如何输出:绘图?表格?文本?
API生成
设计部分其实是使用大模型来构建更符合上下文语义的 API 调用语句,以及 API 的输入输出。这部分代码并未开源......所以我们只依据论文和脑补做简单介绍。主要分成以下四个步骤
1. 生成更多的用户请求
API 的生成需要基于用户会问什么样的问题。而用户的提问又是基于你有什么样的数据。因此这里使用数据描述和人工编写的种子提问作为上文,让 LLM 生成更多的用户提问。
2. 生成 API 调用语句
把以上生成的所有用户提问,一个个输入模型,使用以下 prompt 指令引导 llm 生成完成一个数据分析任务,所需的多个步骤,以及每个步骤对应的API 描述和伪代码"Interface1={Interface Name: %s, Function description:%s, Input and Output:%s}"
3. 合并相似的 API 调用
每得到一个新的 API function,都会和已生成的 API function 配对后输入模型,并使用以下指令让大模型判断两个 function 是否功能相似可以合并为一个新的 API。例如把查询 GDP 的 API 和查询 CPI 的 API 合并为查询 GDP_CPI 的 API。不过个人感觉这个方案时间和 token 开销颇大,可能比较适合 online API 的在线构建,在离线构建时先基于 API 的描述进行聚类,然后每个 cluster 进行合并可能更经济实惠?
4. 为每个 API 生成对应代码
最后针对合并后的 API,使用大模型进行代码生成。这里使用了 pandas DataFrame 作为数据处理,数据绘图的数据交互格式。这里论文把工具调用分成了 5 个大类:数据获取,数据处理,合并切片,建模和可视化。
看完以上整个 API 构建流程,不难发现使用 llm 来自动生成 API 有以下几个好处(不过估计完全自动化难度不小......)
- 节省人力
- 和 APE 的思路类似,大模型生成的指令更符合模型生成偏好,API 同理
- 当前是离线批量生成,如果可以优化为 online 的 API 生成的话,可以使得 API 具有动态可扩展性
API调用
获得 API 之后,就是如何排列组合规划 API 的执行来回答用户的提问/完成用户的任务。这里的任务流同样拆成了多个步骤:
意图识别
第一步是意图识别,这里其实融合了搜索中 query 预处理的几个功能:
- 意图识别用于缩小问题范围提高后面 API 调用的准确率
- 时效性模块基于今天的日期和用户提问,生成问题对应的具体时间范围(包括时间范围标准化)
- 实体模块用于定位问题的核心实体
- 输出形式的判别是绘图、表格还是文本输出
论文把以上多个模块融合成了基于 few-shot 的大模型改写任务,会把用户的提问改写成一个新的具有明确时间区间,任务类型更加明确的文本,与其说是意图识别,其实更像 query 改写。如下
个人感觉意图这里完全可以不基于大模型,或者可以用大模型造样本再蒸馏到小模型上。以及整个意图识别的模块可以拆分成多个独立且粒度更细的模块,在金融领域至少可以拆分成大类资产实体的抽取对齐,针对不同资产类型的不同问题意图的识别,以及独立的时效性生成/判别模块。意图模块直接影响后面的行为规划,需要准确率和执行成功率都足够高。
行为规划
行为规划模块包含两个步骤,第一步是任务拆解,以上改写后的 query 会作为输入,输入任务拆解模块。同样是基于 few-shot 的大模型指令任务,把任务拆分成多个执行步骤,每个步骤包括任务类型。
这里作者定义了 stock_task、fund_task、economic_task, visualization_task、financial_task 这 5 种任务,任务拆解类似 COT 把一个任务拆分成多个执行步骤,但本质上还是为了缩小 API的调用范围。指令如下
基于以上任务选择模块每个步骤的任务类型,例如 stock_task,会有不同的 few-shot prompt 来指导模型针对该任务类型,生成多步的 API 调用,包括每一步调用的 API,输入,输出和返回值。行为规划部分通用指令如下
行为规划中一个有意思的点,是论文构建的API中包含三种不同的执行方式,串行操作常规单个输入单个输出,并行操作获取一个证券的多个指标数据,以及循环操作,类似 map 对多个输入执行相同的操作。以下是Data-Copilot的Demo
数据洞察:InsightPilot
- paper:Demonstration of InsightPilot: An LLM-EmpoweredAutomated Data Exploration System
- 相关 paper:QuickInsights: Quick and Automatic Discovery of Insights fromMulti-Dimensional Data
- 相关 paper:MetaInsight: Automatic Discovery of Structured Knowledge forExploratory Data Analysis
- 相关 paper:XInsight: eXplainable Data Analysis Through The Lens ofCausality
- https://www.msra.cn/zh-cn/news/features/exploratory-data-analysis
InsightPilot与其说是一篇 paper,更像是一份微软 BI 的产品白皮书。主打 EDA 数据洞察,和上面的 Data-copilot 拼在一起,也算是把数据分析最基础工作涵盖了。举个数据洞察的栗子,最早在 UG 用户增长部门工作时,每次 APP 活跃用户下降了,数据分析组收到的任务就是赶紧去分析活跃用户数据,看看到底用户为啥流失了,是被竞品抢走了,是最近上了什么新功能用户不喜欢,还是之前活动拉来的用户质量不高留存较少,基于这些数据洞察,好制定下一步挽留流式用户,激活沉默用户的具体方案。
那如何发现数据中的异常点?一个基础的操作就是对数据进行不同维度的拆分对比。例如把活跃用户分成男女,老幼,不同城市,不同机型,渠道来源,不同阅读偏好等等维度,观察不同 subgroup 的用户他们的活跃是否发生下降,下降比例是否相同,是否有某个维度的用户组流失最显著。这个维度拆分可以是平行维度,也可以是下钻维度,对比方式可以是一阶变化趋势对比,也可以是波动率等二阶趋势的对比等等
微软的实现方案其实是使用 LLM 把之前微软已经开发应用到 BI 的三款数据洞察工具进行了组合串联,这三款数据洞察工具分别是 QuickInsight,MetaInsight和XInsight。我们先简单介绍下这三款工具,再看大模型要如何对数据分析工具进行组合串联。
Insights 们
QuickInsight
QuickInisght 是最早也是功能最基础的数据分析工具,它能快速发现多维数据中的 pattern。它的洞察数据单元由三个要素组成subject ≔ {
标签:数据分析,洞察,19,用户,Agent,生成,API,LLM,数据 From: https://www.cnblogs.com/gogoSandy/p/17833048.html