任务型对话系统架构

在这里插入图片描述
比如，这是一个任务型订票系统的对话例子。

如果要我们实现一个这样的对话系统，其中有三个最大的难点：理解用户输入、记住对话历史信息、知道要问什么。

首先是要能理解用户的输入，知道用户想什么；其次需要维护一个历史状态。因为用户一般不会在一句话中说清楚自己的所有需求，因此需要记住用户所说的关键信息，知道哪些信息提供了，哪些没有提供；最后通过提问题得到未提供信息的答案。

这三个难点可归纳为理解用户、追踪状态和生成下个动作。

任务型对话系统的目标是帮助用户实现他们想做的事情，有一个评测指标是在完成任务的前提下，对话的轮数越少越好。

下面我们来了解一下任务型对话系统中关键的术语。

常用术语

模式(schema)：预定义好的结构化表示，涵盖了任务导向对话所能处理的关键信息。
以订票系统为例，我们需要知道出发地、到达地、出发时间、乘客姓名等。在Python中，可以以字典的形式存储。Key就是这些信息，Value维护了所有可能的Key的取值(或者一个取值规则)。
意图(intent)：用户想要进行的操作。
所谓理解用户输入，就是识别用户的意图。
槽(slot)：其实就是模型中Key的概念。
比如订机票中，出发地和到达地就是两个Slot。得到每个Slot对应的值就可以完成对话任务。该过程也称为填槽。
领域(domain)：预先设计好的意图和槽的集合。
比如订机票和订酒店就可以通过两个领域来维护。

下面是一些领域的例子：

在这里插入图片描述

特点

任务型对话系统的特点/难点：

领域强相关的
- 缺乏训练数据
最终目标：帮助用户做些事情。模型必须理解用户想要什么。
尽量简介高效

在这里插入图片描述
我们再来回顾下任务型对话系统的概述。本文将详细介绍其中的三大模块：自然语言理解、对话管理、对话生成。
这三个模型分别用于解决上面探讨的三个难点：理解用户输入、追踪状态和生成下个动作。

自然语言理解(NLU)模块接收用户(非结构化字符串)的输入，输出结构化的语义帧表示。比如领域、意图和(语义)槽。
对话管理(DM)模块通过状态追踪(DST)来记录关键信息，它的输入是NLU模块的输出，它的输出是对话的策略(是问问题呢，还是做点什么)。其内部会维护一个对话状态。
自然语言生成(NLG)模块根据DM模块输出的对话动作，生成用户能理解的自然语言。但大多数通过基于规则的模板实现。

自然语言理解模块

自然语言理解模块是用户输入进入系统后接触的第一个模块。可分为三个子模块：领域识别、意图识别、语义槽填充。

比如 Show me morning flights from Boston to San Francisco on Tuesday 这句话进入自然语言理解模块后可以得到：

领域识别
- 领域：订机票
意图识别
- 意图：查询航班
语义槽填充
- 出发地: Boston
- 出发日期: Tuesday
- 出发时间: morning
- 到达地: San Francisco

下面看更多的例子，包含三个领域。
在这里插入图片描述

从上图可以看到，这三个子模块也是通过Pipeline的方式运作的，即首先进行领域识别，然后是意图识别，最后才做语义槽填充。

我们知道，领域识别和意图识别本质上都是分类任务，语义槽填充属于序列标注任务。

现在一般使用深度学习来做自然语言理解。

深度学习在意图/领域识别中的发展过程：
在这里插入图片描述
随着自注意的出现，后来常用基于预训练模型的文本分类器。

而在语义槽填充中：
在这里插入图片描述
在BERT出来之前，最火的选择就是LSTM+CRF来实现序列标注。

对话管理模块

我们上面知道对话管理模型结构化的语义帧，输出对话动作。其维护了两个子模块——状态追踪(DST)和策略优化(DPO)。

我们先来看一下对话状态追踪。首先要知道什么是对话状态。

对话状态追踪

**对话状态(Dialogue State)**是对话到当前位置为止，用户所提供的哪些关键信息。
具体实现可以理解为Python中的字典。Key是Slot，Value是用户目前位置提供的值。

来看一个例子，从中可以看到对话状态的更新：
在这里插入图片描述
对话状态追踪即对话状态估计。
在上面的例子中，对话状态挺明确的，为什么说是对话状态估计？

