LLM Agent之数据分析领域的应用

数据分析：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

• LLM时代，探索式数据分析的升级之路有哪些新助攻？

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来生成数据分析报告。

这里大模型主要负责：初始化->洞察选择->意图选择->洞察选择->意图选择....->报告生成

1. 初始化任务：会先调用QuickInsight生成数据集的基础洞察，然后使用Prompt，让LLM基于Agent返回的多条数据洞察，用户Query，和数据集的描述（类似DB Schema）,来选择一条洞察结果来进一步分析。

2. 意图选择任务：如何分析以上洞察，这里分了三个意图，分别对应以上的3个Agent，Understand-QuickInsight, Summarize-MetaInsight, Explain-XInsight。大模型会基于用户query，以上选择的洞察内容，来选择一个Agent来继续分析

3. 洞察选择：基于Agent新产生的多个数据洞察，如果LLM判断无法回答用户问题，则会选择一个洞察继续分析

4. 报告生成：最后基于TopK数据洞察生成报告来解答用户问题

在最后筛选保留Top-K洞察的部分，论文还加入了Ranking环节，说是排序但看实现上，更像是消重+相似度过滤+打散。

1. 首先洞察之间两两消重，如果A洞察包含B洞察的内容，则删除B洞察

2. 其次是相似度过滤，会过滤和用户提问关联较低的洞察。不过这里其实有些存疑，因为洞察存在维度下钻和多维度对比，似乎感觉相似度不太合适作为过滤标准。

3. 最后是打散策略，是为了降低洞察之间的相似度，提高最终内容的丰富度。这里使用了以下的二阶近似打分的策略如下，其中|I|是每条洞察的有用性打分，交集打分是两条洞察有用性的最小值*洞察重叠度，整体策略是为了提高TopK洞察整体包含的信息量

最终是InsightPilot生成的报告效果，以及支持用户对报告内容的每个段落，进行数据验证，当点击第一个段落Inspire Me时会生成对应段落相关的数据图表（右图）。老实说只看这个Demo，效果有些惊艳，不过真正厉害的是上面的三个洞察引擎，LLM只是大自然的搬运工和文案工作者。

几个月前我们就聊过RAG的经典方案解密Prompt系列14. LLM Agent之搜索应用设计。前几天刚看完openAI在DevDay闭门会议上介绍的RAG相关的经验，有些新的感悟，借此机会再梳理下RAG相关的优化方案。推荐直接看原视频（外网）A Survey of Techniques for Maximizing LLM Performance

RAG最关键的一环其实不是LLM而是相关内容的召回，作为大模型推理的上文，优秀的内容召回应该满足以下条件：

• 多样性和召回率：召回的内容要可以回答问题，并且内容丰富度，包括同一问题多个观点，多角度

• 相关性和准确率：召回内容和问题相关，总不能召回100篇里面只有2篇和问题有关

• 一致性和低冲突：召回内容间的观点一致性较高

• 更高要求：高时效性，权威性，观点完整性，内容重复度低

这里不妨借鉴前人经验，参考搜索的主流框架：Query理解和扩展 -> 多路召回 -> 合并排序 -> 重排和打散。过去几个月RAG的论文也像是把传统搜索的方案，使用LLM轮番做了一遍范式更新。本章我们先围绕召回内容的多样性唠上两句。

直接使用用户Query进行向量检索，召回率往往不高，原因有以下几个

• query较短，本身信息有限

• 短文本的embedding效果较差

• query短文本向量和document长文本向量存在空间表征差异

• 用户对自己想问的内容比较模糊

• 用户的query提问可能需要多个方向的信息聚合才能回答

以上问题其实覆盖了两个点：Query本身包含信息的多样性，搜索索引的多样性。下面我们结合新老论文，以及langchain新增的一些功能，来分别介绍~