切换schema_基于 Schema 的对话状态追踪解决方案一则

作者简介：马跃，平安人寿人工智能研发团队高级算法工程师，本硕毕业于北京邮电大学，主要研究方向为自然语言处理、人机对话系统。

随着人工智能和对话技术的发展，多领域人机对话系统已广泛应用于各类在线服务场景，如订餐、订票、打车、旅游线路查询、新闻查询推荐等。由于用户需求复杂，需要进行多轮陈述，还可能在对话过程中不断修改或完善需求。因此，通过对话状态追踪(Dialog State Tracking)来确定用户目标，是辅助对话策略决策的一个关键步骤。

微软联合卡内基梅隆大学于 2013 年发起了对话系统挑战赛 DSTC ，旨在带动学术与工业界在对话技术上的提升，发展至今已成为领域的知名权威赛事。平安人寿 AI 团队在 第八届对话系统挑战赛(DSTC 8)中 ，斩获了“基于 Schema 的对话状态追踪”、“端到端的问答预测”以及“面向多领域端到端对话系统”三项赛事世界第一，并受邀在 AAAI 2020 workshop 发表论文。其中“基于 Schema 的对话状态追踪”是业界公认的难题，该任务要求解决对话系统的状态追踪问题，难点在于 zero-shot learning 缺乏训练语料，本文也将围绕该竞赛方案进行详细解读。主要分为以下五个部分：

1. 任务背景
2. 任务分析
3. 解决方案
4. 性能指标
5. 总结

一 、背景介绍

我们在去年七月参与了本次比赛，整整持续了两个多月的时间，通过不断的迭代，形成了一个完整的对话状态追踪系统。系统中主要是基于阅读理解和Wide&Deep两个方法来实现对话状态追踪。本文也是以这两个方法为核心来展开。

随着人工智能和对话技术的发展，日常生活也出现了很多相关的应用。比如大家非常熟悉的siri、小爱同学，以及一些底层工具的对话服务提供商，如unit、luis等等，前者属于平台化工具，后者则是服务框架提供商，不过目的都是一样的，即帮助实现多领域的人机对话系统。

什么是多领域？上图给出了一些示例，比如机票搜索和预订，有打车、旅游等等这些不同的领域技能，它们组合起来，可以提供对话服务，这就是多领域对话。

其中每一个领域中又可以有多个不同的服务，由不同的厂家提供，比如说出行可能有Uber、有滴滴，机票有去哪、有携程。一个人机交互平台是不可能局限于已有服务的，因为每个厂家都会在不确定的时间在上面提交一些自己的服务，这个时候，作为对话平台，它需要有能力在不同的服务之间，甚至是从来没有过的领域和服务之间进行流畅且智能地切换。

在学术上，这种所谓没有见过的领域有一个统称，即Zero-shot domain。DSTC 8基于Schema的对话状态追踪任务，就是在这个背景下提出来的。

上图中的数据集里的对话样例，是一个14轮的对话。对话中，一个用户想去纽约旅游，不断跟系统交互，咨询了当地的旅游景点，完成了附近的酒店预订，包括来回机票的查询。

其中一共涉及三个服务，我已用方框把它们各自框起来了。此时，系统的目标就是要流畅的跟用户交互，并且顺利完成这三个任务，这就需要每一个时刻都能准确知道用户当前所表达的意义、所处的状态。在DSTC 8这个任务中，每一个服务都是通过scheme来定义的。

比如上图中的例子，针对旅游景点这个服务，正如前文所提，同一个领域下可能有不止一个厂家提供服务。在这个比赛中也是一样的，它通过领域加下划线加数字来进行区分。

以旅游领域的第一个服务为例子。首先，它会有一句话来对服务进行描述，其次，还有可能的意图，每一个意图也有一句自然语言来表达意图的具体意义、进行解释，同时会指定这个意图下有一些必须填充的槽位和可选的槽位。

必须填充的槽位，就是要完成这个意图所必备的元素，也是整个任务要跟踪的一个对象。下面一个部分是槽位的具体内容，可以看到，除了槽位名之外，也有一个自然语言的描述，来表明这个槽位所表达的意义。

槽位分为两种，一种是可枚举的，一种是不可枚举的槽位，是通过布尔值来区分。比如location，它是一个不可枚举的槽位，那就意味着它的槽值是不受约束的，其取值可以是任意字符串，当然这个字符串也必须来自于对话的上下文。

而free_entry是一个可枚举槽位，那它的取值就只能在任务里面给定的取值范围内进行选择。这里是两个值，是True和False，它分别表示这个景点是不是免费的。

还有一些其他槽位，有两个代表性比较强的，第一个是人数的槽位，它的取值只可能是数字，在整个任务中通过分析发现，数字型的可枚举槽，它的取值范围都是在1~9之间的，这些都是对后期的模型设计比较有启发的一些点。

再比如说下面的类别槽位，它的取值就是从它给出的一个文本list，选择当中的某一个。通过这样一个Schema，我们就完成了对一个服务的定义。在这个规范下面要完成这个旅游景点的交互，那就可能会涉及到地点、人数、景点、种类这些槽位，而目的就是去实时捕获这些槽位的填充信息。

再回到刚才给的这个例子就能做进一步解析了。

比如上图标红的内容就是在旅游服务里的关键信息，一位用户最开始就抛出一个景点类别，系统需要知道用户当前表达内容之后才能做出一个合理的规划，给出合理的回复，这里的Turn 1 user state，其实就是要输出的结构化内容，这里我们会抽取到用户表达里面的历史景点这样一个片段，作为种类这个槽位的取值。

在第二轮的时候，系统就会根据历史地标会反问用户现在要去哪一个目的地，到第三轮的时候，用户说了纽约，系统需要准确综合上下文信息，输出一个更加完整的状态，这里就可以得知，用户的目的地是纽约，他的目标景点类型是历史地标，进而在纽约范围内的景点进行检索，来得到符合用户需求的目的地作为推荐。

下面两个结构体，是在每一个用户轮次要生成的结构化信息。单看这个例子，好像整个对话追踪难度没有非常高。

在这个对话后部分的宾馆和预订机票两个服务中，用户使用了一些指代的表达，来间接表明他的目的地