在數字化轉型的浪潮中，AI大模型正成為重塑數據分析和自動化流程的關鍵技術。本文深入探討了如何運用AI大模型構建高效、準確的數據機器人，通過對比傳統NLP技術和現代AI大模型的應用，揭示了不同方法的優勢與挑戰。

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

給大家個示例：

數據機器人示例-就像這樣支持用戶進行自然語言交互

在今天看起來是不是非常像AI大模型？如果那時候有大模型的加持肯定過會事半功倍，當時采用的方法是非常復雜的，不過也有其優點就是能保證數據的準確性。

今天就來教大家如何構建問答式的數據機器人，以及兩種方式各自的優劣。

我之前的方式是采用：NLP分詞+知識圖譜的方式（在增強分析領域，可以稱為NLQ-Natural Language Query）。這個過程是通過NLP解析用戶自然語言的問題轉換為SQL，然后通過SQL在對應的指標圖譜中通過多維指標的數據關系進行指標匯總，最后返回給用戶數據結果。

查詢過程：用戶自然語言查詢→NLP→SQL→查詢指標圖譜→數據聚合→圖表和數據返回

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

所以復雜關系的指標數據聚合其實是在知識圖譜完成的，因為如果讓NLP解析后直接生成復雜SQL的話在那個時候技術并不成熟，當然對于今天的大模型來說生成復雜的SQL語言是小菜一碟。

去年也就是23年初大模型火熱的時候我就在思考這個問題，如果通過大模型來實現是否可行，這取決于大模型的NLQ能力——對指標與分析相關的自然語言的理解以及轉化為SQL的準確性。因為如果通過大模型的方式來實現的話，取代的是“NLP→SQL→查詢指標圖譜”這個流程環節，同時也就不需要構建復雜的知識圖譜了，只需要像數倉中間層正常構建多維的指標數據寬表就夠了，因為派生指標的聚合其實是在大模型中生成的復雜查詢SQL。令人興奮的是，大模型的編程語言能力比想象的更強。

一、利用大模型的方式

首先在大模型中設置提示詞（Prompt）：聲明數據表結構（表元數據信息）→聲明查詢方式→生成SQL

完整機器人交互查詢過程：用戶IM自然語言查詢→大模型NLQ→查詢指標模型表→圖表和數據返回

（這個過程和前面的對比你會發現大模型取代了「NLP分詞」、「SQL生成」和「知識圖譜構建」這幾個很復雜的環節。）

因為我們整個數據指標核心還是依托指標模型（時間周期+修飾詞+原子指標），所以在提示詞聲明表的元數據信息以及查詢方式時可以把表相應的字段約束一下，比如——“時間”是哪個字段，基于時間聚合的話方式是怎樣的（時間已經按照時間周期標簽化了，比如：近1天、近7天。還是字段存儲的是日期，需要根據日期進行篩選后聚合），以及度量（原子指標）是哪個字段。

當然這些工作也可以不做，就相當于把準確性這個東西轉嫁給了大模型，我測試過ChatGPT以及國內的大模型，我們只要把表的元數據信息——字段、字段類型、字段中文描述、分區以及分區存儲類型（增量 or 存量），這些通過提示詞聲明好，我們在通過自然語言查詢的時候生成的SQL準確性很高（因為大模型會根據你的字段描述以及元數據信息去進行自動判斷）。但是對于成熟產品交付來講，我們通過這個約束的目的是減少錯誤率。

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

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

與國內某大模型的NLQ對話截圖

這個用戶明細表如果變成指標模型的多維表的話，表結構如下：

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

即使是變成這樣的指標模型表結構的話數據形式也是有多樣的，比如：

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

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

像上面我列出的這兩種數據格式對于指標查詢的處理就會有區別：

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

當然上面這兩種數據結構的前置數據處理邏輯也有區別，所以會有不同。我這里給大家舉這個簡單的例子是想說明，不同公司對指標數據的處理邏輯是不同的，要根據實際邏輯去看應該用什么樣的查詢方式，然后在提示詞中進行聲明和約束，否則就會導致數據口徑出錯的問題。

二、兩種方式的優、劣對比

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

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

但是對于前一種方式（v1）來說，出錯會意味著查詢失敗，但不會有“驚喜”！因為這里面主要可能出錯的是在NLP分詞的環節，分詞分不好最多是維度、指標的錯誤和缺失之類的，把這些分詞結果加到SQL中進行查詢最多就是沒有數據結果，而不會“一本正經的胡說八道”。

所以說v1版本的：

優勢是——可以確保查詢出的數據的準確性。

缺點是——構建復雜，會有很大的技術壁壘，比如知識圖譜。

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

v2版本的：

優勢是——可以很快速的把產品研發上線，甚至mvp版本2周應該就差不多。

缺點是——你要容忍暫時無法解決的“驚喜”，問題是這種驚喜還不容易發現和監控，甚至不容易察覺。

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

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

以下是一些補充信息

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

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

本文涉及到的一些核心專業知識點：

指標模型的構建——文中指的是兩方面：

①一方面是指標抽象的構成方式「時間周期+修飾詞（維度）+原子指標」；

②另一方面是指的基于這種構成方式，數據表模型的構建。