基于自然語言處理和深度學(xué)習(xí)的NL2SQL技術(shù)及其在BI增強(qiáng)分析中的應(yīng)用

劉譯璟 徐林杰 代其鋒

一、引言

1996年，Gartner提出BI的概念，隨即成為了數(shù)據(jù)分析的重要技術(shù)。直到今天，BI也是企業(yè)首選的數(shù)據(jù)分析應(yīng)用。但隨著企業(yè)數(shù)據(jù)規(guī)模和復(fù)雜度日益增大，現(xiàn)在數(shù)據(jù)分析人員越來越難從海量的數(shù)據(jù)中找到有價值的結(jié)論。在這種背景下，Garnter于2017年提出了增強(qiáng)分析的概念：“增強(qiáng)分析是利用機(jī)器學(xué)習(xí)和 AI 等技術(shù)來幫助數(shù)據(jù)準(zhǔn)備、洞察生成和洞察解釋，以增強(qiáng)人們在分析和 BI平臺中探索和分析數(shù)據(jù)。” 2018年，Gartner 在其發(fā)布的魔力象限報告中，明確指出增強(qiáng)型分析功能是 BI 產(chǎn)品發(fā)展的最重要、也是最顯著的發(fā)展趨勢之一，其原因并不難理解：“當(dāng)前企業(yè)使用的數(shù)據(jù)的規(guī)模和復(fù)雜度已經(jīng)逐漸超過人類可以處理的程度，靜態(tài)報表、儀表板等傳統(tǒng)工具已經(jīng)不能滿足需求，而通過機(jī)器學(xué)習(xí)、人工智能等技術(shù)增強(qiáng)分析，可以更好地處理這些數(shù)據(jù)。而如果利用自然語言處理、人工智能等技術(shù)的增強(qiáng)分析就可以自動、快速地對數(shù)據(jù)進(jìn)行分析，輔助分析人員得到需要的數(shù)據(jù)洞察?！?/p>

實(shí)際上，百分點(diǎn)在自身的業(yè)務(wù)發(fā)展中也得出了與Garnter同樣的觀點(diǎn)。作為諸多企業(yè)第最重要的大數(shù)據(jù)應(yīng)用，我們認(rèn)為BI經(jīng)歷了三個階段：

1990～2003年是第一階段。這一階段的特點(diǎn)是技術(shù)主導(dǎo)，數(shù)據(jù)建模特別是數(shù)據(jù)倉庫建模的建設(shè)實(shí)施占據(jù)了BI項(xiàng)目的絕大多是時間和資源。而BI主要作為一種數(shù)據(jù)呈現(xiàn)的手段供極少數(shù)決策者使用。這時候的BI可以說是九成技術(shù)加一成業(yè)務(wù)；

2003年～2016年是第二階段。這一階段的特點(diǎn)是數(shù)據(jù)分析師主導(dǎo)，敏捷式BI開始流行。以Tableau為代表的BI工具逐步讓數(shù)據(jù)分析不再是一個純技術(shù)工作，而是技術(shù)+業(yè)務(wù)的混合工作。這時候可以說BI是五成技術(shù)加五成業(yè)務(wù)；

2017年開始是第三階段，我們正在經(jīng)歷這個階段。這個階段的特點(diǎn)是數(shù)據(jù)分析平民化、普惠化，技術(shù)工作將主要集中在數(shù)據(jù)準(zhǔn)備和數(shù)據(jù)治理方面，絕大多數(shù)數(shù)據(jù)分析工作都將由業(yè)務(wù)人員主導(dǎo)。未來的BI必定是一成技術(shù)加九成業(yè)務(wù)。相應(yīng)的，BI的理論、技術(shù)和工具將有新一輪的升級改造。

正是看到了這些趨勢，百分點(diǎn)在2017年開始自主研發(fā)增強(qiáng)分析BI工具CleverBI，我們期望通過引入自然語言處理、知識圖譜、推薦算法和機(jī)器問答等人工智能技術(shù)，使得CleverBI可以理解用戶的數(shù)據(jù)分析需求，并幫助其快速完成分析任務(wù)獲得數(shù)據(jù)洞見。

