CN111091221A - 一种出行等候容忍时间预测方法、系统、装置及存储介质 - Google Patents

Abstract

本发明提供了一种出行等候容忍时间预测方法、系统、装置及存储介质。所述方法包括以下一个或一个以上操作。可以获取当前订单的订单数据，所述订单数据包括下单时间和下单地点。可以确定等候容忍时间预测模型，所述等候容忍时间预测模型基于历史取消订单数据和与所述历史取消订单数据相关的历史数据训练后获得。可以基于所述等候容忍时间预测模型和所述当前订单的订单数据，确定所述当前订单的出行等候容忍时间。本发明在出行等候容忍时间预测过程中将综合考虑历史取消订单和与历史取消订单相关的历史数据，能够个性化的生成出行订单的用户的等候容忍时间。

Description

一种出行等候容忍时间预测方法、系统、装置及存储介质

技术领域

本发明涉及按需服务领域，更具体的，涉及一种预测出行等候容忍时间的方法、系统、装置及存储介质。

背景技术

当前，网约车服务已经变得越来越普遍，在某些供不应求的情况下例如，某一区域的运力无法满足该区域内的服务请求，系统后台可能会将该区域内的用车订单分配给距离该用车订单的发起者(即，乘客)的当前位置较远的司机。在这种情况下，乘客可能需要较长的时间等待司机接驾。当等待时间超过了乘客的容忍度时，乘客可能会取消用车订单，将导致订单取消比例上升，影响乘客乘车体验和订单成交量。目前，系统后台在进行订单分配时，未考虑乘客地域等候时间的容忍度。同时，不同乘客在不同时刻、不同出发地点对于等候时间的容忍度也有所不同。因此，在订单分配阶段综合考虑乘客的等候时间容忍度将成为影响乘客乘车体验以及提高订单成功率的重要因素。

发明内容

针对现有技术中对订单等候时间预测时不考虑乘客等候时间容忍度而导致预测准确率低的问题，本发明的在于提供一种预测出行等候容忍时间的方法、系统、装置及存储介质，采用基于历史取消订单数据以及与历史取消订单数据相关的历史数据训练后获得的预测模型，能够更加准确的进行等候容忍时间预测。

为了达到上述发明的目的，本发明提供的技术方案如下：

一种出行等候容忍时间预测方法。所述方法在可以在包括一个处理器和一个存储器的设备上实现。所述方法可以包括以下一个或一个以上操作。可以获取当前订单的订单数据，所述订单数据包括下单时间和下单地点。确定等候容忍时间预测模型，所述等候容忍时间预测模型基于历史取消订单数据和与所述历史取消订单数据相关的历史数据训练后获得。可以基于所述等候容忍时间预测模型和所述当前订单的订单数据，确定所述当前订单的出行等候容忍时间

在本发明中，所述历史取消订单数据包括以下至少一个：历史取消订单下单时间，历史取消订单下单地点以及历史取消订单等候时间，所述历史取消订单等候时间为下单时间至订单取消时间之间的时间间隔。

在本发明中，所述等候容忍时间预测模型基于以下训练方法获得。所述训练方法可以包括以下一个或一个以上操作。可以获取历史取消订单数据。可以获取与所述历史取消订单数据相关的历史数据。可以基于所述历史取消订单数据和所述历史取消订单数据相关的历史数据训练初始预测模型，确定所述等候容忍时间预测模型。

在本发明中，所述基于所述等候容忍时间预测模型和所述当前订单的订单数据，确定所述当前订单的出行等候容忍时间，包括以下一个或一个以上操作。可以确定所述当前订单的用户类型。可以基于所述用户类型，获取用户历史订单数据。可以基于所述订单数据、所述用户历史订单数据和所述等候时间预测模型，确定所述当前订单的出行等候容忍时间。

在本发明中，所述出行等候容忍时间预测方法可以进一步包括以下操作。可以基于所述出行等候容忍时间，分配所述当前订单。

在本发明中，所述出行等候容忍时间预测方法可以进一步包括以下一个或一个以上的操作。可以每隔一个预设时间间隔，获取新的历史取消订单数据以及与所述新的历史取消订单数据相关的历史数据。可以利用所述新的历史取消订单数据以及与所述历史取消订单数据相关的历史数据，更新所述等候容忍时间预测模型。

在本发明中，所述初始预测模型为回归模型。

一种出行等候容忍时间预测系统。所述系统包括获取模块、训练模块以及等候容忍时间预测模块。所述获取模块用于获取当前订单的订单数据，所述订单数据包括下单时间和下单地点。所述训练模块，用于确定等候容忍时间预测模型，所述等候容忍时间预测模型基于历史取消订单数据和与所述历史取消订单数据相关的历史数据训练后获得。所述等候容忍时间预测模块，用于基于所述等候容忍时间预测模型和所述当前订单的订单数据，确定所述当前订单的出行等候容忍时间。

一种出行等候容忍时间预测装置，所述装置包括处理器以及存储器；所述存储器用于存储指令，其特征在于，所述指令被所述处理器执行时，导致所述装置实现如上述任一项所述出行等候容忍时间预测方法对应的操作。

一种计算机可读存储介质，其特征在于，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机运行如上述任意一项所述出行等候容忍时间预测方法。

与现有技术相比，本发明的有益效果如下：

利用历史取消订单数据以及与历史取消订单数据对应的历史数据训练模型，得到训练完成的等候容忍时间模型后可以预测新订单的用户的等候容忍时间，相较于现有技术，综合考虑了用户的等候时间容忍度，提高了用户乘车体验及订单成功率。

附加的特征将在下面的描述中部分地阐述，并且对于本领域技术人员来说，通过查阅以下内容和附图将变得显而易见，或者可以通过实例的产生或操作来了解。本发明的特征可以通过实践或使用以下详细实例中阐述的方法、工具和组合的各个方面来实现和获得。

附图说明

根据示例性实施例可以进一步描述本申请。参考附图可以详细描述所述示例性实施例。所述实施例并非限制性的示例性实施例，其中相同的附图标记代表附图的几个视图中相似的结构，并且其中：

图1是根据本发明的一些实施例所示的一个示例性按需服务系统的示意图；

图2是根据本发明的一些实施例所示的一个示例性计算设备的示例性硬件组件和/或软件组件的示意图；

