CN112214589B - 一种基于冷启动的多轮会话框架的方法 - Google Patents

Abstract

本发明公开了一种基于冷启动的多轮会话框架的方法，其特征在于，包括对本体进行设置、话题追踪器、对话流管理、自然语言理解、对话状态追踪、策略动作、自然语言生成，步骤1，本体设置；所述本体的设置内容包括话题、意图、槽位及其上述三者的触发规则和机器人回答话术；步骤2，话题追踪器；采用预训练文本分类模型判断用户提问的类型，话题追踪器作为门控仅允许任务型提问进入后续多轮会话流程；步骤3，对话流管理；将任务型提问依次进行自然语言理解、对话状态追踪、策略动作和自然语言生成的处理，生成系统回答发送至用户。本发明能满足无训练语料直接冷启动多轮智能会话机器人的需求，本体设置实现可插拔的，即配即用的多轮任务型对话功能。

Description

一种基于冷启动的多轮会话框架的方法

技术领域

本发明涉及智能会话系统领域，具体涉及一种基于冷启动的多轮会话框架的方法。

背景技术

随着AI技术的发展，智能会话技术得到大力发展。任务型的多轮会话是一种能基于特定领域任务与用户进行多轮交流会话的技术。通常多轮会话系统由一个管道结构实现。用户提问utterance通过自然语言理解NLU、对话状态追踪DST、策略动作POLICY和自然语言生成NLG的管道结构依次进行处理，得到系统回复。NLU是自然语言理解模块，用于理解用户的意图和槽位；DST对话状态追踪和POLICY策略学习模块对用户的状态以及系统采取的策略进行学习；NLG用于生成自然的系统回答。这些模块均可由深度学习模型进行学习实现，也可以由规则进行实现，但在实际运用中，因为不同领域的任务型会话系统均需要配置与不同领域、意图相关的槽位和管道结构模型或方法，仅有单一管道结构不足以满足商业多轮会话业务对于即配即用的需求，很难在无语料情况下进行冷启动。

专利申请文件CN202010019770-一种基于专有词纠正和冷启动的多轮对话智能客服系统，涉及有意图识别、槽位识别、多轮会话管理等技术特征，但其存在的问题是槽位识别冷启动是基于词典匹配，如果是数字、日期类型很难穷举所有数字组合，意图识别需要用模型训练，意图是非冷启动的，不能做到完全冷启动。

专利申请文件CN201811202675-一种实现智能对话中对话管理的方法，其中涉及有通过创建对话管理的意图流程和意图结构，优化词槽抽取流程，增加意图跳转机制，融合向下文中对话信息，实现对话过程中的意图跳转，词槽抽取与历史信息融合，多轮对话任务，尤其是意图与词槽间的关系及处理办法，但存在的问题是词槽抽取时如果发现多个词槽为空，没有明确对这些词槽提问的顺序，未考虑到在一些任务上词槽需要根据先后顺序依次填入的情况。

专利申请文件CN201910706857-一种智能交互平台训练方法、装置、设备，其中涉及对多用户提供同一冲突的槽位内容的解决方案，但这一冲突本质上是因为用户之间没有进行隔离和并发设计引起的，缺少对多用户交互进行意图槽位状态隔离的考虑。

因此需要一种基于冷启动的多轮会话框架的方法。

发明内容

本发明所要解决的技术问题是克服现有技术的不足，提供一种基于冷启动的多轮会话框架的方法。

为解决上述技术问题，本发明新增一个任务配置模块，负责对不同领域的意图任务进行配置和统一管理。然后对自然语言理解、对话状态追踪、策略动作和自然语言生成的管道结构均定义了通用的解析方法。综上，本发明提供一种基于冷启动的多轮会话框架的方法，包括对本体进行设置、话题追踪器、对话流管理、自然语言理解、对话状态追踪、策略动作、自然语言生成的步骤，具体如下：

步骤1，本体设置；所述本体的设置内容包括话题、意图、槽位及其上述三者的触发规则和机器人回答话术；

步骤2，话题追踪器；采用预训练文本分类模型判断用户提问的类型，所述提问的类型包括问答型、任务型和闲聊型；话题追踪器作为门控仅允许任务型提问进入后续多轮会话流程，同时允许会话在问答型、任务型和闲聊型之间任意跳转；

步骤3，对话流管理；将任务型提问依次进行自然语言理解、对话状态追踪、策略动作和自然语言生成的处理，生成系统回答发送至用户，具体为：

步骤3-1，自然语言理解；自然语言理解基于步骤1中本体设置的意图和槽位的触发规则，从用户提问中抽取意图和槽位，生成用户动作，所述用户动作包括意图、意图概率、告知槽、查询槽，和候选的歧义意图、一值多槽、一槽多值的字段的解析结果；判断用户动作中的意图和槽位有无歧义，无歧义转到步骤3-2，有歧义转到步骤3-c，重新获得无歧义的用户动作后再转到步骤3-2。

步骤3-c,澄清机制；当用户动作中存在歧义意图、一值多槽和一槽多值的槽位歧义时，要求用户从歧义意图和槽位中选择一个确定值，消除歧义后更新用户动作。

步骤3-2，对话状态追踪；内置一个由关键字和值组成的系统状态表，所述关键字来自于本体设置中所有话题、意图、槽位的英文表示，其初始值设为NULL，

利用操作预测器模块解析用户动作，并判断系统状态表中每个关键字对应的操作，所属操作包括“保留”、“删除”、“更新”、“确认”；状态生成器模块根据每个关键字的操作对系统状态表中的关键字的值进行修改；

