【转载】对话动作集定义CUED Standard Dialogue Acts

原文转自：对话动作集定义CUED Standard Dialogue Acts - 知乎

文章：CUED Standard Dialogue Acts

目标：希望从零开始构建自己对话数据的那种情况，对自己业务定义用户目标、动作集构建有引导作用。

优化：针对动作定义标准，我觉得优化方向有以下：

可以采用一些单一动作的组合，表示复杂的动作。也就是进一步的抽象动作表示。比如Hello(a=b,c=d) 可以表示为 [hello(), inform(a=b), inform(c=d)]，这种会在动作选择，或agenda栈中表达更灵活，代码更抽象。
一句话中是否可以有多个动作组合，目前系统一句话只能表达一个意图，这显然是不太理想的。希望可以建模多个动作的联合概率表达。

Attributes, values and the application domain

本部分主要讲用户目标的表示方法，将本体论概念引入用户目标构建中，采用 the ontology tree structure 来构建用户目标。需要理解ontology rule构建tree 的规则、entity、attribute、subtype等概念。

虽然本文的应用领域主要是信息检索领域，但其实我们还是希望做到领域无关的用户目标和动作集定义，具有较高的拓展性。

应用本体论，我们把对话动作看作是领域内的实体entity，实体有其相应的属性attribute，实体之间、实体与属性之间构建它们的关系。应用到the ontology tree structure中，树的根对应于讨论中的特定实体，树的节点定义了该实体的特征(属性)，叶子节点是属性值，层次结构定义了关系。

上图展示了一个简单旅游信息系统的示例本体规则。括号内以逗号分割的为子节点；括号内竖线分割的枚举了可能的值，叶子节点属性值。

应用到某个目标树中可以看到：

这里注意新添加的灰色部分反向箭头到节点，叫做 subtype，他们指向的节点都是有子属性的。

树中的节点（除了叶子节点），都对应着一个对话动作，它们是属性名；而叶子节点和subtype 是属性值。比如上图中有效的节点entity, area, addr等，有效的值"Italian", "restaurant", "Main Street"等。

节点(属性)命名方面，由于某些节点可能在不同的上下文中重新出现，因此可以限定节点名。如name 在多个出现，限定 landmark.name 和 venue.name。此外，当在限定位置使用时，节点名及其子类型是可互换的。比如 restaurant.food 和 type.food 都可以认为是引用 food 节点。

注：如果有请求的属性，可以标识为“UNK”等特定标识符。

Structure of a Dialogue Act

本部分主要讲对话动作的表示方法。

上图为一个对话动作集合，它对应了对话中的一句对话信息。集合中的每一项代表了动作的一个假设，每个假设会有prob，和为1，但如果说prob是省略的，那么所有可能性相同。

每个attribute=value pair 叫做 item，对应于目标树中的一个属性或者一个领域实体描述。

动作集语法，左边为动作表示组成部分，右边为此部分的表示方法：

注意 item 中有三种表达方式，单独请求 attr；attr=(!=)value；=value见 3-6行。

但是往往一句话中不只有一个意图，但是本文的前提是，一个对话中只有一个意图，保证概率合为1。为了弥补，一个动作中可以添加多个item，比如：I want to eat some Italian food and listen to some Jazz.

而下面这个表示方法含义是要么是Italian 要么是 jazz：

那如果动作type不同怎么办？

命名上也会跟目标树中的命名类似，防止歧义。

属性的值上，要么是subtype 要么是叶子节点，例如，inform（type=restaurant）表示节点类型为subtype restaurant，而inform（food=”Italian”）只是属性节点food的值为“Italian”。可以为任何属性指定值“dontcare”，以指定该属性不重要。属性值是可以不填的，是需要从对话中获取的，例如，request（name，type=hotel）是对酒店名称的请求。对话动作中也可以属性名为空（=“dontcare”）。在这种情况下，用户只是简单地说了一句“我不在乎”，并且没有上下文可用于标识关联节点。

Semantic Decoding and Ambiguity

语义解析，解决歧义性。

由于ASR 误差，用户输入歧义等情况，可能会对用户输入有多种理解方式。比如用户只输入：

可能理解为 inform(area=central) 或者 confirm(area=central)，这种情况会输出多个解析假设结果。

上节抛出的问题，目前该标准前提是每句话只有一个动作，但实际情况一句话中往往有多个动作：

这里会有两个并列的解析结果：request(price) and confirm(price=expensive) 。语义解析器可以将两个都输出作为并列的假设结果，DM将会选择其中一个进行处理，其实对其中一个的合理响应可能会让用户满意。

当然语义解析需要做好歧义性：

Dialogue Act Definitions

这部分介绍CUED标准下定义的动作集合，可以分为4组：

information providing
query
confirmation
housekeeping

这里区分了用户对话行为和系统对话行为。有些行为可能是领域下的，有些则是通用的。但需要自己去优化，我们希望是通用的。完整的表，梳理如下：

Information Providing

inform act：一般用来通知一些信息，但是它不要求对方有任何特定的回应。以下例子对应表中第一行：

第一种特殊情况是，name 的属性值为 none，表明数据库中没有相匹配的实例。

第二种特殊情况是，name的属性值为 dontcare，表示"wildcard"，可以匹配任何实例。对应表中第四行

第三个情况是形如：inform(food!="Italian")，表示除了Italian 其他都可以。

这里有一些组合的情况，name=none 和 negated name attributes (如 inform(name=none, name!="Char Sue", food=Chinese))能够组合起来表达Char Sue是唯一匹配的实例，也就是倒数第一行。

name=none 和 negated one attributes 如 inform(name=none, food!="Italian") 可以表达数据库中所有的实例都有Italian，也就是倒数第二行。注意后面的item = 的项是一些约束项。

Query

Query act：对话动作需要对方给定一个回答。最普通的就是request后再带一个槽位名，如第一行。还有一种情况是，item后再带约束条件的。

其他特殊形式：

reqalts act：表示用户想要继续探讨不同的目标。例如，如果向用户提供了有关餐厅的信息，他可能会说

当然，也可能带一些额外约束信息：

reqmore act：需要当前主题下或某些特定属性下的详细信息。当然可以添加一些约束条件：

Confirmation

Confirm acts：在显示的或隐式的情况下，请求”yes”/”no” 的回答。系统动作可以防止误差导致的误解。用户也可以发出确认的请求，以检查所提供的信息是否与他们的需要相符。

这里有两种形式的验证：

confirm act：显示的验证，需要回答either ”yes” or ”no”.
confreq act：隐式的验证。他可以带一个或多个 item。验证正确，用户可以忽略，只需响应请求。如果它们不正确，用户将被期望no响应，并忽略进一步信息的请求。

affirm act：正向的回应。也可以添加 item，这种情况下与 affirm act 再加一个 inform act 相同了。
negate and deny act：否定的回应。negate act 如果没有带item 参数，就是简单的 NO回应。如果带有参数，这里有两种方式解析第一个参数。如果第一个参数是正确参数，采用negate act。如果第一个参数是否定的参数，采用deny act。第一个参数之后的参数跟 affirm 的其他参数一样，是inform动作