结合NLU在面向任务的对话系统中的具体应用进行介绍-电子发烧友网

以下是节选内容

按照技术实现，我们可将任务驱动的对话系统划分为如下两类：

模块化的对话系统

分模块串行处理对话任务，每一个模块负责特定的任务，并将结果传递给下一个模块，通常由NLU（Natural Language Understanding，自然语言理解）、DST（Dialogue State Tracking，对话状态追踪）、DPL（Dialogue Policy Learning，对话策略学习）、NLG（Natural Language Generation，自然语言生成）4个部分构成。在具体的实现上，可以针对任一模块采用基于规则的人工设计方式，或者基于数据驱动的模型方式。

端到端的对话系统

考虑采用由输入直接到输出的端到端对话系统，忽略中间过程，采用数据驱动的模型实现。

目前，主流的任务对话系统实现为模块化方式，由于现有训练数据规模的限制，端到端的方式仍处于探索阶段。本文主要介绍模块化的面向任务的对话系统，图1介绍了其主要模块。

（1）NLU：将用户输入的自然语言语句映射为机器可读的结构化语义表述，这种结构化语义一般由两部分构成，分别是用户意图（user intention）和槽值（slot-value）。

图1面向任务的对话系统的主要模块

（2）DST：这一模块的目标是追踪用户需求并判断当前的对话状态。该模块以多轮对话历史、当前的用户动作为输入，通过总结和推理理解在上下文的环境下用户当前输入自然语言的具体含义。对于对话系统来说，这一模块有着重大意义，很多时候需要综合考虑用户的多轮输入才能让对话系统理解用户的真正需求。

（3）DPL：也被称为对话策略优化（optimization），根据当前的对话状态，对话策略决定下一步执行什么系统动作。系统行动与用户意图类似，也由意图和槽位构成。

（4）NLG：负责把对话策略模块选择的系统动作转化为自然语言，最终反馈给用户。

在与用户直接关联的两个模块中，ASR指的是自动语音识别，TTS指的是语音合成。如第2章介绍的，ASR和TTS并不是系统必备的模块，也不是本书介绍的重点，因此在面向任务的对话系统中不对这两部分技术做详细介绍。

1.NLU模块

本文主要结合NLU在面向任务的对话系统中的具体应用进行介绍。

对面向任务的对话系统来说，NLU模块的主要任务是将用户输入的自然语言映射为用户的意图和相应的槽位值。因此，在面向任务的对话系统中，NLU模块的输入是用户对话语句，输出是解析后得到的用户动作。该模块涉及的主要技术是意图识别和槽位填充，这两种技术分别对应用户动作的两项结构化参数，即意图和槽位。

下面主要讨论如何针对面向任务的对话系统设计NLU模块，包括针对特定任务定义意图和相应的槽位，以及后续从用户的输入中获取任务目标的意图识别方法和对应的槽位填充方法。

（1）意图和槽位的定义

意图和槽位共同构成了“用户动作”，机器是无法直接理解自然语言的，因此用户动作的作用便是将自然语言映射为机器能够理解的结构化语义表示。

意图识别，也被称为SUC（Spoken Utterance Classification），顾名思义，是将用户输入的自然语言会话进行划分，类别（classification）对应的就是用户意图。例如“今天天气如何”，其意图为“询问天气”。自然地，可以将意图识别看作一个典型的分类问题。意图的分类和定义可参考ISO-24617-2标准，其中共有56种详细的定义。面向任务的对话系统中的意图识别通常可以视为文本分类任务。同时，意图的定义与对话系统自身的定位和所具有的知识库有很大关系，即意图的定义具有非常强的领域相关性。

槽位，即意图所带的参数。一个意图可能对应若干个槽位，例如询问公交车路线时，需要给出出发地、目的地、时间等必要参数。以上参数即“询问公交车路线”这一意图对应的槽位。语义槽位填充任务的主要目标是在已知特定领域或特定意图的语义框架（semantic frame）的前提下，从输入语句中抽取该语义框架中预先定义好的语义槽的值。语义槽位填充任务可以转化为序列标注任务，即运用经典的IOB标记法，标记某一个词是某一语义槽的开始（begin）、延续（inside），或是非语义槽（outside）。

