很久没在CSDN上发文了,发篇文章,攒点收录。
Author: 刘帝伟
原文地址:http://www.csuldw.com/2019/10/20/2019-10-20-nl2sql-introduction/
对于NL2SQL,也许在以前很多人会比较陌生。自从今年6月天池出现首届中文NL2SQL挑战赛之后,算是掀起了一股浪潮,中文NL2SQL也可以说是得到了进一步的发展。NL2SQL是CUI(Conversation User Interface)的新兴研究热点,其研究目的是将用户输入的自然语言转为可用的SQL语句,提高用户查询数据的效率。笔者接触NL2SQL方向并不长,所以也不敢在各位大神面前班门弄斧。比起情感分析、推荐系统、知识图谱这些领域,NL2SQL的文章真是少到可怜。本文也是出于学习目的对NL2SQL方向进行概括和总结,要是相关童鞋也在做这个方向,我们不妨一起交流交流。
NL2SQL(Natural Language to SQL), 顾名思义,是将自然语言转为SQL语句。它可以充当数据库的智能接口,让不熟悉数据库的用户能够快速地找到自己想要的数据。举个例子来说吧,在某个周五的晚上,业务人员小李想写份工作报告,总结下这个月的工作情况。在内容上,有一处需要查看某个产品本月的销售总额,但公司却没有这方面的具体报表数据。小李心里琢磨着,好歹自己也学过数据库,要是知道这个数据在那张表里面就好了。为此,他给开发人员小王打了个电话,本想让他帮忙从后台数据库里查一下,可谁知小王已经趁着周末去度蜜月去了,然后又给另一个开发小夏打了个电话,结果无人接听,真是让小李愁的寝食难安呀!这时候,如果能够有一个搜索框,小李只需要输入"我想查看A产品9月份的销售总额",最后返回给小李一个SQL语句或是查询结果,岂不大快人心哇。
上面这个例子就是NL2SQL的一个应用场景,无论结果是返回数字,还是将其以报表的形式展示给用户,都要经过NL2SQL这一过程。其实基于图谱的QA问答,本质上也与其类似,知识图谱问答是将用户的query转化为SPARQL,然后从图谱中搜索结果返回给用户。举个栗子,如图Fig 1所示,用户以文本的形式提出Question:“what 's the total number of songs originally performed by anna nalick?”,经过开发的系统解析之后,最后返回给用户的是一串SQL语句“?????? ????? ???? ?h???? ????? ???????? ?????? = ???? ?h??????? ??????”,或是返回执行结果:1。
NL2SQL的历史悠久,早在1973年,Woods等人就开发了一个名为LUNAR的系统,可以回答关于从月球带回的岩石样本的问题。到了1978年,Hendrix设计了一个连接美国海军舰艇信息数据库的自然语言接口,名为LIFER/LADDER。这些系统仅仅支持特定数据库的单表操作。
近年来,研究人员也在尝试开发一个能够生成不同查询语句的复杂系统。在2008年,Siasar等人基于句法和语义知识的基本概念提出了专家系统,并提出一个能够从多个结果中选择一个合适查询语句的算法。随后,在2010年,Rao等人提出了一个包含简单和隐式查询的系统。2013年,Chaudhari使用原型技术实现了一个能够处理简单查询和聚合函数的系统。这两个系统也尚未发展到多表关联操作。2014年,Ghosh等人基于Chaudhari的研究成果,在其基础上又开发了一个自动查询生成器,它采用语音或自然语言文本作为输入,支持简单的嵌套查询和聚合操作,同时系统还能够处理那些明确指出的属性。同年,Reinaldha和Widagdo使用了不同的方法来研究用户不同形式的输入,他们采用语义规则来找出问题中出现的词与数据库中的属性之间的关系。2015年,Palakurthi等人提供了与属性类型和分类特征相关的信息,描述了不同属性出现在句子中的处理方式也是不一样的。2016年,Ghosal等人提出了一个系统,能够很好地处理多表简单查询,不过系统使用的数据字典有限。同年,Kaur and J, Jan 强化了系统的简单查询和连接操作,但不支持聚合函数、GROUPBY和HAVING等高级子句。Singh and Solanki也提出了一种将自然语言转为sql查询的算法。他们使用动词表、名词表和规则将属性和表映射到句子中的单词,系统还灵巧地处理了文本的模糊输入。2017年,Google开发了Analyza系统,一个以自然语言为人机交互的接口的系统,支持用户用自然语言做数据探索与数据分析。该系统已在Google两个产品中投入使用,一是Online Sheet产品的QA问答模块,二是提供了一个库存和收入数据数据库的一个访问入口。同年,Sukthankar, Nandan等人开发了nQuery系统,一个自然语言到SQL的查询生成器,支持聚合函数,以及where子句中的多个条件、高级子句(如order by、group by和having)操作。2018年,Utama, Prasetya等人开发了DBPal工具,一个面向数据库的端到端的自然语言接口。DBPal主要有两大特性,一是采用深度模型将自然语言语句转为SQL,二是在用户不知道数据库模式和查询特性的情况下,支持短语提问,同时支持用户查询扩展提示,有助于提高查询效果。
上述研究都是基于英文句子进行分析,中文NL2SQL的研究一直未有公开的进展。直到2019年6月,追一科技在天池平台举行中文NL2SQL比赛,这才有了中文NL2SQL的一席之地。
关于数据集,目前比较火的英文数据集有WikiSQL、Spider、WikiTableQuestions、ATIS等,各个数据集都有各自的特点,下面简单介绍下这几个数据集。
Github地址:
中文数据集目前只有追一科技在天池发布的比赛数据集,包括4万条有标签数据作为训练集,1万条无标签数据作为测试集。目前比赛第一名的成绩,准确率达到了92%。
在学术界,NL2SQL技术已经形成了一套模式,Fig 2就是NL2SQL经典的三层架构。
如上图所示,NL2SQL分为User query interface、Processing Unit、Database三部分,其中Processing Unit是整个架构的中心,也是语义解析的核心所在,打通了User与Database的交互通道,囊括智能分词、实体识别、知识检索等各个技术要点。在上述研究中,Processing Unit的内部算法也在逐步朝着深度学习的方向进展。下面,我们一起来看看几个经典的NL2SQL系统结构。
Google在2017年,针对自身的业务特点开发了Analyza系统,整个系统结构如Fig 3所示。
Analyza系统由四个组成部分:用户UI、Parser、Answering Engine和Storage。将三层架构的Processing Unit划分成Parser和Answering Engine两部分。下面我们来看看各个部分的作用。
DBPal与Analyza的系统结构都有着NL2SQL三层架构的影子,只是细节上略微不同。与Analyza不同的是,DBPal主要由两部分组成,分别是神经查询翻译器(Neural Query Translator)和交互式的自动完成特性(Interactive Auto-Completion)。
如Fig 5所示,左上部分集成了Query Suggestion & Auto-Completion自动问句提示功能,不仅给用户提供更好的体验,更是引导用户得到更精确的回答。在Fig 4右侧,即Server-side,是DBPal的核心,它的主要目的是将用户query转为SQL,实现上将其看做是翻译任务,采用的是sequence-to-sequence 深度学习模型,数据也是通过RNN模型训练生成的,并在模型前后增加了许多预处理和后处理操作。
对于NL2SQL的各个系统,在内部实现上,整体结构都大同小异,只是技术不同罢了。Fig 5描述了从Question到SQL生成的核心细节,简单来说,整个系统将NL2SQL分成了SQL几个子句的识别,包括SELECT clause、WHERE clause,当然可能还有group by、limit等等。每个部分又会牵扯很多的细节,比如table识别,属性识别,适当的添加索引等等。Fig 5是采用深度学习方法,通过encoder-decoder的方式进行NL2SQL的实现。Google的Analyza采用的则是语义解析和规则的方式构建的,paper中解释主要还是因为数据的问题。
对于NL2SQL,笔者在工作中也深深感受到它的难度,通过这些Paper的指引,大致做出了一个NL2SQL的雏形,后续还需要不断提升。本文主要是对NL2SQL做一个大致的总结,内容比较随性,浅尝辄止,如果针对相关的内容有疑问,可以看看对应的论文。最后,各位看官如是对NL2SQL感兴趣或是正在研究这方面的东西,不妨加个微信,一起探讨下中文NL2SQL的工业实践!