數(shù)勢(shì)科技研發(fā)的數(shù)據(jù)資產(chǎn)和數(shù)據(jù)分析相關(guān)產(chǎn)品，主要面向零售和金融企業(yè)，幫助其進(jìn)行業(yè)務(wù)語(yǔ)義層資產(chǎn)構(gòu)建，為企業(yè)提供基于大模型增強(qiáng)的數(shù)據(jù)分析 AI Agent、智能指標(biāo)平臺(tái)、智能標(biāo)簽平臺(tái)及智能營(yíng)銷(xiāo)平臺(tái)，從而助力企業(yè)提升數(shù)字化決策能力，推動(dòng)企業(yè)數(shù)字化升級(jí)。本文將分享如何基于大模型能力，疊加指標(biāo)和標(biāo)簽平臺(tái)能力，構(gòu)建企業(yè)內(nèi)智能數(shù)據(jù)分析產(chǎn)品。

一、企業(yè)經(jīng)營(yíng)分析的難點(diǎn)和挑戰(zhàn)

企業(yè)內(nèi)部的數(shù)據(jù)分析涉及到諸多方面，包括：加工制作報(bào)表；基于數(shù)據(jù)發(fā)現(xiàn)異常因素，開(kāi)發(fā)人員需要通過(guò) SQL 或算法去做多維異常檢測(cè)；進(jìn)一步挖掘異常背后的原因，又需要因果推斷或者歸因洞察等算法；分析之后還需要撰寫(xiě)數(shù)據(jù)分析報(bào)告。

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

因此，業(yè)務(wù)團(tuán)隊(duì)的痛點(diǎn)是在洞察數(shù)據(jù)時(shí)需要在一系列的鏈路層層傳遞需求，看到數(shù)據(jù)和結(jié)論需要很長(zhǎng)時(shí)間的等待。而數(shù)據(jù)開(kāi)發(fā)人員的痛點(diǎn)則是需要每天把時(shí)間和精力投入到開(kāi)發(fā)無(wú)限的報(bào)表之中。因此我們希望利用智能分析相關(guān)產(chǎn)品來(lái)解決這些痛點(diǎn)。

智能分析需求大概可以總結(jié)為 5 個(gè)范式，面臨諸多挑戰(zhàn)：

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

用戶的一句話需求任務(wù)具有多樣性，利用大模型，可以把用戶的需求任務(wù)拆成多個(gè)子任務(wù)，再讓每個(gè)子任務(wù)根據(jù)對(duì)應(yīng)的能力需求做串行或者并行的調(diào)用。Agent 的工作就是將任務(wù)拆解，拆解后的每個(gè)任務(wù)是一個(gè)最簡(jiǎn)單的原子任務(wù)，再調(diào)用具有對(duì)應(yīng)能力的 function 或 API，返回執(zhí)行結(jié)果，再根據(jù)結(jié)果反思是否需要做進(jìn)一步的拆解，或者重新規(guī)劃求解。這就是 Agent 為數(shù)據(jù)分析領(lǐng)域帶來(lái)的幫助。

二、智能分析的路線選擇

智能分析有不同的實(shí)現(xiàn)路線：

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

上圖示例是 NLP2SQL 的實(shí)現(xiàn)路徑，左邊是來(lái)自 OpenAI 的一個(gè)標(biāo)準(zhǔn)的生成 SQL 的示例，但是在實(shí)際生產(chǎn)過(guò)程中并非如此簡(jiǎn)單。先指定一個(gè)系統(tǒng)指令 system prompt，還要告訴模型擁有的數(shù)據(jù)庫(kù)以及數(shù)據(jù)庫(kù)中表的具體描述，再基于標(biāo)準(zhǔn)的 SQL 拼接規(guī)范，生成 SQL。

