精华内容
下载资源
问答
  • 对话管理

    2015-09-22 22:28:55
    对话管理不仅要能够完成对话,还要“漂亮”的完成对话。这个漂亮一方面让提取器尽量提对,没有太多错误。 另一方面对话要多种多样,在完成功能的基础上把话说的漂亮。所以应该在对话MDP模型里应该有对对话多样性...

    对话管理不仅要能够完成对话,还要“漂亮”的完成对话。这个漂亮一方面让提取器尽量提对,没有太多错误。

    另一方面对话要多种多样,在完成功能的基础上把话说的漂亮。所以应该在对话MDP模型里应该有对对话多样性的度量。

    对话多样性1.同一个意思应该有多种表述2.不应该在同一个问题上“纠结”太长时间。

    因为马氏决策过程只根据当前的系统对话状态去决策,过去的状态并不考虑进来。

    而对话系统是需要一定的memory,最直观的解释就是人与人在对话过程中当前说的话可能会考虑到上几轮的对话内容。

    如果仍然在马氏决策过程的这个框架内,应该如何改进MDP模型让它具有一定的memory。

    目前的想法是在state里添加特征,因为state表征的就是多轮对话后造成的影响到现在是一个什么样子的状态。

    那么解决方法就应该是这样: 1.同一个意思应该有多种表述:生成许多个对话模板,随机选择。

    2.不应该在同一个问题上,“纠结”太长时间: 在state里添加上一次对话的动作,这样当同一个动作出现2次,就暂时不让它再出现。 因为重复询问主要集中在“re_requeset”这个动作上,所以没必要把所有的上一次动作都加入进去。

    只需记录上一次动作是不是re_request动作即可。

    另一种方法也可以通过增加槽的activity来实现:1 request_activity 2 confirm_activiyt 3.re_request_activity

    而不用大范围的修改上层MDP的逻辑

    State Slot_state If_Activity fetch_info user_attitude history_info==fetch_info user_action
    0 0 0 0 any any request
    1 0 0 1 any any confirm
    2 0 1 0 any any Re_request
    3 0 1 1 any any confirm
    4 1 0 0 any any confirm
    5 1 0 1 any == done
    6 1 0 1 any != Re_confirm
    7 1 2 0 dis any Dis_request
    8 1 2 0 agr any done
    9 1 2 1 dis != Re_confirm
    10 1 2 1 dis == Done
    11 1 2 1 agr != re_confirm
    12 1 2 1 agr == done
    13 2 any any any any ok

    只需要在底层添加两个状态,上层mdp的逻辑不用大改

    State Slot_state If_Activity fetch_info user_attitude history_info==fetch_info user_action
    14 0 3 0 any any request
    15 0 3 1 any any confirm
    展开全文
  • 口语对话系统中对话管理方法研究综述
  • 人机对话系统又分下面这三方面:自然语言理解、对话管理、自然语言生成。这里面聊天、知识、任务、推荐,都有各自相应的研究点。具体内容请看PPT。 对话管理(Dialog Management, DM)是对话流程中的核心环节,充当...

    人机对话系统具有四大功能
    在这里插入图片描述人机对话系统又分下面这三方面:自然语言理解、对话管理、自然语言生成。这里面聊天、知识、任务、推荐,都有各自相应的研究点。
    在这里插入图片描述


    对话管理(Dialog Management, DM)是对话流程中的核心环节,充当了重要的角色。如图1所示:
    Dialog Management

    图1 对话流程图

    图1 是常见对话流的信息流动图。 首先,用户发出语音指令,1)通过语音识别ASR将语音转换为文本uu; 2) 文本通过语言理解NLU获得用户行为au; 3)通过用户行为生成对应系统行为au; 4)通过action生成对应的回复话术NLG; 5) NLG通过人工合成生成语音。

    Dialog Management

    对话管理(Dialog Management, DM)控制着人机对话的过程,DM 根据对话历史信息,决定此刻对用户的反应。最常见的应用还是任务驱动的多轮对话,用户带着明确的目的如订餐、订票等,用户需求比较复杂,有很多限制条件,可能需要分多轮进行陈述,一方面,用户在对话过程中可以不断修改或完善自己的需求,另一方面,当用户的陈述的需求不够具体或明确的时候,机器也可以通过询问、澄清或确认来帮助用户找到满意的结果。

    对话管理包括如下任务:

    • 对话状态维护(dialog state tracking, DST)
      维护 & 更新对话状态
      t+1 时刻的对话状态 st+1,依赖于之前时刻 t 的状态st,和之前时刻 t 的系统行为at,以及当前时刻 t+1 对应的用户行为at+1。可以写成 st+1st+at+ots_{t+1}\leftarrow s_{t} + a_{t} +o_{t}
    • 生成系统决策(dialog policy)
      根据 DST 中的对话状态(DS),产生系统行为(dialog act),决定下一步做什么
      dialog act 可以表示观测到的用户输入(用户输入 -> DA,就是 NLU 的过程),以及系统的反馈行为(DA -> 系统反馈,就是 NLG 的过程)
      DA 的具体介绍将在 NLU 系列中展开
    • 作为接口与后端/任务模型进行交互
    • 提供语义表达的期望值(expectations for interpretation)
      interpretation: 用户输入的 internal representation,包括 speech recognition 和 parsing/semantic representation 的结果

    本质上,任务驱动的对话管理实际就是一个决策过程,系统在对话过程中不断根据当前状态决定下一步应该采取的最优动作(如:提供结果,询问特定限制条件,澄清或确认需求…)从而最有效的辅助用户完成信息或服务获取的任务
    在这里插入图片描述
    如图,DM 的输入就是用户输入的语义表达(或者说是用户行为,是 NLU 的输出)和当前对话状态,输出就是下一步的系统行为和更新的对话状态。这是一个循环往复不断流转直至完成任务的过程,其中,语义输入就是流转的动力,DM 的限制条件(即通过每个节点需要补充的信息/付出的代价)就是阻力,输入携带的语义信息越多,动力就越强;完成任务需要的信息越多,阻力就越强。

    case 1
    在这里插入图片描述
    实际上,DM 可能有更广泛的职责,比如融合更多的信息(业务+上下文),进行第三方服务的请求和结果处理等等。

    Initiative

    对话引擎根据对话按对话由谁主导可以分为三种类型:

    • 系统主导
      系统询问用户信息,用户回答,最终达到目标
    • 用户主导
      用户主动提出问题或者诉求,系统回答问题或者满足用户的诉求
    • 混合
      用户和系统在不同时刻交替主导对话过程,最终达到目标
      有两种类型,一是用户/系统转移任何时候都可以主导权,这种比较困难,二是根据 prompt type 来实现主导权的移交
      Prompts 又分为 open prompt(如 ‘How may I help you‘ 这种,用户可以回复任何内容 )和 directive prompt(如 ‘Say yes to accept call, or no’ 这种,系统限制了用户的回复选择)。

    Basic concepts

    • Ground and Repair
      对话是对话双方共同的行为,双方必须不断地建立共同基础(common ground, Stalnaker, 1978),也就是双方都认可的事物的集合。共同基础可以通过听话人依靠(ground)或者确认(acknowledge)说话人的话段来实现。确认行为(acknowledgement)由弱到强的 5 种方法(Clark and Schaefer 1989)有:持续关注(continued attention),相关邻接贡献(relevant next contribution),确认(acknowledgement),表明(demonstration),展示(display)。

    听话人可能会提供正向反馈(如确认等行为),也可能提供负向反馈(如拒绝理解/要求重复/要求 rephrase等),甚至是要求反馈(request feedback)。如果听话人也可以对说话人的语段存在疑惑,会发出一个修复请求(request for repair),如

    A: Why is that?
    B: Huh?
    A: Why is that? 
    

    还有的概念如 speech acts,discourse 这类,之前陆陆续续都介绍过一些了。
    人的复杂性(complex)、随机性(random)和非理性化(illogical)的特点导致对话管理在应用场景下面临着各种各样的问题,包括但不仅限于:

    Challenges

    模型描述能力与模型复杂度的权衡

    • 用户对话偏离业务设计的路径
      如系统问用户导航目的地的时候,用户反问了一句某地天气情况
    • 多轮对话的容错性
      如 3 轮对话的场景,用户已经完成 2 轮,第 3 轮由于ASR或者NLU错误,导致前功尽弃,这样用户体验就非常差
    • 多场景的切换和恢复
      绝大多数业务并不是单一场景,场景的切换与恢复即能作为亮点,也能作为容错手段之一
    • 降低交互变更难度,适应业务迅速变化
    • 跨场景信息继承

    Approaches

    1) Structure-based Approaches

    1. Key Pharse Reactive Approaches
      本质上就是关键词匹配,通常是通过捕捉用户最后一句话的关键词/关键短语来进行回应,比较知名的两个应用是 ELIZA 和 AIML。AIML (人工智能标记语言),XML 格式,支持 ELIZA 的规则,并且更加灵活,能支持一定的上下文实现简单的多轮对话(利用 that),支持变量,支持按 topic 组织规则等。
    <category>
    <pattern>DO YOU KNOW WHO * IS</pattern> 
    <template><srai>WHO IS <star/></srai></template> 
    </category>
    
    <category>
    <pattern>MOTHER</pattern>
    <template> Tell me more about your family. </template> 
    </category>
    
    <category>
    <pattern>YES</pattern>
    <that>DO YOU LIKE MOVIES</that> 
    <template>What is your favorite movie?</template> 
    </category>
     
    
    1. Trees and FSM-based Approaches
      Trees and FSM-based approach 通常把对话建模为通过树或者有限状态机(图结构)的路径。 相比于 simple reactive approach,这种方法融合了更多的上下文,能用一组有限的信息交换模板来完成对话的建模。这种方法适用于:
    • 系统主导
    • 需要从用户收集特定信息
    • 用户对每个问题的回答在有限集合中
      这里主要讲 FSM,把对话看做是在有限状态内跳转的过程,每个状态都有对应的动作和回复,如果能从开始节点顺利的流转到终止节点,任务就完成了。
      在这里插入图片描述
      在这里插入图片描述

    FSM 的状态对应系统问用户的问题,弧线对应将采取的行为,依赖于用户回答。

    FSM-based DM 的特点是:

    • 人为定义对话流程
    • 完全由系统主导,系统问,用户答
    • 答非所问的情况直接忽略
    • 建模简单,能清晰明了的把交互匹配到模型
    • 难以扩展,很容易变得复杂
    • 适用于简单任务,对简单信息获取很友好,难以处理复杂的问题
    • 缺少灵活性,表达能力有限,输入受限,对话结构/流转路径受限

    对特定领域要设计 task-specific FSM,简单的任务 FSM 可以比较轻松的搞定,但稍复杂的问题就困难了,毕竟要考虑对话中的各种可能组合,编写和维护都要细节导向,非常耗时。一旦要扩展 FSM,哪怕只是去 handle 一个新的 observation,都要考虑很多问题。实际中,通常会加入其它机制(如变量等)来扩展 FSM 的表达能力。

    2) Principle-based Approaches

    1. Frame-based Approaches
      Frame-based approach 通过允许多条路径更灵活的获得信息的方法扩展了基于 FSM 的方法,它将对话建模成一个填槽的过程,槽就是多轮对话过程中将初步用户意图转化为明确用户指令所需要补全的信息。一个槽与任务处理中所需要获取的一种信息相对应。槽直接没有顺序,缺什么槽就向用户询问对应的信息。
      在这里插入图片描述
      Frame-based DM 包含下面一些要素:

    Frame: 是槽位的集合,定义了需要由用户提供什么信息
    对话状态:记录了哪些槽位已经被填充
    行为选择:下一步该做什么,填充什么槽位,还是进行何种操作
    行为选择可以按槽位填充/槽位加权填充,或者是利用本体选择
    基于框架/模板的系统本质上是一个生成系统,不同类型的输入激发不同的生成规则,每个生成能够灵活的填入相应的模板。常常用于用户可能采取的行为相对有限、只希望用户在这些行为中进行少许转换的场合。

    Frame-based DM 特点:

    • 用户回答可以包含任何一个片段/全部的槽信息
    • 系统来决定下一个行为
    • 支持混合主导型系统
    • 相对灵活的输入,支持多种输入/多种顺序
    • 适用于相对复杂的信息获取
    • 难以应对更复杂的情境
    • 缺少层次
      槽的更多信息可以参考填槽与多轮对话 | AI产品经理需要了解的AI技术概念

    Agenda + Frame(CMU Communicator)

    Agenda + Frame(CMU Communicator) 对 frame model 进行了改进,有了层次结构,能应对更复杂的信息获取,支持话题切换、回退、退出。主要要素如下:

    • product
      树的结构,能够反映为完成这个任务需要的所有信息的顺序
      相比于普通的 Tree and FSM approach,这里产品树(product tree)的创新在于它是动态的,可以在 session 中对树进行一系列操作比如加一个子树或者挪动子树
    • process
      • agenda
        相当于任务的计划(plan)
        类似栈的结构(generalization of stack)
        是话题的有序列表(ordered list of topics)
        是 handler 的有序列表(list of handlers),handler 有优先级
      • handler
        产品树上的每个节点对应一个 handler,一个 handler 封装了一个 information item

    从 product tree 从左到右、深度优先遍历生成 agenda 的顺序。当用户输入时,系统按照 agenda 中的顺序调用每个 handler,每个 handler 尝试解释并回应用户输入。handler 捕获到信息就把信息标记为 consumed,这保证了一个 information item 只能被一个 handler 消费。

    input pass 完成后,如果用户输入不会直接导致特定的 handler 生成问题,那么系统将会进入 output pass,每个 handler 都有机会产生自己的 prompt(例如,departure date handler 可以要求用户出发日期)。

    可以从 handler 返回代码中确定下一步,选择继续 current pass,还是退出 input pass 切换到 output pass,还是退出 current pass 并等待来自用户输入等。handler 也可以通过返回码声明自己为当前焦点(focus),这样这个 handler 就被提升到 agenda 的顶端。为了保留特定主题的上下文,这里使用 sub-tree promotion 的方法,handler 首先被提升到兄弟节点中最左边的节点,父节点同样以此方式提升。
    在这里插入图片描述
    系统还能处理产品树中节点之间的依赖关系。典型的依赖关系在父节点和子节点之间。通常父节点的值取决于其子节点。每个节点都维护一个依赖节点的列表,并且会通知依赖节点值的变化,然后依赖节点可以声明自己是无效的并成为当前对话的候选主题。

    给一个例子,能够回应用户的显式/隐式话题转移(A1-A3, U11),也能够动态添加子树到现有的 agenda(A8-A10)。
    在这里插入图片描述
    具体还是看论文吧
    AN AGENDA-BASED DIALOG MANAGEMENT ARCHITECTURE FOR SPOKEN LANGUAGE SYSTEMS

    Information-State Approaches

    Information State Theories 提出的背景是:

    • 很难去评估各种 DM 系统

    • 理论和实践模型存在很大的 gap
      理论型模型有:logic-based, BDI, plan-based, attention/intention
      实践中模型大多数是 finite-state 或者 frame-based
      即使从理论模型出发,也有很多种实现方法
      因此,Information State Models 作为对话建模的形式化理论,为工程化实现提供了理论指导,也为改进当前对话系统提供了大的方向。Information-state theory 的关键是识别对话中流转信息的 relevant aspects,以及这些成分是怎么被更新的,更新过程又是怎么被控制的。idea 其实比较简单,不过执行很复杂罢了。理论架构如下:
      在这里插入图片描述
      介绍下简单的一些要素:

    • Statics

      • Informational components
        包括上下文、内部驱动因子(internal motivating factors)
        e.g., QUD, common ground, beliefs, intentions, dialogue history, user models, etc.
      • Formal representations
        informational components 的表示
        e.g., lists, records, DRSs,…
    • Dynamics

      • dialog moves
        会触发更新 information state 的行为的集合
        e.g., speech acts
      • update rules
        更新 information state 的规则集合
        e.g., selection rules
      • update strategy
        更新规则的选择策略,选择在给定时刻选用哪一条 update rules
        意义在于可以遵循这一套理论体系来构建/分析/评价/改进对话系统。基于 information-state 的系统有:
        TrindiKit Systems
        –  GoDiS (Larsson et al) – information state: Questions Under Discussion
        –  MIDAS – DRS information state, first-order reasoning (Bos &Gabsdil, 2000)
        –  EDIS – PTT Information State, (Matheson et al 2000)
        –  SRI Autoroute –Conversational Game Theory (Lewin 2000)
        Successor Toolkits
        –  Dipper (Edinburgh)
        –  Midiki (MITRE)
        Other IS approaches
        –  Soar (USC virtual humans)
        –  AT&T MATCH system

    Plan-based Approaches

    一般指大名鼎鼎的 BDI (Belief, Desire, Intention) 模型。起源于三篇经典论文:

    • Cohen and Perrault 1979
    • Perrault and Allen 1980
    • Allen and Perrault 1980
      基本假设是,一个试图发现信息的行为人,能够利用标准的 plan 找到让听话人告诉说话人该信息的 plan。这就是 Cohen and Perrault 1979 提到的 AI Plan model,Perrault and Allen 1980 和 Allen and Perrault 1980 将 BDI 应用于理解,特别是间接言语语效的理解,本质上是对 Searle 1975 的 speech acts 给出了可计算的形式体系。

    官方描述(Allen and Perrault 1980):

    A has a goal to acquire certain information. This causes him to create a plan that involves asking B a question. B will hopefully possess the sought information. A then executes the plan, and thereby asks B the question. B will now receive the question and attempt to infer A’s plan. In the plan there might be goals that A cannot achieve without assistance. B can accept some of these obstacles as his own goals and create a plan to achieve them. B will then execute his plan and thereby respond to A’s question.

    重要的概念都提到了,goals, actions, plan construction, plan inference。理解上有点绕,简单来说就是 agent 会捕捉对 internal state (beliefs) 有益的信息,然后这个 state 与 agent 当前目标(goals/desires)相结合,再然后计划(plan/intention)就会被选择并执行。对于 communicative agents 而言,plan 的行为就是单个的 speech acts。speech acts 可以是复合(composite)或原子(atomic)的,从而允许 agent 按照计划步骤传达复杂或简单的 conceptual utterance。

    这里简单提一下重要的概念。

    • 信念(Belief)
      基于谓词 KNOW,如果 A 相信 P 为真,那么用 B(A, P) 来表示
    • 期望(Desire)
      基于谓词 WANT,如果 S 希望 P 为真(S 想要实现 P),那么用 WANT(S, P) 来表示,P 可以是一些行为的状态或者实现,W(S, ACT(H)) 表示 S 想让 H 来做 ACT

    Belief 和 WANT 的逻辑都是基于公理。最简单的是基于 action schema。每个 action 都有下面的参数集:

    • 前提(precondition)
      为成功实施该行为必须为真的条件
    • 效果(effect)
      成功实施该行为后变为真的条件
    • 体(body)
      为实施该行为必须达到的部分有序的目标集(partially ordered goal states)

    计划推理(Plan Recognition/Inference, PI)
    根据 B 实施的行为,A 试图去推理 B 的计划的过程。

    • PI.AE Action-Effect Rule(行为-效果规则)
    • PI.PA Precondition-Action Rule(前提-行为规则)
    • PI.BA Body-Action Rule(体-行为规则)
    • PI.KB Know-Desire Rule(知道-期望规则)
    • E1.1 Extended Inference Rule(扩展推理规则)

    计划构建(Plan construction)

    找到从当前状态(current state)达到目标状态(goal state)需要的行为序列(sequence of actions)
    Backward chaining,大抵是说,试图找到一个行为,如果这个行为实施了能够实现这个目标,且它的前提在初始状态已经得到满足,那么计划就完成了,但如果未得到满足,那么会把前提当做新的目标,试图满足前提,直到所有前提都得到满足。(find action with goal as effect then use preconditions of action as new goal, until no unsatisfied preconditions)
    backward chaining 在 NLP 笔记 - Meaning Representation Languages 中提到过。
    还有个重要的概念是 speech acts,在 NLP 笔记 - Discourse Analysis 中提到过,之后会细讲。

    更多见 Plan-based models of dialogue

    值得一提的是,基于 logic 和基于 plan 的方法虽然有更强大更完备的功能,但实际场景中并不常用,大概是因为大部分的系统都是相对简单的单个领域,任务小且具体,并不需要复杂的推理。

    Statistical Approaches

    1. RL-Based Approaches
      前面提到的很多方法还是需要人工来定规则的(hand-crafted approaches),然而人很难预测所有可能的场景,这种方法也并不能重用,换个任务就需要从头再来。而一般的基于统计的方法又需要大量的数据。再者,对话系统的评估也需要花费很大的代价。这种情况下,强化学习的优势就凸显出来了。RL-Based DM 能够对系统理解用户输入的不确定性进行建模,让算法来自己学习最好的行为序列。首先利用 simulated user 模拟真实用户产生各种各样的行为(捕捉了真实用户行为的丰富性),然后由系统和 simulated user 进行交互,根据 reward function 奖励好的行为,惩罚坏的行为,优化行为序列。由于 simulated user 只用在少量的人机互动语料中训练,并没有大量数据的需求,不过 user simulation 也是个很难的任务就是了。
      在这里插入图片描述

    参考文献

    展开全文
  • 基于主题森林结构的对话管理模型,一种对话管理的新模式,新方法
  • 口语对话管理综述

    2018-11-26 09:02:46
    口语对话管理综述 作者:王菁华 对话系统的基本流程 1 语音识别(将用户输入的声音转化成文本)命令行输入时可不用(ASR) 2自然语言分析(NLU) 对ASR输出的文本进行分析,建立语义表示。 3对话管理 核心部分,根据...

    口语对话管理综述

    作者:王菁华

    对话系统的基本流程

    1 语音识别(将用户输入的声音转化成文本)命令行输入时可不用(ASR)

    2自然语言分析(NLU) 对ASR输出的文本进行分析,建立语义表示。

    3对话管理 核心部分,根据NLU分析出的用户语义控制整个对话的进行

    4后台数据库 进行查询数据

    5自然语言生成 将文本结构合成声音(NLG)

     

    核心部分:

    从NLU服务器接收分析出来的结果,根据保存的对话状态和对历史判断对话流程,组织回答发送给NLG,若查询条件满足则组织进行后台数据库的查询。

    对话管理系统应当根据对话历史建立上下文信息,并根据上下文正确理解用户输入。

    现流行的是用户与系统主导的对话系统,用户可以提出问题,系统根据查询条件是否满足回馈用户,若查询条件满足,则进行查询数据库组织语言返回,若不满足,则对用户进行提问来查找缺少的查询条件。

     

    对话管理设计方法介绍

    1 基于状态图的结构

    利用有限状态机来控制对话的进行,类似于RNN,s表示状态,x表示用户输入,y表示系统输出。s(t+1) = r(s(t),x(t)) 这表示一状态,y(t) = u(s(t),x(t)),表示系统输出,即下一状态由当前状态和系统输入决定,输出由当前状态和用户输入决定。个人感觉类似于RNN

    缺点:需要考虑到用户提问的全部情况,小对话时可使用 例如提问bye thank you这种,当需要查询条件多时无法满足。灵活性较差。但响应较快。

    2 填充槽结构

    采用多维特征向量来表示对话的情况。可以在对话的过程中不断修改向量的值,对于操作的顺序没有严格限制,根据现在状态进行响应,随后根据用户的回答或系统的反应修改特征向量。

    缺点:也需要列出所有可能状态。

    3 基于任务的结构

    任务是指用户为达到某一 目的采取的一系列操作或对话。可以采用树进行表示

    电影服务是根节点,随后以下各个节点表示为解决该任务所需要的信息,要素之间的关系可通过与或者 “或” 进行表示,系统首先判断是什么任务,建立任务树,随后提问用户所需要的查询信息,根据用户回答来填充树。

    4 基于逻辑表达式的结构

    将上述任务树转换成逻辑表达式与的结构。

    根任务表达成各个自信息元素的集合。是对任务树的一种抽象,信息要素之间的关系表达更为简单明了。

    买飞机票的任务树转换成逻辑表达式

     

    5状态图和逻辑表达式混合使用

    对于简单的提问 例如谢谢 再见等可用有限状态机来进行表示,而对于复杂的提问。可建立对应的任务树或者逻辑表达式进行信息条件填充,查询和应答。

     

    展开全文
  • 主要介绍了口语对话系统中对话管理的作用、基本问题和设计方法。对话管理在整个对话系统中处于核心地位,控制整个对话的进行,负责对用户输入的理解以及根据领域内容决定系统对用户的反应。对话管理的设计主要有基于...
  • 多轮对话之对话管理(Dialog Management)

    千次阅读 2019-05-16 15:55:37
    多轮对话之对话管理(Dialog Management)徐阿衡人工智能与机器学习工程师​关注她115 人赞同了该文章开始涉猎多轮对话,这一篇想写一写对话管理(Dialog Management),感觉是个很庞大的工程,涉及的知识又多又杂,在...

    多轮对话之对话管理(Dialog Management)

    115 人赞同了该文章

    开始涉猎多轮对话,这一篇想写一写对话管理(Dialog Management),感觉是个很庞大的工程,涉及的知识又多又杂,在这里只好挑重点做一个引导性的介绍,后续会逐个以单篇形式展开。

    放一张多轮语音对话流程图,理解下 DM 在整个对话流程中处于什么地位。

    简单描述一下这个流程图常见的一种信息流动方式,首先是语音识别 ASR,产生语音识别结果也就是用户话语 u_u ;语义解析模块 NLU 将 u_u 映射成用户对话行为 a_u;对话管理模块 DM 选择需要执行的系统行为a_m;如果这个系统行为需要和用户交互,那么语言生成模块 NLG 会被触发,生成自然语言或者说是系统话语 u_m;最后,生成的语言由语音合成模块 TTS 朗读给用户听。

    这一篇第一部分介绍下对话管理及重要的几个小知识点,第二部分介绍对话管理的一些方法,主要有三大类:

    • Structure-based Approaches
      • Key phrase reactive
      • Tree and FSM
    • Principle-based Approaches
      • Frame
      • Information-State
      • Plan
    • Statistical Approaches
      • 这一类其实和上面两类有交叉…不过重点想提的是:
      • Reinforcement Learning

    方法不等于模型,这里只介绍一些重要概念,不会涉及模型细节。

    Dialog Management

    对话管理(Dialog Management, DM)控制着人机对话的过程,DM 根据对话历史信息,决定此刻对用户的反应。最常见的应用还是任务驱动的多轮对话,用户带着明确的目的如订餐、订票等,用户需求比较复杂,有很多限制条件,可能需要分多轮进行陈述,一方面,用户在对话过程中可以不断修改或完善自己的需求,另一方面,当用户的陈述的需求不够具体或明确的时候,机器也可以通过询问、澄清或确认来帮助用户找到满意的结果。

    总的来说,对话管理的任务大致有下面一些:

    • 对话状态维护(dialog state tracking, DST)
      维护 & 更新对话状态
      t+1 时刻的对话状态 s_{t+1},依赖于之前时刻 t 的状态 s_t,和之前时刻 t 的系统行为 a_t,以及当前时刻 t+1 对应的用户行为 o_{t+1}。可以写成 s_{t+1} \leftarrow s_t+a_t+o_{t+1}
    • 生成系统决策(dialog policy)
      根据 DST 中的对话状态(DS),产生系统行为(dialog act),决定下一步做什么
      dialog act 可以表示观测到的用户输入(用户输入 -> DA,就是 NLU 的过程),以及系统的反馈行为(DA -> 系统反馈,就是 NLG 的过程)
      DA 的具体介绍将在 NLU 系列中展开
    • 作为接口与后端/任务模型进行交互
    • 提供语义表达的期望值(expectations for interpretation)
      interpretation: 用户输入的 internal representation,包括 speech recognition 和 parsing/semantic representation 的结果

    本质上,任务驱动的对话管理实际就是一个决策过程,系统在对话过程中不断根据当前状态决定下一步应该采取的最优动作(如:提供结果,询问特定限制条件,澄清或确认需求…)从而最有效的辅助用户完成信息或服务获取的任务。


    如图,DM 的输入就是用户输入的语义表达(或者说是用户行为,是 NLU 的输出)和当前对话状态,输出就是下一步的系统行为和更新的对话状态。这是一个循环往复不断流转直至完成任务的过程,其中,语义输入就是流转的动力,DM 的限制条件(即通过每个节点需要补充的信息/付出的代价)就是阻力,输入携带的语义信息越多,动力就越强;完成任务需要的信息越多,阻力就越强。

    一个例子

    实际上,DM 可能有更广泛的职责,比如融合更多的信息(业务+上下文),进行第三方服务的请求和结果处理等等。

    Initiative

    对话引擎根据对话按对话由谁主导可以分为三种类型:

    • 系统主导
      系统询问用户信息,用户回答,最终达到目标
    • 用户主导
      用户主动提出问题或者诉求,系统回答问题或者满足用户的诉求
    • 混合
      用户和系统在不同时刻交替主导对话过程,最终达到目标
      有两种类型,一是用户/系统转移任何时候都可以主导权,这种比较困难,二是根据 prompt type 来实现主导权的移交
      Prompts 又分为 open prompt(如 ‘How may I help you‘ 这种,用户可以回复任何内容 )和 directive prompt(如 ‘Say yes to accept call, or no’ 这种,系统限制了用户的回复选择)。

    Basic concepts

    Ground and Repair
    对话是对话双方共同的行为,双方必须不断地建立共同基础(common ground, Stalnaker, 1978),也就是双方都认可的事物的集合。共同基础可以通过听话人依靠(ground)或者确认(acknowledge)说话人的话段来实现。确认行为(acknowledgement)由弱到强的 5 种方法(Clark and Schaefer 1989)有:持续关注(continued attention),相关邻接贡献(relevant next contribution),确认(acknowledgement),表明(demonstration),展示(display)

    听话人可能会提供正向反馈(如确认等行为),也可能提供负向反馈(如拒绝理解/要求重复/要求 rephrase等),甚至是要求反馈(request feedback)。如果听话人也可以对说话人的语段存在疑惑,会发出一个修复请求(request for repair),如

    A: Why is that?
    B: Huh?
    A: Why is that? 

    还有的概念如 speech acts,discourse 这类,之前陆陆续续都介绍过一些了。

    Challenges

    人的复杂性(complex)、随机性(random)和非理性化(illogical)的特点导致对话管理在应用场景下面临着各种各样的问题,包括但不仅限于:

    • 模型描述能力与模型复杂度的权衡
    • 用户对话偏离业务设计的路径
      如系统问用户导航目的地的时候,用户反问了一句某地天气情况
    • 多轮对话的容错性
      如 3 轮对话的场景,用户已经完成 2 轮,第 3 轮由于ASR或者NLU错误,导致前功尽弃,这样用户体验就非常差
    • 多场景的切换和恢复
      绝大多数业务并不是单一场景,场景的切换与恢复即能作为亮点,也能作为容错手段之一
    • 降低交互变更难度,适应业务迅速变化
    • 跨场景信息继承

    Structure-based Approaches

    Key Pharse Reactive Approaches

    本质上就是关键词匹配,通常是通过捕捉用户最后一句话的关键词/关键短语来进行回应,比较知名的两个应用是 ELIZAAIML。AIML (人工智能标记语言),XML 格式,支持 ELIZA 的规则,并且更加灵活,能支持一定的上下文实现简单的多轮对话(利用 that),支持变量,支持按 topic 组织规则等。

    <category>
    <pattern>DO YOU KNOW WHO * IS</pattern> 
    <template><srai>WHO IS <star/></srai></template> 
    </category>
    

    <category>
    <pattern>MOTHER</pattern>
    <template> Tell me more about your family. </template>
    </category>

    <category>
    <pattern>YES</pattern>
    <that>DO YOU LIKE MOVIES</that>
    <template>What is your favorite movie?</template>
    </category>

    附上自己改写的 aiml 地址,在原有基础上增添了一些功能:

    • 支持 python3
    • 支持中文
    • 支持 * 扩展

    Trees and FSM-based Approaches

    Trees and FSM-based approach 通常把对话建模为通过树或者有限状态机(图结构)的路径。 相比于 simple reactive approach,这种方法融合了更多的上下文,能用一组有限的信息交换模板来完成对话的建模。这种方法适用于

    • 系统主导
    • 需要从用户收集特定信息
    • 用户对每个问题的回答在有限集合中

    这里主要讲 FSM,把对话看做是在有限状态内跳转的过程,每个状态都有对应的动作和回复,如果能从开始节点顺利的流转到终止节点,任务就完成了。

    FSM 的状态对应系统问用户的问题,弧线对应将采取的行为,依赖于用户回答。

    FSM-based DM 的特点是:

    • 人为定义对话流程
    • 完全由系统主导,系统问,用户答
    • 答非所问的情况直接忽略
    • 建模简单,能清晰明了的把交互匹配到模型
    • 难以扩展,很容易变得复杂
    • 适用于简单任务,对简单信息获取很友好,难以处理复杂的问题
    • 缺少灵活性,表达能力有限,输入受限,对话结构/流转路径受限

    对特定领域要设计 task-specific FSM,简单的任务 FSM 可以比较轻松的搞定,但稍复杂的问题就困难了,毕竟要考虑对话中的各种可能组合,编写和维护都要细节导向,非常耗时。一旦要扩展 FSM,哪怕只是去 handle 一个新的 observation,都要考虑很多问题。实际中,通常会加入其它机制(如变量等)来扩展 FSM 的表达能力。

    Principle-based Approaches

    Frame-based Approaches

    Frame-based approach 通过允许多条路径更灵活的获得信息的方法扩展了基于 FSM 的方法,它将对话建模成一个填槽的过程,就是多轮对话过程中将初步用户意图转化为明确用户指令所需要补全的信息。一个槽与任务处理中所需要获取的一种信息相对应。槽直接没有顺序,缺什么槽就向用户询问对应的信息。


    Frame-based DM 包含下面一些要素:

    • Frame: 是槽位的集合,定义了需要由用户提供什么信息
    • 对话状态:记录了哪些槽位已经被填充
    • 行为选择:下一步该做什么,填充什么槽位,还是进行何种操作
      行为选择可以按槽位填充/槽位加权填充,或者是利用本体选择

    基于框架/模板的系统本质上是一个生成系统,不同类型的输入激发不同的生成规则,每个生成能够灵活的填入相应的模板。常常用于用户可能采取的行为相对有限、只希望用户在这些行为中进行少许转换的场合。

    Frame-based DM 特点:

    • 用户回答可以包含任何一个片段/全部的槽信息
    • 系统来决定下一个行为
    • 支持混合主导型系统
    • 相对灵活的输入,支持多种输入/多种顺序
    • 适用于相对复杂的信息获取
    • 难以应对更复杂的情境
    • 缺少层次

    槽的更多信息可以参考填槽与多轮对话 | AI产品经理需要了解的AI技术概念

    Agenda + Frame(CMU Communicator)

    Agenda + Frame(CMU Communicator) 对 frame model 进行了改进,有了层次结构,能应对更复杂的信息获取,支持话题切换、回退、退出。主要要素如下:

    • product
      树的结构,能够反映为完成这个任务需要的所有信息的顺序
      相比于普通的 Tree and FSM approach,这里产品树(product tree)的创新在于它是动态的,可以在 session 中对树进行一系列操作比如加一个子树或者挪动子树
    • process
      • agenda
        相当于任务的计划(plan)
        类似栈的结构(generalization of stack)
        是话题的有序列表(ordered list of topics)
        是 handler 的有序列表(list of handlers),handler 有优先级
      • handler
        产品树上的每个节点对应一个 handler,一个 handler 封装了一个 information item

    从 product tree 从左到右、深度优先遍历生成 agenda 的顺序。当用户输入时,系统按照 agenda 中的顺序调用每个 handler,每个 handler 尝试解释并回应用户输入。handler 捕获到信息就把信息标记为 consumed,这保证了一个 information item 只能被一个 handler 消费。

    input pass 完成后,如果用户输入不会直接导致特定的 handler 生成问题,那么系统将会进入 output pass,每个 handler 都有机会产生自己的 prompt(例如,departure date handler 可以要求用户出发日期)。

    可以从 handler 返回代码中确定下一步,选择继续 current pass,还是退出 input pass 切换到 output pass,还是退出 current pass 并等待来自用户输入等。handler 也可以通过返回码声明自己为当前焦点(focus),这样这个 handler 就被提升到 agenda 的顶端。为了保留特定主题的上下文,这里使用 sub-tree promotion 的方法,handler 首先被提升到兄弟节点中最左边的节点,父节点同样以此方式提升。


    系统还能处理产品树中节点之间的依赖关系。典型的依赖关系在父节点和子节点之间。通常父节点的值取决于其子节点。每个节点都维护一个依赖节点的列表,并且会通知依赖节点值的变化,然后依赖节点可以声明自己是无效的并成为当前对话的候选主题。

    给一个例子,能够回应用户的显式/隐式话题转移(A1-A3, U11),也能够动态添加子树到现有的 agenda(A8-A10)。

    具体还是看论文吧
    AN AGENDA-BASED DIALOG MANAGEMENT ARCHITECTURE FOR SPOKEN LANGUAGE SYSTEMS

    Information-State Approaches

    Information State Theories 提出的背景是:

    • 很难去评估各种 DM 系统
    • 理论和实践模型存在很大的 gap
      理论型模型有:logic-based, BDI, plan-based, attention/intention
      实践中模型大多数是 finite-state 或者 frame-based
      即使从理论模型出发,也有很多种实现方法

    因此,Information State Models 作为对话建模的形式化理论,为工程化实现提供了理论指导,也为改进当前对话系统提供了大的方向。Information-state theory 的关键是识别对话中流转信息的 relevant aspects,以及这些成分是怎么被更新的,更新过程又是怎么被控制的。idea 其实比较简单,不过执行很复杂罢了。理论架构如下:

    介绍下简单的一些要素
    Statics

    • Informational components
      包括上下文、内部驱动因子(internal motivating factors)
      e.g., QUD, common ground, beliefs, intentions, dialogue history, user models, etc.
    • Formal representations
      informational components 的表示
      e.g., lists, records, DRSs,…

    Dynamics

    • dialog moves
      会触发更新 information state 的行为的集合
      e.g., speech acts
    • update rules
      更新 information state 的规则集合
      e.g., selection rules
    • update strategy
      更新规则的选择策略,选择在给定时刻选用哪一条 update rules

    意义在于可以遵循这一套理论体系来构建/分析/评价/改进对话系统。基于 information-state 的系统有:

    • TrindiKit Systems
      –  GoDiS (Larsson et al) – information state: Questions Under Discussion
      –  MIDAS – DRS information state, first-order reasoning (Bos &Gabsdil, 2000)
      –  EDIS – PTT Information State, (Matheson et al 2000)
      –  SRI Autoroute –Conversational Game Theory (Lewin 2000)
    • Successor Toolkits
      –  Dipper (Edinburgh)
      –  Midiki (MITRE)
    • Other IS approaches
      –  Soar (USC virtual humans)
      –  AT&T MATCH system

    Plan-based Approaches

    一般指大名鼎鼎的 BDI (Belief, Desire, Intention) 模型。起源于三篇经典论文:

    • Cohen and Perrault 1979
    • Perrault and Allen 1980
    • Allen and Perrault 1980

    基本假设是,一个试图发现信息的行为人,能够利用标准的 plan 找到让听话人告诉说话人该信息的 plan。这就是 Cohen and Perrault 1979 提到的 AI Plan model,Perrault and Allen 1980 和 Allen and Perrault 1980 将 BDI 应用于理解,特别是间接言语语效的理解,本质上是对 Searle 1975 的 speech acts 给出了可计算的形式体系。

    官方描述(Allen and Perrault 1980):

    A has a goal to acquire certain information. This causes him to create a plan that involves asking B a question. B will hopefully possess the sought information. A then executes the plan, and thereby asks B the question. B will now receive the question and attempt to infer A’s plan. In the plan there might be goals that A cannot achieve without assistance. B can accept some of these obstacles as his own goals and create a plan to achieve them. B will then execute his plan and thereby respond to A’s question.

    重要的概念都提到了,goals, actions, plan construction, plan inference。理解上有点绕,简单来说就是 agent 会捕捉对 internal state (beliefs) 有益的信息,然后这个 state 与 agent 当前目标(goals/desires)相结合,再然后计划(plan/intention)就会被选择并执行。对于 communicative agents 而言,plan 的行为就是单个的 speech acts。speech acts 可以是复合(composite)或原子(atomic)的,从而允许 agent 按照计划步骤传达复杂或简单的 conceptual utterance。

    这里简单提一下重要的概念。

    • 信念(Belief)
      基于谓词 KNOW,如果 A 相信 P 为真,那么用 B(A, P) 来表示
    • 期望(Desire)
      基于谓词 WANT,如果 S 希望 P 为真(S 想要实现 P),那么用 WANT(S, P) 来表示,P 可以是一些行为的状态或者实现,W(S, ACT(H)) 表示 S 想让 H 来做 ACT

    Belief 和 WANT 的逻辑都是基于公理。最简单的是基于 action schema。每个 action 都有下面的参数集:

    • 前提(precondition)
      为成功实施该行为必须为真的条件
    • 效果(effect)
      成功实施该行为后变为真的条件
    • 体(body)
      为实施该行为必须达到的部分有序的目标集(partially ordered goal states)

    计划推理(Plan Recognition/Inference, PI):
    根据 B 实施的行为,A 试图去推理 B 的计划的过程。

    • PI.AE Action-Effect Rule(行为-效果规则)
    • PI.PA Precondition-Action Rule(前提-行为规则)
    • PI.BA Body-Action Rule(体-行为规则)
    • PI.KB Know-Desire Rule(知道-期望规则)
    • E1.1 Extended Inference Rule(扩展推理规则)

    计划构建(Plan construction):

    • 找到从当前状态(current state)达到目标状态(goal state)需要的行为序列(sequence of actions)
    • Backward chaining,大抵是说,试图找到一个行为,如果这个行为实施了能够实现这个目标,且它的前提在初始状态已经得到满足,那么计划就完成了,但如果未得到满足,那么会把前提当做新的目标,试图满足前提,直到所有前提都得到满足。(find action with goal as effect then use preconditions of action as new goal, until no unsatisfied preconditions)
      backward chaining 在 NLP 笔记 - Meaning Representation Languages 中提到过。

    还有个重要的概念是 speech acts,在 NLP 笔记 - Discourse Analysis 中提到过,之后会细讲。

    更多见 Plan-based models of dialogue

    值得一提的是,基于 logic 和基于 plan 的方法虽然有更强大更完备的功能,但实际场景中并不常用,大概是因为大部分的系统都是相对简单的单个领域,任务小且具体,并不需要复杂的推理。

    Statistical Approaches

    RL-Based Approaches

    前面提到的很多方法还是需要人工来定规则的(hand-crafted approaches),然而人很难预测所有可能的场景,这种方法也并不能重用,换个任务就需要从头再来。而一般的基于统计的方法又需要大量的数据。再者,对话系统的评估也需要花费很大的代价。这种情况下,强化学习的优势就凸显出来了。RL-Based DM 能够对系统理解用户输入的不确定性进行建模,让算法来自己学习最好的行为序列。首先利用 simulated user 模拟真实用户产生各种各样的行为(捕捉了真实用户行为的丰富性),然后由系统和 simulated user 进行交互,根据 reward function 奖励好的行为,惩罚坏的行为,优化行为序列。由于 simulated user 只用在少量的人机互动语料中训练,并没有大量数据的需求,不过 user simulation 也是个很难的任务就是了。

    对话仿真的整体框架如下图:


    参考链接:
    多轮对话 multi-turn dialog for task-oriented system
    Dialog Management in Bot Framework
    AN AGENDA-BASED DIALOG MANAGEMENT ARCHITECTURE FOR SPOKEN LANGUAGE SYSTEMS
    The Information State Approach to Dialogue Management
    Plan-based models of dialogue
    对话管理的一些思考
    填槽与多轮对话 | AI产品经理需要了解的AI技术概念


    博客: shuang0420.com

    公众号: xu_a_heng

    欢迎关注公众号:
    展开全文
  • 基于层级MDP的对话管理,高明辉,王小捷,对话管理(Dialogue Management,DM)在对话系统(Dialogue System)中扮演着重要角色,将马尔科夫决策过程(Markov Decision Process,MDP)用于对话管
  • 多轮对话之对话管理:Dialog Management

    千次阅读 2018-01-15 00:00:00
    开始涉猎多轮对话,这一篇想写一写对话管理(Dialog Management),感觉是个很庞大的工程,涉及的知识又多又杂,在这里只好挑重点做一个引导性的介绍,后续会逐个以单篇形式展开。 放一张多轮语音对话流程图,理解...
  • 用于情感对话管理的新颖的分解式POMDP模型框架
  • 对一个pipeline任务导向型对话系统来说,最重要的三个模块是自然语言理解、对话管理、自然语言生成,之前已经讨论过自然语言理解,这次就来谈一下对话管理,为了避免翻译上的偏差,接下来部分名词都直接用英语。...
  • 在多轮对话管理中,怎么实现多轮对话的可配置化:比如 只需输入领域意图实体,通过一个流程图就可以实现多轮对话流程? 在你的项目中有考虑这点吗,php不太熟,代码各部分作用...
  • my_multi_dialogue 我的多轮对话管理
  • 1. 对话管理模型背景 从人工智能研究的初期开始,人们就致力于开发高度智能化的人机对话系统。艾伦·图灵(Alan Turing)在 1950 年提出图灵测试 [1],认为如果人类无法区分和他对话交谈的是机器还是人类,那么就...
  • 作者丨戴音培、虞晖华、蒋溢轩、唐呈光、李永彬、孙健单位丨阿里巴巴-达摩院-小蜜Conversational AI团队,康奈尔大学对话管理模型背景从人工智能研究的初期开始,人们就致力于开发...
  • cPanel下FTP对话管理

    2016-05-09 21:36:56
    cPanel下FTP对话管理 作者: Scud 十二月 10, 2013 发表在 文件管理 发表评论 本文将介绍cPanel FTP对话管理。该功能显示登录您FTP服务器的访问者的一般信息,包括账户名称、IP地址、登入时间、...
  • 随着互联网的发展,各大线上平台都拥有大量的用户粉丝,那么用户与商家的会有大量的沟通,尤其在电商平台或者机器人市场有很大的需求,然而人工客服效率低以及成本高,难以满足客户的需求,智能对话是一个必然的趋势...
  • 对话管理的一些思考

    2017-11-28 14:41:51
    写这个文章的目的让更多关注,想要搞,正在搞对话管理(dialogue manager,后面简称DM)的同学尽力少踩坑,至于已经在坑里,甚至从坑里爬起来的人那么来多拍拍砖,甚是欢迎! 基本概念 这个是经典的语音智能交互的图...
  • Rasa Core 聊天机器人对话管理

    万次阅读 2018-01-23 23:24:19
    Rasa Core RasaCore 是一个用来处理对话流程的框架。... ...智能机器人是人工智能一个重大分支,只能机器人包括几大模块:自然语言识别(ASR)、自然语言处理(NLU)、对话管理(DM)、自然语言生成
  • 对话管理模型研究最新进展源于前沿的深度的研究。 作者: 戴音培1、虞晖华2、蒋溢轩2、唐呈光1、李永彬1、孙健1 单位: 阿里巴巴-达摩院-小蜜Conversational AI团队1,康奈尔大学2 对话管理模型背景 从人工...
  • 本篇文章首先基于学习和增加自己的理解,梳理了对话系统中的对话管理的原理,包括是...目录一、对话管理1.对话系统的框架2.对话管理的主要任务二、Bot分发1.领域识别/场景分类2.意图检测3.分发三、技能/Bot处理1....
  • DM Kit作为UNIT的开源对话管理模块,可以无缝对接UNIT的理解能力,并赋予开发者多状态的复杂对话流程管理能力,还可以低成本对接外部知识库,迅速丰富话术信息量。
  • 这一篇是一段时间之前小夕初入对话领域时刷到的徐阿衡小姐姐写的一篇文章,写的深入浅出,十分适合有一定基础的情况下想快速了解对话管理技术的童鞋阅读~另外顺手推一下阿衡小姐姐的订阅号「徐阿衡」...
  • 1.18 对话管理 对话管理功能主要协调聊天机器人的各个部分,并维护对话的结构和状态[9] 。对话管理功能中涉及到的关键技术主要有对话行为识别、对话状态识别、对话策略学习及对话奖励等。 1)对话行为识别:对话行为...
  • 对话管理 mindmeld应用程序管理会话方面 使用基于模式的规则来确定每个传入请求的对话状态 实现执行业务逻辑并向用户返回自然语言响应的处理程序 除了最简单的会话应用程序外,开发对话管理器可能是一项艰巨的任务...
  • 一个基于事务的口语对话管理系统体系结构 ABSTRACT 对话管理可以被用来解决两类具体问题: 1. 提供一个连贯的整体结构来使一轮对话得到扩展和提升。 2. 正确的管理交替主动型的对话行为。(即在对话过程中,既...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,551
精华内容 1,420
关键字:

对话管理