图3是根据本发明的一些实施例所示的一个示例性移动设备的示例性硬件组件和/或软件组件的示意图；

图4是根据本发明的一些实施例所示的一个示例性处理引擎的框图；

图5是根据本发明的一些实施例所示的确定当前订单出行等候容忍时间的示例性流程图；

图6是根据本发明的一些实施例所示的确定等候容忍时间预测模型的示例性流程图；

图7是根据本发明的一些实施例所示的确定当前订单的出行等候容忍时间的示例性流程图。

图8是根据本发明的一些实施例所述的更新所述等候容忍时间预测模型的示例性流程图。

具体实施方式

为了更清楚地说明本申请的实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。

如本申请和权利要求书中所示，除非上下文明确提示例外情形，

“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其他的步骤或元素。

虽然本申请对根据本申请的实施例的系统中的某些模块做出了各种引用，然而，任何数量的不同模块可以被使用并运行在车辆客户端和/或服务器上。所述模块仅是说明性的，并且所述系统和方法的不同方面可以使用不同模块。

本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，前面或下面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各种步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

本申请的实施例可以应用于不同的交通系统和/或移动终端，不同的交通系统包括但不限于陆地、水面航行、航空、航天等中的一种或几种的组合。例如，人力车、代步工具、汽车(例如，小型车、巴士、大型运输车等)、轨道交通(例如，火车、动车、高铁、地铁等)、船舶、飞机、飞船、卫星、热气球、无人驾驶的交通工具等。不同的移动终端包括但不限于智能手机、智能手表、摄像机、照相机、笔记本、平板电脑、个人数码助理(PDA)、车载电脑等移动设备。本申请的不同实施例应用场景包括但不限于运输业、仓储物流业、农业作业系统、城市公交系统、商业运营车辆等中的一种或几种的组合。应当理解的是，本申请的系统及方法的应用场景仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。

图1是根据本发明的一些实施例所示的一种按需服务系统100的示意图。例如，按需服务系统100可以是一个为交通运输服务提供服务的平台。按需服务系统100可以包括一个服务器110、一个或一个以上服务请求端120、一个存储设备130、一个或多个服务提供端140、一个网络150和一个信息源160。服务器110可以包括一个处理引擎112。

在一些实施例中，服务器110可以是一个单个的服务器或者一个服务器群组。所述服务器群可以是集中式的或分布式的(例如，服务器110可以是一个分布式的系统)。在一些实施例中，服务器110可以是本地的或远程的。例如，服务器110可以通过网络150访问存储在存储设备130、服务请求端120和/或服务提供端140中的信息和/或数据。再例如，服务器110可以直接连接到存储设备130、服务请求端120和/或服务提供端140以访问存储的信息和/或数据。在一些实施例中，服务器110可以在一个云平台上实现。仅仅举个例子，所述云平台可以包括私有云、公共云、混合云、社区云、分布云、云之间、多重云等或上述举例的任意组合。在一些实施例中，服务器110可以在与本申请图2或图3所示的计算设备上实现。例如，服务器110可以在如图2所示的一个计算设备200上实现，包括计算设备200中的一个或多个部件。再例如，服务器110可以在如图3所示的一个移动设备300上实现，包括计算设备300中的一个或多个部件。

在一些实施例中，服务器110可以包括一个处理引擎112。处理引擎112可以处理与服务请求相关的信息和/或数据以执行本申请描述的一个或多个功能。例如，处理引擎112可以预测服务请求订单的用户的等候容忍时间。在一些实施例中，处理引擎112可以包括一个或多个处理器(例如，单核处理器或多核处理器)。仅仅举个例子，处理引擎112可以包括一个或多个硬件处理器，例如中央处理器(CPU)、专用集成电路(ASIC)、专用指令集处理器(ASIP)、图像处理器(GPU)、物理运算处理器(PPU)、数字信号处理器(DSP)、现场可编辑门阵列(FPGA)、可编辑逻辑器件(PLD)、控制器、微控制器单元、精简指令集计算机(RISC)、微处理器等或上述举例的任意组合。

服务请求端120和服务提供端140可以统称为用户，它可以是直接与服务订单相关联的个人、工具或其他实体，例如服务订单的请求者与提供服务者。服务请求端120的用户可以是乘客。在本申请中，“乘客”和

“服务请求端”可以互换使用。服务提供端140的用户可以是司机。在本申请中，“司机”和“服务提供端”可以互换使用。在一些实施例中，服务请求端120可以包括但不限于台式电脑120-1、笔记本电脑120-2，车载内置设备120-3、移动设备120-4等或其任意组合。服务请求端120可以在线发送服务请求。例如，服务请求端120可以基于当前所在位置及目的地发送网约车订单。在一些实施例中，车载内置设备120-3可以包括但不限于个车载电脑、车载抬头显示(HUD)、车载自动诊断系统(OBD)等或其任意组合。在一些实施例中，移动设备120-4可以包括但不限于智能手机、个人数码助理(Personal Digital Assistance，PDA)、平板电脑、掌上游戏机、智能眼镜、智能手表、可穿戴设备、虚拟显示设备、显示增强设备等或其任意组合。在一些实施例中，服务请求端120可以将服务订单信息发送至按需服务系统100中的一个或多个设备中。例如，服务请求端120可以将服务订单信息发送至服务器110进行处理。服务提供端140也可以包括上述类似的设备中的一种或多种。

存储设备130可以存储数据和/或指令。在一些实施例中，存储设备130可以存储从服务请求端120和/或服务提供端140获得的数据。在一些实施例中，存储设备130可以存储供服务器110执行或使用的数据和/或指令，服务器110可以通过执行或使用所述数据和/或指令以实现本申请描述的示例性方法。在一些实施例中，存储设备130可以包括大容量存储器、可移动存储器、挥发性读写存储器、只读存储器(ROM)等或上述举例的任意组合。示例性的大容量存储器可以包括磁盘、光盘、固态硬盘等。示例性的可移动存储器可以包括闪存盘、软盘、光盘、记忆卡、压缩硬盘、磁带等。示例性的挥发性只读存储器可以包括随机存储器(RAM)。示例性的随机存储器可以包括动态随机存储器(DRAM)、双数据率同步动态随机存储器(DDRSDRAM)、静态随机存储器(SRAM)、可控硅随机存储器(T-RAM)和零电容存储器(Z-RAM)等。示例性的只读存储器可以包括掩蔽型只读存储器(MROM)、可编程只读存储器(PROM)、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)、压缩硬盘只读存储器(CD-ROM)和数字多功能硬盘只读存储器等。在一些实施例中，存储设备130可以在一个云平台上实现。仅仅举个例子，所述云平台可以包括私有云、公共云、混合云、社区云、分布云、云之间、多重云等或上述举例的任意组合。

