【无标题】

滴滴司机调度

《When Recommender Systems Meet Fleet Management: Practical Study in Online Driver Repositioning System》

背景

解决供需错配，为空闲司机个性化推荐接单点。
目标：优化司机体验，同时提高平台效率
挑战：

1. 司机体验满意度：失败的调度会增加司机对平台的质疑，降低信任度。 -> 要确保能接到单
2. 获取丰富的实时供需信息，以上帝视角协调多司机协作

总结

1. 定义司机调度问题，提供工业界解法
2. 设计“调度任务”
3. 建模，解最优化问题
4. 收益：司机收入+2%

调度任务

1. 向空闲司机提供一个建议的指定地点with更高可能性接到单，并同时提供导航和eta
2. 定义是否调度成功：
   去了相反方向 -> 0
   向目的地走，并在途中接到单 -> 1
   向目的地走，到达后xmin内接到单 -> 1
   向目的地走，到达后xmin内未接到单 -> 0
3. 失败补偿，建立司机和平台的信任

建模

召回 rep=

1. 司机召回（D*）：等待时长>x
2. 目的地召回（G*）：distance < a && eta< b。 临近位置（如.附近三圈13层格子）/ 路网结构容易到达的 （如. 有高速）/ 全城热点
3. 失败率控制（F）：使用调度失败概率模型进行过滤，模型刻画司机在当前供需场景下对调度路线的接受程度，类似接受率ctr模型，故特征考虑driver related + route related + supply-demand
4. 调度补偿（r) : =average order fare in city

任务打分

任务的score衡量的是调度任务可以给大盘提效多少，可以让实时供需平衡收益多少。所以将score定义为向目的地输送一个司机带来的边际效益提升。

首先，用当前区域的司机和订单个数拟合一条应答率曲线, 每个样本表示一个特定的时空

对每一次调度任务，可以对其时空边际效益打分，即增加一个司机对当前格子的增益：

同时，可以计算出这个时空到达预期应答率的司机数量缺口delta（capacity of driver)

其中，下式表示达到Rr_hat需要的司机数是多少，订单量是预估值。

Programming

建模最优化问题，要最大化的是所有调度任务的价值，限制每个司机只能被分配一个调度任务 且 格子调度个数不能超过最大司机数量缺口

为解决计算量过大的问题，将此优化问题转化为最小费用流问题：

每条edge上的两个值分别表示<容量capacity, 花费cost>， 表示流量从左到右，在容量的限制下，如何选择路径，可以使得花费最小。这里的最小化花费 也就是 最大化价值。

实验

evaluation 指标：

1. CPO：单均进线量 （ 不是针对单的投诉，无单的情况怎么计算单均进线量？？）
2. IPH: 总收入（看司机体验）和小时收入（看效率）
3. GMV

observation 指标：

4. 司机天均调度任务个数
5. 接受率：接受调度任务个数 / 总调度任务个数
6. 失败率：接受且失败个数 / 接受个数

实验方式：

1. 司机id分流 - > 给司机调度任务 or 司机自由行驶。可观测司机相关指标 如接受率、失败率、cpo
2. 两小时时间片分流 -> gmv

insights

1. 早高峰司机都很忙，调度任务触发很少
2. 接受率全天基本一致
3. 高峰期失败率很低，其他时间的失败率也只有10%，牛。
4. 午夜接受率低，失败率高