智能配送系統的運籌優化實戰

深刻各個產業已經成爲互聯網目前的主攻方向，線上和線下存在大量複雜的業務約束和多種多樣的決策變量，爲運籌優化技術提供了用武之地。做爲美團智能配送系統最核心的技術之一，運籌優化是如何在美團各類業務場景中進行落地的呢？本文根據美團配送技術團隊資深算法專家王聖堯在2019年ArchSummit全球架構師峯會北京站上的演講內容整理而成。

美團智能配送系統架構

美團配送業務場景複雜，單量規模大。下圖這組數字是2019年5月美團配送品牌發佈時的數據。

更直觀的規模數字，多是美團每一年給騎手支付的工資，目前已經達到幾百億這個量級。因此，在如此大規模的業務場景下，配送智能化就變得很是重要，而智能配送的核心就是作資源的優化配置。

外賣配送是一個典型的O2O場景。既有線上的業務，也有線下的複雜運營。配送鏈接訂單需求和運力供給。爲了達到需求和供給的平衡，不只要在線下運營商家、運營騎手，還要在線上將這些需求和運力供給作合理的配置，其目的是提升總體的效率。只有將配送效率最大化，才能帶來良好的顧客體驗，實現較低的配送成本。而作資源優化配置的過程，其實是有分層的。根據咱們的理解，能夠分爲三層：

1. 基礎層是結構優化，它直接決定了配送系統效率的上限。這種基礎結構的優化，週期比較長，頻率比較低，包括配送網絡規劃、運力結構規劃等等。
2. 中間層是市場調節，相對來講是中短時間的，主要經過訂價或者營銷手段，使供需達到一個相對理想的平衡狀態。
3. 再上層是實時匹配，經過調度作實時的資源最優匹配。 實時匹配的頻率是最高的，決策的週期也最短。

根據智能配送的這三層體系，配送算法團隊也針對性地進行了運做。如上圖所示，右邊三個子系統分別對應這三層體系，最底層是規劃系統，中間層是訂價系統，最上層是調度系統。一樣很是重要的還包括圖中另外四個子系統，在配送過程當中作精準的數據採集、感知、預估，爲優化決策提供準確的參數輸入，包括機器學習系統、IoT 和感知系統、LBS系統，這都是配送系統中很是重要的環節，涉及大量複雜的機器學習問題。

而運籌優化則是調度系統、訂價系統、規劃系統的核心技術。接下來，咱們分享幾個典型的運籌優化案例。

實戰業務項目

智能區域規劃

爲了幫助你們快速理解配送業務的基本背景，這裏首先分享智能區域規劃項目中常常遇到的問題及其解決方案。

配送鏈接的是商家、顧客、騎手三方，配送網絡決定了這三方的鏈接關係。當用戶打開App，查看哪些商家能夠點餐，這由商家配送範圍決定。​每一個商家的配送範圍不同，看似是商家粒度的決策，但實際上直接影響每一個C端用戶獲得的商流供給，這自己也是一個資源分配或者資源搶奪問題。商家配送範圍智能化也是一個組合優化問題，可是咱們這裏講的是商家和騎手的鏈接關係。

用戶在美團點外賣，爲他服務的騎手是誰呢？又是怎麼肯定的呢？這些是由配送區域邊界來決定的。配送區域邊界指的是一些商家集合所對應的範圍。爲何要劃分區域邊界呢？從優化的角度來說，對於一個肯定問題來講，約束條件越少，目標函數值更優的可能性就越大。作優化的同窗確定都不喜歡約束條件，可是配送區域邊界實際上就是給配送系統強加的約束。

在傳統物流中，影響末端配送效率最關鍵的點，是配送員對他所負責區域的熟悉程度。這也是爲何在傳統物流領域，配送站或配送員，都會固定負責某幾個小區的緣由之一。由於越熟悉，配送效率就會越高。

即時配送場景也相似，每一個騎手須要儘可能固定地去熟悉一片商家或者配送區域。同時，對於管理而言，站點的管理範圍也比較明確。另外，若是有新商家上線，也很容易肯定由哪一個配送站來提供服務。因此，這個問題有不少運營管理的訴求在其中。

