ChatGPT4 橫空出世，其強大的語義泛化能力以及針對 Zero-Shot、Few-Shot 等場景的特性讓 AI 的使用門檻進一步降低，也為各行各業(yè)帶來了更多想象空間。本文將分享海南數(shù)造科技對 DataOps 加大模型驅動數(shù)據(jù)創(chuàng)新的思考與實踐。

一、傳統(tǒng)數(shù)據(jù)管理面臨的挑戰(zhàn)

企業(yè)做數(shù)字化轉型會制定自己的數(shù)字戰(zhàn)略，在數(shù)字戰(zhàn)略與業(yè)務戰(zhàn)略對齊的過程中，企業(yè)也完成了數(shù)據(jù)從收集、管理到分析的流程，這個流程就是企業(yè)數(shù)字化轉型的體現(xiàn)。

企業(yè)數(shù)字化轉型呈現(xiàn)出三大戰(zhàn)略趨勢：

• 首先是數(shù)據(jù)分析民主化。數(shù)據(jù)分析不再只是少數(shù)人的工作，各個崗位都會去看報表，也會用一些統(tǒng)計算法，以實時支撐業(yè)務決策。
• 第二是數(shù)據(jù)技術多元化。現(xiàn)在信息系統(tǒng)多元化，數(shù)據(jù)開發(fā)同學面臨著各種多元異構的數(shù)據(jù)。在復雜的數(shù)據(jù)環(huán)境下，我們需要多元化的一些技術組件來支撐，比如 Flink、Spark 等計算組件和存儲組件。又比如在很多金融反欺詐場景中，會用到知識圖譜建模和分析的數(shù)據(jù)組件。整體上變成了一個很龐大的、復雜的系統(tǒng)化工程。
• 第三是業(yè)務價值精益化。對于業(yè)務部門來說，也希望數(shù)據(jù)能實現(xiàn)快速變現(xiàn)。

在上述趨勢下，我們面臨著供需不平衡的痛點?，F(xiàn)在市場變化很快，業(yè)務同學需要快速響應市場變化，所以經常會有大量的、臨時的，且有高時效性要求的數(shù)據(jù)需求。開發(fā)在早期會面臨開發(fā)環(huán)境與測試環(huán)境不一致，部署和集成需要大量人工介入，系統(tǒng)之間存在數(shù)據(jù)孤島問題。導致調研數(shù)據(jù)口徑要耗費大量時間，數(shù)據(jù)開發(fā)從交付到上線往往超過一周，甚至更長時間。同時也存在數(shù)據(jù)語義缺失、業(yè)務用數(shù)困難等其它一些問題。

數(shù)據(jù)開發(fā)工作也像軟件工程一樣，不應該是瀑布式的流程，即所有事情都要先計劃好、設計好才去開發(fā)，而是要實現(xiàn)敏捷交付，能夠實時地響應需求。當前研發(fā)進度是落后于市場需求的。

二、DataOps 與大模型的結合驅動數(shù)據(jù)工程創(chuàng)新

在數(shù)字化轉型的趨勢下，也是在上述痛點的驅動下，企業(yè)亟需新的數(shù)據(jù)研發(fā)范式，需要滿足以下要求：

• 形成敏捷數(shù)據(jù)研發(fā)流水線。
• 構建高效的跨域協(xié)同機制。
• 打造自助的用數(shù)體驗。
• 建立精細化的運營體系。

這樣才能實現(xiàn)快速交付數(shù)據(jù)的目的。

在這樣的背景下，我們提出了 DataOps 的理念。DataOps 是在 DevOps 的基礎上發(fā)展而來的，其本質是數(shù)據(jù)工作流的編排、數(shù)據(jù)的開發(fā)、測試、部署上線、回歸這套機制需要達到持續(xù)集成的效果，有標準化的體系，實現(xiàn)自動化部署，同時優(yōu)化整個數(shù)據(jù)發(fā)布的流程，優(yōu)化資源達到敏捷開發(fā)交付的效果。

從 2018 年開始，DataOps 的理念度被 Gartner 列入了技術成熟度曲線，并有著逐年上升的趨勢。數(shù)造科技在 2022 年與信通院聯(lián)合成立了一個專家工作小組，制定了 DataOps 的能力標準。