智能問答功能是CleverBI中的一個重要功能，它允許用戶以自然語言和語音的方式與系統(tǒng)進(jìn)行交互式對話，系統(tǒng)分析對話內(nèi)容提取出用戶的數(shù)據(jù)分析意圖，而后自動從數(shù)據(jù)庫中提取數(shù)據(jù)、計算得到結(jié)果并進(jìn)行可視化展現(xiàn)。譬如用戶在系統(tǒng)中提問“2015年各地區(qū)的銷售額”，系統(tǒng)自動就能展示如下圖：

可以看出，智能問答實(shí)際上是一種特定的語義分析任務(wù)。在學(xué)術(shù)界，類似的任務(wù)最早可以追溯到1970年代提出的自然語言編程（Natural-language programming），是指將自然語言（研究比較多的是英語）翻譯為特定的編程語言。在1980年代，人們又針對關(guān)系性數(shù)據(jù)庫提出了自然語言數(shù)據(jù)庫查詢（Natural Language Database Query），也稱為Text2SQL、NL2SQL等，現(xiàn)在這個領(lǐng)域變得越來越熱門。目前，業(yè)內(nèi)比較知名的是WikiSQL和Spider數(shù)據(jù)集及其相關(guān)研究成果。可惜的是，中文目前還沒有統(tǒng)一的數(shù)據(jù)集，最近追一科技發(fā)布了一個10W級別的中文數(shù)據(jù)集用于其NL2SQL挑戰(zhàn)賽，我們認(rèn)為這個數(shù)據(jù)集有望成為中文數(shù)據(jù)集的標(biāo)準(zhǔn)。

在 WikiSQL 數(shù)據(jù)集上，Leaderboard 中的方法都是把NL2SQL任務(wù)轉(zhuǎn)化為槽值填充，然后利用深度學(xué)習(xí)的方法訓(xùn)練多個不同的子模型對每個槽位進(jìn)行填充，比如作為SOTA模型的X-SQL，而追一數(shù)據(jù)集上的 SOTA 模型M-SQL 采用的是和 X-SQL 類似的結(jié)構(gòu)，但是為了提高過濾條件值的提取和匹配準(zhǔn)確度，對模型結(jié)構(gòu)進(jìn)行了修改。雖然在WikiSQL 數(shù)據(jù)集和追一科技的數(shù)據(jù)集上，機(jī)器學(xué)習(xí)模型的效果已經(jīng)超越了人類，但這兩個數(shù)據(jù)集過于簡單，很難覆蓋真實(shí)應(yīng)用場景。比如WikiSQL只支持1個查詢目標(biāo)（select）、1個聚合函數(shù)、最多4個過濾條件，且不支持分組。但是在實(shí)際使用中，有多個查詢目標(biāo)以及包含分組字段的問題比比皆是，比如“各省份的人口”，“每年的人口”，所以只采用 X-SQL 的方法是無法滿足工業(yè)的需要。

Spider 數(shù)據(jù)集中支持對分組進(jìn)行提問，而且支持跨表join，但是 SOTA 模型的測試準(zhǔn)確率只有55%，還無法滿足產(chǎn)品化的效果。

同時需要注意的是，在實(shí)際應(yīng)用中，時間是一個很特殊并且重要的提問維度，比如用戶可能會問“近七天的總銷售額”，“2019/2018年的銷售額”，“今年前三個季度的總銷售額”等等，但關(guān)于時間的問題在上述數(shù)據(jù)集中都沒有覆蓋。

綜上所述，考慮到已有數(shù)據(jù)集的局限性以及其上SOTA模型的能力。我們要想在CleverBI中實(shí)現(xiàn)比較好的智能問答功能，就必須針對CleverBI的場景定制新的技術(shù)和算法。這就需要我們的模型既能準(zhǔn)確的提取問題中的槽位信息，又需要無監(jiān)督的語義分析方法。所以我們綜合了X-SQL和依存句法兩種技術(shù)，首先采用X-SQL槽位匹配的方法提取出問題中的select、where 內(nèi)容，然后利用這些信息輔助依存句法樹的解析，最終得到完整的select、where、group、order 等內(nèi)容。而針對提問中的時間維度，我們采用定制模板的方法來處理，準(zhǔn)確度和擴(kuò)展性都能很好的保障。

