多轮对话之对话管理:Dialog Management

简介:

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

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

简单描述一下这个流程图常见的一种信息流动方式,首先是语音识别 ASR,产生语音识别结果也就是用户话语;语义解析模块 NLU 将映射成用户对话行为;对话管理模块 DM 选择需要执行的系统行为

如果这个系统行为需要和用户交互,那么语言生成模块 NLG 会被触发,生成自然语言或者说是系统话语;最后,生成的语言由语音合成模块 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 根据对话历史信息,决定此刻对用户的反应。最常见的应用还是任务驱动的多轮对话,用户带着明确的目的如订餐、订票等,用户需求比较复杂,有很多限制条件,可能需要分多轮进行陈述。

一方面,用户在对话过程中可以不断修改或完善自己的需求,另一方面,当用户的陈述的需求不够具体或明确的时候,机器也可以通过询问、澄清或确认来帮助用户找到满意的结果。 

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

1. 对话状态维护(dialog state tracking, DST) 

t+1 时刻的对话状态,依赖于之前时刻 t 的状态,和之前时刻 t 的系统行为,以及当前时刻 t+1 对应的用户行为。可以写成

2. 生成系统决策(dialog policy) 

根据 DST 中的对话状态(DS),产生系统行为(dialog act),决定下一步做什么 dialog act 可以表示观测到的用户输入(用户输入 -> DA,就是 NLU 的过程),以及系统的反馈行为(DA -> 系统反馈,就是 NLG 的过程)。

3. 作为接口与后端/任务模型进行交互 

4. 提供语义表达的期望值(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),如:


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

Challenges

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

  • 模型描述能力与模型复杂度的权衡
  • 用户对话偏离业务设计的路径

如系统问用户导航目的地的时候,用户反问了一句某地天气情况。

  • 多轮对话的容错性

如 3 轮对话的场景,用户已经完成 2 轮,第 3 轮由于 ASR 或者 NLU 错误,导致前功尽弃,这样用户体验就非常差。

  • 多场景的切换和恢复

绝大多数业务并不是单一场景,场景的切换与恢复即能作为亮点,也能作为容错手段之一。

  • 降低交互变更难度,适应业务迅速变化
  • 跨场景信息继承

Structure-based Approaches

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>

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

  • 支持 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 特点: 

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

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 [3]

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,大抵是说,试图找到一个行为,如果这个行为实施了能够实现这个目标,且它的前提在初始状态已经得到满足,那么计划就完成了,但如果未得到满足,那么会把前提当做新的目标,试图满足前提,直到所有前提都得到满足。

Backward chaining 详细可参考 NLP 笔记 - Meaning Representation Languages [4]。 

还有个重要的概念是 speech acts,在 NLP 笔记 - Discourse Analysis [5]中提到过,之后会细讲。更多可见 Plan-based models of dialogue [6]

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

Statistical Approaches

RL-Based Approaches

前面提到的很多方法还是需要人工来定规则的(hand-crafted approaches),然而人很难预测所有可能的场景,这种方法也并不能重用,换个任务就需要从头再来。而一般的基于统计的方法又需要大量的数据。再者,对话系统的评估也需要花费很大的代价。

这种情况下,强化学习的优势就凸显出来了。RL-Based DM 能够对系统理解用户输入的不确定性进行建模,让算法来自己学习最好的行为序列。

首先利用 simulated user 模拟真实用户产生各种各样的行为(捕捉了真实用户行为的丰富性),然后由系统和 simulated user 进行交互,根据 reward function 奖励好的行为,惩罚坏的行为,优化行为序列。

由于 simulated user 只用在少量的人机互动语料中训练,并没有大量数据的需求,不过 user simulation 也是个很难的任务就是了。 

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



原文发布时间为:2018-01-15

本文作者:徐阿衡

本文来自云栖社区合作伙伴“PaperWeekly”,了解相关信息可以关注“x”微信公众号