介紹了 DataOps 的背景后，讓我們再回到 AI。從 AlphaGo 為代表的深度學習技術的發(fā)展，到去年 ChatGPT 大語言模型技術的出現(xiàn)，AI 使用門檻越來越低，我們的信息化系統(tǒng)越來越智能化。

僅僅一年時間里，出現(xiàn)了很多基于大語言模型的 AI 工具。我們團隊使用了一款名為 Bito 的代碼自動生成和檢查的開源插件，使得工作效率提升了 20% 以上。

上圖展示了我們 DataOps 的標準化流程，在數(shù)據(jù)的開發(fā)、發(fā)布的過程中，使用大模型支持代碼生成、代碼解釋以及代碼審查的工作，讓整個流程更加智能化。

上圖中對比了傳統(tǒng)數(shù)據(jù)開發(fā)模式和“DataOps+大模型”模式。傳統(tǒng)數(shù)據(jù)開發(fā)模式，從數(shù)據(jù)建模、數(shù)據(jù)開發(fā)到測試、部署、回歸，步驟繁雜，需要大量的人力介入。在最早的時候，我們有開發(fā)環(huán)境、測試環(huán)境和準生產環(huán)境，不同的環(huán)境中會有不同的開發(fā)人員維系其參數(shù)配置文件。當部署的時候，就要手動改配置文件，往往會引入潛在的風險。

有了 DataOps 這一套敏捷數(shù)據(jù)開發(fā)發(fā)布的標準后，就能達到自動化的效果。這些配置文件會被統(tǒng)一、自動化地管理起來，達到一套數(shù)據(jù)開發(fā)，一套數(shù)據(jù)建模的腳本，能在多套環(huán)境里面去使用，配置參數(shù)會自動替換。同時還具備數(shù)據(jù)沙箱的功能，測試數(shù)據(jù)可能無法體現(xiàn)生產環(huán)境的情況，所以可以使用準生產環(huán)境的數(shù)據(jù)去驗證腳本。在這種自動化的體系下，加入了一些大模型的能力，可以幫助我們生成一些數(shù)據(jù)指令，比如自動生成 SQL 或者加入注釋，以及自動審查等等。所以“DataOps+大模型”就是在 DataOps 這套標準化流程的體系上，加入自動化和智能化，讓數(shù)據(jù)的開發(fā)和交付更加高效。

三、DataOps+大模型產品實踐探索

大模型有很多有趣的應用場景，例如文案生成、數(shù)字人、知識檢索增強等等。還有一個比較熱門的場景就是 Text2SQL，讓大模型去生成指令，接下來將介紹我們在這一方向上的探索與實踐。

Text2SQL 就是基于以自然語言描述的問題，結合表的元數(shù)據(jù)信息（包括表名、列名以及表之間的關聯(lián)關系），生成一個準確的 SQL 語句。2022 年，在大模型出現(xiàn)之前，Text2SQL 基于預訓練模型的準確率能夠做到 75-77% 左右。這一數(shù)據(jù)來自 Spider 的評測榜單，這是一個跨域的，在 Text2SQL 領域比較權威的榜單。大模型出現(xiàn)后，每兩個月榜單會更新一次，GPT4 做的 Text2SQL 任務，準確率也從原來的 78% 一路飆升到 91%。

而 Text2SQL 任務，產生正確的 SQL 只實現(xiàn)了其一半的價值，對于數(shù)據(jù)開發(fā)人員來說，另一半的價值是快速找到想要的數(shù)據(jù)。現(xiàn)實的生產環(huán)境中有大量的數(shù)據(jù)庫、表，要基于自然語言的提問，找到準確的表和列，也就是準確數(shù)據(jù)口徑。所以我們認為 Text2SQL 的定義還要包括在不同 schema 下面能產生正確 SQL 的任務。

在大模型出現(xiàn)之前的做法，是用 Seq2Seq 的模型。對于提問，表的元數(shù)據(jù)信息做嵌入，基于嵌入的向量信息，生成 SQL 語句，這里會有 mismatch problem in literature 的問題。我們做文本時，中文轉英文或者中文轉德文，詞語表述不一樣，語法結構不一樣，但可能語義是一樣的。而對于 Text2SQL 的任務來說，語義是不一樣的，問題用 SQL 是沒辦法準確表述的，比如 SQL 中的 group by、intersect、union 是不會在自然語言里面出現(xiàn)的，你不會說：“幫我查這個季度的總銷售額，用 group by 這個語句”，所以就會存在語義不對等的問題。

