前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >SQLNET:无强化学习的由自然语言生成结构化查询语句

SQLNET:无强化学习的由自然语言生成结构化查询语句

作者头像
企鹅号小编
发布2018-01-31 09:38:29
2.7K0
发布2018-01-31 09:38:29
举报
文章被收录于专栏:人工智能人工智能

来源:arXiv

作者:Xiaojin Xu*、Chang Liu、Dawn Song

编辑:智察(ID:Infi-inspection)

文章字数:9238 预计阅读用时:12分钟

摘要

从自然语言中合成SQL查询语句问题是一个长期的开放性问题,并已经引起人们极大的兴趣。为了解决这个问题,实际方法是使用序列到序列风格的模型,而这种方法必然要求SQL查询序列化。因为相同的SQL查询可能具有多个等效序列化,而训练序列到序列风格的模型对从其中选择一个是敏感的,这种现象被记录为“顺序影响”问题。而现有的技术是靠强化学习,当解码器产生等价序列时进行回馈,然而,我们观察到从强化学习得到的改善是有限的。

本文中我们提出一种全新的方法,即SQLNET,可以在顺序不重要时可以通过避免序列到序列的结构来从根本上解决这个问题。尤其是这里采用了基于草图的方法,其中草图包含一个依赖图,这样我们只需考虑以前的依赖预测,就可以完成一个预测。此外,我们提出了一个序列到集模型和一种列注意力机制来合成基于草图的查询语句。把所有这些新的技术结合起来,我们可以看出,在WikiSQL任务上,SQLNet的性能比现有技术高出9%至13%。

1、 介绍

语义分析是一个长期的开放性问题并有许多应用。特别是将自然语言描述解析为SQL查询语句最近备受学术界和工业界关注。我们将这个问题称为自然语言到SQL(NL2SQL)问题。实际解决这个问题的标准方法是将自然语言描述和SQL查询看作序列,并训练一个序列到序列模型或其变体,可看做一个解析器,但这种方法的一个问题是,由于交换性和相联性,不同的SQL查询可能是等价的。例如下面的两个查询:

在“WHERE”中两个约束的顺序不影响查询结果的执行,但在语法上会被认定是两个不同的查询。众所周知,这些约束的顺序影响序列到序列样式模型的性能,并且难以找到最佳排序。为了减轻这种排序问题,强化学习已经被应用到很多类似情况中。其基本思想是,经过一个标准的监督训练过程,再使用策略梯度算法对模型进行进一步的训练。特别是在给定输入序列,序列到序列模型的解码器在输出分布之后对输出序列进行采样,并对基于该输出是否生成良好的查询语句以及是否查询语句将进行正确计算进行奖励。这种奖励可以由策略梯度算法用于微调模型。然而,通过强化学习可以实现的改进往往是有限的。例如在一个叫WIKISQL的NL2SQL任务在最新报告中说,其通过强化学习性能只提高了2%。

在这项工作中,我们提出SQLNet来从根本上解决这个问题,通过在顺序不重要情况下避免序列到序列的结构。特别地,我们使用基于草图的方法从草图中来生成SQL查询,草图自然地与SQL查询的语法结构保持一致,然后使用一个名为SQLNet的神经网络来预测草图中每个插槽的内容。我们的方法可以被看作是一种神经网络替代传统的基于草图的程序合成方法。值得注意的是最新的神经网络SQL合成方法也采用了基于草图的方法,虽然他们的草图更粗糙,但他们使用序列到序列的结构来填补草图中最具挑战性的插槽。

正如前文所讨论的,最具挑战性的部分是生成WHERE子句。基本上,序列到序列解码器的问题在于下一个标记的预测取决于所有先前生成的标记。但是,不同的约束可能不具有互相的依赖关系。在我们的方法中,SQLNet使用草图来为不同键槽之间提供依赖关系,以便每个键槽的预测仅基于它所依赖的其他插槽的预测。为了实现这一想法,SQLNet的设计引入了两个新的构造:顺序到集合和列注意力。前一个设计用来预测一组无序的约束,而后一设计是为了捕获预测时草图中定义的依赖关系。

