论文题目：Bridging the Semantic Gap with SQL Query Logs in Natural Language Interfaces to Databases
通过数据库自然语言接口的SQL查询日志消除语义差距
摘要—构建自然语言数据库接口（NLIDB）的一个关键任务是消除自然语言查询（NLQ）与底层数据之间的语义鸿沟。 挑战本身表现出的两种特定方式是通过关键字映射和联接路径推断。 关键字映射是将原始NLQ中的各个关键字映射到数据库元素（例如关系，属性或值）的任务。 这是一项困难的挑战，因为将用户的思维模型和命令映射到架构定义和底层数据库的内容是模棱两可的。 连接路径推断是在最终SQL查询的FROM子句中选择关系和连接条件的过程，并且这很困难，因为NLIDB用户缺乏数据库模式或SQL的知识，因此无法显式指定所需的中间表和连接从而 构造最终的SQL查询。 在本文中，我们建议利用数据库的SQL查询日志中的信息来增强现有NLIDB在这些挑战方面的性能。 我们提出了一个系统名字叫做TEMPLAR，可用于扩充现有的NLIDB。 我们广泛的实验评估证明了我们方法的有效性，通过利用SQL查询日志信息，可以使现有NLIDB的top-1准确性提高138％。
PS：自然语言查询的两个关键点：
1.自然语言关键到数据库底层数据元素的映射问题
2.如何从用户的语句中提取出要查询的表以及要连接的中间表。（因为大部分用户是没有数据库知识的，计算有也不知道你们数据库里有哪些表，这些表是如何关联的）
介绍：
从商业智能到网页设计再到回答日常事实问题，当今技术含量高的世界绝大多数情况下都依赖于数据库系统。 最终用户有着各种各种的不同需求来查询这些数据库来获取信息，无论是通过Google Assist1，Apple Siri2或Amazon Echo3等基于语音的助手；还是 以结构化语言（例如SQL或LINQ）进行查询； 又或在Google或Bing等搜索引擎上进行关键字搜索。
虽然关系数据库已经存在了数十年，但是访问诸如SQL之类的数据库的查询语言对于普通的最终用户而言却不太可能成为常识。 因此，该领域的主要目标是提供一种方法，供用户通过与数据库的自然语言接口（NLIDB）使用日常语言查询数据库。
NLIDB的任务主要被建模为将自然语言查询（NLQ）转换为SQL查询的问题。 为解决此任务而开发的最新系统采用两种体系结构方法之一：
①将NLQ转换为中间表示然后将这些表示映射到SQL的管道方法
以及②使用端到端学习的方式的深度神经网络进行翻译（转换）。
但是，正如[23]指出的那样，支持NLIDB的一个基本挑战是消除NLQ和底层数据之间的语义差距。 将NLQ转换为SQL时，会遇到两个特定问题：（1）关键字映射和（2）连接路径推断。 关键字映射是将原始NLQ中的各个关键字映射到数据库元素（例如关系，属性或值）的任务。 这是一项具有挑战性的任务，因为在将用户的思维模型和方向映射到模式定义和数据库内容时，模棱两可。 连接路径推断是在最终SQL查询的FROM子句中选择关系和连接条件的过程，这很困难，因为NLIDB用户不了解数据库模式或SQL，因此无法显式指定中间表和连接 需要构造最终的SQL查询。
表一总结了最新的系统及其处理从NLQ到SQL转换的每个步骤的策略。 上半部分列出了基于管道的系统，其中每个子问题都得到了明确处理，而下半部分则是深度学习系统，它们通过选择输入表示形式和网络体系结构隐式解决了这些挑战。 关键字映射任务分为“相对/属性映射”和“值映射”列，因为某些系统具有独立的处理程序。 出现一些常见的模式：
•对于关键字映射，绝大多数系统使用词法数据库，如WordNet [28]或词嵌入模型[27]，[31]。
•连接路径推断主要通过用户交互[22]或启发式方法（例如选择最短的连接路径[38]或手写的修复规则[41]）进行处理。
尽管这些方法中的每一种都工作得相当好，但仍有很大的改进空间。 例如……论文中自己看。
比如：
1.在word embedding model中相似度很高的两个词容易造成匹配错表。（关键字映射出错。）
2.关联表的路径不符合预期的意图。
最近的端到端深度学习系统显示了从大量NLQ-SQL对中学习的巨大希望。 但是，手动创建带标签的NLQSQL对既昂贵又费时。 尽管最近做出了努力来合成NLQ-SQL对[18]，[38]或从SQL查询的用户描述中得出[9]，但是获得现实的标记数据仍然是一个开放的研究挑战。 结果，到目前为止，最先进的深度学习系统[40]，[44]只能在不需要联接的简单NLQ数据集中进行测试。
PS：用于给深度学习模型学习的NLQ-SQL的数据集制作成本高，因此缺少数据集，所以现有的深度学习模型还只能在不需要表关联的简单NLQ数据集中进行测试。
a）我们的方法：虽然对于给定的架构很少有大量的NLQ-SQL对，但是鉴于NLIDB通常不是为新实例化的数据库而是为现有的生产数据库而构建的，因此更容易获得大型SQL查询日志[1]， [2]。 尽管SQL查询日志不是典型的有输入输出对的有监督学习训练集，但是像SQL查询日志这样的丰富数据输出集仍可以提供翻译价值，就像人们可以只听电话通话的一端推断出很多正在交流的信息，接下来该说些什么。 我们的方法是使用数据库的SQL查询日志中的信息来选择更相似的关键字映射并为NLQ的SQL转换连接路径。
我们提出了一个系统名叫TEMPLAR，该系统使用SQL查询日志信息来扩展现有的基于流水线的NLIDB，例如[22]，[32]，[33]，[41]。 虽然也有可能增加端到端深度学习NLIDB，但这将需要额外的预处理或后处理，我们将其留作以后的工作。（以后可能会用端到端学习的深度学习？再说吧）
考虑我们的运行示例中的TEMPLAR用户：
示例3. John在扩展了TEMPLAR的NLIDB上发布了示例1的NLQ。 NLIDB将关键字映射推迟到TEMPLAR，TEMPLAR使用SQL查询日志中的信息将发布确定为最可能的映射。 NLIDB接收此信息，执行任何必要的处理，然后通过将映射的关系和属性传递给TEMPLAR来推迟对TEMPLAR的联接路径推断。 TEMPLAR接受输入，然后再次使用SQL查询日志得出结论，最可能的联接路径涉及通过关键字关系将发布连接到域。 此联接路径被传递回NLIDB，后者构造与John的意图匹配的最终SQL查询。
b）技术挑战：与传统的学习任务不同，传统的学习任务使用完整的输入输出对（即NLQ-SQL对）来训练模型，而我们仅使用输出日志（即SQL查询）。 因此，SQL查询日志中的信息不会直接映射到翻译任务。 此外，即使查询日志很大，大多数查询也可能不是先前发出的查询的精确重复。 最后，我们的目标是增加而不是取代NLIDB。 因此，我们需要TEMPLAR能够通过一个简单的公共界面来协助多个NLIDB。 简而言之，挑战在于（1）有选择地激活SQL日志中的信息以进行NLQ-SQL转换；（2）允许生成不在日志中的新SQL查询；（3）（1）有选择地激活SQL日志中的信息以进行NLQ-SQL转换；（2）允许生成不在日志中的新SQL查询；（3）优雅地将日志信息与NLIDB中的现有技术集成。
c）贡献：我们的主要贡献如下：
•我们建议将查询片段作为SQL的基本组成部分，提供SQL日志的细粒度视图，以允许选择性激活日志中的信息。可以混合并匹配查询片段，以允许生成在查询日志中尚未观察到的新SQL查询。
•我们建议使用查询片段图作为一种新颖的抽象，通过对来自SQL查询日志的查询片段的共现进行建模，并将其与现有技术进行适当地集成以提高关键字的准确性，从而提高NLIDB中关键字映射和联接路径推断的准确性。
•我们引入了一个原型系统TEMPLAR，该系统在不更改其内部体系结构的情况下扩展了现有的NLIDB。
•我们通过广泛的评估证明了TEMPLAR如何能够将最新的NLIDB的top-1准确性提高至我们基准基准的138％。
网友评论