CN111861620A - 一种订单处理方法和系统 - Google Patents

Abstract

本申请提供一种订单处理方法和系统。所述方法包括：获取乘客的订单请求，以及与所述订单请求相关的信息；基于与所述订单请求相关的信息，利用订单取消概率模型，确定所述乘客的订单取消概率；至少基于所述订单取消概率，对所述订单请求进行分配。

Description

一种订单处理方法和系统

技术领域

本申请涉及按需服务领域，特别涉及一种订单处理方法和系统。

背景技术

随着移动通信技术的快速发展，越来越多的用户通过安装在移动终端上的叫车软件进行打车，然而大量的因素可能导致用户在叫车过程中取消订单。例如，司机接驾距离较远、司机接驾预估到达时间较长、上车点区域内车辆供不应求用户需较长时间等待司机接驾等。由于不同用户可接受的等待接驾时间或接驾距离不同，当等待接驾时间或等待接驾距离超过用户的可接受范围时，用户就会取消订单，导致平台完单量和用户乘车体验降低。

目前，打车平台在进行订单分配时，未充分考虑不同用户在不同上车区域、不同订单发起时间、不同上车时间的可接受接驾时间或可接受接驾距离，导致订单取消率较高。因此，希望可以提供一种订单处理方法和系统，综合考虑不同用户的可接受接驾时间或可接受接驾距离，进行个性化订单分配，以提高订单完单量和用户乘车体验。

发明内容

本申请的一个方面提供一种订单处理方法。所述方法包括：获取乘客的订单请求，以及与所述订单请求相关的信息；基于与所述订单请求相关的信息，利用订单取消概率模型，确定所述乘客的订单取消概率；至少基于所述订单取消概率，对所述订单请求进行分配。

本申请的另一方面提供一种订单处理系统。所述系统包括：获取模块，用于获取乘客的订单请求，以及与所述订单请求相关的信息；订单取消概率确定模块，用于基于与所述订单请求相关的信息，利用订单取消概率模型，确定所述乘客的订单取消概率；订单分配模块，用于至少基于所述订单取消概率，对所述订单请求进行分配。

本申请的另一方面提供一种订单处理的装置。所述装置包括至少一个存储介质及至少一个处理器；所述至少一个存储介质用于存储计算机指令；所述至少一个处理器用于执行所述计算机指令，以实现如前所述的订单处理的方法。

本申请的另一方面提供一种计算机可读存储介质。所述存储介质存储有计算机指令，当所述计算机指令被处理器执行时，实现如前所述的订单处理的方法。

本申请的另一方面提供一种订单处理方法。所述方法包括：获取乘客的订单请求，以及与所述订单请求相关的信息；至少基于订单取消概率，输出与订单处理相关的提示内容；所述订单取消概率基于与所述订单请求相关的信息，利用订单取消概率模型确定。

本申请的另一方面提供一种订单处理系统。所述系统包括：获取模块，用于获取乘客的订单请求，以及与所述订单请求相关的信息；显示模块，用于至少基于订单取消概率，输出与订单处理相关的提示内容；所述订单取消概率基于与所述订单请求相关的信息，利用订单取消概率模型确定。

本申请的另一方面提供一种订单处理的装置。所述装置包括至少一个存储介质及至少一个处理器；所述至少一个存储介质用于存储计算机指令；所述至少一个处理器用于执行所述计算机指令，以实现如前所述的订单处理的方法。

本申请的另一方面提供一种计算机可读存储介质。所述存储介质存储有计算机指令，当所述计算机指令被处理器执行时，实现如前所述的订单处理的方法。

附图说明

本申请将以示例性实施例的方式进一步说明，这些示例性实施例将通过附图进行详细描述。这些实施例并非限制性的，在这些实施例中，相同的编号表示相同的结构，其中：

图1是根据本申请一些实施例所示的订单处理系统的应用场景示意图；

图2是根据本申请一些实施例所示的一种订单处理系统的模块图；

图3是根据本申请一些实施例所示的一种订单处理方法的示例性流程图；

图4是根据本申请一些实施例所示的对订单请求进行分配的方法的示例性流程图；

图5是根据本申请一些实施例所示的一种订单处理系统终端的模块图；

图6是根据本申请一些实施例所示的一种订单处理方法的示例性流程图。

具体实施方式

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

应当理解，本文使用的“系统”、“装置”、“单元”和/或“模组”是用于区分不同级别的不同组件、元件、部件、部分或装配的一种方法。然而，如果其他词语可实现相同的目的，则可通过其他表达来替换所述词语。

如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。

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

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

本申请描述的“乘客”、“乘客端”、“乘车人”、“用户”、“用户终端”、“顾客”、“请求者”、“服务请求者”、“消费者”、“消费方”、“使用请求者”等是可以互换的，是指需要或者订购服务的一方，可以是个人，也可以是工具。同样地，本申请描述的“司机”、“司机端”、“提供者”、“供应者”、“服务提供者”、“服务者”、“服务方”等也是可以互换的，是指提供服务或者协助提供服务的个人、工具或者其他实体等。另外，本申请描述的“用户”可以是需要或者订购服务的一方，也可以是提供服务或者协助提供服务的一方。

图1是根据本申请一些实施例所示的订单处理系统的应用场景示意图。该订单处理系统100可以预估乘客的订单取消概率，并至少基于订单取消概率，对订单请求进行分配。该订单处理系统100可以是用于互联网服务的线上服务平台。例如，该订单处理系统100可以是运输服务的线上运输服务平台。在一些实施例中，该订单处理系统100可以应用于网约车服务，例如出租车呼叫、快车呼叫、专车呼叫、小巴呼叫、拼车、公交服务、司机雇佣和接送服务等。在一些实施例中，该订单处理系统100还可以应用于代驾服务、快递、外卖等。订单处理系统100可以包括服务器110、网络120、乘客终端130、司机终端140、存储设备150、信息源160和定位系统170。该服务器110可以包含处理设备112。

服务器110可以处理来自订单处理系统100的至少一个组件或外部数据源(例如，云数据中心)的数据和/或信息。服务器110可以与乘客终端130通信以提供在线服务的各种功能。例如，服务器110可以从乘客终端130发送的订单请求中提取上车信息。又例如，服务器110可以利用订单取消概率模型，确定乘客的订单取消概率。