相关文章
|
1月前
|
人工智能 JSON 数据可视化
OpenAI调用接口多轮对话Multi Turn Multi Agent 多轮多角色对话调试和可视化工具Dialogue Visualization
伴随着生成式人工智能技术发展,进2年涌现出大语言模型LLM/Agent系统/AI推理等众多方向的技术项目和论文。其中对话系统,智能体交互是用户通过UX界面和AI系统进行交互,这种交互有时候也是多模态(用户输入文字/语音/图像)等等。在调用OpenAI 的对话接口时候,有时候需要把对话结果打印出来检查是否有bug,JSON数据格式就比较难看出来了,尤其是有多角色的多轮对话。这个时候可以借助一些在线的"对话"可视化的工具 (Online Dialogue Visualization Tool) DeepNLP Dialogue Visualization Tool,方便产品经理,算法研发,学术研究
OpenAI调用接口多轮对话Multi Turn Multi Agent 多轮多角色对话调试和可视化工具Dialogue Visualization
|
2月前
|
人工智能 自然语言处理 搜索推荐
如何让智能客服像真人一样对话?容联七陌揭秘:多Agent大模型
科技云报到原创。 经历了多年的“答非所问”、“一问三不知”,很多人已经厌倦了所谓的“智能客服”。哪怕是技术已经非常成熟、可以模拟真人发音的外呼机器人,也会因为“机感”重而被用户迅速挂机或转向人工客服。 智能客服似乎遇到了一道坎,在理解用户、和用户对话方面,始终无法实现真正的“智能”。然而大模型技术的出现,让智能客服看到了前所未有的曙光——基于大模型特有的生成式技术和智能的涌现,让智能客服越来越逼近人们想象中的样子。 但问题是,仅有大模型就够了吗?大模型技术要如何引入智能客服才能落地?落地后的大模型究竟如何在智能客服具体场景中发挥作用?又能为客服行业带来了哪些改变?更进一步,对于企业和
198 1
如何让智能客服像真人一样对话?容联七陌揭秘:多Agent大模型
|
1月前
|
人工智能
Agent应用对话情感优化
【10月更文挑战第2天】
39 0
Agent应用对话情感优化
|
2月前
|
自然语言处理 Python
【Prompt Engineering提示:Active-Prompt、方向性刺激提示、PAL(程序辅助语言模型)】
Diao等人(2023)提出了一种名为Active-Prompt的新方法,通过自适应提示来优化大型语言模型(LLMs)在特定任务中的表现。此方法通过不确定性评估选择需标注的问题,利用少量人工标注的思维链(CoT)示例逐步优化模型,提高其解决问题的能力。相比固定范例,Active-Prompt能够更有效地针对不同任务调整提示,从而提升模型性能。
【Prompt Engineering提示:Active-Prompt、方向性刺激提示、PAL(程序辅助语言模型)】
|
2月前
|
人工智能 搜索推荐 UED
Bot 商店 + 一键优化提示词 Prompt,开启AI新体验!| Botnow上新
Botnow 迎来了重大更新,新增了 Bot 商店功能,并优化了 Bot 编排,提升了 AI 使用效率。用户可在 Bot 商店中轻松浏览和体验各类官方及用户发布的 Bots,并可一键发布或下架自己的 Bot。此外,还推出了一键优化 Prompt 功能,帮助用户生成清晰、精准的指令,提升对话质量。新老用户快来体验吧![链接]
112 4
|
3月前
|
机器学习/深度学习 自然语言处理 vr&ar
ICML 2024:复杂组合3D场景生成,LLMs对话式3D可控生成编辑框架来了
【8月更文挑战第24天】近年来,3D内容生成技术为虚拟现实和游戏领域带来革新,但仍面临处理复杂场景和多对象交互的挑战。为此,研究者提出了Layout-guided Gaussian Splatting (LGS)框架,结合大型语言模型(LLMs)和扩散模型,实现高质量3D场景生成。LGS通过LLMs提取文本描述中的实例关系并转化为布局,再使用扩散模型和自适应几何控制技术优化3D高斯表示,生成更准确、细腻的场景。实验表明,LGS在复杂场景生成方面表现优异,但计算成本和训练时间较长,且主要针对静态场景。论文详情参见:https://arxiv.org/pdf/2402.07207
50 3
|
3月前
|
自然语言处理 机器人 API
【Azure 机器人】微软Azure Bot 编辑器系列(3) : 机器人对话流中加入帮助和取消按钮功能 (The Bot Framework Composer tutorials)
【Azure 机器人】微软Azure Bot 编辑器系列(3) : 机器人对话流中加入帮助和取消按钮功能 (The Bot Framework Composer tutorials)
|
4月前
|
人工智能
魔搭多模态AI单词助记&通义APP即时口语练习,你从未体验过的全新版本!
首次接触魔搭多模态AI单词助记工具让我颇感惊喜。传统背单词方式枯燥低效,而该工具通过生成关联图像、短语或故事,让记忆变得生动有趣。访问[Word-wizard](https://modelscope.cn/studios/makabakaing/Word-wizard)体验其图文记忆和视觉学习功能。目前图文记忆功能似乎存在问题,但视觉学习功能仍可正常使用,能识别图片特征并生成释义和例句,辅助学习效果不错。此外,可通过通义APP实现即时口语练习,尽管缺乏上下文记忆功能,但仍是一个优秀的练习工具。
|
3月前
|
存储 JSON 机器人
【Azure 机器人】微软Azure Bot 编辑器系列(2) : 机器人/用户提问回答模式,机器人从API获取响应并组织答案 (The Bot Framework Composer tutorials)
【Azure 机器人】微软Azure Bot 编辑器系列(2) : 机器人/用户提问回答模式,机器人从API获取响应并组织答案 (The Bot Framework Composer tutorials)
|
5月前
|
语音技术 开发者
ChatTTS:专为对话场景设计的文本转语音模型,底模开源!
最近,开源社区杀出一匹文本转语音领域的黑马——ChatTTS,在Github上仅4天斩获11.2k star。
ChatTTS:专为对话场景设计的文本转语音模型,底模开源!