基于自然语言输入的用车服务预订方法和系统与流程

1.本发明涉及汽车领域，更具体地，涉及基于自然语言输入的用车服务预订方法和系统。


背景技术：

2.近年来，汽车租赁市场规模日益扩大，尤其是随着共享经济的升温，汽车短时租赁业务的种类也不断丰富，包括但不限于出租车、专车、顺风车、共享汽车等等。这些业务目前已普遍被整合在各种基于互联网平台的叫车平台，诸如滴滴、优步、神州等等，用户可使用移动终端通过各平台提供的移动客户端来实时叫车或预约用车。
3.然而，目前的各类提供用车服务的叫车平台的客户端一般都需要用户通过手动输入出发点和目的地。典型地，如图3所示，在各种叫车客户端的叫车界面中都至少提供了上车点和目的地两栏，用户需要通过手动或语音输入文字或选择地图上的点的方式来分别输入上车点和目的地，此外如果想要使用预约用车服务，还需要进一步输入希望预约用车的时间。这对于部分用户来说可能是繁琐的，诸如那些相对不太擅长在移动设备进行各种操作的用户，以及对于新安装的客户端仍不熟悉的用户。
4.因此，希望能够提供更便捷以及更智能的提供预约用车服务的方式。


技术实现要素：

5.提供本发明内容以便以简化形式介绍将在以下具体实施方式中进一步的描述一些概念。本发明内容并非旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。
6.针对以上问题，根据本发明的一个方面，提供了一种用车服务处理系统，包括：
7.自然语言处理模块，所述自然语言处理模块被配置成：
8.将接收到的来自用户的自然语言形式的用车服务请求消息处理成结构化数据形式的用车信息；以及
9.对话模块，所述对话模块被配置成：
10.确定所述用车信息中是否包含预订用车服务所需的所有必要信息；
11.若确定所述用车信息中缺少预订用车服务所需的一项或多项必要信息，则生成发送给所述用户的对话，以向所述用户获取所缺少的所述一项或多项必要信息；
12.若确定所述用车信息中已包含预订用车服务所需的所有必要信息，则将所述用车信息发送给服务平台；以及
13.基于所述服务平台返回的用车服务确认结果，生成发送给所述用户的对话，以向所述用户告知所述用车服务确认结果。
14.根据本发明的一个实施例，所述自然语言处理模块还被配置成：将来自用户的语音形式的用车服务请求消息转换成文本。
15.根据本发明的进一步实施例，所述系统还包括：用户简档模块，所述用户简档模块
被配置成存储每一位用户的用户简档。
16.根据本发明的进一步实施例，所述对话模块被进一步配置成：在确定所述用车信息中是否包含预订用车服务所需的所有必要信息之前，基于所述用户简档对所述用车信息中的一项或多项信息进行完善。
17.根据本发明的进一步实施例，所述用户简档模块还被配置成为用户建立用户画像，所述用户画像包括按照用车习惯划分的一个或多个用户类别。
18.根据本发明的进一步实施例，所述对话模块被进一步配置成：基于所述用户简档和用户画像中的一者或两者，生成发送给所述用户的对话，以向所述用户提供针对除所述必要信息以外的附加用车信息的推荐。
19.根据本发明的另一方面，提供了一种用于处理用车服务的方法，其中所述方法包括：
20.接收来自用户的自然语言形式的用车服务请求消息；
21.将接收到的所述用车服务请求消息处理成结构化数据形式的用车信息；
22.确定所述用车信息中是否包含预订用车服务所需的所有必要信息；
23.若确定所述用车信息中缺少预订用车服务所需的一项或多项必要信息，则生成发送给所述用户的对话，以向所述用户获取所缺少的所述一项或多项必要信息；
24.若确定所述用车信息中已包含预订用车服务所需的所有必要信息，则将所述用车信息发送给服务平台；以及
25.基于所述服务平台返回的用车服务确认结果，生成发送给所述用户的对话，以向所述用户告知所述用车服务确认结果。
26.根据本发明的进一步实施例，将接收到的所述用车服务请求消息处理成结构化数据形式的用车信息进一步包括：将来自用户的语音形式的用车服务请求消息转换成文本。
27.根据本发明的进一步实施例，所述方法还包括：在确定所述用车信息中是否包含预订用车服务所需的所有必要信息之前，基于用户简档对所述用车信息中的一项或多项信息进行完善。
28.根据本发明的进一步实施例，所述方法还包括：基于所述用户简档和用户画像中的一者或两者，生成发送给所述用户的对话，以向所述用户提供针对除所述必要信息以外的附加用车信息的推荐，其中所述用户画像包括按照用车习惯划分的一个或多个用户类别。
29.根据本发明的进一步实施例，所述方法还包括：基于服务提供商提供的可选服务选项，生成发送给所述用户的对话，以针对当前用车信息中未提及的选项询问用户或提供推荐。
30.根据本发明的进一步实施例，确定所述用车信息中是否包含预订用车服务所需的所有必要信息还包括：
31.确定所述用车信息中是否包括一项或多项不准确的信息；以及
32.若确定所述用车信息中包括一项或多项不准确的信息，则生成发送给所述用户的对话，以向所述用户询问所述一项或多项不准确的信息的准确含义。
33.根据本发明的进一步实施例，所述方法还包括：训练针对用车服务场景的语义理解引擎，所述语义理解引擎被用于将接收到的所述用车服务请求消息处理成结构化数据形
式的用车信息。
34.根据本发明的进一步实施例，训练针对用车服务场景的语义理解引擎进一步包括：
35.定义与所述用车服务场景有关的结构化数据的多个字段；
36.从多位不同用户收集训练语料，其中每一条所述训练语料是一位用户对用车意图的自然语言表述，所述自然语言表述中包含所述字段中的至少一些；以及
37.使用所收集的训练语料通过机器学习算法来训练所述语义理解引擎。
38.根据本发明的进一步实施例，与用户之间的对话是在通用消息收发应用中进行的。
39.针对现有技术中存在的问题，本发明提供了基于自然语言输入的用车服务预订方法和系统，与现有技术相比至少具有以下优点：
40.1、用户可以全程使用自然语言来进行用车服务预订，简化了相关的操作流程；
41.2、用车服务预订过程可在用户日常使用的消息收发应用中以对话的方式进行，不需要安装特定的应用程序，也无需额外的学习成本；以及
42.3、可以针对不同用户提供更智能、更个性化的用车服务和推荐，改善了用户体验和满意度。
43.通过阅读下面的详细描述并参考相关联的附图，这些及其他特点和优点将变得显而易见。应该理解，前面的概括说明和下面的详细描述只是说明性的，不会对所要求保护的各方面形成限制。
附图说明
44.为了能详细地理解本发明的上述特征所用的方式，可以参照各实施例来对以上简要概述的内容进行更具体的描述，其中一些方面在附图中示出。然而应该注意，附图仅示出了本发明的某些典型方面，故不应被认为限定其范围，因为该描述可以允许有其它等同有效的方面。
45.图1是根据本发明的一个实施例的用车服务系统的架构示意图。
46.图2是根据本发明的一个实施例的处理用车服务的方法的示意流程图。
47.图3是现有技术中的一个打车应用程序的预约用车界面。
具体实施方式
48.下面结合附图详细描述本发明，本发明的特点将在以下的具体描述中得到进一步的显现。
49.图1是根据本发明的一个实施例的用车服务系统100的架构示意图。如图1所示，用车服务系统100可由客户端102、用车服务处理系统104以及服务平台106组成。
50.客户端102可被配置成用于接收来自用户的用车服务请求消息。作为一个示例，客户端102可被实现为用户移动设备上的应用程序。优选地，客户端102可以被实现在通用消息收发应用中(诸如微信公众号或微信小程序)，从而允许用户可以以消息收发形式来向用车服务处理系统104发送用车服务请求消息。与现有用车服务中传统的订车操作不同，本发明所提供的这种订车形式不需要用户通过诸如下拉菜单、选择定位等繁琐方式来提供订车
所需的信息(包括上车点、目的地和预订时间)，而是可以通过自然语言的形式以对话方式完成用车预约。例如，用户可以直接在微信中的消息收发界面中向与朋友聊天一样发送诸如“我需要辆车下午3点从外滩去上海博物馆”之类的消息。这一消息既可以是用户通过文本输入方式输入并以文本形式发送给用车服务处理系统104，也可以是用户通过语音输入方式并以语音形式发送给用车服务处理系统104。同样，通过这一消息收发界面，用户可以接收来自用车服务处理系统104的用车服务确认消息或其他关于用车服务的进一步细节的其他消息。根据本发明的一个实施例，用车服务请求消息中除了用户输入的自然语言文本或语音，还可包括其他相关信息，包括但不限于用户id、位置信息、会话id等等。
51.用车服务处理系统104被配置成接收来自客户端102的用车服务请求消息，并将其处理成服务请求发送给服务提供商106。根据本发明的一个实施例，用车服务处理系统104可包括自然语言处理模块108和对话模块110。
52.自然语言处理模块108用于处理从客户端102接收的用车服务请求消息。如之前提到的，用车服务请求消息是由用户以自然语言的形式输入的消息。如果该消息是以语音形式提供的，则自然语言处理模块108可通过各种语音识别技术将语音转换成文本。
53.自然语言处理模块108可被进一步配置成将文本消息处理成结构化数据，以从该消息中提取与用车服务相关的信息(以下简称“用车信息”)。更具体地，沿用之前提到的示例，假设自然语言处理模块108接收到来自客户端102的消息“我需要辆车下午3点从外滩去上海博物馆”，则从该消息中可以提取出以下信息：
54.用车人：我
55.用车时间：下午3点
56.出发点：外滩
57.目的地：上海博物馆
58.自然语言处理模块108在将用户的自然语言消息处理成结构化的用车信息后，该用车信息被提供给对话模块110。对话模块110可被配置成生成与用户的对话，以及将收集到的用车信息发送给服务平台106。
59.对话模块110首先可以对用车信息可以被进一步自动完善。例如，通过与客户端绑定的用户id，用车人“我”可被替代为相应的用户；用车时间“下午3点”可基于系统时钟被自动完善为2019年3月17日下午3点(假设当天是2019年3月17日)；出发点“外滩”可基于用户的位置信息被补全为“上海外滩”；诸如此类。
60.随后，对话模块110可对照预定义的用车信息表来检查该用车消息中是否已包含预订用车服务所需的所有必要信息。例如，一般而言，用车人、用车时间、出发点和目的地是一次用车服务的必要信息。根据本发明的一个实施例，如果已经包含了全部必要信息，则可生成给用户的对话，告知用户用车服务已收到，正等待服务提供商确认中，例如“好的，正在为您安排！”同时，相关用车信息被发送给服务平台106。替代地，对话模块110也可以先将相关用车信息被发送给服务平台106，等到服务平台106返回了确认结果后，再生成给用户的对话，直接告知用户该用车服务预订结果，例如“好的，已为您安排3点从外滩去上海博物馆的车辆，车辆信息是
……
，祝您用车愉快！”或者“非常抱歉，您预约的时间暂时无法安排车辆，是否需要为您改约其他时间？”，诸如此类。
61.如果收到的消息中缺少一项或多项必要信息，或者该项信息不准确，则对话模块
110可生成对话，向用户询问关于缺少或不准确的信息。例如，收到的消息中没有明确的用车时间，则对话模块110可生成诸如“请问您想预约几点来接您？”之类的对话。另外，如上述提到的示例中，出发点或目的地信息可能还不够准确，例如“外滩”的范围比较大，不清楚具体的上车地点，则对话模块110可查询可能的上车地点，例如系统中有“外滩游客中心”和“外滩浦江游览码头”两个地点，则可以生成对话，“请问您希望车在外滩游客中心还是在外滩浦江游览码头接您？或者其他地点？”62.此外，除了必要用车信息，用车信息表中还可以包括多个附加用车信息，包括但不限于：车辆类型(例如轿车、suv、mpv等)、车型(例如bmw 7系、bmw 5系、bmw x5、mini copper等)、车内设施(例如是否提供安全座椅、雨伞、饮用水、充电器、车内wi-fi等等)等诸如此类。相应地，对话模块110还进一步就这些附加信息来生成对话，例如“您想要什么车型？我们可为您提供
……”
。
63.作为一个可选实施例，用车服务处理系统104还可包括用户简档模块112。用户简档模块112可存储每一位用户的用户简档，用户简档中可包括例如个人信息、用车偏好等。这些信息可以由用户通过在客户端中进行注册来获取，例如用户的姓名、性别、手机号码、常用地址、偏好车型、职业、收入情况、自有车辆等等。此外，用车偏好也可根据用户的历史用车记录来自动生成和更新，例如用户每次都预订bmw 5系轿车，则可以为该用户生成偏好车型为bmw 5系轿车。进一步的，用户简档模块112还可以为用户建立用户画像，以方便为用车习惯类似的用户提供更有针对性的推荐。例如，用户画像类别可包括但不限于：商务接待、全家出游、热爱运动等等。
64.相应地，对话模块110在完善用车信息和检查用车信息并生成相应对话时都可与用户简档模块112交互来获取相关信息。
65.例如，在完善用车信息步骤中，对话模块110可将用户id发送给用户简档模块112来获取用户的身份信息。在另一示例中，当用车信息中的出发点或目的地是“家”或“公司”之类的简称时，对话模块110可通过查询用户简档模块112来获取相应的具体地址。此外，在针对附加信息生成对话时，对话模块110可查询用户简档模块112中的用户偏好或用户画像来为用户提供推荐。例如，针对被归类为“商务接待”这一用户画像类别的用户，可为其推荐适合商务接待的bmw 7系或5系轿车，针对“全家出游”类别的用户则可推荐配备有“安全座椅”的车辆，而针对“热爱运动”类别的用户可推荐suv或bmw m系运动轿跑。
66.在对话模块110生成的对话被发送给用户之后，用户可进一步以对话形式提供相应的信息。这一信息再次以自然语言消息的形式发送给用车服务处理系统104，并经由自然语言处理模块108处理后提供给对话模块110。当对话模块110收集齐所有相关用车信息之后，可将这些用车信息发送给服务平台106。
67.服务平台106可包括一个或多个服务提供商114。服务提供商114负责具体承接相关的用车服务。在收到来自用车服务处理系统104的用车信息之后，服务提供商114确定是否能够承接该用车服务并经由服务平台106返回相应的确认结果，例如可以提供服务或无法提供服务。作为一个可选示例，在无法提供服务的情况下，服务提供商114可进一步提供其他提供服务的可能选项(例如，不同时间(如提前或延后30分钟)、更换不同车型等等)。
68.作为另一可选示例，为了使整个用车预订流程更有效率并提升用户体验，服务提供商114可维护其可以提供的服务的各项细节并定期提供给用车服务处理系统104。例如，
服务提供商114能够提供的车型的变更，额外服务的变更(例如，可提供接送机服务、可提供外语接待服务等等)，诸如此类。这些更新的信息被提供给用车服务处理系统104后，对话模块110可利用这些信息以对话形式提供更令用户满意的推荐。
69.在服务平台106返回服务确认结果之后，用车服务处理系统104的对话模块110仍然以对话形式发送给客户端102，告知用户服务确认结果。值得注意的是，从用户的角度来看，整个用车服务预订流程全部是以自然语言的对话形式完成的，在使用语音输入的情况下，甚至可以全程都通过语音交流的形式完成。
70.图2是根据本发明的一个实施例的处理用车服务的方法200的示意流程图。作为一个示例，方法200可以由图1中的用车服务处理系统104来实施。
71.方法200开始于步骤202，接收来自用户的自然语言形式的用车服务请求消息。如之前提到的，本发明所提供的方案不需要用户通过诸如下拉菜单、选择定位等繁琐方式来提供订车所需的信息，而是可以通过自然语言的形式以对话方式完成用车预约。例如，可能接收到用户经由直接在微信中的消息收发界面中发送的诸如“我需要辆车下午3点从外滩去上海博物馆”之类的消息。这一消息既可以是文本形式，也可以是语音形式。
72.在步骤204，将接收到的用车服务请求消息处理成结构化数据形式的用车信息。作为一个示例，该步骤可由图1中的用车服务处理系统104中的自然语言处理模块108来执行。如之前提到的，如果用车服务请求消息是以语音形式提供的，则可通过各种语音识别技术先将语音转换成文本。
73.为了将自然语言转换成结构化数据，可采用任何现有的自然语言处理技术，并在此基础上针对本发明的应用场景进行专门的适配。更具体地，可以基于规则和机器学习算法来训练针对用车服务场景的语义理解引擎。例如，为了使机器能够更准确地理解用户的意图并从中提取出正确的用车服务相关信息，可以首先定义相关的规则。例如，可预先建立用户服务请求消息语料库并定义用车相关信息包含哪些具体字段。作为一个示例，可以通过邀请多位不同用户来表述其用车意图，例如让其用自己的习惯方式表述其在想要用车时会说的话。可以理解，用户的数量越多、用户各自的身份、经历、背景越丰富，收集到的针对同一用车意图的不同表述形式也越丰富，这将十分有助于提高理解的准确率。字段的设置则有助于将自然语言转换为结构化数据，同时也可简化机器的语义理解过程的复杂度。随后，通过所设定的规则以及所建立的训练语料库，可训练针对用车服务场景的语义理解引擎。这一训练过程可采用任何合适的机器训练方法，诸如基于神经网络的训练方法等等。
74.在步骤206，确定用车信息中是否包含预订用车服务所需的所有必要信息。例如，如之前提到的，可对照预定义的用车信息表来检查该用车消息中是否已包含预订用车服务所需的所有必要信息，包括但不限于用车人、用车时间、出发点和目的地。
75.作为一个可选示例，有时候用户的自然语言中提取出的信息可能并不准确，因此在确定步骤之前还可以先对不准确的信息进行完善。例如，用车人“我”可被完善为相应的用户真实姓名。此外，还可以基于用户简档和/或用户画像来完善某些信息，比如将上车点或目的地中的“公司”完善为用户提供的公司的具体地址。
76.若在步骤206中确定用车信息中缺少预订用车服务所需的一项或多项必要信息，则方法前进至步骤208，生成发送给用户的对话，以向所述用户获取所缺少的所述一项或多项必要信息。此外，针对某些不准确的信息也可以视为该信息的缺失。例如，用户的消息中
提到了“公司”，但用户的简档中并未记录公司的地址，这种情况也需要向用户进一步询问。
77.随后，方法返回到步骤202，再次从用户接收自然语言形式的消息并进行处理，随后再次判断是否已包含所有必要信息，直到确定用车信息中已包含预订用车服务所需的所有必要信息后，方法前进至步骤210，将用车信息发送给服务平台。服务平台可将用车信息进一步发布给一个或多个合作的用车服务提供商。可选地或附加地，在将必要用车信息发送给用车服务提供商之前，可基于用户简档和/或用户画像来生成发送给用户的对话，以向用户提供针对除必要信息以外的附加用车信息的推荐，诸如若用户未提到选订的车型或车内设施，则可以向用户提供这些方面的推荐。可选地，如之前提到的，服务平台可向用车服务处理系统提供服务提供商可提供的最新的服务信息，例如可供用户选择的各类选项，因此还可进一步针对这些选项(尤其是用户在当前提供的用车信息中没有提及的选项)向用户进行询问或推荐。最后，将用户针对这些推荐服务的反馈信息与之前的用车信息一起发送给服务平台。
78.在步骤212，基于服务平台返回的服务确认结果，生成发送给用户的对话，以向用户告知服务确认结果，例如“您的预约已成功”或者“很抱歉，您预约的时间无可用车辆，您是否要更换用车时间？”等等，诸如此类。至此，本次用车服务预订处理流程结束。
79.以上所已经描述的内容包括所要求保护主题的各方面的示例。当然，出于描绘所要求保护主题的目的而描述每一个可以想到的组件或方法的组合是不可能的，但本领域内的普通技术人员应该认识到，所要求保护主题的许多进一步的组合和排列都是可能的。从而，所公开的主题旨在涵盖落入所附权利要求书的精神和范围内的所有这样的变更、修改和变化。