下面的內(nèi)容中，我們首先在第二節(jié)簡介CleverBI智能問答的整體架構(gòu)，在第三節(jié)介紹語義解析模塊的流程，在第四節(jié)介紹最核心的問題解析模塊的算法和流程，在第五節(jié)介紹我們的方法的實(shí)驗(yàn)效果，最后在第六屆進(jìn)行展望和進(jìn)一步研究討論。

二、CleverBI智能問答架構(gòu)

上圖展示了CleverBI智能問答功能的整體架構(gòu)，它主要包括三大部分：

（一）智能問答服務(wù)

用于接收來自BI后臺的請求，并且返回解析完成的結(jié)果。

（二）數(shù)據(jù)庫讀寫服務(wù)、離線調(diào)度服務(wù)、計算引擎等

后臺在元數(shù)據(jù)發(fā)生變更時，會調(diào)用讀寫服務(wù)。讀寫服務(wù)的目的是在本地MySQL 數(shù)據(jù)庫中的元數(shù)據(jù)發(fā)生變動時對緩存進(jìn)行更新。并且利用計算引擎重新計算枚舉值和數(shù)據(jù)樣例，將最新結(jié)果存入本地 MySQL數(shù)據(jù)庫中。

在智能問答中，需要利用第三方數(shù)據(jù)的枚舉值和數(shù)據(jù)樣例信息，輔助進(jìn)行語義解析。所以當(dāng)表的元數(shù)據(jù)發(fā)生變更時，需要重新進(jìn)行計算。同時，為了保證枚舉值的時效性，還需要一個離線調(diào)度服務(wù)定期自動計算枚舉值，并且將結(jié)果存入 MySQL數(shù)據(jù)庫。計算枚舉值時采用如下公式：

就是某個字段的不重復(fù)率，如果 ，則表示該字段是一個枚舉值字段，該字段的不重復(fù)值就是所謂的枚舉值。

計算引擎是一個統(tǒng)一的生成數(shù)據(jù)庫查詢語句并且提交數(shù)據(jù)庫執(zhí)行的程序，它提供統(tǒng)一的對外接口，但是支持在 MySQL、PostgreSQL、Oracle、Sql Server、MongoDB、Vertica、ClickHouse 數(shù)據(jù)庫中進(jìn)行查詢。

（三）語義解析服務(wù)

這是智能問答服務(wù)的核心部分，它會把BI后臺的參數(shù)，以及從數(shù)據(jù)服務(wù)中得到的數(shù)據(jù)整理成語義解析需要的結(jié)構(gòu)，然后利用語義解析的流程解析得到最終的結(jié)果。下一節(jié)將介紹它是如何工作的。

三、語義解析流程

上圖是智能問答功能中語義解析服務(wù)的工作流程，可以看出，當(dāng)接受到一個用戶提問時，系統(tǒng)會經(jīng)過如下處理：

（一）找表

由于智能問答支持用戶不指定具體的數(shù)據(jù)表就進(jìn)行提問，所以語義解析的第一步就是要定位到哪個（些）數(shù)據(jù)表是適合用戶的問題的，只有確定了表，后續(xù)的解析工作才能開展。為了能夠準(zhǔn)確快速地從所有數(shù)據(jù)表中匹配出需要的表，需要結(jié)合精確匹配策略和模糊匹配策略：

1. 首先執(zhí)行精確匹配

精確匹配時，在離線任務(wù)中需要把表的字段名、枚舉值、實(shí)體標(biāo)簽按字級別構(gòu)建成倒排索引。倒排索引的內(nèi)容如下：

鍵：字段名、枚舉值的字，或者 ${PER}、${ORG}等標(biāo)簽；

值：（包含鍵的表id，該字出現(xiàn)位置列表）的集合，該字所在位置列表是指將字段名，枚舉值按字典序排序之后，該字出現(xiàn)的所有位置所組成的列表。

