论文读后感

本文所思及所得都是基于KDD(2017)由滴滴出行发表的论文：
A Taxi Order Dispatch Model based On Combinatorial Optimization

一、问题引入
在之前的出租车分配策略，都是顺序的将某个距离最近的出租车分配给一个候车人，初看起来，对于某个订单，我找到了距离最近的司机，这应该是合理的，但这并没有从全局进行考虑，所以并不会提升整体的接单成功率，因此可以说距离最近并不一定是最合适的。举个简单的例子，如下图所示：

图中有两个候车人Rider1和Rider2，以及三个司机Driver1、Driver2和Driver3，现在场景是：
Rider1和Rdier2同时发出了一个打车请求，按照顺序分配最优的策略，这个时候应该给Rider1分配给Driver1，因为两者的距离最近（1.5KM），Rider2分配给Driver3，因为Driver2当前还未完成上一单，因此根据该方案，最后实际距离为1.5+6=7.5KM。但是若是能够根据某些策略，能够将Rider1分配给Driver2，将Rider2分配给Driver1，那么实际距离为3+2=5KM。所以只单纯孤立的考虑某单，为其分配距离最近的司机，并不能达到全局最优（或者说近似全局最优）。
同时还有一个问题，当某个司机完成订单后，他只能被放到一个队列里面，等待下一次的分配，因此司机变成“静止”的了，从而无法激活司机的积极性。
由于分配上的策略，可能会导致某个候车人分配更远的司机，从而降低了用户体验。
二、解决方案
其中解决的主要有两个问题：
1.如何派单从而提升全局接单成功率
2.如何提升用户体验
接下来依次简述论文是如何处理这两个问题的（将问题抽象建模到模型求解的思路很值得学习）。
由于采用的是派单+抢单模式，将当前所有的订单分发到可用的司机端，但是司机端在一轮中最多只能收到一单，然后由司机决定是否接受该单，若在这一轮中，某单没有任何司机接受，那么该单则进入下轮。接着将该问题进行抽象：
假设当前共有N个订单，然后分派给M个可用的司机，记为：

最后我们只要得到这个矩阵了，那么也就知道如何派单了。
在上面还需要有一个限制条件

表明在一轮派单中派给司机j的订单数最多只有一单。
接下来我们来进一步抽象这个业务场景，司机对于分配给他的订单，他只能有两种操作，接受或者拒绝，那么我们更希望给他分配的订单，司机接受该单的概率越大越好，所以我们需要得到司机对每个订单的喜欢程度，或者说接受每个订单的概率。当知道每个司机对每个订单的接受程度后，那么接下来的工作就是如何分配才能最大化全局接单成功率了。
因此第一步：得到每个司机对每个订单的喜好程度，也就是司机接受订单的概率。
我们进行数学化描述：假设用

表示司机j接受订单i的概率。那么如何得到这个值了？其实只要我们将历史派单记录中的一个订单的信息

一个司机的信息

以及两者的交互信息联合起来作为一个样本属性

然后以这个订单是否成交（成交标记为1，否则标记为0）作为样本的标记y，那么就形成了不错的数据集，那么最后就是求解：

论文中基于LR和GBDT模型进行建模，最后选择了LR模型，从而有：

接下来第二步：最大化全局接单成功率。
因为一个订单是分配给M个司机，所以只要分配的其中一个人接单了那么就表明这个订单是成交的，即订单i的成功接单率：

那么全局接单成功率为：

所以我们最后的优化模型为：

最后就是对上面的模型进行求解，上面的模型是一种组合优化问题，论文中采用了启发式算法——爬山算法进行了求解。其思想就是先将每个订单分配给对该单最有可能接单的司机，然后计算当前分配情景下的全局接单成功率，接着遍历所有订单，然后对于没有派送该单的所有司机，如果用该单替换该司机之前的那个订单，并使得全局接单成功率得到了提升，那么就进行替换，同时更新全局接单成功率。
PS：在论文算法里面，并没有展示一些细节问题，比如算法并没有显示如何保证优化问题的限制条件成立。论文爬山算法中的第7行个人觉得应该放到循环外面。
对于提升用户体验方面，论文里面提到了基于贝叶斯的目的地预测模型，具体细节可参考论文。
三、实现
本文对论文中的派单模块进行了简单的实现，具体代码见Github：
https://github.com/jmsking/paper_imp.git
四、实验效果

其中avg_sr表示每次迭代过程中的平均接单成功率
中间的整型矩阵即派单矩阵
最下面的矩阵表示司机对某个订单的喜好程度