CN104599168A - 叫车订单的分配方法和装置 - Google Patents

Abstract

本发明的实施例提供了一种叫车订单的分配方法和装置。该方法包括：确定包括多个待分配订单的订单群和包括多个待接单用户的用户群；基于所述订单群和所述用户群来确定订单分配方式；以及根据所确定的订单分配方式，向所述用户群中的用户推送所述订单群中的订单。根据本发明的实施例的叫车订单的分配方法和装置可以取得对于叫车软件平台的整体而言的最优的订单分配方式。

Description

叫车订单的分配方法和装置

技术领域

本发明的实施例一般涉及在打车软件平台中使用的方法和装置，并且更特别地涉及叫车订单的分配方法和装置。

背景技术

随着打车软件的普及，人们的打车习惯已经被深刻的改变。以某打车软件为例，乘客打开软件发出叫车需求，该软件的服务器接收到叫车请求后，自动匹配该乘客周围的多个司机，并利用大数据计算出与该订单最为匹配的若干司机，将该订单推送给相关司机。司机端收到订单并将其展现，由司机决定发起抢单行为决定接受或不接受。

打车软件作为连接乘客和出租车司机的平台，如何对司机和订单进行匹配，也就是如何选择“哪些订单播给哪些司机，哪些司机听哪些订单”，是平台的核心体验。

首先，对乘客而言，当然希望其订单有较高的概率被司机应答；对司机而言，希望自己愿意接受的订单有较大概率能抢到；对于打车软件平台而言，希望每个乘客的订单都能成交，同时大多数司机都能抢到订单。

目前大多数的联系司机和订单的交易平台的打车软件，在订单分配方面大多采用如下两种方式进行分配。

其一，以订单为中心，通过为订单寻找合适司机的方式进行分配。在这种分配方式下，订单分配***的触发方式为单个订单触发，某一乘客发起打车请求，订单分配***收到订单请求后，在待接单司机里为该订单寻找合适司机，进行推送；司机收到该订单推送，根据自己的意愿决定是否接单，而是否能够成功接单，还要看其他司机对该订单的抢单情况。

其二，以司机为中心，通过为司机寻找合适订单的方式进行分配。这种分配方式较上面的分配方式而言在***实现上相对简单，直接以单个司机触发，比如，某一司机当前一个订单推送完后，客户端就不断给服务端发起推送订单请求，服务端接到司机客户端的请求后，将该司机转发给订单分配***，订单分配***拿到该司机后，在订单数据库中搜寻未成交订单，计算该司机与每个订单的相关性，选择N个(比如N＝2)最匹配的推送给司机，由司机决定是否响应。若司机未响应且订单推送完后，司机客户端再次向服务器发起推送订单请求，继续下一轮订单推送。

然而，无论是订单-司机一对多的订单分配***还是订单-司机多对一的订单分配***，都无法确保准确找到最优的匹配方式，因此给平台的整体效果带来损失。

从上面的分析可以看出，无论是订单-司机一对多的订单分配***还是订单-司机多对一的订单分配***，都无法确保准确找到最优的匹配方式，因此给平台的整体效果带来一定的损失。而产生这个问题的根本原因在于：其一，对于一对多的分配方式，始终有一方(订单或司机)以个体为中心，无法兼顾到其他个体；其二，该分配机制不满足机制设计中的激励相容原理，即个体的目标与整体平台目标不完全一致。

发明内容

鉴于现有技术中存在的上述问题，本发明的实施例的目的之一在于：提供一种在分配过程中以订单群和司机群作为分配基础的订单-司机多对多的订单分配***模型，从而解决现有技术中所存在的上述技术问题。

根据本发明的第一方面，提供了一种叫车订单的分配方法，包括：确定包括多个待分配订单的订单群和包括多个待接单用户的用户群；基于所述订单群和所述用户群来确定订单分配方式；以及根据所确定的订单分配方式，向所述用户群中的用户推送所述订单群中的订单。

根据本发明的一些实施例，其中确定包括多个待分配订单的订单群和包括多个待接单用户的用户群包括：基于一个地理区域来确定所述订单群和所述用户群。

根据本发明的一些实施例，其中基于一个地理区域来确定所述订单群和所述用户群包括：将所述地理区域中的当前所有订单确定为所述订单群，并且将所述地理区域中的当前所有待接单用户确定为所述用户群。

根据本发明的一些实施例，其中所述地理区域包括城市。

根据本发明的一些实施例，其中基于所述订单群和所述用户群来确定订单分配方式包括：基于所述订单群和所述用户群，并且根据订单成交率、抢单成功率以及听单抢单率中的至少一项来确定所述订单分配方式。

根据本发明的一些实施例，其中根据订单成交率、抢单成功率以及听单抢单率中的至少一项来确定所述订单分配方式包括：计算所述订单成交率、抢单成功率以及听单抢单率的加权和；以及确定使得所述加权和最大的订单分配方式，作为所确定的订单分配方式。

根据本发明的一些实施例，其中基于所述用户群中的任一用户对所述订单群中的任一订单的抢单概率，分别计算所述订单成交率、所述抢单成功率以及所述听单抢单率。

根据本发明的一些实施例，其中基于与待接单用户和发出订单的乘客有关的状态特征来计算所述抢单概率。

根据本发明的一些实施例，其中所述状态特征包括以下各项中的至少一项：待接单用户与乘客之间的距离、订单预期收入、乘客加价、乘客的目的地方向是否与待接单用户的预期行驶方向一致。

