语义解析 (Text-to-SQL) 技术研究及应用 下篇

欢迎关注“百度NLP”官方微信公众号，及时获取更多自然语言处理领域的技术干货！

---

原文链接：https://mp.weixin.qq.com/s/5lTLW5OOuRMo2zjbzMxr_Q

 

在上篇中，我们结合实例向大家介绍了语义解析技术中的Text-to-SQL任务，明确了该任务的研究动机，并从相关数据集和模型两方面讲解了Text-to-SQL的技术进展。

 

本篇，我们就数据集DuSQL的建设和模型DuParser的构建，向大家介绍百度在Text-to-SQL技术方面的研究，并展示百度在ToB客服业务和搜索业务中对该技术的应用，同时也对该技术面临的挑战和未来发展进行了一些思考。

 

 百度对Text-to-SQL技术的研究

 

百度在一些实际业务中需要用到Text-to-SQL技术，比如基于表格的问答、ToB的客服业务等，所以结合实际应用，在数据集建设及模型构建方面做了一些工作，有一定的技术积累。

 

1、数据集DuSQL

由表1可见，当前Text-to-SQL数据集大部分是英文数据集，中文数据集只有NL2SQL数据集和CSpider数据集。

 

表1

 

其中CSpider数据集是英文数据集Spider的翻译版本，中英文化差异导致问题用语和知识上存在差异，比如行政区划相关的数据在Spider数据集上表示为“州、县、市”等，在CSpider数据集上则表示为“省、市、县”等，这种差异性降低了该数据集在实际应用中的价值。

 

NL2SQL数据集中的问题相对简单，问题类型为基于单/多条件查询匹配的答案检索，能够解决如“3000元以下的手机有哪些”等简单问题，但无法解决“便宜的手机有哪些”、“苹果8手机256G比128G贵多少”这样较难的问题。在实际应用中，后种难度较高的问题占比很高，尤其是在商业智能（BI）和购物相关咨询的业务中。

 

我们从实际应用中随机抽取用户问题，就问题解决所需要的操作对问题类型进行了人工分析，结果如表2所示，可以看出涉及到计算、排序、比较等操作的问题有一定的占比。

 

表2

 

为了更好地理解这些问题类型，我们列举了一些问题类型及对应的问题实例（数据库见上篇图1），见表3：

 

表3: 问题类型及实例

 

为了更好地覆盖实际应用中常见的问题类型，使构建的数据集在实际应用中发挥更大的价值，我们基于实际应用分析构建了多领域、多表、包含复杂问题的数据集DuSQL。

 

数据集构建主要分为两大步骤：数据库构建和<问题，SQL查询语句>构建。在数据库构建中，要保证数据库覆盖的领域足够广泛，在<问题, SQL查询语句>构建中，要保证覆盖实际应用中常见的问题类型。

 

数据库主要来自百科（包括三元组数据和百科页面中的表格）、权威网站（如国家统计局、天眼查、中国产业信息网、中关村在线等）、各行业年度报告以及论坛（如贴吧）等。

 

从这些网站挖掘到表格后，我们按表格的表头对同类表格进行了聚类，并根据表格中的实体链接等信息构建表格之间的关联，最终保留了813张表格，分为200个数据库。由于很多表格的内容较敏感，我们仅使用了表格的表头，对表格内容进行了随机填充，无法保证事实性。

 

基于一个半自动方案构建<问题, SQL查询语句>，首先需要基于SQL文法自动生成SQL查询语句和对应的伪语言问题描述，然后通过众包方式将伪语言问题描述改写为自然语言问题。在自动生成SQL查询语句时，我们设计了覆盖所有常见问题类型的SQL规约文法，最终构建了近2.4万的数据。

 

表4展示了DuSQL数据集与其他多领域数据集的对比情况。其中，时间计算属于常数计算，引入常量TIME_NOW（表示当前时间），比如数据库Schema为“{公司名称, 成立年份, 员工数, …}”，问题为“XX公司成立多少年了”， SQL查询语句为“Select TIME_NOW – 成立年份 Where 公司名称=XX”。在实际应用中，常数计算中的时间计算需求较大，因此我们构建了相关数据。

 

表4：CSpider来自Spider训练集和开发集的翻译，其统计使用Spider的统计

 

2、模型DuParser

基于实际应用，百度研发了一种基于表格元素识别和文法组合的解析算法DuParser，要求其在实际应用中能够基于用户提供的数据或反馈达到快速迭代、效果可解释、可控的要求，解析算法框架见图5（对应的实例见图6，不同颜色的箭头表示了流程中各模块对应输入输出）。

 

图5

 