同時(shí)，還要根據(jù)問(wèn)題去設(shè)計(jì) prompt 模板，并且要對(duì) NLP2SQL 模型微調(diào)、評(píng)測(cè)和訓(xùn)練。評(píng)測(cè)也存在挑戰(zhàn)，如何定義 SQL 生成的準(zhǔn)確度，如何評(píng)估 SQL 的可執(zhí)行性？SQL 的可執(zhí)行性還需要考慮性能，不能只是可以執(zhí)行出結(jié)果，也要評(píng)估執(zhí)行出結(jié)果的耗時(shí)，才能達(dá)到企業(yè)級(jí)應(yīng)用的標(biāo)準(zhǔn)。

NLP2API 是先定義好數(shù)據(jù)分析相關(guān) API，比如 BI 系統(tǒng)和指標(biāo)平臺(tái)的 API 和算法 API 等很多 API 池子，這樣就能通過(guò) API 路徑實(shí)現(xiàn)搜索，通過(guò)搜索，找到合適的 API，再把用戶的語(yǔ)句翻譯成 API 參數(shù)完成對(duì) API 的調(diào)用。這種方式的好處是 API 自帶校驗(yàn)性，并且通過(guò)工程化而不是通過(guò)大模型生成的方式可以實(shí)現(xiàn)性能較好的 SQL 結(jié)果生成。

如何定義 Semantic API？數(shù)據(jù)本身沒(méi)有語(yǔ)義，我們要通過(guò)工具和手段對(duì)已有數(shù)據(jù)定義出其語(yǔ)義。

• 語(yǔ)義統(tǒng)一：大模型對(duì)語(yǔ)義理解相對(duì)比較好，但是模型學(xué)不到在企業(yè)內(nèi)部的行業(yè)黑話和術(shù)語(yǔ)，所以需要增加企業(yè)內(nèi)部的同義詞，幫助大模型去理解。
• 口徑統(tǒng)一：需要統(tǒng)一數(shù)據(jù)字段在企業(yè)內(nèi)部的技術(shù)口徑和業(yè)務(wù)口徑，保證字段和描述之間的口徑統(tǒng)一。
• 權(quán)限統(tǒng)一：企業(yè)內(nèi)部每個(gè)人或者不同部門(mén)能看到的數(shù)據(jù)應(yīng)該不一樣，因?yàn)閿?shù)據(jù)權(quán)限不一樣，在企業(yè)內(nèi)部做數(shù)據(jù)要考慮權(quán)限統(tǒng)一問(wèn)題并融合到語(yǔ)義層。

為什么要基于指標(biāo)和標(biāo)簽去做 NLP2API？

• 面向?qū)ο罄斫猓褐笜?biāo)和標(biāo)簽中封裝了業(yè)務(wù)邏輯和口徑，其分層結(jié)構(gòu)設(shè)計(jì)包含了很多過(guò)濾條件和表達(dá)式，模型不需要理解具體內(nèi)容，而是將指標(biāo)和標(biāo)簽視為對(duì)象，面向?qū)ο笕ダ斫狻?/span>
• 指標(biāo)和標(biāo)簽體系化設(shè)計(jì)：體系化設(shè)計(jì)增加了大模型召回命中率，因?yàn)槊總€(gè)指標(biāo)層級(jí)下指標(biāo)維度是少數(shù)的幾個(gè)，天然會(huì)有助于進(jìn)行語(yǔ)義上的過(guò)濾， 使召回的范圍少且準(zhǔn)，進(jìn)而生成效果就比較準(zhǔn)，所以指標(biāo)體系輔助了語(yǔ)義理解召回的效果。
• 可解釋性高：解析結(jié)果可以通過(guò)要素反顯給用戶，相較于 SQL 更易被非技術(shù)人員理解。
• 衍生能力：通過(guò)指標(biāo)體系可以衍生很多 API 或者 function 等分析能力（如歸因，預(yù)警，趨勢(shì)預(yù)測(cè)等），被大模型合理并無(wú)縫地銜接和調(diào)用。