步骤3-3，策略动作；所述策略动作是根据系统状态表判断当前会话的意图的类型和进度，生成系统动作；所述意图是步骤1中设置的意图，所述系统动作的字段包括类型、候选项、意图、和查询结果；

步骤3-4，自然语言生成；结合系统动作和本体设置中的机器人回答话术生成系统回答；所述步骤1中，所述话题、意图、槽位之间的关系为包含关系：一个话题下包含任意数量个意图，每个意图下包含任意数量个槽位；所述槽位分为告知槽和查询槽，所述查询槽是指用户在某一意图下能够查询到的信息，所述告知槽是指系统完成查询槽时要求用户告知才能完成任务的信息；所述话题的设置内容包括：话题英文表示、话题中文解释、话题触发词、话题触发规则、话题触发时的回答话术和意图；所述话题触发词和话题触发规则是或关系，所述或关系是指当用户提问包含任意一个触发词或者符合任意一个触发规则，即启动话题触发时的回答话术对用户进行回复；所述话题触发时的回答话术是指设定若干条回答话术用于提示用户在该话题下可进行的意图会话，所述意图的设置包括意图英文表示、意图中文解释、意图触发词、意图触发规则、告知槽、告知槽填充关系、查询槽、意图回答话术。所述意图触发词和意图触发规则两者是或关系。所述告知槽包括对任意数量个槽位进行设置，每个槽位设置包括槽位英文表示、槽位中文解释、槽位提取规则、槽位询问话术。所述告知槽填充关系是指：设置当完成某一意图时要求用户对告知槽完成填充的数量以及填充时槽位应遵循的顺序。设置查询天气意图的告知槽是城市、区域和日期三个槽位，用户告知“城市和日期”或者“区域和日期”系统即可完成查询天气意图，则告知槽填充关系可设置为“城市+日期”与“区域+日期”的“或关系”；ORDER标记代表按照顺序填充，如“城市+日期+ORDER”或“区域+日期+ORDER”代表要求用户先告知城市或区域后告知日期。所述查询槽包括对任意数量个槽位进行设置，每个槽位设置包括槽位英文表示、槽位中文解释、槽位触发词。所述意图回答话术是指对不同类型的意图进度设置不同的回答话术，所述意图进度包括三种类型：启动态、进行态、完成态。意图回答话术要求对启动态和完成态两种意图进度设置回答话术，进行态的回答话术在所述告知槽的槽位询问话术中已进行定义。所述启动态的回答话术是指：当根据触发词或触发规则匹配到某一意图时，引导用户填充告知槽。所述完成态的回答话术指：设置告知用户查询槽信息时的回答话术。

所述步骤2中，所述分类的具体判定方法是：文本分类模型分别预测用户提问的类型的概率，概率的最大值所对应的类型即为用户提问所属会话类型；当用户提问被分类为问答型，交由单轮问答模型进行处理，当用户提问被分类为闲聊型，交由闲聊模型处理，当用户提问被分类为任务型，交由多轮会话框架中的对话流管理模型进行处理。

所述步骤3中，所述对话流管理还包括：对当前轮的用户动作、系统状态表、系统动作进行暂存，所述步骤3-c中，要求用户从歧义意图和槽位中选择一个确定值，消除歧义后更新用户动作具体为：主动发起一轮对用户的询问，让用户从多个歧义意图或歧义槽位中选择确定的一个意图或槽位，当用户完成选择后，将确定的意图或槽位在用户动作中进行更新，以便自然语言理解、对话状态追踪、策略动作具备结合前一轮上下文语境进行更准确的解析。

所述步骤3-1中，所述自然语言理解从用户提问中解析得到用户动作的步骤包括：

步骤3-1-1，基于本体设置文件获取所有意图的触发词和触发条件，判断用户提问是否触发意图，若仅触发一个意图，则在用户动作中设置该意图概率为1.若并无触发任何意图，则默认继承前一轮用户动作中暂存的意图和意图概率，若触发多个意图则设置为候选的歧义意图，意图概率为1与歧义意图数量的比值；

步骤3-1-2，若用户动作中的意图概率大于0.5，解析告知槽的值，基于步骤1中设置的告知槽触发规则进行抽取，根据触发规则发现某个槽位匹配到多个值时，设置到一槽多值字段；若某个词语符合多个槽位的触发规则，设置到一值多槽字段；若某个槽位仅匹配到一个值则填入告知槽。

步骤3-1-3，判断用户中是否含有查询槽的触发词，若有则填充至用户查询槽。

所述步骤3-2中，所述系统状态表还包括一个ambiguity标记，所述ambiguity标记代表当前意图模糊；在未更新前，所述系统状态表全部继承前一轮系统状态表；所述更新的具体步骤包括：操作预测器判断系统状态表中每个槽位的操作默认每个槽位是“保留”类型，根据不同情况对满足条件的槽位进行操作修改，具体包括：

Case1:用户动作中的意图概率小于0.5,操作的ambiguity标记为True；

Case2:将用户动作中的意图在操作中设置为“确认”；判断用户动作中的查询槽是否为空，若为空，对于该意图下的所有查询槽的操作设置为“确认”；若不为空，则只设置系统动作中存在的查询槽对应操作为“确认”；这一步的含义是如果用户未指名想要查询特定槽位即查询槽为空，系统将默认用户想查询该意图下所有查询槽信息；如果用户指定了其中若干槽位即查询槽不为空，系统将只查询指定槽位。

Case3:判断前一轮系统状态表中保存的非空告知槽和值是否符合在当前用户动作的告知槽中被其他值覆盖或者值为空两种情况。若被覆盖则将对应槽位操作设置为“更新”，若值为空则设置操作为“删除”。