在一些实施例中，存储设备130可以与网络150连接以实现与按需服务系统100中的一个或多个部件(例如，服务器110、服务请求端120、服务提供端140等)之间的通信。按需服务系统100的一个或多个部件可以通过网络150访问存储在存储设备130中的数据或指令。在一些实施例中，存储设备130可以直接与按需服务系统100的一个或多个部件(例如，服务器110、服务请求端120、服务提供端140等)连接或通信。在一些实施例中，存储设备130可以是服务器110的一部分。

网络150可以促进信息和/或数据的交换。在一些实施例中，按需服务系统100中的一个或多个部件(例如，服务器110、存储设备130、服务请求端120和服务提供端140等)可以通过网络150向按需服务100中的其他部件发送信息和/或数据。例如，服务器110可以通过网络150从服务请求端120和/或服务提供端140获取/得到请求。在一些实施例中，网络150可以是有线网络或无线网络中的任意一种，或其组合。例如，网络150可以包括电缆网络、有线网络、光纤网络、远程通信网络、内联网、互联网、局域网(LAN)、广域网(WAN)、无线局域网(WLAN)、城域网(MAN)、公共开关电话网络(PSTN)、蓝牙网络、ZigBee网络、近场通讯(NFC)网络等或上述举例的任意组合。在一些实施例中，网络130可以包括一个或多个网络接入点。例如，网络150可能包括有线或无线网络接入点，如基站和/或互联网交换点150-1、150-2等等。通过接入点，按需服务系统100的一个或多个部件可能连接到网络150以交换数据和/或信息。

信息源160是为按需服务系统100提供其他信息的一个源。信息源160可以用于为系统提供与服务相关的信息，例如，天气情况、交通信息、法律法规信息、新闻信息、生活资讯、生活指南信息等。信息源160可以是一个单独的中央服务器的形式存在，也可以是以多个通过网络连接的服务器的形式存在，还可以是以大量的个人设备形式存在。当信息源150以大量个人设备形式存在时，这些设备可以通过一种用户生成内容(user-generatedcontents)的方式，例如向云端服务器上传文字、语音、图像、视频等，从而是云端服务器连通与其连接的众多个人设备一起组成信息源160。

图2是根据本发明的一些实施例所示的一种示例性计算设备200的示意图。服务器110、服务请求端120、存储设备130和/或服务提供端140可以在计算设备200上实现。例如，处理引擎112可以在计算设备200上实现并被配置为实现本申请中所披露的功能。

计算设备200可以包括用来实现本申请所描述的系统的任意部件。例如，处理引擎112可以在计算设备200上通过其硬件、软件程序、固件或其组合实现。为了方便起见图中仅绘制了一台计算机，但是本申请所描述的与按需服务系统100相关的计算功能可以以分布的方式、由一组相似的平台所实施，以分散系统的处理负荷。

计算设备200可以包括与网络连接的通信端口250，用于实现数据通信。计算设备200可以包括一个处理器(例如，CPU)220，可以以一个或多个处理器的形式执行程序指令。示例性的电脑平台可以包括一个内部总线210、不同形式的程序存储器和数据存储器包括，例如，硬盘270、和只读存储器(ROM)230或随机存储器(RAM)240，用于存储由计算机处理和/或传输的各种各样的数据文件。示例性的计算设备可以包括存储在只读存储器230、随机存储器240和/或其他类型的非暂时性存储介质中的由处理器220执行的程序指令。本申请的方法和/或流程可以以程序指令的方式实现。计算设备200也包括输入/输出部件260，用于支持电脑与其他部件之间的输入/输出。计算设备200也可以通过网络通讯接收本披露中的程序和数据。

为理解方便，图2中仅示例性绘制了一个处理器。然而，需要注意的是，本申请中的计算设备200可以包括多个处理器，因此本申请中描述的由一个处理器实现的操作和/或方法也可以共同地或独立地由多个处理器实现。例如，如果在本申请中，计算设备200的处理器执行步骤1和步骤2，应当理解的是，步骤1和步骤2也可以由计算设备200的两个不同的处理器共同地或独立地执行(例如，第一处理器执行步骤1，第二处理器执行步骤2，或者第一和第二处理器共同地执行步骤1和步骤2)。

图3是根据本发明的一些实施例所示的一个示例性的移动设备300的示例性硬件和/或软件的示意图。服务请求端120和/或服务提供端140可以在移动设备300上实现。如图3所示，移动设备300可以包括一个通讯单元310、一个显示单元320、一个图形处理器330、一个处理器340、一个输入/输出单元350、一个内存360和一个存储单元390。移动设备300中还可以包括一个总线或者一个控制器。在一些实施例中，移动操作系统370和一个或多个应用程序380可以从存储单元390加载到内存360中，并由处理器340执行。在一些实施例中，应用程序380可以接收和显示与处理引擎112有关的图像处理或其他信息的信息。输入/输出单元350可以实现用户与按需服务系统100的交互，并将交互相关信息通过网络150提供给按需服务系统100中的其他部件，如服务器110。

为了实现本申请中描述的各种模块、单元及其功能，计算机硬件平台可以用作这里提到的一个或多个元件的硬件平台。一个拥有用户界面元件的计算机可以用于实现个人计算机(PC)或者其它任何形式的工作站或终端设备。通过合适的编程，一个计算机也可以充当一台服务器。

图4是根据本发明的一些实施例所示的示例性处理引擎112的框图。如果所示，处理引擎112可以包括获取模块410、训练模块420和等候容忍时间预测模块430。

