深度學習在美團配送ETA預估中的探索與實踐

1.背景

ETA（Estimated Time of Arrival，「預計送達時間」），即用戶下單後，配送人員在多長時間內將外賣送達到用戶手中。送達時間預測的結果，將會以」預計送達時間」的形式，展示在用戶的客戶端頁面上，是配送系統中很是重要的參數，直接影響了用戶的下單意願、運力調度、騎手考覈，進而影響配送系統總體成本和用戶體驗。

對於整個配送系統而言，ETA既是配送系統的入口和全局約束，又是系統的調節中樞。具體體如今：

• ETA在用戶下單時刻就須要被展示，這個預估時長繼而會貫穿整個訂單生命週期，首先在用戶側給予準時性的承諾，接着被調度系統用做訂單指派的依據及約束，而騎手則會按照這個ETA時間執行訂單的配送，配送是否準時還會做爲騎手的工做考覈結果。
• ETA做爲系統的調節中樞，須要平衡用戶-騎手-商家-配送效率。從用戶的訴求出發，儘量快和準時，從騎手的角度出發，過短會給騎手極大壓力。從調度角度出發，太長或過短都會影響配送效率。而從商家角度出發，都但願訂單被儘量派發出去，由於這關係到商家的收入。

ETA在配送系統中做用

 

在這樣多維度的約束之下，外賣配送的ETA的建模和估計會變得更加複雜。與打車場景中的ETA作對比，外賣場景的ETA面臨以下的挑戰：

• 外賣場景中ETA是對客戶履約承諾的重要組成部分，不管是用戶仍是騎手，對於ETA準確性的要求很是高。而在打車場景，用戶更加關心是否能打到車，ETA僅提供一個參考，司機端對其準確性也不是特別在乎。
• 因爲外賣ETA承擔着承諾履約的責任，所以是否可以按照ETA準時送達，也是外賣騎手考覈的指標、配送系統總體的重要指標；承諾一旦給出，系統調度和騎手都要盡力保證準時送達。所以太短的ETA會給騎手帶來極大的壓力，並下降調度合單能力、增長配送成本；過長的ETA又會很大程度影響用戶體驗。
• 外賣場景中ETA包含更多環節，騎手全程完成履約過程，其中包括到達商家、商家出餐、等待取餐、路徑規劃、不一樣樓宇交付等較多的環節，且較高的合單率使得訂單間的流程互相耦合，不肯定性很大，作出合理的估計也有更高難度。

外賣及打車中的ETA

 

下圖是騎手履約全過程的時間軸，過程當中涉及各類時長參數，能夠看到有十幾個節點，其中關鍵時長達到七個。這些時長涉及多方，好比騎手（接-到-取-送）、商戶（出餐）、用戶（交付），要經歷室內室外的場景轉換，所以挑戰性很是高。對於ETA建模，不光是簡單一個時間的預估，更須要的是全鏈路的時間預估，同時更須要兼顧」單量-運力-用戶轉化率」轉化率之間的平衡。配送ETA的演變包括了數據、特徵層面的持續改進，也包括了模型層面一路從LR-XGB-FM-DeepFM-自定義結構的演變。

ETA的探索與演變

 

具體ETA在整個配送業務中的位置及配送業務的總體機器學習實踐，請參看《機器學習在美團配送系統的實踐：用技術還原真實世界》。

2.業務流程迭代中的模型改進

2.1 基礎模型迭代及選擇

與大部分CTR模型的迭代路徑類似，配送ETA模型的業務迭代經歷了LR->樹模型->Embedding->DeepFM->針對性結構修改的路徑。特徵層面也進行不斷迭代和豐富。

• 模型維度從最初考慮特徵線性組合，到樹模型作稠密特徵的融合，到Embedding考慮ID類特徵的融合，以及FM機制低秩分解後二階特徵組合，最終經過業務指標需求，對模型進行鍼對性調整。
• 特徵維度逐步豐富到用戶畫像/騎手畫像/商家畫像/地址特徵/軌跡特徵/區域特徵/時間特徵/時序特徵/訂單特徵等維度。