根据本发明的一些实施例，其中使用以下算法中的至少一种来确定使得所述加权和最大的订单分配方式：穷举法、遗传算法、蚁群算法、禁忌搜索算法、模拟退火算法、以及基于贪心的爬山算法。

根据本发明的一些实施例，其中确定使得所述加权和最大的订单分配方式包括：基于预定规则来生成初始的订单分配方式；以及使用基于贪心的爬山算法对所述初始的订单分配方式进行优化，从而确定使得所述加权和最大的订单分配方式。

根据本发明的一些实施例，其中使用订单缓存区和用户缓存区分别存储所述订单群和所述用户群，并且定期地读取所述订单缓存区和所述用户缓存区以确定订单分配方式。

根据本发明的一些实施例，其中在订单被创建时或者被推送但是在一段时间之后未被抢单，将该订单添加到所述订单缓存区中；并且在订单被推送给用户之后，从所述订单缓存区删除该订单。

根据本发明的一些实施例，其中当用户处于待接单状态时，将该用户添加到所述用户缓存区中；并且当用户抢单成功之后，从所述用户缓存区删除该用户。

根据本发明的第二方面，提供了一种叫车订单的分配装置，包括：第一确定单元，被配置为确定包括多个待分配订单的订单群和包括多个待接单用户的用户群；第二确定单元，被配置为基于所述订单群和所述用户群来确定订单分配方式；以及推送单元，被配置为根据所确定的订单分配方式，向所述用户群中的用户推送所述订单群中的订单。

通过采用本发明的实施例的叫车订单的分配方法和装置，实现了以订单群和司机群作为分配基础的订单-司机多对多的订单分配***模型，并且确定全局期望目标和个体期望目标，建立全局目标和个体目标间的联系，从而可以获得对于平台的整体效果而言的最优的订单匹配方式。

附图说明

通过参考附图阅读下文的详细描述，本发明的实施例的上述以及其他目的、特征和优点将变得容易理解。在附图中，以示例性而非限制性的方式示出了本发明的若干实施例，其中：

图1示意性地示出了根据本发明的一个实施例的一种叫车订单的分配方法；

图2示意性地示出了叫车订单的分配方法的一种在工程上的实施方式；以及

图3示意性地示出了根据本发明的一个实施例的一种叫车订单的分配装置。

具体实施方式

下面将参考附图来描述本发明的实施例的原理和精神。应当理解，描述这些实施例仅是为了使本领域的技术人员能够更好地理解并实施本发明，而并非以任何方式限制本发明的范围。

参考图1，图1示意性地示出了根据本发明的一个实施例的一种叫车订单的分配方法100。方法100在开始之后进入步骤101。在步骤101中，确定包括多个待分配订单的订单群和包括多个待接单用户的用户群。

本领域的技术人员可以理解，待分配订单可以包括乘客通过打车软件平台创建但是尚未推送给司机的打车订单。本领域的技术人员还可以理解，待分配订单也可以包括乘客通过打车软件平台所创建并且已经向司机推送但是在一段时间之后没有被抢单的打车订单。本领域的技术人员可以进一步理解，只要是在某一时间需要向司机推送的订单都可以属于这里的待分配订单，本发明在这个方面不受限制。

本领域的技术人员可以理解，待接单用户可以包括打车平台的司机用户。本领域的技术人员还可以理解，如果根据本发明的实施例的打车软件运用至其他的类型的运输场景中，待接单用户还可以包括各种其他交通工具的各种操作人员。本领域的技术人员将进一步理解，只要是在某一时间处于可以接受订单状态的打车软件平台的用户都可以属于这里的待接单用户，本发明在这个方面不受限制。

应当注意，在步骤101中，多个待分配订单也包括两个待分配订单，并且多个待接单用户也包括两个待接单用户。换句话说，尽管根据本发明的实施例的叫车订单的分配方法100通常使用在大量待分配订单和大量待接单用户的场景中，但是方法100也能够应用在只有两个订单和两个司机的场景中。

根据本发明的一些实施例，在步骤101中，可以基于一个地理区域来确定订单群和用户群。具体而言，可以将某个地理区域中的当前所有订单确定为订单群，并且将该地理区域中的当前所有待接单用户确定为用户群。例如，该地理区域可以包括省、城市、县市等通过行政区划来划分的地理区域，也可以是通过地理上的经度和纬度所划分的地理区域。本领域的技术人员可以理解，本发明并不受具体的地理区域的划分方式的限制。

接着，方法100前进至步骤102。在步骤102中，基于订单群和用户群来确定订单分配方式。

根据本发明的一些实施例，在步骤102中可以进一步包括：基于订单群和用户群，并且根据订单成交率、抢单成功率以及听单抢单率中的至少一项来确定订单分配方式。订单成交率E_{OrderSuccRate}是指在订单群中的最终通过打车软件平台成交的订单与订单群中的所有订单的比率。抢单成功率E_{StrivesSuccRate}是指用户群中的用户实施的成功抢单操作的数量与用户实施的抢单操作的数量的比率。听单抢单率E_StriveRate是指用户群中的用户对推送给他的订单实施抢单操作的数量与订单群中被推送给他的订单数量的比率。通过这种方式，方法100可以实现对打车软件平台整体而言的最优分配方式。但是，本领域的技术人员可以理解，根据订单成交率、抢单成功率以及听单抢单率中的至少一项来确定订单分配方式仅仅是基于订单群和用户群来确定订单分配方式的一种实施方式。本领域的技术人员可以在具体的不同的技术环境、应用场景、以及设计要求的情况下，采用其他的指标或者其他的方式来基于订单群和用户群而确定订单分配方式。

