此篇基于 PyDial：A Multi-domain Statistical Dialogue System Toolkit 论文笔记和 A Benchmarking Environment for Reinforcement Learning Based Task Oriented Dialogue Management 论文笔记。 PyDial 的官方文档在此处。

语音对话系统架构

PyDial 的论文中已经描述了系统的架构，本文最上面的 alert 中也已经给出了两篇论文笔记。我在这里做个总结。

PyDial 的总体架构如下图所示。其中主要组件被称为 Agent，它封装了所有对话系统模块，以实现基于文本的交互。对话系统模块依赖于由一个本体（Ontology）定义的领域规范。为了与环境交互，PyDial 提供了三个接口：Dialogue Server【允许语音型交互】、Texthub【允许输入型交互】和 User Simulation system。交互的性能由评估（Evaluation）组件监视。

下图总计四大部分，将在下面的小节中分别阐述。

Agent

主要关注 Agent 部分。Agent 负责对话交互，因此内部的架构类似于下图中的内容。Agent 还维护 dialogue sessions。因此，可以通过实例化多个 agents 来支持多个对话。

Semantic Parser/Semantic Decoder：将文本输入转化为一个语义表征。PyDial 提供了一个基于规则（使用正则表达式）的实现，以及一个基于 SVM 的统计模型，即 the Semantic Tuple Classifier。对于后者，只提供了 CamRestaurants 领域的模型
Belief Tracker：负责维护一个被称为 belief state 的对话状态表征，可用 the rule-based focus tracker 实现。该实现与领域无关。所有特定领域的信息都是从本体中提取的
Policy：将 belief state 映射到适合的 system dialogue act。有两种实现方式：1）人工制定的策略（应该适用于所有领域）；2）Gaussian process (GP) reinforcement learning policy。对于多领域对话来说，策略管理器可以像处理所有其他模块一样处理策略。给定每个用户的输入的领域，然后选择相应的领域策略；3）此外，还可以选择 Gasic et al.(2015b) 提出的 Bayesian committee machine(BCM) 处理程序；4）博主注：目前（2020.1）已经不止这三种方法，还有十数种强化学习策略可供选择。
Semantic Output/Language Generator：将 system dialogue act 转化为文本表示。PyDial 提供了两个实现组件：1）对于所有领域来说，提供了一个基于模板（定义规则）的语言生成；2）此外 Wen et al. (2015) 提出了基于 LSTM 的语言生成器，里面包含了 CamRestaurants 领域的预训练模型
Topic Tracker：对于多域功能，需要 topic tracker。如果 Topic Tracker 已为某些用户输入标识了领域，那么它将继续使用该领域，直到识别了新的领域。因此，并非每个用户输入都必须包含相关关键字。如果 Topic Tracker 无法在开始时识别领域，那么它将创建与用户的 meta-dialogue，直到确定初始领域或达到最大重试次数。

与环境交互

为了与环境交互，PyDial 提供了三个接口：Dialogue Server【允许语音型交互】、Texthub【允许输入型交互】和 User Simulation system。

Texthub：只需将 Agent 连接到终端
Dialogue Server：要启用基于语音的对话，Dialogue Server 允许连接到外部语音客户端。此客户端负责使用 ASR 将输入语音信号映射到文本，并使用语音合成将输出文本映射到语音。注意，语音客户端不是 PyDial 的一部分。PyDial 目前连接到 DialPort（Zhao等人，2016）。
User Simulation：支持在语义层面进行对话模拟。使用的是 agenda-based 用户模拟器（Schatzmann et al., 2006）。

Evaluation

用于计算对话的评估度量（例如 Task Success）。对于基于强化学习的对话模块来说，评估组件还负责提供 reward。

Ontology

Ontology 封装了对话域规范以及对后端数据库（例如，一组餐厅及它们的属性）的访问。它被建模为一个全局对象，大多数对话系统模块和用户模拟器使用它来获取用户的相关信息。

PyDial
├─belieftracking
├─cedm
├─config
├─curiosity
├─Docs
├─evaluation
├─ontology
├─policy
├─resources
├─scripts
├─semanticbelieftracking
├─semi
├─semo
├─tasks
├─tests
├─topictracking
├─Tutorials
├─usersimulator
├─utils
├─__init__.py
├─Agent.py
├─conf.py
├─DialogueServer.py
├─pydial.py
├─Simulate.py
└─Texthub.py

semanticbelieftracking

如果你仔细看过 PyDial 就会发现里面还有一个 semanticbelieftracking 包，两个包有点关联，所以此处将两个包放在一起讲解。