上圖是上述三種實(shí)現(xiàn)路徑的優(yōu)劣勢(shì)對(duì)比，在實(shí)際場(chǎng)景中需要根據(jù)具體情況去選擇。在表不是特別多邏輯不復(fù)雜的時(shí)候，可以采用 NLP2Code 和 NLP2SQL。當(dāng)業(yè)務(wù)邏輯復(fù)雜時(shí)或表多時(shí)，要通過(guò)一種底座和手段把數(shù)據(jù)在工程層面上提前做聚合，再讓大模型更好地去理解。

三、如何設(shè)計(jì)經(jīng)營(yíng)分析 Agent

上圖展示了 SwiftAgent 的流轉(zhuǎn)鏈路。在用戶提出請(qǐng)求時(shí)，沒(méi)有完全拋棄 NLP2SQL 和 NLP2Code 的方式，我們通過(guò)一套意圖路由機(jī)制，在用戶 query 進(jìn)來(lái)的每個(gè)節(jié)點(diǎn)做意圖判斷和路由，判斷是否能通過(guò)指標(biāo)和標(biāo)簽解決問(wèn)題，在 Agent 機(jī)制下去做技能的采樣、元數(shù)據(jù)采樣、記憶采樣，即圍繞指標(biāo)和標(biāo)簽有哪些方式和 API 技能，元數(shù)據(jù)，以及歷史記憶。如果是指標(biāo)和標(biāo)簽之外的問(wèn)題，我們會(huì)通過(guò)開(kāi)放性的分析生成 SQL 的方式去做兜底。

上圖是 Agent 的簡(jiǎn)要框架，不是每個(gè)問(wèn)題需要通過(guò) Agent 去做規(guī)劃和任務(wù)拆解，用戶的問(wèn)題既有簡(jiǎn)單又有復(fù)雜，而交互時(shí)效性要求較高，所以前期通過(guò)意圖識(shí)別機(jī)制，判斷問(wèn)題類(lèi)型是簡(jiǎn)單還是復(fù)雜。針對(duì)簡(jiǎn)單問(wèn)題，就直接調(diào)用相關(guān)的技能做參數(shù)的 mapping 和解析。對(duì)于復(fù)雜問(wèn)題，則通過(guò) planner 機(jī)制，包括 ReAct 和 P&E，P&E 是做分步執(zhí)行，沒(méi)有反思，而 ReAct 時(shí)間較長(zhǎng)，每步做反思，通過(guò)之前任務(wù)的結(jié)果去做校正。此外，還利用 RAG 去做動(dòng)態(tài)的 embedding 嵌入，以及做歷史的上下文反饋，告訴大模型 goodcase 和 badcase。

總結(jié)來(lái)說(shuō)，它具有規(guī)劃反思能力、意圖路由能力、垂直領(lǐng)域調(diào)優(yōu)能力。每個(gè)技能都要定義好描述，包括出參和入?yún)ⅲ拍芙馕?，之后拼接各?xiàng)技能串行或者并行執(zhí)行，匯總最終的結(jié)果，再通過(guò) reward 分?jǐn)?shù)判斷是否需要重新規(guī)劃路徑，如果是完成狀態(tài)，將結(jié)果發(fā)回給前端。

我們?cè)谠O(shè)計(jì) Agent 時(shí)遇到了以下難點(diǎn)：

1. 靜態(tài)規(guī)劃思路無(wú)法解決所有個(gè)性化提問(wèn)方式