根据本发明的一些实施例，根据订单成交率、抢单成功率以及听单抢单率中的至少一项来确定订单分配方式可以包括：计算订单成交率、抢单成功率以及听单抢单率的加权和；以及确定使得该加权和最大的订单分配方式，作为所确定的订单分配方式。具体而言，在方法100的实施过程中，本领域的技术人员可以根据实际的技术场景或者环境来设置这三个指标之间的权重，这可以用公式表示为E＝α₁*E_{OrderSuccRate}+α₂*E_{StriveSuccRate}+α₃*E_StriveRate，E表示这三个指标的加权和，α₁、α₂、α₃分别表示这三个指标的权重值。根据本发明的一个实施例，方法100选择使得该加权和E最大的订单分配方式作为最终确定的订单分配方式。应当注意，本领域的技术人员可以采用其他的方式来综合考虑这三个指标而最终确定订单分配方式，本发明并不局限于如上所描述的线性加权方式，该方式仅仅是本发明的实施例的一种示例。

根据本发明的一些实施例，可以基于用户群中的任一用户对订单群中的任一订单的抢单概率，分别计算订单成交率、抢单成功率以及听单抢单率。在本发明的一个实施例的一种示例中，假设在订单群中存在N_o个订单，用户群中存在N_d个用户，则用户群中的用户j对订单群中的订单i的抢单概率可以表示为P_ij。那么订单成交率可以进一步表示为 $E_{\mathrm{OrderSuccRate}}=\frac{{\mathrm{\&Sigma;}}_{i=1}^{N_o}[1-{\mathrm{\&Pi;}}_{j=1}^{N_d}{(1-P_{\mathrm{ij}})}^{d_{\mathrm{ij}}}]}{N_o},$ 抢单成功率可以表示为 $E_{\mathrm{StriveSuccRate}}=\frac{{\mathrm{\&Sigma;}}_{i=1}^{N_o}[1-{\mathrm{\&Pi;}}_{j=1}^{N_d}{(1-P_{\mathrm{ij}})}^{d_{\mathrm{ij}}}]}{{\mathrm{\&Sigma;}}_i<N_{o,j}<N_d{P}_{\mathrm{ij}}*d_{\mathrm{ij}}},$ 听单抢单率可以表示为 $E_{\mathrm{StriveRate}}=\frac{{\mathrm{\&Sigma;}}_i<N_{o,j}<N_d{P}_{\mathrm{ij}}*d_{\mathrm{ij}}}{{\mathrm{\&Sigma;}}_i<N_{o,j}<N_d{d}_{\mathrm{ij}}},$ 其中本领域的技术人员可以理解，还可以根据其他的方式从抢单概率推导出订单成交率、抢单成功率以及听单抢单率，本发明的实施例并不限于从抢单概率推导出订单成交率、抢单成功率以及听单抢单率的具体方式。

根据本发明的一些实施例，可以基于与待接单用户和发出订单的乘客有关的状态特征来计算抢单概率P_ij。这样的状态特征包括但不限于：待接单用户与乘客之间的距离、订单预期收入、乘客加价、乘客的目的地方向是否与用户的预期行驶方向一致、以及将会影响到待接单用户对于订单的抢单意愿的其他因素，等等。在这种情况下，抢单概率P_ij可以表示为其中X_ij表示状态特征所组成的特征向量，W表示X_ij中每个状态特征所对应的权重，其可以根据具体的技术场景和需求来设置。

接着，方法100前进至步骤103。在步骤103中，根据所确定的订单分配方式，向用户群中的用户推送订单群中的订单。

根据本发明的一些实施例，所确定的订单分配方式可以是向一个用户推送一个订单，也可以是向一个用户推送多个订单；一个订单可以在一个时间仅被推送给一个用户，也可以在一个时间被推送给多个用户；可以向每个用户至少推送一个订单，也可以在没有适合订单的情况下不向某些用户推送订单。本领域的技术人员可以理解，具体的推送订单的个数以及规则可以根据具体的技术场景和需求来选择，本发明在这个方面不受限制。

另外，本领域的技术人员可以理解，本发明也不受具体的推送方式的限制。具体的推送方式可以是通过语音播报、文字显示、以及任何使得待接单用户能够得知待分配订单的推送方式，等等。

因此，如上所述，根据本发明的一个实施例，本发明的实施例的订单的分配方法100可以通过建立如下的模型来进行分析和求解。首先，在业务上假设一个司机用户同时只能接受一个订单，同一订单可以推送给多个司机。当多个司机对同一订单发起抢单请求时，只有一个司机能抢单成功，其余司机则抢单失败。在这个业务场景下，对订单分配模型可以在数学上建模如下：

在上面的模型中，E_{OrderSuccRate}(成交率)、E_{StriveSuccRate}(抢单成功率)、E_StriveRate(听单抢单率)为核心业务指标，E为以上若干核心指标的加权和，模型的优化目标为加权目标最大。模型的解为矩阵{d_ij,i∈[0,N_o],j∈[0,N_d]}。换句话说，就是对N_o个待分配订单，N_d个待接单用户，按照上面的约束及对应的抢单率P_ij，求出使综合目标E最大的分配方式D＝{d_ij}。