Case4:前一轮系统状态表查询槽与当前的用户动作中查询槽不一致，将不一致的查询槽的操作设置为“删除”；

状态生成器将操作转换为系统状态表中的值：对于系统状态表中的每一个槽，若操作中的ambiguity为True，设置系统状态表中ambiguity也为True；若操作为“更新”,设置槽位的值为用户动作中对应告知槽的值；若操作为“删除”，设置槽位的值为NULL；若操作为“确认”，设置槽位的值为“YES”。

所述步骤3-3中，将系统状态表解析成系统动作；具体转换规则包括：

1，设置系统动作的意图为系统状态表中标记为YES的意图；

2，系统状态表中ambiguity为True，设置系统动作的类型为ambiguity，意味着系统采取的策略是返回系统内置的意图模糊时的回答模板；

3，对于所有已填告知槽，若步骤1中，告知槽填充关系定义的任一条件被满足，设置类型为“finish”，代表意图进度为“完成态”；有部分槽位填充但没有完全满足告知槽填充关系,代表意图进度为“进行态”，并根据告知槽填充关系是否存在ORDER标记，存在ORDER标记则将类型设置为“running_order”，否则设置为“running_disorder”。若槽位无一填充，代表意图进度为“启动态”，根据有无ORDER标记将类型设置为“start_order”或“start_disorder”。

4，当类型为running_order时，表明用户需遵循顺序进行槽位填充，设置候选项为告知槽填充关系中未被填入值的第一顺位槽；若类型为running_disorder，设置候选项为告知槽填充关系定义的所有未被填入值的槽；

5，当类型为finish时，完成与具体意图相关的后台执行动作并在查询结果字段中填入结果信息。

所述步骤3-4中，自然语言生成具体为：根据系统动作的类型字段，当类型为ambiguity时，从本体设置中随机筛选一条关于意图模糊时的内置回答；当类型为start_disorder，结合系统动作中的意图字段，从本体设置中该意图的启动态回答话术下随机筛选一条回答；当类型为start_order或running_order时,根据候选项字段的槽位对应的槽位询问话术中随机筛选一条回答；当类型为running_disorder时，根据本体设置中告知槽的英文表示或中文解释生成一条提示，用于引导用户回答候选项中所有槽位；当类型为finish时，将查询结果字段信息和本体设置中意图的完成态回答话术结合起来进行回答。

本发明的有益效果：本体设置可实现可插拔的，即配即用的多轮任务型对话功能。话题追踪器的设置使得能在同一对话系统里整合问答型、任务型、闲聊型对话模块，实现三种对话自由跳转，避免对话类型单一的问题。对话流管理是纯基于规则的，解决了多轮会话模型通常面临的缺乏标注语料的问题，完全实现多轮会话意图识别、槽位抽取冷启动。此外，对话流管理对前一轮对话状态保存的设置，能够实现用户意图和槽位的继承，能够结合上下文理解用户的多轮意图。澄清机制解决了意图歧义、槽位歧义问题，让系统能更准确的理解用户真实意图。

附图说明

图1为本发明的示例性实施例的基于冷启动多轮会话的方法流程图；

图2为本发明的示例性实施例的本体设置说明示意图；

图3为本发明的示例性实施例的本体设置举例示意图。

具体实施方式

下面结合附图和示例性实施例对本发明作进一步的说明：

由于本案大量涉及英文技术术语，现列举所涉及的中英文对照，以明确技术术语的指代：

步骤1所涉中英对照：本体：Ontology，意图：intents，告知槽：inform_slots,查询槽：request_slots,告知槽填充关系：inform_relation，话题、意图和查询槽的触发词：triggles，话题、意图和告知槽触发规则：rule，槽位询问话术：clarify_reply,话题和意图的回答话术：reply,启动态：start,完成态：finish。

步骤2所涉中英对照：话题追踪器：TopicTracker，用户提问：utterance，问答型会话：QA。

步骤3所涉中英对照：自然语言理解模块：NLU，对话状态追踪：DST，策略动作：POLICY，自然语言生成：NLG，澄清机制：Clarify。

步骤3-1所涉中英对照：用户动作：user_action,前一轮用户动作：last_user_action,意图概率：intents_prob,候选的歧义意图：candidate_intents,一值多槽：candidate_slots，一槽多值：candidate_values。

步骤3-2所涉中英对照：系统状态表：state，前一轮系统状态表：last_state，操作预测起：OperatorPredictor,状态生成器：Generator,操作Operator,“保留”：CARRYOVER，“更新”：UPDATE，“删除”：DELETE，“确认”：UPDATE。

步骤3-3所涉中英对照：系统动作：action，类型：Type,候选项：Alternatives,意图：intents，查询结果：query_result，后台执行动作：BackendAction。

本发明新增一个任务配置模块，负责对不同领域的意图任务进行配置和统一管理。然后对自然语言理解、对话状态追踪、策略动作和自然语言生成的管道结构均定义了通用的解析方法。

综上，如图1所示的本发明的一种示例性实施例，提供一种基于冷启动的多轮会话框架的方法，包括对本体进行设置、话题追踪器、对话流管理、自然语言理解、对话状态追踪、策略动作、自然语言生成的步骤，具体如下：

步骤1，本体设置；所述本体的设置内容包括话题、意图、槽位及其上述三者的触发规则和机器人回答话术；

步骤2，话题追踪器；采用预训练文本分类模型判断用户提问的类型，所述提问的类型包括问答型、任务型和闲聊型；话题追踪器作为门控仅允许任务型提问进入后续多轮会话流程，同时允许会话在问答型、任务型和闲聊型之间任意跳转；