實(shí)體標(biāo)簽包括人名、地名、組織名、電話、郵箱和時間。通過對數(shù)據(jù)樣例進(jìn)行命名實(shí)體識別或者正則表達(dá)式匹配求得，我們采用的是 pyltp 庫判斷數(shù)據(jù)樣例的實(shí)體標(biāo)簽（人名、地名、組織名標(biāo)簽），通過正則表達(dá)式判斷電話、郵箱和時間標(biāo)簽。由于一條樣例數(shù)據(jù)可能是短文本，命名實(shí)體識別效果不佳，所以采用下面的公式判斷：

其中 question 為問題中的字和實(shí)體標(biāo)簽的集合，table 為表的字段名、枚舉值中的字和實(shí)體標(biāo)簽的集合，invert_index 為倒排索引，注意在對其取交集時只以表id為依據(jù)。

上述方式?jīng)]有考慮字的位置，在某些情況下會出錯。比如問題是“總銷售金額”，其中一張表中包含“銷售額”字段，另一個表中有“銷售人”、“保證金”、“總額”。合理的方式是匹配到第一張表，但是上述方式會匹配到第二張表。把字位置的因素考慮進(jìn)來，得到改進(jìn)后的相似度計算公式：

其中 position_diff 的計算方式為，將問題中匹配出來的字按順序排列，計算在倒排索引中記錄的距離的差分序列之和。

通過這種方式，最后進(jìn)行倒序排序就能夠得到精確匹配下的最佳匹配表了。

但是在問題非常靈活的情況下，經(jīng)常出現(xiàn)所有表的similarity都為零的情況，在這種情況下，就需要采用模糊匹配得到最優(yōu)的表。

2. 精確匹配無法找到數(shù)據(jù)表時，利用模糊匹配尋找最優(yōu)表

此時首先對問題進(jìn)行分詞，然后在問題上使用長度為3的滑動窗口從左向右滑動，每滑動一次，計算窗口內(nèi)的詞的向量和預(yù)先算好的表向量之間的相似度。在上面的過程中，都是通過word2vec 對詞進(jìn)行向量化。當(dāng)窗口滑動完畢，每個窗口相似度的最大值就是表的分?jǐn)?shù)，最后得分最大的表就是所要匹配的表。

經(jīng)過精確匹配和模糊匹配的結(jié)合，我們會確定在哪張數(shù)據(jù)表上來回答用戶的提問。

（二）數(shù)據(jù)預(yù)處理

在這一步，我們對問題進(jìn)行分詞、詞性標(biāo)注、實(shí)體識別和依存句法分析，提取出一系列的問題要素送到后續(xù)問題解析模塊。

（三）問題解析

這是語義解析的核心，它負(fù)責(zé)將預(yù)處理得到的問題要素翻譯為如下面例子的數(shù)據(jù)結(jié)構(gòu)：

這個數(shù)據(jù)結(jié)構(gòu)中包含了需要查詢的字段、查詢結(jié)果數(shù)量、排序和分組要求，并且說明了必要的指標(biāo)和維度，信息非常豐富。不難看出這個數(shù)據(jù)結(jié)構(gòu)是非常容易轉(zhuǎn)化為SQL語句的我們會在下一節(jié)詳細(xì)介紹問題解析模塊是如何獲得這個數(shù)據(jù)結(jié)構(gòu)的。

（四）圖表匹配

圖表匹配是指問題解析得到上面的數(shù)據(jù)結(jié)構(gòu)后，找到最適合用戶提問的圖表類型，以便最后進(jìn)行數(shù)據(jù)展示。圖表類型包括表格、柱狀圖、散點(diǎn)圖、折線圖、餅圖、桑基圖等。由于每種圖表都有相應(yīng)的維度、指標(biāo)個數(shù)要求，為此我們設(shè)定了一個規(guī)則集來描述這些要求。規(guī)則集中每條規(guī)則都是以維度和指標(biāo)為條件，圖表類型為結(jié)果的。例如“如果維度個數(shù)>=0并且指標(biāo)個數(shù)>=0，那么用表格”。規(guī)則的順序需要按照圖表的使用頻率人為確定，在下面的規(guī)則匹配時這個順序是很重要的，因?yàn)橄到y(tǒng)會從第一條規(guī)則開始逐個匹配，直到碰到滿足條件的圖表類型。