目前版本模型在比較了Wide&Deep、DeepFM、AFM等經常使用模型後，考慮到計算性能及效果，最終選擇了DeepFM做爲初步的Base模型。整個DeepFM模型特徵Embedding化後，在FM（Factorization Machine）基礎上，進一步加入deep部分，分別針對稀疏及稠密特徵作針對性融合。FM部分經過隱變量內積方式考慮一階及二階的特徵融合，DNN部分經過Feed-Forward學習高階特徵融合。模型訓練過程當中採起了Learning Decay/Clip Gradient/求解器選擇/Dropout/激活函數選擇等，在此不作贅述。

2.2 損失函數

在ETA預估場景下，準時率及置信度是比較重要的業務指標。初步嘗試將Square的損失函數換成Absolute的損失函數，從直觀上更爲切合MAE相比ME更爲嚴苛的約束。在適當Learning Decay下，結果收斂且穩定。

同時，在迭代中考慮到相同的ETA承諾時間下，在先後N分鐘限制下，早到1min優於晚到1min，損失函數的設計但願總體的預估結果可以儘可能前傾。對於提早部分，適當下降數值懲罰。對於遲到部分，適當增大數值懲罰。進行屢次調試設計後，最終肯定之前後N分鐘以及原點做爲3個分段點。在原先absolute函數優化的基礎上，在前段設計1.2倍斜率absolute函數，後段設計1.8倍斜率absolute函數，以便讓結果總體往中心收斂，且預估結果更傾向於提早送達，對於ETA各項指標均有較大幅度提高。

損失函數

 

2.3 業務規則融入模型

目前的業務架構是」模型+規則」，在模型預估一個ETA值以後，針對特定業務場景，會有特定業務規則時間疊加以知足特定場景需求，各項規則由業務指標屢次迭代產生。這裏產生了模型和規則總體優化的割裂，在模型時間和規則時間分開優化後，即模型訓練時並不能考慮到規則時間的影響，而規則時間在一年之中不一樣時間段，會產生不一樣的浮動，在通過一段時間重複迭代後，會加大割裂程度。

在嘗試了不一樣方案後，最終將總體規則寫入到了TF模型中，在TF模型內部調整總體規則參數。

• 對於簡單的(a*b+c)*d等規則，能夠將規則邏輯直接用TF的OP算子來實現，好比當b、d爲定值時，則a、c爲可學習的參數。
• 對於過於複雜的規則部分，則能夠藉助必定的模型結構，經過模型的擬合來代替，過多複雜OP算子嵌套並不容易同時優化。

經過調節不一樣的擬合部分及參數，將多個規則徹底在TF模型中實現。最終對業務指標具有很大提高效果，且經過對部分定值參數的更改，具有部分人工干涉模型能力。

多目標補時結構

 

在這裏，總體架構就簡化爲多目標預估的架構，這裏採用多任務架構中經常使用的Shared Parameters的結構，訓練時按比例採起不一樣的交替訓練策略。結構上從最下面的模型中間融合層出發，分別在TF內實現常規預測結構及多個規則時間結構，而其對應的Label則仍然從常規的歷史值和規則時間值中來，這樣考慮瞭如下幾點：

• 模型預估時，已充分考慮到規則對總體結果的影響（例如多個規則的疊加效應），做爲總體一塊兒考慮。
• 規則時間做爲輔助Label傳入模型，對於模型收斂及Regularization，起到進一步做用。
• 針對不一樣的目標預估，採起不一樣的Loss，方便進行鍼對性優化，進一步提高效果。

模型結構在進行預估目標調整嘗試中：

• 嘗試過固定共享網絡部分及不固定共享部分參數，不固定共享參數效果明顯。
• 一般狀況下激活函數差別不大，但在共享層到獨立目標層中，不一樣的激活函數差別很大。

2.4 缺失值處理

在模型處理中，特徵層面不可避免存在必定的缺失值，而對於缺失值的處理，徹底借鑑了《美團「猜你喜歡」深度學習排序模型實踐》文章中的方法。對於特徵x進入TF模型，進行判斷，若是是缺失值，則設置w1參數，若是不是缺失值則進入模型數值爲w2*x，這裏將w1和w2做爲可學習參數，同時放入網絡進行訓練。以此方法來代替均值/零值等做爲缺失值的方法。

缺失值處理

 

3.長尾問題優化

3.1 模型預估結果+長尾規則補時

