论文阅读：《Towards Scalable Multi-domain Conversational Agents:The Schema-Guided Dialogue Dataset》

论文阅读：《Towards Scalable Multi-domain Conversational Agents:The Schema-Guided Dialogue Dataset》

背景

英文名：Towards Scalable Multi-domain Conversational Agents:
The Schema-Guided Dialogue Dataset
中文名：迈向可扩展的多领域对话代理：SGD数据集
因为项目要调研多领域多轮问答技术，所以看了好多篇paper。经过查阅，发现最大的痛点还是难做的数据集。然后这篇论文，顾名思义，就是通过新数据集来致力于开启工业界多领域问答的。

所谓的多领域，是对传统的单领域而言的。单领域，或者说限定域面向任务/目标型的问答机器人，已经发展的不错了。但是一些大型的问答机器人（比如Google Assistant），需要支持数量不断增加的大量服务，把众多领域中不断增加的大量服务集成在一起（每种服务的功能可能有重叠部分)，为达到这个目的，有很多的挑战需要解决，数据层面讲，我们缺少能够匹敌大型跨服务问答机器人所面对的规模和复杂性的合适数据集；从设计层面讲，过去的通用思想即master schema有很多局限性，比如难以支持新服务、造成新的或小型服务的集成复杂化，维护机器人的工作量大、跨服务的概念不易联合建模等。

论文团队的解决方案就是新数据集+模式引导范式。论文团队(谷歌)发布了新的数据集SGD——Schema-Guided Dialogue，模式引导的对话数据集。谷歌研究团队称，SGD数据集是目前公开可用的、最大的任务型对话数据集，是第一个涵盖多个领域并为每个域提供多个API的数据集。SGD的意思是Schema-Guided Dialogue。模式引导范式不同于过去的master schema，其思想后面会讲。

论文团队这样形如它们的Schema-Guided对话数据集——This allows a single dialogue system to easily support a large number of services and facilitates simple integration of new services without requiring additional training data.(这样的数据集能够使得一个对话系统支持很多的服务并且能够简化新的服务整合的过程)。

论文团队这样形如它们的Schema-Guided范式——present a novel architecture for multi-domain dialogue state tracking.（为多领域对话状态跟踪提供了新颖的架构）。

本论文会反复提到一些概念，在此罗列：
zero-shot :零样本。zero-shot 设置，即没有针对新服务和API的训练数据
OOV：out of vocabulary,即超出词表外的词。

1 Introduction

Virtual assistants（虚拟助手，本文中即指任务型问答系统）目前面临的新挑战，是需要能方便地添加和支持新服务。所以研究工作就相应转向了scalable dialogue systems that can handle tasks across multiple application domains（多应用领域的大型对话系统）。
数据导向的多领域模型深度学习（无论端到端的还是模块化的）都是对话状态跟踪+策略学习的工作流，相应的就是已经公布的几个好的多领域数据集：MultiWOZ,M2M,FRAMES。

然而，现存数据集还是有缺陷，因为现在工业界需求的多领域问答，必须支持大型、可持续的跨领域不断增长的服务。相形之下，现存数据集覆盖的领域太少，而且它们为每一个领域定义一个静态API，但是现实中，服务之间是存在重叠功能，但异构接口的。

论文团队对此提出了SGD数据集。SGD数据集是目前公开可用的、最大的任务型对话数据集，是第一个涵盖多个领域并为每个域提供多个API的数据集。其测试集中包含了属于16个领域的26个种服务，共16000场对话。此外，为了充分测试模型在zero-shot settings(零样本环境)上的泛化能力，验证集包含了不可见的服务和领域(unseen services and domains)。此数据集被设计成能做为有效的测试平台，它也可用于意图预测，槽位填充，状态跟踪和语言生成以及大型问答系统的其他任务。

论文团队还提出了schema-guided paradigm（模式引导范式），支持对所有服务和API建立一个统一的对话模型。以服务的模式（service’s schema）作为输入，模型将对模式中存在的意图和槽位的动态集作出预测。这种设置使得所有服务可以有效地共享知识，以及允许模型处理unseen的服务和API（通过关联模式们之中的语义信息）。

通过使用BERT大型预训练模型（有谷歌味了），我们的模型可以泛化到unseen服务中，并且对API变动鲁棒，并且在两版本的MultiWOZ datasets上都达到SOTA。

模型下载地址：schema_guided_dst

数据集的下载地址：github.com/google-researchdatasets/dstc8-schema-guided-dialogue

数据集内容对比：见表1