在圖表匹配模塊，我們采用的是“先關(guān)鍵詞后規(guī)則”匹配過程：首先進(jìn)行關(guān)鍵詞匹配。關(guān)鍵詞匹配是指根據(jù)提問中的關(guān)鍵詞找到對應(yīng)的圖表類型。這需要預(yù)制關(guān)鍵詞庫，詞庫的格式為“詞：對應(yīng)的圖表類型”，比如“占比：餅圖”，“趨勢：折線圖”，“比例：餅圖”。通過關(guān)鍵詞庫在問題上進(jìn)行匹配，如果匹配成功，就得到了候選圖表類型。如果該候選圖表類型滿足對應(yīng)的圖表類型規(guī)則，那么候選圖表類型就是所需要的結(jié)果。否則系統(tǒng)直接使用規(guī)則的方式得到需要的圖表類型。

四、基于X-SQL和依存句法樹的問題解析

本節(jié)介紹語義解析中最重要的問題解析模塊的實(shí)現(xiàn)技術(shù)。

問題解析是一個典型的NL2SQL任務(wù)。將自然語言轉(zhuǎn)化成 SQL 本身可以認(rèn)為是一個 Seq2Seq 的任務(wù)，所以在 WikiSQL 中很多早期模型也確實(shí)是這么做的，比如Corse2fine[ ]，它會對問題和字段名進(jìn)行編碼，然后利用中間的預(yù)解碼層將向量解碼為 SQL 的框架，這個過程就能相當(dāng)于自動生成了槽位模板，最后再把槽位模板也進(jìn)行編碼，結(jié)合原始的向量，最后能夠解碼出最終的 SQL。但是這樣生成的結(jié)果不一定符合 SQL 的語法規(guī)則，所以后面改進(jìn)的生成方法都是事先寫好SQL 的模板槽，然后再用多個模型逐個預(yù)測槽位，X-SQL[ ] 就是其中效果最好的一種。

X-SQL 的大體流程如下圖所示，通過 MT-DNN 對原始問題以及字段名稱進(jìn)行編碼，但是在問題前面人為添加一個 [CXT] 用于提取全局信息。中間的 Context Reinforcing Laryer 層是這個模型的核心部分，它的目的是把 MT-DNN 得到的預(yù)訓(xùn)練編碼在 NL2SQL 任務(wù)上進(jìn)行增強(qiáng)和重組。這個層包括體現(xiàn)上下文信息的 h[CXT]，以及通過 Attention機(jī)制對字段名稱的編碼進(jìn)行強(qiáng)化（紫色部分）。這一層輸出的結(jié)果包括問題的編碼，以及強(qiáng)化后的字段編碼，后面的輸出層都在這個基礎(chǔ)上進(jìn)行。 輸出層包括了6個子模型：S-COL和S-AGG 用于預(yù)測 select的字段，只依賴于強(qiáng)化后的字段名稱編碼，通過 softmax對每個字段打分就行了。W-NUM 只依賴全局信息h[CXT]，用于預(yù)測 where 條件個數(shù)。W-COL、W-OP和W-VAL 用于預(yù)測過濾條件的具體內(nèi)容，通過組合字段編碼，當(dāng)前的 where 條件編號以及問題編碼，通過softmax評分就能得到需要的結(jié)果。

這個架構(gòu)已經(jīng)十分完善了，但是由于數(shù)據(jù)的局限，模型無法預(yù)測多個 select 以及 group 的內(nèi)容。而且模型完全依賴字段名稱去提取過濾條件和select的內(nèi)容，在中文字段名稱特征不夠明顯或者領(lǐng)域數(shù)據(jù)和訓(xùn)練數(shù)據(jù)偏差較大時，容易出錯。

