數勢科技研發的數據資產和數據分析相關產品，主要面向零售和金融企業，幫助其進行業務語義層資產構建，為企業提供基于大模型增強的數據分析 AI Agent、智能指標平臺、智能標簽平臺及智能營銷平臺，從而助力企業提升數字化決策能力，推動企業數字化升級。本文將分享如何基于大模型能力，疊加指標和標簽平臺能力，構建企業內智能數據分析產品。

一、企業經營分析的難點和挑戰

企業內部的數據分析涉及到諸多方面，包括：加工制作報表；基于數據發現異常因素，開發人員需要通過 SQL 或算法去做多維異常檢測；進一步挖掘異常背后的原因，又需要因果推斷或者歸因洞察等算法；分析之后還需要撰寫數據分析報告。

早期的企業經營分析主要是基于數據庫進行開發，通過寫 SQL 或者 Python 等編碼方式實現，開發門檻很高，企業內部受眾大約只有 1% 左右。隨著 BI 時代的到來，利用無代碼化平臺，可以在平臺上拖拉拽，通過業務規則和業務邏輯配置的方式，快速生成報表和可視化展示，得到想要的結論。然而使用 BI 的人要有業務分析思維，同時熟悉產品和配置，這些要求也無法推廣到一線業務人員，因此受眾人群在企業內部大概僅有 15% 到 20%。企業內部其余的人想看數據做決策就需要提需求，經過層層傳遞，最后通過業務分析師幫助得到想要的結果。

因此，業務團隊的痛點是在洞察數據時需要在一系列的鏈路層層傳遞需求，看到數據和結論需要很長時間的等待。而數據開發人員的痛點則是需要每天把時間和精力投入到開發無限的報表之中。因此我們希望利用智能分析相關產品來解決這些痛點。

智能分析需求大概可以總結為 5 個范式，面臨諸多挑戰：

• 最近 7 天 XX 產品的訂單總量多少？這種需求需要找到時間范圍、維度以及指標字段，比如訂單總量。
• XX 產品今年累計賣了多少？人通過語言提問有時會語義模糊，“賣了多少”可能指銷售量、訂單量、銷售額，大模型對這句話進行翻譯時，很難找到背后的字段和含義。
• 今年 XX 品牌在國內和海外的整體銷量是多少？這個需求可能涉及多表查詢，比如國內和國外分別有一張數據表，就需要通過 join 關聯關系把兩個銷量字段取出來。如何通過語言去實現跨表的關聯是一個挑戰。
• XX 品牌最近 3 個月國內銷量最好的產品哪一款？每個產品平均每月銷量多少？用戶一句話的需求可能會有多個任務，這個示例是兩段式的任務，第一個要先找到國內前三個月銷量最好的產品，然后再找到這個產品平均每個月銷量是多少。
• 華北地區 XX 的銷量月環比為什么下降了？這個需求是一個隱含性假設任務，要先找到華北地區 XX 的銷量的月環比，再判斷月環比下降值，再基于下降值，通過歸因算法去做一些維度歸因。用戶可能還會需要根據歷史銷量值生成折線圖等圖表生成任務。這些任務單純通過 NLP2SQL 是難以實現的。

用戶的一句話需求任務具有多樣性，利用大模型，可以把用戶的需求任務拆成多個子任務，再讓每個子任務根據對應的能力需求做串行或者并行的調用。Agent 的工作就是將任務拆解，拆解后的每個任務是一個最簡單的原子任務，再調用具有對應能力的 function 或 API，返回執行結果，再根據結果反思是否需要做進一步的拆解，或者重新規劃求解。這就是 Agent 為數據分析領域帶來的幫助。

二、智能分析的路線選擇

智能分析有不同的實現路線：