数据集对比表：SGD的服务数、领域数、对话轮次数和每场对话的平均轮次数远超其他。槽值对更是高了一个数量级。

2 Related Work

任务型问答系统是数据密集型的，此节主要谈谈相关的数据集们。
起初的数据集受限于单领域；
后来DST挑战带动了数据集复杂度的提升；
其他优秀数据集，如WOZ2.0,FRAMES,M2M,Multi-WOZ等，引入了多种数据采集技术，包括两大类：

• WOZ型：找两个人，分别扮演用户和系统，用户给出其要满足的目标，系统连接实体数据库，返回首选项。代表数据集：WOZ2.0,FRAMES,Multi-WOZ
• 机器对机器交互型：指的是基于模拟的对话生成的一系列探索工作，其中模拟用户和系统的角色以生成完整的对话流，然后可以通过人工将其转换为自然对话。 这样的框架具有成本上的高效和容错能力，因为底层人员的工作更加简单，还能自动获取语义注释.代表数据集：M2M

除了多领域之外，近期的研究工作还集中在zero-shot modeling（零样本建模）、领域适应（domain adaptation）和迁移学习（transfer learning）技术。

小规模数据集下，对话状态被看做是所有可能的槽值对的分布。对于要操作大型槽值动态集的真实服务的虚拟助手来说，按上面方式部署上去并不实际。 解决这些问题的方法是利用槽值的动态词汇表，这已经在2019的一系列论文中被提出来了。

3 The Schema-Guided Dialogue Dataset

我们的目标是创建一个基准数据集，用于构建大规模的虚拟助手。
本文提出的SGD的特点：
每一领域拥有多种服务，代表了规模性挑战
测试集包含了很多的服务和相应槽位，是测试集中未出现的，以帮助测试模型在不可见服务上的表现。

使用众包方式来将大纲改写成自然语言。

如表2中列出了存在于我们的数据集中的数据：17个领域（训练中不包含“Alarm”领域），34个实现这些域的服务或API。 我们的模拟框架与这些服务互动，生成对话大纲(dialogue outline)，即对话的语义表示。然后，我们使用了众包将这些大纲转译为自然语言话语。 我们新颖的众包流程保留从模拟器获得的所有注释，并且对话收集后不需要任何额外的注释。

在本节中，我们将详细描述这些步骤，然后介绍对收集的数据集的分析。

3.1 Services and APIs 服务和API

把带附加约束的意图和槽位的组合定义为服务的模式，一个例子如图1所示（电子手表）。

使用SQL引擎实施所有服务。从FreeBase中依据模式抽样出实体，从适当的属性获取模式中定义的槽值——由于实体属性通常是相关的（比如餐厅名称往往包含了其特色的美食），因此我们决定使用Freebase而非合成实体来对真实的实体进行采样。FreeBase中不提供的那些槽位（例如事件日期、事件、可用账单计数）由综合采样得到。

为了反映存在于真实世界的服务和API的约束，我们设置了一些其他的限制。

1. 槽位可分类性限制：
   首先，对于日期、时间，以及像电影歌曲这种会定期添加新值的槽位，我们专门讲它们识别为非分类(non-categorical)槽位，并且并不专门为其维护一个所有可能槽值的列表/集合。我们还确保验证集含有足够量的测试集中没有的槽值，以便在存在新值的情况下评估模型。另外的一些槽位被定义为可分类槽位（categorial），例如性别、星期、人数等，我们给它们指定了所有可能槽值的集合。但是，这些值在跨服务时未必是一致的，例如性别槽位的值可能是(male，female)、（M，F）、（he，she）等。

2. 槽位组合行限制：
   其次，真实世界只会使用有限数量的槽位组合来调用服务，例如餐厅预订API不允许用户在未指定位置的情况下按日期检索餐厅。而现有数据集把这些规矩简单化了，从而导致了实际服务或API无法支持的工作流。如图1所示，一个服务所支持的不同服务调用被列举为意图（intent），每个意图指定一组必需的槽位，如果这些必需槽位未指定具体指，系统就不允许调用此意图。每个意图的槽位是灵活的，比如列举出若干个可选槽位，如果用户未指定就是默认值，指定则覆盖默认值。

3.2 Dialogue Simulator Framework 对话模拟器框架