我们在就我们所知最大的NL2SQL数据集WikiSQL数据集中评估了我们的方法,并与最先进的Seq2SQL进行了比较。结果是我们的方法在WikiSQL测试集上获得了61.5%的查询匹配精度和68.3%的结果匹配精度。换言之,SQLNet可以实现的查询匹配和查询结果匹配的精度,分别比Seq2SQL的相应度量标准高出7.5和8.9个百分点,从而表明在WikiSQL数据集上我们的方法是最先进的方法。

WikiSQL数据集最初是为了确保训练集和测试集有一组不相交的表。在实际设置中,更可能针对大多数表在训练集中都存在至少一个查询这种情况部署NL2SQL解决方案。我们重组WikiSQL数据集以模拟这种情况,并将我们的方法和基准方法Seq2SQL进行评估。我们观察到,在这样的情况下,SQLNET相对于seq2SQL的优势扩大2个百分点,并且SQLNET模型可以实现70.1%的执行准确率。

总之,我们在这项工作中的主要贡献有三个方面。首先,我们提出了一种新的处理序列到集合生成问题的方法。我们的方法避免了序列到序列模型中的“顺序影响”问题,从而避免了使用强化学习算法的必要性,并取得了比现有的基于序列到序列的方法更好的性能。其次,我们提出了一种新的注意力结构,称为“列注意力”,并指出这有助于进一步提高原始的序列到集合模型的性能。最后,我们设计的SQLNet,它在WikiSQL数据集上比以前最先进的方法领先了9到13个百分点,这表明在NL2SQL任务上是目前最先进的方法。

2、 从自然语言问题和表结构生成SQL查询语句

在这项工作中,我们考虑的是WikiSQL任务,不同于以往的NL2SQL数据集,Wikiql任务有几个我们所期望的属性。首先,它提供了一个大型数据集,在其中神经网络可以进行有效的训练。第二,它利用群体资源收集人类创造的自然语言问题,从而帮助克服一个训练有素的模型可能在模板合成描述上过拟合的问题。第三,该任务仅基于自然语言和表结构而不依赖表格内容来合成SQL查询语句。

图1:WikiSQL任务的示例

这将有助于减轻其他可选方法在应用于实际应用场景时可能遭受到的可扩展性和隐私问题,因为实际应用场景中涉及大量的敏感的用户数据。第四,数据分割为训练,开发,和测试集,并且互相之间不共享表。这有助于评估一个方法在未知场景的泛化能力。

我们现在解释WikiSQL任务。其中输入包含两部分:一个针对表进行查询的自然语言问题,另外是用来查询的表的结构。这里表的结构包含每一列的名字和类型。输出是其反映了关于查询表的自然语言问题的SQL查询语句。请注意这里WikiSQL任务考虑仅用一个表来合成SQL查询。因此,在SQL查询输出中只需要预测SELECT子句和WHERE子句并省略FROM子句。我们在图1中进行了举例。

WikiSQL任务做出了进一步的假设以便于处理。首先,它假设每个列名都是有意义的自然语言描述,因此合成任务只能从自然语言问题和列名中提取。其次,SQL查询输出中的任何标记都是SQL关键字或自然语言问题的子字符串。例如,在WHERE子句中生成约束时,假设name=‘Bob’,那么标记‘Bob’必须以子字符串的形式出现在自然语言问题中。当数据库表中的内容时不作为输入时这个假设很有必要。第三,WHERE子句中的每个约束都具有COLUMN OP VALUE的形式,其中COLUMN是一个列名。OP是“, ≥, ≤”的其中一个,VALUE是上述自然语言问题的一个子字符串。

尽管有这些假设,WikiSQL任务仍然具有挑战性。ZHONG等人的报告中最先进的任务不可知语义分析模型仅可实现37%的执行精度,而该任务最先进的模型可以实现大约60%的执行精度。鉴于在本节开始时讨论的几个特性,我们认为WikiSQL任务是比以前的任务更适合的具有挑战性的任务。我们考虑将构建和处理更复杂SQL查询语句的合成任务作为今后的工作重点。

