【论文笔记】A User Simulator for Task-Completion Dialogues

基本框架(包含对话系统):

Abstract:

做任务型bot的时候,强化学习(RL)很强,但是有一些困难:

  1. 需要和环境互动,已有的完整对话训练数据没用;
  2. 每个不同的任务都需要各自领域的标注数据;
  3. 收集人人对话或者人机对话需要领域知识。

但是啊:

====>建造数据库又贵又花时间

====>只好模拟

====>user simulator诞生

====>Bot(agent)先用simulator去训练,搞定了simulator就可以上线,持续online learning

Introduction:

对话系统一般如 Figure 1. 所示。Dialongue Policy (DP)是一个任务型bot的核心。

一般来说传统的Dialogue Policy(DP)使用规则编程的,但有缺点:

对于复杂系统,难以设计

  1. 最优的policy也会变化,不好维护。
    因此,一般用强化学习训练DP。

为啥要user simulator ?

  1. Supervised Learning(SL)监督学习在任务型的bot里不行:

    1. 需要专家来标注大量数据;
    2. 大量专业的领域知识需要大量的数据来训练;
    3. 即使有大量训练数据,还是会有对话空间没有被搜索到。
  2. 相反的,RL很吊,不需要专家生成的数据,给一个奖励信号,agent就可以通过交互优化DP。

但是不幸的是:RL需要从环境来的很多sample,所以和真实用户从零开始训练不实际。

====> 所以需要User Simulators!

一般的操作是:先在simulator上训练出一个比较好的效果,再部署到真实场景中,持续online learning。

很难判断user simulator好不好,没有Metric来判定,so没有标准方法,放手乱做。user simulation主要有这么几个类型:

从粒度上分:

  1. 在对话行为(dialogue-act)上进行操作的;
  2. 在对话文本(utterance)进行操作的

从方法的角度讲:

  1. 基于规则的(rule-based)
  2. 基于模型的(model-based)

以前的 bi-gram 模型 $P(a_u |a_m)$,基于上一个系统行为 $a_m$ 去预测下一个用户行为 $a_u$。这就很傻。(user有可能改goal,看的信息太少)

后面两个办法来处理:

  1. 看更长的对话历史
  2. 把user goal 放到user state modeling中

seq2seq端到端解决闲聊可以,任务型不太行。

本文用的叫 agenda-based user simulation 的架构,类似栈的结构通过进栈出栈来 model 状态转移和用户行为生成。很方便,显性encode了对话历史和用户目标(user goal)。

总结:文章 结合了rule-based和model-based 的方法:

  1. 在dialog-act level,用了agenda-based (rule)的方法;
  2. 在nlg部分,用了seq2seq (model)的方法。

Task-completion的对话系统(Dialogue system)

任务型对话系统(以订票bot为例),通过nl交互,去获取客户期望的信息,最终实现订票。以:

  1. 是否订票成功
  2. 是否电影满足要求

为标准,输出一个二进制结果,success or failure,评估系统。

数据:用Amazon Mechanical Turk(众包平台)收集的数据,内部标注,11个intent(i.e., inform,request,confirm-question,confirm-answer,etc),29个slot(i.e., movie-name,start-time,theater,numberofpeople,etc)。

一共标注了280个对话,对话平均11轮。

User Simulator

User Goal

TC Bot的user simulator第一步是生成user goal。agent不知道user goal,但是要帮助user来完成他的goal。user goal的定义分两个部分:

  1. inform_slots: 包含了constraints(C)
  2. request_slots: unk(R)

又可以分成:

  1. 必须有的slots(required slots)
  2. 选择有的slots(optional slots,i.e., ticket就是request slots 里的必须项)。

Goal是在labeled dataset里生成的,两个机制:

  1. 在第一个用户轮提取所有的slots。对于所有的slots,在所有的用户轮里提取第一次出现的。
  2. 每次跑对话的时候,就先sample一个user goal。

User Action

第一轮的action sampling:要加一些限制(比如通常是request turn,至少一个inform slot,movie_name必须在,等等)。

如果不用NLG,NLU的话,还要加入噪声来模拟NLG和NLU过程产生的噪音,去训练DM部分。

Dialogue Status

三个对化状态:

  1. no_outcome_yet
  2. success
  3. failure

具体情况具体讨论。

NLU

IOB-format slots tags + Intent tags

最后的hidden layer判断 intent。

NLG

基于Template的NLG:dialog-act 被found在模板中的,套模板句型。
基于Model的NLG:没发现的,用model生成。(这一点感觉很扯,都没见过,咋生成,数据量肯定不够啊。)

Usages

Task-completing Dialogue Setting:任务型Bot(订票),衡量 agent的Metrics为:1. success rate;2. average reward;3. average turns。
KB-InfoBot(简单点,agent和user都只有request和inform):问答Bot(电影信息)

Discussion

Rule-based的 user simulation 很safe,但是很耗时,因为要手动制定各种规则。两个优化方向:

包含user goal的改变(已做)
实现Model-based 的simulator,优点是泛化性能好,缺点是1. 需要大量数据, 2. 万一有漏洞,RL agent 会抓住这个漏洞,假假的成功,你以为success了,其实都是RL agent抓住了loophole给你的假象。

总结:

(根据《Agenda-Based User Simulation for bootstrapping a POMDP Dialogue System》by J. Schatzmann)

  1. 语义层的 User Simulation
    人机对话可以看成是状态转移(state transition)和对话行为(Dialog)的序列:用户根据状态 S (或加上机器人的 $a_m$,第一轮可能没有$a_m$),采取行动 $a_u$, 把状态转移到$S’$。收到agent行动 $a_m$,再根据 $S’$ ,再把状态转移到 $S’’$。
    这个user行为可以被分解为三个模型:$P(a_u|S)$ 行为选择,$P(S’|a_u, S)$ 状态转移(用户行为),$P(S’’|a_m,S’)$ 状态转移(系统行为)。
  2. 基于Goal和Agent的状态表示
    用户状态(User State)由用户目标(Goal)及议程(Agenda)构成。

Goal由Constraint(C)(比如要市中心的啤酒酒吧)和Request(R)(比如酒吧电话是多少)构成。

Agenda是一个类似栈的结构,包含了在排队中的,用来引出目标中明确的信息的用户行为。在对话开始的时候,用数据库随机生成一个新的Goal。然后,从Goal里的内容来初始化Agenda,把Goal中的 C 都convert成 Inform动作,把Goal中的 R 都convert成 Request动作,再在最后加一个bye动作。有新的 $a_m$ 的时候,新的user acts 会被压进栈,不需要的会被出栈。具体实现方法(框架和数据结构),后面分析miulab的simulator源码的时候会写。

上图描述了Agenda随着$a_m$,$a_u$的状态转移过程(进栈和出栈)。

上图描述了无NLU和NLG的训练。