预订车辆的方法、装置、设备以及存储介质转让专利

申请号 : CN202211235946.7

文献号 : CN115293389B

文献日 :

基本信息:

PDF:

法律信息:

相似专利:

发明人 : 戴静

申请人 : 深圳市人马互动科技有限公司

摘要 :

本申请实施例公开了一种预订车辆的方法、装置、设备以及存储介质。其中方法包括:根据第一用户语句识别用户意图;判断所述第一用户语句中是否包含完整的第一预订信息;判断被接送人和用户的人物关系;调用第一打车应用,根据所述第二订车需求为用户预订车辆。本申请实施例可以通过对用户需求信息进行分析,可以更好获取用户接送车意图并根据用户接送车意图主动推荐和预订车辆。

权利要求 :

1.一种预订车辆的方法,其特征在于,应用于打车服务系统中的终端设备,所述打车服务系统包括服务器和所述终端设备,所述服务器与所述终端设备通信连接,所述终端设备设置有人机互动服务引擎,包括:调用所述人机互动服务引擎获取用户输入的第一语音信息,对所述第一语音信息进行语音转文字操作得到第一用户语句,对所述第一用户语句进行意图识别,得到用户意图识别结果为预订车辆;

判断所述第一用户语句中是否包含完整的第一预订信息;

若判断出所述第一用户语句中包含完整的第一预订信息,则分析所述第一用户语句,得到用户的第一订车需求;

若判断出所述第一用户语句中不包含完整的第一预订信息,则向用户询问缺失的第一预订信息,获取第二用户语句,对所述第一用户语句与所述第二用户语句分析得到用户的第一订车需求;

若所述第一用户语句和所述第二用户语句中包含被接送人信息,则分析所述被接送人信息,并判断所述被接送人信息中指代的被接送人与所述用户的第一人物关系在本地存储的人物关系集合中是否为首次出现;

若判断出所述第一人物关系在本地存储的人物关系集合中为首次出现,则将所述第一人物关系存储于所述人物关系集合中;

若判断出所述第一人物关系在本地存储的人物关系集合中不是首次出现,则从所述人物关系集合中获取所述用户与所述被接送人的第一人物关系;

将所述第一订车需求和所述第一人物关系发送给语音服务器,接收所述语音服务器根据所述第一订车需求和所述第一人物关系确定的所述用户的第二订车需求,所述第二订车需求包括出行地点、目的地点和待预订的车辆型号;

调用第一打车应用,根据所述第二订车需求为用户预订车辆。

2.根据权利要求1所述的方法,其特征在于,所述方法还包括:若检测到预订车辆的等待时长大于或等于第一预设时长,则根据所述第二订车需求中包括的出行地点和目的地点,调用导航应用生成导航路线并调用所述导航应用向导航服务器发送获取所述导航路线的道路情况的请求,获取来自所述导航服务器发送的道路情况信息,对所述导航路线的道路拥堵状况进行判断;

若满足以下至少一种情况,则提醒所述用户更改导航路线或提醒所述用户更改所述目的地点预设范围内且不存在拥堵状况的地点作为导航目的地:所述导航路线存在拥堵情况;

预订车辆的出行时间或到达所述目的地点的时间处于早高峰时段或晚高峰时段;

所述目的地点为预设标记过的拥堵热点区域。

3.根据权利要求2所述的方法,其特征在于,所述方法还包括:若检测到预订车辆的等待时长小于第二预设时长,则继续根据所述第二订车需求为所述用户预订车辆;其中,所述第二预设时长在所述预订车辆的等待时长等于所述第一预设时长时开始计时;

若检测到预订车辆的等待时长大于或等于第二预设时长,则提醒用户更换打车应用或扩大待预订的车辆型号范围。

4.根据权利要求3所述的方法,其特征在于,在所述若检测到预订车辆的等待时长大于或等于第二预设时长,则提醒用户更换打车应用或扩大待预订的车辆型号范围之后,还包括:若同时预订到的车辆数目为两辆或两辆以上时,则对所述预订到的车辆进行排序,将排序第一的车辆推荐给用户,其中所述排序由用车价格、用车时间或司机信誉度确定。

5.根据权利要求1‑4任一项所述的方法,其特征在于,所述对所述第一用户语句进行意图识别,得到用户意图识别结果为预订车辆,包括:对所述第一用户语句进行关键词拆解并提取至少两个关键词以及所述关键词之间的语义关系;

根据所述关键词以及所述语义关系确定语义识别结果;

根据所述语义识别结果确定当前为需要预订车辆的场景。

6.根据权利要求5所述的方法,其特征在于,所述判断所述第一用户语句中是否包含完整的第一预订信息,包括:对所述第一用户语句中的关键词根据第一识别条件进行筛选,识别所述第一用户语句中的出行时间、出行地点以及出行人数;

将所述第一用户语句中识别的所述出行时间、出行地点以及出行人数发送给信息服务器;

接收来自所述信息服务器对所述出行时间、出行地点以及出行人数与预设的第一预订信息对应的判断信息;

根据所述判断信息确定所述第一用户语句中是否包含完整的第一预订信息。

7.根据权利要求6所述的方法,其特征在于,所述判断所述被接送人信息中指代的被接送人与所述用户的第一人物关系在本地存储的人物关系集合中是否为首次出现,包括:对所述第一用户语句中的关键词根据第二识别条件进行筛选,识别所述第一语音信息中的指代人物词语,将所述第一用户语句中识别的所述指代人物词语与所述用户关系集合中存储的人物关系进行对应:若所述指代人物词语在所述用户关系集合中寻找不到对应储存的人物关系,则判定所述指代人物词语为首次出现;

若所述指代人物词语在所述用户关系集合中寻找到对应储存的人物关系,则判定所述指代人物词语为非首次出现。

8.一种预订车辆的装置,其特征在于,包括:

接收模块,用于调用人机互动服务引擎获取用户输入的第一语音信息,对所述第一语音信息进行语音转文字操作得到第一用户语句,对所述第一用户语句进行意图识别,得到用户意图识别结果为预订车辆;

第一判断模块,用于判断所述第一用户语句中是否包含完整的第一预订信息;

若判断出所述第一用户语句中包含完整的第一预订信息,则分析所述第一用户语句,得到用户的第一订车需求;

若判断出所述第一用户语句中不包含完整的第一预订信息,则向用户询问缺失的第一预订信息,获取第二用户语句,对所述第一用户语句与所述第二用户语句分析得到用户的第一订车需求;

第二判断模块,用于若所述第一用户语句和所述第二用户语句中包含被接送人信息,则分析所述被接送人信息,并判断所述被接送人信息中指代的被接送人与所述用户的第一人物关系在本地存储的人物关系集合中是否为首次出现;

若判断出所述第一人物关系在本地存储的人物关系集合中为首次出现,则将所述第一人物关系存储于所述人物关系集合中;

若判断出所述第一人物关系在本地存储的人物关系集合中不是首次出现,则从所述人物关系集合中获取所述用户与所述被接送人的第一人物关系;

将所述第一订车需求和所述第一人物关系发送给语音服务器,接收所述语音服务器根据所述第一订车需求和所述第一人物关系确定的所述用户的第二订车需求,所述第二订车需求包括出行地点、目的地点和待预订的车辆型号;