3、 SQLNet

在本节中,我们使用了我们的SQLNet解决方案来处理WikiSQL任务。不同于现存的用于输出与语法无关的模型的语义分析器,我们的基本理念是使用与SQL语法高度一致的草图。因此,仅需将SQLNet填充到草图中的插槽中,而不是预测输出语法和内容。

草图设计得足够通用,这样所有感兴趣的SQL查询都可以用草图来表达。因此,使用草图并不妨碍我们的方法的通用性。我们将在第3.1节中解释草图的细节。

草图捕捉了要做的预测的依赖性。通过这样,预测一个插槽的值只取决于它所依赖的那些键槽的值。这避免了序列到序列模型中“顺序影响”问题,即其中任何一个预测都取决于以往的所有预测。为了根据草图进行预测,我们开发了两种技术:序列到集合和列注意力。我们会在3.2节中解释这些技术。我们结合所有的技术设计一个SQLNet神经网络并从自然语言问题和表结构中合成SQL查询语句。在3.3节中我们介绍了SQLNet和培训细节的详细信息,无需强化学习便可以超越以前的技术。

3.1、 基于草图的查询合成

SQL草图我们在图2a中有正式说明。用粗体的标记表示SQL关键字。以“$”开头的标记表示插槽需要填充,“$”后面的名称表示预测的类型。例如,$AGG插槽可以用空标记或某一聚合操作符来填充,例如SUM和MAX。$COLUMN和$VALUE插槽分别需要列名称和问题的子字符串来填充。$OP可以从{=, }中取值。概念使用正则表达式指示零个或多个AND子句。

草图的依赖关系图如图2b所示。所有将被预测值的插槽都被绘制成盒子,并且每个依赖性都被描绘为定向边缘。例如,OP1的盒子有分别来自Column 1和自然语言问题的两个传入边。这些边表示OP1值的预测既取决于Column 1的值,也取决于自然语言的问题。我们可以将模型视为一个基于该依赖图的图模型来查看,并且将查询合成问题作为图的推理问题。从这个角度来看,我们可以看到,一个约束的预测是独立于其他约束的,因此我们的方法可以从根本上避免序列对序列模型中的“顺序影响”问题。

请注意,虽然简单,但此草图足以表示WikiSQL任务中的所有查询。我们的SQLNet方法不仅限于此草图。为了合成更复杂的SQL查询,我们可以简单地使用支持更丰富语法的草图。事实上,在WikiSQL任务中的最新方法Seq2SQL也可以看做一种基于草图的方法。特别是当Seq2SQL预测与分别来自WHERE子句的$AGG和$COLUMN。然而,Seq2SQL仍会受到“顺序影响”问题的困扰,因为Seq2SQL是使用序列到序列模型来生成WHERE子句的。

3.2、 使用列注意力的序列到集合预测

在本节中,我们使用WHERE子句中列名称的预测作为示例来解释序列到集合模型和列注意力的思想。我们将在第3.3节中解释完整的SQLNET模型。

序列到集合。直观的说,出现在WHERE子句中的列名称构成所有列名称的完整集的子集。因此,替代了生成列名称序列,我们可以简单地预测该子集中会出现哪些列名称。我们把这个想法作为序列到集合预测。

特别地,我们计算概率,其中是一个列名称,是自然语言问题。出于这个目的,我们有一种方法就是将计算为:

其中是sigmoid函数,和分别是列名称和自然语言问题的嵌入。和是可训练变量的两个列向量。这里,嵌入和可以被计算为分别在和的序列的顶部上运行的双向LSTM的隐藏状态。注意两个用来编码列名称和问题的LSTM不共享它们的权重。的纬度都为d,这也是LSTM隐藏状态层的纬度。

在这种情况下,可以通过检查来决定是否在WHERE子句中包含特定列,从而独立于其他列。

