在之前的 LLM Agent+DB 的章节我们已经谈论过如何使用大模型接入数据库并获取数据,这一章我们聊聊大模型代理在数据分析领域的应用。数据分析主要是指在获取数据之后的数据清洗,数据处理,数据建模,数据洞察和数据可视化的步骤。可以为经常和数据打交道,但是并不需要太过艰深的数据分析能力的同学提供日常工作的支持,已看到很多 BI 平台在尝试类似的方案。这里我们聊两篇论文:Data-Copilot 和 InsightPilot, 主要参考一些有意思的思路~
数据分析:Data-Copilot
- paper: Data-Copilot: Bridging Billions of Data and Humans with Autonomous Workflow
- github: github.com/zwq2018/Dat…
先介绍下浙大提出的已扩展的数据分析框架,支持多种金融数据类型的查询,数据处理,简单建模,和数据可视化。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
- www.msra.cn/zh-cn/news/…
InsightPilot与其说是一篇 paper,更像是一份微软 BI 的产品白皮书。主打 EDA 数据洞察,和上面的 Data-copilot 拼在一起,也算是把数据分析最基础工作涵盖了。举个数据洞察的栗子,最早在 UG 用户增长部门工作时,每次 APP 活跃用户下降了,数据分析组收到的任务就是赶紧去分析活跃用户数据,看看到底用户为啥流失了,是被竞品抢走了,是最近上了什么新功能用户不喜欢,还是之前活动拉来的用户质量不高留存较少,基于这些数据洞察,好制定下一步挽留流式用户,激活沉默用户的具体方案。
那如何发现数据中的异常点?一个基础的操作就是对数据进行不同维度的拆分对比。例如把活跃用户分成男女,老幼,不同城市,不同机型,渠道来源,不同阅读偏好等等维度,观察不同 subgroup 的用户他们的活跃是否发生下降,下降比例是否相同,是否有某个维度的用户组流失最显著。这个维度拆分可以是平行维度,也可以是下钻维度,对比方式可以是一阶变化趋势对比,也可以是波动率等二阶趋势的对比等等
微软的实现方案其实是使用 LLM 把之前微软已经开发应用到 BI 的三款数据洞察工具进行了组合串联,这三款数据洞察工具分别是 QuickInsight,MetaInsight和XInsight。我们先简单介绍下这三款工具,再看大模型要如何对数据分析工具进行组合串联。
Insights 们
QuickInsight
QuickInisght 是最早也是功能最基础的数据分析工具,它能快速发现多维数据中的 pattern。它的洞察数据单元由三个要素组成subject ≔ {𝑠𝑢𝑏𝑠𝑝𝑎𝑐𝑒(𝑠)数据空间, 𝑏𝑟𝑒𝑎𝑘𝑑𝑜𝑤𝑛 拆分维度, 𝑚𝑒𝑎𝑠𝑢𝑟𝑒(𝑠)观察指标}, 以下是{Los Angeles,Month,Sales}产生的数据洞察
QuickInsight,会先按不同维度,计算不同指标得到多组数据。洞察部分则是预定了 12 种不同的数据分析方式,例如异常值,突变点,趋势,季节性,相关性等等。每种洞察类型会基于显著性和贡献度进行综合打分,排名靠前的应该是单维度数据变化最显著,且对整体影响较大的。
MetaInsight
QuickInsight的洞察主要基于单个洞察数据单元进行,MetaInsight可以聚合关联多个洞察数据单元,产出更复杂,高级的数据洞察。简单来说是在以上三元组数据洞察的基础上,搜索不同的subsapce,以及measure,寻找具有相似数据洞察的三元组,并进行组合分析。继续以上洛杉矶销量数据的洞察,当我们扩展subspace到其他城市的销售数据时,MetaInsight会产出以下关联分析。
XInsight
以上QuickInsight和MetaInsight都还停留在相关性数据分析的领域,而XInsight着眼在因果性分析,也算是前两年很火的因果推断方向。也就是我们不仅想知道手机里同时有快手和抖音APP的用户,使用抖音的时间较短,还想知道到底是快手APP抢夺了用户的时间,还是这部分用户群体本身就属于东看看西看看没有固定偏好的群体。但真实世界中很难找到完全符合假设的因果推断,因为哈哈没有平行世界呀,因此只能通过一些控制变量,和数学建模的方案来近似模拟因果场景。感兴趣的同学可以看过来因果推断的春天
以下的案例中,同样是按月份维度进行拆分,航班延误时间作为指标。当在整个数据上进行洞察时会发现5月的延误时间比11月高了很多,但当控制变量当日是否下雨时,会发现在下雨天5月的航班延误时间是要低于11月的,因此5月份更高的降雨率可能可以解释5月更高的航班延误时间。
LLM Pipeline
InsightPilot就是基于以上三个数据分析引擎,使用大模型进行串联,来完成用户的数据洞察需求。还是那个观点,LLM+Agent的组合中,真正重要的是Agent,LLM只是负责基于上下文语义来选择最合适的Agent,并基于Agent的返回内容来决定下一步的操作,说白了就是串场子的,当然最后也需要LLM来生成数据分析报告。
这里大模型主要负责:初始化->洞察选择->意图选择->洞察选择->意图选择….->报告生成
- 初始化任务:会先调用QuickInsight生成数据集的基础洞察,然后使用Prompt,让LLM基于Agent返回的多条数据洞察,用户Query,和数据集的描述(类似DB Schema),来选择一条洞察结果来进一步分析。
- 意图选择任务:如何分析以上洞察,这里分了三个意图,分别对应以上的3个Agent,Understand-QuickInsight, Summarize-MetaInsight, Explain-XInsight。大模型会基于用户query,以上选择的洞察内容,来选择一个Agent来继续分析
- 洞察选择:基于Agent新产生的多个数据洞察,如果LLM判断无法回答用户问题,则会选择一个洞察继续分析
- 报告生成:最后基于TopK数据洞察生成报告来解答用户问题
在最后筛选保留Top-K洞察的部分,论文还加入了Ranking环节,说是排序但看实现上,更像是消重+相似度过滤+打散。
- 首先洞察之间两两消重,如果A洞察包含B洞察的内容,则删除B洞察
- 其次是相似度过滤,会过滤和用户提问关联较低的洞察。不过这里其实有些存疑,因为洞察存在维度下钻和多维度对比,似乎感觉相似度不太合适作为过滤标准。
- 最后是打散策略,是为了降低洞察之间的相似度,提高最终内容的丰富度。这里使用了以下的二阶近似打分的策略如下,其中|I|是每条洞察的有用性打分,交集打分是两条洞察有用性的最小值*洞察重叠度,整体策略是为了提高TopK洞察整体包含的信息量
最终是InsightPilot生成的报告效果,以及支持用户对报告内容的每个段落,进行数据验证,当点击第一个段落Inspire Me时会生成对应段落相关的数据图表(右图)。老实说只看这个Demo,效果有些惊艳,不过真正厉害的是上面的三个洞察引擎,LLM只是大自然的搬运工和文案工作者。
想看更全的大模型相关论文梳理·微调及预训练数据和框架·AIGC应用,移步Github >> DecryPrompt