首先，“成分映射”模块完成问题中表格相关成分识别（图6黑色箭头表示的流程），用户提供的数据包括同义词、应用常见问题形式等，该部分可充分利用用户提供的数据进行效果优化。然后对识别的成分进行SQL关键词识别（图6紫色箭头表示的流程），该部分算法基于Sequence-to-set模型改进。

 

前两个过程将问题中被映射成功的词汇替换成相应的符号，输入到基于文法组合的解析算法中，该部分的替换使后面模块与具体数据库无关，这提升了模型对新数据库的泛化能力。

 

最后，在基于文法组合的语义解析阶段，通过改造CYK算法，DuParser构建了一个自下向上的解析框架（图6蓝色箭头表示的流程），并且，在文法组合过程中通过引入SQL片段与对应问题片段相似度匹配来选择最优文法。

 

图6：黑色箭头表示成分映射，紫色表示标签识别，蓝色表示文法组合

 

该框架有以下几个优点：

首先，与端到端的神经网络模型相比，它具有良好的可解释性和效果可控性，容易进行系统调试和针对性效果优化；其次，它可以充分利用用户提供的数据及反馈，在用户任务上快速启动且加快迭代优化速度；最后，该框架可以做到语言无关、领域无关，有很好的扩展能力。

 

该模型在单表数据集合上进行了效果验证，结果见表5（使用的预训练模型与对应的SOTA一致）。

 

表5

注:

1）NL2SQL数据集的SOTA是开源最好模型[20]在开发集上的结果;

2）WikiSQL数据集的SOTA模型是不加执行指导的X-SQL[13]模型；

3）Spider单表来自Spider数据集中的单表部分数据，SOTA模型是IRNet[16]，评估了其中单表上的准确率（非bert版本）；

4）百度应用数据会针对数据集做优化，重点是“同义词”部分。

 

 百度对Text-to-SQL技术的应用

 

Text-to-SQL技术主要的应用场景是基于数据库的问答。在实际的应用中，百度将该技术应用于ToB客服业务和搜索业务中。

 

对于ToB业务，以UNIT平台为输出接口，支持结构化问答业务（参见下方链接）。支持的业务应用于车载对话系统、企业智能报表生成系统、电话客服系统等，图7给出落地于车载对话系统中的案例。

 

链接：

https://ai.baidu.com/forum/topic/show/957042

 

图7

 

对于搜索业务，我们探索了搜索中的计算类问答（图8）和企业表格问答（图9）。

 

图8

 

图9

 

 目前挑战及未来思考

 

Text-to-SQL技术在实际应用中可直接使用，但由于实际应用领域覆盖广泛，模型需要满足领域无关、语言无关、问题无关。

 

当前模型在中间表示、树形解码、图网络建模数据库等方向均有探索，并取得了一定的成效，但对一些复杂操作的解决效果还不够好，可参见Spider数据集标注为“难”和“极难”的数据效果。同时，在实际应用中，还需要考虑以下问题：

 

• 表格的识别及规范化表示：表格默认以第一行为表头，但在实际挖掘表格中，有三种情况：以第一行为表头，以第一列为表头，或者第一行和第一列共同表示表格；挖掘的表格存在信息缺失问题，如表名缺失、表格值不全等；同时，面对多个表格时缺失表间链接关系。

   

•  外界知识的利用：有一些常识信息不包含在表格中，如排序操作的方向判断（列为“出生日期”，问题为“年龄最大的员工”）、表格值进制转换（列为“人口(亿)”，问题为“人口超5千万的城市”）等，这些信息需要引入外界知识来协助SQL生成。

   

• 融进渐进式对话：对于用户的歧义表达和模糊表达，需要有“提问-反馈-再提问”的过程，这类问题往往需要通过多轮对话解决，而用户的问题通常是上下文相关的，因此需要模型具备基于上下文的理解和分析能力。

 

  参考文献

 

[13] X-SQL: Reinforce Context Into Schema Representation (Pengcheng He, Yi Mao, Kaushik Chakrabarti, Weizhu Chen. CoRR2019)

[16] Towards Complex Text-to-SQL in Cross-Domain Database with Intermediate Representation (Jiaqi Guo, Zecheng Zhan, Yan Gao, Yan Xiao, Jian-Guang Lou, Ting Liu, Dongmei Zhang. ACL2019)

[20] https://github.com/beader/tianchi_nl2sql

 

百度自然语言处理（Natural Language Processing，NLP）以『理解语言，拥有智能，改变世界』为使命，研发自然语言处理核心技术，打造领先的技术平台和创新产品，服务全球用户，让复杂的世界更简单。