在之前的 LLM Agent+DB 的章節(jié)我們已經(jīng)談?wù)撨^如何使用大模型接入數(shù)據(jù)庫并獲取數(shù)據(jù)，這一章我們聊聊大模型代理在數(shù)據(jù)分析領(lǐng)域的應(yīng)用。數(shù)據(jù)分析主要是指在獲取數(shù)據(jù)之后的數(shù)據(jù)清洗，數(shù)據(jù)處理，數(shù)據(jù)建模，數(shù)據(jù)洞察和數(shù)據(jù)可視化的步驟。可以為經(jīng)常和數(shù)據(jù)打交道，但是并不需要太過艱深的數(shù)據(jù)分析能力的同學(xué)提供日常工作的支持，已看到很多 BI 平臺在嘗試類似的方案。這里我們聊兩篇論文：Data-Copilot 和 InsightPilot, 主要參考一些有意思的思路~

數(shù)據(jù)分析：Data-Copilot

• paper: Data-Copilot: Bridging Billions of Data and Humans with Autonomous Workflow
• github: https://github.com/zwq2018/Data-Copilot

先介紹下浙大提出的已擴展的數(shù)據(jù)分析框架，支持多種金融數(shù)據(jù)類型的查詢，數(shù)據(jù)處理，簡單建模，和數(shù)據(jù)可視化。Data-copilot 以金融領(lǐng)域的數(shù)據(jù)分析為例，提供了一套可以簡單基于已有數(shù)據(jù)進行擴展生成的數(shù)據(jù)分析框架。

整個框架分成兩個部分，基于大模型的 API 生成和基于生成 API 的 llm 任務(wù)規(guī)劃和執(zhí)行。其實說復(fù)雜也不復(fù)雜，數(shù)據(jù)分析任務(wù)里面幾個核心的要素就是

• 分析啥：提問的實體，股票？債券？基金經(jīng)理？
• 分析哪段時間：數(shù)據(jù)的覆蓋范圍，一季度？今年？
• 用什么指標(biāo)：股票的收益率？債券利率？基金凈值？
• 如何分析：收益對比？價格漲跌？排名？
• 如何輸出：繪圖？表格？文本？

API生成

設(shè)計部分其實是使用大模型來構(gòu)建更符合上下文語義的 API 調(diào)用語句，以及 API 的輸入輸出。這部分代碼并未開源......所以我們只依據(jù)論文和腦補做簡單介紹。主要分成以下四個步驟

1. 生成更多的用戶請求

API 的生成需要基于用戶會問什么樣的問題。而用戶的提問又是基于你有什么樣的數(shù)據(jù)。因此這里使用數(shù)據(jù)描述和人工編寫的種子提問作為上文，讓 LLM 生成更多的用戶提問。

2. 生成 API 調(diào)用語句

把以上生成的所有用戶提問，一個個輸入模型，使用以下 prompt 指令引導(dǎo) llm 生成完成一個數(shù)據(jù)分析任務(wù)，所需的多個步驟，以及每個步驟對應(yīng)的API 描述和偽代碼"Interface1={Interface Name: %s, Function description:%s, Input and Output:%s}"

3. 合并相似的 API 調(diào)用

每得到一個新的 API function，都會和已生成的 API function 配對后輸入模型，并使用以下指令讓大模型判斷兩個 function 是否功能相似可以合并為一個新的 API。例如把查詢 GDP 的 API 和查詢 CPI 的 API 合并為查詢 GDP_CPI 的 API。不過個人感覺這個方案時間和 token 開銷頗大，可能比較適合 online API 的在線構(gòu)建，在離線構(gòu)建時先基于 API 的描述進行聚類，然后每個 cluster 進行合并可能更經(jīng)濟實惠？

4. 為每個 API 生成對應(yīng)代碼

最后針對合并后的 API，使用大模型進行代碼生成。這里使用了 pandas DataFrame 作為數(shù)據(jù)處理，數(shù)據(jù)繪圖的數(shù)據(jù)交互格式。這里論文把工具調(diào)用分成了 5 個大類：數(shù)據(jù)獲取，數(shù)據(jù)處理，合并切片，建模和可視化。