获取模块410可以获取数据。在一些实施例中，获取模块410可以从按需服务系统100、服务请求端120、存储设备130、服务提供端140、网络150、信息源160或本申请中公开的能够存储数据的任何设备或组件中的一个或一个以上获取数据。所获取的数据可以包括订单信息、车辆信息、环境信息、用户指令、算法、模型等中的一种或一种以上的组合。在一些实施例中，获取模块410可以获取当前订单的订单数据。所述订单数据包括与所述当前订单相关的信息，例如，当前订单的下单时间，当前订单的下单地点等。所述订单数据还可以包括当前订单的终点等。在一些实施例中，获取模块410可以获取历史取消订单数据和与所述历史取消订单数据相关的历史数据。所述历史取消订单数据可以包括但不限于历史取消订单下单时间，历史取消订单下单地点，历史取消订单等候时间等或其任意组合。所述历史数据可以是与历史取消订单的用户的出行服务请求对应的数据，包括但不限于用户的历史订单总数、不同类型的订单的数量(例如，快车订单数量，专车订单数量，顺风车订单数量等)、历史取消订单数总量、历史取消订单比例(历史取消的订单占历史订单总数的比例)、历史取消订单平均等候时间、历史成交订单平均等候时间、历史订单的平均里程、历史订单的最长里程、历史订单的最短里程、历史平均消费金额等或其任意组合。在一些实施例中，获取模块410可以将所述历史取消订单数据和与所述历史取消订单数据相关的历史数据传输至处理引擎112的其他模块(例如，训练模块420)用于后续操作，例如，模型训练。在一些实施例中，获取模块410可以每个一段预设时间间隔获取新的获取新的历史取消订单数据以及与所述新的历史取消订单数据相关的历史数据，并将上述数据传输至训练模块420，用于模型的更新。

训练模块420可以确定等候容忍时间预测模型。在一些实施例中，训练模块420可以基于所述历史取消订单数据和所述历史取消订单数据相关的历史数据训练初始预测模型，确定所述等候容忍时间预测模型。所述初始预测模型可以是回归模型。训练模块420可以将所述历史取消订单数据和所述历史取消订单数据相关的历史数据作为样本输入，对所述初始预测模型进行训练。所述初始预测模型可以是回归模型，包括但不限于线性回归模型(Linear Regression)、逻辑回归模型(Logistics Regression)、多项式回归模型(Polynomial Regression)、逐步回归模型(Stepwise Regression)、岭回归模型(RidgeRegression)、套索回归模型(Lasso Regression)、ElasticNet回归模型(ElasticNetRegression)等或其任意组合。在训练过程中，可以利用验证集对模型进行验证，并根据验证结果(例如，模型处于欠拟合和/或过拟合状态)对模型参数进行调整以使模型达到最佳状态。所述验证集中的数据与所述初始预测模型的训练数据独立同分布，且没有交集。在一些实施例中，当满足预设条件时，可以停止模型训练，并将最终的模型作为所述等候容忍时间预测模型输出。所述预设条件可以是训练样本数达到预定值，或模型性能达到预设指标。例如，当输入的训练样本数达到一万个、五万个或十万个时，可以停止模型训练。又例如，通过模型参数稳定性检测方法(比如，Chow检测、LR检测、虚拟变量检测或贝叶斯检测)对模型参数进行检测，确定参数稳定后，可以停止模型训练。在一些实施例中，训练模块420可以基于由获取模块410获取的新的获取新的历史取消订单数据以及与所述新的历史取消订单数据相关的历史数据，对所述等候容忍时间预测模型进行更新。

等候容忍时间预测模块430可以用于对所述当前订单进行等候容忍时间预测。在一些实施例中，等候容忍时间预测模型430可以将所述当前订单的订单数据直接输入至所述等候容忍时间预测模型，确定所述当前订单的出行等候容忍时间。所述出行等候容忍时间可以指所述当前订单的用户愿意等待司机来接驾的最长时间。在一些实施例中，等候容忍时间预测模块430可以将所述当前订单的用户进行分类，并基于用户类型获取用户订单数据。例如，等候容忍时间预测模块430可以通过查询所述当前订单的用户历史上的用车服务订单，包括成交的订单和/或被取消的订单。没有被取消的订单的用户可以被分为一个类型的用户(例如，一类用户或第一用户)，有取消的订单的用户可以被分为另一个类型的用户(例如，二类用户或第二用户)。等候容忍时间预测模块430可以将所述当前订单的订单数据和/或所述用户历史订单数据输入至所述等候容忍时间预测模型中，对所述当前订单的等候容忍时间进行预测。例如，对于有被取消的订单的用户，可以将当前订单数据和被取消订单的订单数据输入至所述等候容忍时间预测模型中进行预测。又例如，对于没有被取消的订单的用户，可以将当前订单的数据输入至所述等候容忍时间预测模型中进行预测。在一些实施例中，等候容忍时间预测模块430可以根据所述当前订单的下单地点周围交通环境以及在下单时间时的天气情况对所述当前订单的等候容忍时间进行调整，例如，延长或缩减。例如，若当前订单的下单地点周围出现交通拥堵，则可以延长当前订单的等候容忍时间(比如，一分钟)。若在当前订单的下单时间时处于雨天状态，则可以缩短当前订单的等候容忍时间(比如，一分钟)。

应当理解，图4所示的系统及其模块可以利用各种方式来实现。例如，在一些实施例中，系统及其模块可以通过硬件、软件或者软件和硬件的结合来实现。其中，硬件部分可以利用专用逻辑来实现；软件部分则可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域技术人员可以理解上述的方法和系统可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本申请的系统及其模块不仅可以有诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用例如由各种类型的处理器所执行的软件实现，还可以由上述硬件电路和软件的结合(例如，固件)来实现。

需要注意的是，以上描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该系统的原理后，可以在不背离这一原理的情况下，对实施上述方法和系统的应用领域进行形式和细节上的各种修正和改变。例如，获取模块410和训练模块420可以集成在一起成为一个模块，同时实现数据获取以及模型训练的功能。然而，这些变化和修改不脱离本申请的范围。

