配送交付時間輕量級預估實踐

1. 背景

可能不少同窗都不知道,從打開美團App點一份外賣開始,而後在半小時內就能夠從騎手小哥手中拿到溫熱的飯菜,這中間涉及的環節有多麼複雜。而美團配送技術團隊的核心任務,就是將天天來自祖國各地的數千萬份訂單,迅速調度幾十萬騎手小哥按照最優路線,並以最快的速度送到你們手中。html

在這種場景下,騎手的交付時間,即騎手到達用戶附近下車後多久能送到用戶手中,就是一個很是重要的環節。下圖是一個訂單在整個配送鏈路的時間構成,時間軸最右部分描述了交付環節在整個配送環節中的位置。交付時間衡量的是騎手送餐時的交付難度,包括從騎手到達用戶樓宇附近,到將餐品交付到用戶手中的整個時間。前端

交付時間的衡量是很是有挑戰的一件事,由於騎手在送餐交付到用戶手中時會碰到不一樣的問題,例如:騎手一次送餐給樓宇內多個用戶,騎手對於特定樓宇尋址特別困難,騎手在交付樓宇附近只能步行,老舊小區沒有電梯,寫字樓沒法上樓,或者難以等到電梯等等。交付時間預估須要具有刻畫交付難度的能力,在訂價、調度等多個場景中被普遍使用。例如根據交付難度來肯定是否調節騎手郵資,根據交付難度來肯定是否調節配送運單的順序,從而避免超時等等。總的來講,交付時間預估是配送業務基礎服務的重要一環。git

可是,交付時間預估存在以下的困難:github

  • 輸入信息較少,且多爲非數值型數據,目前可以被用來預估的僅有以下維度特徵:交付地址、交付點的經緯度、區域、城市,適配常規機器學習模型須要從新整理且容易丟失信息。
  • 計算性能要求很高。因爲是基礎服務,會被大量的服務調用,須要性能TP99保證在10ms之內,整個算法平均響應時間須要控制在5ms內,其中包括數據處理及RPC的時間。且該標準爲CPU環境下的性能要求,而非GPU下的性能要求。

上圖爲部分版本所對應的性能,平響時間均在5ms內,TP99基本在10ms內

總結起來,交付時間預估的問題,在於須要使用輕量級的解決方案來處理多種數據形式的非數值型數據,並提取有效信息量,獲得相對準確的結果。在相同效果的前提下,咱們更傾向於性能更優的方案。算法

在本文中,咱們介紹了交付時間預估迭代的三個版本,分別爲基於地址結構的樹模型、向量召回方案以及輕量級的End-to-End的深度學習網絡。同時介紹瞭如何在性能和指標之間取捨,以及模型策略迭代的中間歷程,但願能給從事相關工做的同窗們有所啓發和幫助。後端

2. 技術迭代路徑

首先,在交付時間預估的技術迭代上,咱們主要經歷了三個大版本的改動,每一版本在5ms計算性能的約束下,追求輕量化的解決方案,在兼顧提高效果的基礎上,不顯著增長性能的消耗。網絡

本章節分別敘述了3個模型的迭代路徑,包括技術選型、關鍵方案及最終效果。數據結構

2.1 樹模型

技術選型框架

最先也是最容易被考慮到的是利用規則,核心思路是利用樹結構衡量地址類似性,儘量在類似的交付地址上積聚結構化數據,而後利用局部的迴歸策略,獲得相對充裕的迴歸邏輯,而未能達到迴歸策略要求的則走兜底的策略。機器學習

爲了快速聚積局部數據,樹模型是一個較爲合適的解決方案,樹的規則解析可以有效地彙集數據,同時一個層級並不深的樹,在計算速度上,具有足夠的優點,可以在較短的時間內,獲得相對不錯的解決方案。

觀察用戶填寫地址以及聯繫實際中地址的層級結構,不難發現,一個地址能夠由四級結構組成:地址主幹詞(addr)、樓宇號(building)、單元號(unit)、樓層(floor)。其中的地址主幹詞在實際中可能對應於小區名或者學校名等地標名稱。例如望京花園1號樓2單元5樓,解析爲(望京花園,1號樓,2單元,5樓)。經過分析,實際交付時長與樓層高低呈正相關關係,且不一樣交付地址的交付時長隨樓層增長的變化幅度也有所區別,因此可使用線性迴歸模型擬合樓層信息和交付時長的關係,而地址主幹詞、樓宇號、單元號做爲其層級索引。但用戶填寫的地址中並不必定包含完整的四級結構,就會存在必定比例的缺失,因此利用這樣的層級結構構建成一棵樹,而後充分利用上一層已知的信息進行預估。預測時,只需根據結點的分支找到對應的模型便可,若是缺失,使用上一層結構進行預測。對於沒有達到訓練模型要求數據量的地址,使用其所在的區域平均交付時長做爲交付時長的預估結果,這部分也能夠看做區域信息,做爲樹結構的根節點。