根据本发明的一些实施例，可以使用以下算法中的至少一种来确定使得上述加权和E最大的订单分配方式：穷举法、遗传算法、蚁群算法、禁忌搜索算法、模拟退火算法、以及基于贪心的爬山算法。本领域的技术人员将理解，还可以采用其他的智能算法和非智能算法来对上述模型进行求解，本发明的实施例不限制于具体的求解算法。

根据本发明的一些实施例，由于在实际的软件平台中，上述模型需要在线进行计算求解，综合性能和效果，可以基于预定规则来生成初始的订单分配方式；以及使用基于贪心的爬山算法对初始的订单分配方式进行优化，从而确定使得加权和最大的订单分配方式。

图2示意性地示出了叫车订单的分配方法100的一种在工程上的实施方式200。在工程实现上，为了保证实现待分配订单与待接单用户之间的多对多的模型，采用了订单缓存区和用户缓存区。两个缓存区分别负责存储当前待分配订单和待接单用户、新数据的进入、过期数据的删除等工作(框201)。具体而言，在订单被创建时或者被推送但是在一段时间之后未被抢单，将该订单添加到订单缓存区中；并且在订单被推送给用户之后，从订单缓存区删除该订单。此外，当用户处于待接单状态时，将该用户添加到用户缓存区中；并且当用户抢单成功之后，从用户缓存区删除该用户(框201)。订单分配服务每间隔一定时间(例如500毫秒)从两个缓存区取回当前待分配用户(框202)、待分配订单的集合、对当前所有待接单用户和待分配订单来计算任一用户对任一订单的抢单概率(框203)，然后按照上面的方法对模型进行求解，得到当前最合适的订单分配方式矩阵D(框204)。

图3示意性地示出了根据本发明的一个实施例的一种叫车订单的分配装置300。装置300可以包括第一确定单元301、第二确定单元302以及推送单元303。装置300可以进一步可选地包括订单缓存区304和用户缓存区305。

根据本发明的一些实施例，第一确定单元301可以被配置为确定包括多个待分配订单的订单群和包括多个待接单用户的用户群。确定单元302可以被配置为基于订单群和用户群来确定订单分配方式。推送单元303可以被配置为根据所确定的订单分配方式，向用户群中的用户推送订单群中的订单。

根据本发明的一些实施例，第一确定单元301可以进一步被配置为：基于一个地理区域来确定所述订单群和所述用户群。根据本发明的一些实施例，第一确定单元301可以进一步被配置为：将地理区域中的当前所有订单确定为订单群，并且将地理区域中的当前所有待接单用户确定为用户群。根据本发明的一些实施例，地理区域可以包括城市。

根据本发明的一些实施例，第二确定单元302可以进一步被配置为：基于订单群和用户群，并且根据订单成交率、抢单成功率以及听单抢单率中的至少一项来确定订单分配方式。第二确定单元302可以进一步被配置为：计算订单成交率、抢单成功率以及听单抢单率的加权和；以及确定使得该加权和最大的订单分配方式，作为所确定的订单分配方式。第二确定单元302可以进一步被配置为：基于用户群中的任一用户对订单群中的任一订单的抢单概率，分别计算订单成交率、抢单成功率以及听单抢单率。

根据本发明的一些实施例，第二确定单元302可以进一步被配置为：基于与待接单用户和发出订单的乘客有关的状态特征来计算抢单概率。状态特征包括以下各项中的至少一项：待接单用户与乘客之间的距离、订单预期收入、乘客加价、待接单乘客的目的地方向是否与用户的预期行驶方向一致。

根据本发明的一些实施例，第二确定单元302可以进一步被配置为，使用以下算法中的至少一种来确定使得加权和最大的订单分配方式：穷举法、遗传算法、蚁群算法、禁忌搜索算法、模拟退火算法、以及基于贪心的爬山算法。根据本发明的一些实施例，第二确定单元302可以进一步被配置为：基于预定规则来生成初始的订单分配方式；以及使用基于贪心的爬山算法对初始的订单分配方式进行优化，从而确定使得加权和最大的订单分配方式。

根据本发明的一些实施例，装置300可以进一步包括订单缓存区304和用户缓存区305分别存储订单群和用户群，并且定期地读取订单缓存区304和用户缓存区305来确定订单分配方式。在图3中订单缓存区304和用户缓存区305用虚线表示。具体而言，在订单被创建时或者被推送但是在一段时间之后未被抢单，将该订单添加到订单缓存区304中；并且在订单被推送给用户之后，从订单缓存区304删除该订单。当用户处于待接单状态时，将该用户添加到用户缓存区305中；并且当用户抢单成功之后，从用户缓存区305删除该用户。

以下分别从具体的示例方面来论述根据本发明的实施例的叫车订单的分配方法和装置相对于现有方案的优点和技术效果。在讨论如何进行订单分配之前，先进行以下的假设，并在这些假设下考虑后面两个具体示例。

假设1：司机决定是否发起抢单请求，与司机和订单间的距离正相关，司机距离订单越近，司机越愿意抢单，距离越远，司机越不愿意抢单。假设2：如果司机距离订单非常远，则该司机几乎不会参加抢单，因为接驾将要空驶很长距离，导致收益不高。假设3：乘客发出订单后，有一定的忍耐度，如果较长时间还没有司机应答，乘客会取消订单。

示例1：订单1距离司机1有300米，距离司机2有400米；订单2距离司机1有2000米，具体司机2有500米。