要使一个面向任务的对话系统能正常工作，首先要设计意图和槽位。意图和槽位能够让系统知道该执行哪项特定任务，并且给出执行该任务时需要的参数类型。为了方便与问答系统做异同对比，我们依然以一个具体的“询问天气”的需求为例，介绍面向任务的对话系统中对意图和槽位的设计。

用户输入示例：“今天上海天气怎么样”

用户意图定义：询问天气，Ask_Weather

槽位定义

槽位一：时间，Date

槽位二：地点，Location

“询问天气”的需求对应的意图和槽位如图2所示。

图2意图与槽位定义（1）

在上述示例中，针对“询问天气”任务定义了两个必要的槽位，它们分别是“时间”和“地点”。

对于一个单一的任务，上述定义便可解决任务需求。但在真实的业务环境下，一个面向任务的对话系统往往需要能够同时处理若干个任务，例如气象台除了能够回答“询问天气”的问题，也应该能够回答“询问温度”的问题。

对于同一系统处理多种任务的复杂情况，一种优化的策略是定义更上层的领域，如将“询问天气”意图和“询问温度”意图均归属于“天气”领域。在这种情况下，可以简单地将领域理解为意图的集合。定义领域并先进行领域识别的优点是可以约束领域知识范围，减少后续意图识别和槽位填充的搜索空间。此外，对于每一个领域进行更深入的理解，利用好任务及领域相关的特定知识和特征，往往能够显著地提升NLU模块的效果。据此，对图2的示例进行改进，加入“天气”领域。

用户输入示例

1.“今天上海天气怎么样”

2.“上海现在气温多少度”

领域定义：天气，Weather

用户意图定义

1. 询问天气，Ask_Weather

2. 询问温度，Ask_Temperature

槽位定义

槽位一：时间，Date

槽位二：地点，Location

改进后的“询问天气”的需求对应的意图和槽位如图3所示。

图3意图与槽位定义（2）

（2）意图识别和槽位填充

做好意图和槽位的定义后，需要从用户输入中提取用户意图和相应槽对应的槽值。意图识别的目标是从用户输入的语句中提取用户意图，单一任务可以简单地建模为一个二分类问题，如“询问天气”意图，在意图识别时可以被建模为“是询问天气”或者“不是询问天气”二分类问题。当涉及需要对话系统处理多种任务时，系统需要能够判别各个意图，在这种情况下，二分类问题就转化成了多分类问题。

槽位填充的任务是从自然语言中提取信息并填充到事先定义好的槽位中，例如在图2中已经定义好了意图和相应的槽位，对于用户输入“今天上海天气怎么样”系统应当能够提取出“今天”和“上海”并分别将其填充到“时间”和“地点”槽位。基于特征提取的传统机器学习模型已经在槽位填充任务上得到了广泛应用。近年来，随着深度学习技术在自然语言处理领域的发展，基于深度学习的方法也逐渐被应用于槽位填充任务。相比于传统的机器学习方法，深度学习模型能够自动学习输入数据的隐含特征。例如，将可以利用更多上下文特征的最大熵马尔可夫模型引入槽位填充的过程中[8]，类似地，也有研究将条件随机场模型引入槽位填充。

基于RNN的深度学习模型在意图识别和槽位填充领域也得到了大量的应用，Attention-Based Recurrent Neural Network Models for Joint Intent Detection and Slot Filling中介绍了使用Attention-Based RNN模型进行意图识别和槽位填充的方法，作者提出将“alignment information”加入Encoder-Decoder模型，以及将“alignment information”和“attention”加入RNN这两种解决槽位填充和意图识别问题的模型。需要特别介绍的是，与基于RNN的意图识别和槽位填充相比，基于LSTM模型的槽位填充可以有效解决RNN模型中存在的梯度消失问题。

