（以下文章來源於大魚的數據人生）
🔎大模型出來後，讓用戶用自然語言的方式做數據分析就成了BI領域關注的焦點，這其中最關鍵的點在於如何將數據分析的問題轉化成能夠執行的SQL，從而跨越業務理解到數據提取的巨大鴻溝。
今天就來談談ChatSQL的實現思路，下面以“分地區統計4月1日年齡>50歲的客戶的購物金額”需求爲例說明SQL組裝實現的過程👇。
01 需求分析
需求分析是將自然語言轉換為SQL語句的整個流程的第一步。具體包括以下幾個方面：
1、確定支持哪種類型的數據統計問題
（1）聚合查詢：如平均值、總和、計數等。
（2）時間序列分析：如月度銷售額、季度利潤等。
（3）多維度分析：如按地區、年齡段、性別等不同維度進行數據分析。
本案例的“分地區統計購物金額“涉及多維度分析、總和等類型的統計問題
2、確定支持哪些數據源和數據表結構
（1）數據源：數據可以存儲在不同類型的數據庫中，如關係數據庫（MySQL, PostgreSQL）、NoSQL數據庫（MongoDB, Cassandra）或者是分佈式數據倉庫（如Snowflake, Redshift）。
（2）數據表結構：瞭解每個數據表的結構，包括表名、字段名、字段類型等。這樣才能確保自然語言的需求能準確地映射到具體的數據庫字段。
本案例涉及客戶信息表（CustomerInfo）、購物記錄表（ShoppingRecords），如下所示。
為了簡化後續操作，這裡假設大模型具備連續問答的能力，同時兩張表內容已經成為本次問答的上下文。
3、瞭解目標用戶和使用場景
（1）目標用戶：瞭解將使用這個系統的主要用戶群體，他們可能是管理者、數據分析師、業務人員或者是沒有數據庫經驗的普通用戶。
（2）使用場景：瞭解在哪些具體場景下，用戶最有可能使用這個系統。是為了報告生成、實時數據監控，還是為了業務決策支持。
起步的時候，ChatSQL只能實現非常簡單的取數邏輯，其不是為IT人員服務的，他們也不需要，服務的對象更可能是不懂SQL的業務人員或者老闆。
業務人員希望自己能快速的獲得某個數據。比如取上月arpu大於50的用戶清單進行營銷，管理人員希望能快速靈活的獲得某個維度的指標數據，但讓他自己找或找別人要，這個指標沒個半天下不來。
通過這一階段的需求分析，我們將能更清晰地瞭解系統需要解決的具體問題，以及如何去解決這些問題。這為後續的設計和實現提供了明確的方向。
02 大模型識別出基礎元素
SQL做統計要明確四個要素：維度、指標、條件及時間，我們要從需求描述中把四個要素準確的提取出來：
（1）識別維度：找出句子中表示維度（如地區、時間等）的詞彙。
（2）識別指標：找出句子中表示指標（如購物金額、次數等）的詞彙。
（3）識別條件：找出句子中表示篩選條件的詞彙。
（4）識別時間：如果有，找出句子中表示時間範圍的詞彙。
這就需要靠大模型的語義理解能力了，這裡以ChatGPT4為例說明，可以這麼問大模型:
❓問題：
“假設你是自然語言處理專家和統計學家，並是XX行業的數據分析師，請理解以下業務需求，將需求描述進行統計元素拆解，並採用{【指標】：比如”在網用戶數“；【時間】：比如”2020年5月“；【維度】：比如”地市“；【條件】：比如”收入大於100元“}的格式輸出，需求描述：分地區統計4月1日年齡>50歲的客戶的購物金額”
ChatGPT4：
【指標】：購物金額
【時間】：4月1日
【維度】：地區
【條件】：年齡>50歲
可以看到，chatgpt準確的提取出了四個關鍵要素，這是非常關鍵的一步。
03 字段映射
【指標】、【維度】及【條件】通過向量檢索查詢最相似的列，然後提取表名和列名，也可以直接問大模型要答案：
❓問題：
“請將購物金額、地區、年齡>50歲、時間與CustomerInfo、ShoppingRecords表對應的字段做匹配，輸出格式參考：購物金額->ShoppingRecords.shopping_amount”
ChatGPT4：
購物金額->ShoppingRecords.shopping_amount；
地區->CustomerInfo.region；
年齡>50歲->CustomerInfo.age；
時間->ShoppingRecords.shopping_date
04 SQL組裝
大模型支持連續對話，可以直接讓chatgpt基於前面的語義分析給出組裝SQL：
❓問題：
“請基於字段匹配關係，對“分地區統計4月1日年齡>50歲的客戶的購物金額“給出拼裝的統計SQL”
ChatGPT4：
事實上，ChatGPT4已經足夠聰明到能夠推理出你統計的意圖，並且給出了正確的組裝SQL。
05 大模型的挑戰
以上只是基於ChatGPT 4的測試結果，還是比較理想化的，但要實現一個真正實用的ChatSQL，要解決的問題其實很多。
1、大模型的能力問題
現在大多數模型跟chatgpt4有巨大的差距，為了得到你想要的結果，往往需要給出更多的提示詞和使用更多的輔助工具。下面我們基於chatgpt3.5再走一遍流程，看看會發生什麼問題，探討下應該怎麼解決：
（1）大模型識別出基礎元素
❓問題：
“假設你是自然語言處理專家和統計學家，並是XX行業的數據分析師，請理解以下業務需求，將需求描述進行統計元素拆解，並採用
{【指標】：比如”在網用戶數“；【時間】：比如”2020年5月“；【維度】：比如”地市“；【條件】：比如”收入大於100元“}的格式輸出
需求描述：分地區統計4月1日年齡>50歲的客戶的購物金額”
ChatGPT3.5：
1、指標：購物金額
2、時間：4月1日
3、維度：地區
4、條件：年齡大於50歲的客戶
可以看到，ChatGPT3在條件中把“客戶”帶進來了，這會干擾後續條件字段的映射。
（2）字段映射
❓問題：
“請將購物金額、地區、年齡大於50歲的客戶、時間與CustomerInfo、ShoppingRecords表對應的字段做匹配，輸出格式參考：購物金額->ShoppingRecords.shopping_amount“
ChatGPT3.5：
購物金額->ShoppingRecords.shopping_amount
地區->CustomerInfo.region
年齡大於50歲的客戶->CustomerInfo.age > 50
時間->ShoppingRecords.shopping_date
果然，”年齡大於50歲的客戶“無法很好的與某個字段匹配，這裡可以有兩種解決方式：
第一種是調整提示詞：
問題：
“請將購物金額、地區、客戶年齡大於50歲、時間與CustomerInfo、ShoppingRecords表對應的字段做匹配，輸出格式參考：購物金額->ShoppingRecords.shopping_amount“，如果無法直接匹配到字段，請選擇含義最近的字段進行匹配“
ChatGPT3.5:
購物金額 -> ShoppingRecords.shopping_amount
地區 -> CustomerInfo.region
客戶年齡大於50歲 -> CustomerInfo.age（儘管無法直接匹配，但代表客戶年齡信息）
時間 -> ShoppingRecords.shopping_date
這時它終於匹配上了正確的字段，但需要不停的優化提示詞才能做到通用性。
第二種就是採取分詞、詞性標註、實體識別等方式，先把”客戶年齡“這個實體名稱單獨識別出來再去匹配字段，這是在特定領域解決大模型能力不足的特定方法，但會導致ChatSQL的複雜度大大增加。
（3）SQL組裝
❓問題：
”請基於字段匹配關係，對“分地區統計4月1日年齡>50歲的客戶的購物金額“給出拼裝的統計SQL“
chatgpt3.5:
ChatGPT3.5基於上下文，還是能拼裝出這個簡單的SQL，我也測試了文心一言等大模型，對於這個簡單場景基本還是OK。但統計需求的靈活性實在太高了，下面稍加變化一下統計用詞，再來看看各大模型的表現：
❓問題：
”分地區統計昨天購物金額的同比增長情況“
ChatGPT4:
ChatGPT4的組裝SQL是正確的，它精準的理解了按天同比的概念。
ChatGPT3.5:
ChatGPT3.5的SQL基本正確，但它有BUG：
第一、沒有考慮空值，當去年同一天沒有數據時，同比增長率的計算可能會出現問題。
第二、完整性問題，LEFT JOIN會導致去年沒有數據的地區顯示為NULL，如果對NULL進行數學運算，結果也會是NULL，子查詢。
第三、性能問題，子查詢可能會影響查詢性能，特別是當表非常大的時候。
但總體來講勉強及格。
文心一言：
文心一言的SQL完全是錯誤的，它沒有理解按天同比的概念，語法也有大量錯誤，基本是不可用的。
ChatSQL難點就在於此，為了彌補大模型每個階段能力的不足，我們得針對特定的場景進行大量的定製化自然語言模型的開發、配備合適的工具、同時優化大量的提示詞來引導笨笨的大模型一步一步達成組裝SQL的目標，當這個代價特別大的時候，就意味著ChatSQL的失敗。
2、數據管理的問題
ChatSQL的成功還依賴於企業數據目錄的完備程度，其關鍵一步是大模型要將四要素跟企業的數據字典元數據進行精準匹配，如果企業數據字典的業務元數據、技術元數據不完善的話，匹配率會非常差，ChatSQL也無實用性可言。
當前我們只能採取臨時補充元數據的方法來解決問題，但當ChatSQL規模化後，這種做法就不可持續了，企業需要建立較為完備的數據治理體系，能夠對數據目錄進行常態化的運營，否則，一切基於數據的大模型創新就會舉步維艱。
3、ChatdSQL的場景問題
正如前面所說，初期的ChatSQL能力有限，對於開發人員、取數人員價值有限，當前願意用ChatSQL的用戶要滿足兩個條件：
第一、有較為強烈的實時，準實時用數的需求
第二、沒有SQL開發能力或者對數據架構不熟悉
滿足這兩種條件的，ChatSQL才有下場的機會，我想到的有兩種場景：一種是業務人員需要快速取數，另一種是管理者有快速靈活看指標的需求，如果不滿足這些條件，那就讓子彈再飛一會兒吧。
ChatSQL最終能成功的，一定是在不斷縮小垂直領域的業務分析範圍和不斷增強的大模型能力之間達成了某種平衡的企業，如果ChatSQL真的能成功，BI的增強分析就是水到渠成的事了。
以上就是本期的內容分享~~，碼字不易，如果覺得對你有一點點幫助，歡迎「追蹤」，「點贊」，「分享」喔，我會持續為大家輸出優質的內容~~
※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※
我是「數據分析那些事」。常年分享數據分析乾貨，不定期分享好用的職場技能工具。各位也可以關注我的Facebook，按讚我的臉書並私訊「10」，送你十週入門數據分析電子書唷！期待你與我互動起來~
☞☞☞點選下方圖片免費體驗FineBI工具demo！
文章推薦：
回顧十週入門數據分析系列文：
關注數據君的臉書，ins（全網同名）
我是「數據分析那些事」。常年在臉書，ins分享數據分析乾貨，不定期分享好用的職場技能工具。按贊我的臉書，並在臉書置頂帖子下回復SQL50,會有MySQL經典50題及答案贈送唷！