迭代路徑

總體的思路是基於離散特徵訓練樹模型,在樹的結點上基於樓層訓練線性迴歸模型。樹結點訓練分裂規則:(1)數據量大於閾值;(2)分裂後MAE(平均絕對偏差)的和小於分裂前。考慮到數據的時效性,採用加權線性迴歸增長近期數據的權重。

2.2 樹模型+向量召回方案

技術選型

向量召回做爲主流的召回方案之一,被業界普遍使用,在使用LSH、PQ乘積量化等經常使用開源工具基礎上,高維向量召回性能一般在毫秒量級。

而從算法上考慮,樹模型中NLP地址解析結果可以達到模型使用要求的僅爲70%+,剩餘20%+的地址沒法經過訓練獲得的模型從而只能走降級策略。利用高維向量來表達語義類似性,即利用向量來表達地址類似性,從而用類似數據對應的模型來替代類似但未被召回數據,將地址主幹詞進行Embedding後,擺脫主幹詞徹底匹配的低魯棒性。

例如,在地址上可能會出現【7天酒店晉陽街店】數據量比較充足,但【7天連鎖酒店太原高新區晉陽街店】數據量不充足從而沒法訓練模型的案例,這多是同一個交付位置。咱們但願儘量擴大地址解析的成功率。

迭代路徑

整個技術路徑較爲清晰簡單,即利用Word2Vec將charLevel字符進行Embedding,得到該地址的向量表示,而且融入GPS位置信息,設計相應兜底策略。

向量召回方案決策路徑

最終效果

比較大地提高了總體策略的召回率,提高了12.20pp,對於未被上一版本樹模型召回的地址,指標有了顯著的提高,其中ME降低87.14s,MAE降低38.13s,1min絕對誤差率減少14.01pp,2min絕對誤差率減少18.45pp,3min絕對誤差率減少15.90pp。

2.3 End-to-End輕量化深度學習方案

技術選型

在樹模型的基礎上,迭代到向量召回方案,整個模型的召回率有了較大幅度的增加,但仍然不是100%。分析發現,召回率提高的障礙在於NLP對於地址解析的覆蓋率。

整個方案的出發點:

從模型複雜度考慮,一樣僅僅使用地址信息的話,在提高模型VC維的基礎上,使用其餘的模型方案至少能夠持平樹模型的效果,若是在這基礎上還能融入其餘信息,那麼對於原模型的基線,還能有進一步的提高。

考慮到不只僅須要使用地址數據,同時須要使用GPS數據、大量ID類的Embedding,對於各種非數值類型的處理靈活性考慮,採用深度學習的方案,來保證多源且多類型特徵能在同一個優化體系下優化學習。

工程上須要考慮的點:

交付模型做爲基礎模型,被普遍應用在路徑構造、訂價、ETA等各個業務中頻繁調用,在樹模型版本中,對於性能的要求爲平均響應時間5ms,TP99在10ms左右,本方案須要考慮沿襲原業務的性能,不能顯著增長計算耗時。

交付模型的難點在於非數值型特徵多,信息獲取形式的多樣化,當前的瓶頸並不在於模型的複雜度低。若是能夠輕量地獲取信息及融合,不必對Fusion後的信息作較重的處理方案。

因此總體的設計思路爲:利用深度學習融合非數值型特徵,在簡單Fusion的基礎上,直接獲得輸出結構,對於組件的選擇,儘量選用Flops較低的設計。該設計背後意圖是,在充分使用原始輸入信息,在儘量避免信息損失的基礎上,將非數值型的信息融入進去。並將信息充分融合,直接對接所須要的目標。而選用的融合組件結構儘量保證高性能,且具有較高學習效率。這裏分別針對地址選用了較爲Robust的LSTM,針對GPS選用了自定義的雙線性Embedding,兼顧性能和效果。

迭代路徑

開始採用端到端的深度學習模型,這裏首先須要解決的是覆蓋率問題,直接採用LSTM讀取charLevel的地址數據,通過全鏈接層直接輸出交付時間。做爲初版本的數據,該版本數據基本持平樹模型效果,但對於樹模型未召回的20%數據,有了較大的提高。

