以下内容总结自《自然语言处理实践与聊天机器人原理应用与实践》
很多国内外企业和研究单位公开了自己研发的聊天机器人平台，基于这些公开的平台，从业者可以很方便地进行任务驱动的对话系统的搭建。小 i 机器人 、图灵机器人 [7] 、竹间智能科技 [8] 等都是国内智能机器人平台和架构的提供者，它们的平台在功能上各有侧重，对国内部分聊天机器人平台的侧重点进行了汇总。
下表所示为主流国外聊天机器人平台功能汇总。
聊天机器人平台的评测因素一般需要考虑平台的功能、可用性、效果等。本节将利用聊天机器人开放平台——百度的 UNIT 平台，以「询问天气」为例，阐述如何从零开始搭建一个解决特定任务的对话系统，并将搭建过程中的每一步与上一篇播客介绍的对话系统框架中的各个模块及方法相对应。
NLU模块实现
根据上一篇的介绍，NLU 模块要实现对自然语言的处理，首先需要针对任务需求进行意图与槽位的定义。由于本例主要以「询问天气」的需求为例进行介绍，可以先将意图定义为「ASK_WEATHER」，即询问天气。参考上一篇中对槽位定义的描述与示例，槽位的定义可以同前文示例一致，具体的槽位定义如下。
（1）时间：user_time，自定义时间槽位，可复用平台内置的时间字典。
（2）地点：user_loc，自定义地点槽位，可复用平台内置的地点字典。下图给出了 UNIT 平台的槽位定义示例。
完成意图与槽位的定义后，需要做的是意图识别与槽位填充。意图识别与槽位填充本质上都是通过训练样本进行学习的，所以先导入训练样本数据。如果没有现成的训练数据，则需要开发者手动完成样本数据的建设工作。具体的样本数据准备包括样本的输入与标注两部分，如下图所示，对于每一句手工输入的样本，开发者都需要进行意图和槽位的标注，分别对应到意图识别任务和槽位填充任务。样本标注示例如下:
下图所示为若干条训练样本最终形成的样本集情况。
对于简单的任务对话系统，对话样本数量较少也可以维持基本的运作，如上例中的 4 句对话样本就可以支持「询问天气」任务。但对稍微复杂一点的任务来说，由于复杂的任务往往涉及多个意图，有可能产生冲突导致意图分类出错，这种情况下系统意图识别的准确率就依赖于训练样本的数量和质量。不管是正例样本还是负例样本，均需要足够多的数量，以保证意图识别的准确率。有了训练数据之后，平台会调用该训练数据进行模型的训练。
DST与DPL模块实现
开放平台的 DST 与 DPL 模块均采用了基于规则的实现方式，因此可以参考 4.2.3 节设计的有限状态自动机来实现，其中有限状态自动机的系统动作可以定义为「Ask Date」和「Ask Location」，即下图中的「澄清话术」。
同时，「澄清顺序」指有限状态自动机中对应槽位均为空时，优先执行「Ask Date」还是「Ask Location」动作。该例中，与 4.2.3 节有限状态自动机的设计相同，都是优先询问时间，即优先执行「Ask Date」动作。
补充:4.2.3节的有限状态自动机
DPL 模块的输入是 DST 模块输出的当前对话状态 s n ，通过预设的对话策略，选择系统动作 a n 作为输出。下面结合具体案例介绍基于规则的 DPL 方法，也就是通过人工设计有限状态自动机的方法实现 DPL。
案例一:询问天气
以有限状态自动机的方法进行规则的设计，有两种不同的方案：一种以点表示数据，以边表示操作；另一种以点表示操作，以边表示数据，这两种方案各有优点，在具体实现时可以根据实际情况进行选择。
方案一： 以点表示数据（槽位状态），以边表示操作（系统动作)
在这种情况下，有限状态自动机中每一个对话状态 S 表示槽位的填充情况，例如槽位均为空时，状态为 NULL，表示为（0,0）；仅时间（Time）槽位被填充时，状态表示为（0,1）。本示例中槽位共有两个，分别为时间和地点（Location），因此共有 4 种不同的状态。
状态迁移是由系统动作引起的，例如仅时间槽位被填充时，下一步的系统动作为「询问地点」（Ask Location），以获取完整的槽位填充。S0 为起始状态，Z 为终结状态，S1、S2、S3 三个状态的作用是对槽位填充进行确认。如果成功填充，则跳转到下一个状态继续；如果没有成功，则再一次询问进行槽位填充（Ask Again）。这种方式的弊端非常明显：随着槽位数量的增加，对话状态的数量也会急剧增加。具体来说，在上述方案中，对话状态的总数由槽位的个数决定，如果槽位有 k 个，那么对话状态的数量为 2 k 个。尝试改进这一弊端的研究有很多，如 Young S 等人 [12] 提出的隐藏信息状态模型（Hidden Information State,HIS）和 Thomson B 等人 [13] 提出的基于贝叶斯更新的对话状态管理模型（Bayesian Update of Dialogue State,BUDS）等。方案二： 以点表示操作（系统动作），以边表示数据（槽位状态)
有限状态自动机设计如下:
在这种情况下，有限状态自动机中每一个对话状态 S 表示一种系统动作，本例中系统动作共有 3 种，分别是两种问询动作：「询问时间」（Ask Date）和「询问地点」（Ask Location），以及最后的系统回复「回答天气」（Answer）动作。有限状态自动机中状态的迁移则是由槽位的状态变化，即「用户动作」引起的。对比上述两种方案可以发现，第二种有限状态自动机以系统动作为核心，设计方式更简洁，并且易于工程实现，更适合人工设计的方式。第一种有限状态自动机以槽位状态为核心，枚举所有槽位情况的做法过于复杂，更适合数据驱动的机器学习方式。系统动作的定义通常有问询、确认和回答 3 种。问询的目的是了解必要槽位缺失的信息；确认是为了解决容错性问题，填槽之前向用户再次确认；回答则是最终回复，意味着任务和有限状态自动机工作的结束。细心的读者可能已经发现，采取问询的方式获得缺失的槽位信息，在一些情况下是不合适的，以「询问天气」任务为例，向用户问询槽位缺失的信息会大幅降低用户对系统的满意度。在真实的业务环境下，系统往往会直接采取默认值填充槽位的方式，或者结合以往的对话历史数据，自动填补个性化的结果。例如，用户以往问的都是上海的天气，那么「地点」槽位就会被个性化地填充为「上海」。这就引出了对面向任务的对话系统的质量评估方法：对面向任务的对话系统而言，完成用户指定任务所需的对话轮数越少越好。在实际应用中，诸如「询问天气」这样的任务，通常都尽可能地在一次对话中完成，而有些任务则必须要进行多轮对话，例如订餐、购票等任务。接下来，我们以「订餐需求」为例，说明多轮对话的必要性，以及对话轮数的取舍问题。
上面讲到，该例中，与 4.2.3 节有限状态自动机的设计相同，都是优先询问时间，即优先执行「Ask Date」动作。下面为系统动作示例图:
同时，我们还需要对系统动作「Answer」进行触发条件的设置，如下图所示。这里将条件设置为槽位填满，即只有当所有槽位均填满时才执行最终的回复命令。
可以发现，基于开放平台实现对话系统的核心部分 DST 与 DPL 模块，其设计思路与有限状态自动机的一致，只是用了另外一种形式进行配置，本质上仍然是状态的迁移。
NLG模块的实现
系统回复的实现有两种方式，一种是采用固定文本进行回复，如下图所示；
另一种是通过其他函数或者 API 调用返回动态的结果。以「询问天气」为例，最终需要调用天气查询 API 返回天气数据供对话系统回复给用户。接下来，以基于 Amazon Lex 的订餐需求定义的任务对话系统的对话效果为例，向读者展示基于开放平台搭建对话任务系统的实现效果，如图所示。
