任务驱动的多轮对话的设计参考.docVIP

背景知识介绍 多轮对话之所以称之为多轮对话，而不是多轮问答，是因为除了问答内容外，还有闲聊模式下的情感交流，以及多数情况以陈述句形式表达的情景模式，因此多轮问答实际是多轮对话的子集。由于事件的复杂性直接导致了多轮对话的复杂性，即上文所述的正常的知识问答和命令问答外，还有情感和场景表述，造成每一句与上下文语义高度相关或不相关交错出现，就导致了规则的高度复杂性。 如果用有限状态机来处理多轮对话，就必须对话语权方（即谁说出的话，必须被对方回答，则这方为对话话语权方）的每一个token语句进行意图识别，引入意图队列，对队列进行基于规则的推理机处理或基于深度学习的预测，例如：（寒暄 查订单 确认退款 ? ）正常情况 ？ == 再见结束本轮对话。 当然也可以用seq2seq的方法，将整个对话过程，抽象成一个session。输入若干个相关句子，解码成一个句子，即答案。 多轮交互的一个重点问题是：如何根据上下文理解当前的意图，而不仅仅是针对单轮进行一个分析，从而能够使得对话在一个连续的语境下，是具备session粒度理解能力的。 以下方案，均假设有一个已经做得比较好的单轮理解以后的情况： 尝试方案1： 最简单粗暴地，把多轮query，融合成一个单轮的query，进行一次性的解析. 直接将多轮交互的意图理解问题，转换成一个单轮的意图理解问题，从而复用原有的单轮理解效果。 例如：我想看电影--周星驰演的--喜剧片，三个query合并以后，解析到实际用户的需求，是周星驰主演的喜剧电影。 优点：简单，粗暴，易于实现，几乎服用了单轮解析能力 缺点：简单，粗暴，易于出错，几乎没有任何实质性的多轮解析能力，纯粹靠运气 优化方向：可以加入一些query拼接的限制，提高拼接的准确率，从而在运用到单轮解析能力的同时，不至于在准召上偏离得太离谱（如：只拼接两轮的、三轮及以上拼接，考虑拼接后的意图变化情况等） 尝试方案2： 不是简单拼接，而是结果和query的识别过程拼接： 单轮已经解析出了一个意图和某些槽位，将此意图及槽位存储起来。 遇到query的时候，判定该意图下，这个query能否纳入同样的意图中，抽取出对应的槽位。 如果可以，则更新意图的槽位内容。 如果不可以，则抛弃当前意图，以query作为单轮解析，得到新的意图。 例如：我想看电影--要免费的，第一轮意图为电影，第二轮在电影这个意图下，发现“免费”这个槽位，是符合电影意图描述的，所以，为该意图的槽位新增一个“免费” 例如：我想看爱情电影--能给我讲个笑话吗，第一轮意图为电影，而第二轮在电影这个意图下，发现query并没有任何跟电影相关的槽位信息，所以，抛弃第一轮的电影意图，直接将第二轮query当成单轮的，直接解析得到新的意图--笑话。 优点：基于意图来进行判定，比拼接更准确，也更广泛地识别当前query是否仍在同一个意图中，递归地实现多轮意图解析，避免了拼接过长，拼接过于粗暴带来的误召回和欠召回 缺点：存储下来的是意图和槽位，然后再基于此进行新的query解析，判定是否槽位能够纳入原有意图范围内，这种递归一旦有某一步除了问题，后面的每一步，基本上都挂掉了，解析错误的传播深度和广度，都会很大 优化方向：前面几步，可以辅助以方案一的拼接，来提高意图的正确性，保证后续的方向，都是正确的 尝试方案3： 以对话管理过程中增加一些冗余性来对方案2进行扩充，提高召回率。 多轮交互一旦进入了某个意图，即开始该意图的满足，而当其第一次多轮解析未能命中该意图，也无法命中任何其他意图（纯属闲聊）的时候，可以跳过该轮的意图解析，而继续进入下一轮，检测该意图是否涵盖了当前query中的槽位，是则可以继续该意图的满足，不至于轻易断开多轮对话流（此处的冗余轮数可以根据实际情况自行调整，一轮、两轮均可）。 例如：给我推荐个餐厅--有川菜口味的吗--咦，还蛮多嘛（冗余跳过）--找个最便宜的吧 优点：可以一定程度上缓解方案二递归性带来的意外跳出意图的问题，提高每个意图的服务整体性，保证多轮的延续性。 缺点：因为原理上跟方案二是一致的，所以还是会存在方案二的缺点，并且冗余跳过有可能是未能识别到具体的意图，从而令本该跳出对话的多轮，多停留了一两轮在了当前意图，才能跳出去，会降低交互的智能性。 优化方向：尽可能提升多个意图的覆盖面，从而减少切换意图的误判为聊天，提升冗余的准确性 上述三个方案，都是可以直接通过比较简单的框架设计来实现的，而读者可以发现，可能最关键的还是这些方案的前提：【假设有一个已经做得比较好的单轮理解】。 可以看到，单轮理解是所有意图识别的基础，只有做好单轮的理解，才可能做好多轮，当然，做好了单轮，不一定就能做好多轮。 对话系统的分类及方法： 按照对话答案的生成方式大致可以分为以下几种： 规则依存系统（Rule-bas