智慧配送系統的運籌最佳化實戰

美團配送業務場景複雜，單量規模大。下圖這組數字是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年加入美團，美團配送團隊資深演算法專家。