ACL 2018 | 提高NLP语义解析准确度：融合SQL语法的生成式语义解析模型

编者按：人们越来越习惯于通过自然语言来进行人机交互，如何能让计算机与用户之间的“沟通”更加顺畅？微软亚洲研究院自然语言计算组在ACL 2018上提出了一个融合SQL语法的生成式语义解析模型，能够更加准确地将用户输入的自然语言转化为机器可以理解并执行的表达形式。

无论是在日常生活还是工作中，人们都越来越多地使用自然语言来与计算机进行交互。例如，使用自然语音交互方式让虚拟语音助手（如Cortana、Siri、Google Assistant、Amazon Alexa等）查询天气、预定日程、拨打电话等；用户在搜索引擎中用自然语言输入查询内容，得到精准的答案；员工使用自然语言与结构化的企业数据库交互，完成查询操作。

在上述的应用场景中，输入的是用户的自然语言（natural language），而输出的是机器可以理解并执行的规范语义表示（formal meaning representation），该表示可以在某个环境中被执行并返回结果。

在自然语言处理领域，上述输入-输出任务被称为语义解析（semantic parsing），即把自然语言自动转化为一种机器可以理解并执行的表达形式。例如，在虚拟语音助手场景中，语义解析模型可以将用户的语言转换为调用不同应用程序的API语句；在基于知识库的搜索场景中，语义解析模型可以将用户查询转换为可以在结构化知识库（如Microsoft Satori）上可以执行的SPARQL语句；在企业数据交互场景中，语义解析模型可以将用户的语言转换为结构化查询语句（Structured Query Language, SQL）；

多变的自然语言与有限的结构化查询语句

在本文中，我们以结构化查询语句为例介绍在语义解析领域的研究进展。该任务的输入是一张web table或一个关系数据库表以及一个关于这张表的自然语言问句，输出是表达该问句语义的SQL语句。这个SQL语句可以在输入的表上被执行，从而得到问题的答案。

图1 结构化查询语句

目前，做生成任务比较流行的方法是基于序列到序列（sequence to sequence）架构的神经模型，这类模型一般由一个编码器（encoder）和一个解码器（decoder）组成。编码器负责建模句子表示，解码器则根据编码器得到的问句表示来逐个从词表中挑选出一个个符号进行生成。

当生成任务的目标语言是SQL时，由于其语法的符号有限，我们可以使用Pointer Network模型来进行建模。这个模型在解码过程中使用了“拷贝”机制，即只从SQL的关键字和问句中的单词所组成的集合中选择每个时刻生成的单词，以达到减少预测空间大小的目的。在Pointer Network模型中，在每个时刻t，decoder选择问句中第i个单词x_i的概率如公式1中所示：

公式1

其中代表解码器中的隐层状态，代表编码器中第i个单词对应的因层状态。

由于自然语言表达的多变性，问句中对表中内容的表述可能与表中的真实表述不一致。在图1的例子中，表中的一列名称为“Song choice”，一个单元的内容为“Anna Christine Nalick”。而在问句中对应的表达却是“songs”和“anna nalick”。由于这种不一致的存在，用Pointer Network生成的SQL就包含了许多不能执行的结果。

融合SQL语法的生成式语义解析模型

图2 融合SQL语法的生成式语义解析模型

为了解决这个问题，我们提出了一个融合SQL语法的生成式语义解析模型，其整体结构如图2所示。这是一个序列到序列的模型，其编码器由双向的RNN组成，双向RNN的最终状态向量在首尾相连后作为解码器的初始状态。解码器则由三个频道和一个门单元组成。其中三个频道分别为Column、value、SQL频道，在每个频道中分别预测表中列名称、表中单元格名称和SQL语法关键字。而门单元则预测在每个时间节点应该选择哪个频道的预测结果作为输出。解码器在t时刻生成目标y_t的概率如公式2所示，其中z_t代表由门单元选择的频道，p_z（·）是选择频道的概率，而p_w（·）类似于公式1，它是各自频道的概率输出。

公式2