输出模块,用于调用第一打车应用,根据所述第二订车需求为用户预订车辆。

9.一种电子设备,其特征在于,包括:

处理器、存储器和通信接口,其中,所述存储器存储有计算机程序,所述计算机程序被配置由所述处理器执行,所述计算机程序包括用于执行权利要求1‑7中任一项方法中的步骤的指令。

10.一种可读存储介质,其特征在于,包括:

所述可读存储介质存储计算机程序,所述计算机程序使得计算机执行以实现权利要求

1‑7中任一项所述的方法。

说明书 :

预订车辆的方法、装置、设备以及存储介质

技术领域

[0001] 本申请涉及互联网产业的数据处理技术领域,尤其涉及一种预订车辆的方法、装置、设备以及存储介质。

背景技术

[0002] 随着互联网的快速发展以及智能终端的普及,线上预订车辆服务已经成为当下用户出行的主要方式,线上预订车辆服务如今已经形成了一个规模和格局都比较稳定的市场。此外,当前线上预订车辆服务也在快速的被移动互联网和共享经济模式所改造,智能出行服务正在逐渐根据用户需求变得更人性化,比如商务用车服务以及拼车服务等。打车软件出现的目的是让我们的出行更加便捷,未来用户对线上打车服务有着更加多元化的需求,随着各类软件的不断发展,打车软件需要为用户提供更加智能化的服务。
[0003] 当前大多数线上预订车辆服务对用户的需求重视程度仍然不足,当用户需要预定车辆去接送人的时候,可能出现软件对用户具体接车事项不清楚导致用户预定的车辆与实际需求不符合等情况。

发明内容

[0004] 本申请实施例提供了一种推荐和预订车辆的方法、装置、电子设备以及存储介质,通过对用户需求信息进行分析,从而更好地获取用户订车需求并根据用户订车需求主动推荐和预订车辆。
[0005] 第一方面,本申请实施例提供了一种推荐和预订车辆的方法,包括:
[0006] 一种预订车辆的方法,其特征在于,应用于打车服务系统中的终端设备,所述打车服务系统包括服务器和所述终端设备,所述服务器与所述终端设备通信连接,所述终端设备设置有人机互动服务引擎,包括:
[0007] 调用所述人机互动服务引擎获取用户输入的第一语音信息,对所述第一语音信息进行语音转文字操作得到第一用户语句,对所述第一用户语句进行意图识别,得到用户意图识别结果为预订车辆;
[0008] 判断所述第一用户语句中是否包含完整的第一预订信息;
[0009] 若判断出所述第一用户语句中包含完整的第一预订信息,则分析所述第一用户语句,得到用户的第一订车需求;
[0010] 若判断出所述第一用户语句中不包含完整的第一预订信息,则向用户询问缺失的第一预订信息,获取第二用户语句,对所述第一用户语句与第二用户语句分析得到用户的第一订车需求;
[0011] 若所述第一用户语句和所述第二用户语句中包含被接送人信息,则分析所述被接送人信息,并判断所述被接送人信息中指代的被接送人与所述用户的第一人物关系在本地存储的人物关系集合中是否为首次出现;
[0012] 若判断出所述第一人物关系在本地存储的人物关系集合中为首次出现,则将所述第一人物关系存储于所述人物关系集合中;
[0013] 若判断出所述第一人物关系在本地存储的人物关系集合中不是首次出现,则从所述人物关系集合中获取所述用户与所述被接送人的第一人物关系;
[0014] 将所述第一订车需求和所述第一人物关系发送给所述语音服务器,接收所述语音服务器根据所述第一订车需求和所述第一人物关系确定的所述用户的第二订车需求,所述第二订车需求包括出行地点、目的地点和待预订的车辆型号;
[0015] 调用第一打车应用,根据所述第二订车需求为用户预订车辆。
[0016] 第二方面,本申请实施例提供了一种推荐和预订车辆的装置,包括:
[0017] 接收模块,用于调用所述人机互动服务引擎获取用户输入的第一语音信息,对所述第一语音信息进行语音转文字操作得到第一用户语句,对所述第一用户语句进行意图识别,得到用户意图识别结果为预订车辆;
[0018] 第一判断模块,用于判断所述第一用户语句中是否包含完整的第一预订信息;
[0019] 若判断出所述第一用户语句中包含完整的第一预订信息,则分析所述第一用户语句,得到用户的第一订车需求;
[0020] 若判断出所述第一用户语句中不包含完整的第一预订信息,则向用户询问缺失的第一预订信息,获取第二用户语句,对所述第一用户语句与第二用户语句分析得到用户的第一订车需求;
[0021] 第二判断模块,用于若所述第一用户语句和所述第二用户语句中包含被接送人信息,则分析所述被接送人信息,并判断所述被接送人信息中指代的被接送人与所述用户的第一人物关系在本地存储的人物关系集合中是否为首次出现;
[0022] 若判断出所述第一人物关系在本地存储的人物关系集合中为首次出现,则将所述第一人物关系存储于所述人物关系集合中;
[0023] 若判断出所述第一人物关系在本地存储的人物关系集合中不是首次出现,则从所述人物关系集合中获取所述用户与所述被接送人的第一人物关系;
[0024] 将所述第一订车需求和所述第一人物关系发送给所述语音服务器,接收所述语音服务器根据所述第一订车需求和所述第一人物关系确定的所述用户的第二订车需求,所述第二订车需求包括出行地点、目的地点和待预订的车辆型号;
[0025] 输出模块,用于调用第一打车应用,根据所述第二订车需求为用户预订车辆。
[0026] 第三方面,本申请实施例提供了一种电子设备,处理器、存储器和通信接口,其中,所述存储器存储有计算机程序,所述计算机程序被配置由所述处理器执行,所述计算机程序包括用于执行第一方面以及第一方面任意一种实现方式1‑7中任一项方法中的步骤的指令。
[0027] 第四方面,本申请实施例提供了一种可读存储介质,所述可读存储介质存储计算机程序,所述计算机程序使得计算机执行以实现第一方面以及第一方面任意一种实现方式1‑7中任一项所述的方法。
[0028] 实施本申请实施例,将具有如下有益效果:
[0029] 采用上述的一种推荐和预订车辆的方法、装置、电子设备以及可读存储介质,在调用所述人机互动服务引擎获取用户输入的第一语音信息,对所述第一语音信息进行语音转文字操作得到第一用户语句,对所述第一用户语句进行意图识别,得到用户意图识别结果为预订车辆之后,判断所述第一用户语句中是否包含完整的第一预订信息;若判断出所述第一用户语句中包含完整的第一预订信息,则分析所述第一用户语句,得到用户的第一订车需求;若判断出所述第一用户语句中不包含完整的第一预订信息,则向用户询问缺失的第一预订信息,获取第二用户语句,对所述第一用户语句与第二用户语句分析得到用户的第一订车需求。然后,若所述第一用户语句和所述第二用户语句中包含被接送人信息,则分析所述被接送人信息,并判断所述被接送人信息中指代的被接送人与所述用户的第一人物关系在本地存储的人物关系集合中是否为首次出现;若判断出所述第一人物关系在本地存储的人物关系集合中为首次出现,则将所述第一人物关系存储于所述人物关系集合中;若判断出所述第一人物关系在本地存储的人物关系集合中不是首次出现,则从所述人物关系集合中获取所述用户与所述被接送人的第一人物关系;将所述第一订车需求和所述第一人物关系发送给所述语音服务器,接收所述语音服务器根据所述第一订车需求和所述第一人物关系确定的所述用户的第二订车需求,所述第二订车需求包括出行地点、目的地点和待预订的车辆型号。最后,调用第一打车应用,根据所述第二订车需求为用户预订车辆。如此,可以通过对用户需求信息进行分析,可以更好获取用户接送车意图并根据用户接送车意图主动推荐和预订车辆。