在这个示例中，不难发现(司机1，订单1)，(司机2，订单2)是最好的匹配。对上面的示例，采用(x,y)表示将订单x分配给司机y，订单分配***有4种分配方式。

第一种，(1,1)，(2,2)，这种分配方式显然是最好的，如果司机1、2均发起抢单，由于没有竞争，两人均成功；对乘客而言，两个乘客均有司机应答。

第二种，(1,1)，(1,2)，在这种方式中，两个司机都被推送了距离自己最近的订单，很可能均发生抢单行为，这时必然有一个司机抢单失败。

如果司机2抢单失败，此时，司机1如愿完成了订单1，而***获知司机1失败后，再次给司机2重新分配订单，此时只有1个订单剩余，选择推送订单2，司机2收到订单2后，抢单成功。虽然结果是好的，但是显然效率有些偏低；并且在另外一种情况中，由于订单2是间隔了一段时间才播出，如果恰在此时乘客因为等待时间较长而取消了订单，则无法获得如方式1的最优解。

如果司机1失败，此时司机2完成了订单1。同理，***给司机1推送订单2。如果司机1决定抢单，那么此时的组合是(1,2)、(2,1)，相比(1,1)，(2,2)而言，两个司机均要付出较大的接驾距离；而另一种情况，如果司机1觉得太远而不愿抢单，则订单1没有成交，同时司机1没有获得合适的订单。

类似，对另外两种情况(1,2)，(2,1)和(1,2)，(2,2)，均不能高效的获得最优匹配，或无法获得最优匹配。

再考虑另一个示例2：订单1距离司机1有300米，距离司机2有400米；订单2距离司机1有800米，距离司机2有9000米。

在这个示例下，由于订单2距离两个司机均非常远，因此两个司机对该订单的抢单意愿几乎为零，而两个司机也不一定会对订单1发生抢单，只是两个司机对订单1的抢单意愿比较大。这时的最优解为(1,1)，次优解为(1,2)。

在订单分配角度，依然有上面的4种分配情况。首先，考虑到订单2距离两个司机都很远，其成交的希望不大；同时，虽然订单1距离每个司机均比较近，但是毕竟存在一定的如下可能性，即其中的某个司机或两个司机均不响应。因此，针对这种情况，分配策略应该尽可能大的保证订单1成交，因此比较好的分配方式是订单1同时播给司机1和司机2。

上面的两个示例代表了两类比较典型的情况，相对比较容易得出最好的分配方式。更进一步，对下面这个情况就较难判断出最好的分配方式。

示例3：订单1距离司机1有300米，距离司机2有400米；订单2距离司机1有1100米，距离司机2有1000米。

对这个示例，订单1距离两个司机较近，而订单2处在一个说近不近，说远不远的距离，因此该示例是一个处在示例1和示例2之间的一个示例，那么(1,1)，(1,2)和(1,1)，(2,3)究竟哪个好就很难判断了。

上面只是两个订单和两个司机，如果是N个订单M个司机情况会更加复杂；同时，在上面的假设下，只考虑了距离这一个因素对司机抢单意愿的影响，实际上还有很多因素影响司机抢单意愿的因素，比如订单最终的计价、订单目的地接单的难易程度、道路的拥堵情况、是否与司机计划行驶方向一致等。

下面在上述示例的基础上对现有技术的解决方案进行分析。

目前在大多数联系接单用户(司机)和订单(乘客)的打车交易平台中，在订单分配方面大多采用如下两种方式进行分配。

第一，以订单为中心，通过为订单寻找合适司机的方式进行分配。在这种分配方式下，订单分配***的触发方式为单个订单触发，某一乘客发起打车请求，订单分配***收到订单请求后，在待接单司机里为该订单寻找合适司机，进行推送；司机受到该订单推送，根据自己的意愿决定是否接单，而是否能够成功接单，还要看其他司机对该订单的抢单情况。

在这个***的实现方面，需要有两个考虑：需要有一个数据库，可以获取当前需要接单的司机，简称司机缓存区。当某一司机需要推送订单时，司机进入该缓存区；当某一订单需要进行分配时，分配***从司机缓存区中选出若干司机，将该订单与每个司机计算相关性后，最后选定若干司机进行推送；某一司机获得推送订单后，从缓存区中清除，待其下次需要订单时再进入。另外，需要有一个控制***，随时为未成交订单进行再分配，简称订单调度***。

订单刚刚创建时，分配***为该订单进行第一次分配，为保证该订单不致过度占用司机信道，对其他订单推送产生影响，一般情况下，***会做一个限制，即一次分配最多为该订单选择N个(比如N＝10)司机进行推送，如果这10个司机均未对该订单进行响应，那么何时对该订单进行再分配则是订单调度***的任务。

一般情况下，订单调度***每隔一段时间(如5秒)扫描一次数据库，对未成交订单，依次发送给订单分配***，***拿到订单后，重复上面的工作，继续给该订单寻找合适司机进行推送。

基于上面的逻辑设计的订单分配***，其特征为以订单为中心，每次处理一个订单，在众多司机中寻找合适的匹配，进行分配。因此，该***成为订单-司机一对多的订单分配***。

用该***分析上面的示例1，简单起见，这里假设N＝1，即每次分配，每个订单只选择1个司机。

假设订单1先被处理，对订单1，从司机1、司机2中进行选择，显然司机1更近，因此订单1选择司机1进行推送，同时将司机1从司机缓存区中清除；对订单2，当前只有司机2可选，因此选择司机2进行推送。这种分配方式，达到了理想中的最优分配方式。

