一种回复问题的方法和设备
技术领域
本申请涉及计算机领域,特别是涉及一种回复问题的方法和设备。
背景技术
现今很多网站或系统都提供在线问答的机器人,用于自动回答用户提出的各种问题。理想状况下,在线服务机器人能极大降低人工客服的数量,从而达到降低服务成本的目的。但目前在线服务机器人能解决的问题有限,通常只能支持一些标准性的问答,而针对用户提出一些稍微带有个性化业务场景的问题,在线服务机器人就很难给出令人满意的回答。
在实现本申请的过程中,发明人发现现有技术至少存在如下问题:
现有技术中,在线机器人的问题解决率比较低,操作相对繁琐且容易出错,浪费用户大量时间,用户的体验较差,并且用户可能会放弃在线机器人的服务,转而求助人工服务,这就失去了在线机器人存在的意义。此外,在线服务机器人给出的答案通常是大段的说明性文字,很难激起用户的阅读兴趣。
发明内容
本申请的目的在于提供一种回复问题的方法和设备,本申请为了提升在线服务机器人的问题解决率,将现有的问题识别技术结合全新的业务场景识别技术以及基于业务场景的话术模板,在用户设备提出个性化业务问题后,向用户设备输出与用户个性化相关的且更具人性化的答案。通过答案质量的提升,来达到提升问题解决率的目的,为此,本申请采用如下技术方案:
一种回复问题的方法,其特征在于,包括以下步骤:
服务器根据用户设备发送的问题信息确定所述问题信息所属的问题类目;
所述服务器根据所述问题类目查找所述用户设备进行的相关业务记录中存在问题的业务记录,并获取所述存在问题的业务的数据记录;
所述服务器根据存在问题的业务记录确定存在问题的业务场景,及其所述业务场景下存在问题的业务步骤;
所述服务器获取所述业务步骤下预设的话术模板;
所述服务器根据所述数据记录与所述话术模板生成所述问题信息的回复信息,并将所述回复信息发送到所述用户设备。
所述服务器根据用户设备发送的问题信息确定所述问题信息所属的问题类目,具体为:
所述服务器对所述问题信息进行分词处理确定关键词;
所述服务器根据所述关键词查询语料库确定所述问题信息所属的问题类目。
在所述服务器根据用户设备发送的问题信息确定所述问题信息所属的问题类目之后,还包括:
所述服务器获取所述用户设备登录会话中的用户信息。
所述服务器根据所述数据记录与所述话术模板生成所述问题信息的回复信息,具体为:
所述服务器将所述数据记录与所述话术模板进行组合渲染生成所述问题信息的回复信息。
所述服务器将所述回复信息发送到所述用户设备之后,还包括:
所述服务器根据所述用户设备的后续操作判断此次回复是否解决了所述用户设备发送的问题信息;
如果没有解决,所述服务器保存此次操作的相关数据,用于完善相关操作和数据。
一种服务器,其特征在于,所述服务器包括:
第一确定模块,用于根据用户设备发送的问题信息确定所述问题信息所属的问题类目;
查询模块,用于根据所述问题类目查找所述用户设备进行的相关业务记录中存在问题的业务记录,并获取所述存在问题的业务的数据记录;
第二确定模块,用于根据存在问题的业务记录确定存在问题的业务场景,及其所述业务场景下存在问题的业务步骤;
第一获取模块,用于获取所述业务步骤下预设的话术模板;
回复模块,用于根据所述数据记录与所述话术模板生成所述问题信息的回复信息,并将所述回复信息发送到所述用户设备。
所述第一确定模块,具体用于:
对所述问题信息进行分词处理确定关键词;
根据所述关键词查询语料库确定所述问题信息所属的问题类目。
所述服务器,还包括:
第二获取模块,在所述第一确定模块根据用户设备发送的问题信息确定所述问题信息所属的问题类目之后,用于获取所述用户设备登录会话中的用户信息。
所述回复模块,具体用于:
将所述数据记录与所述话术模板进行组合渲染生成所述问题信息的回复信息。
所述服务器,还包括:
保存模块,在所述回复模块将所述回复信息发送到所述用户设备之后,用于根据所述用户设备的后续操作判断此次回复是否解决了所述用户设备发送的问题信息;
如果没有解决,所述服务器保存此次操作的相关数据,用于完善相关操作和数据。
与现有技术相比,本申请实施例至少具有以下优点:
本申请首先对用户提出的问题信息进行识别,将问题信息进行分词处理确定关键词,根据已有的问题分类及语料库来判定所述问题信息归属于哪个问题类目下,再结合用户设备在该问题类目下的用户设备进行的相关业务记录中存在问题的业务记录及其数据记录,最终将所述数据记录和所述业务记录下预设的话术模板进行组合,渲染出返回给用户设备的回复,在这个过程中,用户设备的交互界面始终停留在聊天窗口中,无需各种链接跳转或新开页面,最大程度的简化了用户的操作,节省了用户的时间,且接收到的回答不是乏味的说明性文案,而是带有用户自身业务信息的个性化回答,更能吸引用户的注意力,而且问题命中率高,服务过程的问答数据及最终是否解决用户问题的结果需要保存下来,用于衡量和验证业务场景模型的准确性,以及不断完善该模型。
附图说明
图1为本申请实施例中的回复问题的方法流程关系示意图;
图2为本申请实施例中的回复问题的方法流程图;
图3为本申请实施例中的服务器结构构架图;
图4为本申请实施例中的回复问题的方法中业务场景模型结构示意图;
图5为本申请实施例中的回复问题的方法具体实施例的业务场景模型示意图;
图6为本申请实施例中的服务器结构示意图。
具体实施方式
本申请实施例提供的技术方案中,如图1所述示意图,本申请首先对用户设备提出的问题信息进行识别,将用户设备的问题信息进行分词处理确定关键词,根据已有的问题分类及语料库来判定所述问题信息归属于哪个问题类目下,再结合用户设备在该问题类目下的用户设备进行的相关业务记录中存在问题的业务记录及其数据记录,最终将所述数据记录和所述业务记录下预设的话术模板进行组合,渲染出返回给用户设备的回复。
下面将结合本申请中的附图,对本申请中的技术方案进行清楚、完整的描述,显然,所描述的实施例是本申请的一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
如图2所示,为本申请实施例中回复问题的方法流程图,包括以下步骤:
步骤201,服务器根据用户设备发送的问题信息确定所述问题信息所属的问题类目。
所述服务器根据用户设备发送的问题信息确定所述问题信息的问题类目,具体为:
所述服务器对所述问题信息进行分词处理确定关键词;
所述服务器根据所述关键词查询语料库确定所述问题信息的问题类目。
具体的,用户通过用户设备连接服务器中的在线服务系统,通过服务器提供的聊天窗口发送问题信息,服务器在接收到所述问题信息后根据分词技术对所述问题信息进行拆分,确定出停用词和关键词,所述服务器使用关键词在语料库中查询,找到最符合所述关键词所属的问题类目。其中,所述停用词和关键词的确定方法可以根据实际需要进行设定。所述语料库中存储有关键词组成的词组与问题类目的对应关系,所述服务器根据所述关键词就能通过语料库查找到对应的问题类目,例如:关键词:支付宝、提现业务,那么关键词组为:支付宝和提现业务,所述问题类目为:支付宝的提现业务与语料库中的关键词组成的词组为:支付宝和体现业务相对应,所述服务器可以使用关键词在语料库中查询到相应的关键词组成的词组,通过预料库中的关键词组成的词组可以找到对应的问题类目可以为支付宝的提现业务。
在所述服务器根据用户设备发送的问题信息确定所述问题信息所属的问题类目之后,还可以包括:
所述服务器获取所述用户设备登录会话中的用户信息。
所述服务器可以根据所述用户信息查找所述用户设备一段时间内都进行过什么业务。
步骤202,所述服务器根据所述问题类目查找所述用户设备进行的相关业务记录中存在问题的业务记录,并获取所述存在问题的业务的数据记录。
服务器的在线服务系统中存在多个业务系统,同一问题类目可能会出现在不同的业务系统中,因此,在确定出问题类目后需要在不同的业务系统中进行查找所述用户设备进行的相关业务记录中存在问题的业务记录,并获取所述存在问题的业务的数据记录。具体的,如图1所示,在服务器的在线服务系统中的一个业务系统中存在多种业务场景的模型,所述服务器可以根据所述问题类目确定出具体的业务场景,所述服务器在根据所述业务场景获取最近某时间段内对应业务的业务记录,并根据记录的状态识别出这些记录中潜在的问题记录,同时,所述服务器还可以获取这些问题记录的数据记录。
步骤203,所述服务器根据存在问题的业务记录确定存在问题的业务场景,及其所述业务场景下存在问题的业务步骤。
具体的,如图4所示,当确定出存在问题的业务记录后,所述服务器可以确定出所述存在问题的业务记录具体的业务场景的模型,及其所述业务场景模型下的具体业务分类,并且还能确定出具体业务分类下哪个业务状态码(服务器对业务分类下的业务状态进行的编号,例如:当前业务分类下的业务状态有处理中、成功和失败,那么可以为三个状态进行编号分别为1、2、3,其中所述业务状态码1为处理中)出现问题,其中,所述业务状态码为所述业务步骤。
步骤204,所述服务器获取所述业务步骤下预设的话术模板。
具体的,如果一个业务步骤对应有多个场景,并且不同的场景下对应的话术模板是不一样的,所述服务器还要结合相应的数据记录选择出合适的话术模板,如图4所示,例如:当前存在问题的业务步骤为业务状态码1,所述业务状态1下由两个对应的场景,所述服务器根据所述业务的数据记录确定所述业务状态码1具体处于那种场景下,并获该场景下的话术模板,当然,所述服务器也可以获取所述业务状态码1下所有场景对应的话术模板。其中,所述话术模板为预设的,不同场景下预设的话术模板是不一样的,所述话术模板根据具体的场景进行具体设定。在实际应用中,具体采用何种方式进行选择,凡是能够达到相应效果的其他基于本发明技术思路的技术方案也均是属于本发明的保护范围。
步骤205,所述服务器根据所述数据记录与所述话术模板生成所述问题信息的回复信息,并将所述回复信息发送到所述用户设备。
所述服务器根据所述数据记录与所述话术模板生成所述问题信息的回复信息,具体为:
所述服务器将所述数据记录与所述话术模板进行组合渲染生成所述问题信息的回复信息。其中,组合方式和渲染方式可以根据实际需要求进行设定。
所述服务器将所述回复信息发送到所述用户设备之后,还包括:
所述服务器根据所述用户设备的后续操作判断此次回复是否解决了所述用户设备发送的问题信息;
如果没有解决,所述服务器保存此次操作的相关数据,用于完善相关操作和数据。当然所述服务器还可以将确定回复信息过程中的其他相关操作和数据进行保存,以衡量和验证业务场景模型的准确性,以及不断完善该模型。
与现有技术相比,本申请实施例至少具有以下优点:
本申请首先对用户提出的问题信息进行识别,将问题信息进行分词处理确定关键词,根据已有的问题分类及语料库来判定所述问题信息归属于哪个问题类目下,再结合用户设备在该问题类目下的用户设备进行的相关业务记录中存在问题的业务记录及其数据记录,最终将所述数据记录和所述业务记录下预设的话术模板进行组合,渲染出返回给用户设备的回复,在上述过程中,用户设备的交互界面始终停留在聊天窗口中,无需各种链接跳转或新开页面,最大程度的简化了用户的操作,节省了用户的时间,且接收到的回答不是乏味的说明性文案,而是带有用户自身业务信息的个性化回答,更能吸引用户的注意力,而且问题命中率高,服务过程的问答数据及最终是否解决用户问题的结果需要保存下来,用于衡量和验证业务场景模型的准确性,以及不断完善该模型。
为了进一步阐述本申请的技术思想,现结合具体的应用场景,对本申请的技术方案进行说明。所述服务器中的在线服务系统为第三方支付服务器的在线服务器系统,如:支付宝、财付通等,为了描述方便,本申请实施例中具体以支付宝为业务场景模型,以提现业务为业务分类,对本申请所提出的技术方案进行说明,在实际应用中,具体业务场景模型和业务分类的变化并不会影响本申请的保护范围。
基于上述说明,提现是用户经常在支付宝上做的一个业务操作,当用户执行提现操作后,需要经过一段时间的等待提现金额才能从用户的支付宝账号划拨至用户对应的银行卡上,由于银行系统、用户自身等级等诸多因素影响,这段等待时间不是一个固定的时间,期间用户就可能会来咨询支付宝客服这笔提现的到账时间,因此本申请公开了一种回复问题的方法,具体如下:
如图3所示服务器结构构架,所述用户通过用户设备使用在线服务系统的聊天界面向服务器输入问题信息,例如:我的支付宝提现业务何时到账。所述服务器获取所述问题信息,并进行分词处理,例如:分词后的停用词为:我的、何时到账,关键词是:支付宝、提现业务。所述服务器使用关键词在语料库中查询到与这些关键词对应的问题类目,如:根据关键词:支付宝、提现业务,那么关键词的词组为:支付宝和提现业务,所述问题类目为:支付宝的提现业务与语料库中的关键词组:支付宝和体现业务相对应,所述服务器可以使用关键词在语料库中查询到相应的关键词组,通过预料库中的关键词组可以找到对应的问题类目可以为支付宝的提现业务。并且,所述服务器在获取问题信息后,所述服务器还获取用户在服务系统的登录会话中输入的用户信息。
所述服务器根据所述问题类目确定与所述问题类目对应的业务接口,如:根据问题类目为:支付宝的提现业务,找到的业务接口为:支付宝提现业务接口,并根据用户信息调用该用户的近期的相关业务记录,例如:获取24小时之内与支付宝提现业务有关的业务数据记录。在获取近期相关业务数据记录后,确定可能存在问题的业务记录,如:操作没有成功或操作还未完成的业务,并且还要获操作没有成功或操作还未完成的业务的数据记录,所述数据记录可以为用户进行提现操作的结束时间,业务进行的时间,以及用户在进行提现业务时的相关的操作数据等。
在所述服务器确定存在问题业务记录后,还需要确定存在问题的业务场景,及其所述业务场景下存在问题的业务步骤,当所述服务器确定存在问题的业务步骤后,所述服务器还需要获取所述业务步骤下预设的话术模板。
具体的,如图5所示,例如:当前存在问题的业务为支付宝-提现业务出现问题,并且当前的业务步骤分为:处理中、提现成功和提现失败。如果所述业务步骤为提现失败的场景只有银行渠道问题,那么预先为提现失败配置的话术模板为银行系统故障的话术,如果所述业务步骤为处理中的场景有两种,一种是提现申请不足2小时,另一种是提现申请已超过2小时,那么为提现申请不足2小时配置的话术为:告知用户情况正常,耐心等待即可,为提现申请已超过2小时配置的话术为:安慰性说辞。如果出现问题的步骤为提现失败时,所述服务器直接获取该步骤下为其场景分配的话术模板,即服务器获取银行系统故障的话术模板;如果出现问题的步骤为处理中时,所述服务器需要先根据数据记录判断提现申请是否超过两小时,如果超过那么选择的话术模块为:安慰性说辞,如果未超过,那么选择话术模块为:告知用户情况正常,耐心等待即可,当然,所述服务器还可以获取所述步骤中所有的话术模板。
所述服务器根据所述数据记录与所述话术模板组合渲染成所述问题信息的回复信息,并将所述回复信息发送到所述用户设备。
具体为,如果获取的话术模板只有一个时,例如:所述话术为:告知用户情况正常,耐心等待即可,那么,将数据记录和话术组合渲染后的回复信息可以为:尊敬的用户您好,业务正在处理中,请您耐心等待,我们会尽快为您处理,谢谢!当获取的话术模板为多个时,例如:多个话术为:告知用户情况正常,耐心等待即可和安慰性说辞,那么,将数据记录和话术组合渲染后的回复信息,具体为:所述服务器根据数据记录判断提现业务是否超过2小时,如果未超过,那么选择话术模块为:告知用户情况正常,耐心等待即可,如果超过那么选择的话术模块为:安慰性说辞,在确定了话术模板后然后在与数据记录进行组合渲染生成回复信息。
与现有技术相比,本申请实施例至少具有以下优点:
本申请首先对用户提出的问题信息进行识别,将问题信息进行分词处理确定关键词,根据已有的问题分类及语料库来判定所述问题信息归属于哪个问题类目下,再结合用户设备在该问题类目下的用户设备进行的相关业务记录中存在问题的业务记录及其数据记录,最终将所述数据记录和所述业务记录下预设的话术模板进行组合,渲染出返回给用户设备的回复,在这个过程中,用户设备的交互界面始终停留在聊天窗口中,无需各种链接跳转或新开页面,最大程度的简化了用户的操作,节省了用户的时间,且接收到的回答不是乏味的说明性文案,而是带有用户自身业务信息的个性化回答,更能吸引用户的注意力,而且问题命中率高,服务过程的问答数据及最终是否解决用户问题的结果需要保存下来,用于衡量和验证业务场景模型的准确性,以及不断完善该模型。
另外,所述服务器还可以为在用户设备上为用户提供资助的引导式服务,通过历史服务经验沉淀下来的问题类目树来引导用户解决问题;又或是,在用户通过用户设备进入服务器时,所述服务器获取用户设备在登录会话中的用户信息,所述服务器根据所述用户信息获取用户近期的操作记录,根据用户的操作记录来判断用户可能要咨询的问题,并且推荐这些问题的解决方案,以提升用户的体验。
基于与上述方法同样的申请构思,本申请还提出了一种服务器,如图6所述,该设备包括:
第一确定模块61,用于根据用户设备发送的问题信息确定所述问题信息所属的问题类目;
查询模块62,用于根据所述问题类目查找所述用户设备进行的相关业务记录中存在问题的业务记录,并获取所述存在问题的业务的数据记录;
第二确定模块63,用于根据存在问题的业务记录确定存在问题的业务步骤;
第一获取模块64,用于获取所述业务步骤下预设的话术模板;
回复模块65,用于根据所述数据记录与所述话术模板生成所述问题信息的回复信息,并将所述回复信息发送到所述用户设备。
所述第一确定模块,具体用于:
对所述问题信息进行分词处理确定关键词;
根据所述关键词查询语料库确定所述问题信息所属的问题类目。
所述服务器,还包括:
第二获取模块,在所述第一确定模块根据用户设备发送的问题信息确定所述问题信息的问题类目之后,用于获取所述用户设备登录会话中的用户信息。
所述回复模块,具体用于:
将所述数据记录与所述话术模板进行组合渲染生成所述问题信息的回复信息。
所述服务器,还包括:
保存模块,在所述回复模块将所述回复信息发送到所述用户设备之后,用于根据所述用户设备的后续操作判断此次回复是否解决了所述用户设备发送的问题信息;
如果没有解决,所述服务器保存此次操作的相关数据,用于完善相关操作和数据。
具体地,所述服务器还根据指令执行上述实施例所述的回复问题的方法,具体在此不再赘述。
与现有技术相比,本申请实施例至少具有以下优点:
本申请首先对用户提出的问题信息进行识别,将问题信息进行分词处理,去除无意义的停用词保留关键词,根据已有的问题分类及语料库来判定所述问题信息归属于哪个问题类目下,再结合用户设备在该问题类目下的用户设备进行的相关业务记录中存在问题的业务记录及其数据记录,最终将所述数据记录和所述业务记录下预设的话术模板进行组合,渲染出返回给用户设备的回复,在这个过程中,用户设备的交互界面始终停留在聊天窗口中,无需各种链接跳转或新开页面,最大程度的简化了用户的操作,节省了用户的时间,且接收到的回答不是乏味的说明性文案,而是带有用户自身业务信息的个性化回答,更能吸引用户的注意力,而且问题命中率高,服务过程的问答数据及最终是否解决用户问题的结果需要保存下来,用于衡量和验证业务场景模型的准确性,以及不断完善该模型。
本领域技术人员可以理解实施例中的设备中的模块可以按照实施例描述进行分布于实施例的装置中,也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块,也可以进一步拆分成多个子模块。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式提现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台设备设备(可以是手机,个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述的方法。
以上所述仅是本申请的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视本申请的保护范围。
以上公开的仅为本申请的几个具体实施例,但是,本申请并非局限于此,任何本领域的技术人员能思之的变化都应落入本申请的保护范围。