图5是根据本发明的一些实施例所示的确定当前订单出行等候容忍时间的示例性流程图。在一些实施例中，流程500可以通过处理逻辑来执行，该处理逻辑可以包括硬件(例如，电路、专用逻辑、可编程逻辑、微代码等)、软件(运行在处理设备上以执行硬件模拟的指令)等或其任意组合。图5所示的用于确定当前订单出行等候容忍时间的流程500中的一个或多个操作可以通过图1所示的按需服务系统100实现。例如，流程500可以以指令的形式存储在存储设备150中，并由处理引擎140执行调用和/或执行(例如，图2所示的计算设备200的处理器220、图3所示的移动设备300的中央处理器340)。

在510中，可以获取当前订单的订单数据。操作510可以有获取模块410执行。在一些实施例中，所述当前订单可以是终端120的用户在当前时刻发起的用车订单。所述当前订单可以是交通服务请求订单，例如，快车订单，出租车订单，专车订单，顺风车订单，代驾订单等或其任意组合。在一些实施例中，所述订单数据包括与所述当前订单相关的信息，例如，当前订单的下单时间，当前订单的下单地点等。所述下单时间可以指用户(例如，乘客)发送订单至服务器的时间，例如，发送至服务器110的时间。所述下单地点可以指用车服务的起始点，或用车服务的服务提供者(例如，司机)接驾乘客的地点。在一些实施例中，所述订单数据还可以包括用车服务的终点，是否接受动态调价，是否接受服务模式调整等或其任意组合。

在520中，可以确定等候容忍时间预测模型。操作520可以由训练模块420执行。在一些实施例中，等候容忍时间可以指用户在发出用车请求后愿意等待司机来接驾的最长时间。例如，假定某一用户的等候容忍时间是3分钟，当该用户在10:00发出服务订单后，如果接单的司机在10:03分还没有到达订单的出发地接驾该用户，则用户可能会取消该订单，选择其他方式出行，比如，乘坐公交、地铁，或重新发起一份新的用车服务订单。在一些实施例中，所述等候容忍时间预测模型可以用来对用车服务订单的用户的等候容忍时间进行预测。所述等候容忍时间预测模型可以基于历史取消订单和与所述历史取消订单相关的历史数据训练后获得。所述历史取消订单可以是指被取消的历史用车服务订单。例如，一星期前某一用户因为司机的接驾时间超过了该用户的等候容忍时间而取消了用车服务订单，该用车服务订单可被指定为历史取消订单。所述与历史取消订单相关的历史数据可以是与历史取消订单的用户的出行服务请求对应的数据。例如，对于某一历史取消订单，与该历史取消订单相关的历史数据可以包括该历史取消订单的用户在该历史取消订单之前所有的用车服务订单记录，该用户的用户信息，该历史取消订单被取消时的天气道路情况等。所述历史取消订单可以是在一定预设时间段内(例如，从当前时刻往前一年内)被用户取消的历史用车服务订单，也可以是所有的被用户取消的历史用车服务订单(例如，从有数据记录开始时到当前时刻之间的时间内的所有的被取消的历史用车服务订单)。在一些实施例中，可以将所述历史取消订单和与所述历史取消订单相关的历史数据作为输入样本进行模型训练得到所述等候容忍时间预测模型。关于所述等候容忍时间预测模型的训练方法的描述，可以在本申请的其他地方找到(例如，图6)，在此不在赘述。

在530中，可以基于所述等候容忍时间预测模型和所述当前订单的订单数据，确定所述当前订单的出行等候容忍时间。操作530可以由等候容忍时间预测模块430执行。在一些实施例中，可以将所述当前订单的订单数据直接输入至所述等候容忍时间预测模型，确定所述当前订单的出行等候容忍时间。所述出行等候容忍时间可以指所述当前订单的用户愿意等待司机来接驾的最长时间。例如，所述出行等候容忍时间为五分钟，表示所述当前订单的用户在下单后愿意等待司机五分钟时间让其来接驾。超过五分钟后，用户可能取消订单。在一些实施例中，可以将所述当前订单的用户进行分类，并基于用户分类获取用户的历史出行订单。所述当前订单数据和所述历史出行订单将被输入至所述等候容忍时间预测模型以获取所述当前订单的出行等候容忍时间。关于确定所述当前订单的等候容忍时间的描述，可以在本申请的其他地方找到(例如，图7)，在此不在赘述。

需要注意的是，以上描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该系统的原理后，可以在不背离这一原理的情况下，对实施上述方法和系统的应用领域进行形式和细节上的各种修正和改变。

图6是根据本发明的一些实施例所示的确定等候容忍时间预测模型的示例性流程图。在一些实施例中，流程600可以通过处理逻辑来执行，该处理逻辑可以包括硬件(例如，电路、专用逻辑、可编程逻辑、微代码等)、软件(运行在处理设备上以执行硬件模拟的指令)等或其任意组合。图6所示的用于确定等候容忍时间预测模型的流程600中的一个或多个操作可以通过图1所示的按需服务系统100实现。例如，流程600可以以指令的形式存储在存储设备150中，并由处理引擎140执行调用和/或执行(例如，图2所示的计算设备200的处理器220、图3所示的移动设备300的中央处理器340)。

在610中，可以获取历史取消订单数据。操作610可以由获取模块410执行。在一些实施例中，所述历史取消订单数据可以是被取消的历史用车服务订单的数据。所述历史取消订单数据可以是在一定预设时间段内(例如，从当前时刻往前一年内)被用户取消的历史用车服务订单的数据，也可以是所有的被用户取消的历史用车服务订单(例如，从有数据记录开始时到当前时刻之间的时间内的所有的被取消的历史用车服务订单)的数据。对于某一历史取消订单，所述历史取消订单数据可以包括历史取消订单下单时间，历史取消订单下单地点，历史取消订单等候时间等。所述历史取消订单等候时间可以是该订单时间至订单被取消时间之间的时间间隔。例如，上周一上午10：00某用户发起了用车服务订单，服务起始点在金融大厦。五分钟后(即，10:05)因为等待接驾时间超过了该用户的容忍时间，该用户取消了订单。则针对该取消订单，所述历史取消订单下单时间为周一上午10:00，所述历史取消订单下单地点为金融大厦，所述历史取消订单等候时间为五分钟。

在一些实施例中，可以获取预设时间段内的历史取消订单数据，例如，一个月，一个季度，一年等。在一些实施例中，可以所有的历史取消订单数据，例如，存储在存储设备130中的所有的历史取消订单数据。获取模块410可以通过网络150访问存储设备130并读取存储在其中的历史取消订单数据。