所述步骤2中，所述分类的具体判定方法是：文本分类模型分别预测用户提问的类型的概率，概率的最大值所对应的类型即为用户提问所属会话类型；当用户提问被分类为问答型，交由单轮问答模型进行处理，当用户提问被分类为闲聊型，交由闲聊模型处理，当用户提问被分类为任务型，交由多轮会话框架中的对话流管理模型进行处理。

步骤3，对话流管理；将任务型提问依次进行自然语言理解、对话状态追踪、策略动作和自然语言生成的处理，生成系统回答发送至用户，所述步骤3中，所述对话流管理还包括：对当前轮的用户动作、系统状态表、系统动作进行暂存，具体为：

步骤3-1，自然语言理解；自然语言理解基于步骤1中本体设置的意图和槽位的触发规则，从用户提问中抽取意图和槽位，生成用户动作，所述用户动作包括意图、意图概率、告知槽、查询槽，和候选的歧义意图、一值多槽、一槽多值的字段的解析结果；判断用户动作中的意图和槽位有无歧义，无歧义转到步骤3-2，有歧义转到步骤3-c，重新获得无歧义的用户动作后再转到步骤3-2。

所述步骤3-1中，所述自然语言理解从用户提问中解析得到用户动作的步骤包括：

步骤3-1-1，基于本体设置文件获取所有意图的触发词和触发条件，判断用户提问是否触发意图，若仅触发一个意图，则在用户动作中设置该意图概率为1.若并无触发任何意图，则默认继承前一轮用户动作中暂存的意图和意图概率，若触发多个意图则设置为候选的歧义意图，意图概率为1与歧义意图数量的比值；

步骤3-1-2，若用户动作中的意图概率大于0.5，解析告知槽的值，基于步骤1中设置的告知槽触发规则进行抽取，根据触发规则发现某个槽位匹配到多个值时，设置到一槽多值字段；若某个词语符合多个槽位的触发规则，设置到一值多槽字段；若某个槽位仅匹配到一个值则填入告知槽。

步骤3-1-3，判断用户中是否含有查询槽的触发词，若有则填充至用户查询槽。

步骤3-c,澄清机制；当用户动作中存在歧义意图、一值多槽和一槽多值的槽位歧义时，要求用户从歧义意图和槽位中选择一个确定值，消除歧义后更新用户动作。

所述步骤3-c中，要求用户从歧义意图和槽位中选择一个确定值，消除歧义后更新用户动作具体为：主动发起一轮对用户的询问，让用户从多个歧义意图或歧义槽位中选择确定的一个意图或槽位，当用户完成选择后，将确定的意图或槽位在用户动作中进行更新，以便自然语言理解、对话状态追踪、策略动作具备结合前一轮上下文语境进行更准确的解析。

步骤3-2，对话状态追踪；内置一个由关键字和值组成的系统状态表，所述关键字来自于本体设置中所有话题、意图、槽位的英文表示，其初始值设为NULL，

利用操作预测器模块解析用户动作，并判断系统状态表中每个关键字对应的操作，所属操作包括“保留”、“删除”、“更新”、“确认”；状态生成器模块根据每个关键字的操作对系统状态表中的关键字的值进行修改；

所述步骤3-2中，所述系统状态表还包括一个ambiguity标记，所述ambiguity标记代表当前意图模糊；在未更新前，所述系统状态表全部继承前一轮系统状态表；所述更新的具体步骤包括：操作预测器判断系统状态表中每个槽位的操作默认每个槽位是“保留”类型，根据不同情况对满足条件的槽位进行操作修改，具体包括：

Case1:用户动作中的意图概率小于0.5,操作的ambiguity标记为True；

Case2:将用户动作中的意图在操作中设置为“确认”；判断用户动作中的查询槽是否为空，若为空，对于该意图下的所有查询槽的操作设置为“确认”；若不为空，则只设置系统动作中存在的查询槽对应操作为“确认”；这一步的含义是如果用户未指名想要查询特定槽位即查询槽为空，系统将默认用户想查询该意图下所有查询槽信息；如果用户指定了其中若干槽位即查询槽不为空，系统将只查询指定槽位。

Case3:判断前一轮系统状态表中保存的非空告知槽和值是否符合在当前用户动作的告知槽中被其他值覆盖或者值为空两种情况。若被覆盖则将对应槽位操作设置为“更新”，若值为空则设置操作为“删除”。

Case4:前一轮系统状态表查询槽与当前的用户动作中查询槽不一致，将不一致的查询槽的操作设置为“删除”；

状态生成器将操作转换为系统状态表中的值：对于系统状态表中的每一个槽，若操作中的ambiguity为True，设置系统状态表中ambiguity也为True；若操作为“更新”,设置槽位的值为用户动作中对应告知槽的值；若操作为“删除”，设置槽位的值为NULL；若操作为“确认”，设置槽位的值为“YES”。

步骤3-3，策略动作；所述策略动作是根据系统状态表判断当前会话的意图的类型和进度，生成系统动作；所述意图是步骤1中设置的意图，所述系统动作的字段包括类型、候选项、意图、和查询结果；

所述步骤3-3中，将系统状态表解析成系统动作；具体转换规则包括：

1，设置系统动作的意图为系统状态表中标记为YES的意图；

2，系统状态表中ambiguity为True，设置系统动作的类型为ambiguity，意味着系统采取的策略是返回系统内置的意图模糊时的回答模板；