固然，區域規劃項目的發起，存在不少問題須要解決。主要包括如下三種狀況：

1. 配送區域裏的商家不聚合。這是一個典型站點，商家主要集中在左下角和右上角，形成騎手在區域裏取餐、送餐時執行任務的地理位置很是分散，須要不停往返兩個商圈，無效跑動很是多。
2. 區域奇形怪狀，空駛嚴重。以前在門店上線外賣平臺的發展過程當中，不少地方本來沒有商家，後來上線的商家多了，就單獨做爲一個配送區域。這樣的區域形狀可能就會不規則，致使騎手不少時候在區域外跑。 而商家和騎手都有綁定關係，騎手只能服務本身區域內的商家，所以騎手沒法接到配送區域外的取餐任務，空駛率很是高。不少時候騎手送完餐以後，只能空跑回來纔可能接到新任務。
3. 站點的大小不合理。圖三這個站點，天天的單量只有一二百單。若是從騎手平均單量的角度去配置騎手的話，只能配置3~4個騎手。若是某一兩我的忽然有事要請假，可想而知，站點的配送體驗必定會變得很是差，運營管理難度會很高。 反之，若是某一個站點變得很是大，站長也不可能管得了那麼多的騎手，這也是一個問題。因此，須要給每一個站點規劃一個合理的單量規模。

既然存在這麼多的問題，那麼作區域規劃項目就變得很是有必要。那麼，什麼是好的區域規劃方案？基於統計分析的優化目標設定。

優化的三要素是：目標、約束、決策變量。

第一點，首先要肯定優化目標。在不少比較穩定或者傳統的業務場景中，目標很是肯定。而在區域規劃這個場景中，怎麼定義優化目標呢？首先，咱們要思考的是區域規劃主要影響的是什麼。從剛纔幾類問題的分析能夠發現，影響的主要是騎手的順路性、空駛率，也就是騎手平均爲每一單付出的路程成本。因此，咱們將問題的業務目標定爲優化騎手的單均行駛距離。基於現有的大量區域和站點積累的數據，作大量的統計分析後，能夠定義出這樣幾個指標：商家聚合度、訂單的聚合度、訂單重心和商家重心的偏離程度。數據分析結果說明，這幾個指標和單均行駛距離的相關性很強。通過這一層的建模轉化，問題明確爲優化這三個指標。

第二點，須要梳理業務約束。在這方面，咱們花費了大量的時間和精力。好比：區域單量有上限和下限；區域之間不能有重合，不能有商家歸多個區域負責；全部的AOI不能有遺漏，都要被某個區域覆蓋到，不能出現商家沒有站點的服務。

基於業務場景的約束條件梳理

最難的一個問題，實際上是要求區域邊界必須沿路網。起初咱們很難理解，由於本質上區域規劃只是對商家進行分類，它只是一個商家集合的概念，爲何要畫出邊界，還要求邊界沿路網呢？其實剛纔介紹過，區域邊界是爲了回答若是有新商家上線到底屬於哪一個站點的問題。並且，從一線管理成原本講，更習慣於哪條路以東、哪條路以南這樣的表述方式，便於記憶和理解，提升管理效率。因此，就有了這樣的訴求，咱們但願區域邊界更「便於理解」。

在目標和約束條件肯定了以後，總體技術方案分紅三部分：

1. 首先，根據三個目標函數，肯定商家最優集合。這一步比較簡單，作運籌優化的同窗均可以快速地解決這樣一個多目標組合優化問題。
2. 後面的步驟比較難，怎麼把區域邊界畫出來呢？爲了解決這個問題，配送團隊和美團地圖團隊進行合做。先利用路網信息，把城市切成若干互不重疊的多邊形，而後根據計算幾何，將一批商家對應的多邊形拼成完整的區域邊界。
3. 最後，用美團自主研發的配送仿真系統，評測這樣的區域規劃對應的單均行駛距離和體驗指標是否符合預期。由於一線直接變更的成本很是高，仿真系統就起到了很是好的做用。

