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

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

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

交付時間的衡量是非常有挑戰的一件事，因為騎手在送餐交付到使用者手中時會碰到不同的問題，例如：騎手一次送餐給樓宇內多個使用者，騎手對於特定樓宇定址特別困難，騎手在交付樓宇附近只能步行，老舊小區沒有電梯，寫字樓無法上樓，或者難以等到電梯等等。交付時間預估需要具備刻畫交付難度的能力，在定價、排程等多個場景中被廣泛使用。例如根據交付難度來確定是否調節騎手郵資，根據交付難度來確定是否調節配送運單的順序，從而避免超時等等。總的來說，交付時間預估是配送業務基礎服務的重要一環。

• 輸入資訊較少，且多為非數值型資料，目前能夠被用來預估的僅有如下維度特徵：交付地址、交付點的經緯度、區域、城市，適配常規機器學習模型需要重新整理且容易丟失資訊。

• 計算效能要求很高。由於是基礎服務，會被大量的服務呼叫，需要效能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下降不如地址資訊明顯，主要是地址資訊包含一定冗餘資訊（下文會分析），而其他資訊的影響則可以忽略不計。

最終效果

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效能最快，但對效能有損失】

注：在評估中，不僅僅包括了序列模型，也包括了其他功能模組，故引數量及模型大小按照總體模型而言

3.3 向量效果分析

將向量召回與深度學習模型進行橫向比較，二者中間過程均生成了高維向量。不難發現，二者具備一定的相似性，這裡就引發了我們的思考：

• 相較於向量召回，深度學習模型帶來的提升主要來自於哪裡？

• 有監督的lstm學習到的Embedding向量與自監督的Word2Vec得到的向量在地址相似性計算中有多大差別，孰優孰劣？

首先，我們分析第一個問題，End-to-End模型提升主要來自哪裡？

我們直接將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個方面:

1. 對於charLevel地址的學習結構不同，一個為Word2Vec，一個為LSTM。

2. 輸入資訊的不同，Word2Vec的資訊輸入僅僅為地址主幹詞，而End-to-End的資訊輸入則包括了地址主幹詞、地址附屬資訊、GPS等其他資訊。

注：

• 完整地址：卓瑪護膚造型（洞庭湖店） （洞庭湖路與天山路交叉路口卓瑪護膚造型）

• 地址主幹詞：卓瑪護膚造型店

• 地址附屬資訊：（洞庭湖店）（洞庭湖路與天山路交叉路口卓瑪護膚造型）

針對第二個問題，有監督的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預估中的重要一環，關於ETA預估，請參見《深度學習在美團配送ETA預估中的探索與實踐》。

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

6. 作者介紹

基澤，美團點評技術專家。

閆聰，美團點評演算法工程師。