人工智慧時代如何高效發掘資料庫的價值?NL2SQL值得你關注
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。
※ARM推出下一代旗艦晶元架構,GPU提升60%,「NPU」即將上線
※性能碾壓,價格僅為英特爾一半:AMD推出全新Ryzen旗艦處理器
TAG:機器之心 |