• NLP2SQL：本質是取數，大模型通過微調或 SQL 訓練集生成 SQL。當前更多地會結合 RAG，把生成式的任務改成填充式的任務，在生產中發現大模型做填空要比做生成穩定性更高，其生成穩定性會受到多方面影響，固定住 temperature 或隨機種子，模型在生成 100 個 token 之后隨機性會增加，大模型網絡間的梯度傳遞也會有隨機性波動，導致生成的 token 波動。在 SQL 生成時也會面臨一些問題，如何結合一系列衍生的能力，比如基于指標的歸因洞察、異常檢測以及制作可視化報告和圖表，還需要給到大模型各表描述，讓大模型去找到多表之間的關聯關系，大模型在判斷表之間關系方面的穩定性會相對不足。
• NLP2API：把數據語義化封裝到 API。其本質也是做填空題，確定 k 值之后根據 k 的描述去填充其對應的 value，API 能把產品功能里復雜的邏輯封裝到 API，大模型只需要把用戶的語句 NLP2API，這種方式穩定性會更高。
• NLP2Python：開發時用 code 的靈活性很高，code 可以突破 SQL 本身的一些局限性，通過 Python 代碼可以生成算法預測和歸因的模塊，但同時也會帶來穩定性的不足。但隨著大模型代碼生成能力的增強，這種方式的能力也會逐步增強。

上圖示例是 NLP2SQL 的實現路徑，左邊是來自 OpenAI 的一個標準的生成 SQL 的示例，但是在實際生產過程中并非如此簡單。先指定一個系統指令 system prompt，還要告訴模型擁有的數據庫以及數據庫中表的具體描述，再基于標準的 SQL 拼接規范，生成 SQL。

同時，還要根據問題去設計 prompt 模板，并且要對 NLP2SQL 模型微調、評測和訓練。評測也存在挑戰，如何定義 SQL 生成的準確度，如何評估 SQL 的可執行性？SQL 的可執行性還需要考慮性能，不能只是可以執行出結果，也要評估執行出結果的耗時，才能達到企業級應用的標準。

NLP2API 是先定義好數據分析相關 API，比如 BI 系統和指標平臺的 API 和算法 API 等很多 API 池子，這樣就能通過 API 路徑實現搜索，通過搜索，找到合適的 API，再把用戶的語句翻譯成 API 參數完成對 API 的調用。這種方式的好處是 API 自帶校驗性，并且通過工程化而不是通過大模型生成的方式可以實現性能較好的 SQL 結果生成。

如何定義 Semantic API？數據本身沒有語義，我們要通過工具和手段對已有數據定義出其語義。

• 語義統一：大模型對語義理解相對比較好，但是模型學不到在企業內部的行業黑話和術語，所以需要增加企業內部的同義詞，幫助大模型去理解。
• 口徑統一：需要統一數據字段在企業內部的技術口徑和業務口徑，保證字段和描述之間的口徑統一。
• 權限統一：企業內部每個人或者不同部門能看到的數據應該不一樣，因為數據權限不一樣，在企業內部做數據要考慮權限統一問題并融合到語義層。

為什么要基于指標和標簽去做 NLP2API？

• 面向對象理解：指標和標簽中封裝了業務邏輯和口徑，其分層結構設計包含了很多過濾條件和表達式，模型不需要理解具體內容，而是將指標和標簽視為對象，面向對象去理解。
• 指標和標簽體系化設計：體系化設計增加了大模型召回命中率，因為每個指標層級下指標維度是少數的幾個，天然會有助于進行語義上的過濾， 使召回的范圍少且準，進而生成效果就比較準，所以指標體系輔助了語義理解召回的效果。
• 可解釋性高：解析結果可以通過要素反顯給用戶，相較于 SQL 更易被非技術人員理解。
• 衍生能力：通過指標體系可以衍生很多 API 或者 function 等分析能力（如歸因，預警，趨勢預測等），被大模型合理并無縫地銜接和調用。

上圖是上述三種實現路徑的優劣勢對比，在實際場景中需要根據具體情況去選擇。在表不是特別多邏輯不復雜的時候，可以采用 NLP2Code 和 NLP2SQL。當業務邏輯復雜時或表多時，要通過一種底座和手段把數據在工程層面上提前做聚合，再讓大模型更好地去理解。

三、如何設計經營分析 Agent

上圖展示了 SwiftAgent 的流轉鏈路。在用戶提出請求時，沒有完全拋棄 NLP2SQL 和 NLP2Code 的方式，我們通過一套意圖路由機制，在用戶 query 進來的每個節點做意圖判斷和路由，判斷是否能通過指標和標簽解決問題，在 Agent 機制下去做技能的采樣、元數據采樣、記憶采樣，即圍繞指標和標簽有哪些方式和 API 技能，元數據，以及歷史記憶。如果是指標和標簽之外的問題，我們會通過開放性的分析生成 SQL 的方式去做兜底。