基礎模型學習的是總體的統計分佈，但對於一些長尾情形的學習並不充分，體如今長尾情形下預估時間偏短（因爲ETA擁有考覈騎手的功能，預估偏短對騎手而言意味着很大的傷害）。故將長尾拆解成兩部分來分析：

• 業務長尾，即總體樣本分佈形成的長尾。主要體如今距離、價格等維度。距離越遠，價格越高，實際送達時間越長，但樣本佔比越少，模型在這一部分上的表現總體都偏短。
• 模型長尾，即因爲模型自身對預估值的不肯定性形成的長尾。模型學習的是總體的統計分佈，但不是對每一個樣本的預估都有「信心」。實踐中採用RF多棵決策樹輸出的標準差來衡量不肯定性。RF模型生成的決策樹是獨立的，每棵樹均可以當作是一個專家，多個專家共同打分，打分的標準差實際上就衡量了專家們的「分歧」程度（以及對預估的「信心」程度）。從下圖也能夠看出來，隨着RF標準差的增長，模型的置信度和準時率均在降低。

模型長尾因子

 

在上述拆解下，採用補時規則來解決長尾預估偏短的問題：長尾規則補時爲 <業務長尾因子 , 模型長尾因子> 組合。其中業務長尾因子爲距離、價格等業務因素，模型長尾因子爲RF標準差。最終的ETA策略即爲模型預估結果+長尾規則補時。

4.工程開發實踐

4.1 訓練部分實踐

總體訓練流程

對於線下訓練，採起以下訓練流程：

Spark原始數據整合 -> Spark生成TFRecord -> 數據並行訓練 -> TensorFlow Serving線下GPU評估 -> CPU Inference線上預測

整個例行訓練億級數據多輪Epoch下流程持續約4小時，其中TF訓練中，考慮到TF實際計算效率並非很高，有很大比例在數據IO部分，經過Spark生成TFRecord部分，在此可將速度加速約3.6倍。而在數據並行訓練部分，16卡內的並行度擴展基本接近線性，具有良好的擴展性。因爲PS上參數量並未達到單機沒法承受，暫時未對參數在PS上進行切分。Serving線下GPU評估部分，是整個流程中的非必需項，雖然在訓練過程當中Chief Worker設置Valid集合可有必定的指標，但對全量線下，經過Spark數據調用Serving GPU的評估具有短期內完成所有流程能力，且能夠指定大量複雜自定義指標。

數據並行訓練方式

整個模型的訓練在美團的AFO平臺上進行，前後嘗試分佈式方案及單機多卡方案。考慮到生產及結果穩定性，目前線上模型生產採用單機多卡方案進行例行訓練。

• 分佈式方案：

採用TF自帶的PS-Worker架構，異步數據並行方式，利用tf.train.MonitoredTrainingSession協調整個訓練過程。整個模型參數存儲於PS，每一個Step上每一個Worker拉取數據進行數據並行計算，同時將梯度返回，完成一次更新。目前的模型單Worker吞吐1~2W/s，億級數據幾輪Epoch耗時在幾小時內完成。同時測試該模型在平臺上的加速比，大約在16塊內，計算能力隨着Worker數目線性增長，16卡後略微出現分離。在目前的業務實踐中，基本上4-6塊卡能夠短期內完成例行的訓練任務。

• 單機多卡方案：

採用PS-Worker的方案在平臺上具有不錯的擴展性，可是也存在必定的弊端，使用RPC的通信很容易受到其餘任務的影響，整個的訓練過程受到最慢Worker的影響，同時異步更新方式對結果也存在必定的波動。對此，在線上生產中，最終選取單機多卡的方案，犧牲必定的擴展性，帶來總體訓練效果和訓練速度的穩定性。單機多卡方案採起多GPU手動指定OP的Device，同時在各個Device內完成變量共享，最後綜合Loss與梯度，將Grad更新到模型參數中。

加速比曲線

 

TF模型集成預處理

模型訓練過程當中，ID類特徵低頻過濾須要用到Vocab詞表，連續型特徵都須要進行歸一化。這裏會產生大量的預處理文件，在線下處理流程中很容易在Spark中處理成Libsvm格式，而後載入到模型中進行訓練。可是在線上預測時，須要在工程開發端載入多個詞表及連續型特徵的歸一化預處理文件（avg/std值文件等），同時因爲模型是按天更新，存在不一樣日期版本的對齊問題。