下面是一個實際案例，咱們用算法把一個城市作了從新的區域規劃。固然，這裏必需要強調的是，在這個過程當中，人工介入仍是很是必要的。對於一些算法很難處理好的邊角場景，須要人工進行微調，使整個規劃方案更加合理。中間的圖是算法規劃的結果。通過試點後，測試城市總體的單均行駛距離降低了5%，平均每一單騎手的行駛距離節省超過100米。能夠想象一下，在這麼龐大的單量規模下，每單平均減小100米，總節省的路程、節省的電瓶車電量，都是一個很是可觀的數字。更重要的是，可讓騎手本身明顯感受到本身的效率獲得了提高。

智能騎手排班

業務背景

這是隨着外賣配送的營業時間愈來愈長而衍生出的一個項目。早期，外賣只服務午高峯到晚高峯，後來你們慢慢能夠點夜宵、點早餐。到現在，不少配送站點已經提供了24小時服務。可是，騎手不可能全天24小時開工，勞動法對天天的工做時長也有規定，因此這一項目勢在必行。

另外，外賣配送場景的訂單「峯谷效應」很是明顯。上圖是一個實際的進單曲線。能夠看到全天24小時內，午晚高峯兩個時段單量很是高，而閒時和夜宵相對來講單量又少一些。所以，系統也沒辦法把一天24小時根據每一個人的工做時長作平均切分，也須要進行排班。

對於排班，存在兩類方案的選型問題。 不少業務的排班是基於人的維度，好處是配置的粒度很是精細，每一個人的工做時段都是個性化的，能夠考慮到每一個人的訴求。可是，在配送場景的缺點也顯而易見。若是站長鬚要爲每一個人去規劃工做時段，其難度可想而知，也很難保證分配的公平性。

配送團隊最終選用的是按組排班的方式，把全部騎手分紅幾組，規定每一個組的開工時段。而後你們能夠按組輪崗，每一個人的每一個班次都會輪到。

這個問題最大的挑戰是，咱們並非在作一項業務工具，而是在設計算法。而算法要有本身的優化目標，那麼排班的目標是什麼呢？若是你要問站長，怎麼樣的排班是好的，可能他只會說，要讓須要用人的時候有人。但這不是算法語言，更不能變成模型語言。

爲了解決這個問題，首先要作設計決策變量，決策變量並無選用班次的起止時刻和結束時刻，那樣作的話，決策空間太大。咱們把時間作了離散化，以半小時爲粒度。對於一天來說，只有48個時間單元，決策空間大幅縮減。而後，目標定爲運力需求知足訂單量的時間單元最多。這是由於，並不能保證站點的人數在對應的進單曲線狀況下能夠知足每一個單元的運力需求。因此，咱們把業務約束轉化爲帶懲罰的目標函數。這樣作，還有一個好處，那就是不必知道站點的總人數是多少。

在建模層面，標準化和通用的模型纔是最優選。因此，咱們把人數作了歸一化，算法分配每一個班次的騎手比例，但不分人數。最終只須要輸入站點的總人數，就獲得每一個班次的人數。在算法決策的時候，不決策人數、只決策比例，這樣也能夠把單量進行歸一化。每一個時間單元的進單量除以天天峯值時間單元的單量，也變成了0~1之間的數字。這樣就能夠認爲，若是某個時間單元內人數比例大於單量比例，那麼叫做運力獲得知足。這樣，經過各類歸一化，變成了一個通用的問題，而不須要對每種場景單獨處理。

另外，這個問題涉及大量複雜的強約束，涉及各類管理的訴求、騎手的體驗。約束有不少，好比每一個工做時段儘可能連續、每一個工做時段持續的時間不太短、不一樣工做時段之間休息的時間不太短等等，有不少這樣的業務約束，梳理以後能夠發現，這個問題的約束太多了，求最優解甚至可行解的難度太大了。另外，站長在使用排班工具的時候，但願能立刻給出系統排班方案，再快速作後續微調，所以對算法運行時間要求也比較高。

算法核心思想

綜合考慮以上因素，咱們最終基於約束條件，根據啓發式算法構造初始方案，再用局部搜索迭代優化。使用這樣的方式，求解速度可以達到毫秒級，並且能夠給出任意站點的排班方案。總體的優化指標還不錯，固然，不保證是最優解，只是能夠接受的滿意解。

落地應用效果

• 站點體驗指標良好，一線接受度高。
• 排班時間節省：2h/每站點每次