上圖是 Agent 的簡要框架，不是每個問題需要通過 Agent 去做規劃和任務拆解，用戶的問題既有簡單又有復雜，而交互時效性要求較高，所以前期通過意圖識別機制，判斷問題類型是簡單還是復雜。針對簡單問題，就直接調用相關的技能做參數的 mapping 和解析。對于復雜問題，則通過 planner 機制，包括 ReAct 和 P&E，P&E 是做分步執行，沒有反思，而 ReAct 時間較長，每步做反思，通過之前任務的結果去做校正。此外，還利用 RAG 去做動態的 embedding 嵌入，以及做歷史的上下文反饋，告訴大模型 goodcase 和 badcase。

總結來說，它具有規劃反思能力、意圖路由能力、垂直領域調優能力。每個技能都要定義好描述，包括出參和入參，才能解析，之后拼接各項技能串行或者并行執行，匯總最終的結果，再通過 reward 分數判斷是否需要重新規劃路徑，如果是完成狀態，將結果發回給前端。

我們在設計 Agent 時遇到了以下難點：

1. 靜態規劃思路無法解決所有個性化提問方式

Planner 機制無法滿足千人千面的用戶個性化 query 實現。規劃方式有很多種，包括逐步思考分解法、P&E、批判法、假設法等。我們把每種方式形成原子 module，當用戶 query 請求時，通過判斷對應 query 應該選擇的思考 module，然后讓大模型基于選擇的思考方式組件，形成 planner 的 prompt，實現通過不同的思考方式執行任務的鏈路。因此，對應的解決方法是首先進行思考方式的選擇，然后基于用戶的 query 和思考方式對 prompt 做修正，最后基于修正后的 prompt 讓大模型做解析。另外，還引入動態的 Few-Shot 的方式引導大模型持續執行。

2. 任務規劃“穿越性”問題

指標分為原子指標、派生指標和衍生指標。比如用戶想要查詢過去一個月的累計銷售額，數據庫里可能既有原子指標銷售額，也有派生指標月累計銷售額，那么大模型如何生成規劃呢？如果只有月累計銷售指標，那只能生成上圖中第二種方式的規劃。如果兩個指標都有，可以規劃成兩個方式的任務，第一個是先查詢過去一個月每天的原子指標銷售額，然后再基于時間窗口累計求和，第二個是直接查詢最新時間一個月的月累計銷售額，這種情況下應該選擇哪種路徑去解決？有以下兩種解法，當前我們也在對比其效果：

• 第一種方式是基于指標樹關系設計，我們編排一個 DSL 模板，里面有 SUM 算子。當指標識別到月累積銷售額，口徑包含 SUM，就把 DSL 模板里的 SUM 算子去掉；而如果指標是銷售額就要用到 DSL 里的 SUM 算子。
• 第二種方式是在規劃時提前把已有的指標告訴大模型，它通過向量和關鍵詞召回等方式，返回相關的候選指標，再根據候選指標生成規劃路徑，一條規劃路徑是不穩定的，我們會生成多條規劃路徑，從中選擇最短可執行路徑，再拆分成具體的任務分步執行。

3. 提升工具調用的效果

接下來探討如何提高 API 的調用能力。如果每次通過語言去解析到對應的參數，難以保證穩定性。我們的基座模型是針對一些 case 去生成相應的結果，下一次它能夠遵循相應的結果去解析，這種方法穩定性會比較高。告訴大模型工具的 description 和出參、入參，生成 query，再基于這些 query 正向解析去調用工具得到對應的結果，這樣就會產生很多正負樣例，存到數據庫里，下一次調用相應的工具時，可以索引到對應工具的樣例，把樣例動態去引入到 prompt 里，再通過 prompt 調優的方式學習，從而保證執行的準確性。

4. 時間推理效果不穩定

大模型時間推理效果極其不穩定，主要原因包括：

• 語義割裂問題：比如“幫我看一下去年的銷售額是多少，按月呈現”，大模型理解時間實體時可能會忽略掉后面“按月呈現”的描述，而解析成 2023 年。
• 時間推理判斷：比如“6 月第 3 周”，大模型可能先去推理 6 月第 3 周是哪一周，具體是幾號之間，經常會存在解析的日期不準的情況。
• 陳述模糊：比如“幫我看一下最近幾天的銷售額”，最近幾天表述模糊，大模型可能今天返回最近三天，明天又會返回最近 7 天，回答結果不穩定。
• 歧義沖突：比如“幫我查看一下 6 月前兩天的銷售額是多少”，大模型可能有三種理解結果：6 月 1 號和 6 月 2 號，5 月 30 號和 5 月 31 號，或者是 5 月 31 號和 6 月 1 號。

