劉譯璟 徐林杰 代其鋒

一、引言

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

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

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

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

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

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

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

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

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

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

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

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

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

二、CleverBI智能問答架構

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

（一）智能問答服務

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

（二）數據庫讀寫服務、離線調度服務、計算引擎等

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

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

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

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

（三）語義解析服務

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

三、語義解析流程

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

（一）找表

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

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

精確匹配時，在離線任務中需要把表的字段名、枚舉值、實體標簽按字級別構建成倒排索引。倒排索引的內容如下：

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

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

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

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

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

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

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

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

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

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

經過精確匹配和模糊匹配的結合，我們會確定在哪張數據表上來回答用戶的提問。

（二）數據預處理

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

（三）問題解析

這是語義解析的核心，它負責將預處理得到的問題要素翻譯為如下面例子的數據結構：

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

（四）圖表匹配

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

步驟4：得到解析結果并輸出。

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

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

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

其中 SBV 表示主謂關系。

步驟3：

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

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

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

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

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

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

步驟4：得到解析結果并輸出。

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

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

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

下面是一個具體的模板實例：

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

有了模板之后，只需要解析模板就行了。只需要將template 轉化成對應的正則表達式，然后把問題中的詞替換成對應的槽位，就能進行匹配了。匹配完成之后，將得到的槽位信息對應填入 result 中就得到了最終的解析結果。

五、智能問答的實驗效果

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

可以看出，本文提出NL2SQL實現方法更加具備實用性。

六、展望和進一步研究計劃

CleverBI智能問答已經具備商用的條件，我們計劃在實際應用中大量收集數據，形成類似甚至超越Spider的中文NL2SQL標準數據集，這對該領域來說至關重要。

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

作者單位：北京百分點信息科技有限公司