在之前的 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 ? {????????????????(??)數據空間, ?????????????????? 拆分維度, ??????????????(??)觀察指標}， 以下是{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只是大自然的搬運工和文案工作者。

想看更全的大模型相關論文梳理·微調及預訓練數據和框架·AIGC應用，移步Github >> DecryPrompt

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。