另外，在实际工程中往往需要先对句子中的各个组成部分进行标注，所以通常也会应用到序列标注方法。

进行意图识别和槽位填充的传统方法是使用串行执行的方式，即先进行意图识别，再根据意图识别的结果进行槽位填充任务。这种方式的主要缺陷是：

可能产生错误传递，导致错误放大。

限定领域也就意味着不同领域需要不同的方法和模型进行处理，各个领域之间的模型没有共享，但在很多情况下，例如订火车票和飞机票时，时间、地点等槽位都是一致的。

因为串行执行的方式存在上述问题，所以研究人员改为使用Multi-Domain Joint Semantic Frame Parsing Using Bi-Directional RNN-LSTM, INTERSPEECH中设计的联合学习（joint learning）方式进行意图识别和槽位填充。

另外，还有一种情况需要特别注意。在一次天气询问任务完成后，用户又问“那明天呢”时，实际上可以认为第二个问句是开始了另一次“询问天气”任务，只是其中的“时间”槽位是指定的，而“地点”槽位则需要重复利用（继承）上一次任务中的值。

对意图识别模块和槽位填充模块的主要评价指标包括：

意图识别的准确率，即分类的准确率。

槽位填充的F1-score。

2.DST模块

DST模块以当前的用户动作、n-1前轮的对话状态和相应的系统动作作为输入，输出是DST模块判定得到的当前对话状态。

对话状态的表示（DST-State Representation）通常由以下3部分构成。

（1）目前为止的槽位填充情况。

（2）本轮对话过程中的用户动作。

（3）对话历史。

其中，槽位的填充情况通常是最重要的状态表示指标。

我们知道，由于语音识别不准确或是自然语言本身存在歧义性等原因，NLU模块的识别结果往往与真实情况存在一定的误差。所以，NLU模块的输出往往是带概率的，即每一个可能的结果有一个相应的置信程度。由此，DST在判断当前的对话状态时就有了两种选择，这两种选择分别对应了两种不同的处理方式，一种是1-Best方式，另一种则是N-Best方式[11]。

1-Best方式指DST判断当前对话状态时只考虑置信程度最高的情况，因此维护对话状态的表示时，只需要等同于槽位数量的空间，如图4所示。

图4 1-Best方式下的对话状态与槽位的对应

N-Best方式指DST判断当前对话状态时会综合考虑所有槽位的所有置信程度，因此每一个槽位的N-Best结果都需要考虑和维护，并且最终还需要维护一个槽位组合在一起（overall）的整体置信程度，将其作为最终的对话状态判断依据，如图5所示。

图5N-Best方式下的对话状态与槽位的对应

实现DST模块的方法主要有：基于条件随机场模型的序列跟踪模型、基于RNN和LSTM的序列跟踪模型等。

3.DPL模块

DPL模块的输入是DST模块输出的当前对话状态，通过预设的对话策略，选择系统动作作为输出。下面结合具体案例介绍基于规则的DPL方法，也就是通过人工设计有限状态自动机的方法实现DPL。

案例一：询问天气

以有限状态自动机的方法进行规则的设计，有两种不同的方案：一种以点表示数据，以边表示操作；另一种以点表示操作，以边表示数据，这两种方案各有优点，在具体实现时可以根据实际情况进行选择。

方案一：以点表示数据（槽位状态），以边表示操作（系统动作）（如图6所示）

在这种情况下，有限状态自动机中每一个对话状态S表示槽位的填充情况，例如槽位均为空时，状态为NULL，表示为(0,0)；仅时间（Time）槽位被填充时，状态表示为(0,1)。本示例中槽位共有两个，分别为时间和地点（Location），因此共有4种不同的状态。

图6“询问天气”有限状态自动机设计（1）