因为虽然我们这里的例子很简单，但实际上真实系统上，我们很难找到这么清晰的例子。用户总能想到我们无法处理的意图，或者说用户总有一些我们意想不到的举措。为了满足这些举措，我们需要设计很多的对话动作，很多的槽，并且每个槽有很多不同的取值。最终导致我们对话状态空间非常庞大。
在这里插入图片描述
在用户表述不清楚的情况下，我们很难更新对话状态。所以我们需要进行对话状态估计。
那么我们过去一般是如何解决这个问题呢。

在这里插入图片描述
通过马尔科夫决策过程(Markov Decision Process)。提出者认为对话管理模块在和用户交互的过程中，遵循了上面的流程。
具体为：用户说了一句话 $a_u$ ，为用户的真实动作。通过语音转文字，得到 $\tilde{a}_u$ ，为系统观察到的用户行为。这里就可能和用户的真实意图有偏差。模型根据这个观察到的行为，需要产生对于当前对话状态的估计 $\tilde{s}_m$ ，然后通过对话策略模块生成下一步动作 $a_m$ 。接着，通过文字转语音得到系统输出的动作 $\tilde{a}_m$ 。用户根据系统输出，认为自己已经提供了哪些关键信息 $s_u$ ，和DM中维护的对话系统认为用户已经提供的关键信息 $\tilde{s}_m$ 很有可能不同。

而现在在学术界和比赛中把它当成文本生成任务。
在这里插入图片描述
将当前对话历史得到的对话状态打包成字符串，然后通过自回归的语言模型学习。
对于新的对话历史怎么得到状态呢，也是将其打包成字符串，喂给语言模型，然后让语言模型以字符串的方式输出键值对。

https://arxiv.org/abs/2012.03539
https://github.com/salesforce/simpletod
但在商业化应用中只是通过基于对话流的方式，会遍历所有可能的对话状态。

对话策略

在这里插入图片描述

对话策略就是根据当前的对话状态决定对话系统下一步的动作。

具体做法为，将对话策略看成函数 $\pi$ 。
在这里插入图片描述
它接收的输入为当前的对话状态 $s$ ，输出为对话动作 $a$ 。通过多轮的对话交互，就可以得到一系列动作序列 $A$ 。

对话策略过去是通过有限状态机的方式实现的。

在这里插入图片描述
即系统会遍历所有可能的状态，在不同的状态下有不同的决策。在不同的决策中使用规则的方式决定下一步动作。
以订票为例。首先会问出发地，然后问目的地、出发时间。中间会问要不要订返程票，根据答案的不同流程会不同。

而更有趣的做法是把它看成强化学习过程：
在这里插入图片描述

但实际应用中，我们仍然采用的是基于有限状态机的方式。

甚至我们也可以为开放领域的聊天机器人设定一些对话管理过程：
在这里插入图片描述

对话生成模块

自然语言生成模块主要用于根据对话动作生成文本回复。
最简单的方式就是通过模板来实现。

在这里插入图片描述
即为每个对话动作配置一些问题模板。

后来，大家发现可以把生成模板的过程写得更花俏一点。
在这里插入图片描述
主要是对生成模板的过程进行细分，比如上图终端Text Planner、Sentence Planner和Realizer。

随着深度学习的发展，有人也尝试通过语言模型来生成。
在这里插入图片描述

但是在工业界，还是通过基于模板的方式。因为它简单、可控。

任务型对话系统的评价方法

整体评价

分为两个方面：

客观指标
- 对话成功率
  - 通常在对话结束后得到(任务是否被解决)
- 平均对话轮次数
  - 任务型对话追求简短的轮次完成对话任务(完成任务所需)
主观指标
- 用户满意度
  - 多类别分值问题
  - 通常需要人工标注
- 场景及用户体验相关的评价指标

自然语言理解的评价

对于自然语言理解模块，它分为三个子模块：领域识别、意图识别和槽值填充。
前两个是分类任务，最后一个是序列标注任务。
对于领域识别，我们认为是一个多分类任务，所以用准确率来评价；
对于意图识别，也是一个多分类任务，也可以用准确率来评价。
对于槽值填充，作为序列标注任务进行评价，使用F1分数：加权平均所有不同的槽值类型上的F1分数。