時效準確率提升之承運商路由網(wǎng)絡挖掘
1、引子
履約時長是電商的生命線，直接關系到用戶的消費體驗。新華網(wǎng)[5]2022年雙十一的報告顯示，37.4%的受訪者希望次日達，29.91%希望當日達。相較于其他物品，受訪者對手機、電腦、數(shù)碼產(chǎn)品的物流時效要求更高，更希望當日或1-2天內能收到貨。
得物履約場景中，主要的階段包括倉庫內生產(chǎn)和第三方承運商配送。在用戶支付時，得物會根據(jù)倉庫的生產(chǎn)情況和運配資源，給用戶一個承諾時效。
1.1 為什么要預測承運商的線路時效
在履約過程中，得物需要監(jiān)控訂單的流轉，及時的發(fā)現(xiàn)可能超時的訂單（與和用戶承諾時效相比），這里包含倉庫生產(chǎn)的監(jiān)控和三方配送的監(jiān)控。在實際過程中我們發(fā)現(xiàn)：配送節(jié)點發(fā)生變更時，承運商給的預測偏保守的。下面例子中，到了營業(yè)部承運商才給到比較精準的預計送達時間，故在分揀中心使用承運商的預計送達時間容易出現(xiàn)誤報。
網(wǎng)點 | 離開時間 | 承運商預計送達 |
xxx網(wǎng)點 | 2022-12-02 07:05:47 | 2022-12-10 22:00:00 |
A集貨分揀中心 | 2022-12-02 14:09:19 | 2022-12-10 22:00:00 |
B集貨分揀中心 | 2022-12-04 07:42:03 | 2022-12-10 22:00:00 |
C散貨分揀中心 | 2022-12-05 04:58:28 | 2022-12-09 22:00:00 |
D營業(yè)部 | 2022-12-05 08:47:58 | 2022-12-05 15:00:00 |
下圖是承運商接口返回的預計送達時效的寬松指數(shù)，可以看到在接近目的地時，承諾時效才比較準確。
2、承運商網(wǎng)絡是如何運作的
在構建承運商網(wǎng)絡之前，需要先了解承運商網(wǎng)絡是如何工作的。下面是從A網(wǎng)點到E網(wǎng)點的配送示意圖，分為以下內容：
（1）節(jié)點，包含的攬收和派送網(wǎng)點以及分揀中心。
（2）線路，包括干線和支線。例如從網(wǎng)點到分揀中心屬于支線，從分揀中心到分揀中心屬于干線。
（3）班次：承運商為了平衡成本和時效，會設置生產(chǎn)班次。到分揀中心之后，需要根據(jù)目的地進行分揀，當?shù)竭_一定量的貨物之后，會從分揀中心出發(fā)，前往下一個節(jié)點。承運商在設置班次的時候，會考慮單量，兼顧運輸?shù)某杀疽约皶r效。
上圖中：以紫色為例，在A網(wǎng)點，早上8點截單，即8點之前交接給承運商的貨物，會在8點20左右完成封車，然后從網(wǎng)點出發(fā)，前往B分揀中心，到達B分揀中心的時間是11點40，這個時候趕上了B分揀中心截單時間為12點的班次，B分揀中心會在12：30完成分揀并前往下一個分揀中心，以此類推完成整個配送過程。
在構建承運商的網(wǎng)絡時，需要進行建模。除了節(jié)點、線路和班次之外，核心還包括以下兩個模型：
（5）成品線，即從A網(wǎng)點到E網(wǎng)點經(jīng)過所有節(jié)點。上圖中：A網(wǎng)點-B分揀中心-C分揀中心-D分揀中心-E網(wǎng)點構成了一條成品線。
（6）成品線波次：因為節(jié)點存在波次，所以成品線也存在波次，實際上成品線波次和第一個節(jié)點的波次數(shù)一樣。
3、如何構建承運商網(wǎng)絡
在了解承運商網(wǎng)絡如何工作后，需要著手構建承運商的網(wǎng)絡。承運商會將軌跡信息推送到得物，內容類似以下的文本。
3.1 結構化清洗
軌跡的文本，需要經(jīng)過結構化的清洗之后，才能獲取軌跡的含義。對于每一個運單，它的軌跡會經(jīng)過很多個節(jié)點，而每個節(jié)點的數(shù)據(jù)類型如下：
3.2 軌跡里面是否真的有班次信息
承運商網(wǎng)絡工作原理提到了承運商會按班次進行生產(chǎn)，從軌跡的結果里面是否能找到班次生產(chǎn)的證據(jù)呢。通過分析，我們猜想：相同流向（例如從A分揀中心開往B分揀中心）離開某個分揀中心（例如離開A分揀中心）的時間應該是相對集中的。
實時上通過一些簡單的聚類方法，證實了我們的猜想。下面圖中，橫軸表示的是出分揀中心的小時，每一個點表示歷史上的某一個運單，縱軸沒有業(yè)務含義，只是為了方便顯示。
繪制上述圖時使用的是kmeans聚類算法，kmeans聚類算法需要指定聚類的個數(shù)。故需要使用Knee/Elbow這類的算法進行聚類數(shù)檢測，同時它對異常值敏感，故在實現(xiàn)時最終使用的DBSCAN。
3.3 聚類參數(shù)該如何選取
DBSCAN雖然不需要指定聚類的個數(shù)，但是需要指定點之間的距離以及點的密度，通過反復調整，最終確定這兩個核心的參數(shù)如下：
clustering = DBSCAN(eps=0.25, min_samples=max(5, int(x.size * 0.02)), metric=metric).fit(x_after_reshape)
其中eps為0.25，即15分鐘。點密度為5和總數(shù)的2%的最大值。
3.4 如何解決跨天的問題
從上面聚類圖看，同一個波次的點可能出現(xiàn)跨天的情況，即有些點出分撥中心的時間可能是23:50，有些分撥中心的點可能是00:10。這兩個點的歐式距離比較大，故需要重寫距離的metrics函數(shù)。
3.5 線路是如何串聯(lián)的
分析節(jié)點的生產(chǎn)班次和線路的班次是不夠的，還需要將它們進行串聯(lián)，得到成品線班次，這樣才能在售前或者售中進行應用。這里在處理的時候進行了一些簡化，一方面是分揀中心的分揀波次是沒有辦法識別到的，另外一方面其實可以不用關注分揀中心的分揀波次。
實際上，串聯(lián)成品線班次的過程是這樣的：
核心的代碼如下：
3.6 四級地址與攬派網(wǎng)點的關系是如何建立的
從應用的角度，輸入條件是買家的四級地址，但承運商網(wǎng)絡的終點是派送站點，故需要建立承運商派送站點和四級地址的映射關系。映射關系的建立比較簡單，取過去一段時間負責派送該四級地址的站點中，派送該地址單量最多的那個。
4、工程落地的挑戰(zhàn)
Part 3更像是一個理論家的滔滔不絕，那如何在工程上進行落地呢？這里面包含了ODPS SQL的開發(fā)、UDF的開發(fā)以及DDD，總之需要十八般武藝。
4.1 如何在ODPS進行簡單的機器學習
在班次分析的過程中，使用到DBSCAN的聚類算法。如果在odps上使用這些算法呢？實際上python里面已經(jīng)實現(xiàn)了DBSCAN算法，而odps支持使用python編寫UDF。只是目前odps的運行環(huán)境并沒有安裝DBSCAN相關的包，故需要手動進行安裝，安裝的教程可以參考阿里云的官方文檔
4.2 在線服務化的問題
上述清洗過程需要每天或者至少一周運行一次，選取過去一個時間窗口的數(shù)據(jù)進行訓練，得到承運商的網(wǎng)絡，這樣才能及時的感知承運商網(wǎng)絡的變化。這意味著會定時的更新成品線、成品線波次以及節(jié)點波次的信息，在在線服務化的過程中，我們是直接將數(shù)據(jù)這些數(shù)據(jù)存放在redis里面。為了不占用太多的內存，通過使用hash數(shù)據(jù)結構對內存進行了一些優(yōu)化，當然hash的一個缺點是無法為field設置超時時間，這意味著某個key的某個field數(shù)據(jù)實際已經(jīng)是過期數(shù)據(jù)了，但是它不會被刪除，進而造成泄漏，但這種泄漏可以通過其他技術手段解決。
5、進展與規(guī)劃
目前我們已經(jīng)構建了第三方承運商網(wǎng)絡，首網(wǎng)點預測的準確率在65%左右，末分揀預測的準確率在85%左右。未來持續(xù)優(yōu)化點包括：班次聚合（對于一些數(shù)據(jù)比較稀疏線路，需要做班次的聚合）、時間衰減（清洗數(shù)據(jù)需要選取過去一段時間的數(shù)據(jù)，對于太久遠的數(shù)據(jù)，應該進行衰減，使得它在結果中的貢獻小一些）等，相信準確率能有進一步提升。
6、參考文獻
[1]. Knee/Elbow Point Detection
[2]. arvkevi/kneed
[3].https://datascience.stackexchange.com/questions/46106/kmeans-vs-dbscan
[4]. https://redis.io/docs/management/optimization/memory-optimization/
[5]. 用戶調研:今年11.11消費者最關注“確定性” 京東是八成用戶首選-新華每日電訊