Planner 機(jī)制無(wú)法滿足千人千面的用戶個(gè)性化 query 實(shí)現(xiàn)。規(guī)劃方式有很多種，包括逐步思考分解法、P&E、批判法、假設(shè)法等。我們把每種方式形成原子 module，當(dāng)用戶 query 請(qǐng)求時(shí)，通過(guò)判斷對(duì)應(yīng) query 應(yīng)該選擇的思考 module，然后讓大模型基于選擇的思考方式組件，形成 planner 的 prompt，實(shí)現(xiàn)通過(guò)不同的思考方式執(zhí)行任務(wù)的鏈路。因此，對(duì)應(yīng)的解決方法是首先進(jìn)行思考方式的選擇，然后基于用戶的 query 和思考方式對(duì) prompt 做修正，最后基于修正后的 prompt 讓大模型做解析。另外，還引入動(dòng)態(tài)的 Few-Shot 的方式引導(dǎo)大模型持續(xù)執(zhí)行。

2. 任務(wù)規(guī)劃“穿越性”問(wèn)題

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

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

3. 提升工具調(diào)用的效果

接下來(lái)探討如何提高 API 的調(diào)用能力。如果每次通過(guò)語(yǔ)言去解析到對(duì)應(yīng)的參數(shù)，難以保證穩(wěn)定性。我們的基座模型是針對(duì)一些 case 去生成相應(yīng)的結(jié)果，下一次它能夠遵循相應(yīng)的結(jié)果去解析，這種方法穩(wěn)定性會(huì)比較高。告訴大模型工具的 description 和出參、入?yún)?，生?query，再基于這些 query 正向解析去調(diào)用工具得到對(duì)應(yīng)的結(jié)果，這樣就會(huì)產(chǎn)生很多正負(fù)樣例，存到數(shù)據(jù)庫(kù)里，下一次調(diào)用相應(yīng)的工具時(shí)，可以索引到對(duì)應(yīng)工具的樣例，把樣例動(dòng)態(tài)去引入到 prompt 里，再通過(guò) prompt 調(diào)優(yōu)的方式學(xué)習(xí)，從而保證執(zhí)行的準(zhǔn)確性。

4. 時(shí)間推理效果不穩(wěn)定

大模型時(shí)間推理效果極其不穩(wěn)定，主要原因包括：

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

大模型這種解析結(jié)果的不穩(wěn)定，會(huì)使用戶感覺(jué)效果不好，不利于用戶的使用體驗(yàn)。

針對(duì)上述問(wèn)題，我們的解決思路是，先以規(guī)則去保障穩(wěn)定性，開(kāi)發(fā)一系列包括農(nóng)歷日和公歷日日期識(shí)別的相關(guān)算子，通過(guò)規(guī)則性實(shí)體抽取，把實(shí)體通過(guò)規(guī)則解析成具體的年月日。抽取時(shí)間實(shí)體時(shí)，讓大模型去判斷規(guī)則抽取的實(shí)體是否能夠去滿足用戶的 query。經(jīng)測(cè)試，這樣做能使準(zhǔn)確性達(dá)到 98% 以上。大模型判斷能滿足時(shí)，用時(shí)間解析 Parser 解析成具體的時(shí)間，對(duì)于剩下 2% 的 badcase，大模型先去抽取時(shí)間的實(shí)體，再基于實(shí)體去解析成對(duì)應(yīng)的時(shí)間，而不是讓大模型直接端到端地把用戶的 query 去解析成具體日期。

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

大模型每次做新題不會(huì)保證答案的穩(wěn)定，而舊題可以參考?xì)v史答案。Agent 是產(chǎn)品里的一個(gè)機(jī)制，并不是算法的能力。所以我們通過(guò)用戶以往問(wèn)詢的一些樣例，去解析正確要素，然后復(fù)用到相似的樣例上。除了歷史問(wèn)詢記憶，我們還有知識(shí)庫(kù)里的記憶，通過(guò)記憶對(duì)用戶的 query 做標(biāo)準(zhǔn)化的改寫(xiě)。實(shí)驗(yàn)發(fā)現(xiàn)如果 query 改寫(xiě)成標(biāo)準(zhǔn)化的版本大模型會(huì)理解得非常準(zhǔn)確，實(shí)現(xiàn)標(biāo)準(zhǔn)問(wèn)詢，標(biāo)準(zhǔn)出結(jié)果，從而保證穩(wěn)定性。Query 改寫(xiě)同樣也遵循通用公式：最近性、相關(guān)性和重要性。