在一些实施例中，服务器110可以是单个处理设备，也可以是处理设备组。处理设备组可以是经由接入点连接到网络120的集中式处理设备组，或者经由至少一个接入点分别连接到网络120的分布式处理设备组。在一些实施例中，服务器110可以本地连接到网络120或者与网络120远程连接。例如，服务器110可以经由网络120访问存储在乘客终端130、司机终端140、存储设备150和/或信息源160中的信息和/或数据。又例如，存储设备150可以用作服务器110的后端数据存储器。在一些实施例中，服务器110可以在云平台上实施。仅作为示例，所述云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。

在一些实施例中，服务器110可以包括处理设备112。处理设备112可以处理与本申请中描述的至少一个功能相关的信息和/或数据。在一些实施例中，处理设备112可以执行订单处理系统100的主要功能。

在一些实施例中，服务器110可以包括处理设备112。处理设备112可以处理与本申请中描述的至少一个功能相关的信息和/或数据。在一些实施例中，处理设备112可以执行订单处理系统100的主要功能。在一些实施例中，处理设备112可以执行与本申请中描述的方法和系统相关的其他功能。在一些实施例中，处理设备112可包括至少一个处理单元(例如，单核处理设备或多核处理设备)。仅作为示例，处理设备112包括中央处理单元(CPU)、专用集成电路(ASIC)、专用应用指令集处理器(ASIP)、图形处理单元(GPU)、物理处理单元(PPU)、数字信号处理器(DSP)、现场可程序门阵列(FPGA)、可程序逻辑设备(PLD)、控制器、微控制器单元、精简指令集计算机(RISC)、微处理器等，或其任意组合。

网络120可以促进信息和/或数据的交换。在一些实施例中，订单处理系统100中的至少一个组件(例如，服务器110、乘客终端130、存储设备150等)可以经由网络120将信息和/或数据发送到订单处理系统100中的其他组件。例如，处理设备112可以经由网络120从存储设备150获得多个历史订单数据。

在一些实施例中，网络120可以为任意形式的有线或无线网络，或其任意组合。仅作为示例，网络120可以包括缆线网络、有线网络、光纤网络、远程通信网络、内部网络、互联网、局域网络(LAN)、广域网络(WAN)、无线局域网络(WLAN)、城域网(MAN)、公共开关电话网络(PSTN)、蓝牙网络、ZigBee网络、近场通讯(NFC)网络等或其任意组合。在一些实施例中，网络120可以包括至少一个网络接入点。例如，网络120可以包括有线或无线网络接入点，如基站和/或互联网交换点120-1、120-2、……，通过订单处理系统100的至少一个部件可以连接到网络120以交换数据和/或信息。

乘客终端130可以经由网络120与服务器110通信。在一些实施例中，乘客终端130的使用者可以是服务请求者本人。在一些实施例中，乘客终端130的使用者可以是除服务请求者以外的其他人。例如，在网约车服务中，乘客终端130的使用者可以是乘车人本人，也可以是乘车人的亲戚、朋友等帮乘车人下单的人。

在一些实施例中，乘客终端130可以包括但不限于移动设备130-1、平板计算机130-2、膝上型计算机130-3等或其任意组合。在一些实施例中，移动设备130-1可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、增强现实设备等，或其任意组合。在一些实施例中，智能家居设备可以包括智能照明设备、智能电器控制设备、智能监控设备、智能电视、智能摄像机、对讲机等，或其任意组合。在一些实施例中，该可穿戴设备可包括智能手环、智能鞋袜、智能眼镜、智能头盔、智能手表、智能衣服、智能背包、智能配件等或其任意组合。在一些实施例中，智能移动设备可以包括智能电话、个人数字助理(PDA)、游戏设备、导航设备、销售点(POS)等，或其任意组合。在一些实施例中，虚拟现实设备和/或增强型虚拟现实设备可以包括虚拟现实头盔、虚拟现实眼镜、虚拟现实补丁、增强现实头盔、增强现实眼镜、增强现实补丁等或其任意组合。例如，虚拟现实设备和/或增强现实设备可以包括Google Glass^TM、Oculus Rift^TM、Hololens^TM或Gear VR^TM等。

在一些实施例中，乘客终端130可以将运输服务需求发送至服务器110进行处理。在一些实施例中，乘客终端130可以是一带有定位技术的装置，以确定乘客和/或乘客终端130的位置，并发送给订单处理系统100中的一个或多个设备，例如服务器110。

司机终端140可以经由网络120与服务器110通信。司机终端140的使用者可以是司机本人。在一些实施例中，司机终端140的使用者可以是除司机以外的其他人。例如，在网约车服务中，司机终端140的使用者可以是司机本人，也可以是帮助司机接单的人。

在一些实施例中，司机终端140可以是与乘客终端130类似或相同的装置。在一些实施例中，司机终端140可以将运输服务需求发送至服务器110进行处理。在一些实施例中，司机终端140可以是一带有定位技术的装置，以确定司机和/或司机终端140的位置，并发送给订单处理系统100中的一个或多个设备，例如服务器110。

存储设备150可以储存数据和/或指令。例如，存储设备150可以存储订单发起时间、司机接驾的行驶距离、司机接驾的预估到达时间、订单轨迹信息、基础信息等。在一些实施例中，存储设备150可以存储从服务器110、乘客终端130、司机终端140和/或信息源160获得/获取的数据。在一些实施例中，存储设备150可以存储处理设备112可以执行的数据和/或指令，服务器110可以通过执行或使用所述数据和/或指令以实现本申请描述的示例性方法。在一些实施例中，存储设备150可包括大容量存储器、可移动存储器、易失性读写存储器、只读存储器(ROM)等或其任意组合。示例性的大容量存储器可以包括磁盘、光盘、固态磁盘等。示例性可移动存储器可以包括闪存驱动器、软盘、光盘、存储卡、压缩盘、磁带等。示例性易失性读写存储器可以包括随机存取存储器(RAM)。示例性RAM可包括动态随机存取存储器(DRAM)、双倍数据速率同步动态随机存取存储器(DDRSDRAM)、静态随机存取存储器(SRAM)、晶闸管随机存取存储器(T-RAM)和零电容随机存取存储器(Z-RAM)等。示例性只读存储器可以包括掩模型只读存储器(MROM)、可编程只读存储器(PROM)、可擦除可编程只读存储器(PEROM)、电可擦除可编程只读存储器(EEPROM)、光盘只读存储器(CD-ROM)和数字多功能磁盘只读存储器等。在一些实施例中，所述存储设备150可在云平台上实现。仅作为示例，所述云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。