這種算法也在自營場景作了落地應用，跟那些排班經驗豐富的站長相比，效果基本持平，一線的接受程度也比較高。最重要的是帶來排班時間的節省，每次排班幾分鐘就搞定了，這樣可讓站長有更多的時間去作其它的管理工做。

騎手路徑規劃

具體到騎手的路徑規劃問題，不是簡單的路線規劃，不是從a到b該走哪條路的問題。這個場景是，一個騎手身上有不少配送任務，這些配送任務存在各類約束，怎樣選擇最優配送順序去完成全部任務。這是一個NP難問題，當有5個訂單、10個任務點的時候，就存在11萬多條可能的順序。而在高峯期的時候，騎手每每揹負的不止5單，甚至有時候一個騎手會同時接到十幾單，這時候可行的取送順序就變成了一個天文數字。

再看算法的應用場景，這是智能調度系統中最爲重要的一個環節。系統派單、系統改派，都依賴路徑規劃算法。在騎手端，給每一個騎手推薦任務執行順序。另外，用戶點了外賣以後，美團會實時展現騎手當前任務還須要執行幾分鐘，要給用戶提供更多預估信息。這麼多應用場景，共同的訴求是對時效要求很是高，算法運行時間要越短越好。

可是，算法僅僅是快就能夠嗎？並非。由於這是派單、改派這些環節的核心模塊，因此算法的優化求解能力也很是重要。若是路徑規劃算法不能給出較優路徑，可想而知，上層的指派和改派很難作出更好的決策。

因此，對這個問題作明確的梳理，核心的訴求是優化效果必須是穩定的好。不能此次的優化結果好，下次就很差。另外，運行時間必定要短。

在求解路徑規劃這類問題上，不少公司的技術團隊，都經歷過這樣的階段：起初，採用相似遺傳算法的迭代搜索算法，可是隨着業務的單量變大，發現算法耗時太慢，根本不可接受。而後，改成大規模鄰域搜索算法，但算法依然有很強的隨機性，由於沒有隨機性在就沒辦法獲得比較好的解。而這種基於隨機迭代的搜索策略，帶來很強的不肯定性，在問題規模大的場景會出現很是多的Bad Case。另外，迭代搜索耗時太長了。主要的緣由是，隨機迭代算法是把組合優化問題當成一個單純的Permutation問題去求解，不多用到問題結構特徵。這些算法，求解TSP時這樣操做，求解VRP時也這樣操做，求解Scheduling仍是這樣操做，這種相似「無腦」的方式很難有出色的優化效果。

因此，在這個項目中，基本能夠肯定這樣的技術路線。首先，只能作啓發式定向搜索，不能在算法中加隨機擾動。不能容許一樣的輸入在不一樣運行時刻給出不同的優化結果。而後，不能用普通迭代搜索，必須把這個問題結構特性挖掘出來，作基於知識的定製化搜索。

提及來容易，具體要怎麼作呢？咱們認爲，最重要的是看待這個問題的視角。這裏的路徑規劃問題，對應的經典問題模型，是開環TSP問題，或是開環VRP的變種麼？能夠是，也能夠不是。咱們作了一個有意思的建模轉換，把它看做流水線調度問題：每一個訂單能夠認爲是job；一個訂單的兩個任務取餐和送餐，能夠認爲是一個job的operation。任意兩個任務點之間的通行時間，能夠認爲是序列相關的準備時間。每一單承諾的送達時間，包括預訂單和即時單，能夠映射到流水線調度問題中的提早和拖期懲罰上。

算法應用效果

作了這樣的建模轉換以後，流水線調度問題就有大量的啓發式算法能夠借鑑。咱們把一個經典的基於問題特徵的啓發式算法作了適當適配和改進，能夠獲得很是好的效果。相比於以前的算法，耗時降低70%，優化效果不錯。由於這是一個肯定性算法，因此運行多少次的結果都同樣。咱們的算法運行一次，跟其它算法運行10次的最優結果相比，優化效果是持平的。

訂單智能調度

配送調度場景，能夠用數學語言描述。它不只是一個業務問題，更是一個標準的組合優化問題，而且是一個馬爾可夫決策過程。