具体来说，在三个频道中，column和value频道的候选由于由N个单词组成，所以用RNN建模，得到向量表示，而SQL频道的候选用对应的word embedding表示。在每个频道中，当前时刻生成元素的概率是由此时刻解码器RNN的状态向量和候选元素的向量表示之间通过计算相似度后归一化所得。而门单元的概率输出则是直接由解码器RNN的状态向量经线性变化后经过softmax所得。由于column、value频道的预测候选是直接从表中获得，所以解决了Pointer Network模型所面对的不一致问题。

此外，我们还在模型中加入了SQL语法和表结构的信息来提升性能。

首先，列名和单元格直接的关系可以帮助column频道的预测。如果我们在问题中提到了表中的某一单元格，那么Where column的结果也大概率是此单元格所在的列。所以，我们也用了表中单元格的信息去帮助column频道的预测。具体来说，我们将单元格的向量表示的加权求和与原列名称的向量表示首尾相，以此作为新的列名的向量表示。这个权重是由单元格中出现的单词在句子中复现的程度决定的。

公式3

其次，列名和单元格之间的关系也可以帮助value频道的预测。Where value所在的单元格一定在Where column所在的列，所以我们用一个全局变量保存了最近一侧预测的列位置，在value频道中只选择这列的单元格作为候选进行预测。直观来看，要预测的单元格内容基本都出现在问句之中，所以我们进一步用上文中提到的由单词复现得到的权重和value频道预测的概率分布做一个加权求和，从而得到最终value频道的预测概率。

公式4

我们在WikiSQL数据集上进行了实验。这个数据集包含了61,297/9,145/17,284个训练/开发/测试样本。每个样本分别包含了一个问句、一张表、一个SQL表达式，以及问句在表中的答案。我们用了两种评估指标，分别是逻辑表达式准确率(Acc_lf)：生成的SQL是否和样本中的SQL表达式完全匹配的比例，和执行准确率(Acc_ex)：生成的SQL在表中查询后得到的答案和样本中的答案一致的比例。

实验结果如下图所示。Aug.PntNet代表Pointer Network模型，其中在STAMP（w/o）cell的模型中，value频道预测的候选不是表中的单元格，而是问句中的单词，即在value频道沿用了Point Network的拷贝机制。在STAMP  (w/o column-cell relation)模型中，我们去掉了单元格信息对于column和value频道的增强。

图3

通过此表我们可以看到，用表中的元素整体作为预测候选以及加入列名与单元格之间的依赖关系这两点设计都对模型有所加强。我们在逻辑表达式准确率和执行准确率两个维度上对比Pointer Network模型分别获得了14.7%和14.1%的提升。

下图展示了我们的模型在更细粒度上的执行准确率：

图4

可以看到，在Where从句中，我们模型的效果有着明显的提升。

下图中展示了模型的输出样例：

图5

我们可以看到，我们的模型解决了问题表达和表中内容表达不一致所导致的问题。

总结

本文以自然语言到SQL语句生成任务为例，介绍了在语义分析（semanticparsing）领域我们提出的一种融合SQL语法的端到端神经网络方法。这一语义分析技术的应用将有效地提升搜索引擎的结果准确度、提高虚拟语音助手的多轮对话表现等。未来，我们还计划使用更多样的监督信号学习适用于不同场景的语义分析算法。

想要了解更多细节的读者，欢迎阅读我们发布在今年ACL 2018上的论文：

Semantic Parsing with Syntax- and Table-Aware SQL Generation, Yibo Sun, Duyu Tang, Nan Duan, Jianshu Ji , Guihong Cao , Xiaocheng Feng , Bing Qin, Ting Liu, Ming Zhou, ACL 2018

论文链接：https://arxiv.org/pdf/1804.08338.pdf

作者简介

孙一博，微软亚洲研究院自然语言计算组的实习生，目前就读于哈尔滨工业大学，社会计算与信息检索实验室。研究兴趣包括问答系统，语义分析和深度学习等。

你也许还想看：

感谢你关注“微软研究院AI头条”，我们期待你的留言和投稿，共建交流平台。来稿请寄：[e-mail]。