使用对话模拟器（Dialogue Simulator）对服务交互，通过USER agent和SYSTEM agent交互的方式生成对话大纲（非自然语言）(dialogue outlines)。
图2显示了我们的对话模拟器的总体框架。
两个agent，分别扮演用户和系统，使用对话动作制定的有限动作集进行交互，这些对话动作在于为了捕获各种对话轨迹(dialogue trajectory)而设计的概率自动机（probabilistic automaton）。这些对话动作使用一个或多个槽值对作为参数。对话动作的分布如图4b所示。

对话开始时，为用户agent植入场景(scenario)，所谓场景指的是一系列待实现的意图。我们为训练集确定了200多种不同的场景，每个包含5个意图。对于多领域对话，我们还确定了在切换意图时槽值可能会转交的槽位组合，例如，餐厅预订中address可能会成为出租车服务中的destination。

植入场景后的用户agent便生成对话动作，以在下一轮输出。它可以通过访问服务模式或raw SQL后端来检索参数（即生成动作的槽值）。得到用户动作后，系统agent会以相似的方式生成下一组活动。但与用户agent不同，系统agent限制了对服务的访问（以虚线表示），例如，它只能通过为服务调用提供所有必需槽值来查询服务，这样做可以确保我们生成的所有工作流都是合法的。

在通过一些列用户和系统动作实现了意图之后，用户agent查询场景，或者系统可以给出意图的建议，以进入下一个意图。例如，在预订餐厅后紧接着预订餐桌。模拟器还允许一个给定turn中同时有多个意图是激活的。

值得注意的是，我们在模拟自动机（ simulation automaton）中未包含任何特定于领域的约束。所有特定于领域的约束it is worth noting that 是编码在schema和scenario中的, 这样使得我们可以在跨领域和服务时方便地使用模拟器。

3.3 Dialogue Paraphrasing 对话改写

对话改写框架，作用是把模拟器生成的大纲转化为自然语言对话。如图3所示，

用户或系统动作中存在的槽值采用规范形式（canonical form），因为它们是直接从服务获得的。但是，用户在对话过程中可能会以各种不同的方式引用这些值，例如“los angeles”被引用作为“LA”。为了引入这些自然语言上的变种，我们用一个随机选择的变量（在用户对话轮次中保持恒定）。替代不同的槽值，如图3b所示。

接下来我们定义了一组动作模板，用于将每个动作转化为utterance。下面展示了一个例子：
然后将通过上述步骤转化来的自然语言交给底层员工进行改写，以确保其自然连贯。
另外的一个好处是能自动生成slot span，这大大减轻了标注工作。整个过程保留了从模拟器中获取的所有标注，包括对话状态，因此不需要进一步的标注。

于是，我们可以以很少的资源收集更多的数据。

3.4 Dataset Analysis

我们的数据集，是目前公开可用的、最大的任务型对话数据集，是第一个涵盖多个领域并为每个域提供多个API的数据集。SGD的意思是Schema-Guided Dialogue。标注包括每个用户说话的意图和对话状态，以及每个系统的动作。（我们还有一些其他注释，例如用户动作，但是我们在公开版本中保留了它们）。这些标注使得我们的数据集也可用于意图预测，槽位填充，状态跟踪和语言生成以及大型问答系统的其他任务。数据集的内容详见图4和表2.注意除了INFROM，REQUESRT，GOODBYE之外，所有的对话动作都是特定于用户后系统的。

4 The Schema-Guided Dialogue Approach

构建多领域多服务的虚拟助手，一种设计思想是master schema，即为虚拟助手定义一个大型的统一框架，不同服务与之集成。但是这样其实是不行的，首先，很难开发出能涵盖所有case的通用模式。其次，即使开发成功，master schema也会使新的或小型服务的集成复杂化，并会增加维护虚拟助手的工作量。本文中，我们提出了模式引导方法作为替代方案，以允许轻松集成新的服务或API。下面是介绍：

每一个服务都提供一个列出了可支持的槽位、意图，以及配套自然语言描述的模式（图1就是一个例子）。虚拟助手采用一个不包含领域或服务特定参数的统一模型来基于模式元素进行预测。举个例子，如图5。图5展示了同一对话的相同对话状态表示在两种不同服务中如何得不同。在这里，departure和arrivial city是通过两种服务中功能相似而名称不同的槽位捕获的。此外，number_steps和direct_only突出显示，对于同一概念做解释的服务的独特性。

使用这种方法的优点有：

• 单一模型的使用有助于相关服务之间表示和转移共享知识；
• 由于该模型利用了模式元素的语义表示作为输入，它可以与未被训练到的不可见服务或API交互；
• 对于向服务中添加新的意图或槽位这样的变动，更加鲁棒。

5 Zero-Shot Dialogue State Tracking