在一些实施例中，存储设备150可以连接到网络120以与订单处理系统100中的一个或以上组件(例如，服务器110、乘客终端130、司机终端140等)通信。订单处理系统100中的一个或以上组件可以通过网络120访问存储设备150中存储的数据或指令。在一些实施例中，存储设备150可以与系统100中的一个或以上组件(例如，服务器110、乘客终端130、司机终端140等)直接连接或通信。在一些实施例中，存储设备150可以是服务器110的一部分。

信息源160是为订单处理系统100提供其他信息的一个源。在一些实施例中，信息源160可以用于为系统提供历史订单信息、路况信息、天气信息等。信息源160可以是一个单独的中央服务器的形式存在，也可以是以多个通过网络连接的服务器的形式存在，还可以是以大量的个人设备形式存在。当信息源160以大量个人设备形式存在时，这些设备可以通过一种用户生成内容(user-generated contents)的方式，例如向云端服务器上传文字、语音、图像、视频等，从而是云端服务器连通与其连接的众多个人设备一起组成信息源160。

定位系统170可以提供与位置相关的信息。位置相关的信息可包括对象的位置、高度、速度或加速度、当前时间等。在一些实施例中，订单处理系统100中也可以包括其他具有定位功能的设备，这类具有定位功能的设备可以与其他设备(例如，乘客终端130、司机终端140)通信以确定其他设备的位置。例如，定位设备可以确定司机或者司机终端140的位置。又例如，定位设备可以确定乘客或者乘客终端130的位置。在一些实施例中，乘客终端130、司机终端140可以是具有定位功能的设备。例如，所述定位功能的设备可以用于定位乘客和/或乘客终端130的位置，所述定位功能的设备可以用于定位司机和/或司机终端140的位置。

应当注意的是，上述有关订单处理系统100的描述仅仅是为了示例和说明，而不限定本申请的适用范围。对于本领域技术人员来说，在本申请的指导下可以对订单处理系统100进行各种修正和改变。然而，这些修正和改变仍在本申请的范围之内。

图2是根据本申请一些实施例所示的一种订单处理系统的模块图。所述订单处理系统可以包括获取模块210、订单取消概率确定模块220、订单分配模块230。这些模块可以是处理设备112的至少一部分的硬件电路。这些模块也可以作为应用程序或由处理设备112读取或执行的指令实现。此外，这些模块可以是硬件电路和应用/指令的任何组合。例如，当处理设备执行应用程序/指令时，这些模块可以是处理设备112的一部分。

获取模块210可以用于获取信息。在一些实施例中，获取模块210可以获取乘客的订单请求，以及与所述订单请求相关的信息。例如，获取模块210可以获取乘客的订单请求，以及与所述订单请求相关的信息。在一些实施例中，获取模块210可以从订单处理系统100中的一个或以上组件(例如，乘客终端130、司机终端140、存储设备150、信息源160等)获取与服务请求有关的信息。所获取的信息可以包括但不限于订单信息、乘客信息、司机信息、车辆信息、环境信息等信息。在一些实施例中，与所述订单请求相关的信息可以包括但不限于订单发起时间、上车地点、上车时间、目的地、司机接驾的行驶距离、司机接驾的预估到达时间、乘客历史信息、乘客需求信息等或其任意组合。所述乘客历史信息可以是与当前订单请求对应的乘客的历史订单信息，包括但不限于乘客历史完成订单数量、乘客历史取消订单数量、乘客历史完成订单/乘客历史取消订单对应的预估到达时间、乘客历史完成订单/乘客历史取消订单对应的司机接驾行驶距离、乘客历史完成订单/乘客历史取消订单的价格等或其任意组合。所述乘客需求信息可以是与当前订单请求对应的乘客的可接受等待司机接驾的意愿信息，包括但不限于乘客可接受的等待时间、乘客可接受的等待接驾距离等。在一些实施例中，获取模块210还可以获取所述订单请求中上车地点区域的供需比。

订单取消概率确定模块220可以用于确定乘客的订单取消概率。例如，订单取消概率确定模块220可以用于基于与所述订单请求相关的信息，利用订单取消概率模型，确定所述乘客的订单取消概率。所述订单取消概率可以表示服务器110获取乘客订单请求后，利用常规派单算法为该订单虚拟分配了一个司机，针对该分配的虚拟司机乘客可能取消订单的概率。所述订单取消概率模型可以是神经网络模型或回归模型。在一些实施例中，订单取消概率确定模块220可以将订单请求以及与订单请求相关的信息输入到订单取消概率模型中，对所述订单的取消概率进行预测。在一些实施例中，订单取消概率确定模块220可以根据订单请求的订单发起地点的周围路况以及订单发起时的天气状况对所述订单的取消概率进行调整。关于利用订单取消概率模型确定乘客的订单取消概率的更多内容可以参见图3及相关描述，在此不再赘述。

订单分配模块230可以用于对订单请求进行分配。例如，订单分配模块230可以用于至少基于所述订单取消概率，对所述订单请求进行分配。在一些实施例中，订单分配模块230可以根据订单取消概率和订单请求中上车地点区域的供需比，对订单请求进行分配。例如，判断订单请求中上车地点区域的供需比是否大于第一预设阈值；如果所述供需比大于第一预设阈值，进一步判断所述订单取消概率是否大于第二预设阈值；如果所述订单取消概率大于第二预设阈值，将所述订单请求优先分配给预估到达时间小于第三预设阈值的司机，或者如果所述订单取消概率不大于第二预设阈值，采用常规派单算法对所述订单进行分配。又例如，判断订单请求中上车地点区域的供需比是否大于第一预设阈值；如果所述供需比不大于第一预设阈值，进一步判断所述订单取消概率是否大于第二预设阈值；如果所述订单取消概率大于第二预设阈值，延迟分配所述订单请求，或者如果所述订单取消概率不大于第二预设阈值，将所述订单请求优先分配给司机。关于根据订单取消概率和供需比对订单请求进行分配的更多内容可以参见图4及相关描述，在此不再赘述。

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