在620中，可以获取与所述历史取消订单数据相关的历史数据。操作620可以由获取模块410执行。在一些实施例中，所述历史数据可以是与历史取消订单的用户的出行服务请求对应的数据。对于某一特定的历史取消订单，与该历史取消订单相关的历史数据可以包括在该历史取消订单的下单时间之前，该历史取消订单的用户的历史订单总数、不同类型的订单的数量(例如，快车订单数量，专车订单数量，顺风车订单数量等)、历史取消订单数总量、历史取消订单比例(历史取消的订单占历史订单总数的比例)、历史取消订单平均等候时间、历史成交订单平均等候时间、历史订单的平均里程、历史订单的最长里程、历史订单的最短里程、历史平均消费金额等。例如，在某一历史取消订单发起时间之前，该取消订单的用户一共发起过10次用车服务请求订单，其中7次快车服务请求订单，3次出租车服务请求订单。在10次用车服务请求订单中，该用户取消了2次服务请求订单。对于取消的服务请求订单，其中，用户分别在下单后7分钟和10分钟后取消了服务请求订单。对于成交的服务请求订单，用户在下单后分别等待了4分钟、6分钟、4分钟、5分钟、5分钟、3分钟、4分钟和5分钟后，司机到达订单起始点接到了用户。七个成交订单，行驶的里程分别为5.4公里、5.2公里、6.7公里、6公里、5.5公里、5.7公里、5.1公里和5.5公里，用户的消费金额分别是9.8元、9.5元、10.7元、10.2元、9.7元、9.8元、15元和15元。则历史订单总数为10，快车订单数量为7，出租车订单数量为3，历史取消订单总量为2，历史取消订单比例为20％(2/10)，历史取消订单平均等候时间为8.5分钟(17/2)，历史成交订单平均等候时间为4.5分钟(36/8)，历史订单的平均里程为5.6公里(45.1/8)，历史订单的最长里程为6.7公里，历史订单的最短里程为5.1公里，历史平均消费金额为11.2元(89.7/8)。在一些实施例中，所述历史数据还可以包括历史取消订单的用户的注册信息，例如，年龄，性别，电话号码等。

在630中，可以基于所述历史取消订单数据和所述历史取消订单数据相关的历史数据训练初始预测模型，确定所述等候容忍时间预测模型。操作630可以由训练模块420执行。在一些实施例中，所述初始预测模型可以是回归模型，包括但不限于线性回归模型(Linear Regression)、逻辑回归模型(Logistics Regression)、多项式回归模型(Polynomial Regression)、逐步回归模型(Stepwise Regression)、岭回归模型(RidgeRegression)、套索回归模型(Lasso Regression)、ElasticNet回归模型(ElasticNetRegression)等或其任意组合。所述初始预测模型包括多个初始参数，例如，对于线性回归模型，可以用以下方程式表示：

y＝a+bx+e

其中，a，b和e可以被指定为模型参数。当模型训练未开始时，a，b和e的初始值可以被指定为所述初始参数。所述初始参数可以是按需服务系统100的默认值，也可以根据不同的应用场景进行变换，还可以进行人工设置，在此不做限制。

在一些实施例中，所述历史取消订单数据和与所述历史订单数据相关的历史数据将作为训练样本对所述初始预测模型进行训练。在训练过程过，所述初始参数可以进行不断的调整以达到更好的预测性能。当预设条件满足时，训练将停止并获取最终的模型作为所述等候容忍时间预测模型。所述预设条件可以按需服务系统100预先存储的条件，也可以是人工设置的条件。所述预设条件包括但不限于训练样本达到预定数量，模型性能达到预设指标等或其任意组合。当满足预设条件时，可以将模型输出。

需要注意的是，以上描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该系统的原理后，可以在不背离这一原理的情况下，对实施上述方法和系统的应用领域进行形式和细节上的各种修正和改变。

图7是根据本发明的一些实施例所示的确定当前订单的出行等候容忍时间的示例性流程图。在一些实施例中，流程700可以通过处理逻辑来执行，该处理逻辑可以包括硬件(例如，电路、专用逻辑、可编程逻辑、微代码等)、软件(运行在处理设备上以执行硬件模拟的指令)等或其任意组合。图7所示的用于确定当前订单的出行等候容忍时间的流程700中的一个或多个操作可以通过图1所示的按需服务系统100实现。例如，流程700可以以指令的形式存储在存储设备150中，并由处理引擎140执行调用和/或执行(例如，图2所示的计算设备200的处理器220、图3所示的移动设备300的中央处理器340)。

在710中，可以确定所述当前订单的用户类型。操作710可以由等候容忍时间确定模块430执行。在一些实施例中，所述用户类型可以包括第一用户和第二用户。所述第一用户可以是没有订单取消记录的用户。例如，新注册的用户(即，没有过用车服务记录的用户)可以被指定为第一用户。或，在所述当前订单的下单时间之前，某用户请求的用车订单全部成交，该用户可以被指定为第一用户。所述第二用户可以是已有订单取消记录的用户。例如，在所述当前订单下单时间之前，所述第二用户已经取消过一个或一个以上的用车服务订单。在一些实施例中，等候容忍时间确定模块430可以通过网络150访问存储在存储设备130中的数据，基于所述当前订单的用户的注册信息(例如，电话号码或ID)，获取用户在按需服务系统100中的存档数据，来确定所述当前订单的用户类型。

在720中，可以基于所述用户类型，获取用户历史订单数据。操作720可以用等候容忍时间确定模块430执行。在一些实施例中，所述用户历史订单数据可以是所述当前订单的用户请求的所有的用车服务订单数据。对于从未有过用车服务记录的第一用户，所述用户历史订单数据可以为空。对于所有用车服务订单全部成交的第一用户，所述用户历史订单数据可以包括但不限于所有成交用车服务订单的数量、不同类型的用车服务订单数量、订单下单时间、订单下单地点、订单等候时间、订单平均等候时间、订单平均里程、订单最长里程、订单最短里程、订单平均消费金额等或其任意组合。对于第二用户，所述用户历史订单数据可以包括但不限于所有用车服务订单的数量、不同类型的用车订单数量、被取消的订单数量、被取消的订单数量占比(被取消订单占所有订单的比例)、成交订单平均等候时间、取消订单平均等候时间(即、所述历史取消订单等候时间)、成交订单平均里程、成交订单最长里程、成交订单最短里程、成交订单平均消费金额等或其任意组合。在一些实施例中，在一些实施例中，等候容忍时间确定模块430可以通过网络150访问存储在存储设备130中的数据以获取所述用户历史订单数据。

