架构模式#

本节介绍的架构模式提出了一种解决方案，用于构建与用户交互的交互式系统。解决的主要架构挑战是如何集成“决策”组件，即决定系统应如何响应与用户交互相关的各种事件的高级逻辑。这个决策组件对于系统的“智能”程度至关重要。

注意

架构模式是解决重复出现的架构问题的一种方法。例如，MVC（模型-视图-控制器）解决了将 UI 与模型分离的问题。

概念框架#

下面定义了与提议的架构模式相关的概念。

用户#

用户是指想要与交互式系统交互以实现某些目标的人，例如订购食物、预约、获取一些信息等。

交互式系统#

交互式系统是一种计算机系统，可以与人交互以帮助他们实现目标。交互式系统也可以用目的/目标来表征，例如，宣传或销售产品、在前台办理新酒店客人的入住手续等。

事件#

事件是指与用户、机器人、系统或用户和系统都存在的环境相关的事情，例如，环境的状态变化、用户执行的动作、系统执行的动作。

动作#

动作是用户或交互式系统主动或响应其他动作和事件而执行的操作。每个动作都与一个单一的模态相关联。多个动作可以映射到相同的模态（例如，语音、喊叫、耳语、哼唱，都映射到 BotVoice）。动作不能占用多个模态。每个动作在 UMIM 中都由一系列事件表示，以表示其生命周期和执行。生成事件以启动和停止动作，并提供有关动作执行的更新。有关更多信息，请参阅基本动作规范部分。

上下文#

上下文包含交互式系统可用的所有信息，并且与交互相关。通常，上下文将包含各种类型的信息，如配置信息、会话数据、环境数据（例如，对象、变体）、用户信息等。

传感器#

传感器捕获与用户交互的原始输入，例如麦克风、摄像头、触摸屏、温度、运动等。

会话#

会话（或交互会话）完全由一系列事件表征，这些事件表示用户执行的动作、系统执行的动作以及与系统状态相关的其他变化。

模态#

在多模态交互中，用户和交互式系统之间的信息可以在多个模态上交换。模态是机器人和用户之间独立的“交互通道”。模态不是指技术通道，而是“交互通道”。模态的示例包括 UserVoice、BotVoice。每个动作都影响一个单一的模态，该模态反过来可以影响多个系统通道（见下文）。例如：BotUtterance 动作（让机器人口头与用户交流）与 BotVoice 模态相关联。在机器人由 3D 头像表示的交互式系统中，此模态映射到多个系统通道：音频输出（合成语音）、嘴唇运动（嘴唇与语音同步）、用户界面上的文本（话语的字幕）。

系统通道#

系统通道是允许将信息从交互式系统发送给用户和反之亦然的技术通道。系统通道的示例包括音频输出、麦克风输入、摄像头输入或用户界面。交互式系统负责将不同的模态映射到系统通道。根据交互式系统，单个 UMIM 模态可以覆盖多个系统通道。例如，BotMovement 动作影响 BotLowerBody 模态，但可以映射到系统通道：下半身动画（行走动画）、音频输出（脚步声）。

交互管理器 (IM) 架构模式#

交互管理器模式旨在将决策逻辑与交互式系统的其余部分分开，并定义了三个架构约束

  1. 交互管理器作为一个独特的事件驱动组件；

  2. 事件、上下文和动作作为交互管理器的核心接口；

  3. 传感器服务器和动作服务器作为独立的组件。

以下各节更详细地描述了这些架构约束中的每一个。

1. 独特的事件驱动组件#

交互式系统的架构应具有一个独特的组件，称为交互管理器，负责决定系统应采取哪些动作来响应用户动作或其他事件，同时考虑到当前的上下文。IM 应仅通过事件驱动机制与系统的其余部分交互。IM 和交互式系统的其余部分之间不应有共享状态。

../../_images/system_overview.png

架构中交互管理器 (IM) 作为一个独特的事件驱动组件。#

2. 事件、动作和上下文#