基于這個問題，在模型架構上，比如 Encoder Decoder 上做了很多優(yōu)化策略。在大模型出來之前，我們常用的就是谷歌 T5-3B、Electra 或者 RoBERTa 這些預訓練模型作為模型底座，不斷優(yōu)化其 Encoder，一開始只是簡單的 input representation，一個簡單的嵌入的任務，但是會發(fā)現(xiàn)有 schema-linking 不準確的問題。為了更好地將問題與需要用到的表或者列關聯(lián)起來，后面有了更復雜的 Structure Modeling 的建模，會對問題建模，對元數(shù)據(jù)采用更復雜建模的策略，以找到問題相關的表和列。

近幾年比較流行的一種方法是基于知識圖譜的建模方式，一開始大家會用 GNN 圖神經網絡的方法去做建模，但存在一個問題，模型更多的是對節(jié)點的建模，沒辦法泛化到兩度以上深度的信息。所以后面又提出了 RAT-SQL、RASAT 模型，本質是在知識圖譜上去定義 meta-path，把元數(shù)據(jù)的關聯(lián)關系定義出來，在 Encoder 會去做多頭注意力，把關系的向量信息嵌入到里面，加強問題跟本地元數(shù)據(jù)的關聯(lián)性。

Encoder 的優(yōu)化策略解決完，就到 Decoder，怎么把 encoder 的編碼生成 SQL 語句，開始大家會用 Sketch-based 的方法，把生成 SQL 語句拆解成一個個的子部分，生成 select，生成 where，生成 from，基于小的語句去做詞槽，把之前 encoder 識別到的表名、列名填到這個詞槽里，但實際上效果并不好，會產生很多錯誤的、不符合語法的 SQL 語句，所以我們用 Generation-based method 的方法，最經典的就是 AST 語法樹的結構，讓它遵循一定的語法樹來生成 SQL，還有 PICARD，在 search 的時候不斷地去一個記憶空間檢查生成的 SQL 跟前面的 Encoder 的 schema-linking 內容是不是對等的、是不是合語法的，包括 RESDSQL，這樣的優(yōu)化策略，讓它生成更加準確的 SQL。

但是仍然不夠準確，經過分析，還是存在語義不匹配的問題，于是我們又加入了 Intermediate representation 的架構，發(fā)明了基于自然語言跟 SQL 之間的中間語言，NatureSQL、SemQL，先生成中間語言，再基于中間語言生成 SQL，準確率又進一步得到了提升。

大模型出現(xiàn)后，其生成 SQL 的準確度，尤其是 GPT4 基于策略的生成，準確度越來越高。大模型目前主要使用有兩種方法，一種是提示工程，一個是基于指令的監(jiān)督微調，讓大模型產生對應的 SQL。

今年這篇論文來自 SQL，也是大模型生成 SQL 任務的常用方法，即基于思維鏈的方法。在傳統(tǒng) Seq2Seq 的方法中，輸入自然語言和 schema 信息，讓它去生成 SQL，結果發(fā)現(xiàn)這種端到端的方法效果很差，所以才有了 Encoder Decoder 的優(yōu)化策略。大模型其實也一樣，一開始通過 prompt 把自然語言、schema 喂給它，讓它生成 SQL，發(fā)現(xiàn)準確率有問題，所以后面把大模型的任務拆解成一個個子任務，比如先用一個 schema-linking 的 prompt 的模板，找關聯(lián)的表、列，再基于表、列，根據(jù)問題的復雜性來進行分類，是簡單的一個單表查詢的 SQL，還是有一些 join 語句的 SQL，還是在 join 的基礎上有一些復雜子查詢的 SQL。為什么這樣分類呢？因為對于很簡單的單表查詢的 SQL，如果用復雜的 prompt 模板去生成，效果反而會下降，所以加了一個分類的 prompt。在這篇論文里，還加了 self-correction 的 prompt 的模板，告訴大模型再幫我優(yōu)化一下 SQL?；谶@一系列子任務，還有思維鏈的工程，最終才能讓 GPT4 生成比較準確的 SQL 語句。