需要注意的是，以上对于订单处理系统及其模块的描述，仅为描述方便，并不能把本申请限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该系统的原理后，可能在不背离这一原理的情况下，对各个模块进行任意组合，或者构成子系统与其他模块连接。例如，在一些实施例中，获取模块210、订单取消概率确定模块220、订单分配模块230可以是一个系统中的不同模块，也可以是一个模块实现上述的两个或两个以上模块的功能。例如，获取模块210和订单取消概率确定模块220可以是两个模块，也可以是一个模块同时具有获取订单信息和确定订单取消概率等功能。又例如，获取模块210、订单取消概率确定模块220和订单分配模块230可以是一个系统中的不同模块，也可以是一个模块实现上述的两个或两个以上模块的功能。再例如，各个模块可以共用一个存储模块，各个模块也可以分别具有各自的存储模块。诸如此类的变形，均在本申请的保护范围之内。

图3是根据本申请一些实施例所示的一种订单处理方法的示例性流程图。在一些实施例中，所述订单处理方法300可以由处理设备112实施。

步骤310，获取乘客的订单请求，以及与所述订单请求相关的信息。具体的，步骤310可以由获取模块210执行。

在一些实施例中，乘客可以通过安装在乘客终端130中的应用程序发送订单请求，处理设备112中的订单获取模块210可以从乘客终端130接收订单请求。在一些实施例中，订单请求可以包括实时订单请求或者预约订单请求。例如，所述实时订单请求可以是要求司机立即或者在接近订单发起时间的特定时间范围(例如，1min、3min、5min)内执行接驾服务的请求。所述预约订单请求可以是要求司机在乘客指定时间(例如，当天9:30、当天13:00、第二天6:00)内执行接驾服务的请求。在一些实施例中，订单请求可以是不同类型交通服务请求。例如，快车订单请求、出租车订单请求、豪华车订单请求、专车订单请求、顺风车订单请求、代驾订单请求等或其任意组合。

在一些实施例中，与所述乘客的订单请求相关的信息可以包括但不限于订单发起时间、上车地点、上车时间、目的地、司机接驾的行驶距离、司机接驾的预估到达时间等或其任意组合。在一些实施例中，前述信息可以由获取模块210从乘客的订单请求中直接获取。所述订单发起时间可以指乘客发送订单请求至服务器的时间。所述上车地点可以指司机接驾乘客的上车地点。所述上车时间可以指乘客指定的司机提供接驾服务的时间，或者可以是服务器110根据乘客下单地点与上车地点之间的距离预计的上车时间。所述目的地可以指司机完成服务订单的地点，也就是乘客下车地点。所述司机接驾的行驶距离可以指服务器110利用常规派单算法为该订单虚拟分配了一个司机，该司机当前定位位置与乘客上车地点之间的距离。例如，所述司机接驾的行驶距离为1.3km，表示发起订单请求的用户的上车地点与接单司机当前定位位置间的距离为1.3km，该司机需要行驶1.3km才能到达乘客上车点进行接驾。所述司机接驾的预估到达时间可以指服务器110利用常规派单算法为该订单虚拟分配了一个司机，该司机从其当前定位位置到达乘客上车地点进行接驾所需要的时间。例如，所述司机接驾的预估到达时间为2min，表示乘客发起订单请求后需要等待2min，接单司机才能到达用户上车点提供接驾服务。

在一些实施例中，获取模块210可以通过网络120访问读取存储在存储设备150中的数据，根据所述订单请求的乘客信息(例如，用户名、ID等)获取该乘客的历史打车数据，从所述历史打车数据中提取到与该订单请求相关的信息。在一些实施例中，与所述订单请求相关的信息还可以包括乘客历史信息、乘客需求信息等。在一些实施例中，所述乘客历史信息可以是与当前订单请求对应的乘客的历史订单信息，包括但不限于乘客历史完成订单数量、乘客历史取消订单数量、乘客历史完成订单/乘客历史取消订单对应的预估到达时间、乘客历史完成订单/乘客历史取消订单对应的司机接驾行驶距离、乘客历史完成订单/乘客历史取消订单的价格等或其任意组合。其中，所述乘客历史完成订单数量可以指乘客利用订单处理系统已完成的历史用车订单数量。所述乘客历史取消订单数量可以指被乘客取消的历史用车订单数量。例如，乘客发出用车请求后主动取消的订单，或者系统取消的乘客未完成的订单。所述乘客历史完成订单/乘客历史取消订单对应的预估到达时间可以指乘客历史完成订单或者乘客历史取消订单中，对从乘客发出订单请求开始到司机接驾乘客所用的预估时间。例如，乘客历史完成订单中的司机预估到达时间为3min，表示司机从其接到订单的当前定位位置到达乘客上车点进行接驾，需要乘客等待3min。又例如，乘客历史取消订单中的司机预估到达时间为5min，表示司机从其接到订单的当前定位位置到达乘客上车点进行接驾，需要乘客等待5min，但由于乘客可能无法接受等待5min，可能会取消该订单，选择其他方式出行，比如，坐公交车、坐地铁、或者重新发一个订单请求。所述乘客历史完成订单/乘客历史取消订单对应的司机接驾行驶距离可以指司机历史接单时的定位位置与乘客的上车地点间的距离。例如，乘客历史完成订单对应的司机接驾行驶距离为1.5km，由于该距离乘客可以接受，所以乘客愿意等待司机前来接驾。又例如，乘客历史取消订单对应的司机接驾行驶距离为3.8km，由于该乘客可能接受的最大司机接驾行驶距离为3km，当该订单中司机接驾行驶距离超出该乘客可接受的范围后，该乘客取消了该订单。在一些实施例中，所述乘客需求信息可以是与当前订单请求对应的乘客的可接受等待司机接驾的意愿信息，包括但不限于乘客可接受的等待时间、乘客可接受的等待接驾距离等。所述乘客可接受的等待时间可以指乘客可以接受司机前来接驾的最长等待时间。例如，所述乘客可接受的等待时间为6min，表示乘客发起订单请求后愿意等待司机6min让其前来接驾，如果超过6min，乘客可能取消订单。所述乘客可接受的等待接驾距离可以指乘客可以接受司机前来接驾的最长行驶距离。例如，所述乘客可接受的等待接驾距离为5km，表示乘客发起订单请求后愿意等待司机从5km远的位置前来接驾，如果超过5km，乘客可能取消订单。在一些实施例中，与所述订单请求相关的信息还可以包括车辆类型、运力供需比、路况信息、天气信息等或其任意组合。