状态迁移是由系统动作引起的，例如仅时间槽位被填充时，下一步的系统动作为“询问地点”（AskLocation），以获取完整的槽位填充。S0为起始状态，Z为终结状态，S1、S2、S3三个状态的作用是对槽位填充进行确认。如果成功填充，则跳转到下一个状态继续；如果没有成功，则再一次询问进行槽位填充（Ask Again）。

这种方式的弊端非常明显：随着槽位数量的增加，对话状态的数量也会急剧增加。具体来说，在上述方案中，对话状态的总数由槽位的个数决定，如果槽位有k个，那么对话状态的数量为2k个。尝试改进这一弊端的研究有很多，如Young S等人提出的隐藏信息状态模型（Hidden Information State，HIS）和Thomson B等人提出的基于贝叶斯更新的对话状态管理模型（Bayesian Update of Dialogue State，BUDS）等。

方案二：以点表示操作（系统动作），以边表示数据（槽位状态）（如图7所示）

图7“询问天气”有限状态自动机设计（2）

在这种情况下，有限状态自动机中每一个对话状态S表示一种系统动作，本例中系统动作共有3种，分别是两种问询动作：“询问时间”（Ask Date）和“询问地点”（Ask Location），以及最后的系统回复“回答天气”（Answer）动作。有限状态自动机中状态的迁移则是由槽位的状态变化，即“用户动作”引起的。

对比上述两种方案可以发现，第二种有限状态自动机以系统动作为核心，设计方式更简洁，并且易于工程实现，更适合人工设计的方式。第一种有限状态自动机以槽位状态为核心，枚举所有槽位情况的做法过于复杂，更适合数据驱动的机器学习方式。

系统动作的定义通常有问询、确认和回答3种。问询的目的是了解必要槽位缺失的信息；确认是为了解决容错性问题，填槽之前向用户再次确认；回答则是最终回复，意味着任务和有限状态自动机工作的结束。

细心的读者可能已经发现，采取问询的方式获得缺失的槽位信息，在一些情况下是不合适的，以“询问天气”任务为例，向用户问询槽位缺失的信息会大幅降低用户对系统的满意度。在真实的业务环境下，系统往往会直接采取默认值填充槽位的方式，或者结合以往的对话历史数据，自动填补个性化的结果。例如，用户以往问的都是上海的天气，那么“地点”槽位就会被个性化地填充为“上海”。

这就引出了对面向任务的对话系统的质量评估方法：对面向任务的对话系统而言，完成用户指定任务所需的对话轮数越少越好。在实际应用中，诸如“询问天气”这样的任务，通常都尽可能地在一次对话中完成，而有些任务则必须要进行多轮对话，例如订餐、购票等任务。

接下来，我们以“订餐需求”为例，说明多轮对话的必要性，以及对话轮数的取舍问题。

案例二：订餐

在典型的订餐领域的对话系统中，根据生活经验，我们知道需要为系统定义以下几个槽位。

（1）slot1：用户住址（Address）。

（2）slot2：用户手机号码（Phone）。

（3）slot3：订餐餐厅名称（Res_name）。

（4）slot4：食物名称（Food_item）。

（5）slot5：食物类型（Food_type）。

（6）slot6：价格范围（Price_range）。

其中前4项为必要槽位，对订餐任务来说是必须提供的参数，最后两项为非必要槽位，可有可无，有的话可以提高订餐任务的精准度。参考案例一的处理过程，首先对此任务设计相应的有限状态自动机，如图8所示。

图8“订餐”系统有限状态自动机设计

可以发现，在该任务下的有限状态自动机设计中，我们只加入了必要槽位的问询操作，没有对Food_type和Price_range进行强制的系统问询。两个非必要槽位能够对“Ask Food_item”，即询问具体的食物名称起到辅助作用。当用户没有明确需求时，系统可以给出具体的食物推荐，这样的设定可以有效地减少非必要的对话，减少对话轮数。

4.NLG模块

NLG模块的输入是DPL模块输出的系统动作，输出是系统对用户输入的回复。