看完以上整個 API 構(gòu)建流程，不難發(fā)現(xiàn)使用 llm 來自動生成 API 有以下幾個好處（不過估計完全自動化難度不小......）

• 節(jié)省人力
• 和 APE 的思路類似，大模型生成的指令更符合模型生成偏好，API 同理
• 當(dāng)前是離線批量生成，如果可以優(yōu)化為 online 的 API 生成的話，可以使得 API 具有動態(tài)可擴展性

API調(diào)用

獲得 API 之后，就是如何排列組合規(guī)劃 API 的執(zhí)行來回答用戶的提問/完成用戶的任務(wù)。這里的任務(wù)流同樣拆成了多個步驟：

意圖識別

第一步是意圖識別，這里其實融合了搜索中 query 預(yù)處理的幾個功能：

• 意圖識別用于縮小問題范圍提高后面 API 調(diào)用的準(zhǔn)確率
• 時效性模塊基于今天的日期和用戶提問，生成問題對應(yīng)的具體時間范圍（包括時間范圍標(biāo)準(zhǔn)化）
• 實體模塊用于定位問題的核心實體
• 輸出形式的判別是繪圖、表格還是文本輸出

論文把以上多個模塊融合成了基于 few-shot 的大模型改寫任務(wù)，會把用戶的提問改寫成一個新的具有明確時間區(qū)間，任務(wù)類型更加明確的文本，與其說是意圖識別，其實更像 query 改寫。如下

個人感覺意圖這里完全可以不基于大模型，或者可以用大模型造樣本再蒸餾到小模型上。以及整個意圖識別的模塊可以拆分成多個獨立且粒度更細(xì)的模塊，在金融領(lǐng)域至少可以拆分成大類資產(chǎn)實體的抽取對齊，針對不同資產(chǎn)類型的不同問題意圖的識別，以及獨立的時效性生成/判別模塊。意圖模塊直接影響后面的行為規(guī)劃，需要準(zhǔn)確率和執(zhí)行成功率都足夠高。

行為規(guī)劃

行為規(guī)劃模塊包含兩個步驟，第一步是任務(wù)拆解，以上改寫后的 query 會作為輸入，輸入任務(wù)拆解模塊。同樣是基于 few-shot 的大模型指令任務(wù)，把任務(wù)拆分成多個執(zhí)行步驟，每個步驟包括任務(wù)類型。

這里作者定義了 stock_task、fund_task、economic_task, visualization_task、financial_task 這 5 種任務(wù)，任務(wù)拆解類似 COT 把一個任務(wù)拆分成多個執(zhí)行步驟，但本質(zhì)上還是為了縮小 API的調(diào)用范圍。指令如下

基于以上任務(wù)選擇模塊每個步驟的任務(wù)類型，例如 stock_task，會有不同的 few-shot prompt 來指導(dǎo)模型針對該任務(wù)類型，生成多步的 API 調(diào)用，包括每一步調(diào)用的 API，輸入，輸出和返回值。行為規(guī)劃部分通用指令如下

行為規(guī)劃中一個有意思的點，是論文構(gòu)建的API中包含三種不同的執(zhí)行方式，串行操作常規(guī)單個輸入單個輸出，并行操作獲取一個證券的多個指標(biāo)數(shù)據(jù)，以及循環(huán)操作，類似 map 對多個輸入執(zhí)行相同的操作。以下是Data-Copilot的Demo

數(shù)據(jù)洞察：InsightPilot

• paper：Demonstration of InsightPilot: An LLM-EmpoweredAutomated Data Exploration System
• 相關(guān) paper：QuickInsights: Quick and Automatic Discovery of Insights fromMulti-Dimensional Data
• 相關(guān) paper：MetaInsight: Automatic Discovery of Structured Knowledge forExploratory Data Analysis
• 相關(guān) paper：XInsight: eXplainable Data Analysis Through The Lens ofCausality
• https://www.msra.cn/zh-cn/news/features/exploratory-data-analysis