步骤320，基于与所述订单请求相关的信息，利用订单取消概率模型，确定所述乘客的订单取消概率。具体的，步骤320可以由订单取消概率确定模块220执行。

在一些实施例中，订单取消概率确定模块220可以通过所述订单取消概率模型处理与所述订单请求相关的信息，来确定订单取消概率。具体的，可以将与所述订单请求相关的信息输入订单取消概率模型，获取所述订单请求的订单取消概率。所述订单取消概率可以表示服务器110获取乘客订单请求后，利用常规订单分配策略为该订单虚拟分配一个司机，针对该分配的虚拟司机乘客可能取消订单的概率。例如，当虚拟分配的司机距离乘客上车点距离较远时(例如，5.9km)，由于司机从5.9km处驶来进行接驾可能会需要乘客等待一段时间(例如，8min)，乘客可能不愿意等待8min，导致该乘客取消订单的概率可能较高(例如，0.9)。又例如，当虚拟分配的司机距离乘客上车点距离较近时(例如，0.7km)，由于司机可能仅需要1min就可以驶到乘客上车点进行接驾，该乘客取消订单的概率可能较低(例如，0.1)。

在一些实施例中，可以将与所述历史订单请求相关的历史数据作为样本输入对初始机器学习模型进行训练，以得到订单取消概率模型。在一些实施例中，所述与所述历史订单请求相关的历史数据可以包括不限于历史订单发起时间、上车地点、上车时间、目的地、司机接驾的行驶距离、司机接驾的预估到达时间、乘客历史信息、乘客需求信息等或其任意组合。所述乘客历史信息可以包括但不限于乘客历史完成订单数量、乘客历史取消订单数量、乘客历史完成订单/乘客历史取消订单对应的预估到达时间、乘客历史完成订单/乘客历史取消订单对应的司机接驾行驶距离、乘客历史完成订单/乘客历史取消订单的价格等或其任意组合。所述乘客需求信息可以包括但不限于乘客可接受的等待时间、乘客可接受的等待接驾距离等。

在一些实施例中，所述初始机器学习模型可以包括但不限于神经网络模型、回归模型、极端梯度提升(XGBoost)模型、梯度提升决策树(GBDT)模型等。优选地，所述初始机器学习模型可以是神经网络模型或回归模型。例如，所述订单取消概率模型可以为神经网络模型，包括但不限于深度神经网络模型(DNN)、前馈神经网络模型、径向基函数神经网络模型(RBF)、Kohonen自组织神经网络模型、递归神经网络模型(RNN)、卷积神经网络模型(CNN)等或其任意组合。又例如，所述初始机器学习模型可以为回归模型，包括但不限于线性回归模型(Linear Regression)、逻辑回归模型(Logistics Regression)、多项式回归模型(Polynomial Regression)、逐步回归模型(Stepwise Regression)、岭回归模型(RidgeRegression)、套索回归模型(Lasso Regression)、ElasticNet回归模型(ElasticNetRegression)等或其任意组合。

在一些实施例中，模型在训练过程中，模型的初始参数可以不断调整以达到更好的预测性能。例如，当满足预设条件时，停止训练并获取最终的模型作为所述订单取消概率模型。所述预设条件可以包括但不限于模型性能达到预设指标、达到预设训练次数等。

在一些实施例中，订单取消概率确定模块220可以提取所述与所述订单请求相关的信息的一个或多个特征，并将所述提取的特征输入到订单取消概率模型，获取所述订单请求的订单取消概率。在一些实施例中，可以将与所述历史订单请求相关的历史数据作为样本数据，提取与所述历史订单请求相关的信息的一个或多个特征，根据所述提取的特征和样本数据，训练初始机器学习模型，获得订单取消概率模型。在一些实施例中，从所述与历史订单请求相关的信息中提取的特征可以包括但不限于历史订单发起时间、上车地点、上车时间、目的地、司机接驾的行驶距离、司机接驾的预估到达时间、乘客历史信息、乘客需求信息等或其任意组合。所述乘客历史信息可以包括但不限于乘客历史完成订单数量、乘客历史取消订单数量、乘客历史完成订单/乘客历史取消订单对应的预估到达时间、乘客历史完成订单/乘客历史取消订单对应的司机接驾行驶距离、乘客历史完成订单/乘客历史取消订单的价格等或其任意组合。所述乘客需求信息可以包括但不限于乘客可接受的等待时间、乘客可接受的等待接驾距离等。所述订单取消概率模型可以是神经网络模型或回归模型。在一些实施例中，所述样本数据包括正样本和负样本。所述正样本表示该条历史订单请求未被乘客取消。所述负样本表示该条历史订单请求被乘客取消。在一些实施例中，所述正样本和负样本可分别用二进制值标记。例如，正样本可以标记为“1”，负样本可以标记为“0”。在一些实施例中，可以将正样本和负样本中每一个样本的特征输入到初始机器学习模型中对模型进行训练。指示历史打车订单请求是否被取消和/或被取消的相应概率可以是标签(即，输出)。在一些实施例中，所述初始机器学习模型可以包括但不限于神经网络模型、回归模型、极端梯度提升(XGBoost)模型、梯度提升决策树(GBDT)模型等。优选地，所述初始机器学习模型可以是神经网络模型或回归模型。应该理解的是，训练模型可以包括训练其他类型的模型。本申请中训练模型的类型的描述不是限制性的。在一些实施例中，模型在训练过程中，模型的初始参数可以不断调整以达到更好的预测性能。

步骤330，至少基于所述订单取消概率，对所述订单请求进行分配。具体的，步骤330可以由订单分配模块230执行。

在一些实施例中，获取模块210可以获取订单请求中上车地点区域的供需比，所述上车地点区域为包括所述上车地点在内的具有设定覆盖面积的地理区域。所述供需比表示订单请求中包括上车地点在内的一定范围区域内可用车辆数量与该区域内订单请求数量的比值。

