NL2SQL（Natural Language to SQL）是一項將用戶的自然語句轉(zhuǎn)為可執(zhí)行 SQL 語句的技術，有很大的實際應用價值，對改善用戶與數(shù)據(jù)庫之間的交互方式有很大意義。在本文中，追一科技介紹了 NL2SQL 的價值，及其過去、現(xiàn)在與未來，希望能有更多關于 NL2SQL 的落地場景研究。在 AI、區(qū)塊鏈、IoT、AR 等高新技術飛速發(fā)展的當下，這一寶庫似乎被大家遺忘在了角落。數(shù)據(jù)庫存儲了大量的個人或者企業(yè)的生產(chǎn)運營數(shù)據(jù)，我們每天都會和數(shù)據(jù)庫產(chǎn)生或多或少的交互。通常，查詢數(shù)據(jù)庫中的數(shù)據(jù)需要通過像 SQL 這樣的程序式查詢語言來進行交互，這就需要懂 SQL 語言的專業(yè)技術人員來執(zhí)行這一操作。為了讓非專業(yè)用戶也可以按需查詢數(shù)據(jù)庫，當前流行的技術方案設計了基于條件篩選的專門界面，用戶可以通過點選不同的條件來查詢數(shù)據(jù)庫，比如下面這個篩選汽車的界面。然而，在這個界面上操作，極大地限制了數(shù)據(jù)庫查詢的使用場景和查詢界限。同時，即使對于精通數(shù)據(jù)庫程序語言的專業(yè)人士，經(jīng)常構(gòu)思 SQL 語句、維護這樣一個查詢界面也是一項重復度較高的工作。在 CUI（Conversation User Interface）的大背景下，如何通過自由地查詢數(shù)據(jù)庫中的目標數(shù)據(jù)成為了新興的研究熱點。Natural Language to SQL (NL2SQL) 就是這樣的一項技術，它可以將用戶的自然語句轉(zhuǎn)為可以執(zhí)行的 SQL 語句。Nothing is better than an example. 針對上圖這樣的數(shù)據(jù)庫表格，用戶可能會想知道「寶馬的車總共賣了多少輛？」，其相應的 SQL 表達式是「SELECT SUM(銷量) FROM TABLE WHERE 品牌==」寶馬」;」。而 NL2SQL 做的，就是結(jié)合用戶想要查詢的表格，將用戶的問句轉(zhuǎn)化為相應的 SQL 語句，從而得到答案「8」。表格數(shù)據(jù)是信息在經(jīng)過人為整理、歸納后的一種高效的結(jié)構(gòu)化表達形式，信息的價值、密度和質(zhì)量高于普通的文字文本。用很多文字才能描述清楚的信息，可能一張表格就夠了。在行業(yè)研報、業(yè)績報告、新聞公告、使用說明書等各種書面信息載體上，尤其是金融、快消等行業(yè)的各種報告中，充斥著許多表格形式的。而當用戶去查詢表格中的內(nèi)容時，需要肉眼去從表格中篩選滿足條件的數(shù)據(jù)，準確率和效率都較低。通過 NL2SQL，用戶在查詢這些表格的內(nèi)容時，可以直接通過自然語言與表格進行交互，并得到結(jié)果，用戶體驗會很自然。比如下面這張出自某房地產(chǎn)行業(yè)研報的表格：針對這張表格，用戶可能會想問「哪些城市的全月銷量同比超過了 50% 或者當日環(huán)比大于 25%？相應的房產(chǎn)類型和銷售面積情況如何？」這樣的問題。通過 NL2SQL 模型，可以直接得到相應的 SQL 語句「select 城市, 類型, 全月數(shù)值 (萬平) from table where 全月同比 (%) > 50 or 當日環(huán)比 (%) > 25」，并進一步返回執(zhí)行該 SQL 語句后的結(jié)果，如下表所示：如今，在很多日常應用場景中，用戶都會和數(shù)據(jù)庫進行交互，比如訂餐、訂票、查天氣、查報表等等，絕大部分的解決方案也是通過輸入條件和點選條件來進行查詢。即使部分場景已經(jīng)進行了技術升級，可以通過對話機器人的方式來進行交互，但其背后仍然預設了不同的條件入口，需要模型通過一系列的實體識別、槽值提取等流程來填充預先規(guī)定好的 SQL 模板。對于這樣的方案，不僅查詢的信息和篩選的條件會局限于預先設好的字段，這些功能模塊的開發(fā)和維護也需要大量的人力資源。而如果使用 NL2SQL 的技術方案，用戶與數(shù)據(jù)庫之間的距離可以進一步縮短，用戶可以更自由地查詢更多信息、表達自己更豐富的查詢意圖，還可以減輕目前技術方案的繁瑣，解放程序員。NL2SQL 不僅可以獨當一面，降低人機交互的距離和門檻，也可以與其它技術相輔相成。比如，現(xiàn)今的機器閱讀理解技術已經(jīng)可以在 SQUAD 1.0、SQUAD 2.0 等數(shù)據(jù)集上超越人類水平，還可以在其它各種形式的數(shù)據(jù)集上尋找答案，比如多段落、多文檔、抽取式答案、生成式答案等形式。但目前機器閱讀理解技術還不能對文章中出現(xiàn)的表格進行解讀，如果用戶想要的答案存在于文章中的表格內(nèi)，那么現(xiàn)有的模型就都束手無策了。然而表格數(shù)據(jù)在真實場景中存在很多，且表格中的數(shù)據(jù)很有價值，用戶也會經(jīng)常針對其中的數(shù)據(jù)進行提問。比如下圖中的這一真實場景，用戶如果想問「在哪些年里平均溢價率高于 20%」這樣的問題，依靠現(xiàn)有的機器閱讀理解技術，在文本中是找不到答案的。而 NL2SQL 可以很好地彌補現(xiàn)有技術的不足，完善非結(jié)構(gòu)化文本問答在真實落地場景中的應用，更充分地發(fā)掘此類結(jié)構(gòu)化數(shù)據(jù)的價值。研報部分來源于東吳證券《房地產(chǎn)行業(yè) 2019 年度策略》存儲在 Excel 中的表格數(shù)據(jù)也可以被利用起來。設想一下這樣的場景，財務人員將日常的財務數(shù)據(jù)存儲在 Excel 中，日積月累產(chǎn)生了大量的 Excel 文件。財務人員需要了解其中的數(shù)據(jù)時，首先要從層層深入的文件夾、密密麻麻的 Excel 中找到正確的文件，然后打開 Excel 文件去密集的單元格中找到想要的答案。在這個過程中找錯文件是常事，效率十分低下。如果利用 NL2SQL 技術，這一場景就會非常的優(yōu)雅高效：首先定位預處理存入數(shù)據(jù)庫的表格，再執(zhí)行查詢邏輯，最后將結(jié)果直接返回。我們可以期待，NL2SQL 將改變傳統(tǒng)的人與表格之間的交互方式，作為不可或缺的功能來改善人與機器之間的交流，讓這場 CUI 升級革命可以走進更多的場景、行業(yè)，惠及更廣泛的群體。早在上世紀中后期，人們就已經(jīng)在嘗試開發(fā)通過自然語言直接訪問數(shù)據(jù)庫中存儲數(shù)據(jù)的界面了（NLIDB，Natural Language Interfaces to Databases），其中最知名的是二十世紀六十年代的 LUNAR 系統(tǒng)，它通過對問句的句式語法分析，來回答關于從阿波羅任務中帶回的月巖的地質(zhì)學分析問題。再比如二十世紀七十年代初的 LADDER 系統(tǒng)，它已經(jīng)支持通過一定的語義語言從數(shù)據(jù)庫提取信息。但這種系統(tǒng)對自然語言問題的解析并不依賴于句子成分，這要求每一個具有特定知識的數(shù)據(jù)庫都需要特定的語義語法，所以該方法在普適性上不夠完善。受限于當時技術發(fā)展，NLIDB 面臨很大的挑戰(zhàn)，系統(tǒng)語言的支持上限以及對于語言的理解上限不明確、語言上邏輯和含義的歧義、生僻詞的出現(xiàn)等，以及替代品的發(fā)展（如 Excel 表格這種存儲表格新形式的出現(xiàn)），這些都極大限制了這個領域的發(fā)展。直到 2015 年 AI 的復蘇和自然語言處理的創(chuàng)新，人們才慢慢把關注拉回了 NLIDB。如何利用自然語言更自然更自由地與數(shù)據(jù)庫交互成為了新興的研究熱點。那 NL2SQL 在學術中的定位是怎么樣的呢？NL2SQL 這一任務的本質(zhì)，是將用戶的自然語言語句轉(zhuǎn)化為計算機可以理解并執(zhí)行的規(guī)范語義表示 (formal meaning representation)，是語義分析 (Semantic Parsing) 領域的一個子任務。NL2SQL 是由自然語言生成 SQL，那么自然也有 NL2Bash、NL2Python、NL2Java 等類似的研究。下面是來自 NL2Bash Dataset 的一條數(shù)據(jù)：NL: Search for the string ‘git’ in all the files under current directory tree without traversing into ‘.git’ folder and excluding files that have ‘git’ in their names.Bash: find . -not -name '.git' -not -path '*.git*' -not –name '*git*' | xargs -I {} grep git {}雖然生成的程序語言不同，但核心任務與 NL2SQL 相同，都是需要計算機理解自然語言語句，并生成準確表達語句語義的可執(zhí)行程序式語言。廣義來說，KBQA 也與 NL2SQL 技術有著千絲萬縷的聯(lián)系，其背后的做法也是將用戶的自然語言轉(zhuǎn)化為邏輯形式，只不過不同點在于前者轉(zhuǎn)化的邏輯形式是 SPARQL，而不是 SQL。將生成的查詢語句在知識圖譜執(zhí)行，直接得到用戶的答案，進而提升算法引擎的用戶體驗。目前，NL2SQL 方向已經(jīng)有 WikiSQL、Spider、WikiTableQuestions、ATIS 等諸多公開數(shù)據(jù)集。不同數(shù)據(jù)集都有各自的特點，這里簡單介紹一下這四個數(shù)據(jù)集。WikiSQL 是 Salesforce 在 2017 年提出的大型標注 NL2SQL 數(shù)據(jù)集，也是目前規(guī)模最大的 NL2SQL 數(shù)據(jù)集。它包含了 24,241 張表、80,645 條自然語言問句及相應的 SQL 語句。下圖是其中的一條數(shù)據(jù)樣例，包括一個 table、一條 SQL 語句及該條 SQL 語句所對應的自然語言語句。該數(shù)據(jù)集自提出之后，已經(jīng)有 18 次公開提交。由于 SQL 的形式較為簡單，該數(shù)據(jù)集不涉及高級用法，Question 所對應的正確表格已經(jīng)給定，不需要聯(lián)合多張表格，這些簡化使得強監(jiān)督模型已經(jīng)可以在 WikiSQL 上達到執(zhí)行 91.8% 的執(zhí)行準確率。Spider 是耶魯大學 2018 年新提出的一個較大規(guī)模的 NL2SQL 數(shù)據(jù)集。該數(shù)據(jù)集包含了 10,181 條自然語言問句、分布在 200 個獨立數(shù)據(jù)庫中的 5,693 條 SQL，內(nèi)容覆蓋了 138 個不同的領域。雖然在數(shù)據(jù)數(shù)量上不如 WikiSQL，但 Spider 引入了更多的 SQL 用法，例如 Group By、Order By、Having，甚至需要 Join 不同表，這更貼近真實場景，也帶來了更高的難度。因此目前在該榜單上只有 8 次提交，在不考慮條件判斷中 value 的情況下，準確率最高只有 54.7，可見這個數(shù)據(jù)集的難度非常大。上圖是該數(shù)據(jù)集中的一條樣例。在這個以 College 為主題的數(shù)據(jù)庫中，用戶詢問「講師的工資高于平均工資水平的部門以及相應的預算是什么？」，模型需要根據(jù)用戶的問題和已知的數(shù)據(jù)庫中各種表格、字段及其之間錯綜復雜的關系來生成正確的 SQL。WikiTableQuestions 是斯坦福大學于 2015 年提出的一個針對維基百科中那些半結(jié)構(gòu)化表格問答的數(shù)據(jù)集，包含了 22,033 條真實問句以及 2,108 張表格。由于數(shù)據(jù)的來源是維基百科，因此表格中的數(shù)據(jù)是真實且沒有經(jīng)過歸一化的，一個 cell 內(nèi)可能包含多個實體或含義，比如「Beijing, China」或「200 km」；同時，為了很好地泛化到其它領域的數(shù)據(jù)，該數(shù)據(jù)集測試集中的表格主題和實體之間的關系都是在訓練集中沒有見到過的。下圖是該數(shù)據(jù)集中的一條示例，數(shù)據(jù)闡述的方式展現(xiàn)出作者想要體現(xiàn)的問答元素。The Air Travel Information System (ATIS) 是一個年代較為久遠的經(jīng)典數(shù)據(jù)集，由德克薩斯儀器公司在 1990 年提出。該數(shù)據(jù)集獲取自關系型數(shù)據(jù)庫 Official Airline Guide (OAG, 1990)，包含 27 張表以及不到 2,000 次的問詢，每次問詢平均 7 輪，93% 的情況下需要聯(lián)合 3 張以上的表才能得到答案，問詢的內(nèi)容涵蓋了航班、費用、城市、地面服務等信息。下圖是取自該數(shù)據(jù)集的一條樣例，可以看出比之前介紹的數(shù)據(jù)集更有難度。圖片來自于 http://www./anthology/H90-1021在深度學習端到端解決方案流行之前，這一領域的解決方案主要是通過高質(zhì)量的語法樹和詞典來構(gòu)建語義解析器，再將自然語言語句轉(zhuǎn)化為相應的 SQL。圖片來自于 Natural Language Interfaces to Databases（https:///pdf/cmp-lg/9503016.pdf）現(xiàn)在的解決方案則主要是端到端與 SQL 特征規(guī)則相結(jié)合。以在 WikiSQL 數(shù)據(jù)集上的 SOTA 模型 SQLova 為例：首先使用 BERT 對 Question 和 SQL 表格進行編碼和特征提取，然后根據(jù)數(shù)據(jù)集中 SQL 語句的句法特征，將預測生成 SQL 語句的任務解耦為 6 個子任務，分別是 Select-Column、Select-Aggregation、Where-Number、Where-Column、Where-Operation 以及 Where-Value，不同子任務之間存在一定的依賴關系，最終使用提取到的特征依次進行 6 個任務的預測。圖片來自于 SQLNet（https:///pdf/1711.04436.pdf）WikiSQL 數(shù)據(jù)集雖然是目前規(guī)模最大的有監(jiān)督數(shù)據(jù)集，但其數(shù)據(jù)形式和難度過于簡單：對于 SQL 語句，條件的表達只支持最基礎的>、<、=，條件之間的關系只有 and，不支持聚組、排序、嵌套等其它眾多常用的 SQL 語法，不需要聯(lián)合多表查詢答案，真實答案所在表格已知等，所以在這個數(shù)據(jù)集上，SQL 執(zhí)行結(jié)果的準確率目前已經(jīng)達到了 91.8%。圖片來自于 WikiSQL（https://github.com/salesforce/WikiSQL）但存在一個問題，這樣的數(shù)據(jù)集并不符合真實的應用場景。在真實場景中，用戶問題中的值很可能不是數(shù)據(jù)表中所出現(xiàn)的，需要一定的泛化才可以匹配到；真實的表之間存在錯綜復雜的鍵關聯(lián)關系，想要得到真實答案，通常需要聯(lián)合多張表進行查詢；每張表都有不同的意義，并且每張表中列的意義也各不不同，甚至可能相同名字的列在不同的表格中所代表的含義也是不同的；真實場景中，用戶的問題表達會很豐富，會使用各種各樣的條件來篩選數(shù)據(jù)。諸如此類的實際因素還有很多。因此，WikiSQL 數(shù)據(jù)集起到的作用很大程度上是拋磚引玉，而不具備實際應用場景落地的價值。相比之下，Spider 等數(shù)據(jù)集更貼近真實應用場景：涉及到查詢語句嵌套、多表聯(lián)合查詢，并且支持幾乎所有 SQL 語法的用法，用戶問句的表達方式和語義信息也更豐富。但即使作者們考慮到數(shù)據(jù)集的難度，貼心地將數(shù)據(jù)集按照難度分為簡單、中等和困難，該數(shù)據(jù)集的難度也依然讓人望而生畏，目前各項指標也都很低。如何更好地結(jié)合數(shù)據(jù)庫信息來理解并表達用戶語句的語義、如何編碼及表達數(shù)據(jù)庫的信息、如何生成復雜卻有必要的 SQL 語句，此類挑戰(zhàn)還有很多需要解決，它們都是非常值得探索的方向。現(xiàn)在很多 NLP 子任務的指標已經(jīng)刷得讓人無路可走了，低垂的果實被摘得七零八落。而 NL2SQL 以及其它的語義分析任務，因為各種各樣的原因，現(xiàn)在還沒有引起大家足夠的關注，但它們有著相比于其它任務更高的實際應用價值。如果可以落地真實場景，這將極大地改變現(xiàn)有的用戶和數(shù)據(jù)庫之間的交互方式，人們可以自由地和數(shù)據(jù)庫進行交互，充分挖掘數(shù)據(jù)的價值，也減輕程序員的負擔。學界和工業(yè)界也越來越關注這方面的研究，追一科技 6 月份將發(fā)起首屆中文 NL2SQL 挑戰(zhàn)賽，期待 NL2SQL 在不遠的將來會迎來屬于自己的春天，學術應用兩開花。  WikiSQL：https://github.com/salesforce/WikiSQL Spider：https://yale-lily./spider ATIS：https://www./siddhadev/ms-cntk-atis WikiTableQuestions：https://github.com/ppasupat/WikiTableQuestions
SQLova：https://github.com/naver/sqlova SQLNet：https://github.com/xiaojunxu/SQLNet SyntaxSQL：https://github.com/taoyds/syntaxsql
Text2SQL 資源匯總：https://github.com/jkkummerfeld/text2sql-data NLIDB 背景：http:///2017/12/natural-language-interfaces-to-databases-nlidb/ ACL Semantic Parsing Tutorial：https://github.com/allenai/acl2018-semantic-parsing-tutorial
|