地址信息輸入charLevel模型

在採用charLevel的地址奏效後,咱們開始採用加入用戶地址GPS的信息,因爲GPS爲經緯度信息,非數值型數據,咱們使用一種基於地理位置格點的雙線性插值方法進行Embedding。該方案具有必定的擴展性,對不一樣的GPS均能合理獲得Embedding向量,同時具有平滑特性,對於多對偏移較小的GPS點可以很好的進行支持。

最終方案將地址Embedding後,以及GPS點的Embedding化後,加入下單時間、城市ID、區域ID等特徵後,再進行特徵融合及變換,獲得交付模型的時間預估輸出。整個模型是一個端到端的訓練,全部參數均爲Trainable。

模型結構示意圖

擴展組件

在證明End-to-End路徑可行後,咱們開始進行擴展組件建設,包括自定義損失函數、數據採樣修正、全國模型統一等操做,獲得一系列正向效果,並開發上線。

特徵重要性分析

對於深度學習模型,咱們有一系列特徵重要性評估方案,這裏採用依次進行Feature Permutation的方式,做爲評估模型特徵重要性的方式。

考慮GPS經緯度和用戶地址存在較大程度的信息重疊,評估結果以下。Shuffle後,用戶地址的特徵重要性高於GPS經緯度的特徵重要性。加入GPS後ME降低不如地址信息明顯,主要是地址信息包含必定冗餘信息(下文會分析),而其餘信息的影響則能夠忽略不計。

特徵 特徵重要排名
用戶地址 1
GPS經緯度 2
其餘特徵 ......

注:在配送的其餘案例中,商戶GPS的經緯度重要性>>用戶地址重要性>>用戶GPS的經緯度重要性,該特徵重要性僅僅爲本案例特徵重要性排序,不一樣學習目標下可能會有比較明顯差異。

最終效果

End-to-End深度學習模型的最終效果較爲顯著:對於樹模型及向量召回方案的最痛點,覆蓋率獲得完全解決,覆蓋率提高到100%。ME降低4.96s,MAE降低8.17s,1min絕對誤差率減少2.38pp,2min絕對誤差率減少5.08pp,3min絕對誤差率減少3.46pp。同時,對於以前樹模型及向量召回方案未能覆蓋到的運單,提高則更爲明顯。

3. 模型相關分析

在整個技術迭代的過程當中,因爲整個解決方案對於性能有着較爲苛刻的要求,須要單獨對方案性能進行分析。本章節對向量召回方案及深度學習方案進行了相應的性能分析,以便在線下確認性能指標,最終保證上線後性能均達到要求。下文分別着重介紹了向量匹配的工具Faiss以及TensorFlow Operation算子的選取,還有對於總體性能的影響。

同時對比End-to-End生成向量與Word2Vec生成向量的質量區別,對於相關項目具有必定的借鑑意義。

3.1 向量召回性能

最近鄰搜索(Nearest Neighbor Search)指的是在高維度空間內找到與查詢點最近點的問題。在數據樣本小的時候,經過線性搜索就能知足需求,但隨着數據量的增長,如達到上百萬、上億點時候,傾向於將數據結構化表示來更加精確地表達向量信息。

此時近似最近鄰搜索ANN(Approximate Nearest Neighbor)是一個可參考的技術,它能在近似召回一部分以後,再進行線性搜索,平衡效率和精度。目前大致上有如下3類主流方法:基於樹的方法,如K-D樹等;基於哈希的方法,例如LSH;基於矢量量化的方法,例如PQ乘積量化。在工業檢索系統中,乘積量化是使用較多的一種索引方法。

針對向量召回的工具,存在大量的開源實現,在技術選型的過程當中,咱們參照ANN-Benchmarks以及Erikbern/ANN-Benchmarks中的性能評測結果。在衆多ANN相關的工具包內,考慮到性能、內存、召回精度等因素,同時能夠支持GPU,在向量召回方案的測試中,選擇以Faiss做爲Benchmark。

Faiss是FaceBook在2017年開源的一個用於稠密向量高效類似性搜索和密集向量聚類的庫,可以在給定內存使用下,在速度和精度之間權衡。能夠在提供多種檢索方式的同時,具有C++/Python等多個接口,也對大部分算法支持GPU實現。

下圖爲Faiss測評曲線:

交付時間模型召回的性能測試以下,能夠達到性能需求。

  • 召回候選集數量:8W條向量【因爲採用了GPS距離做爲距離限制,故召回測試採用8W數量級】
  • 測試機器:Mac本機CPU【CPU已知足性能,故再也不測試GPU】

3.2 序列模塊性能

在TensorFlow系統中,以C API爲界限,將系統劃分爲【前端】和【後端】兩個子系統,前端扮演Client角色,完成計算圖的構造,而後由Protobuf發送給後端啓動計算圖計算。計算圖的基礎單元是OP,表明的是某種操做的抽象。在TensorFlow中,考慮到實現的不一樣,不一樣OP算子的選擇,對於計算性能具備較大影響。

爲了評測深度學習交付模型的性能瓶頸,首先對整個模型進行Profile,下圖即爲Profile後的Timeline,其中整個計算大部分消耗在序列模塊處理部分,即下圖中的藍色部分。故須要對序列模塊的計算性能進行OP算子的加速。

考慮到序列處理的需求,評估使用了LSTM/GRU/SRU等模塊,同時在TensorFlow中,LSTM也存在多種實現形式,包括BasicLSTMCell、LSTMCell、LSTMBlockCell、LSTMBlockFusedCell和CuDNNLSTM等實現,因爲整個交付模型運行在CPU上,故排除CuDNNLSTM,同時設置了全鏈接層FullyConnect加入評估。

從評估中能夠發現,全鏈接層速度最快,可是對於序列處理會損失2.3pp效果,其他的序列模型效果差別不大,但不一樣的OP實現對結果影響較大。原生的BasicLSTM性能較差,contrib下的LSTMBlockFusedCell性能最好,GRU/SRU在該場景下未取得顯著優點。

這是LSTMBlockFusedCell的官方說明,其核心實現是將LSTM的Loop合併爲一個OP,調用時候整個Timeline上更爲緊湊,同時節約時間和內存:

This is an extremely efficient LSTM implementation, that uses a single TF op for the entire LSTM. It should be both faster and more memory-efficient than LSTMBlockCell defined above.

如下是序列模塊的性能測試:

  • 環境:Tensorflow1.10.0,CentOS 7。
  • 測試方法:CPU inference 1000次,取最長的地址序列,求平均時間。
  • 結論:LSTMBlockFused實現性能最佳。【FullyConnect性能最快,但對性能有損失】

注:在評估中,不只僅包括了序列模型,也包括了其餘功能模塊,故參數量及模型大小按照整體模型而言

lstm結構OP 時間(ms) FLOPs 可訓練參數量 模型大小(MB) 效果差別
Fully Connect 1.18 27.83M 7.00M 29.1 -2.3pp
SRU 4.00 27.96M 7.06M 29.4 差別不顯著
GRU Block 3.64 28.02M 7.10M 29.6 差別不顯著
GRU 4.44 28.02M 7.10M 29.6 差別不顯著
LSTMBlockFused 2.48 28.09M 7.13M 29.7 差別不顯著
LSTM Block 4.34 28.09M 7.13M 29.7 差別不顯著
LSTM 4.85 28.09M 7.13M 29.7 差別不顯著
BasicLSTM 4.92 28.09M 7.13M 29.7 差別不顯著

3.3 向量效果分析

將向量召回與深度學習模型進行橫向比較,兩者中間過程均生成了高維向量。不難發現,兩者具有必定的類似性,這裏就引起了咱們的思考:

相較於向量召回,深度學習模型帶來的提高主要來自於哪裏?

有監督的lstm學習到的Embedding向量與自監督的Word2Vec獲得的向量在地址類似性計算中有多大差異,孰優孰劣?

首先,咱們分析第一個問題,End-to-End模型提高主要來自哪裏?

ME MAE 1min絕對誤差率 2min絕對誤差率 3min絕對誤差率
End-to-End模型 - Word2Vec模型 4.14 -0.45 -0.31% 0.05% -0.41%

咱們直接將End-to-End模型獲得的char embedding抽取出來,直接放入到Word2Vec方案內,取代Word2Vec生成的char embedding,再進行向量召回的評估。結果以下表所示,單獨抽取出來的char embedding在向量召回方案中,表現與Word2Vec生成的向量基本一致,並無明顯的優點。

注:

  • 1min絕對誤差率定義:|pred-label|<=60s
  • 2min絕對誤差率定義:|pred-label|<=120s
  • 3min絕對誤差率定義:|pred-label|<=180s