在一些实施例中，订单分配模块230可以根据订单取消概率和订单请求中上车地点区域的供需比，对所述订单请求进行分配。在一些实施例中，如果供需比大于第一预设阈值，进一步判断订单取消概率是否大于第二预设阈值；响应于所述订单取消概率大于第二预设阈值，将所述订单请求优先分配给预估到达时间小于第三预设阈值的司机，或者如果所述订单取消概率不大于第二预设阈值，采用常规订单分配策略对所述订单进行分配。所述常规订单分配策略可以是指不考虑订单取消概率的任意一种派单方式。例如，服务器110获取乘客的订单请求后，选取位于订单中上车点预设区域范围内的司机作为候选司机，将订单请求按照排队顺序依次分配给候选司机。在一些实施例中，如果供需比不大于第一预设阈值，进一步判断订单取消概率是否大于第二预设阈值；如果所述订单取消概率大于第二预设阈值，延迟分配所述订单请求，或者如果所述订单取消概率不大于第二预设阈值，将所述订单请求优先分配给司机。关于对订单请求进行分配的更多内容可以参见图4及相关描述，在此不再赘述。

图4是根据本申请一些实施例所示的对订单请求进行分配的方法的示例性流程图。在一些实施例中，所述对订单请求进行分配过程400可以由处理设备112实施执行。

步骤410，获取所述订单请求中上车地点区域的供需比。具体的，步骤410可以由获取模块210执行。

在一些实施例中，服务器110获取订单请求后，可以基于订单请求中上车地点确定该上车点一定范围区域内的供需比。例如，供需比较大时，表示该区域范围内可用车辆较多，用户预计等待派单时长较短；供需比较小时，表示该区域范围内可用车辆较少，用户预计等待派单时长可能较长。具体的，服务器110可以获取订单请求中上车地点一定范围区域内可用车辆数量以及该区域内订单请求数量，通过计算所述可用车辆数量与订单请求数量的比值得到供需比。在一些实施例中，所述上车地点一定范围区域内可用车辆可以是与上车地点距离小于预设阈值(例如，3km、4km等)范围内的可用车辆，或者可以是上车地点所属网格区域内的可用车辆。所述可用车辆可以包括空载车辆、载有乘客但未载满的车辆、预计空闲车辆(当前为非空闲状态，预计一段时间后为空闲车辆)等。所述网格区域可以是矩形、六边形等规则或不规则的形状，每个网格区域的大小可以相同也可以不同。

步骤420，根据所述供需比和所述订单取消概率，对所述订单请求进行分配。具体的，步骤420可以由订单分配模块230执行。

在一些实施例中，订单分配模块230可以确定所述供需比是否大于第一预设阈值。在一些实施例中，如果所述供需比大于第一预设阈值，表示在该订单上车点一定范围内提供运输服务的车辆较多，进一步判断订单取消概率是否大于第二预设阈值；响应于所述订单取消概率大于第二预设阈值，将所述订单请求优先分配给预估到达时间小于第三预设阈值的司机，或者，响应于所述订单取消概率不大于第二预设阈值，采用常规订单分配策略对所述订单进行分配。例如，订单请求中上车地点区域的供需比大于第一预设阈值(例如，2.0、3.0、4.0等)，如果该订单取消概率大于第二预设阈值(例如，0.6、0.7、0.8等)，表示该订单请求具有较大概率被取消，其为高取消率订单请求，当高取消率订单请求和低取消率订单请求同时在排队等候订单分配模块230为其分配司机时，订单分配模块230可以将高取消率订单请求优先分配给具有最短预估到达时间的司机，从而有效提高高取消率订单的完单量。所述最短预估到达时间可以指从司机接单的当前位置到达上车点接驾的最短时间。又例如，订单请求中上车地点区域的供需比大于第一预设阈值(例如，2.0、3.0、4.0等)，如果该订单取消概率小于或等于第二预设阈值(例如，0.6、0.7、0.8等)，表示该订单请求被取消的概率较小，其为低取消率订单请求，订单分配模块230可以采用常规订单分配策略对所述低取消率订单请求进行分配。所述常规订单分配策略表示针对所有用户统一进行派单的策略。例如，根据订单请求的排队顺序依次进行派单。

在一些实施例中，如果供需比不大于第一预设阈值，表示在该订单上车点一定范围内提供运输服务的车辆供不应求，进一步判断订单取消概率是否大于第二预设阈值；响应于所述订单取消概率大于第二预设阈值，延迟分配所述订单请求，或者，响应于所述订单取消概率不大于第二预设阈值，将所述订单请求优先分配给司机。例如，订单请求中上车地点区域的供需比小于或等于第一预设阈值(例如，2.0、3.0、4.0等)，表示当前上车地点区域内可用车辆较少，如果该订单取消概率大于第二预设阈值(例如，0.6、0.7、0.8等)，表示该订单请求具有较大概率被取消，其为高取消率订单请求，为了保证打车平台的完单量，所述高取消率订单请求被延迟分配给数量有限的司机。又例如，订单请求中上车地点区域的供需比小于或等于第一预设阈值(例如，2.0、3.0、4.0等)，如果该订单取消概率小于或等于第二预设阈值(例如，0.6、0.7、0.8等)，表示该订单请求被取消的概率较小，其为低取消率订单请求，为了保证打车平台的完单量，可以将低取消率订单请求优先分配给数量有限的司机。

图5是根据本申请一些实施例所示的一种订单处理系统终端的模块图。所述订单处理系统终端(如乘客终端130)可以包括获取模块510和显示模块520。

获取模块510可以用于获取乘客的订单请求，以及与所述订单请求相关的信息。在一些实施例中，获取模块510可以从乘客的订单请求中直接获取与所述订单请求相关的信息。在一些实施例中，获取模块210可以访问读取存储在乘客终端130中的数据，根据所述订单请求的乘客信息(例如，用户名、ID等)获取该乘客的历史打车数据，从所述历史打车数据中提取到与该订单请求相关的信息。关于获取模块510的更多细节和应用可以参见图6及相关描述。