我们的模式引导设置模型，除了通过意图和槽位的描述来限定service’s schema职位，对于来自新服务的潜在不可见输入，这些模型也需要访问表示。最近的预训练模型，例如ELMo（Peters等，2018）和BERT（Devlin等，2019）可以提供帮助，因为它们是在非常大型的语料库上训练的。本文我们基于ELMo、BERT等大规模预训练模型，提出了Zero-Shot模式引导的对话状态跟踪模型。
基于BERT的DST模型，叫做BERT-DST，参见论文:
BERT-DST: Scalable End-to-End Dialogue State Tracking with Bidirectional Encoder Representations from Transformer
模型包括两大部分：

1. Schema Embedding Module
   模式嵌入模块。数据集中的模式文件提供了每个模式元素(intents, slots and categorical slot values) 的自然语言描述，用预训练的BERT进行词嵌入。这些嵌入表示在状态更新模块中不再进行微调。
2. State Update Module
   状态更新模块。所谓的State Update，指的是存在于当前服务（current service）帧的槽值、与存在于先前的user utterance中的对于同样服务的帧的槽值的差别。我们训练这一模块，以预测active intent, requested slots和state update。

5.1 Model

现有的模型对静态模式进行预测，因此无法跨领域跨服务地共享知识。它们对模式的变动不鲁棒，需要添加新的标注数据（引入新的意图、槽位、槽值）重新训练模型。而我们的模型的方式与之相反，我们使用一个对所有服务和领域共享的模型进行这些预测。
首先，将存在于模式中的可分类槽位的所有意图、槽位和槽值encode为嵌入式表示。由于不同的模式具有的意图或槽位数量可能不同，因此可以通过在相应的模式嵌入中对它们进行调节来对动态模式元素集进行预测。

Schema Embedding

首先是模式嵌入模块。该模块的作用是，获取每一种服务模式的意图、槽位和槽值的嵌入表示。表3展示了用于嵌入每个模式元素是序列对（sequence pairs）。这些序列对被送入预训练的BERT encoder（如图6），输出$u_{CTS}$为模式嵌入。
对于一个给定的服务，有它的所有意图嵌入向量（I个，记为 { i j } \left\{ \bm i_j\right\} {ij​}）和槽位嵌入向量（S个，记为 { s j } \left\{ \bm s_j\right\} {sj​}），其中N（N≤S）个槽位是不可分类槽位，C=S-N个是可分类槽位，每一个可分类槽位对应一组所有可能的槽值的嵌入向量。上述收集起来的所有嵌入合称为模式嵌入。

Utterance Encoding