InsightPilot與其說是一篇 paper，更像是一份微軟 BI 的產(chǎn)品白皮書。主打 EDA 數(shù)據(jù)洞察，和上面的 Data-copilot 拼在一起，也算是把數(shù)據(jù)分析最基礎(chǔ)工作涵蓋了。舉個數(shù)據(jù)洞察的栗子，最早在 UG 用戶增長部門工作時，每次 APP 活躍用戶下降了，數(shù)據(jù)分析組收到的任務(wù)就是趕緊去分析活躍用戶數(shù)據(jù)，看看到底用戶為啥流失了，是被競品搶走了，是最近上了什么新功能用戶不喜歡，還是之前活動拉來的用戶質(zhì)量不高留存較少，基于這些數(shù)據(jù)洞察，好制定下一步挽留流式用戶，激活沉默用戶的具體方案。

那如何發(fā)現(xiàn)數(shù)據(jù)中的異常點？一個基礎(chǔ)的操作就是對數(shù)據(jù)進行不同維度的拆分對比。例如把活躍用戶分成男女，老幼，不同城市，不同機型，渠道來源，不同閱讀偏好等等維度，觀察不同 subgroup 的用戶他們的活躍是否發(fā)生下降，下降比例是否相同，是否有某個維度的用戶組流失最顯著。這個維度拆分可以是平行維度，也可以是下鉆維度，對比方式可以是一階變化趨勢對比，也可以是波動率等二階趨勢的對比等等

微軟的實現(xiàn)方案其實是使用 LLM 把之前微軟已經(jīng)開發(fā)應(yīng)用到 BI 的三款數(shù)據(jù)洞察工具進行了組合串聯(lián)，這三款數(shù)據(jù)洞察工具分別是 QuickInsight，MetaInsight和XInsight。我們先簡單介紹下這三款工具，再看大模型要如何對數(shù)據(jù)分析工具進行組合串聯(lián)。

Insights 們

QuickInsight

QuickInisght 是最早也是功能最基礎(chǔ)的數(shù)據(jù)分析工具，它能快速發(fā)現(xiàn)多維數(shù)據(jù)中的 pattern。它的洞察數(shù)據(jù)單元由三個要素組成subject ? {????????????????(??)數(shù)據(jù)空間, ?????????????????? 拆分維度, ??????????????(??)觀察指標(biāo)}， 以下是{Los Angeles，Month，Sales}產(chǎn)生的數(shù)據(jù)洞察

QuickInsight，會先按不同維度，計算不同指標(biāo)得到多組數(shù)據(jù)。洞察部分則是預(yù)定了 12 種不同的數(shù)據(jù)分析方式，例如異常值，突變點，趨勢，季節(jié)性，相關(guān)性等等。每種洞察類型會基于顯著性和貢獻(xiàn)度進行綜合打分，排名靠前的應(yīng)該是單維度數(shù)據(jù)變化最顯著，且對整體影響較大的。

MetaInsight

QuickInsight的洞察主要基于單個洞察數(shù)據(jù)單元進行，MetaInsight可以聚合關(guān)聯(lián)多個洞察數(shù)據(jù)單元，產(chǎn)出更復(fù)雜，高級的數(shù)據(jù)洞察。簡單來說是在以上三元組數(shù)據(jù)洞察的基礎(chǔ)上，搜索不同的subsapce，以及measure，尋找具有相似數(shù)據(jù)洞察的三元組，并進行組合分析。繼續(xù)以上洛杉磯銷量數(shù)據(jù)的洞察，當(dāng)我們擴展subspace到其他城市的銷售數(shù)據(jù)時，MetaInsight會產(chǎn)出以下關(guān)聯(lián)分析。

XInsight

以上QuickInsight和MetaInsight都還停留在相關(guān)性數(shù)據(jù)分析的領(lǐng)域，而XInsight著眼在因果性分析，也算是前兩年很火的因果推斷方向。也就是我們不僅想知道手機里同時有快手和抖音APP的用戶，使用抖音的時間較短，還想知道到底是快手APP搶奪了用戶的時間，還是這部分用戶群體本身就屬于東看看西看看沒有固定偏好的群體。但真實世界中很難找到完全符合假設(shè)的因果推斷，因為哈哈沒有平行世界呀，因此只能通過一些控制變量，和數(shù)學(xué)建模的方案來近似模擬因果場景。感興趣的同學(xué)可以看過來因果推斷的春天