显示模块520可以用于至少基于订单取消概率，输出与订单处理相关的提示内容。所述订单取消概率基于与所述订单请求相关的信息，利用订单取消概率模型确定。在一些实施例中，与订单处理相关的提示内容可以为具有不同订单取消概率的乘客提供多种乘车选择。在一些实施例中，与订单处理相关的提示内容可以反映以下中的至少一种：近距离车辆需要等待，能立刻接单的车辆较远，请选择继续等待近距离车辆还是接受远距离车辆；接驾车辆较远，是否接受；接驾用时较长，是否接受。关于显示模块520的更多细节和应用可以参见图6及相关描述。

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

图6是根据本申请一些实施例所示的一种订单处理方法的示例性流程图。在一些实施例中，所述订单处理方法600可以由乘客终端130实施。

步骤610，获取乘客的订单请求，以及与所述订单请求相关的信息。具体的，步骤610可以由获取模块510执行。

在一些实施例中，与所述订单请求相关的信息可以包括但不限于订单发起时间、上车地点、上车时间、目的地、司机接驾的行驶距离、司机接驾的预估到达时间等或其任意组合。在一些实施例中，前述信息可以由获取模块510从乘客的订单请求中直接获取。在一些实施例中，获取模块510可以通过网络120访问读取存储在乘客终端130中的数据，根据所述订单请求的乘客信息(例如，用户名、ID等)获取该乘客的历史打车数据，从所述历史打车数据中提取到与该订单请求相关的信息。在一些实施例中，与所述订单请求相关的信息还可以包括乘客历史信息、乘客需求信息等。关于与订单请求相关的信息的更多细节可以参见图3及相关描述，在此不再赘述。

步骤620，至少基于订单取消概率，输出与订单处理相关的提示内容。具体的，步骤620可以由显示模块520执行。

在一些实施例中，所述订单取消概率基于与所述订单请求相关的信息，利用订单取消概率模型确定。关于订单取消概率模型和利用订单取消概率模型确定订单取消概率的更多细节可以参见图3及相关描述，在此不再赘述。

在一些实施例中，当乘客的订单请求为高取消率订单请求时，该乘客终端130可以在其用户界面上显示与所述订单处理相关的提示内容。在一些实施例中，所述与订单处理相关的提示内容可以反映但不限于以下中的至少一种：近距离车辆需要等待，能立刻接单的车辆较远，请选择继续等待近距离车辆还是接受远距离车辆；接驾车辆较远，是否接受；接驾用时较长，是否接受。通过这种方式，当近距离车辆需要等待，能立刻接单的车辆距离乘客上车点较远时，该乘客可以决定是否继续等待近距离车辆或者选择远距离车辆前来接驾。通过这种方式，当可接驾车辆距离乘客上车点较远时，该乘客可以决定是否接受该车辆前来接驾。通过这种方式，当可接驾车辆由于某些原因(例如，交通拥堵、接驾存在绕路情况、天气因素)到达乘客上车点的接驾时间较长时，该乘客可以决定是否接受该车辆前来接驾。通过上述与订单处理相关的提示内容，用户可以快速获得当前的订单请求响应情况，从而可以提高用户的出行效率，降低用户流失率。

在一些实施例中，用户界面上显示与所述订单处理相关的提示内容时，可以同时显示以下中的至少一个信息：接驾车辆的行驶距离、接驾车辆的预估到达时间和等待接驾车辆的排队编号。例如，当可接驾车辆较远时，用户界面上显示与所述订单处理相关的提示内容时，还可以显示可接驾车辆当前位置到用户上车点的行驶距离(例如，8km)。又例如，当可接驾车辆到达用户上车点的预估接驾用时较长时，用户界面上显示与所述订单处理相关的提示内容时，还可以显示可接驾车辆的预估接驾用时。再例如，当可接驾的近距离车辆需要等待，能立刻接单的车辆较远时，用户界面上显示与所述订单处理相关的提示内容时，还可以显示若选择近距离车辆的排队编号(例如，你在队列中排第23位，需等待20min)或若选择远距离车辆的接驾行驶距离(例如，7.8km)等。

在一些实施例中，乘客终端130可以具有显示部件(例如，显示屏)，用于显示所述与订单处理相关的提示内容。乘客终端130可以以文字、图像等形式显示所述与订单处理相关的提示内容。在一些实施例中，可以根据乘客或司机的当前位置变化更新与订单处理相关的提示内容。

本申请实施例可能带来的有益效果包括但不限于：(1)综合考虑了不同乘客的可接受司机接驾时间，利用订单取消概率模型预测当前订单请求的取消概率，为乘客提供个性化派单，提高平台运营效率；(2)根据订单取消率和供需比调整订单分配策略，有效提高了乘客的打车体验和平台的完单率；(3)通过在用户终端显示与订单处理相关的提示内容，用户可以快速获得当前的订单请求响应情况，可以提高用户的出行效率，降低用户流失率。需要说明的是，不同实施例可能产生的有益效果不同，在不同的实施例里，可能产生的有益效果可以是以上任意一种或几种的组合，也可以是其他任何可能获得的有益效果。

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本申请的限定。虽然此处并没有明确说明，本领域技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。

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

此外，本领域技术人员可以理解，本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对他们的任何新的和有用的改进。相应地，本申请的各个方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。此外，本申请的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。

计算机存储介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可能有多种表现形式，包括电磁形式、光形式等，或合适的组合形式。计算机存储介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机存储介质上的程序编码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、RF、或类似介质，或任何上述介质的组合。

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

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

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

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

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

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

Claims (22)

1.一种订单处理方法，其特征在于，所述方法包括：

获取乘客的订单请求，以及与所述订单请求相关的信息；

基于与所述订单请求相关的信息，利用订单取消概率模型，确定所述乘客的订单取消概率；

至少基于所述订单取消概率，对所述订单请求进行分配。

2.根据权利要求1所述的订单处理方法，其特征在于，所述订单取消概率模型为神经网络模型或回归模型。

3.根据权利要求1所述的订单处理方法，其特征在于，所述与所述订单请求相关的信息包括以下中的至少一个：订单发起时间、上车地点、上车时间、目的地、司机接驾的行驶距离、司机接驾的预估到达时间、乘客历史信息和乘客需求信息。

