ACL 2018 | 提高NLP语义解析准确度：融合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就包含了许多不能执行的结果。

图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