列注意力。方程式(1)存在使用的问题。由于它仅仅被计算为自然语言问题的隐藏状态,所以它可能不能够记住有助于预测特定列名称的特定信息。例如图1中的问题,在WHERE子句中标记“number”对于预测列“No”来说更重要。然而在SELECT子句中,标记“player”对于预测列“player”来说更重要。当预测特定列时,嵌入应反映在自然语言问题中与之最相关的信息。

整合这个直觉,我们设计了列注意力机制来计算而不是。我们假设是一个的矩阵,其中是自然语言问题的长度。的第列对应问题的第个草图LSTM的隐藏状态层输出。

我们为问题中每一个标记都计算了注意权重,是维的列向量,其可计算为:

其中表示的第维,表示的第列,是一个尺寸为的可训练矩阵。

在计算注意力权重之后,我们可以基于计算并作为每一个标记的LSTM隐藏输出的加权和:

为了得到列注意力模型,我们可以使用方程式(1)中的来代替:

事实上,我们发现在之前添加一个仿射变换层,可使预测性能提高1.5%左右。因此,我们得到了在WHERE子句中预测列名称的最终模型:

其中和是尺寸为的可训练矩阵,是一个纬度为的可训向量。我们要强调,列注意力是一种对基于列名称条件的问题来计算注意力图的通用注意力机制的特例。我们将在我们的评估中表明这个机制可以在序列到集合模型上改进大约3个百分点的性能。

3.3、 SQLNet模型和训练细节

在本节中,我们将介绍完整的SQLNet模型和训练细节。如图2b所示,SELECT子句和WHERE子句的预测是分开的。在下面的文章中,我们首先介绍了生成WHERE子句的模型,然后是生成SELECT子句的模型。最后,我们描述了更多可以有助于提高预测精度的训练细节。

3.3.1、 预测WHERE子句

WHERE子句是WikiSQL任务中预测的最复杂结构。我们的SQLNet模型首先根据第3.2节预测了出现在WHERE子句中的一组列。然后通过OP和VALUE为每个列生成约束。下面来进行介绍。

列插槽。在基于方程式(3)对进行计算之后,SQLNet需要决定哪些列包括在WHERE中。一种方法是设置阈值这样所有的列都会选上。

然而,我们发现另一种能给出更好的性能的方法。我们现在解释这一方法。我们使用一个网络来预测被列入子集的列的总数,为了在WHERE子句中形成列名称我们选择拥有最高的前列。

我们观察到,大多数查询的WHERE子句中的列数量有限。因此,我们为要选择的列数设定上限,因此,我们可以将问题转换为类的分类问题(从0到N)。我们可以得到:

其中和分别是尺寸为和的可训练矩阵,标记代表softmax输出的第维,我们将在描述的后续部分沿用这一标记。SQLNet选择使得最大的列数。

在我们的评估中,我们只选用来简化我们的评估设置。但是请注意,我们可以使用可变长度预测模型来摆脱超参数,例如将在3.2节中讨论的一个SELECT预测列模型。

OP插槽。WHERE子句中的每一列预测其OP插槽值都可以视为3分类问题:模型需要从中选择运算符,因此,我们计算:

其中是考虑列,是尺寸分别为,和的可训练矩阵。注意要在右边使用,这意味着SQLNet在OP预测中使用列注意力来捕获图2b中的依赖项。

VALUE插槽。对于VALUE插槽,我们需要从自然语言问题中预测一个子串。为此,SQLNet使用一个序列到序列的结构来生成子串。注意,在这里VALUE键槽中标记的顺序很重要。因此,采用序列到序列结构是合理的。

编码器方面仍然采用双向LSTM。解码器阶段使用列注意力机制的指针网络来计算下一个标记的分布。考虑到先前生成的序列的隐藏状态是,自然语言问题中每个草图的LSTM输出是。然后,下一个VALUE中的标记的概率可以计算为:

其中是一个尺寸为的可训练向量,是三个尺寸为的可训练矩阵,是自然语言问题的长度。注意的计算使用了列注意力机制,其类似于计算。