實踐過程中發(fā)現(xiàn)，無論是傳統(tǒng)的預訓練模型還是大模型，都面臨著很多挑戰(zhàn)。傳統(tǒng)預訓練模型的語義泛化能力肯定比大模型弱，它的生成能力也不一定比大模型強，容易出現(xiàn) missmatch 的問題，復雜查詢語句的生成能力也比較弱，加上 Encoder、Decoder 采用了大量復雜的優(yōu)化策略，尤其是基于 graph based 方法，還要人工先生成 meta-path，維護這些 meta-path 也需要大量的工作，相比于大模型的 zero-shot、few-shot 能力，還要準備一些標注語料，工作量也是很大的。比如 T53B 模型用的顯卡資源并不比大模型少。

大模型也同樣面臨一些挑戰(zhàn)，最近發(fā)表的所有的 Text2SQL 論文全部集中在 GPT4 的研究，對于本地化、私有化的大模型研究偏少。Prompt 的良好實踐，比較依賴于思維鏈，還有 in-context learning，也就是要給大模型一些樣例數(shù)據(jù)去引導它生成更加準確的 SQL，但對于復雜的 schema，就會超出大模型的 token。所以有一種做法是先把表預處理成寬表，生成的 SQL 就沒那么復雜了，就變成了基于寬表去生成查詢語句，不用做 join 操作。但生成寬表的時候，面臨著 schema 非常大的問題，很容易超出它的 token?；谒接谢竽Ｐ偷奈⒄{也是非常少的。

我們認為傳統(tǒng)預訓練模型和大模型都面臨著一個共同的挑戰(zhàn)，用戶在實際使用過程中其實不知道數(shù)據(jù)是在哪一個數(shù)據(jù)庫中，怎么去從大量的庫、表、幾千行的 schema 中找到問題對應的列和表，高效的完成 schema-linking 是非常困難的?，F(xiàn)在很多 Text2SQL 的評測任務是已經假定了要用哪個庫，這個庫中的表和列往往是非常少的，所以沒有遇到復雜的 schema 中找數(shù)的問題。

我們提出了一些實踐和方法，先構建一個元數(shù)據(jù)的語義圖譜，語義就是問題加上表名加列名，這就是生成 SQL 需要用到的所有語義。當我們去生成一個語義圖譜的時候，有更多的 label 信息，還有指標的描述，能補充到這個語義里，讓 prompt 生成的準確率更高。生成語義圖譜，需要一套完備的數(shù)據(jù)治理工具。我們在數(shù)據(jù)建模的時候，有一套自動化的數(shù)據(jù)標準工具，把這套數(shù)據(jù)標準落到數(shù)據(jù)模型中，稱為模型落標的過程?；跀?shù)據(jù)標準完成數(shù)據(jù)模型的時候，會把邏輯層、概念層的元數(shù)據(jù)，還有管理元數(shù)據(jù)共同落到元數(shù)據(jù)目錄上，再基于元數(shù)據(jù)目錄最終生成語義圖譜，這個是生成元數(shù)據(jù)血緣的過程。

另外有些客戶在搭建數(shù)倉的過程中，會抄一些事實表、維度表，這種數(shù)倉建模的形式，整個數(shù)倉建模直接做成從邏輯層開始建模，但是當建模完成后，數(shù)據(jù)開發(fā)人員不知道這個表對應到什么業(yè)務口徑，而業(yè)務口徑也不知道這個業(yè)務指標需要用到哪些表，有哪些工作流，這也導致了語義不對等的問題。更多業(yè)務口徑的語義在哪里？其實是在概念層上面，現(xiàn)在大家做概念層的語義其實全部是用知識圖譜去做的，所以這個血緣圖譜在 Text2SQL 的任務上是非常重要的。很多論文中的數(shù)據(jù)預處理的工作是在做語義轉換，比如表名叫 department，其實就用 DEPT 簡稱來縮寫，DEPT 是一個沒有任何意義的列名，SQL 模型怎么能識別得到呢？所以需要一些數(shù)據(jù)治理的前期準備工作。