並不是對於某個時刻的一批訂單作最優分配就足夠，還須要考慮整個時間窗維度，每一次指派對後面的影響。每一次訂單分配，都影響了每一個騎手後續時段的位置分佈和行進方向。若是騎手的分佈和方向不適合將來的訂單結構，至關於下降了後續調度時刻最優性的天花板。因此，要考慮長週期的優化，而不是一個靜態優化問題。

爲了便於理解，咱們仍是先看某個調度時刻的靜態優化問題。它不只僅是一個算法問題，還須要咱們對工程架構有很是深入的理解。由於，在對問題輸入數據進行拆解的時候，會發現算法的輸入數據太龐大了。好比說，咱們須要任意兩個任務點的導航距離數據。

而咱們面臨的問題規模，前幾年只是區域維度的調度粒度，一個商圈一分鐘峯值100多單，匹配幾百個騎手，可是這種乘積關係對應的數據已經很是大了。如今，因爲美團有更多業務場景，好比跑腿和全城送，是會跨很是多的商圈，甚至跨越半個城市，因此只能作城市級的全局優化匹配。目前，調度系統處理的問題的峯值規模，是1萬多單和幾萬名騎手的匹配。而算法容許的運行時間只有幾秒鐘，同時對內存的消耗也很是大。

另外，配送和網約車派單場景不太同樣。打車的調度是作司機和乘客的匹配，本質是個二分圖匹配問題，有多項式時間的最優算法：KM算法。打車場景的難點在於，如何刻畫每對匹配的權重。而配送場景還須要解決，對於沒有多項式時間最優算法的狀況下，如何在指數級的解空間，短期獲得優化解。若是認爲每一單和每一個騎手的匹配有不一樣的適應度，那麼這個適應度並非可線性疊加的。也就意味着多單對多人的匹配方案中，任意一種匹配都只能從新運算適應度，其計算量可想而知。

總結一下，這個問題有三類挑戰：

1. 性能要求極高，要作到萬單對萬人的秒級求解。咱們以前作了一些比較有意思的工做，好比基於歷史最優指派的結果，用機器學習模型作剪枝。基於大量的歷史數據，能夠幫助咱們節省不少無用的匹配方案評價。
2. 動態性。 做爲一個MDP問題，須要考慮動態優化場景，這涉及大量的預估環節。在只有當前未完成訂單的狀況下，騎手如何執行、每一單的完成時刻如何預估、將來時段會進哪些結構的訂單、對業務指標和效率指標產生怎樣的影響……可能會以爲這是一個典型的強化學習場景，但它的難點在於決策空間太大，甚至能夠認爲是無限大的。目前咱們的思路，是經過其它的建模轉換手段進行解決。
3. 配送業務的隨機因素多。好比商家的出餐時間，也許是很長時間內都沒法解決的隨機性。就連歷史每個已完成訂單，商家出餐時間的真值都很難得到，由於人爲點擊的數據並不能保證準確和完整。商家出餐時刻不肯定，這個隨機因素永遠存在，而且很是制約配送效率的提高。另外，在顧客位置交付的時間也不肯定。寫字樓工做日的午高峯，上電梯、下電梯的時間，很難準確進行預估。固然，咱們也在不斷努力讓預估變得更精準，但隨機性永遠存在。對於騎手來講，平臺無法規定每一個騎手的任務執行順序。騎手在配送過程當中能夠自由發揮，因此騎手執行順序的不肯定性也一直存在。爲了解決這些問題，咱們嘗試用魯棒優化或是隨機規劃的思想。可是，若是基於隨機場景採樣的方式，運算量又會大幅增長。因此，咱們須要進行基於學習的優化，優化不是單純的機器學習模型，也不是單純的啓發式規則，優化算法是結合真實數據和算法設計者的經驗，學習和演進而得。只有這樣，才能在性能要求極高的業務場景下，快速的獲得魯棒的優化方案。

目前，美團配送團隊的研究方向，不只包括運籌優化，還包括機器學習、強化學習、數據挖掘等領域。這裏具備不少很是有挑戰的業務場景，歡迎你們加入咱們。

做者簡介

王聖堯，2017年加入美團，美團配送團隊資深算法專家。