另外，傳統(tǒng)的語法分析一般依賴于依存句法分析的結(jié)果，能夠把問題的語法依賴關(guān)系體現(xiàn)出來，在此基礎(chǔ)上結(jié)合 POS，NER 的結(jié)果，可以使依存語法樹上的每個節(jié)點(diǎn)都具有詞性、實(shí)體標(biāo)簽等屬性。然后通過后序遍歷，每次遍歷到父節(jié)點(diǎn)的時候，都將孩子節(jié)點(diǎn)的以及當(dāng)前父節(jié)點(diǎn)的內(nèi)容通過規(guī)則進(jìn)行整理合并，最終遍歷到根節(jié)點(diǎn)的時候，就得到了select、group 等要素。這種方法的好處是它完全依賴于問題的語法規(guī)則，不需要訓(xùn)練數(shù)據(jù)，并且對于領(lǐng)域不敏感，遷移性強(qiáng)。它的缺點(diǎn)是只能處理相對規(guī)范的問題，對非常靈活的問題效果不佳。

那么，如果我們能結(jié)合上述兩種方法的話，就能把語法和語義結(jié)合起來，得到能力更為強(qiáng)大的分析模型。也就是說 X-SQL 從深層語義的角度提取要素，而語法分析從問題的語法組成結(jié)構(gòu)上進(jìn)行提取。

我們的問題解析模塊就是采用了上述思路，它的實(shí)現(xiàn)原理如下：首先用 X-SQL 得到解析結(jié)果，然后在依存句法樹中將 X-SQL 的結(jié)果標(biāo)記在依存語法樹的節(jié)點(diǎn)上，作為它的屬性之一，然后進(jìn)行上述的遍歷過程。對于非常靈活的問題，一般該方法得到的結(jié)果就是 X-SQL 的結(jié)果，對于相對規(guī)范的問題，語義解析方法能夠?qū)?X-SQL的結(jié)果進(jìn)行補(bǔ)充和糾正，從而得到功能更加強(qiáng)大，效果更好的結(jié)果。

我們用兩個小例子來看一下具體的算法流程。

例子一：“各地區(qū)的總新增訂單量”

步驟1：分詞后的結(jié)果（需要考慮字段名，X-SQL 的結(jié)果）： 各 / 地區(qū) / 的 / 總 / 新增訂單量

步驟2：得到的聚合了所有信息的樹：

其中 HED、ATT 等表示依存關(guān)系，HED 表示核心關(guān)系，ATT 表示定中關(guān)系，RAD 表示附加關(guān)系。

步驟3：通過詞庫以及后序遍歷解析依存樹：

1.首先遍歷到“總”。由X-SQL得知這是聚合函數(shù)；

2.遍歷到“各”。得到這個是一個分組描述符；

3.遍歷到“的”。得到這是一個無意義的詞；

4.遍歷到“地區(qū)”。從表中匹配得知這是一個字段名稱，從孩子節(jié)點(diǎn)處得到的信息以及 ATT 的關(guān)系，得知這是一個分組字段；

5.遍歷到“新增訂單量”。由 X-SQL 得知這是查詢詞，并且結(jié)合孩子節(jié)點(diǎn)得知聚合函數(shù)是“總”，分組詞是“地區(qū)”；

6.遍歷到root，得到最終結(jié)果：select內(nèi)容為總新增訂單量，分組字段為地區(qū)。

步驟4：得到解析結(jié)果并輸出。

例子二：“銷售額最高的3個地區(qū)”

步驟1：分詞后的結(jié)果（需要考慮字段名，X-SQL 的結(jié)果）： 銷售額 / 最高 / 的 / 3個 / 地區(qū)

步驟2：得到的聚合了所有信息的樹：

其中 SBV 表示主謂關(guān)系。

步驟3：

1.遍歷到“3個”。由詞性及規(guī)則得知這個是 limit。（不是 where 中的內(nèi)容，否則會被 X-SQL 標(biāo)記出來）；

2.遍歷到“銷售額”。得知這是一個字段名；

3.遍歷到“的”。得到這是一個無意義的詞；

4.遍歷到“最高”。由依存關(guān)系，以及孩子回溯上來的信息，得知這個是一個降序排序信息；

5.遍歷到“地區(qū)”。由 X-SQL 得知這是查詢詞。并且整合孩子節(jié)點(diǎn)的所有信息，得知limit 3， 按銷售額降序排序；