現(xiàn)在業(yè)界都是基于 GPT4 去做 Text2SQL 任務，我們與一些國產大模型開展生態(tài)合作，接入了它們的一些接口去做測試。現(xiàn)在所有測試是基于特定場景、特定數(shù)據(jù)、特定私有化的大模型去做的，僅供參考，不一定是具有很高的代表性。我們發(fā)現(xiàn)私有化大模型的指令微調在 Text2SQL 任務上的效果是有限的，這個問題相信很快會得到解決。另外基于 schema-linking 所選取出來的元數(shù)據(jù)信息，再去生成 prompt，在私有化的大模型上，Text2SQL 任務有 5% 到 10% 的提升。先用一個 schema-linking 的模型，先找出和問題相關的表名、列名，再基于表名、列名去做prompt 模板，模型的準確率會有提升，而不是直接把所有元數(shù)據(jù)信息喂給大模型?；陬A訓練模型 schema-linking 的效果是好于大模型的。In-context learning 對私有化大模型的提升效果是最明顯的，大概有 10% 的提升。我們之前 Text2SQL 經常用的 Intermediate Representation 的方法，生成自然語言和 SQL 語句的一種中間語言策略在部分大模型上沒有化學反應，甚至效果更差。Self-correction 對私有化大模型有小幅提升。相比于私有化大模型，目前 GPT4 的效果還是遙遙領先的。

這就是我們提出的方法，schema-linking 是基于預訓練模型去找到問題相關的表和列名，再基于 prompt 去做大模型，現(xiàn)在很多評測，尤其榜單的評測數(shù)據(jù)，用到的表名和列名非常少，所以在做 schema-linking 的時候，也加大了難度，給它更多不同的數(shù)據(jù)庫、不同的表、不同的列名，其 AUC 并沒有明顯的下降。

這是我們基于人大今年發(fā)表的一篇 RESDSQL 的論文所做的 schema-linking。其底層是 RoBERTa，基于 RoBERTa 做 Pooling Module，把切的詞對應到完整的表名或者列名上，在做多頭注意力的時候，對列名做多頭注意力，把一些列的信息嵌入到表名上來提升它對問題相關的表名、列名做排序。我們是基于這個模型做的 schema-linking。

我們也參考了阿里發(fā)表的 Dail SQL 這篇論文，其中提出了 prompt 模板的一個標準方法，基于 prompt 模板，再加上 GPT4，準確率能達到 85-86%。一開始用了 Code Representation 來表示 schema，然后用了 Intermediate Representation，同時最重要的是加入了 in-context learning。這篇論文中，同時使用了相似的問題和相似的 SQL 去組成 prompt 模板中的示例，提示大模型去生成正確的 SQL。其實這里缺失了 schema 結構的相似性，很多時候sql語句的結構不光取決于問題，還取決于對應的數(shù)據(jù)庫 schema 結構，如何在相似問題和相似 SQL 的基礎上引入相似 schema 的判斷，我們認為是大模型生成SQL下一個可以探索的方向。

上圖中列出了一些 Prompt 的成功實踐。比如分割符的應用和結構設計，可以讓大模型知道哪一個部分是在提問，哪一個部分是在講 schema，哪一部分是講 in-context learning。另外我們會加入一些輸出前綴，能讓大模型在生成答案的時候更加穩(wěn)定。這就涉及到大模型的魯棒性，以及指定遵從性的問題，因為測試的過程中，我們會用大模型去嘗試做 schema-linking，讓它按 JSON 格式輸出問題相關的列名和表名，可能 10 次中會有 1 次報錯，比如 JSON 里有個反括號漏掉了，所以魯棒性還是有一定問題的。

接下來介紹數(shù)造科技的產品是如何實現(xiàn) DataOps 與大模型融合的。

上圖是數(shù)造科技的產品體系架構。對 DataOps 的整個過程，包括數(shù)據(jù)集成、開發(fā)，提供了標準化的流程和方法，同時基于數(shù)據(jù)湖倉適配了不同的私有化大模型，基于私有化大模型去完成代碼生成、代碼解釋的工作，幫助 DataOps 提效。同時有統(tǒng)一元數(shù)據(jù)的服務，對于 Text2SQL 任務來說，語義就在表名、列名和問題上，因此要提供更多的語義信息，構建元數(shù)據(jù)血緣圖譜。

