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