上圖是我們產(chǎn)品的架構(gòu)，核心優(yōu)勢(shì)包括：

• 統(tǒng)一語(yǔ)義層的構(gòu)建：即指標(biāo)和標(biāo)簽，確保數(shù)據(jù)分析準(zhǔn)確可靠。
• 用戶可干預(yù)：用戶的每一次的干預(yù)都是對(duì)模型的一種反饋，對(duì)大模型的迭代和微調(diào)，以及產(chǎn)品邏輯和業(yè)務(wù)規(guī)則的迭代都有幫助。
• 多源異構(gòu)數(shù)據(jù)鏈接：分析不僅需要結(jié)構(gòu)化的數(shù)據(jù)分析，還需要知道分析之后的決策和行動(dòng)，可搭配知識(shí)庫(kù)，把結(jié)構(gòu)和非結(jié)構(gòu)化數(shù)據(jù)串聯(lián)起來(lái)，通過(guò)企業(yè)內(nèi)部的知識(shí)文檔，在分析洞察完數(shù)據(jù)產(chǎn)生的原因后告訴業(yè)務(wù)人員下一步的行動(dòng)。
• 持續(xù)反思學(xué)習(xí)：讓系統(tǒng)更懂用戶。
• 數(shù)據(jù)計(jì)算加速引擎：在 API 內(nèi)部通過(guò)工程化手段做 SQL 的底層優(yōu)化，讓查詢性能得到極大的提升。

四、企業(yè)經(jīng)營(yíng)分析的展望和思考

對(duì)經(jīng)營(yíng)分析 Agent 的未來(lái)發(fā)展有如下一些展望和思考：

• 大模型從能聽(tīng)懂人話升級(jí)為幫人說(shuō)話：我們當(dāng)前對(duì) chatbot 是被動(dòng)式使用，我問(wèn)你答的模式。在未來(lái)，我們希望大模型能夠主動(dòng)去幫人，構(gòu)思業(yè)務(wù)分析的場(chǎng)景，根據(jù)使用者用戶畫(huà)像，以往的提問(wèn)歷史，角色部門(mén)權(quán)限，可以每天生成目標(biāo)和任務(wù)，用戶點(diǎn)擊確認(rèn)，整個(gè) Agent 到后臺(tái)自動(dòng)運(yùn)行，最終跑出來(lái)用戶需要的分析報(bào)告，還能幫助用戶額外產(chǎn)出其它有洞見(jiàn)的分析報(bào)告和結(jié)論。
• 能和人一樣總結(jié)歸納升級(jí)為總結(jié)之后自動(dòng)決策：數(shù)據(jù)分析是為了發(fā)現(xiàn)數(shù)據(jù)背后的本質(zhì)和原因，再進(jìn)行下一步的行動(dòng)。Agent 的本質(zhì)是連接，Agent 的方式，能夠把企業(yè)內(nèi)部的系統(tǒng)工具和產(chǎn)品連接起來(lái)，做到整體互聯(lián)互通，進(jìn)行各種決策和行動(dòng)。
• 能像人一樣規(guī)劃升級(jí)為像業(yè)務(wù)專(zhuān)家一樣規(guī)劃：Agent 初期階段，還無(wú)法達(dá)到專(zhuān)家的規(guī)劃能力，未來(lái)希望它能夠像專(zhuān)家一樣去幫助用戶解決問(wèn)題。

未來(lái)通過(guò)上述三個(gè)方向的升級(jí)，能夠讓產(chǎn)品基于大模型的工具和能力更有價(jià)值。

五、問(wèn)答環(huán)節(jié)

Q1：企業(yè)用到您介紹的分析產(chǎn)品之后，數(shù)據(jù)分析人員的職業(yè)定位會(huì)有什么改變？

