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

1. 背景

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

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

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。

複製代碼

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

複製代碼

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 年加入美團，目前主要負責配送算法數據平臺深度學習相關的研發工做。

本文轉載自美團技術博客： https://tech.meituan.com/2019/02/21/meituan-delivery-eta-estimation-in-the-practice-of-deep-learning.html