4.根据权利要求3所述的订单处理方法，其特征在于，所述乘客历史信息包括以下中的至少一个：乘客历史完成订单数量、乘客历史取消订单数量、乘客历史完成订单/乘客历史取消订单对应的预估到达时间、乘客历史完成订单/乘客历史取消订单对应的司机接驾行驶距离、乘客历史完成订单/乘客历史取消订单的价格；

所述乘客需求信息包括以下中的至少一个：乘客可接受的等待时间和乘客可接受的等待接驾距离。

5.根据权利要求1所述的订单处理方法，其特征在于，所述至少根据所述乘客的订单取消概率，对所述订单请求进行分配，包括：

获取所述订单请求中上车地点区域的供需比，所述上车地点区域为包括所述上车地点在内的具有设定覆盖面积的地理区域；

根据所述供需比和所述订单取消概率，对所述订单请求进行分配。

6.根据权利要求5所述的订单处理方法，其特征在于，所述根据所述供需比和所述订单取消概率，对所述订单请求进行分配，包括：

确定所述供需比是否大于第一预设阈值；

如果所述供需比大于第一预设阈值，进一步确定所述订单取消概率是否大于第二预设阈值；

响应于所述订单取消概率大于第二预设阈值，将所述订单请求优先分配给预估到达时间小于第三预设阈值的司机。

7.根据权利要求5所述的订单处理方法，其特征在于，所述根据所述供需比和所述订单取消概率，对所述订单请求进行分配，还包括：

确定所述供需比是否大于第一预设阈值；

如果所述供需比不大于第一预设阈值，进一步确定所述订单取消概率是否大于第二预设阈值；

响应于所述订单取消概率大于第二预设阈值，延迟分配所述订单请求；或者，

响应于所述订单取消概率不大于第二预设阈值，将所述订单请求优先分配给司机。

8.一种订单处理系统，其特征在于，所述系统包括：

获取模块，用于获取乘客的订单请求，以及与所述订单请求相关的信息；

订单取消概率确定模块，用于基于与所述订单请求相关的信息，利用订单取消概率模型，确定所述乘客的订单取消概率；

订单分配模块，用于至少基于所述订单取消概率，对所述订单请求进行分配。

9.根据权利要求8所述的订单处理系统，其特征在于，所述订单取消概率模型为神经网络模型或回归模型。

10.根据权利要求8所述的订单处理系统，其特征在于，所述与所述订单请求相关的信息包括以下中的至少一个：订单发起时间、上车地点、上车时间、目的地、司机接驾的行驶距离、司机接驾的预估到达时间、乘客历史信息和乘客需求信息。

11.根据权利要求10所述的订单处理系统，其特征在于，所述乘客历史信息包括以下中的至少一个：乘客历史完成订单数量、乘客历史取消订单数量、乘客历史完成订单/乘客历史取消订单对应的预估到达时间、乘客历史完成订单/乘客历史取消订单对应的司机接驾行驶距离、乘客历史完成订单/乘客历史取消订单的价格；

所述乘客需求信息包括以下中的至少一个：乘客可接受的等待时间和乘客可接受的等待接驾距离。

12.根据权利要求8所述的订单处理系统，其特征在于，

所述获取模块还用于获取所述订单请求中上车地点区域的供需比，所述上车地点区域为包括所述上车地点在内的具有设定覆盖面积的地理区域；

所述订单分配模块还用于根据所述供需比和所述订单取消概率，对所述订单请求进行分配。

13.根据权利要求12所述的订单处理系统，其特征在于，所述订单分配模块还用于：

确定所述供需比是否大于第一预设阈值；

如果所述供需比大于第一预设阈值，进一步确定所述订单取消概率是否大于第二预设阈值；

响应于所述订单取消概率大于第二预设阈值，将所述订单请求优先分配给预估到达时间小于第三预设阈值的司机。

14.根据权利要求12所述的订单处理系统，其特征在于，所述订单分配模块还用于：

确定所述供需比是否大于第一预设阈值；

如果所述供需比不大于第一预设阈值，进一步确定所述订单取消概率是否大于第二预设阈值；

响应于所述订单取消概率大于第二预设阈值，延迟分配所述订单请求；或者，

响应于所述订单取消概率不大于第二预设阈值，将所述订单请求优先分配给司机。

15.一种订单处理的装置，其特征在于，包括至少一个存储介质及至少一个处理器；

所述至少一个存储介质用于存储计算机指令；

所述至少一个处理器用于执行所述计算机指令，以实现权利要求1～7中任一项所述的订单处理的方法。

16.一种计算机可读存储介质，所述存储介质存储有计算机指令，当所述计算机指令被处理器执行时，实现如权利要求1～7中任一项所述的订单处理的方法。

17.一种订单处理方法，其特征在于，所述方法包括：

获取乘客的订单请求，以及与所述订单请求相关的信息；

至少基于订单取消概率，输出与订单处理相关的提示内容；

所述订单取消概率基于与所述订单请求相关的信息，利用订单取消概率模型确定。

18.根据权利要求17所述的订单处理方法，其特征在于，与订单处理相关的提示内容反映以下中的至少一种：

近距离车辆需要等待，能立刻接单的车辆较远，请选择继续等待近距离车辆还是接受远距离车辆；

接驾车辆较远，是否接受；

接驾用时较长，是否接受。

19.一种订单处理系统，其特征在于，所述系统包括：

获取模块，用于获取乘客的订单请求，以及与所述订单请求相关的信息；

显示模块，用于至少基于订单取消概率，输出与订单处理相关的提示内容；

所述订单取消概率基于与所述订单请求相关的信息，利用订单取消概率模型确定。

20.根据权利要求19所述的订单处理系统，其特征在于，所述显示模块显示的与订单处理相关的提示内容反映以下中的至少一种：

近距离车辆需要等待，能立刻接单的车辆较远，请选择继续等待近距离车辆还是接受远距离车辆；

接驾车辆较远，是否接受；

接驾用时较长，是否接受。

21.一种订单处理的装置，其特征在于，包括至少一个存储介质及至少一个处理器；

所述至少一个存储介质用于存储计算机指令；

所述至少一个处理器用于执行所述计算机指令，以实现权利要求17～18中任一项所述的订单处理的方法。

22.一种计算机可读存储介质，所述存储介质存储有计算机指令，当所述计算机指令被处理器执行时，实现如权利要求17～18中任一项所述的订单处理的方法。

Images