A1：產(chǎn)品并不是替代分析人員，而是作為一個(gè)助手，幫助其完成日常大量枯燥的、沒(méi)有技術(shù)含量的報(bào)表開(kāi)發(fā)工作，而分析人只需要聚焦于更復(fù)雜的工作，比如像專(zhuān)家一樣做更深度的洞察和分析。

Q2：醫(yī)療行業(yè)的企業(yè)使用你們的產(chǎn)品，怎么確保數(shù)據(jù)的安全性？

A2：首先該產(chǎn)品并非為醫(yī)療行業(yè)訂制，而是用于企業(yè)經(jīng)營(yíng)分析。從產(chǎn)品本身來(lái)看，可私有化部署，所以數(shù)據(jù)可以不出企業(yè)，也就不存在數(shù)據(jù)出域的安全性問(wèn)題。

Q3：Agent 應(yīng)用開(kāi)發(fā)是定制化的，還是依據(jù)幾個(gè)主要的成熟的 Agent 開(kāi)發(fā)框架來(lái)開(kāi)發(fā)，您更傾向于哪種方式？

A3：我傾向于第 2 種，做 Agent 開(kāi)始要參考一些開(kāi)源的 Agent 框架，現(xiàn)在已經(jīng)公布了十幾種 Agent 開(kāi)源框架，一定會(huì)有一種是適合你當(dāng)前場(chǎng)景的，然后基于這種框架的思路，再去做針對(duì)性的業(yè)務(wù)的嵌套和開(kāi)發(fā)。我們會(huì)參考多種框架，因?yàn)槊總€(gè)開(kāi)源框架都有各自的優(yōu)劣勢(shì)。AutoGPT 是大模型 Agent 鼻祖，但存在不穩(wěn)定的問(wèn)題。單 Agent 可以參考 ReAct 的方式，多 Agent 可以參考阿里的通義千問(wèn) Agent，或者國(guó)外的一些開(kāi)源框架。需要根據(jù)具體的場(chǎng)景去選最適合的。

Q4：在產(chǎn)品和技術(shù)上怎么去引導(dǎo)用戶更高質(zhì)量地提問(wèn)？

A4：內(nèi)部技術(shù)層面，query 改寫(xiě)讓用戶無(wú)感知是最好的，但是難度比較高。產(chǎn)品引導(dǎo)層面其實(shí)也包含很多技術(shù)，比如搜索聯(lián)想，提供一些標(biāo)準(zhǔn)問(wèn)題供用戶參考；又比如要素的聯(lián)想，用戶問(wèn)“賣(mài)了多少”，產(chǎn)品可以給出銷(xiāo)售額、訂單量等選擇，讓用戶去選一個(gè)。搜索聯(lián)想的方式可能效果會(huì)更好，因?yàn)榻o出的是一個(gè)完整的問(wèn)題，而不會(huì)像要素聯(lián)想那樣打斷用戶輸入思路。

Q5：怎么能讓用戶相信返回的數(shù)據(jù)是準(zhǔn)確的？

A5：這里包括兩層，第一層是相信大模型翻譯出來(lái)的是準(zhǔn)確的，第二層是基于翻譯出來(lái)的取的數(shù)字結(jié)果是準(zhǔn)確的。第一層是通過(guò)要素的反寫(xiě)，讓用戶知道把他的提問(wèn)翻譯成了哪些要素的組合，從而增加可信度。第二層在做指標(biāo)和標(biāo)簽開(kāi)發(fā)的時(shí)候，從數(shù)倉(cāng)到平臺(tái)里的數(shù)據(jù)核準(zhǔn)和校驗(yàn)要做準(zhǔn)確，這是和大模型本身沒(méi)有關(guān)系的基礎(chǔ)工作。