3，对于所有已填告知槽，若步骤1中，告知槽填充关系定义的任一条件被满足，设置类型为“finish”，代表意图进度为“完成态”；有部分槽位填充但没有完全满足告知槽填充关系,代表意图进度为“进行态”，并根据告知槽填充关系是否存在ORDER标记，存在ORDER标记则将类型设置为“running_order”，否则设置为“running_disorder”。若槽位无一填充，代表意图进度为“启动态”，根据有无ORDER标记将类型设置为“start_order”或“start_disorder”。

4，当类型为running_order时，表明用户需遵循顺序进行槽位填充，设置候选项为告知槽填充关系中未被填入值的第一顺位槽；若类型为running_disorder，设置候选项为告知槽填充关系定义的所有未被填入值的槽；

5，当类型为finish时，完成与具体意图相关的后台执行动作并在查询结果字段中填入结果信息。

步骤3-4，自然语言生成；结合系统动作和本体设置中的机器人回答话术生成系统回答；所述步骤1中，所述话题、意图、槽位之间的关系为包含关系：一个话题下包含任意数量个意图，每个意图下包含任意数量个槽位；所述槽位分为告知槽和查询槽，所述查询槽是指用户在某一意图下能够查询到的信息，所述告知槽是指系统完成查询槽时要求用户告知才能完成任务的信息；所述话题的设置内容包括：话题英文表示、话题中文解释、话题触发词、话题触发规则、话题触发时的回答话术和意图；所述话题触发词和话题触发规则是或关系，所述或关系是指当用户提问包含任意一个触发词或者符合任意一个触发规则，即启动话题触发时的回答话术对用户进行回复；所述话题触发时的回答话术是指设定若干条回答话术用于提示用户在该话题下可进行的意图会话，所述意图的设置包括意图英文表示、意图中文解释、意图触发词、意图触发规则、告知槽、告知槽填充关系、查询槽、意图回答话术。所述意图触发词和意图触发规则两者是或关系。所述告知槽包括对任意数量个槽位进行设置，每个槽位设置包括槽位英文表示、槽位中文解释、槽位提取规则、槽位询问话术。所述告知槽填充关系是指：设置当完成某一意图时要求用户对告知槽完成填充的数量以及填充时槽位应遵循的顺序。设置查询天气意图的告知槽是城市、区域和日期三个槽位，用户告知“城市和日期”或者“区域和日期”系统即可完成查询天气意图，则告知槽填充关系可设置为“城市+日期”与“区域+日期”的“或关系”；ORDER标记代表按照顺序填充，如“城市+日期+ORDER”或“区域+日期+ORDER”代表要求用户先告知城市或区域后告知日期。所述查询槽包括对任意数量个槽位进行设置，每个槽位设置包括槽位英文表示、槽位中文解释、槽位触发词。所述意图回答话术是指对不同类型的意图进度设置不同的回答话术，所述意图进度包括三种类型：启动态、进行态、完成态。意图回答话术要求对启动态和完成态两种意图进度设置回答话术，进行态的回答话术在所述告知槽的槽位询问话术中已进行定义。所述启动态的回答话术是指：当根据触发词或触发规则匹配到某一意图时，引导用户填充告知槽。所述完成态的回答话术指：设置告知用户查询槽信息时的回答话术。

所述步骤3-4中，自然语言生成具体为：根据系统动作的类型字段，当类型为ambiguity时，从本体设置中随机筛选一条关于意图模糊时的内置回答；当类型为start_disorder，结合系统动作中的意图字段，从本体设置中该意图的启动态回答话术下随机筛选一条回答；当类型为start_order或running_order时,根据候选项字段的槽位对应的槽位询问话术中随机筛选一条回答；当类型为running_disorder时，根据本体设置中告知槽的英文表示或中文解释生成一条提示，用于引导用户回答候选项中所有槽位；当类型为finish时，将查询结果字段信息和本体设置中意图的完成态回答话术结合起来进行回答。

一种基于冷启动的多轮会话框架的方法的具体实施例，包括：

进行Ontology设置。所述步骤1中设置的具体形式如图2所示。图3是基于出行话题、预定酒店意图的Ontology配置举例。Travel是话题英文表示，出行是话题中文解释，话题触发词包括“旅游”、“出差”、“出游”，话题触发规则可设置为空，话题回答话术用于告知用户在该话题下可进行预订酒店和查询天气两种意图。以预订酒店意图为例，设置意图英文表示为hotel，中文解释为订酒店，意图触发词为“酒店”、“宾馆”或“hotel”，意图触发规则为空。告知槽包括城市city、酒店等级rating、区域district、入住时间time。告知槽填充关系是city+rating+district+time，表明此4个槽位填充完毕时意图达到完成态且不要求用户按照顺序填槽。查询槽是酒店名称name和地址address。Reply中start的设置用于提醒用户告知酒店的城市、等级、区域、入住时间信息，finish设置用于告知用户查询的酒店具体信息。

TopicTracker会话分类模型。用通用大规模问答语料、任务型语料、和闲聊语料训练一个通用的文本分类模型。对每一轮用户输入的utterance均使用TopicTracker判断该话语属于QA、任务型、闲聊型的哪一种类型，判断为任务型时调用对话流管理模块进行回复。该TopicTracker模型的设置可以随时让会话在QA、任务和闲聊之间切换。

对话流管理。对话流管理模块的输入是utterance,输出是系统回答Reply。其内部将utterance从NLU向DST、POLICY和NLG的管道结构依次进行解析，当在NLU模块检测到歧义时，通过澄清机制直接提示用户立即澄清。表格1对对话流管理过程进行进一步说明：

表格1对话流管理过程

