在之前的 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-Empowered Automated Data Exploration System 相关 paper：QuickInsights: Quick and Automatic Discovery of Insights from Multi-Dimensional Data 相关 paper：MetaInsight: Automatic Discovery of Structured Knowledge for Exploratory Data Analysis 相关 paper：XInsight: eXplainable Data Analysis Through The Lens of Causality 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 ≔ {