Q6：Agent 現(xiàn)在是內(nèi)部自己訓(xùn)練，還是外面公共的大模型。在一些解決方案上發(fā)現(xiàn)對(duì)大模型本身的能力是要有一定要求的。如果想要在一個(gè)私有環(huán)境中使用，是需要自己部署一個(gè)大模型，還是可以配其他大模型。

A6：有兩方面考慮，第一個(gè)是在部署時(shí)需要考慮企業(yè)內(nèi)部可承擔(dān)的算力成本，百億左右的模型成本相對(duì)來(lái)說(shuō)比較低，但超過(guò) 500 億以上的成本相對(duì)來(lái)說(shuō)就會(huì)比較高，這要看企業(yè)的選擇。根據(jù)我們的經(jīng)驗(yàn)，300 億以下要靠微調(diào)，300 億尤其 500 億以上，靠 prompt 微調(diào)就可以。500 億以上通過(guò) prompt 和工程的方式能夠避免很多錯(cuò)誤的情況。但是在 500 億以下，可能有很多情況是工程手段無(wú)法避免的，這種情況下需要靠調(diào)，而部署方式要看客戶對(duì)資源的要求。

Q7：SwiftAgent 流轉(zhuǎn)框架里有 check system 和 retry system，它們都有最終的 output 分支，其執(zhí)行標(biāo)準(zhǔn)是什么？

A7：Check system 是我們內(nèi)部的一個(gè)重試機(jī)制，針對(duì)于不同的情況，比如當(dāng)它發(fā)現(xiàn)找不到對(duì)應(yīng)的指標(biāo)，或者用指標(biāo)的 API 邏輯回答的結(jié)果是錯(cuò)的，或者和用戶提問(wèn)的要素不匹配的時(shí)候，我們會(huì)通過(guò) SQL 的方式直接侵入到底層模型表以下，通過(guò) SQL 生成的方式，去檢索出來(lái)相應(yīng)的結(jié)果。其中，判斷用戶的 query 和解析的要素是否一致，是由大模型來(lái)完成的。此外，還有很多工程化手段，比如 API 底層引擎里直接有代碼報(bào)錯(cuò)，此時(shí)也需要重試的機(jī)制。

對(duì)于 retry system，一部分會(huì)到 Agent 重試，還有一部分會(huì)到 SQL generate。因?yàn)?Agent 部分融合了標(biāo)簽和指標(biāo)，而生成 SQL 是一種兜底，它是一個(gè)單獨(dú)的線路和技能，SQL 本身生成效果也有不穩(wěn)定，一般也會(huì)讓它重試，但是會(huì)設(shè)置最大重試次數(shù)。

Q8：用戶對(duì)數(shù)據(jù)的信任問(wèn)題，除了用數(shù)據(jù)治理去解決一些事情之外，還有什么其他方式解決嗎？

A8：這個(gè)只能保證底層數(shù)據(jù)的準(zhǔn)確，數(shù)據(jù)治理是必不可少的。

Q9：產(chǎn)品的優(yōu)勢(shì)之一是用戶可干預(yù)，在哪些環(huán)節(jié)是用戶比較適合介入干預(yù)的？干擾和輔助提問(wèn)的臨界點(diǎn)應(yīng)該怎么把握？

A9：其實(shí)是召回和生成的平衡。比如大模型召回的字段生成的結(jié)果，你判斷它生成的結(jié)果在你之前的候選集里分?jǐn)?shù)排得并不是特別靠前，但是大模型選擇了它，那你就要反問(wèn)，同時(shí)要附上分?jǐn)?shù)較高那幾個(gè)，這個(gè)是要根據(jù)具體的業(yè)務(wù)場(chǎng)景去做一個(gè)抉擇。出現(xiàn)沖突矛盾的時(shí)候，就需要去做反問(wèn)。除了反問(wèn)，還有對(duì)結(jié)果的贊和踩也可視為一種用戶干預(yù)，但其實(shí)是對(duì)結(jié)果的校準(zhǔn)。