在730中，可以基于所述订单数据、所述用户历史订单数据和所述等候容忍时间预测模型，确定所述当前订单的出行等候容忍时间。操作730可以由等候容忍时间确定模块430执行。在本申请中，所述出行等候容忍时间可以和所述等候容忍时间互换使用。在一些实施例中，可以将所述订单数据、所述用户历史订单数据输入至所述等候容忍时间预测模型，获取所述当前订单的出行等候容忍时间。所述出行等候容忍时间可以指所述当前订单的用户愿意等待司机来接驾的最长时间。例如，所述出行等候容忍时间为五分钟，表示所述当前订单的用户在下单后愿意等待司机五分钟时间让其来接驾。超过五分钟后，用户可能取消订单。在一些实施例中，对于所述第一用户，等候容忍时间确定模块430可以基于所述当前订单的订单数据和所述等候容忍时间预测模型，预测所述当前订单的出行等候容忍时间。对于所述第二用户，因在模型训练过程中，已经将所述第二用户的用户历史订单数据中与取消订单相关的数据作为训练样本。在对所述当前订单的出行等候容忍时间进行预测时，可以基于所述订单数据、所述用户历史订单数据和所述等候容忍时间预测模型，预测所述第二用户的个性化出行等候容忍时间。

在一些实施例中，所述出行等候容忍时间可以根据所述当前订单的下单地点周围交通环境以及在下单时间时的天气情况进行调整。例如，若所述当前订单的下单地点附近出现交通拥堵情况，则所述出行等候容忍时间可以进行延长。又例如，若在所述当前订单的下单时间时，正处于雨天状况，则所述出行等候容忍时间可以进行缩减。所述出行等候容忍时间的增加值和缩减值可以是按需服务系统100的预设值，也可以进行人工设置，在此不做限制。

在740中，可以基于所述出行等候容忍时间，分配所述当前订单。服务器110可以根据所述出行等候容忍时间，将所述当前订单分配给能够在所述出行等候容忍时间之内到达所述当前订单的下单地点(起始地)接驾乘客的司机。例如，某一用户的出行等候容忍时间为5分钟，在用户所处区域内有两辆空载车辆(车辆A和车辆B)可以为该用户提供出行用车服务。车辆A从所处位置到达服务起始点为4分钟，车辆B从所处到达服务起始点为7分钟。则该用户发出的用车服务请求订单将会被分配给车辆A。在一些实施例中，若没有满足条件的车辆存在(即，没有车辆能够在所述出行等候容忍时间内到达所述当前订单的下单地点的车辆)，则服务器110可以向所述当前订单的用户发送提示信息，用于提示用户耐心等待，或提示用户变换出行用车类型(例如，由快车服务转换至专车服务)等。

需要注意的是，以上描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该系统的原理后，可以在不背离这一原理的情况下，对实施上述方法和系统的应用领域进行形式和细节上的各种修正和改变。

图8是根据本发明的一些实施例所示的更新所述等候容忍时间预测模型的示例性流程图。在一些实施例中，流程800可以通过处理逻辑来执行，该处理逻辑可以包括硬件(例如，电路、专用逻辑、可编程逻辑、微代码等)、软件(运行在处理设备上以执行硬件模拟的指令)等或其任意组合。图7所示的用于更新所述等候容忍时间预测模型的流程800中的一个或多个操作可以通过图1所示的按需服务系统100实现。例如，流程800可以以指令的形式存储在存储设备150中，并由处理引擎140执行调用和/或执行(例如，图2所示的计算设备200的处理器220、图3所示的移动设备300的中央处理器340)。

在810中，可以每隔一个预设时间间隔，获取新的历史取消订单数据以及与所述新的历史取消订单数据相关的历史数据。操作810可以有获取模块410执行。在一些实施例中，所述预设时间间隔可以是一天、一星期、一个月、一季度、半年、一年等。所述新的历史取消订单数据以及与所述新的历史取消订单数据相关的历史数据可以是在所述预设时间间隔内产生的被取消的用车服务订单的数据和与被取消的用车服务订单的用户相对应的数据。例如，假定所述预设时间间隔是一天，则在一天内产生的取消订单将会被获取作为所述新的历史取消订单数据，其对应的在一天内产生的用户的出行服务请求对用的数据将被作为所述新的历史取消订单数据相关的历史数据。

在820中，可以利用所述新的历史取消订单数据以及与所述历史取消订单数据相关的历史数据，更新所述等候容忍时间预测模型。操作820可以由训练模块420执行。在一些实施例中，可以将所述新的历史取消订单数据以及与所述新的历史取消订单数据相关的历史数据作为样本，输入至所述等候容忍时间预测模型对上述模型进行继续训练来调整模型参数达到提升性能的目的。在一些实施例中，可以将所述新的所述新的历史取消订单数据以及与所述新的历史取消订单数据相关的历史数据与所述历史取消订单数据以及与所述历史取消订单数据相关的历史数据进行分别合并，得到更新后的历史取消订单数据以及更新后的历史数据。所述更新后的历史取消订单数据以及更新后的历史数据可以对所述等候容忍时间模型进行再训练，以达到更新模型的目的。

需要注意的是，以上描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该系统的原理后，可以在不背离这一原理的情况下，对实施上述方法和系统的应用领域进行形式和细节上的各种修正和改变。

以上内容描述了本申请和/或一些其他的示例。根据上述内容，本申请还可以作出不同的变形。本申请披露的主题能够以不同的形式和例子所实现，并且本申请可以被应用于大量的应用程序中。后文权利要求中所要求保护的所有应用、修饰以及改变都属于本申请的范围。

同时，本申请使用了特定词语来描述本申请的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一替代性实施例”并不一定是指同一实施例。此外，本申请的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