注意代表在自然语言问题中第个标记生成下一个标记的概率,而SQLNet只是简单地为每个步骤选择最可能的一个来生成序列。注意标记也会出现在问题中,当预测出标记后,SQLNet模型将停止生成VALUE。

3.3.2、 预测SELECT子句

SELECT子句有一个聚合器和一个列名称。SELECT子句中的列名称预测与WHERE子句非常相似。主要区别在于,在SELECT子句中,我们只需要选择所有列中的一个列。因此,我们计算:

其中类似于(3)中的,是列的总数。注意,矢量的不同纬度都是有其相对应的列计算得来的。该模型可以预测最大化的列。

对于聚合器,假设SELECT子句中预测的列名称为,我们可以做简单的计算:

其中是一个尺寸为的可训练矩阵。注意聚合器的预测与OP共享相似结构。

3.3.3、 训练细节

为使我们们的实验可以复现,在这节中,我们将提供更多的细节。我们还提供了可以改进我们的模型性能的细节。

输入编码模型细节。自然语言描述和列名称都被看做一个标记序列。我们使用Stanford CoreNLP分词器来解析语句。每个标记代表一个one-hot向量并在它们反馈到双向LSTM之前将其输入到一个词嵌入向量中。在这里我们使用的是GloVe字嵌入。

训练细节。我们需要一个特殊的损失函数来训练序列到集合模型。直观地说,我们设计损失函数来奖励正确的预测而惩罚错误的预测。特别是当给出一个问题和个列的集合时,假设是一个尺寸为的向量,表示第列出现在WHERE子句的ground truth中,否则。然后我们最小化以下加权负对数损失函数来训练子模型:

在此函数中,权重是平衡正数据和负数据的超参数。在评估中,我们选择=3。对于除了的所有子模块,我们最小化标准交叉熵损失函数。

我们选择的隐藏状态的尺寸为100。我们选用学习率为0.001的Adam优化器,我们训练200epoch的模型,批次大小为64。我们在每一批次中随机重新组合训练数据。

权重共享细节。该模型包括用来预测草图中不同插槽的多个LSTM。在评估中我们发现使用不同的LSTM权重来预测插槽比共享权重要有更好的表现。然而,我们发现共享词嵌入向量有助于提高性能。因此,SQLNet的组件间只共享词嵌入。

训练词嵌入。在Seq2SQL中Zhong等人建议在训练期间应当固定出现在GloVe中的标记的词嵌入。然而我们观察到,当我们允许在训练期间更新单词嵌入时,性能可以提升2个百分点。因此我们像上文讨论的一样使用GloVe初始化了词嵌入,并允许其在Adam更新100epoch后进行训练。

表1:WikiSQL任务上的总体结果。和分别表示逻辑形式,查询匹配和执行精度。

4、 评估

在本节中,我们将SQLNet与当前最新技术进行对比,即WikiSQL任务上的Seq2SQL。获取代码请上https://github.com/xxj96/SQLNet。

在下面,我们首先提出评估设置。我们就综合查询的准确性,将我们的方法和Seq2SQL进行了比较,并进行不同子任务的分解比较。最后,我们提出了WikiSQL数据集的另一个变体,以展示SQL查询合成任务的另一个应用场景,并介绍我们的方法对比Seq2SQL的评估结果。

4.1、 评估设置

在这项工作中,我们主要集中于在2017年10月16日更新的WikiSQL数据集上。在我们的评估中,我们使用的是更新后的版本。

我们将我们的工作和WikiSQL任务上先进的技术Seq2SQL进行了比较,并使用三个度量标准来评估查询合成的准确性:

1.逻辑形式精度。我们将合成的SQL查询与groundtruth直接进行比较,以检查它们是否彼此匹配。这个指标被用于Zhong等人的文章中。

2.查询匹配精度。我们将合成的SQL查询和ground truth转换成了规范表示,并比较两个SQL查询是否完全匹配。这个指标可以排除只因为顺序问题而产生的错误负例。