開發(fā)治理一體化的數(shù)據(jù)管道包括管理域、開發(fā)域、治理域。其中，治理域包括一套自動化的數(shù)據(jù)標準和工具，幫助我們在數(shù)據(jù)建模的時候落地數(shù)據(jù)標準，不允許生成毫無意義的表名、列名，這些會嚴重影響 Text2SQL 任務效果。開發(fā)域會基于大模型做代碼生成、代碼解析，還有注釋標注的工作。

最后，產品會有持續(xù)集成與發(fā)布的能力，包括一套代碼在多套環(huán)境運行的這種多環(huán)境創(chuàng)建和管理的能力。

上圖展示了我們產品的部分功能界面。有些企業(yè)采用 Altas 等開源的圖數(shù)據(jù)血緣工具，它有一個最大的問題是一張表可能有幾十個列，一展開就是爆炸式的、很多的點，讀起來非常困難。所以我們在數(shù)據(jù)血緣方面做了很多優(yōu)化的工作，不光是把底層元數(shù)據(jù)的數(shù)據(jù)血緣管理起來，也做了一些可視化的優(yōu)化，讓數(shù)據(jù)開發(fā)人員能真正的基于可視化的界面去探查整個數(shù)據(jù)血緣。

上圖展示的是數(shù)據(jù)自動落標、工作流編排等功能。

這是我們做的初版 Text2SQL 的智能小助手，基于輸入的問題可以找出相關的元數(shù)據(jù)信息，如果不準，還能根據(jù)之前的數(shù)據(jù)治理標準，手動修正相關的主題域，再去喂給大模型生成 SQL。

生成的 SQL 不單單只是看，有一個比較方便的富文本編輯器，直接在編輯器上選定 SQL 運行，可以查看報表。

最后是持續(xù)集成和持續(xù)發(fā)布的功能。

四、未來展望

最后分享一些對未來的展望。

我們構建元數(shù)據(jù)的語義圖譜，尤其是指標層，包含了更多的業(yè)務語義、業(yè)務口徑等。如何把每個數(shù)據(jù)標準自動化工具嵌入到模型中，這是我們未來要做的工作，基于更多的語義，看模型的提升效果怎么樣，現(xiàn)在需要一些人工去給 Spider 數(shù)據(jù)去做語義的補充。

知識圖譜有很多子圖檢索增強問答的方法，我們也在思考，把語義元素去圖譜后，能不能借鑒知識圖譜基于子圖檢索增強的方法去嵌入子圖的信息，基于子圖去提升 schema-linking 的效果，這也是我們未來想要探索的方向。

另外我們看到大模型，把整個 SQL 任務拆成不同的子任務，基于這些子任務的 Prompt 模板，引導模型生成正確的 SQL，那么能否基于大模型去做一個 agent，用不同的子模型去完成各個階段的 SQL 生成任務，這也是我們目前的一種設想。

近幾個月來我們看到了很多 long-context 大模型的出現(xiàn)，現(xiàn)在的大模型可能就是 2k、4k，有一些長文本的大模型已經輸入到了 200k?，F(xiàn)在 Text2SQL 最大的問題就是怎么把大量的生產環(huán)境的元數(shù)據(jù)喂給模型，所以我們也在想 long-context 的大模型能不能直接把所有的元數(shù)據(jù)喂給它，不需要再做元數(shù)據(jù)分片的工作，讓它去生成 SQL。當然，關于 long-context 大模型的效果，大家也還在觀望中，這種大模型的注意力在于頭尾，中間的信息可能會缺失，所以這也是我們關注的一個點。

數(shù)造科技專注于數(shù)據(jù)治理、DataOps、數(shù)據(jù)開發(fā)，是新一代敏捷數(shù)據(jù)管理平臺的供應商，具有大數(shù)據(jù)賦能能力。

我們的產品是一站式的數(shù)據(jù)開發(fā)管控平臺，包括數(shù)據(jù)治理、血緣圖譜的構建，還有自動化標準數(shù)據(jù)治理的工具，以及行業(yè)大數(shù)據(jù)解決方案。