在數(shù)字化轉(zhuǎn)型的浪潮中，AI大模型正成為重塑數(shù)據(jù)分析和自動化流程的關(guān)鍵技術(shù)。本文深入探討了如何運(yùn)用AI大模型構(gòu)建高效、準(zhǔn)確的數(shù)據(jù)機(jī)器人，通過對比傳統(tǒng)NLP技術(shù)和現(xiàn)代AI大模型的應(yīng)用，揭示了不同方法的優(yōu)勢與挑戰(zhàn)。

我19年在螞蟻的時候獨(dú)立起了個項(xiàng)目，當(dāng)然這個項(xiàng)目整體是個業(yè)務(wù)歸因分析的平臺，但是在這里面我采用了一種新的數(shù)據(jù)分析的用戶交互方式，就是通過釘釘以IM進(jìn)行問答式的分析交互。簡單說就是想看什么樣的數(shù)據(jù)，以及分析和歸因都可以通過自然語言的方式進(jìn)行提問，然后會返回具體的結(jié)果。

給大家個示例：

數(shù)據(jù)機(jī)器人示例-就像這樣支持用戶進(jìn)行自然語言交互

在今天看起來是不是非常像AI大模型？如果那時候有大模型的加持肯定過會事半功倍，當(dāng)時采用的方法是非常復(fù)雜的，不過也有其優(yōu)點(diǎn)就是能保證數(shù)據(jù)的準(zhǔn)確性。

今天就來教大家如何構(gòu)建問答式的數(shù)據(jù)機(jī)器人，以及兩種方式各自的優(yōu)劣。

我之前的方式是采用：NLP分詞+知識圖譜的方式（在增強(qiáng)分析領(lǐng)域，可以稱為NLQ-Natural Language Query）。這個過程是通過NLP解析用戶自然語言的問題轉(zhuǎn)換為SQL，然后通過SQL在對應(yīng)的指標(biāo)圖譜中通過多維指標(biāo)的數(shù)據(jù)關(guān)系進(jìn)行指標(biāo)匯總，最后返回給用戶數(shù)據(jù)結(jié)果。

查詢過程：用戶自然語言查詢→NLP→SQL→查詢指標(biāo)圖譜→數(shù)據(jù)聚合→圖表和數(shù)據(jù)返回

這里面NLP其實(shí)核心是在做分詞，把時間、維度和指標(biāo)名解析出來，因?yàn)樵诓樵儠r是基于指標(biāo)模型（時間周期+修飾詞+原子指標(biāo)）進(jìn)行的，所以只要有查詢的指標(biāo)結(jié)構(gòu)就可以做到。NLP解析出來后生成的SQL更多的是在做簡單查詢，假設(shè)用戶要查詢「今日杭州新注冊用戶數(shù)」的話，對于SQL來講就是直接查詢這個指標(biāo)（select ‘杭州新注冊用戶數(shù)’ where day=‘今天日期’），但其實(shí)這個指標(biāo)是通過知識圖譜（指標(biāo)圖譜）的圖關(guān)系把「今日」、「杭州」和「新注冊用戶數(shù)」這幾個實(shí)體和關(guān)系的數(shù)據(jù)進(jìn)行聚合。

所以復(fù)雜關(guān)系的指標(biāo)數(shù)據(jù)聚合其實(shí)是在知識圖譜完成的，因?yàn)槿绻孨LP解析后直接生成復(fù)雜SQL的話在那個時候技術(shù)并不成熟，當(dāng)然對于今天的大模型來說生成復(fù)雜的SQL語言是小菜一碟。

去年也就是23年初大模型火熱的時候我就在思考這個問題，如果通過大模型來實(shí)現(xiàn)是否可行，這取決于大模型的NLQ能力——對指標(biāo)與分析相關(guān)的自然語言的理解以及轉(zhuǎn)化為SQL的準(zhǔn)確性。因?yàn)槿绻ㄟ^大模型的方式來實(shí)現(xiàn)的話，取代的是“NLP→SQL→查詢指標(biāo)圖譜”這個流程環(huán)節(jié)，同時也就不需要構(gòu)建復(fù)雜的知識圖譜了，只需要像數(shù)倉中間層正常構(gòu)建多維的指標(biāo)數(shù)據(jù)寬表就夠了，因?yàn)榕缮笜?biāo)的聚合其實(shí)是在大模型中生成的復(fù)雜查詢SQL。令人興奮的是，大模型的編程語言能力比想象的更強(qiáng)。