S3-1，NLU。该步骤主要进行意图识别和槽位填充，每一轮对话中utterance解析后得到的user_action如表格2所示。User_action的定义见表格2的初始值所设字段，包括intents,intents_prob,inform_slots,request_slots,candidate_intents,candidate_slots,candidate_values等字段。当意图未确定时，user_action等于初始值。当意图有歧义时，设置intents_prob为1/len(candidate_intents)，candidate_intents字段值等于触发的多个意图，供步骤3-c中的澄清机制进行询问。若只触发单个意图时，设置intents_prob＝1。当ontology中inform_slots的rule与utterance相匹配时，通过该rule抽取到的槽位填入inform_slots。如果出现槽位歧义：一值多槽即一个值与多个槽位的规则相匹配，例如在订机票时用户输入南京，既能匹配出发地也能匹配目的地，此时填入candidate_slots＝{南京:[leave_city,arrive_city]}，供澄清机制进行询问。如果出现一槽多值歧义，例如utterance“3星级和5星级”均符合rating的rule，填入candidate_values＝{RATING:[3星级,5星级]}进行后续澄清。

表格2NLU示例

S3-2，DST对话状态追踪,基于user_action和last_state对state进行更新。State是ontology中所有定义的意图和槽位的集合，并包括一个ambiguity标记，代表此时的意图是模糊的。表格3展示了在订酒店和查天气两个意图下的state定义：

表格3State初始值说明

在未更新前state继承last_state的状态。首先OperationPredictor判断State中每个槽位的operator值是CARRYOVER、DELETE、UPDATE或YES。不同情况下operator值的类型如表格4所示。

Case1:user_action中intents值为空，例如用户输入“？？？？”时，设置operator的ambiguity为空。

Case2:user_action中intents_prob>＝0.5时，例如用户输入“我想订酒店”，设置hotel的operator为YES。若用户没有指名想查询酒店名称还是酒店地址，系统认为酒店名称和地址都必须提供给用户，则设置hotel/name和hotel/address的operator为YES。若用户仅提到想查酒店名称，则只设置hotel/name的operator为YES。

Case3:user_action中提取到了inform_slots。判断是否符合下面情况，情况一是inform_slots的槽与last_state中的槽的值存在不一致，例如前一轮用户告知hotel/rating的条件是五星级，当前轮用户修改为4星级，则设置hotel/rating的operator为UPDATE；情况二是last_state中非空的告知槽未在当前inform_slots中出现，例如前一轮用户想查南京明天的天气，当前轮用户告知想遇到南京的酒店，应该删除weather/city和weather/date的状态，因此设置operator为DELETE。

Case4:last_state的意图和查询槽与user_action中intent和request_slot s不一致，例如前一轮用户想查天气，当前轮改为预订酒店。应将last_state中查天气意图和查询槽的operator设为DELETE。

Generator将operator中的对应操作转换为值。若operator为ambiguity，设置state[ambiguity]＝True。若operator为UPDATE,设置state对应的槽位为inform_slots中的值。若operator为DELETE,设置state中的对应槽为NULL,若operator为YES,设置对应槽的state为YES。

表格4Operator示例

S3-3，将state解析成系统策略action。表格5展示了action的定义，包括Type、Alternatives、intents、和query_result四个字段。下面结合表格5中举例说明action在不同条件下应如何取值：

(1)用户提出想订酒店意图，此时state中ambiguity＝False，且intents＝hotel。设置action的intents＝hotel，便于NLG模块调用ontology中hotel的reply进行回答。

(2)用户意图不明确，此时state中ambiguity＝True,设置action的type＝ambiguity，便于NLG模块生成引导用户确认意图的回答。

(3)用户完成订酒店意图的告知槽填充条件，即酒店名称、等级、区域、入住日期全部被填充，action的type设为finish。执行BackendAction获得酒店名称和地址，将结果填入action的query_result中。

(4)用户只提出订酒店，尚未填充一个槽位，此时意图进度为启动态，且inform_relation中无ORDER标记，设置action的Type为start_disorder；设置alternatives的值为inform_relation中定义的槽位，表示待填告知槽为酒店名称、等级、区域和入住日期。便于NLG模块提示用户输入所有alternatives中的槽位信息。

(5)用户告知了酒店名称和酒店等级，但inform_relation中要求的区域和入住日期未告知，此时意图进度是进行态。设置action的Type为running_disorder，设置alternatives的值为区域和入住日期。便于NLG模块提示用户填入未填槽位。

表格5action示例

S3-4，NLG根据action中的intents,Type和ontology中intents对应的reply，生成回答。当action中的Type＝ambiguity时，从ontology中随机筛选一条关于意图模糊时的内置回答，例如“sorry,匹配不到您的意图，您可以进行订酒店和查天气哦”。Type＝start_disorder,从ontology中该意图的start回复下随机筛选一条回答，例如“收到，您想查哪个城市几号的天气呀？”。Type＝start_order或type＝running_order时,根据action中alternatives字段告知槽对应的clarify_reply中随机筛选一条回答，例如规定inform_relation＝[city+date+ORDER]，待填入的第一个槽是city,POLICY模块会在action中定义alternatives＝[city]，此时回答是ontology中city的clarify_reply:“请问您想查询哪个城市的天气？”。Type＝running_disorder时，生成一条提示用户回答action中alternatives字段的未填槽位的回复，例如alternatives＝[city,time]时，回复可以是“订酒店还需知道您的目的城市和入住时间哦”。Type＝finish时，将query_result的查询结果和ontology中意图的finish回复设定结合起来进行回答，例如query_result＝“天气：晴朗”，回复是“查到天气为晴朗哦”。