3.执行精度。我们同时执行合成查询和ground truth查询,并比较结果是否匹配。这个指标被用于Zhong等人的文章中。

我们还对不同子任务的分解结果感兴趣:(1)SELECT子句中的聚合器;(2)SELECT子句中的列;(3)WHERE子句。由于结构不同,要做进一步的细化比较是很困难的。

我们使用PyTorch来实现SQLNet。Seq2SQL为我们比较中的基准方法,我们将我们的结果与Zhong等人报告的数字进行比较。

然而,Zhong等人的报告中不包括子任务的分解结果,并且其源代码不开源。为解决这些问题,我们复现了Seq2SQL。对于Zhong等人论文中没有提及的结果,我们提供了复现后的结果,并将其作为基准的结果与SQLNet进行比较。

4.2、 WikiSQL任务上的评估

表一显示了Seq2SQL和我们的方法的查询生成精度结果。我们首先发现我们复现的Seq2SQL结果要比Zhong等人论文中的要更好。由于我们无法访问其源代码,因此无法分析原因。

我们发现SQLNet甩下Seq2SQL很大一段差距。在逻辑形式矩阵中,在开发集上SQLNet超过我们复现的Seq2SQL10.7个百分点,并在测试集上超过10.5个百分点。如果我们与Zhong等人论文中的原始结果进行比较的话该结果会分别高出13.4和13.0个百分点。值得注意的是,即使我们通过查询的匹配精度来消除Seq2sql的错误负例,差距只会缩减1个百分点,而仍有9.7个百分点的差距。我们认为是由于Seq2SQL使用了序列到序列模型的原因才会使其存在“顺序影响”问题,而我们基于序列到集合的方法可以完全解决这个问题。

表2:WikiSQL数据集上的分解结果。Seq2SQL (C-order)表示在Seq2SQL在生成WHERE子句后,比较时我们就会把预测和groundtruth转换成规范顺序。Seq2set表示采用了序列到集合的技术。+CA表示使用了列注意力。+WE表示词嵌入允许被训练。和表示聚合器的精度和SELECT子句的列预测精度。表示生成WHERE子句的精度。

就执行精度度量来讲,SQLNet在开发和测试集分别比Seq2SQL高出9.0和8.6个百分比。虽然它们仍然很大,但仍比不上查询匹配精度的差距。这种现象表明,对于Seq2SQL无法进行完全准确预测的一些查询来说,其执行结果仍然正确。我们要强调的是,执行精度对表中的数据是敏感的,这有助于区别查询匹配精度和执行精度。

4.3、 WikiSQL任务的分解分析

我们希望对SQLNet和Seq2SQL在不同子任务上的性能进行进一步分析,以及对SQLNet中不同技术提供的改进进行讨论。结果陈列在表2中。

我们观察到SELECT子句的预测精度在90%左右。这表明SELECT子句比WHERE子句更易于预测。SQLNet对SELECT列预测的精度优于SEQ2SQL。我们将此改进归因于SQLNET使用了列注意力。

我们观察到SQLNet相对Seq2SQL最大的优势在于WHERE子句的预测精度。对WHERE子句预测的改进大约是11到12个百分点。此时请注意Seq2SQL事件所生成的约束的顺序起着重要作用。为了消除这种影响,我们使用类似于查询匹配精度的方式基于规范顺序的一种精度,即(我们复现的规范顺序的)Seq2SQL。这个指标下Seq2sql精度提高了一个百分点,它遵循我们观察到的Seq2SQL查询匹配的总体准确性。但我们仍然观察到SQLNet的性能大大超过了Seq2SQL。从分解角度来看,使用序列到集合体系结构的改进最大可以达到大约6个百分点。列注意力使一个纯序列到集合结构的性能提高了大约3个百分点,另外词嵌入提供了另外2个百分点的提升。

注意,SELECT预测的改进约为2点。两种子句大约一共提供了13到14个百分点的改进。