由于 semanticbelieftracking 包相对于 belieftracking 包只是多了一个 semantic，所以我一度认为 semanticbelieftracking 继承自 belieftracking，但是后来发现并不是。semanticbelieftracking 包将 semantic decode 和 belief track 视为两个独立问题。即 SemanticBeliefTracking 由 semantic decode 和 belief track 两部分组成。

它们的关系大致如上述所示，但是有一点不太好。PyDial 类与类之间的关系太乱了，明明有一个类可以继承另一个类，非要将这个类重写一遍，导致我在阅读代码时产生了极大的困扰。另外还有一点就是类的命名问题，我真的看不懂。我不知道为啥要叫 semanticbelieftracking。。。所以两个包的关系大致如下所示：

cedm

cedm 的全称是 The Conversational Entity Dialogue Model，是一个新颖的对话模型，旨在解决传统的单个/多个领域对话模型在对复杂对话结构（如关系，relations）建模能力上的限制。详见 Ultes et al., 2019.1。

请注意，已被设计出来的 CEDM 原型实现，在某种程度上，是在尽可能地利用 PyDial 的结构和实现。因此，在实现上有一些限制，将在未来的版本中解决。CEDM 默认是关闭的，使用方法详见文档。

config

我并没有介绍全，其他的配置文件待补充。

一堆配置文件。PyDial 的文档并没有明确地在某个文档中指出 config 文件夹的用法，只介绍了某一个模块的配置文件该如何配置。但是这样写得太杂了，不易理解，接下来写下自己的理解。

Tut 代表 Tutorials，bcm 代表 Bayesian committee machine，gp 代表 Gaussian Process，hdc 代表 Handcrafted。在官方的教程中经常会看到类似 Tut-gp-CamRestaurants.cfg 的配置文件，这些其实是用于教程的配置文件。

PyDial 的基准环境在 config/pydial_benchmarks 下，由此篇论文引进。其中一共有 6 个环境，每个环境下又有三个领域。环境：不同的环境拥有不同的训练参数，领域：不同的领域拥有不同场景，如剑桥餐厅、笔记本电脑和洛杉矶餐厅。

evaluation

用于评估对话的性能。

policy

policy 是 Agent 中的一部分。policy 包中包含许多 policy 实现，它们都是历年论文的实现。我估计论文 《A Benchmarking Environment for Reinforcement Learning Based Task Oriented Dialogue Management》 使用这些 policy 实现从而提供了 6 个基准测试环境。policy 包中的各个类的关系大致如下所示：

其中 GPPolicy 的关系如下所示：

semi

semi 全名 Semantic input parser。所有的领域都有一个基于规则的 semantic decoder，但是 CamRestaurants 领域有一个基于统计的 decoder，在该包下可以发现一个 SVMSemi.py 文件，所以实际上是基于 SVM 的。semi 的各类关系大致如下所示：

semo

semo 全名 Semantic Output。为大多数领域提供了基于模版的语言生成，但是为 CamRestaurants 提供了一个基于 LSTM 的生成器。semo 的各类关系大致如下所示：

topictracking

用于在多领域下追踪主题。各类关系大致如下所示：

usersimulator

对话模拟。

总结

经过分析发现，所有的模块最终都是由一个 *Manager 的类来管理的。并且在第一节中，我就介绍了 Agent 由 5 个部分组成，即 Semantic Parser/Semantic Decoder(SemI), Belief Tracker, Policy, Semantic Output/Language Generator(SemO), Topic Tracker。在 belieftracking 一节中已经介绍过，SemI 与 belieftracking 已经合并称为 semanticbelieftracking。所以 Agent 实际上只需管理四个 Manager 即可。

正巧，在 pydial 工具包根目录中发现了 Agent.py 模块，那么可想而知该模块就是 Agent 的管理。它管理的 Manager 如下所示：

TopicTrackingManager
SemanticBeliefTrackingManager
PolicyManager
SemOManager
EvaluationManager

由于需要评估对话，所以多了一个 EvaluationManager。总得来说，agent 中各类的关系如下所示：

以上已经是 PyDial 所有的功能，观察上图可以发现，所有功能最终的管理者有三类：ConsoleHub、DialogueServer、SimulationSystem。其中 DialogueServer 用于语音输入，SimulationSystem 用于模拟对话，我们暂且不管。

那么最后就只剩下了 ConsoleHub，它用于处理文本型输入。而 ConsoleHub 由 pydial.py 管理，至此 PyDial 的所有模块几乎都已经理清了，还有个别几个模块我没有整理过，但是它们大部分都只有几个类，并且目前暂时用不上，所以先不整理了。

博客

分析PyDial toolkit各个包的功能