附图说明

[0030] 为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以基于这些附图获得其他的附图。其中:
[0031] 图1为本申请实施例提供的一种预订车辆的系统架构示意图;
[0032] 图2为本申请实施例提供的一种预订车辆的方法的流程示意图;
[0033] 图3为本申请实施例提供的一种使用智能手机预订车辆的实例示意图;
[0034] 图4为本申请实施例提供的另一种使用智能手机预订车辆的实例示意图;
[0035] 图5为本申请实施例提供的一种预订车辆的装置的结构示意图;
[0036] 图6为本申请实施例提供的一种预订车辆电子设备的结构示意图。

具体实施方式

[0037] 下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
[0038] 本申请的说明书及所述附图中的术语“第一”、“第二”、“第三”和“第四”等是用于区别不同对象,而不是用于描述特定顺序。此外,术语“包括”和“具有”以及它们任何变形,意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元,而是可选地还包括没有列出的步骤或单元,或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
[0039] 在本文中提及“实施例”意味着,结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例,也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是,本文所描述的实施例可以与其它实施例相结合。
[0040] 还应理解,本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。
[0041] 为了更好地理解本申请实施例的技术方案,先对本申请实施例可能涉及的系统架构进行介绍。请参照图1,本申请实施例提供的一种预订车辆的系统架构示意图,该系统架构可以包括:语音服务器101和终端设备102。其中,终端设备102中的人机互动服务引擎接收用户第一语音信息的方式可以但不仅限于语音输入,也可以采用文字输入等形式;语音服务器101和终端设备102之间可以通过网络通信。网络通信可以基于任何有线和无线网络,包括但不限于因特网、广域网、城域网、局域网、虚拟专用网络(virtual private network,VPN)和无线通信网络等等。
[0042] 需要说明的是,图1所示的系统中的语音服务器101的种类和终端设备102的数量仅用于举例,并不构成对本申请实施例的限定。本申请实施例中并不限定语音服务器101的数目,本申请实施例中的终端设备102可以是智能手机、平板电脑、笔记本电脑等。
[0043] 本申请实施例提供的终端设备102中设置有一种人机互动服务引擎,其核心功能是对用户输入语句进行意图识别,得到意图识别结果,根据意图识别结果,调用对应的服务模块,进行服务执行。
[0044] 此外,该人机互动服务引擎也能够通过其他应用开放的接口调用其他应用或其他应用的服务模块,如调用打车应用的打车服务模块,具体可以通过导航应用的打车接口或者打车应用的打车接口等调用打车服务模块等。
[0045] 终端设备102可以包括显示屏幕,用于显示接收用户输入的信息或显示提供给用户的信息,以及显示终端设备102的各种菜单界面等。显示界面可以有一个也可以有多个,一个显示界面可以显示一个信息识别程序,也可以同时显示多个信息识别程序。
[0046] 需要说明的是,终端设备102还可以包括麦克风、扬声器、听筒、闪光灯、蓝牙、外部接口、按键、各类传感器等其他可能的功能模块。其中,麦克风可以用于接收用户的语音信息,扬声器和听筒可以用于向用户传输语音询问信息。
[0047] 随着互联网的快速发展以及智能终端的普及,线上预订车辆服务已经成为当下用户出行的主要方式,线上预订车辆如今已经形成了一个规模和格局都比较稳定的市场。但是当前大多数预订车辆服务对用户的需求重视程度仍然不足,当用户需要预定车辆去接送人的时候,可能出现用户对具体接车事项等不清楚,用户预定的车辆与实际需求不符合等情况。
[0048] 为了解决上述问题,本申请实施例提供了一种预订车辆的方法。实施该方法,可以通过对用户需求信息进行分析,从而更好地获取用户订车需求并根据用户订车需求主动推荐和预订车辆。
[0049] 请参照图2,图2是本申请实施例提供的一种预订车辆方法的流程示意图。以该方法应用在智能手机终端为例进行举例说明,主要包括步骤S201 S209,其中:~
[0050] 步骤S201:调用所述人机互动服务引擎获取用户输入的第一语音信息,对所述第一语音信息进行语音转文字操作得到第一用户语句,对所述第一用户语句进行意图识别,得到用户意图识别结果为预订车辆。
[0051] 在本申请实施例中,其具体实现过程为用户输入语音信息,系统将该语音信息进行语音转文字操作,得到第一用户语句;若用户直接使用文字输入形式输入系统,则系统直接将用户的输入文字作为第一用户语句。需要额外提及的是,对于所述第一用户信息转化为所述第一用户语句的方法,可以是通过外部语音转换技术方法实现的。
[0052] 在一种可能的实施方式中,步骤S201中所述对所述第一用户语句进行意图识别,得到用户意图识别结果为预订车辆具体可以包括步骤A11‑A13:
[0053] 步骤A11:对所述第一用户语句进行关键词拆解并提取至少两个关键词以及所述关键词之间的语义关系。
[0054] 在本申请实施例中,语义识别引擎对第一用户语句进行拆解,得到多个解析图,每个解析图包括解析节点(单个词语)和每个解析节点关系线;针对每个解析图确定出目标解析节点和对应的解析节点关系线,即得到主原始三元组,每个原始三元组包括原始关联关系(语义关系或语法关系)和两个原始实体,每个原始实体对应一个词语,所述原始关联关系用于表征所述两个原始实体的语义和/或语法关系。
[0055] 例如,用户输入第一用户语句“我需要去机场接客户”,则可以拆解得到“我”、“需要”、“去”、“机场”、“接”、“客户”六个解析节点和五条解析节点关系线,得到该第一需求信息的解析图,其中原始三元组分别为“我‑需要”、“需要‑去”、“去‑机场”、“机场‑接”、“接‑客户”,主原始三元组为“去‑机场”和“接‑客户”(“‑”表示为解析节点关系线)。
[0056] 步骤A12:根据所述关键词以及所述语义关系确定语义识别结果。
[0057] 在本申请实施例中,在步骤A11确定所述主原始三元组之后,根据主原始三元组尝试在知识库的知识图中找到与当前处理的解析图存在匹配关系知识子图,知识图为多个知识子图连接构成,每个知识子图中包括多个知识节点和每个知识节点间的知识节点关系线,即知识图中包括多个目标三元组,每个目标三元组包括目标关联关系和两个目标实体,每个目标实体对应有至少一个词语,所述目标关联关系用于表征所述两个目标实体的语义和/或句法关系;
[0058] 若能够找到,则标记当前处理的解析图为正确语句,确定主原始三元组用于表征用户输入语句的用户意图;例如主原始三元组“去‑机场”可以在知识库的知识图中找到对应匹配的知识子图中的多个目标三元组“去‑某地”;“接‑客户”也可以在知识库的知识图中找到对应匹配的知识子图中的多个目标三元组“接‑某人”;则主原始三元组“去‑机场”和“接‑客户”可以用于表征用户输入语句的用户意图。
[0059] 若不能够找到,则根据知识库对解析图进行想象推理得到概率图,然后将概率图拿到知识图中去进行匹配,看是否能找到知识子图(该知识子图对应相同语义的不同表达方式);
[0060] 若无法找到,则确定没有不同表达方式,为错误语句,丢弃;
[0061] 若能够找到,则确定找到的知识子图对应的三元组为用于表征用户输入语句的用户意图的特征数据。
[0062] 若通过上述方法能找到对应的知识子图,则当前处理的解析图即为正确的解析图,即该解析图中包含的原始三元组可以用于表征用户意图。
[0063] 所述根据知识库对解析图进行想象推理得到概率图,包括:若当前主原始三元组的两个实体分别为(Xa,Xb),则去知识库中寻找与Xa有连接关系,且不与Xb匹配的知识节点,得到Ya,同理得到Yb,因此可以得到拓展图,实体分别为(Ya,Xa)和(Xb,Yb),即得到拓展图;将更新后的拓展图与解析图连接,得到概率图。
[0064] 所述将概率图拿到知识图中去进行匹配,看是否能找到知识子图,包括:假设当前使用的语义识别引擎所关联的知识库的知识图中仅包括知识子图,根据概率图匹配到该知识子图。
[0065] 所述确定找到的知识子图对应的三元组为用于表征用户输入语句的用户意图的特征数据,包括:确定该找到的知识子图所包含的三元组为用于表征用户输入语句的用户意图的特征数据,即用户原始输入语句,通过处理后确定表征该用户意图的语句可以为知识库中预存的另一句,至此完成针对用户原始输入语句的语义识别处理过程。
[0066] 步骤A13:根据所述语义识别结果确定当前为需要预订车辆的场景。
[0067] 在本申请实施例中,步骤A12中已经将主原始三元组“去‑机场”和“接‑客户”分别与知识子图中的“去‑某地”和“接‑某人”成功匹配,获取了输入语句的用户意图,系统根据该主原始三元组“去‑机场”和“接‑某人”即可判定当前为预订车辆场景。
[0068] 步骤S202:判断所述第一用户语句中是否包含完整的第一预订信息。
[0069] 所述第一预订信息包括:出行人数、出行时间和出行地点。
[0070] 在一种可能的实施方式中,步骤S202中所述判断所述第一用户语句中是否包含完整的第一预订信息具体包括:
[0071] 对所述第一用户语句中的关键词根据第一识别条件进行筛选,识别所述第一用户语句中的出行时间、出行地点以及出行人数,将所述第一用户语句中识别的所述出行时间、出行地点以及出行人数发送给信息服务器,之后接收来自信息服务器对所述出行时间、出行地点以及出行人数与预设的第一预订信息对应的判断信息。
[0072] 在本申请实施例中,出行时间信息识别通常采用二十四小时制。
[0073] 若用户输入的第一用户语句中输入的时刻是大于12时且不大于24时的时候,系统则默认采用二十四小时制确定用户用车需求时间,如用户输入“今天13点我需要一辆商务车去机场接客户”,则系统直接识别确认时间为13点,也即下午1点;若用户输入的第一用户语句中输入的时刻是不大于12时的时候,则需要根据判断第一用户语句中是否存在如“上午”、“下午”、“晚上”、“中午”以及“凌晨”等时间段词语,若存在明确指出时间段的词语,则需根据时间段词语和时刻共同识别确认时间并将其转化为二十四小时制进行分析,如用户输入“今天下午1点我需要一辆商务车去机场接客户”,则系统根据“下午”和“1点”共同识别确认时间为13点;若用户输入的第一需求信息中输入的时刻是不大于12时,且语句中不存在其他指明时间段的词语,则不能判定第一用户语句中包含完整时间信息,需要对用户进行询问第一用户语句进行识别判断。
[0074] 需要指出的是,通常第一用户语句中的出行时间信息指的是用户需要预订车辆接取用户本身的时间,而并非是实际接取客户的时间。例如:用户输入“今天下午1点我需要一辆商务车去机场接客户”,这里指的下午1点通常默认为用户需要车辆下午1点这个时刻来到用户打车地点接取用户,之后再随同该车辆前往机场接取客户,而并非指的是客户需要在下午1点直接在机场被车辆接取,这样设定的原因是更符合用户实际语言表达习惯和意图。也存在某种特定情况,如用户本身因为特殊原因无法随同预订车辆前往出行地点接取客户,则也可以采用附加信息的方式向系统输入用户需求,如用户输入“今天下午1点我需要一辆商务车去机场接客户,直接前往机场接取客户不用来接我”,因为存在附加信息所以在进行用户需求判断时需要对附加信息进行共同分析。
[0075] 在本申请实施例中,出行地点信息识别通常根据用户定位所在城市进行判断。
[0076] 根据第一用户语句中提及的地点信息和用户定位所在城市共同识别判断地点的具体位置,如用户输入“今天下午1点我需要一辆商务车去机场接客户”,若用户定位所在城市存在机场且不止一个,则无法判断用户具体需要前往哪一个机场,需要对用户进行询问获取第二用户语句后进行识别判断,也可以直接向用户推送本市所有机场地点供用户手动选择;若用户定位所在城市存在机场有且仅有一个,则可直接识别判断第一需求信息中的地点;若用户定位城市不存在任何一个机场,则需告知用户本城市不存在“机场”这一地点并对用户进行询问获取第二用户语句,也可以直接向用户推送相邻城市的机场供用户手动选择。
[0077] 需要指出的是,所述出行地点信息均指代的是出行目的地点,如第一用户语句中无特别指出出行始发地点信息,则对于出行始发地点通常默认为终端设备定位的位置,在获取用户定位信息前向用户发送获取用户定位信息权限请求,在获取定位信息之后系统默认选择用户定位位置为出行始发地点,若用户特别指出出行始发地点信息,系统则根据用户需求进行识别安排,出行始发地点信息和出行目的地点信息共同存储为第一预订信息中的出行地点信息。
[0078] 所述出行目的地点也同样可以存在多个,如用户输入“今天下午1点我需要一辆商务车去机场接客户去公司”,若用户定位的位置为用户居住地址,则能够判断出用户的出行始发地点为所述用户居住地址,而出行目的第一地点为机场,出行目的第二地点为公司,其中三个地点的出行路线为用户居住地址——机场——公司。
[0079] 在本申请实施例中,出行人数信息识别通常根据第一用户语句中的人数数字和指代人物词语数目共同确定。
[0080] 为了区分人数数字与第一用户语句中可能存在的其他数字,所述人数数字通常识别方法为与该数字前后可能存在的量词(如“人”、“位”、“名”等)进行共同识别。举例:“今天下午1点我需要一辆商务车去机场接三位客户”,其中出现了三个数字“1”、“一”、“三”,其中“1”后接的为“点”可识别为表示时刻数字,“一”后接的为“辆”可识别为表示用车数字,“三”后接的为“位”可识别为表示人数数字,因此确定第一用户语句中的出行人数为包括“我”在内的四人;若是所述被送人情况,则举例:“今天下午1点我需要一辆商务车去机场送三位客户”,其中出现了三个数字“1”、“一”、“三”,其中“1”后接的为“点”可识别为表示时刻数字,“一”后接的为“辆”可识别为表示用车数字,“三”后接的为“位”可识别为表示人数数字,因此确定第一用户语句中的出行人数为包括“我”在内的四人。
[0081] 根据第一预订信息的不同判断情况分别执行如下步骤S203或S204。
[0082] 步骤S203:若判断出所述第一用户语句中包含完整的第一预订信息,则分析所述第一用户语句,得到用户的第一订车需求。
[0083] 获取所述第一用户语句中所述第一预订信息对应的关键词,若所述第一用户语句中包含完整的第一预订信息时,将所述关键词进行组合获得所述第一订车需求。例如,接收用户输入的第一用户语句:“今天下午1点我需要一辆商务车去机场接三位客户”,其中所述第一用户语句中包含“今天下午1点”、“去机场”和“接三位客户”三条关键词,分别对应了所述第一预订信息中的出行时间、出行地点和出行人数,由此可获得所述第一订车需求为“今天下午1点去机场接三位客户”。
[0084] 步骤S204:若判断出所述第一用户语句中不包含完整的第一预订信息,则向用户询问缺失的第一预订信息,获取第二用户语句,对所述第一用户语句与第二用户语句分析得到用户的第一订车需求。
[0085] 获取所述第一用户语句中所述第一预订信息对应的关键词,若所述第一用户语句中不包含完整的第一预订信息时,则在获取了所述第二用户语句之后对所述第二用户语句中的关键词进行提取,之后将所述第一用户语句和所述第二用户语句中的所述第一预订信息对应的关键词进行组合获得所述第一订车需求。例如,接收用户输入的第一用户语句:“今天下午1点我需要一辆商务车去机场接客户”,其中所述第一用户语句中包含“今天下午
1点”和“去机场”“条关键词,分别对应了所述第一预订信息中的出行时间和出行地点,但是并没有关于“出行人数”的信息,因此向用户获取所述第二用户语句:“三位客户”,此时所述第二用户语句中存在关键词“三位用户”,对应了所述第一预订信息中的出行人数,之后将所述第一用户语句中的关键词“今天下午1点”、“去机场”以及所述第二用户语句中的关键词“三位客户”进行组合,由此可获得所述第一订车需求为“今天下午1点去机场接三位客户”。
[0086] 步骤S205:若所述第一用户语句和所述第二用户语句中包含被接送人信息,则分析所述被接送人信息,并判断所述被接送人信息中指代的被接送人与所述用户的第一人物关系在本地存储的人物关系集合中是否为首次出现。
[0087] 在一种可能的实施方式中,步骤S205中所述判断所述被接送人信息中指代的被接送人与所述用户的第一人物关系在本地存储的人物关系集合中是否为首次出现具体可以包括如下步骤:
[0088] 对所述第一用户语句中的关键词根据第二识别条件进行筛选,识别所述第一语音信息中的指代人物词语,将所述第一用户语句中识别的所述指代人物词语与所述用户关系集合中存储的人物关系进行对应:
[0089] 若所述指代人物词语在所述用户关系集合中寻找不到对应储存的人物关系,则判定所述指代人物词语为首次出现;
[0090] 若所述指代人物词语在所述用户关系集合中寻找到对应储存的人物关系,则判定所述指代人物词语为非首次出现。
[0091] 可能出现的指代人物词语包括但不仅限于“老板”、“员工”、“客户”、“下属”、“领导”、“朋友”、“父母”等多种称谓,需要指出的是,如果出现的指代人物词语是如“老板”、“员工”等职级称呼时,即使该指代人物词语与用户关系对应的人发生改变,但依然默认为用户选择历史记录的预订信息作为参考。举例:如用户曾经在某公司使用本系统预订过车辆接送“老板”,即使该用户离职跳槽至另一家公司任职,此时现公司“老板”与前公司“老板”并非指代同一人,但下次当用户再次使用本系统预订车辆接送“老板”时,系统也可以继续为用户提供上一次订单接送车辆信息供用户参考使用。此外,若在第一用户语句中只出现单一身份指代词,则直接识别该身份指代词;若在第一用户语句中出现多个身份指代词,则对出现的所有身份指代词进行共同分析,将所有身份指代词集合为一个身份识别信息。
[0092] 根据所述被接送人信息中指代的被接送人与所述用户的第一人物关系在本地存储的人物关系集合中是否为首次出现的不同判断情况分别执行如下步骤S206或S207。
[0093] 步骤S206:若判断出所述第一人物关系在本地存储的人物关系集合中为首次出现,则将所述第一人物关系存储于所述人物关系集合中。
[0094] 对于非首次出现的场合通常出现在新用户时期,此时本地存储的用户人物关系较少,需要在新用户使用过程中逐步获取与所述新用户相关人物的关系。
[0095] 步骤S207:若判断出所述第一人物关系在本地存储的人物关系集合中不是首次出现,则从所述人物关系集合中获取所述用户与所述被接送人的第一人物关系。
[0096] 在本申请实施例中,用户关系集合中存储有曾经的被接送人的指代人物词语以及姓名等。若此次分析第一用户语句中时出现与存储的被接送人信息一致的情况,则在为用户预订车辆之前展示和跳转询问用户是否选择上次订单选择的车辆型号等,若用户选择“是”,则为用户预订与上次订单相同车型的车辆,若用户选择“不是”,则回到原预订车辆的步骤继续执行。
[0097] 在一种可能的实施方式中,在所述获取所述用户关系集合中的对应关系之后具体还可以包括步骤:对所述指代人物与用户的对应关系进行分析,若所述指代人物与用户的关系为上下级关系时,则根据所述上下级关系筛选出一批适合该职位的车辆。
[0098] 考虑到可能存在商务或职务目的需要预订车辆的场景,对于不同职级的预订车辆需求也是不相同的,系统可以为用户提供智能筛选方案为用户选择适合特定上下级关系的车辆,可以减少用户对于规划车辆需求的负担。对于不同需求场景可以进行更加细致分类以保证用户用车的适宜程度。例如,若用户出于公务目的时,系统则优先为用户筛选出品牌相对较为高档的车辆进行推荐供用户选择,若用户仅是以私人目的需要车辆服务时,则会优先为用户筛选出品牌较为经济实用的车辆供用户选择。
[0099] 在本申请实施例中,商务用途中往往存在特殊的职级关系,这也是用户需要个性化定制打车需求的重要原因之一,因此对于不同职级关系也对应不同层次的需求,而判断条件即为接送人与被接送人之间的职位关系。例如当被接送人为接送人的老板时,系统会捕捉到“老板”这一特殊的人称指代词,之后系统会根据用户以往预订车辆订单信息或者互联网的大数据信息进行分析为用户筛选出适合该职位身份的车辆,这也为用户提供了更加便捷的服务。
[0100] 需要指出的是,由于本预订车辆的服务中存在三部分关系,分别是用户、司机和被接送人,其中被接送人又可以分为被接人和被送人两种。本实施例中所述被接人指的并非是叫车的用户,而是叫车用户在叫到车之后随同车辆和司机要去接的人员;所述被送人也并非是指所述用户为需要被送的人员,而是在所述用户叫到车之后随同车辆和司机一起需要被送去目的地点的人员。所述被接人和所述被送人分别对应了接人场景和送人场景,若为所述接人场景,则整个订车场景下的路线为所述出行始发地点至出行第一目的地点,再从所述出行第一目的地点至出行第二目的地点;若为所述送人场景,则整个订车场景下的路线为所述出行始发地点至出行第一目的地点。
[0101] 步骤S208:将所述第一订车需求和所述第一人物关系发送给所述语音服务器,接收所述语音服务器根据所述第一订车需求和所述第一人物关系确定的所述用户的第二订车需求,所述第二订车需求包括出行地点、目的地点和待预订的车辆型号。
[0102] 需要额外指出的是,在一些特定场合下,所述用户在叫到车之后并非会随同车辆和司机共同前往目的地点,也存在用户叫车之后让车辆和司机直接前往目的地点接取所述被接人,或者让车辆和司机在出行地点接取所述被送人送至目的地点的情况,此时出行人数信息将会根据实际情况进行判断。举例:“今天下午1点我需要一辆商务车去机场接三位客户”,此时就是所述被接人的情况,若用户选择一同前往,则判断前往出行目的地点机场的出行人数为“一人”,接取客户之后出行人数为“四人”;若用户后续特别说明不选择一同前往,则判断接取客户之后出行人数仍为“三人”。举例:“今天下午1点我需要一辆商务车送三位客户去机场”,此时即为所述被送人的情况,若用户选择一同前往,则判断前往出行目的地点机场的出行人数为“四人”,送别客户之后出行人数为“一人”;若用户后续特别说明不选择一同前往,则判断送别客户前出行人数为“三人”,送别客户后出行人数就变成“零人”,此时也即不需要车辆再从所述出行第一目的地点前往所述出行第二目的地点。这里指出了两种情况在细分情况下是略有不同的。
[0103] 步骤S209:调用第一打车应用,根据所述第二订车需求为用户预订车辆。
[0104] 在一种可能的实施方式中,在所述调用第一打车应用,根据所述第二订车需求为用户预订车辆之后具体还可以包括步骤:
[0105] 若检测到预订车辆的等待时长大于或等于第一预设时长,则根据所述第二订车需求中包括的出行地点和目的地点,调用导航应用生成导航路线并调用所述导航应用向导航服务器发送获取所述导航路线的道路情况的请求,获取来自所述导航服务器发送的道路情况信息,对所述导航路线的道路拥堵状况进行判断;
[0106] 若满足以下至少一种情况,则提醒所述用户更改导航路线或提醒所述用户更改所述目的地点预设范围内且不存在拥堵状况的地点作为导航目的地:
[0107] 所述导航路线存在拥堵情况;
[0108] 预订车辆的出行时间或到达所述目的地点的时间处于早高峰时段或晚高峰时段;
[0109] 所述目的地点为预设标记过的拥堵热点区域。
[0110] 在本申请实施例中,在终端设备向用户发出提醒所述用户更改导航路线或提醒所述用户更改所述目的地点预设范围内且不存在拥堵状况的地点作为导航目的地信息之后,若用户接收所述提醒并选择更改所述导航路线或更改所述目的地点,则终端设备接收用户的更改信息并根据更改后的信息生成第三订车需求,根据所述第三订车需求重新预订车辆;若用户忽略所述提醒并不作处理,则在超过第二预设时长时按照权3的方式进行提醒。
[0111] 现实中可能存在道路拥堵或者接送点难以上车等情况,如部分早高峰或者晚高峰时段,对于部分特殊预设地点而言达到了用车高峰期,此时线上叫车是十分困难的。在超过一定打车时长的时候,可以向用户发出提醒信息,考虑到部分预设地点拥堵的原因可能是由于某些道路车流量过大或者存在道路管制,因此,向用户提出修改打车出行始发地为附近某个拥堵状况较轻或者上车较为方便的地点作为出行始发地能够有效缩短打车时长,提高用户预订车辆的成功率,也为用户和司机都提供了更好的打车体验。
[0112] 此外部分道路存在特殊限制情况,如部分路段可能对车辆种类、时速、车辆高度等有所限制,系统会对此类存在的限制条件进行共同分析,而后筛选车辆再为用户执行预订操作。
[0113] 在一种可能的实施方式中,在所述方法之后具体还可以包括步骤:
[0114] 若检测到预订车辆的等待时长小于第二预设时长,则继续根据第二订车需求为用户预订车辆;其中,所述第二预设时长在所述预订车辆的等待时长等于所述第一预设时长时开始计时;
[0115] 若检测到预订车辆的等待时长大于或等于第二预设时长,则提醒用户更换打车应用或扩大待预订的车辆型号范围;
[0116] 在本申请实施例中,用户打车出行地点或者目的地点为人流量或者车流量较大的地段时,调用导航应用向导航服务器获取出行地点与目的地点之间的道路情况进行分析,仍有时无法在第一时间为用户预定到车辆,因此需要为用户提供更多智能化方案,如更换其他打车平台或者扩大更多待预订的车辆型号范围,也有助于提升用户和司机更好的接车体验。对于出现拥堵状况的路段,用户可能会面临较难打车的场合,原因在于司机十分不愿意接取该出行始发地或者出行目的地的订单,当司机遭遇拥堵情况时,需要很久才能开出该路段再继续接单。因此在该状况下需要适当扩大预订车辆的筛选范围,如通过更换打车应用或扩大待预订的车辆型号范围来提高用户预订车辆的成功率。
[0117] 在一种可能的实施方式中,在所述若检测到预订车辆的等待时长大于或等于第二预设时长,则提醒用户更换打车应用或扩大待预订的车辆型号范围之后具体还包括:
[0118] 若同时预订到的车辆数目为两辆或两辆以上时,则对所述预订到的车辆进行排序,将排序第一的车辆推荐给用户,其中所述排序由用车价格、用车时间、司机信誉度共同确定。
[0119] 在本申请实施例中,由于扩大了预订车辆的范围,所以存在扩大了预订车辆范围之后会有多个可以预订的车辆供用户选择,此时可以根据已分析的诸多信息为用户进行智能化推荐更加合适的车辆,这也减少了用户的人为判断成本。
[0120] 上述阐释了一种预订车辆的方法的具体步骤,为方便技术人员更好理解上述方法,下面将提供一种在实际应用中使用该方法的场景实例。
[0121] 以图3和图4为例,图3和图4展示了一种使用智能手机预订车辆的实例示意图,实施例具体执行步骤如下:
[0122] 系统接收到用户输入的第一用户语句“今天下午1点我要去机场接客户”并通过“去‑机场”和“接‑客户”判断出当前为用户需要预订车辆场景;
[0123] 系统判断第一用户语句得到“今天下午1点”、“去机场”两条信息,分别对应了第一预订信息中的出行时间和出行地点两条信息,但是仍缺乏第一预订信息中的出行人数信息,因此系统判定第一用户语句中不包含全部的第一预订信息;
[0124] 系统向用户询问获取第二用户语句“请问一共几位客户呢。”,用户回答“三位客户”,根据“接客户”可以判断此时为接人场景,由此得到在接取客户之后出行人数信息为包括用户在内的“四人”;此时已成功获取全部的第一预订信息得到第一订车需求;
[0125] 系统检测分析指代人物词语“客户”,在用户关系集合中找到对应的人物关系作为第一人物关系,为用户优先选择“商务车”作为待选车辆。
[0126] 结合第一订车需求和第一人物关系得到第二订车需求。
[0127] 再根据所述第二订车需求为在显示屏幕为用户提供出行地图、预计时间、预计价格等信息,并询问用户“现为你查到:从科技园去机场的商务型车,预计价格为81元,需要现在为你预订该车辆吗。”;
[0128] 用户回答:“帮我预订吧”,由此系统完全获取用户预订车辆需求和许可并为用户预订对应的车辆,至此整个预订车辆服务结束。
[0129] 上述详细阐述了本申请的方法和一种可能的具体实施例,下面提供了本申请实施例的装置。
[0130] 请参照图5,图5是本申请实施例提供的一种的装置的结构示意图。该装置应用于线上预订车辆。如图5所示,该预订车辆的装置500包括接收模块501、第一判断模块502、第二判断模块503、输出模块504,各个模块的详细描述如下:
[0131] 接收模块,用于调用所述人机互动服务引擎获取用户输入的第一语音信息,对所述第一语音信息进行语音转文字操作得到第一用户语句,对所述第一用户语句进行意图识别,得到用户意图识别结果为预订车辆;
[0132] 第一判断模块,用于判断所述第一用户语句中是否包含完整的第一预订信息;
[0133] 若判断出所述第一用户语句中包含完整的第一预订信息,则分析所述第一用户语句,得到用户的第一订车需求;
[0134] 若判断出所述第一用户语句中不包含完整的第一预订信息,则向用户询问缺失的第一预订信息,获取第二用户语句,对所述第一用户语句与第二用户语句分析得到用户的第一订车需求;
[0135] 第二判断模块,用于若所述第一用户语句和所述第二用户语句中包含被接送人信息,则分析所述被接送人信息,并判断所述被接送人信息中指代的被接送人与所述用户的第一人物关系在本地存储的人物关系集合中是否为首次出现;
[0136] 若判断出所述第一人物关系在本地存储的人物关系集合中为首次出现,则将所述第一人物关系存储于所述人物关系集合中;
[0137] 若判断出所述第一人物关系在本地存储的人物关系集合中不是首次出现,则从所述人物关系集合中获取所述用户与所述被接送人的第一人物关系;
[0138] 将所述第一订车需求和所述第一人物关系发送给所述语音服务器,接收所述语音服务器根据所述第一订车需求和所述第一人物关系确定的所述用户的第二订车需求,所述第二订车需求包括出行地点、目的地点和待预订的车辆型号;
[0139] 输出模块,用于调用第一打车应用,根据所述第二订车需求为用户预订车辆。
[0140] 在一种可能的实施方式中,接收模块501具体用于,对所述第一用户语句进行关键词拆解并提取至少两个关键词以及所述关键词之间的语义关系;根据所述关键词以及所述语义关系确定语义识别结果;根据所述语义识别结果确定当前为需要预订车辆的场景。
[0141] 在一种可能的实施方式中,第一判断模块502具体用于对所述第一用户语句中的关键词根据第一识别条件进行筛选,识别所述第一用户语句中的出行时间、出行地点以及出行人数,将所述第一用户语句中识别的所述出行时间、出行地点以及出行人数发送给信息服务器,之后接收来自信息服务器对所述出行时间、出行地点以及出行人数与预设的第一预订信息对应的判断信息。
[0142] 在一种可能的实施方式中,第二判断模块503具体用于对所述第一用户语句中的关键词根据第二识别条件进行筛选,识别所述第一语音信息中的指代人物词语,将所述第一用户语句中识别的所述指代人物词语与所述用户关系集合中存储的人物关系进行对应:若所述指代人物词语在所述用户关系集合中寻找不到对应储存的人物关系,则判定所述指代人物词语为首次出现;若所述指代人物词语在所述用户关系集合中寻找到对应储存的人物关系,则判定所述指代人物词语为非首次出现。
[0143] 在一种可能的实施方式中,第二判断模块503具体还用于若检测到预订车辆的等待时长大于或等于第一预设时长,则根据所述第二订车需求中包括的出行地点和目的地点,调用导航应用生成导航路线并调用所述导航应用向导航服务器发送获取所述导航路线的道路情况的请求,获取来自所述导航服务器发送的道路情况信息,对所述导航路线的道路拥堵状况进行判断;若满足以下至少一种情况,则提醒所述用户更改导航路线或提醒所述用户更改所述目的地点预设范围内且不存在拥堵状况的地点作为导航目的地:所述导航路线存在拥堵情况;预订车辆的出行时间或到达所述目的地点的时间处于早高峰时段或晚高峰时段;所述目的地点为预设标记过的拥堵热点区域。
[0144] 在一种可能的实施方式中,输出模块504具体还用于若检测到预订车辆的等待时长小于第二预设时长,则继续根据第二订车需求为用户预订车辆;其中,所述第二预设时长在所述预订车辆的等待时长等于所述第一预设时长时开始计时;若检测到预订车辆的等待时长大于或等于第二预设时长,则提醒用户更换打车应用或扩大待预订的车辆型号范围;
[0145] 在一种可能的实施方式中,输出模块504具体还用于若同时预订到的车辆数目为两辆或两辆以上时,则对所述预订到的车辆进行排序,将排序第一的车辆推荐给用户,其中所述排序由用车价格、用车时间、司机信誉度共同确定。
[0146] 需要说明的是,各个模块的实现还可以对应参照图2所示的方法实施例的相应描述。
[0147] 请参照图6,图6是本申请实施例提供的一种计算机设备的结构示意图。如图6所示,该电子设备600包括处理器601、存储器602和通信接口603,其中存储器602存储有计算机程序604。处理器601、存储器602、通信接口603以及计算机程序604之间可以通过总线605连接。
[0148] 当计算机设备为智能手机终端时,上述计算机程序604用于执行以下步骤的指令:
[0149] 调用所述人机互动服务引擎获取用户输入的第一语音信息,对所述第一语音信息进行语音转文字操作得到第一用户语句,对所述第一用户语句进行意图识别,得到用户意图识别结果为预订车辆;
[0150] 判断所述第一用户语句中是否包含完整的第一预订信息;
[0151] 若判断出所述第一用户语句中包含完整的第一预订信息,则分析所述第一用户语句,得到用户的第一订车需求;
[0152] 若判断出所述第一用户语句中不包含完整的第一预订信息,则向用户询问缺失的第一预订信息,获取第二用户语句,对所述第一用户语句与第二用户语句分析得到用户的第一订车需求;
[0153] 若所述第一用户语句和所述第二用户语句中包含被接送人信息,则分析所述被接送人信息,并判断所述被接送人信息中指代的被接送人与所述用户的第一人物关系在本地存储的人物关系集合中是否为首次出现;
[0154] 若判断出所述第一人物关系在本地存储的人物关系集合中为首次出现,则将所述第一人物关系存储于所述人物关系集合中;
[0155] 若判断出所述第一人物关系在本地存储的人物关系集合中不是首次出现,则从所述人物关系集合中获取所述用户与所述被接送人的第一人物关系;
[0156] 将所述第一订车需求和所述第一人物关系发送给所述语音服务器,接收所述语音服务器根据所述第一订车需求和所述第一人物关系确定的所述用户的第二订车需求,所述第二订车需求包括出行地点、目的地点和待预订的车辆型号;
[0157] 调用第一打车应用,根据所述第二订车需求为用户预订车辆。
[0158] 在一种可能的实施方式中,所述计算机程序604具体还用于执行以下步骤的指令:
[0159] 若检测到预订车辆的等待时长大于或等于第一预设时长,则根据所述第二订车需求中包括的出行地点和目的地点,调用导航应用生成导航路线并调用所述导航应用向导航服务器发送获取所述导航路线的道路情况的请求,获取来自所述导航服务器发送的道路情况信息,对所述导航路线的道路拥堵状况进行判断;
[0160] 若满足以下至少一种情况,则提醒所述用户更改导航路线或提醒所述用户更改所述目的地点预设范围内且不存在拥堵状况的地点作为导航目的地:
[0161] 所述导航路线存在拥堵情况;
[0162] 预订车辆的出行时间或到达所述目的地点的时间处于早高峰时段或晚高峰时段;
[0163] 所述目的地点为预设标记过的拥堵热点区域。
[0164] 在一种可能的实施方式中,所述计算机程序604具体还用于执行以下步骤的指令:
[0165] 若检测到预订车辆的等待时长小于第二预设时长,则继续根据第二订车需求为用户预订车辆;其中,所述第二预设时长在所述预订车辆的等待时长等于所述第一预设时长时开始计时;
[0166] 若检测到预订车辆的等待时长大于或等于第二预设时长,则提醒用户更换打车应用或扩大待预订的车辆型号范围;
[0167] 在一种可能的实施方式中,所述计算机程序604具体还用于执行以下步骤的指令:
[0168] 若同时预订到的车辆数目为两辆或两辆以上时,则对所述预订到的车辆进行排序,将排序第一的车辆推荐给用户,其中所述排序由用车价格、用车时间、司机信誉度共同确定。
[0169] 在一种可能的实施方式中,所述对所述第一用户语句进行意图识别,得到用户意图识别结果为预订车辆,所述计算机程序604具体用于执行以下步骤的指令:
[0170] 对所述第一用户语句进行关键词拆解并提取至少两个关键词以及所述关键词之间的语义关系;
[0171] 根据所述关键词以及所述语义关系确定语义识别结果;
[0172] 根据所述语义识别结果确定当前为需要预订车辆的场景。
[0173] 在一种可能的实施方式中,所述判断所述第一用户语句中是否包含完整的第一预订信息,所述计算机程序604具体用于执行以下步骤的指令:
[0174] 对所述第一用户语句中的关键词根据第一识别条件进行筛选,识别所述第一用户语句中的出行时间、出行地点以及出行人数,将所述第一用户语句中识别的所述出行时间、出行地点以及出行人数发送给信息服务器,之后接收来自信息服务器对所述出行时间、出行地点以及出行人数与预设的第一预订信息对应的判断信息。
[0175] 在一种可能的实施方式中,所述判断所述被接送人信息中指代的被接送人与所述用户的第一人物关系在本地存储的人物关系集合中是否为首次出现,所述计算机程序604具体用于执行以下步骤的指令:
[0176] 对所述第一用户语句中的关键词根据第二识别条件进行筛选,识别所述第一语音信息中的指代人物词语,将所述第一用户语句中识别的所述指代人物词语与所述用户关系集合中存储的人物关系进行对应:
[0177] 若所述指代人物词语在所述用户关系集合中寻找不到对应储存的人物关系,则判定所述指代人物词语为首次出现;
[0178] 若所述指代人物词语在所述用户关系集合中寻找到对应储存的人物关系,则判定所述指代人物词语为非首次出现。
[0179] 本领域技术人员可以理解,为了便于说明,图6中仅示出了一个存储器和处理器。在实际的终端或服务器中,可以存在多个处理器和存储器。存储器602也可以称为存储介质或者存储设备等,本申请实施例对此不做限定。
[0180] 应理解,在本申请实施例中,处理器601可以是中央处理单元(central processing unit,CPU),该处理器还可以是其他通用处理器、数字信号处理器(digital signal processing,DSP)、专用集成电路(application specific integrated circuit,ASIC)、现成可编程门阵列(field-programmable gate array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。
[0181] 还应理解,本申请实施例中提及的存储器602可以是易失性存储器或非易失性存储器,或可包括易失性和非易失性存储器两者。其中,非易失性存储器可以是只读存储器(read‑only memory,ROM)、可编程只读存储器(programmable ROM, PROM)、可擦除可编程只读存储器(erasable PROM,EPROM)、电可擦除可编程只读存储器(electrically EPROM,EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory,RAM),其用作外部高速缓存。通过示例性但不是限制性说明,许多形式的RAM可用,例如静态随机存取存储器(static RAM,SRAM)、动态随机存取存储器(dynamic RAM,DRAM)、同步动态随机存取存储器(synchronous DRAM,SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM,DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM,ESDRAM)、同步连接动态随机存取存储器synchronize link DRAM,SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM,DR RAM)。
[0182] 需要说明的是,当处理器601为通用处理器、DSP、ASIC、FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件时,存储器(存储模块)集成在处理器中。
[0183] 应注意,本文描述的存储器602旨在包括但不限于这些和任意其它适合类型的存储器。
[0184] 该总线605除包括数据总线之外,还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见,在图中将各种总线都标为总线。
[0185] 在实现过程中,上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成,或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成上述方法的步骤。为避免重复,这里不再详细描述。
[0186] 在本申请的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。
[0187] 本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各种说明性逻辑块(illustrative logical block,ILB)和步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
[0188] 在本申请所提供的几个实施例中,应该理解到,所揭露的方法、装置和设备,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
[0189] 所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0190] 另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
[0191] 在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘)等。
[0192] 在上述实施例中,计算机可读存储介质可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序等;存储数据区可存储根据区块链节点的使用所创建的数据等,在此不做限定。
[0193] 本申请实施例还提供一种计算机存储介质,所述计算机可读存储介质存储有计算机程序,所述计算机程序被处理器执行以实现如上述方法实施例中记载的任何一种预订车辆的方法的部分或全部步骤。
[0194] 本申请实施例还提供一种计算机程序产品,所述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质,所述计算机程序可操作来使计算机执行如上述方法实施例中记载的任何一种预订车辆的方法的部分或全部步骤。
[0195] 以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。