一、利用大模型的方式

首先在大模型中設(shè)置提示詞（Prompt）：聲明數(shù)據(jù)表結(jié)構(gòu)（表元數(shù)據(jù)信息）→聲明查詢方式→生成SQL

完整機(jī)器人交互查詢過程：用戶IM自然語言查詢→大模型NLQ→查詢指標(biāo)模型表→圖表和數(shù)據(jù)返回

（這個過程和前面的對比你會發(fā)現(xiàn)大模型取代了「NLP分詞」、「SQL生成」和「知識圖譜構(gòu)建」這幾個很復(fù)雜的環(huán)節(jié)。）

因?yàn)槲覀冋麄€數(shù)據(jù)指標(biāo)核心還是依托指標(biāo)模型（時間周期+修飾詞+原子指標(biāo)），所以在提示詞聲明表的元數(shù)據(jù)信息以及查詢方式時可以把表相應(yīng)的字段約束一下，比如——“時間”是哪個字段，基于時間聚合的話方式是怎樣的（時間已經(jīng)按照時間周期標(biāo)簽化了，比如：近1天、近7天。還是字段存儲的是日期，需要根據(jù)日期進(jìn)行篩選后聚合），以及度量（原子指標(biāo)）是哪個字段。

當(dāng)然這些工作也可以不做，就相當(dāng)于把準(zhǔn)確性這個東西轉(zhuǎn)嫁給了大模型，我測試過ChatGPT以及國內(nèi)的大模型，我們只要把表的元數(shù)據(jù)信息——字段、字段類型、字段中文描述、分區(qū)以及分區(qū)存儲類型（增量 or 存量），這些通過提示詞聲明好，我們在通過自然語言查詢的時候生成的SQL準(zhǔn)確性很高（因?yàn)榇竽Ｐ蜁鶕?jù)你的字段描述以及元數(shù)據(jù)信息去進(jìn)行自動判斷）。但是對于成熟產(chǎn)品交付來講，我們通過這個約束的目的是減少錯誤率。

不做提示詞約束時大模型NLQ的實(shí)例：

比如這個就是我之前測試大模型NLQ時的一個實(shí)例，這個實(shí)例中我沒有進(jìn)行過多的提示就只是聲明了一下表結(jié)構(gòu)，大模型就能比較好的理解以及幫我生成SQL。

與國內(nèi)某大模型的NLQ對話截圖

這個用戶明細(xì)表如果變成指標(biāo)模型的多維表的話，表結(jié)構(gòu)如下：

日期 | 注冊渠道 | 注冊終端 | 注冊用戶數(shù)（度量）

即使是變成這樣的指標(biāo)模型表結(jié)構(gòu)的話數(shù)據(jù)形式也是有多樣的，比如：

第①種：
近1天 | 微信 | App | 1000
近7天 | 微信 | App | 26000

第②種：
20240910 | 微信 | App | 1000
…
20240904 | 微信 | App | 6000

像上面我列出的這兩種數(shù)據(jù)格式對于指標(biāo)查詢的處理就會有區(qū)別：

–第①種
select 注冊用戶數(shù) where 日期=‘近7天’
–第②種
select sum(注冊用戶數(shù)) where 日期 between ‘20240904’ and ‘20240910’

當(dāng)然上面這兩種數(shù)據(jù)結(jié)構(gòu)的前置數(shù)據(jù)處理邏輯也有區(qū)別，所以會有不同。我這里給大家舉這個簡單的例子是想說明，不同公司對指標(biāo)數(shù)據(jù)的處理邏輯是不同的，要根據(jù)實(shí)際邏輯去看應(yīng)該用什么樣的查詢方式，然后在提示詞中進(jìn)行聲明和約束，否則就會導(dǎo)致數(shù)據(jù)口徑出錯的問題。