假设订单2先被处理。类似上面的分析，这种情况下，将导致司机2推送订单1，司机1推送订单2，距离最优的分配方式相差甚远。

从上面的分析可以看出，这种订单-司机一对多的订单分配***方式，能否获得最优解完全是一个随机事件，由于服务端的计算机的每次处理一个订单分配的时间消耗在毫秒级别，能否得到最优解完全取决两个订单到达服务器的时间顺序。

第二，以司机为中心，通过为司机寻找合适订单的方式进行分配。这种分配方式较上面的分配方式在***实现上相对简单，直接以单个司机触发。比如，某一司机当前一个订单推送完后，客户端就不断给服务发起推送订单请求，服务端接到司机端的请求后，将该司机转发给订单分配***，订单分配***拿到该司机后，在订单数据库中搜寻未成交订单，计算该司机与每个订单的相关性，选择N个(比如N＝2)最匹配的推送给司机，由司机决定是否响应。若司机未响应且订单推送完后，司机客户端再次向服务器发起推送订单请求，继续下一轮订单推送。

基于上面的逻辑设计的订单分配***，其特征为以司机为中心，每次处理一个司机，在众多订单中寻找合适的匹配，进行分配。因此，该***成为订单-司机多对一的订单分配***。

可以从理论上证明，订单-司机一对多的订单分配***和订单-司机多对一的订单分配***是等价的。而订单-司机多对一的订单分配***在工程实现上相对容易，目前业界大多数采用订单-司机多对一的订单分配***。按照这种分配方式对上面的示例进行分析，不难发现，这种分配方式也不能保证找到最优的分配方式。

综上，无论是订单-司机一对多的订单分配***还是订单-司机多对一的订单分配***，都无法确保准确找到最优的匹配方式，因此给平台的整体效果带来一定的损失。

从上面的分析可以看出，无论是订单-司机一对多的订单分配***还是订单-司机多对一的订单分配***，都无法确保准确找到最优的匹配方式，因此给平台的整体效果带来一定的损失。而产生这个问题的根本原因在于：第一，一对多的分配方式，始终有一方(司机或订单)以个体为中心，无法兼顾到其他个体；第二，现有技术中的分配机制不满足机制设计中的激励相容原理，即个体的目标与整体平台目标不完全一致。

例如，对于如下的示例进行分析，只分析订单-司机多对一的订单分配***，即以单个司机为中心进行分析，可以看出上面所论述的所存在的问题。

示例4：订单1距离司机1有500米，距离司机2有400米；订单2距离司机1有2000米，距离司机2有500米。在给司机2分配订单时，在司机2看来，***只知道订单1对他最优，而无法获知其实应该讲订单1分与司机1，司机2应该退而求其次，选择订单2。

其次，平台对每个司机的期望是对推送的订单尽可能响应；而平台的整体目标是所有订单的成交率尽可能大，所有司机抢单冲突尽可能小，个体目标与全局目标不完全匹配。

对于如何解决第一个问题，关键在于如何将所有订单和所有司机一起考虑，这样就能避免个体之间的信息损失；而对第二个问题，需要个体期望目标与全局期望目标之间的联系，进而保证个体目标与全局目标一致。

本发明的实施例在解决上面两个问题上，采用以下的方案：第一，将当前所有乘客(订单)作为一个整体，记为订单群，将当前所有待接单用户(司机)作为一个整体，记为用户群，在分配过程中，以订单群和用户群作为分配单位，因此该模型是订单-司机多对多的订单分配***。第二，确定全局期望目标和个体期望目标，建立全局目标和个体目标间的联系。对个体目标而言，希望每个司机积极响应对其推送的订单，因此我们假设所有司机对定单的抢单意愿服从同一条件概率分布P(STRIVE＝1|X)，其中，STRIVE＝1表示司机抢单，STRIVE＝0表示司机不抢单，X表示当前司机与司机的状态特征信息，如距离、预期价格、付出成本等。同时，确定平台全局目标为所有订单成交率E，显然成交率是所有司机抢单期望的函数，E＝F(P)。

对于抢单概率P(STRIVE＝1|X)，可以采用机器学习的方法训练预估，训练样本为历史播单抢单数据{Y_ij|X_ij}，该记录表示一次推送记录，即某订单对某司机的一次推送，其中X_ij表示该推送时刻的若干特征向量，如司乘距离、订单预期收入、乘客加价、与司机预期行驶方向是否一致等，Y_ij表示推送后，司机是否发生抢单，1为抢单，2为未抢单。预测模型可以采用采用工业界广泛使用的LR模型(类似模型还有线性回归、svm、gbdt等)。

LR模型将概率预估表示为下面的方程：

$P(\mathrm{Yij}=1|\mathrm{Xij})=\frac{1}{1+e^{W*\mathrm{Xij}}}$

其中，X_ij为该推送时刻的若干特征向量，如司乘距离、订单预期收入、乘客加价、与司机预期行驶方向是否一致等；W为X_ij中每个特征对应的权重。

采用离线的方法，用历史播单抢单记录对模型进行训练，然后在线上就可以实时对每一(订单，司机)对，进行抢单率预估，叫做STR(strive through rate)预估。获得了任一对(订单i，司机j)的P_ij后，就可以按照在针对图1所描述的方式开始对订单分配方式进行建模。

为了充分说明本发明的实施例所提供的多对多模型明显优于一对多模型，下面首先用该模型对上面的示例进行分析，其次在从理论上分析该模型的优势。

