与您的数据对话：一个模型，任何关系数据库

TL；DR：基于我们在神经语义解析方面的最新研究，我们介绍了Photon，这是一个针对数据库的自然语言接口的现场演示。Https://naturalsql.com/🔗。

最近，该领域对基于自然语言的数据查询方法的兴趣激增。这在一定程度上是由自然语言处理的最新进展推动的，这些进步导致了基于语音和文本的界面在广泛的应用中的开发。方便快捷地访问数据是一种持续不断的需求，对自然语言信息系统的投资可以追溯到数据库系统的早期。在此之前，Salesforce发布了WikiSQL，这是一个大规模基准数据集，在将自然语言话语映射到开放域表上的结构化查询方面取得了重大进展。本文描述了我们在这一领域朝着更智能和更健壮的建模方向的最新研究，并介绍了Photon，一个复杂关系数据库的自然语言接口的活原型。

关系数据库(DB)。1970年引入的关系数据库仍然是跨行业使用的主流数据库体系结构。它使用由列(也称为"；字段&34；或"；属性"；)和行(也称为"；记录"；或"；元组"；)组成的互联表来组织数据(图2)。通常，每个表表示一个实体类型(例如，用户和联系人)；每列表示实体类型的一个属性(名称和地址)，每行表示一个实例。有些列是主键，用于唯一标识一行(例如contact.account_name)，有些列是外键，用于引用不同表中的主键(例如boat.contact)。

结构化查询语言(SQL)。大多数数据库使用SQL作为用户查询(SELECT)和操作数据(UPDATE/INSERT/DELETE)的语言。工业数据库管理系统(DBMS)通常实现自己的SQL方言(PostgreSQL、SQLite、Oracle、MySQL等)。和分机。虽然这些方言差异很大，彼此不兼容，但它们中的大多数都支持一些共同的功能。图3显示了一个复杂的查询，该查询选择来自不同部门的用户对弓箭手的平均评论分数，这需要连接三个表。

自然语言数据库接口(NLIDB)。虽然SQL最初是为最终用户设计的，但查询构造在实践中往往很费力，并且会造成陡峭的学习曲线。目前，将SQL查询嵌入到软件中以提供更易访问的用户界面(例如仪表板)是很常见的。然而，这并不能消除对基于自然语言的查询的需求，这支持更大的用户主动性，并且通常不那么分散注意力。

Photon是一个最先进的NLIDB原型，它支持大多数常见的SQL操作(包括表连接和查询组合)，并且可以跨不同的数据库工作。

我们设计Photon遵循两个核心原则：智能性和健壮性。它采用模块化结构，包括最先进的神经语义解析器、人在环路中的问题校正器、数据库引擎和响应生成器。我们希望该界面能够正确解释大量不同的自然语言问题，同时避免对噪音输入进行不可靠的猜测。

跨数据库语义解析。NLIDB的核心是将自然语言用户输入映射到可执行SQL查询的语义解析器。Photon采用跨DB语义解析模型，为大量数据库(包括它从未接受过培训的数据库)实现这种映射。

在前人工作[2，4]的基础上，我们设计了一个以自然语言问题和目标数据库模式为输入，合成SQL查询为输出的编解码器模型。我们将输入问题和DB模式联合表示为一个标记序列(图4)，该序列首先用BERT编码，然后用双向LSTM编码。我们使用与此编码中的特殊标记[T]和[C]相对应的隐藏表示作为表和列表示，并为它们注入DB元数据特性。编码的问题部分进一步用另一个Bi-LSTM编码，我们使用它的输出作为解码器的开始状态。

我们的解码器是一个基于LSTM的指针生成器模型，它将复杂的SQL查询生成为一系列令牌。在每个解码步骤，解码器执行由学习的选通函数确定的三个动作之一：生成SQL关键字、复制表/列或从输入发声复制令牌。

我们在流行的跨DB Text-to-SQL数据集SPIDER[4]上训练模型。结合表值扩充和静态SQL正确性检查，我们的模型在Spider dev集合上达到了最先进的结构匹配精度。更多细节可以在我们的研究论文中找到。(我们正在不断改进语义解析器，并更新Photon后端。)。

处理无法翻译的话语。虽然最先进的跨DB语义解析器能够处理大量常见的用户请求，但仍有很大的改进空间。除了减少具有SQL转换的问题上的错误之外，我们还需要正确处理无法映射到SQL语句的输入话语，即使是人工也不能。

实用的NLIDB暴露在各种噪音的用户输入中。用户在与这样的接口[6，8]交互时倾向于使用未指定且不完整的自然语言表达式，并且可能要求数据库不提供的信息。对于这样的输入，基于学习的语义解析器可能会做出表面上看起来正确的不可靠的猜测。当噪声输入看起来类似于嵌入空间中的有效输入时，这一问题对于端到端神经语义解析器尤其严重。

Photon实现了一个模块，该模块自动检测无法翻译的输入话语，并突出显示不明确的跨度，以帮助用户重新表述话语。为此，我们扰动了Spider数据集，以自动合成与图5中的类别相对应的大量不可翻译的话语。我们的扰动方法不仅产生了不可翻译的问题，而且还产生了导致其不可翻译的确切跨度。利用这些新数据，我们通过从输入话语中提取混淆跨度来训练神经可译性检测器。如果检测到混淆跨度，我们认为问题不可翻译，并提示用户重新措辞。如果模型检测到混淆跨度可能引用某个字段，我们将运行语言模型困惑检查来识别可能的目标字段，并将其建议给用户。更多细节可以在我们的研究论文中找到。

双输入模式。Photon接受自然语言问题和格式良好的SQL查询作为输入。如果输入是有效的SQL查询，它会自动检测输入类型并立即执行输入。我们预计在某些情况下，形成自然语言问题可能很困难，直接编写SQL可能会节省时间，特别是对于精通SQL的用户。

图6显示了光子的流程图。混淆检测模块确定输入问题的可译性。对于可翻译的问题，语义解析器尝试将其解析为以DB模式为条件的可执行SQL查询。对于不可翻译的问题，混淆跨度与上下文一起被送入问题纠正模块，以预测用户试图提出的问题。响应生成模块通过确认成功翻译、征求反馈或要求用户重新措辞来处理用户交互。

自7月份首次亮相以来，已有数千名用户与该演示互动，我们收到了许多有用的反馈。在这里可以找到两篇关于Photon的LinkedIn帖子：Link1，Link2。

我们的演示用户主要是数据科学家、分析师、软件工程师、学生和教授。许多人喜欢我们的系统，并对看到未来的迭代表示了强烈的兴趣。以下我们总结了一些建议和关注事项，这些建议和关注可能会对社区未来的发展有所裨益。

信任和可靠性。基于深度学习的语义分析器就像黑匣子一样，它们的预测缺乏可解释性。此外，当输出可执行并产生与正确解释相同类型的结果(例如，到达SFO的航班与离开SFO的航班)时，最终用户很难检测到解析器所犯的错误。一些开发人员表示不愿信任系统输出，强调需要对生成的查询和派生查询的过程进行更好的解释。

自我控制。一些用户表示不愿失去对SQL制作过程的控制。引用其中的一句话，但是……。但是.。我喜欢早上新鲜手工制作的sql的味道，😁&34；。双输入模式是我们提供的一种解决方案，可以让程序员在他们喜欢的时候坐在飞行员的座位上。还可以实现能够与用户交互地生成SQL查询的功能，将最终控制权留给用户。

外部知识。一些用户指出，在某些情况下，用英语表达目标可能很有挑战性，需要了解底层的业务逻辑结构。在未来，我们希望将业务逻辑的背景知识集成到界面中，以便能够从简单的话语实现更复杂的功能。

SQL查询优化。一些用户建议，这些接口应该与数据库设计和资源分析相结合，以生成不仅准确而且优化的SQL查询。考虑到企业越来越多地处理大数据，这个方向特别有趣。

我们介绍了Photon，这是一个模块化的跨域NLIDB，它支持大多数常见的SQL操作和过滤不可翻译的话语。目前的光子系统还只是一个原型，用户交互和功能有限。我们希望在合适的时候继续向Photon添加更多功能，比如语音输入、自动补全和输出可视化。鉴于现代自然语言处理的进步，我们相信自然语言信息系统的时代即将到来。

曾纪川*，习维多利亚·林*，熊才明，Richard Socher，Michael R.Lyu，Irwin King，Steven C.H.Hoi。ACL 2020系统演示。Photon：一个健壮的跨域Text-to-SQL系统。*：同等供款

我们感谢Dragomir Radev和陶宇进行了有价值的研究讨论；Melvin Gruesbeck为前端设计提供了咨询和样机；Andre Esteva、周英波和Niish Keskar为模型服务提供了建议；Srinath Reddy Meadusani和Lavanya Karanam为设置服务器基础设施提供了支持；Victor钟、Jesse Vig和刘文浩就本博客帖子提供了有用的反馈；Salesforce AI Research的成员进行了试点