大模型這種解析結果的不穩定，會使用戶感覺效果不好，不利于用戶的使用體驗。

針對上述問題，我們的解決思路是，先以規則去保障穩定性，開發一系列包括農歷日和公歷日日期識別的相關算子，通過規則性實體抽取，把實體通過規則解析成具體的年月日。抽取時間實體時，讓大模型去判斷規則抽取的實體是否能夠去滿足用戶的 query。經測試，這樣做能使準確性達到 98% 以上。大模型判斷能滿足時，用時間解析 Parser 解析成具體的時間，對于剩下 2% 的 badcase，大模型先去抽取時間的實體，再基于實體去解析成對應的時間，而不是讓大模型直接端到端地把用戶的 query 去解析成具體日期。

5. Agent 記憶緩存和命中較難

大模型每次做新題不會保證答案的穩定，而舊題可以參考歷史答案。Agent 是產品里的一個機制，并不是算法的能力。所以我們通過用戶以往問詢的一些樣例，去解析正確要素，然后復用到相似的樣例上。除了歷史問詢記憶，我們還有知識庫里的記憶，通過記憶對用戶的 query 做標準化的改寫。實驗發現如果 query 改寫成標準化的版本大模型會理解得非常準確，實現標準問詢，標準出結果，從而保證穩定性。Query 改寫同樣也遵循通用公式：最近性、相關性和重要性。

上圖是我們產品的架構，核心優勢包括：

• 統一語義層的構建：即指標和標簽，確保數據分析準確可靠。
• 用戶可干預：用戶的每一次的干預都是對模型的一種反饋，對大模型的迭代和微調，以及產品邏輯和業務規則的迭代都有幫助。
• 多源異構數據鏈接：分析不僅需要結構化的數據分析，還需要知道分析之后的決策和行動，可搭配知識庫，把結構和非結構化數據串聯起來，通過企業內部的知識文檔，在分析洞察完數據產生的原因后告訴業務人員下一步的行動。
• 持續反思學習：讓系統更懂用戶。
• 數據計算加速引擎：在 API 內部通過工程化手段做 SQL 的底層優化，讓查詢性能得到極大的提升。

四、企業經營分析的展望和思考

對經營分析 Agent 的未來發展有如下一些展望和思考：

• 大模型從能聽懂人話升級為幫人說話：我們當前對 chatbot 是被動式使用，我問你答的模式。在未來，我們希望大模型能夠主動去幫人，構思業務分析的場景，根據使用者用戶畫像，以往的提問歷史，角色部門權限，可以每天生成目標和任務，用戶點擊確認，整個 Agent 到后臺自動運行，最終跑出來用戶需要的分析報告，還能幫助用戶額外產出其它有洞見的分析報告和結論。
• 能和人一樣總結歸納升級為總結之后自動決策：數據分析是為了發現數據背后的本質和原因，再進行下一步的行動。Agent 的本質是連接，Agent 的方式，能夠把企業內部的系統工具和產品連接起來，做到整體互聯互通，進行各種決策和行動。
• 能像人一樣規劃升級為像業務專家一樣規劃：Agent 初期階段，還無法達到專家的規劃能力，未來希望它能夠像專家一樣去幫助用戶解決問題。

未來通過上述三個方向的升級，能夠讓產品基于大模型的工具和能力更有價值。

五、問答環節

Q1：企業用到您介紹的分析產品之后，數據分析人員的職業定位會有什么改變？

A1：產品并不是替代分析人員，而是作為一個助手，幫助其完成日常大量枯燥的、沒有技術含量的報表開發工作，而分析人只需要聚焦于更復雜的工作，比如像專家一樣做更深度的洞察和分析。

Q2：醫療行業的企業使用你們的產品，怎么確保數據的安全性？

A2：首先該產品并非為醫療行業訂制，而是用于企業經營分析。從產品本身來看，可私有化部署，所以數據可以不出企業，也就不存在數據出域的安全性問題。