以下的案例中，同樣是按月份維度進行拆分，航班延誤時間作為指標(biāo)。當(dāng)在整個數(shù)據(jù)上進行洞察時會發(fā)現(xiàn)5月的延誤時間比11月高了很多，但當(dāng)控制變量當(dāng)日是否下雨時，會發(fā)現(xiàn)在下雨天5月的航班延誤時間是要低于11月的，因此5月份更高的降雨率可能可以解釋5月更高的航班延誤時間。

LLM Pipeline

InsightPilot就是基于以上三個數(shù)據(jù)分析引擎，使用大模型進行串聯(lián)，來完成用戶的數(shù)據(jù)洞察需求。還是那個觀點，LLM+Agent的組合中，真正重要的是Agent，LLM只是負(fù)責(zé)基于上下文語義來選擇最合適的Agent，并基于Agent的返回內(nèi)容來決定下一步的操作，說白了就是串場子的，當(dāng)然最后也需要LLM來生成數(shù)據(jù)分析報告。

這里大模型主要負(fù)責(zé)：初始化->洞察選擇->意圖選擇->洞察選擇->意圖選擇....->報告生成

1. 初始化任務(wù)：會先調(diào)用QuickInsight生成數(shù)據(jù)集的基礎(chǔ)洞察，然后使用Prompt，讓LLM基于Agent返回的多條數(shù)據(jù)洞察，用戶Query，和數(shù)據(jù)集的描述（類似DB Schema）,來選擇一條洞察結(jié)果來進一步分析。
2. 意圖選擇任務(wù)：如何分析以上洞察，這里分了三個意圖，分別對應(yīng)以上的3個Agent，Understand-QuickInsight, Summarize-MetaInsight, Explain-XInsight。大模型會基于用戶query，以上選擇的洞察內(nèi)容，來選擇一個Agent來繼續(xù)分析
3. 洞察選擇：基于Agent新產(chǎn)生的多個數(shù)據(jù)洞察，如果LLM判斷無法回答用戶問題，則會選擇一個洞察繼續(xù)分析
4. 報告生成：最后基于TopK數(shù)據(jù)洞察生成報告來解答用戶問題

在最后篩選保留Top-K洞察的部分，論文還加入了Ranking環(huán)節(jié)，說是排序但看實現(xiàn)上，更像是消重+相似度過濾+打散。

1. 首先洞察之間兩兩消重，如果A洞察包含B洞察的內(nèi)容，則刪除B洞察
2. 其次是相似度過濾，會過濾和用戶提問關(guān)聯(lián)較低的洞察。不過這里其實有些存疑，因為洞察存在維度下鉆和多維度對比，似乎感覺相似度不太合適作為過濾標(biāo)準(zhǔn)。
3. 最后是打散策略，是為了降低洞察之間的相似度，提高最終內(nèi)容的豐富度。這里使用了以下的二階近似打分的策略如下，其中|I|是每條洞察的有用性打分，交集打分是兩條洞察有用性的最小值*洞察重疊度，整體策略是為了提高TopK洞察整體包含的信息量

最終是InsightPilot生成的報告效果，以及支持用戶對報告內(nèi)容的每個段落，進行數(shù)據(jù)驗證，當(dāng)點擊第一個段落Inspire Me時會生成對應(yīng)段落相關(guān)的數(shù)據(jù)圖表（右圖）。老實說只看這個Demo，效果有些驚艷，不過真正厲害的是上面的三個洞察引擎，LLM只是大自然的搬運工和文案工作者。

想看更全的大模型相關(guān)論文梳理·微調(diào)及預(yù)訓(xùn)練數(shù)據(jù)和框架·AIGC應(yīng)用，移步Github >> DecryPrompt

總結(jié)

以上是生活随笔為你收集整理的解密Prompt系列19. LLM Agent之数据分析领域的应用：Data-Copilot & InsightPilot的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。