此時的變量有2個方面:

  • a)對於charLevel地址的學習結構不一樣,一個爲Word2Vec,一個爲LSTM

  • b)輸入信息的不一樣,Word2Vec的信息輸入僅僅爲地址主幹詞,而End-to-End的信息輸入則包括了地址主幹詞、地址附屬信息、GPS等其餘信息。

注:

  • 完整地址:卓瑪護膚造型(洞庭湖店) (洞庭湖路與天山路交叉路口卓瑪護膚造型)
  • 地址主幹詞:卓瑪護膚造型店
  • 地址附屬信息:(洞庭湖店)(洞庭湖路與天山路交叉路口卓瑪護膚造型)

爲了排除第二方面的因素,即b的因素,使用地址主幹詞做爲輸入,而不用地址附屬信息和其餘模型結構的輸入,保持模型輸入跟Word2Vec一致。在測試集上,模型的效果比完整地址有明顯的降低,MAE增大約15s。同時將char embedding提取出來,取代Word2Vec方案的char embedding,效果反而變差了。結合2.3節中的特徵重要性,可知,深度學習模型帶來的提高主要來自對地址中冗餘信息(相較於向量召回)的利用,其次是多個新特徵的加入。另外,對比兩個End-to-End模型的效果,地址附屬信息中也包含着對匹配地址有用的信息。

ME MAE 1min絕對誤差率 2min絕對誤差率 3min絕對誤差率
End-to-End模型 - Word2Vec模型 -1.28 0.64 0.90% 0.85% 0.35%

針對第二個問題,有監督的End-to-End學習到的Embedding向量,與自監督的Word2Vec獲得的向量在地址類似性計算中有多大差異,孰優孰劣?

採用地址主幹詞代替完整地址,做爲End-to-End模型的輸入進行訓練,其餘信息均保持不變。使用地址主幹詞訓練獲得的Embedding向量,套用到向量召回方案中。

從評估結果來看,對於不一樣的閾值,End-to-End的表現差別相對Word2Vec較小。相同閾值下,End-to-End召回率更高,可是效果不如Word2Vec。

從類似計算結果看,End-to-End模型會把一些語義不相關可是交付時間相近的地址,映射到同一個向量空間,而Word2Vec則是學習一個更通用的文本向量表示。

例如,如下兩個交付地址會被認爲向量距離相近,但事實上只是交付時間相近: 南內環西街與西苑南路交叉口金昌盛國會<=>辰憬家園迎澤西大街西苑南路路口林香齋酒店

若是想要針對更爲複雜的目標和引入更多信息,可使用End-to-End框架;只是計算文本類似性,從實驗結果看,Word2Vec更好一些。同時,經過查看Case也能夠發現,End-to-End更關注結果類似性,從而召回一部分語義上徹底不相關的向量。兩個模型目標上的不一樣,從而致使告終果的差別。

4. 總結與展望

在本篇中,依次展現了在配送交付場景下的三次模型策略迭代過程,以及在較爲苛刻性能要求限制下,如何用輕量化的方案不斷提升召回率及效果。同時,對迭代過程當中的性能進行簡單的分析及衡量,這對相關的項目也具有必定的借鑑意義,最後對Word2Vec及End-to-End生成的向量進行了比較。

事實上,本文中說起的向量召回及深度學習融合非數值型特徵的方案,已經在業界被普遍使用。但對於差別化的場景,本文仍具有必定的借鑑價值,特別是對於訂單-騎手匹配、訂單-訂單匹配等非搜索推薦領域的場景化應用,以及TF OP算子的選用及分析、Embedding生成方式帶來的差別,但願可以給你們提供一些思路和啓發。

5. 關聯閱讀

交付時間預估與ETA預估及配送其餘業務關係:

6. 做者介紹

  • 基澤,美團點評技術專家
  • 閆聰,美團點評算法工程師

7. 招聘信息

美團配送AI團隊支撐全球領先的即時配送網絡——美團配送,並創建了行業領先的美團智能配送系統。美團配送AI團隊主要來自一線互聯網公司以及知名科研機構,研發實力和氛圍卓越。目前美團配送業務仍處於快速發展期,新的場景、新的技術難題不斷涌現,成長空間巨大。

美團配送AI團隊現誠聘算法策略工程師、機器學習工程師和運籌優化工程師,歡迎有興趣的小夥伴投遞簡歷至:tech@meituan.com(郵件標題註明:美團配送AI團隊)

相關文章
相關標籤/搜索