二、兩種方式的優(yōu)、劣對比

對于后一種利用大模型的方式進(jìn)行構(gòu)建（我們稱為v2，前者是v1），很明顯的要簡單很多，容易實(shí)現(xiàn)，甚至說不需要太多的技術(shù)含量。但是這里面總會暗含著不確定性，也就是大模型在NLQ的過程中會不會搞些幺蛾子，這個在我們使用大模型的時候就很有體會，猛不丁的給你造個出人意料的東西出來（比如在這里就是出人意料的SQL查詢邏輯）。

畢竟用戶看的是數(shù)據(jù)結(jié)果，中間是黑盒，有時候結(jié)果很難察覺是否除了問題。所以就像總有一個蒼蠅在你嘴邊飛，不知道哪天就被吃進(jìn)去了…所以就只能盡可能多的約束，但是約束是約束不了生成詭異的SQL代碼邏輯的。

但是對于前一種方式（v1）來說，出錯會意味著查詢失敗，但不會有“驚喜”！因?yàn)檫@里面主要可能出錯的是在NLP分詞的環(huán)節(jié)，分詞分不好最多是維度、指標(biāo)的錯誤和缺失之類的，把這些分詞結(jié)果加到SQL中進(jìn)行查詢最多就是沒有數(shù)據(jù)結(jié)果，而不會“一本正經(jīng)的胡說八道”。

所以說v1版本的：

優(yōu)勢是——可以確保查詢出的數(shù)據(jù)的準(zhǔn)確性。

缺點(diǎn)是——構(gòu)建復(fù)雜，會有很大的技術(shù)壁壘，比如知識圖譜。

所以研發(fā)用時會很久，對于一般效率的研發(fā)來講至少要4-6個月的時間才能有產(chǎn)品的mvp。

v2版本的：

優(yōu)勢是——可以很快速的把產(chǎn)品研發(fā)上線，甚至mvp版本2周應(yīng)該就差不多。

缺點(diǎn)是——你要容忍暫時無法解決的“驚喜”，問題是這種驚喜還不容易發(fā)現(xiàn)和監(jiān)控，甚至不容易察覺。

有的時候如果你的數(shù)據(jù)產(chǎn)品數(shù)據(jù)準(zhǔn)確性像中獎一樣且無法解決，對于需要可靠性的場景就直接被pass。但是從另一個角度來說，有很多對數(shù)據(jù)準(zhǔn)確性沒有那么嚴(yán)格，但是對取數(shù)效率比較重視的場景就是一個很好的產(chǎn)品。并且其實(shí)可以通過多次的查詢以及經(jīng)驗(yàn)去做簡單的驗(yàn)證和判斷。

畢竟對于這么炫酷好用的東西，很多老板可以暫時容忍一些小缺點(diǎn)的是吧！

以下是一些補(bǔ)充信息

本文中涉及到的一些專業(yè)名詞解釋：

• NLP：自然語言處理，一般通過算法模型進(jìn)行語句的分詞、內(nèi)容分析、情緒分析等。
• 增強(qiáng)分析：通過機(jī)器學(xué)習(xí)和AI的方式降低數(shù)據(jù)分析成本以及自動化的分析挖掘
• NLQ：自然語言查詢，通過自然語言的方式轉(zhuǎn)換為查詢語言，比如SQL等。
• 提示詞（Prompt）：通過提示詞幫助大模型理解用戶的意圖，要做什么事情。
• 元數(shù)據(jù)（Meta）：描述數(shù)據(jù)的數(shù)據(jù)，比如像表的元數(shù)據(jù)信息就是指的表名稱、路徑、字段描述之類的相關(guān)信息，與表內(nèi)存儲的數(shù)據(jù)無關(guān)。

本文涉及到的一些核心專業(yè)知識點(diǎn)：

指標(biāo)模型的構(gòu)建——文中指的是兩方面：

①一方面是指標(biāo)抽象的構(gòu)成方式「時間周期+修飾詞（維度）+原子指標(biāo)」；

②另一方面是指的基于這種構(gòu)成方式，數(shù)據(jù)表模型的構(gòu)建。