表3:WikiSQL变体数据集上的总体结果。

4.4、 WikiSQL任务变体上的评估

实际上,机器学习模型经常被定期再训练以反映最新数据集。因此,更常见的是,当模型被训练时,就可以在训练集中看到测试集的表格。原来的WikiSQL数据集被拆分,因此训练、开发和测试集它们的表集合是不相交的,因此它不能很好的接近应用程序场景。

为了更好地理解不同模型在此替代应用场景中的性能,我们重新洗牌数据,以便所有表都可以在训练集中出现至少一次。

我们在这个新的数据集上评估了SQLNet和Seq2SQL,并用结果做成了表3。可以观察到这两种方法的所有指标都得到了改进。我们将此归因于训练集上的模型观察到了测试集中全部的表。这一结果达到了我们的预期,Seq2SQL上的SQLNet的改进在不同指标上保持不变。

5、 相关工作

将自然语言转换为SQL查询语句的研究由来已久。早期的工作主要集中在特定的数据库上,推广到其他新的数据库中需要额外的定制。

最近的工作考虑通过引入用户指南来缓解这个问题。相反,SQLNet在循环中不依赖人工。而另一个方向是将表中的数据合并为额外输入。我们认为,在处理大规模用户数据库时,这种方法可能会遇到可拓展性和隐私的问题。

SQLizer是处理同一应用场景的相关项目。Sqlizer也是基于草图的方法但它不局限于任何特定的数据库。不同于我们的工作SQLizer依赖于使用一个现成的语义分析器将自然语言问题翻译到草图上,然后使用例如类型定向草图和自动修复的编程语言技术,以迭代的方式将草图细化到最终查询中。由于SQLizer不需要特定数据库的训练,而且它的代码也不开源,因此我们不清楚SQLizer将如何在WikiSQL任务上运行。在这个项目中,我们专注于使用神经网络方法来处理NL2SQL任务。

Seq2SQL是与我们项目最相关的项目,并在WikiSQL任务上达到了最先进的水平。我们用Seq2SQL作为我们项目的基准。我们的方法SQLNet可以利用到Seq2SQL的所有优点,例如,我们可以对一个看不见的模式进行泛化,并且克服序列到序列模型的低效性。我们的方法改进了Seq2SQL,我们提出了一种基于序列到集合的方法,就是当顺序不重要时,我们可以消除序列到序列结构,因此我们不需要强化学习。这些技术使SQLNet的性能超越Seq2SQL9至13个百分点。

将自然语言解析为SQL查询的问题可以看作是一般语义解析问题的一个特殊实例。而现在有许多项目考虑将自然语言描述为逻辑形式。虽然它们不处理SQL生成问题,但我们观察到它们中的大多数都需要被微调到特定的兴趣领域,并且可能难以泛化。

Dong和Lapata给出了一个通用的方法,即使用序列到树模型来处理语义解析问题,并在许多任务上产生最先进的结果。这种方法已在Zhong等人论文中进行了评估,证实它已经不如Seq2SQL方法有效。因此,我们并没有把它纳入我们的比较中。

6、 总结

本文提出了一种处理NL2SQL任务的方法——SQLNet。我们观察到,所有使用序列到序列模型的现有方法在顺序无关的情况下都会遇到“顺序影响”问题。以前尝试使用强化学习来解决这个问题时只能带来一个小的改善,例如,大约2个百分点。在我们的项目中,SQLNet从根本上解决了“顺序影响”问题,方法是在顺序不重要的情况下使用序列到集合模型来生成SQL查询语句。我们又进一步介绍了列注意力机制,它可以进一步提高序列到集合模型的性能。总之,我们发现我们的SQLNet系统,可以改进现有的先进技术,即Seq2SQL,并能将各个指标提高9到13个百分点。这表明我们的方法可以有效地解决“顺序影响”问题,并为新的解决结构生成问题的方法提供了新思路。

转载声明

End.

本文来自企鹅号 - 智察媒体

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文来自企鹅号 - 智察媒体

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
数据库
云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档