論文讀後感

本文所思及所得都是基於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表示每次迭代過程中的平均接單成功率 中間的整型矩陣即派單矩陣 最下面的矩陣表示司機對某個訂單的喜好程度