高峰期打车的供求关系不均衡的问题，一直被诟病。是否可以把打车看成一个推荐系统和一个广告系统，通过预估转化率，结合乘客的竞价来分配给相应的司机呢?
起晚了，着急去上班;下班了，着急回家吃饭;我们都习惯拿起手机准备叫个车，却总是被打车应用扔来一枚炸弹，把我们炸回现实，没有一点点防备：
这种一言不合就扔炸弹的行为，难道警察叔叔不管管吗?考虑到警民一家亲，我决定先一本正经地思考一下。
问题分析
高峰期为什么会涨价?废话，当然是因为高峰期乘客多，车辆供不应求啊。这是最最基础的经济规律。这个经济活动中，有三个博弈主体：乘客、司机和平台方。而高峰期加价现象本质是：
需求和供给匹配失衡
平台方不够给力，只能通过加价来调控
我们先对高峰期加价定个性：这不是帕累托最优的调控策略，因为：
加价吓走了很多 乘客 (需求没被满足);
加价没有快速吸引来更多的 司机
平台方 最终没有在高峰期赚到更多的钱，反而冒了一些用户可能会流失的风险。
理想的调控目标是：
不加价或者少量加价让 乘客 打到车;
司机 都能拉到想拉的乘客，不空驶，赚更多的钱;
乘客和司机都对 平台方 满意，并且平台方赚更多的钱
为了达到这个理想的目标，加价只是一种供求失衡的事后弥补的手段，我们应该充分利用乘客和司机积累的巨大数据，挖掘其中各自蕴藏的秘密，从而帮打车平台提前应对每一个上下班的洪峰来袭。
要解决高峰期打车应用的需求供给不匹配问题，我们需要从全局考虑两个问题：
如何把运力资源从过剩的地方引导到稀缺的区域来;
如何把市场需求从过旺的地方引导到冷门的区域来。
第一个主体方案，现在打车应用的做法是粗暴对乘客加价来吸引运力，这并不是理想方法，理想方法是帮司机找到他最想拉的乘客，获得金钱奖励效用之外的效用，这是一个典型的推荐系统，将司机对订单的诉求和乘客订单的特点精准匹配起来。
第二个方案是一个辅助方案，就是引导那些深处订单洪峰区域的用户通过可接受的少量其他交通方式(步行，公交，地铁)去到别的区域发送订单。比如引导中关村西区的乘客步行到黄庄发送订单，这可以稍微分散一下集中的订单，缓解交通拥堵。
基于这些思路，我们构想一下解决高峰期打车问题的主要模块：
供求关系预测系统
动态调度系统
司机偏好挖掘
乘客偏好挖掘
其关系如下：
乘客偏好挖掘
平台方需要对用户进行挖掘，掌握乘客的这些方面：
是否是愿意用时间换取合适的司机的人
是否是愿意用金钱换取合适司机的人
是否是通勤用户
常去目的地
愿意接受的加价倍数
用户价值
司机偏好挖掘
司机在当前时刻是否有常走的特定路线(如回家)
司机是否更在乎赚钱
司机商圈喜好
司机家庭地址(需组合时间特征)
司机常去目的地(更为熟悉的路线)
司机偏好的奖励类型(凑单/早晚高峰补贴/其他)
供求关系预测系统
该系统的作用是提前预测某个区域在某个时间段可能出现的订单数量。订单数量受多个因素的影响：
1.时间
比如：上下班高峰期、节假日、周五下午、企业可报销打车的临界点、电影院散场时间等等
2.地点
比如，帝都著名的三环国贸段、北医三院的花园路、下班时期的后厂村路等，地点的区域类型。
3.天气
突发阵雨、下雪等你能想到的各种恶劣天气
4.路况
修路、临时交通管制等
5.同期平均通勤人数
热门区域通常有大量的通勤人数，可以很好预测正常订单量
综合这些因素及其组合，可以预估某个区域的订单趋势，同时实时地结合该区域已有的司机数量，计算出预估的供求比。如果供求比紧张，可以提起给常用用户发送报警push，提醒他们错峰下班;另一边，还提前通知司机端目前闲置的运力，赶往供求比比较紧张的区域。
关于如何选择被通知的司机，大数据也可以发挥重要作用。本质上是要把合适的区域匹配给合适的司机，并提前推送告知。而推荐系统的核心价值是挖掘潜在司机，不断提高应答率。为此，系统需要用到司机端和目标区域(供求失衡区域)的特征数据。
需考虑的司机端的即时场景特征有：
司机与目标区域之间距离
司机去目标区域的时间成本
司机的商圈喜好
司机当前已接单的目的地方向
司机当日的成交单数(满足司机凑单需求)
需考虑的供求失衡区域的即时场景特征有：
目标区域的地理位置
目标区域的订单特征(路程长短、目的地分布等)
目标区域的拥堵情况
提前调度过程如下：
整个过程包含5个模块：召回潜在司机、预估司机应答率&排序、广播量预测、广播司机以及统计与反馈。
前两个模块用于计算应答率最高的司机名单;广播量预测模块需结合目标区域的订单量(预测值)和司机应答率(可结合历史经验)计算需广播的司机数量;统计与反馈模块用于实时收集司机应答率并反馈给系统用以补充候选司机名单，同时司机的应答行为也可以用于调整整个推荐系统的召回与排序模型。
另外，除系统主动广播司机外，还可以有一只“看不见的手”提前将运力资源过剩区域的司机在分派单策略中实现逐步引导到资源紧张的区域，具体策略下期细讨论。
调度系统
车辆调度系统本质上是一个推荐系统和广告系统的合体，把订单推送给最合适的司机，以提高转化率，让乘客，司机，平台三方的博弈趋向均衡态。
说他是个推荐系统，是因为它本质是在做匹配，为了提高订单转化率。这个推荐任务是把当前订单推送给最适合、最可能的司机。把这个想成是推荐系统，可以解决那些不愿意加价而愿意等待的用户的需求。推荐系统这边，需要大量用到挖掘到的乘客偏好和司机偏好，然后用技术手段将两者匹配，而不是统统加价。
一旦用户愿意主动加价，那我们又说他是个广告系统，是因为用户加价后本质上是在为自己买一个司机广告，本质上也是在计算转化率，并考虑到乘客愿意提出的竞价来进行综合排序，把预估转化率*加价作为最终输出的排序因素。
推荐和广告需要用到乘客端和司机端的各种偏好数据，以及当前场景下的供求关系预测结果。
需考虑的司机端即时场景特征有：
司机与目的地之间距离
司机去目的地的时间成本
司机当日的成交单数(满足司机凑单需求)
司机当前已接单的目的地(商圈、区域、方向)
同时还需要考虑乘客端的即时场景特征：
乘客愿意等待时间
乘客是否愿意拼车
乘客所去目的地(商圈、区域、方向)
乘客愿意接受的加价(一般是系统默认加价，乘客可自己增减)
整个匹配过程如下：
调度过程分为召回订单和订单排序推送两个阶段。从司机端来说，召回订单分为三个层次：
第一个层次是召回个性化的订单，不加价的情形下满足长尾和个性化需求;
第二个层次是召回具有附加值的订单，包括有现金加价的，高价值用户的订单，通勤用户订单;
第三个层次是可能有伤害，但风险略低的订单，也是为了满足核心需求之外的订单，包括为司机赢取奖励或者升级凑单;临时订单(低频用户的订单，非通勤用户订单);愿意等待的用户根据等待时间长短优先召回。
逐级为司机召回订单，并预估订单转化率，给司机推送他最想接的订单。这是结合推荐系统和广告系统的综合调度系统。
不论是调度系统是一个广告系统还是推荐系统，调度系统的框架就是计算匹配的可能性以及乘客应该付出的代价。基于这个框架，不断去发掘乘客取消订单的原因，不断发掘司机不接订单的原因，把这些原因作为特征加入到调度框架中，以提升订单转换率。
如何发掘司机不接订单的原因，可以通过数据挖掘一批司机进行访谈，比如系统预测可调度性高的司机，但并没有应答，或者比如明明在空驶，推送订单却不被司机接受，这些原因需要深入分析司机背后的心理来决定调度系统的改进。关于如何设计有效的用户访谈，可以参看《精益数据分析》第15章。
小结
高峰期打车的供求关系不均衡的问题，一直被诟病。我们提议可以把打车看成一个推荐系统和一个广告系统，通过预估转化率，结合乘客的竞价来分配给相应的司机了。这个框架下，最重要的是调度系统，乘客分析、司机分析。
但是，如果实在是你不想进行这么复杂的设计和计算，那么也不要气馁，无人驾驶可能马上就到来了。一旦实现无人驾驶，就可以完全用计算机去调度每一辆车了，而不是通过利用司机的人性来达到推广目的。