Q3：Agent 應用開發是定制化的，還是依據幾個主要的成熟的 Agent 開發框架來開發，您更傾向于哪種方式？

A3：我傾向于第 2 種，做 Agent 開始要參考一些開源的 Agent 框架，現在已經公布了十幾種 Agent 開源框架，一定會有一種是適合你當前場景的，然后基于這種框架的思路，再去做針對性的業務的嵌套和開發。我們會參考多種框架，因為每個開源框架都有各自的優劣勢。AutoGPT 是大模型 Agent 鼻祖，但存在不穩定的問題。單 Agent 可以參考 ReAct 的方式，多 Agent 可以參考阿里的通義千問 Agent，或者國外的一些開源框架。需要根據具體的場景去選最適合的。

Q4：在產品和技術上怎么去引導用戶更高質量地提問？

A4：內部技術層面，query 改寫讓用戶無感知是最好的，但是難度比較高。產品引導層面其實也包含很多技術，比如搜索聯想，提供一些標準問題供用戶參考；又比如要素的聯想，用戶問“賣了多少”，產品可以給出銷售額、訂單量等選擇，讓用戶去選一個。搜索聯想的方式可能效果會更好，因為給出的是一個完整的問題，而不會像要素聯想那樣打斷用戶輸入思路。

Q5：怎么能讓用戶相信返回的數據是準確的？

A5：這里包括兩層，第一層是相信大模型翻譯出來的是準確的，第二層是基于翻譯出來的取的數字結果是準確的。第一層是通過要素的反寫，讓用戶知道把他的提問翻譯成了哪些要素的組合，從而增加可信度。第二層在做指標和標簽開發的時候，從數倉到平臺里的數據核準和校驗要做準確，這是和大模型本身沒有關系的基礎工作。

Q6：Agent 現在是內部自己訓練，還是外面公共的大模型。在一些解決方案上發現對大模型本身的能力是要有一定要求的。如果想要在一個私有環境中使用，是需要自己部署一個大模型，還是可以配其他大模型。

A6：有兩方面考慮，第一個是在部署時需要考慮企業內部可承擔的算力成本，百億左右的模型成本相對來說比較低，但超過 500 億以上的成本相對來說就會比較高，這要看企業的選擇。根據我們的經驗，300 億以下要靠微調，300 億尤其 500 億以上，靠 prompt 微調就可以。500 億以上通過 prompt 和工程的方式能夠避免很多錯誤的情況。但是在 500 億以下，可能有很多情況是工程手段無法避免的，這種情況下需要靠調，而部署方式要看客戶對資源的要求。

Q7：SwiftAgent 流轉框架里有 check system 和 retry system，它們都有最終的 output 分支，其執行標準是什么？

A7：Check system 是我們內部的一個重試機制，針對于不同的情況，比如當它發現找不到對應的指標，或者用指標的 API 邏輯回答的結果是錯的，或者和用戶提問的要素不匹配的時候，我們會通過 SQL 的方式直接侵入到底層模型表以下，通過 SQL 生成的方式，去檢索出來相應的結果。其中，判斷用戶的 query 和解析的要素是否一致，是由大模型來完成的。此外，還有很多工程化手段，比如 API 底層引擎里直接有代碼報錯，此時也需要重試的機制。

對于 retry system，一部分會到 Agent 重試，還有一部分會到 SQL generate。因為 Agent 部分融合了標簽和指標，而生成 SQL 是一種兜底，它是一個單獨的線路和技能，SQL 本身生成效果也有不穩定，一般也會讓它重試，但是會設置最大重試次數。

Q8：用戶對數據的信任問題，除了用數據治理去解決一些事情之外，還有什么其他方式解決嗎？

A8：這個只能保證底層數據的準確，數據治理是必不可少的。

Q9：產品的優勢之一是用戶可干預，在哪些環節是用戶比較適合介入干預的？干擾和輔助提問的臨界點應該怎么把握？

A9：其實是召回和生成的平衡。比如大模型召回的字段生成的結果，你判斷它生成的結果在你之前的候選集里分數排得并不是特別靠前，但是大模型選擇了它，那你就要反問，同時要附上分數較高那幾個，這個是要根據具體的業務場景去做一個抉擇。出現沖突矛盾的時候，就需要去做反問。除了反問，還有對結果的贊和踩也可視為一種用戶干預，但其實是對結果的校準。