这是话语嵌入模块。用与(Chao and Lane 2019）一定的方法， 使用BERT来encode用户话语以及之前的系统话语，获得话语对（utterance pair）嵌入 $u=u_{CTS}$和 token level representations$t_1$;$t_2$;…;$t_M$, M是两个话语总共的token数。用模式嵌入和话语嵌入一起通过一个投影集（a set of projections）来获取模型预测，映射集如下定义：

Projection

对于任务K，下面三个等式构成一个投影变换$1=F_K(\mathbf{x},\mathbf{y},p)$（Projection Transform ）：
$${\mathbf{h}}_1=A(W_1^K\mathbf{x}+b_1^K)$$$${\mathbf{h}}_2=A(W_2^K(\mathbf{y}\oplus \mathbf{h}1)+b_2^K)$$$$1=W_3^K{\mathbf{h}}_2+b_3^K$$
作用是将d维空间中的向量x和y映射成$p$维向量1。A是一个激活函数，本文同BERT用GELU，h,W和b都是待训练的参数。

Active Intent

一个服务，它的激活意图（active intent）表示被用户询问的，系统当前正在实现的意图。如果当前没有任务意图被处理，就将值设为“NONE”。“NONE”意图的可训练参数记为$i_0$。定义意图网络如下：

$$l_{int}^j=F_{int}(\mathbf{u},{\mathbf{i}}_j,1)$$
$\mathbf{u}$是话语嵌入，${\mathbf{i}}_j$是第j个意图嵌入，$l_{int}^j$是logits，通过一个sotfmax归一化生成全部$I$+1个意图上的分布。在inference中，将概率最大的意图视为active 。

Requested Slots

Requested Slots指的是用户在当前话语中询问value的slot。投影函数$F_{req}$为第j个槽位预测Logit $l_{int}^j$。logits用sigmoid归一化到[0,1]内的分数，在inference中，将分数大于0.5的所有槽位预测为Requested Slots。
$$l_{req}^j=F_{req}(\mathbf{u},{\mathbf{s}}_j,1)$$

User Goal

我们将用户目标定义为直到当前用户话语之前，在对话上下文中指定的用户约束。我们不预测每次用户说话后的整个用户目标，而是预测当前轮和上一个用户轮之间的差异。对用户目标的预测分两阶段更新。首先，对于一个槽位，通过在下式中使用sotfamx归一化logits，获取一个槽位状态的三元分布（none, dontcare, active）。
$${\mathbf{I}}_{status}^j=F_{status}(\mathbf{u},{\mathbf{s}}_j,3)$$
槽位状态为none对应槽值保持不变
槽位状态为dontcare对应将dontcare分配给槽值
槽位状态为active对应槽值要被预测，进入第二阶段。

在第二阶段，用下面这个公式获取每个取自可分类slot的value的logit
$${\mathbf{l}}_{value}^j=F_{value}(\mathbf{u},{\mathbf{v}}_j^k,1)$$
同样地用softmaxa归一化成对所有可能槽值的分布，最大的被分配为该slot。
对每个不可分类slot，用下面两个公式获取logits，然后sotfmax归一化成对所有tokens的两个分布，分别对应这一槽值的span的start index和end index。
$${\mathbf{l}}_{start}^j=F_{start}({\mathbf{t}}_k,{\mathbf{s}}_j^n,1)$$$${\mathbf{l}}_{end}^j=F_{end}({\mathbf{t}}_k,{\mathbf{s}}_j^n,1)$$
最大化start[p]+end[q]的两个索引p和q（p≤q）被预测为span边界，而相对应的槽值被分配给这个槽位。

5.2 Evaluation

DST任务的评估指标如下：

1. Active Intent Accuracy: 激活意图被正确预测的比率。
2. Requested Slot F1: 在所有符合条件的回合中Requested Slot的F1宏平均分数。 在ground truth和预测中没有requested slots的回合被跳过。
3. Average Goal Accuracy: 平均目标准确率。对每一轮，预测对话状态中存在的每一个slot的一个value。
4. Joint Goal Accuracy: 联合目标准确率。

表4是结果：
首先自然是性能相比以往大幅度提升。

SGD-S(Single)是仅在单领域对话上训练和验证的模型。SGD-All 是在全部数据集上训练和验证的模型。

然后是我们主要关注SGD数据集的跨领域表现。表格5展现了不同领域的性能，可看出模型的性能在不同领域的还是不一样的。经过分析，我们认为影响跨领域性能的一个因素还是seen服务（即存在于训练集的服务）。对于可见服务，那些在Event领域中的可见服务，对槽值的OOV rate很低，且训练样例个数最大，这应该是有助于提高联合目标准确率(Joint GA)。对于不可见的服务，我们注意到Service领域的联合目标准确率更低，这是由于OOV rate更高，每场对话的平均轮次更高。对于Services领域和Flights领域，性能的差异可能意味着个槽位之间的性能可能会有偏差，导致有些槽位上的性能显著低于其他槽位上的性能。RideSharing领域性能也不好，应该是因为在数据集中它的可能槽值数最多。我们还注意到，对于具有相似槽值的可分类槽位，模型很难区分不同的类别，从而导致性能不佳。

6 Discussion

过去有人批评基于模拟的数据采集方法，认为它无法产生自然的对话或充分的覆盖性。但是本文以结论证明基于模拟的方法要比什么WOz之类的好多了，原因如下：

1. 标注自动生成，错误少。
2. 人工任务简单，只需要自然语言改写，不需要特别多的训练有素的人员
3. 成本低，原因同上
4. 更好的覆盖性：因为数据采集更高效，所以可以充分覆盖usecases

7 Conclusions

我们希望本文的贡献可以帮助多领域大规模虚拟助手在工业界的发展。

Appendix

附录包括图A1，图A2，图A3，图A4，图A5.

• 图A1：本文数据集中Events领域的一个对话实例
• 图A2：本文数据集中Services领域的一个对话实例
• 图A3：本文数据集中覆盖了Movies、Restaurants、RideSharing三个领域的一个对话实例
• 图A4：本文数据集中覆盖了Buses、RentalCars、Media三个领域的一个对话实例
• 图A5：本文的对话改写任务界面（节选），工作人员的任务是对对话大纲重新讲述，以更加自然的形式呈现。不可分类槽值用蓝色字体高亮。
  
  

其他说明

pretrained [BERT-Base, Cased] model checkpoint