爲了簡化工程開發中的難度，在模型訓練時，考慮將全部的預處理文件寫入TF計算圖之中，每次在線預測只要輸入最原始的特徵，不通過工程預處理，直接可獲得結果：

• 對於ID類特徵，須要進行低頻過濾，而後製做成詞表，TF模型讀入詞表的list_arr，每次inference經過ph_vals，獲得對應詞表的ph_idx。

tf_look_up = tf.constant(list_arr, dtype=tf.int64)
table = tf.contrib.lookup.HashTable(tf.contrib.lookup.KeyValueTensorInitializer(tf_look_up, idx_range), 0)
ph_idx = table.lookup(ph_vals) + idx_bias

• 對於連續型特徵，在Spark處理完獲得avg/std值後，直接寫入TF模型計算圖中，做爲constant節點，每一個ph_in通過兩個節點，獲得相應ph_out。

constant_avg = tf.constant(feat_avg, dtype=tf.float32, shape=[feat_dim], name="avg") constant_std = tf.constant(feat_std, dtype=tf.float32, shape=[feat_dim], name="std") ph_out = (ph_in - constant_avg) / constant_std 

4.2 TF模型線上預測

配送機器學習平臺內置了模型管理平臺，對算法訓練產出的模型進行統一管理和調度，管理線上模型所用的版本，並支持模型版本的切換和回退，同時也支持節點模型版本狀態的管理。

ETA使用的DeepFM模型用TensorFlow訓練，生成SavedModel格式的模型，須要模型管理平臺支持Tensorflow SavedModel格式。

實現方案 S 線上服務加載TensorFlow SavedModel模型有多種實現方案：

• 自行搭建TensorFlow Serving CPU服務，經過gRPC API或RESTful API提供服務，該方案實現比較簡單，但沒法與現有的基於Thrift的模型管理平臺兼容。
• 使用美團AFO GPU平臺提供的TensorFlow Serving服務。
• 在模型管理平臺中經過JNI調用TensorFlow提供的Java API TensorFlow Java API，完成模型管理平臺對SavedModel格式的支持。

最終採用TensorFlow Java API加載SavedModel在CPU上作預測，測試batch=1時預測時間在1ms之內，選擇方案3做爲實現方案。

遠程計算模式

TensorFlow Java API的底層C++動態連接庫對libstdc++.so的版本有要求，須要GCC版本不低於4.8.3，而目前線上服務的CPU機器大部分系統爲CentOS 6, 默認自帶GCC版本爲4.4.7。若是每臺線上業務方服務器都支持TensorFlow SavedModel本地計算的話，須要把幾千臺服務器統一升級GCC版本，工做量比較大並且可能會產生其餘風險。

所以，咱們從新申請了幾十臺遠程計算服務器，業務方服務器只須要把Input數據序列化後傳給TensorFlow Remote集羣，Remote集羣計算完後再將Output序列化後返回給業務方。這樣只須要對幾十臺計算服務器升級就能夠了。

在線序列化

 

線上性能

模型上線後，支持了多個業務方的算法需求，遠程集羣計算時間的TP99基本上在5ms之內，能夠知足業務方的計算需求。

線上效果

 

總結與展望

模型落地並上線後，對業務指標帶來較大的提高。後續將會進一步根據業務優化模型，進一步提高效果：

• 將會進一步豐富多目標學習框架，將取餐、送餐、交付、調度等整個配送生命週期內的過程在模型層面考慮，對訂單生命週期內多個目標進行建模，同時提高模型可解釋性。
• 模型融合特徵層面的進一步升級，在Embedding之外，經過更多的LSTM/CNN/自設計結構對特徵進行更好的融合。
• 特徵層面的進一步豐富。

做者簡介

• 基澤，美團點評技術專家，目前負責配送算法策略部機器學習組策略迭代工做。
• 周越，2017年加入美團配送事業部算法策略組，主要負責ETA策略開發。
• 顯傑，美團點評技術專家，2018年加入美團，目前主要負責配送算法數據平臺深度學習相關的研發工做。