表格6是一段完整的多轮会话例子，Ontology设置如图3所示，包括订酒店和查天气两个意图。为更好的理解多轮会话框架的机制，表格7展示了对于每一轮会话，对话流管道中NLU、DST、POLICY模块的解析结果。

表格6完整的多轮会话示例

表格7基于多轮会话示例的管道结构内部状态

本发明的有益效果：本体设置可实现可插拔的，即配即用的多轮任务型对话功能。话题追踪器的设置使得能在同一对话系统里整合问答型、任务型、闲聊型对话模块，实现三种对话自由跳转，避免对话类型单一的问题。对话流管理是纯基于规则的，解决了多轮会话模型通常面临的缺乏标注语料的问题，完全实现多轮会话意图识别、槽位抽取冷启动。此外，对话流管理对前一轮对话状态保存的设置，能够实现用户意图和槽位的继承，能够结合上下文理解用户的多轮意图。澄清机制解决了意图歧义、槽位歧义问题，让系统能更准确的理解用户真实意图。

以上实施例不以任何方式限定本发明，凡是对以上实施例以等效变换方式做出的其它改进与应用，都属于本发明的保护范围。

Claims (8)

1.一种基于冷启动的多轮会话框架的方法，其特征在于，包括对本体进行设置、话题追踪器、对话流管理、自然语言理解、对话状态追踪、策略动作、自然语言生成的步骤，具体如下：

步骤1，本体设置；所述本体的设置内容包括话题、意图、槽位及其三者的触发规则和机器人回答话术；

步骤2，话题追踪器；采用预训练文本分类模型判断用户提问的类型，所述提问的类型包括问答型、任务型和闲聊型；话题追踪器作为门控仅允许任务型提问进入后续多轮会话流程，同时允许会话在问答型、任务型和闲聊型之间任意跳转；

步骤3，对话流管理；将任务型提问依次进行自然语言理解、对话状态追踪、策略动作和自然语言生成的处理，生成系统回答发送至用户，具体为：

步骤3-1，自然语言理解；自然语言理解基于步骤1中本体设置的意图和槽位的触发规则，从用户提问中抽取意图和槽位，生成用户动作，所述用户动作包括意图、意图概率、告知槽、查询槽，和候选的歧义意图、一值多槽、一槽多值的字段的解析结果；判断用户动作中的意图和槽位有无歧义，无歧义转到步骤3-2，有歧义转到步骤3-c，重新获得无歧义的用户动作后再转到步骤3-2；

步骤3-c,澄清机制；当用户动作中存在歧义意图、一值多槽和一槽多值的槽位歧义时，要求用户从歧义意图和槽位中选择一个确定值，消除歧义后更新用户动作；

步骤3-2，对话状态追踪；内置一个由关键字和值组成的系统状态表，所述关键字来自于本体设置中所有话题、意图、槽位的英文表示，其初始值设为NULL，

利用操作预测器模块解析用户动作，并判断系统状态表中每个关键字对应的操作，所属操作包括“保留”、“删除”、“更新”、“确认”；状态生成器模块根据每个关键字的操作对系统状态表中的关键字的值进行修改；

步骤3-3，策略动作；所述策略动作是根据系统状态表判断当前会话的意图的类型和进度，生成系统动作；所述意图是步骤1中设置的意图，所述系统动作的字段包括类型、候选项、意图、和查询结果；

步骤3-4，自然语言生成；结合系统动作和本体设置中的机器人回答话术生成系统回答。

2.如权利要求1所述的一种基于冷启动的多轮会话框架的方法，其特征在于：所述步骤1中，所述话题、意图、槽位之间的关系为包含关系：一个话题下包含任意数量个意图，每个意图下包含任意数量个槽位；所述槽位分为告知槽和查询槽，所述查询槽是指用户在某一意图下能够查询到的信息，所述告知槽是指系统完成查询槽时要求用户告知才能完成任务的信息；所述话题的设置内容包括：话题英文表示、话题中文解释、话题触发词、话题触发规则、话题触发时的回答话术和意图；所述话题触发词和话题触发规则是或关系，所述或关系是指当用户提问包含任意一个触发词或者符合任意一个触发规则，即启动话题触发时的回答话术对用户进行回复；所述话题触发时的回答话术是指设定若干条回答话术用于提示用户在该话题下可进行的意图会话，所述意图的设置包括意图英文表示、意图中文解释、意图触发词、意图触发规则、告知槽、告知槽填充关系、查询槽、意图回答话术；所述意图触发词和意图触发规则两者是或关系；所述告知槽包括对任意数量个槽位进行设置，每个槽位设置包括槽位英文表示、槽位中文解释、槽位提取规则、槽位询问话术；所述告知槽填充关系是指：设置当完成某一意图时要求用户对告知槽完成填充的数量以及填充时槽位应遵循的顺序；设置查询天气意图的告知槽是城市、区域和日期三个槽位，所述查询槽包括对任意数量个槽位进行设置，每个槽位设置包括槽位英文表示、槽位中文解释、槽位触发词；所述意图回答话术是指对不同类型的意图进度设置不同的回答话术，所述意图进度包括三种类型：启动态、进行态、完成态；意图回答话术要求对启动态和完成态两种意图进度设置回答话术，进行态的回答话术在所述告知槽的槽位询问话术中已进行定义；所述启动态的回答话术是指：当根据触发词或触发规则匹配到某一意图时，引导用户填充告知槽；所述完成态的回答话术指：设置告知用户查询槽信息时的回答话术。

