在之前的 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來生成資料分析報告。
這裡大模型主要負責：初始化->洞察選擇->意圖選擇->洞察選擇->意圖選擇....->報告生成
- 初始化任務：會先呼叫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