本领域技术人员能够理解，本申请所披露的内容可以出现多种变型和改进。例如，以上所描述的不同系统组件都是通过硬件设备所实现的，但是也可能只通过软件的解决方案得以实现。例如：在现有的服务器上安装系统。此外，这里所披露的位置信息的提供可能是通过一个固件、固件/软件的组合、固件/硬件的组合或硬件/固件/软件的组合得以实现。

所有软件或其中的一部分有时可能会通过网络进行通信，如互联网或其他通信网络。此类通信能够将软件从一个计算机设备或处理器加载到另一个。例如：从按需服务系统的一个管理服务器或主机计算机加载至一个计算机环境的硬件平台，或其他实现系统的计算机环境，或与提供订单拼成率预测所需要的信息相关的类似功能的系统。因此，另一种能够传递软件元素的介质也可以被用作局部设备之间的物理连接，例如光波、电波、电磁波等，通过电缆、光缆或者空气实现传播。用来载波的物理介质如电缆、无线连接或光缆等类似设备，也可以被认为是承载软件的介质。在这里的用法除非限制了有形的“储存”介质，其他表示计算机或机器“可读介质”的术语都表示在处理器执行任何指令的过程中参与的介质。

本申请各部分操作所需的计算机程序编码可以用任意一种或多种程序语言编写，包括面向对象编程语言如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB.NET、Python等，常规程序化编程语言如C语言、Visual Basic、Fortran 2003、Perl、COBOL 2002、PHP、ABAP，动态编程语言如Python、Ruby和Groovy，或其他编程语言等。该程序编码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或服务器上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，例如，局域网(LAN)或广域网(WAN)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(SaaS)。

此外，除非权利要求中明确说明，本申请所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本申请流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本申请实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本申请对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

一些实施例中使用了描述属性、数量的数字，应当理解的是，此类用于实施例描述的数字，在一些示例中使用了修饰词“大约”、“近似”或“大体上”来修饰。除非另外说明，“大约”、“近似”或“大体上”表明所述数字允许有±20％的变化。相应地，在一些实施例中，说明书和权利要求中使用的数值参数均为近似值，该近似值根据个别实施例所需特点可以发生改变。在一些实施例中，数值参数应考虑规定的有效数位并采用一般位数保留的方法。尽管本申请一些实施例中用于确认其范围广度的数值域和参数为近似值，在具体实施例中，此类数值的设定在可行范围内尽可能精确。

针对本申请引用的每个专利、专利申请、专利申请公开物和其他材料，如文章、书籍、说明书、出版物、文档、物件等，特将其全部内容并入本申请作为参考。与本申请内容不一致或产生冲突的申请历史文件除外，对本申请权利要求最广范围有限制的文件(当前或之后附加于本申请中的)也除外。需要说明的是，如果本申请附属材料中的描述、定义、和/或术语的使用与本申请所述内容有不一致或冲突的地方，以本申请的描述、定义和/或术语的使用为准。

最后，应当理解的是，本申请中所述实施例仅用以说明本申请实施例的原则。其他的变形也可能属于本申请的范围。因此，作为示例而非限制，本申请实施例的替代配置可视为与本申请的教导一致。相应地，本申请的实施例不限于本申请明确介绍和描述的实施例。

Claims (10)

1.一种出行等候容忍时间预测方法，其特征在于，所述方法包括：

获取当前订单的订单数据，所述订单数据包括下单时间和下单地点；

确定等候容忍时间预测模型，所述等候容忍时间预测模型基于历史取消订单数据和与所述历史取消订单数据相关的历史数据训练后获得；以及

基于所述等候容忍时间预测模型和所述当前订单的订单数据，确定所述当前订单的出行等候容忍时间。

2.根据权利要求1所述的方法，其特征在于，所述历史取消订单数据包括以下至少一个：历史取消订单下单时间，历史取消订单下单地点以及历史取消订单等候时间，所述历史取消订单等候时间为下单时间至订单取消时间之间的时间间隔。

3.根据权利要求1所述的方法，其特征在于，所述等候容忍时间预测模型基于以下训练方法获得，所述训练方法包括：

获取历史取消订单数据；

获取与所述历史取消订单数据相关的历史数据；以及

基于所述历史取消订单数据和所述历史取消订单数据相关的历史数据训练初始预测模型，确定所述等候容忍时间预测模型。

4.根据权利要求1所述的方法，其特征在于，所述基于所述等候容忍时间预测模型和所述当前订单的订单数据，确定所述当前订单的出行等候容忍时间，包括：

确定所述当前订单的用户类型；

基于所述用户类型，获取用户历史订单数据；以及

基于所述订单数据、所述用户历史订单数据和所述等候容忍时间预测模型，确定所述当前订单的出行等候容忍时间。

5.根据权利要求1所述的方法，其特征在于，所述方法进一步包括：

基于所述出行等候容忍时间，分配所述当前订单。

6.根据权利要求1所述的方法，其特征在于，所述方法进一步包括：

每隔一个预设时间间隔，获取新的历史取消订单数据以及与所述新的历史取消订单数据相关的历史数据；以及

利用所述新的历史取消订单数据以及与所述新的历史取消订单数据相关的历史数据，更新所述等候容忍时间预测模型。

7.根据权利要求3所述的方法，其特征在于，所述初始预测模型为回归模型。

8.一种出行等候时间预测系统，其特征在于，所述系统包括获取模块、训练模块以及等候容忍时间预测模块，其中

所述获取模块，用于获取当前订单的订单数据，所述订单数据包括下单时间和下单地点；

所述训练模块，用于确定等候容忍时间预测模型，所述等候容忍时间预测模型基于历史取消订单数据和与所述历史取消订单数据相关的历史数据训练后获得；

所述等候容忍时间预测模块，用于基于所述等候容忍时间预测模型和所述当前订单的订单数据，确定所述当前订单的出行等候容忍时间。

9.一种出行等候容忍时间预测装置，所述装置包括处理器以及存储器；所述存储器用于存储指令，其特征在于，所述指令被所述处理器执行时，导致所述装置实现如权利要求1至7中任一项所述出行等候容忍时间预测方法对应的操作。

10.一种计算机可读存储介质，其特征在于，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机运行如权利要求1至7中任意一项所述出行等候容忍时间预测方法。

Images