3.如权利要求2所述的一种基于冷启动的多轮会话框架的方法，其特征在于：所述步骤2中，所述分类的具体判定方法是：文本分类模型分别预测用户提问的类型的概率，概率的最大值所对应的类型即为用户提问所属会话类型；当用户提问被分类为问答型，交由单轮问答模型进行处理，当用户提问被分类为闲聊型，交由闲聊模型处理，当用户提问被分类为任务型，交由多轮会话框架中的对话流管理模型进行处理。

4.如权利要求3所述的一种基于冷启动的多轮会话框架的方法，其特征在于：所述步骤3中，所述对话流管理还包括：对当前轮的用户动作、系统状态表、系统动作进行暂存，所述步骤3-c中，要求用户从歧义意图和槽位中选择一个确定值，消除歧义后更新用户动作具体为：主动发起一轮对用户的询问，让用户从多个歧义意图或歧义槽位中选择确定的一个意图或槽位，当用户完成选择后，将确定的意图或槽位在用户动作中进行更新。

5.如权利要求4所述的一种基于冷启动的多轮会话框架的方法，其特征在于：所述步骤3-1中，所述自然语言理解从用户提问中解析得到用户动作的步骤包括：

步骤3-1-1，基于本体设置文件获取所有意图的触发词和触发条件，判断用户提问是否触发意图，若仅触发一个意图，则在用户动作中设置该意图概率为1.若并无触发任何意图，则默认继承前一轮用户动作中暂存的意图和意图概率，若触发多个意图则设置为候选的歧义意图，意图概率为1与歧义意图数量的比值；

步骤3-1-2，若用户动作中的意图概率大于0.5，解析告知槽的值，基于步骤1中设置的告知槽触发规则进行抽取，根据触发规则发现某个槽位匹配到多个值时，设置到一槽多值字段；若某个词语符合多个槽位的触发规则，设置到一值多槽字段；若某个槽位仅匹配到一个值则填入告知槽；

步骤3-1-3，判断用户中是否含有查询槽的触发词，若有则填充至用户查询槽。

6.如权利要求5所述的一种基于冷启动的多轮会话框架的方法，其特征在于：所述步骤3-2中，所述系统状态表还包括一个ambiguity标记，所述ambiguity标记代表当前意图模糊；在未更新前，所述系统状态表全部继承前一轮系统状态表；所述更新的具体步骤包括：操作预测器判断系统状态表中每个槽位的操作默认每个槽位是“保留”类型，根据不同情况对满足条件的槽位进行操作修改，具体包括：

Case1:用户动作中的意图概率小于0.5,操作的ambiguity标记为True；

Case2:将用户动作中的意图在操作中设置为“确认”；判断用户动作中的查询槽是否为空，若为空，对于该意图下的所有查询槽的操作设置为“确认”；若不为空，则只设置系统动作中存在的查询槽对应操作为“确认”；

Case3:判断前一轮系统状态表中保存的非空告知槽和值是否符合在当前用户动作的告知槽中被其他值覆盖或者值为空两种情况；若被覆盖则将对应槽位操作设置为“更新”，若值为空则设置操作为“删除”；

Case4:前一轮系统状态表查询槽与当前的用户动作中查询槽不一致，将不一致的查询槽的操作设置为“删除”；

状态生成器将操作转换为系统状态表中的值：对于系统状态表中的每一个槽，若操作中的ambiguity为True，设置系统状态表中ambiguity也为True；若操作为“更新”,设置槽位的值为用户动作中对应告知槽的值；若操作为“删除”，设置槽位的值为NULL；若操作为“确认”，设置槽位的值为“YES”。

7.如权利要求6所述的一种基于冷启动的多轮会话框架的方法，其特征在于：所述步骤3-3中，将系统状态表解析成系统动作；具体转换规则包括：

1）设置系统动作的意图为系统状态表中标记为YES的意图；

2）系统状态表中ambiguity为True，设置系统动作的类型为ambiguity，意味着系统采取的策略是返回系统内置的意图模糊时的回答模板；

3）对于所有已填告知槽，若步骤1中，告知槽填充关系定义的任一条件被满足，设置类型为“finish”，代表意图进度为“完成态”；有部分槽位填充但没有完全满足告知槽填充关系,代表意图进度为“进行态”，并根据告知槽填充关系是否存在ORDER标记，存在ORDER标记则将类型设置为“running_order”，否则设置为“running_disorder”；若槽位无一填充，代表意图进度为“启动态”，根据有无ORDER标记将类型设置为“start_order”或“start_disorder”；

4）当类型为running_order时，表明用户需遵循顺序进行槽位填充，设置候选项为告知槽填充关系中未被填入值的第一顺位槽；若类型为running_disorder，设置候选项为告知槽填充关系定义的所有未被填入值的槽；

5）当类型为finish时，完成与具体意图相关的后台执行动作并在查询结果字段中填入结果信息。

8.如权利要求7所述的一种基于冷启动的多轮会话框架的方法，其特征在于：所述步骤3-4中，所述自然语言生成具体为：根据系统动作的类型字段，当类型为ambiguity时，从本体设置中随机筛选一条关于意图模糊时的内置回答；当类型为start_disorder，结合系统动作中的意图字段，从本体设置中该意图的启动态回答话术下随机筛选一条回答；当类型为start_order或running_order时,根据候选项字段的槽位对应的槽位询问话术中随机筛选一条回答；当类型为running_disorder时，根据本体设置中告知槽的英文表示或中文解释生成一条提示，用于引导用户回答候选项中所有槽位；当类型为finish时，将查询结果字段信息和本体设置中意图的完成态回答话术结合起来进行回答。

Images