6.遍歷到root，得到最終結(jié)果：select內(nèi)容為地區(qū)，limit 3， 按銷售額降序排序。

步驟4：得到解析結(jié)果并輸出。

特別需要注意的是，在具體應(yīng)用的過程中，經(jīng)常會出現(xiàn)比較復(fù)雜的時間問法。比如“上個月”、“近7天”、“一二季度“、“2018/2019年”等。對于這些問法相對固定，但是解析時需要利用大量知識的內(nèi)容，我們采用了模板的方法進(jìn)行處理。一個模板包括問法模板和解析結(jié)果兩部分。

問法模板定義了問法的句式，由槽位、普通字符和正則語法構(gòu)成，其中槽位暫時只用 ${num} 就夠用了。例如“${num1}${num2}季[度]”，“${num1}/${num2}年”。

解析結(jié)果是問法模板對應(yīng)的解析結(jié)果。由“value”，“start”，“end”三個字段構(gòu)成?！皏alue”是列表，每個值定義了某個具體時間，存在多個時相互間取并集。“start”和“end”表示一個時間段的開始時間和結(jié)束時間，只有當(dāng) “value”不存在時才會有“start”和“end”。在解析結(jié)果中需要 NOW_YEAR、NOW_ MONTH、NOW_DAY 常量表示當(dāng)前的年、月、日。

下面是一個具體的模板實(shí)例：

其中 template表示問法模板，result 表示解析結(jié)果。這個模板可以匹配類似“近7天”模式的時間表達(dá)。

有了模板之后，只需要解析模板就行了。只需要將template 轉(zhuǎn)化成對應(yīng)的正則表達(dá)式，然后把問題中的詞替換成對應(yīng)的槽位，就能進(jìn)行匹配了。匹配完成之后，將得到的槽位信息對應(yīng)填入 result 中就得到了最終的解析結(jié)果。

五、智能問答的實(shí)驗(yàn)效果

在學(xué)術(shù)界一般都會以WikiSQL和Spider作為訓(xùn)練集和測試集，都是英文數(shù)據(jù)集。X-SQL采用通過對WikiSQL翻譯得到的5w條有標(biāo)注數(shù)據(jù)進(jìn)行訓(xùn)練，取其中 5000條作為測試數(shù)據(jù)，準(zhǔn)確率達(dá)到了80% 以上。但由于WikiSQL 不支持復(fù)雜時間以及分組，不具備可比較性，而在Spider上目前最優(yōu)效果為測試準(zhǔn)確率 55%。實(shí)際測試環(huán)境中，由于中文NL2SQL領(lǐng)域還沒有統(tǒng)一的數(shù)據(jù)集，所以我們通過收集用戶實(shí)際在平臺上的使用數(shù)據(jù)，最終得到了 266條中文測試數(shù)據(jù)（問題中可能包含了分組、過濾條件、復(fù)雜的時間表達(dá)、查詢內(nèi)容、排序等），在這個基礎(chǔ)上進(jìn)行測試，得到的結(jié)果如下：

可以看出，本文提出NL2SQL實(shí)現(xiàn)方法更加具備實(shí)用性。

六、展望和進(jìn)一步研究計劃

CleverBI智能問答已經(jīng)具備商用的條件，我們計劃在實(shí)際應(yīng)用中大量收集數(shù)據(jù)，形成類似甚至超越Spider的中文NL2SQL標(biāo)準(zhǔn)數(shù)據(jù)集，這對該領(lǐng)域來說至關(guān)重要。

同時，雖然智能問答中最核心的問題解析模塊已經(jīng)取得了不錯的準(zhǔn)確度和擴(kuò)展性，但除此之外的找表、預(yù)處理和圖表匹配步驟還需要大量的人工規(guī)則，在擴(kuò)展性方面并不理想。在后續(xù)的研發(fā)計劃中，一方面我們需要進(jìn)一步提升問題解析的效果；另一方，我們計劃利用半監(jiān)督和無監(jiān)督算法替換現(xiàn)有的算法，讓整個過程更加靈活。

作者單位：北京百分點(diǎn)信息科技有限公司