还是对于上面的示例4，先计算抢单概率P_ij，这里为了简单性的缘故只使用了距离这一个特征。经过线下的机器训练，距离特征的权重为0.001，因此抢单概率的公式可以记为：按照该公式计算，可以得到如下的结果。

订单1

订单2

司机1	0.38	0.12
			司机2	0.4	0.38

接着，求解模型得到订单分配的解，并且在本示例中，为了简单起见，可以只考虑成交率一个核心指标，则每个分配方式对应的成交率如下：

显然，模型经过遍历4种可行解后，将会发现(订单1，司机1)、(订单2，司机2)是使成交率最大的解，因此选择该订单分配的解。同理，按照该方法对示例2、示例3求解，均可以得到最合理的订单分配的解。

由此可见，根据本发明的实施例的叫车订单的分配方法和装置相对于现有技术的方法，可以取得相对于所有订单和所有司机的整体而言的最优的订单分配方案。

以下从模型分析的角度来论述对根据本发明的实施例的叫车订单的分配方法和装置的优点和技术效果。

从概念上将，订单分配模型是一种机制设计。机制设计包含如下三部分：{B(战略空间)，P(分配规则)，M(支付规则)}。这里，B为司机的抢单意愿，***无法得知司机的真实抢单意愿，只能假设司机的抢单意愿服从统一条件概率分布，进而采用机器学习的方法进行预估；P包含两部分：抢单前的推送分配和抢单后的分配，这里抢单后简单按照先抢先的方式进行分配。M为司机得到订单后的支付行为，在目前业务场景下司机只需完成乘客接送。

订单分配模型的核心就是B为司机的抢单意愿的预估和抢单前的推送分配两个模型。订单分配面对的是司机和订单群体，订单分配的目标是成交率、抢单成功率、听单抢单率等目标的加权最大。

根据机制设计理论，一个好的机制应该是激励相容的。激励相容就是参与者理性实现个体利益最大化的策略，与机制设计者所期望的策略一致，从而使参与者自愿按照机制设计者所期望的策略采取行动。

从激励相容的角度分析，多对多的组合优化模型是符合激励相容原理的，在这个策略模型下，只要每个司机按照预估的抢单意愿，那么平台的成交率是最大化的；而对每个司机而言，出于个体利益的趋势，会按照相应的意愿进行抢单响应。

再分析成交率计算公式：

对某一特定订单x而言，其成交率期望如下：

对某一司机y，考虑订单x对除y以外的司机推送，令 ${\mathrm{PSR}}_x^{-y}=1-{\mathrm{\&Pi;}}_{j=1,j!=m}^{N_d}{(1-P_{\mathrm{xj}})}^{d_{\mathrm{xj}}},$ 含义为除司机y外，其余司机对该订单成交率的贡献，也就是订单x在播给司机x之前，根据当前订单x的推送情况，对订单x的成交率预估(predict success rate)，于是上面的公式变为：

对P_xy求导得：

可以看出，导函数与是负相关的。业务上，如果一个订单当前的推送情况对该订单的成交率贡献越大，那么再新加入一个订单对该订单成交率贡献的增量将越小。对于整个平台而言，订单的推送信道是一个有限资源，通过这一点在，可以自动的对订单的推送情况进行调整。如果一个订单推送的比较充分了(PSR较高)，那么***会自动给待播单司机选择推送不充分(PSR较低)的订单。

同理，对求导，得：

同样可以看出，导函数是与P_xy负相关的。在业务上，如果一个司机对某一订单的抢单率越高，当这个订单播给该司机后，该订单再播给其他司机对该订单的成交率贡献越低。通过这一点，如果一个订单推送给一个抢单意愿较强的司机，那么根据该模型，***会自动尽可能少的再将该订单播给其他司机，从而保证该司机能抢到该订单。

应当注意，本发明的实施例可以通过硬件、软件或者软件和硬件的结合来实现。硬件部分可以利用专用逻辑来实现；软件部分可以存储在存储器中，由适当的指令执行***，例如微处理器或者专用设计硬件来执行。本领域的技术人员可以理解上述的设备和方法可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。

此外，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。相反，流程图中描绘的步骤可以改变执行顺序。附加地或备选地，可以省略某些步骤，将多个步骤组合为一个步骤执行，和/或将一个步骤分解为多个步骤执行。还应当注意，根据本发明的两个或更多装置的特征和功能可以在一个装置中具体化。反之，上文描述的一个装置的特征和功能可以进一步划分为由多个装置来具体化。

虽然已经参考若干具体实施例描述了本发明，但是应当理解，本发明不限于所公开的具体实施例。本发明旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等效布置。

Claims (28)

1.一种叫车订单的分配方法，包括：

确定包括多个待分配订单的订单群和包括多个待接单用户的用户群；

基于所述订单群和所述用户群来确定订单分配方式；以及

根据所确定的订单分配方式，向所述用户群中的用户推送所述订单群中的订单。

2.根据权利要求1所述的方法，其中确定包括多个待分配订单的订单群和包括多个待接单用户的用户群包括：

基于一个地理区域来确定所述订单群和所述用户群。

3.根据权利要求2所述的方法，其中基于一个地理区域来确定所述订单群和所述用户群包括：

将所述地理区域中的当前所有订单确定为所述订单群，并且将所述地理区域中的当前所有待接单用户确定为所述用户群。

4.根据权利要求3所述的方法，其中所述地理区域包括城市。