IM 和系统其余部分之间的交互应通过三种主要类型的事件完成

  1. 通用事件：表示“发生”的任何事情，并且与交互相关，例如用户说了什么 (UserSaid)、用户手势 (UserGesture)、使用 UI 元素单击 (UserSelection) 等。

  2. 动作事件：与交互系统应执行的操作相关，例如说些什么、播放声音、在显示器上显示某些内容、更改头像、调用第三方 API 等；这些事件应标记动作生命周期中的各个相关点，例如，决定执行某项操作 (StartAction)、操作何时开始 (ActionStarted) 或完成 (ActionFinished) 等；

  3. 上下文事件：表示交互系统中包含的任何数据的更改 (ContextUpdate)，这些数据与交互相关，例如用户名、用户权限、选定的产品、设备信息等。

3. 传感器服务器和动作服务器#

交互管理器不应执行任何动作，也不应直接处理任何传感器输入。传感器服务器 (SS) 组件负责处理原始输入数据（音频、视觉、文本、自定义事件）并生成事件，这些事件是交互管理器的输入。动作服务器 (AS) 负责动作的执行。AS 还可以为 IM 生成额外的事件，例如，发出信号表示动作的开始或成功/失败执行。

../../_images/sensor_and_action_server.png

传感器服务器 (SS) 和动作服务器 (AS) 作为独立组件。#

关于架构模式的一些注意事项#

本节评论了与 IM 模式和实现此模式的系统的总体架构相关的一些其他方面。

交互会话#

交互会话完全由事件流描述。交互的事件流是不可变的，即一旦添加事件，就无法删除它们。

同步动作执行#

IM 模式的一个重要部分是动作的执行会生成事件，这些事件可以用于触发其他动作。

例如，IM 可以决定系统应该说“你好！”并且只有在 Say 动作完成后才做出特定的手势，例如指向屏幕并询问一些问题。在这种情况下，ActionFinished(Say) 事件将由 IM 用于发送 StartAction(MakeGesture)。

作为另一个示例，IM 可以决定在 Say(hello) 动作开始时开始挥手动画，并在 Say(hello) 完成时停止动画。在这种情况下，ActionStarted(Say) 和 ActionFinished(Say) 可以用作 StartAction(MakeGesture(Wave)) 和 StopAction(MakeGesture(Wave)) 的触发器。

拥有多个交互管理器#

IM 模式并不强制要求只能有一个交互管理器。一个架构可以有多个 IM，并且有两种主要场景

具有内部（辅助）IM 的主 IM；多个对等 IM，每个 IM 处理不同类型的事件。

作为场景 1 的具体示例，在交互式头像体验中，主 IM 可以管理交互的高级流程（例如，问候、收集数据、提供数据、获取确认等各个阶段），并在需要时移交给更具体的 IM（例如，对于复杂的身份验证流程，对于 IRQA 场景）。

作为场景 2 的具体示例，一个 IM 可以处理对话逻辑（即机器人应该说什么），而第二个 IM 可以根据机器人所说的内容处理头像的动画。

状态性#

交互管理器可以实现为有状态组件或无状态组件。

  • 在有状态方法中，IM 需要支持显式的“会话管理”功能。

  • 在无状态方法中，交互的完整历史记录必须随每个新事件一起提供。

一次处理多个事件#

在实践中，当 IM 忙于处理事件（即决定下一个动作）时，交互式系统的其他部分可能会生成多个事件。事件是一个接一个地处理还是全部一次处理取决于交互式系统架构（后者有额外的挑战，因此建议采用逐个处理的方法）。

处理 NLU#

在交互式系统中集成 NLU 有三种主要模式

  1. 作为单独的组件。 在实践中，在大多数系统中，NLU 与对话管理组件是分开的。通过遵循相同的模式，架构中单独的 NLU 组件将处理 UserSaid 事件并生成 UserIntent 事件，然后 IM 将处理这些事件。

  2. 作为“解释”动作。 IM 将显式触发 Interpret 动作，该动作将解释消息并返回结构化表示和置信度级别。基于此，IM 将决定下一个动作。

  3. IM 内部。 IM 本身也可以处理 NLU。例如，IM 可以调用 ML 模型来解释结果，并基于此决定下一步做什么。此消息的缺点是在解释消息期间，事件的处理将被阻止。这可能会在涉及多个模态的场景中产生不良后果。

在本页中