AAAI 2021 | 基于动态混合关系网络的对话式语义解析方法
引言
机器可以自己写 SQL 语句吗?当然可以~只需要用自然语言描述你的想法即可,甚至还能进行多轮的交互!
语义解析(Semantic Parsing)是自然语言处理中的一个非常基础且重要的问题。近些年来,语言解析中的 Text-to-SQL 任务引起了学术界和工业界的广泛关注,该任务的目的是将自然语言转换为可执行的 SQL 语句,帮助用户仅使用自然语言便可完成和数据库的交互。
利用 Text-to-SQL 技术可以实现很多应用,比如对话式(上下文相关)语义解析 (Context-Dependent Semantic Parsing) ,数据库作为对话系统中的「知识」来源,将用户的每一个问题转换为对应的 SQL 语句,通过复杂的多轮问答,进而实现任务型对话。如下图所示,用户通过多轮的询问与数据库进行信息的交换,最终得到期望的回答。
▲ 图1. 对话式 Text-to-SQL 任务
针对这项任务,耶鲁大学联合 Saleforce 分别于 ACL 2019 和 EMNLP 2019 提出了两个公开的 Benchmark,SParC [1] 和 CoSQL [2],这两个数据集有如下共同特点:
1. 跨领域:每个数据库都属于不同的领域,这对模型的泛化性提出了严格的要求;
论文标题:
Dynamic Hybrid Relation Network for Cross-Domain Context-Dependent Semantic Parsing
收录会议:
AAAI 2021
论文链接:
https://arxiv.org/abs/2101.01686
代码链接:
https://github.com/huybery/r2sql
首先我们需要先思考对话式解析模型需要具备哪些能力?首先模型需要能够处理来自任意领域的数据库信息,比如金融、政务、酒旅等行业数据。所以模型面临的第一个挑战:如何处理跨领域问题?对于任意垂域都能够完成 SQL 生成。
其次,在对话场景中,用户是通过多轮的查询实现最终的目的,处理当前的 SQL 生成可能需要依赖历史的信息,其中大量的指代、省略问题需要被关注。同时,在对话流不断增长的过程中,用户关心的焦点也可能发生偏移,这引出了第二个挑战,如何准确的理解和利用上下文?
下面我们从这两个方面分别具体的介绍其中的难点。
2.1 跨领域问题
首先是 Text-to-SQL 的跨领域问题,主流的思路是直接建立自然语言和数据库中 列、表、值的连接,研究者将其称为 Schema linking。如图 2 所示,模型需要能够将自然语言中出现的实体和数据库模式中的信息进行对齐,最终生成正确的 SQL 结果。
我们通过分析 SParC 中验证集的 bad case,发现很多样本都是因为命中了错误了表名或列名导致生成的错误,所以 Schema linking 的效果将直接影响 SQL 的生成。
过往的上下文依赖的方法,包括 CD-Seq2Seq [1],EditSQL [4] 等,都是基于 Cross attention 机制来完成 linking,我们将这种仅仅凭借 Cross attention 方式构建 linking 的结果成为隐式关系,这种方法对于很多表面特征捕捉较差,比如 n-gram 匹配等。
而 RAT-SQL [3] 提出了一种可以融入规则先验的 self-attention 结构,能够有效的捕捉表面特征。尽管 RAT 的结构声称可以同时处理 hard 和 soft 的关系,但是我们发现这种结构还是更容易偏向 hard 的关系,所以我们将 RAT 归类为显式关系。隐式关系和显式关系各有优势,所以一个难点在于能否有一个统一的框架同时兼顾不同类型的关系探索?
2.2 上下文建模
在对话式的 Text-to-SQL 任务中,如何进行上下文的建模也是亟需解决的问题。过去的工作主要是围绕话术 (utterance)层面的上下文,如图 3 展示很多在 utterance 层面上下文建模的方法。
得到表征后,我们又设计了任务相关的编码器来提升表征性能,针对多轮的话术,我们首先利用 utterance-level 的 Bi-LSTM 得到每一个话术的隐向量:
然后利用流行的 interaction-level 的编码器得到上下文向量:
最终利用这个上下文向量来丰富话术编码:
上述流程与图 3 (b) 的基于 turn 上下文建模的方式一致。除了话术外,我们还需要对数据库模式中的表名列名进行编码,这里是利用独立的 Bi-LSTM 进行编码:
如图 4 所示,随着轮次的增多,蓝色节点(token of utterance)不断的增多,并且不断和绿色节点(schema)产生新的交互(linking),整个对话流程可以看做是一个动态进化 graph 的范式。
那么在这个动态图的过程中,模型在编码器层面已经关注到了 utterance 上下文的信息,那么对于 linking 的上下文信息如何处理呢?用户聚焦的意图经常会发生偏移,所以模型应该更关心当前问句下的 linking 信息,而对于较早的 linking 信息应该适度的「衰减」,所以我们需要模仿人类的交谈,引入记忆衰减的方式来归纳偏置。特别的,我们提供了几种针对 linking 的不同衰减方式。
首先从话术粒度的层面考虑,我们可以引入 token-level 的遗忘和 utterance-level 的遗忘;而在遗忘方法的层面,我们首先可以想到的是引入门控机制,让网络自己去学习不同 token/utterance 的权重,这种方式尽管有一定的提升,但是引入了额外的参数而且缺乏显示的约束,容易引入噪声导致训练的不稳定。
所以我们开始考虑能不能引入一些函数,直接来计算衰减的权重?这里我们利用了 Schedule sampling [6] 中的三种衰减函数进行实验,分别是:
我们称之为 DCRI(Dynamic Context Representation over Implicit Relations)。
针对显式关系:
我们称之为 DCRE(Dynamic Context Representation over Explicit Relations)。
最终我们将 DCRI、DCRE 以及解码器输入的表征进行融合,同时结合隐式和显式关系,得到拥有丰富上下文 linking 信息的表征输出。解码器部分我们沿用了 EditSQL [4] 的方案。
我们在两个大规模的跨领域上下文相关的 benchmark,SParC 和 CoSQL 上评估模型的效果。这两个数据集拥有 138 个领域下的 200 个复杂的数据库,以及上万条的问题话术。该任务有两种评测方式,分别是评测单轮的 Question Match 和评测多轮的 Interaction Match。如下表所示,我们在验证集上对比了一系列先进的方法,展示出动态混合关系网络的优势。
我们还将模型提交到了官方的测试集榜单中,截至投稿时,我们的方法达到榜首:
除此之外,我们还执行了一系列的消融实验:针对 DCRI 和 DCRE,我们发现尽管显式关系更具可解释性,但隐式关系对于最终的结果同样有增益,证明了混合关系的重要性。
在衰减函数的作用下,DCRE 呈现渐变的趋势,更关注附近轮次的信息,减少历史轮次的干扰。
我们还分析一些样例,发现我们的模型在指示代词、所有格限定、回指以及操作符等情况下相比之前的模型有较好的改进。
还能做什么?
linking 的路仍然很长。目前的 linking 是数据或规则驱动的,这造成了模型缺乏一些真实世界的常识,比如模型很难理解 「republics」是一种政府的形式,导致无法和 「country.governmentform」进行 linking,而这个信息对于 SQL 的生成至关重要。所以如何引入外部知识解决这些问题是一个重要的方向。 模型效率。当前的模型主要还是基于 seq2seq 架构,其中很多组件无论是训练还是推理都非常耗时,无法满足业务的线上要求,如何将模型更好的落地也非常值得探索。
结论
本文专注于跨领域的对话式 Text-to-SQL 任务,我们提出动态上下文模式图的框架,联合的学习话术(utterance)、数据库模式(schema)和其之间复杂交互(linking)的表征。该框架整合了遗忘机制,从而引入归纳偏差来构建丰富的上下文关系表示,为动态多场景中不同层次的上下文建模提供了一个灵活的框架。提出的模型在 SParC 和 CoSQL 数据集上取得了 SOTA 的结果。
最后打个小广告~ 阿里巴巴达摩院 Conversational AI 团队正在招聘自然语言理解和 Conversational Semantic Parsing 相关方向的 Research Intern,欢迎感兴趣的同学联系 binyuan.hby@alibaba-inc.com !
参考文献
更多阅读
#投 稿 通 道#
让你的论文被更多人看到
如何才能让更多的优质内容以更短路径到达读者群体,缩短读者寻找优质内容的成本呢?答案就是:你不认识的人。
总有一些你不认识的人,知道你想知道的东西。PaperWeekly 或许可以成为一座桥梁,促使不同背景、不同方向的学者和学术灵感相互碰撞,迸发出更多的可能性。
PaperWeekly 鼓励高校实验室或个人,在我们的平台上分享各类优质内容,可以是最新论文解读,也可以是学习心得或技术干货。我们的目的只有一个,让知识真正流动起来。
📝 来稿标准:
• 稿件确系个人原创作品,来稿需注明作者个人信息(姓名+学校/工作单位+学历/职位+研究方向)
• 如果文章并非首发,请在投稿时提醒并附上所有已发布链接
• PaperWeekly 默认每篇文章都是首发,均会添加“原创”标志
📬 投稿邮箱:
• 投稿邮箱:hr@paperweekly.site
• 所有文章配图,请单独在附件中发送
• 请留下即时联系方式(微信或手机),以便我们在编辑发布时和作者沟通
🔍
现在,在「知乎」也能找到我们了
进入知乎首页搜索「PaperWeekly」
点击「关注」订阅我们的专栏吧
关于PaperWeekly
PaperWeekly 是一个推荐、解读、讨论、报道人工智能前沿论文成果的学术平台。如果你研究或从事 AI 领域,欢迎在公众号后台点击「交流群」,小助手将把你带入 PaperWeekly 的交流群里。