5.根据权利要求1所述的方法，其中基于所述订单群和所述用户群来确定订单分配方式包括：

基于所述订单群和所述用户群，并且根据订单成交率、抢单成功率以及听单抢单率中的至少一项来确定所述订单分配方式。

6.根据权利要求5所述的方法，其中根据订单成交率、抢单成功率以及听单抢单率中的至少一项来确定所述订单分配方式包括：

计算所述订单成交率、抢单成功率以及听单抢单率的加权和；以及

确定使得所述加权和最大的订单分配方式，作为所确定的订单分配方式。

7.根据权利要求5所述的方法，其中基于所述用户群中的任一用户对所述订单群中的任一订单的抢单概率，分别计算所述订单成交率、所述抢单成功率以及所述听单抢单率。

8.根据权利要求7所述的方法，其中基于与待接单用户和发出订单的乘客有关的状态特征来计算所述抢单概率。

9.根据权利要求8所述的方法，其中所述状态特征包括以下各项中的至少一项：待接单用户与乘客之间的距离、订单预期收入、乘客加价、乘客的目的地方向是否与待接单用户的预期行驶方向一致。

10.根据权利要求6所述的方法，其中使用以下算法中的至少一种来确定使得所述加权和最大的订单分配方式：

穷举法、遗传算法、蚁群算法、禁忌搜索算法、模拟退火算法、以及基于贪心的爬山算法。

11.根据权利要求6所述的方法，其中确定使得所述加权和最大的订单分配方式包括：

基于预定规则来生成初始的订单分配方式；以及

使用基于贪心的爬山算法对所述初始的订单分配方式进行优化，从而确定使得所述加权和最大的订单分配方式。

12.根据权利要求1所述的方法，其中使用订单缓存区和用户缓存区分别存储所述订单群和所述用户群，并且定期地读取所述订单缓存区和所述用户缓存区以确定订单分配方式。

13.根据权利要求12所述的方法，其中在订单被创建时或者被推送但是在一段时间之后未被抢单，将所述订单添加到所述订单缓存区中；并且在订单被推送给用户之后，从所述订单缓存区删除所述订单。

14.根据权利要求12所述的方法，其中当用户处于待接单状态时，将所述用户添加到所述用户缓存区中；并且当用户抢单成功之后，从所述用户缓存区删除所述用户。

15.一种叫车订单的分配装置，包括：

第一确定单元，被配置为确定包括多个待分配订单的订单群和包括多个待接单用户的用户群；

第二确定单元，被配置为基于所述订单群和所述用户群来确定订单分配方式；以及

推送单元，被配置为根据所确定的订单分配方式，向所述用户群中的用户推送所述订单群中的订单。

16.根据权利要求15所述的装置，其中所述第一确定单元进一步被配置为：

基于一个地理区域来确定所述订单群和所述用户群。

17.根据权利要求16所述的装置，其中所述第一确定单元进一步被配置为：

将所述地理区域中的当前所有订单确定为所述订单群，并且将所述地理区域中的当前所有待接单用户确定为所述用户群。

18.根据权利要求17所述的装置，其中所述地理区域包括城市。

19.根据权利要求15所述的装置，其中所述第二确定单元进一步被配置为：

基于所述订单群和所述用户群，并且根据订单成交率、抢单成功率以及听单抢单率中的至少一项来确定所述订单分配方式。

20.根据权利要求19所述的装置，其中所述第二确定单元进一步被配置为：

计算所述订单成交率、抢单成功率以及听单抢单率的加权和；以及

确定使得所述加权和最大的订单分配方式，作为所确定的订单分配方式。

21.根据权利要求19所述的装置，其中所述第二确定单元进一步被配置为：

基于所述用户群中的任一用户对所述订单群中的任一订单的抢单概率，分别计算所述订单成交率、所述抢单成功率以及所述听单抢单率。

22.根据权利要求21所述的装置，其中所述第二确定单元进一步被配置为：

基于与待接单用户和发出订单的乘客有关的状态特征来计算所述抢单概率。

23.根据权利要求22所述的装置，其中所述状态特征包括以下各项中的至少一项：待接单用户与乘客之间的距离、订单预期收入、乘客加价、乘客的目的地方向是否与待接单用户的预期行驶方向一致。

24.根据权利要求20所述的装置，其中所述第二确定单元进一步被配置为：使用以下算法中的至少一种来确定使得所述加权和最大的订单分配方式：

穷举法、遗传算法、蚁群算法、禁忌搜索算法、模拟退火算法、以及基于贪心的爬山算法。

25.根据权利要求20所述的装置，其中所述第二确定单元进一步被配置为：

基于预定规则来生成初始的订单分配方式；以及

使用基于贪心的爬山算法对所述初始的订单分配方式进行优化，从而确定使得所述加权和最大的订单分配方式。

26.根据权利要求15所述的装置，其中订单缓存区和用户缓存区分别存储所述订单群和所述用户群，并且定期地读取所述订单缓存区和所述用户缓存区以确定订单分配方式。

27.根据权利要求26所述的装置，其中在订单被创建时或者被推送但是在一段时间之后未被抢单，将所述订单添加到所述订单缓存区中；并且在订单被推送给用户之后，从所述订单缓存区删除所述订单。

28.根据权利要求26所述的装置，其中当用户处于待接单状态时，将所述用户添加到所述用户缓存区中；并且当用户抢单成功之后，从所述用户缓存区删除所述用户。