上一篇文章《你以為送外賣全靠小哥飆車嗎？快是因?yàn)橛懈呖萍嫉?！》讓大家知道原來送個外賣背后居然還有個巨大的物流細(xì)分市場——即時配送，而且30分鐘能送到是因?yàn)橛兄悄苷{(diào)度系統(tǒng)支撐的。那么問題來了，外賣公司不是搭了個信息化平臺嗎？把訂單放上去，讓騎手小哥上去搶單就行了，有生意誰不做呀？這個調(diào)度系統(tǒng)需要多少智能呢？

核心的問題在于，外賣訂單中有容易送的“肉”，也有難以完成的“骨頭"，如果靠搶單就會嚴(yán)重依賴騎手的決策能力，挑肉的多而沒人挑骨頭送，假如按照定價高低來搶，一方面人力成本不可控，另一方面搶到遠(yuǎn)的肉還影響配送效率，用戶體驗(yàn)不佳，搶不到肉的騎手會投訴，經(jīng)常這樣必然會想退出，邊騎邊拿手機(jī)搶單安全風(fēng)險也高。

其實(shí)，搶單模式包括再之前效率更低、容易作弊的人工派單模式，還有之后不具備全局優(yōu)化能力的搶推結(jié)合模式，外賣平臺都曾經(jīng)嘗試過，最終還是得往智能派單方向去走。

因?yàn)榍皫追N模式只是基于位置的服務(wù)（Location Based Services，LBS）和延遲隊(duì)列（訂單或騎手運(yùn)力）去執(zhí)行簡單調(diào)度，控制臺調(diào)度引擎計(jì)算的內(nèi)容太少，很多訂單的復(fù)雜度并未考慮在內(nèi)，所以用戶下單體驗(yàn)水平差異很大，平臺管控能力也弱。

因此調(diào)度系統(tǒng)的智能不僅僅是靜態(tài)的訂單分配問題，還包含動態(tài)的騎手路徑規(guī)劃問題。

智能調(diào)度系統(tǒng)不僅要考慮訂單池、運(yùn)力池的匹配，還必須將包括路徑規(guī)劃算法在內(nèi)的各種算法，形成算法庫，通過在不同條件下調(diào)用合適的算法將訂單池里的待發(fā)訂單和運(yùn)力池里的可用騎手對應(yīng)關(guān)聯(lián)起來。

調(diào)度系統(tǒng)的智能性在外賣平臺的訂單量大、騎手多的情況下至關(guān)重要，靠人工派單或主動搶單會完全亂套。

那么算法庫里的各種復(fù)雜算法是靠人想出來的嗎？首先肯定的是必須要有完整的流程來保障算法的可靠設(shè)計(jì)，并且還是一個不斷循環(huán)、反復(fù)測試、持續(xù)迭代的過程。

算法的迭代也不是光靠數(shù)學(xué)邏輯強(qiáng)的人坐在辦公室里就能想全、不斷改造升級的，算法的效果必須接受實(shí)際運(yùn)作無情的鞭打和驗(yàn)證，主動加被動改進(jìn)是系統(tǒng)調(diào)度開發(fā)人員的家常便飯。

因此事后有可視化的回放軌跡，反過來了解為什么算法會派出這種不合理的訂單給騎手，也是改進(jìn)算法的重要工具，至少能夠亡羊補(bǔ)牢。當(dāng)前適用的算法在平臺訂單量和運(yùn)力池持續(xù)提升的過程中也未必一直好用，所以算法庫版本需要一直升級。升級不是說越加越多算法、越搞越復(fù)雜，而有可能是當(dāng)訂單數(shù)量和路徑復(fù)雜度指數(shù)倍增加時，自動或手動降級、減少算法輸入、犧牲部分效果來保證訂單的可執(zhí)行。主動降級也是一種智能。

那么到最后，變動這么大的算法不能讓平臺調(diào)度出現(xiàn)系統(tǒng)性的崩潰等大風(fēng)險，必須有工程管理方法去精細(xì)化保證整個調(diào)度系統(tǒng)，從規(guī)劃預(yù)防開始，到能實(shí)時識別診斷風(fēng)險，最終風(fēng)險爆發(fā)時可控并基本保障外賣訂單的運(yùn)作。

所以，你下的外賣訂單交給哪個騎手來送，不是你覺得哪個小哥帥就能決定讓他天天上門的，平臺調(diào)度系統(tǒng)會結(jié)合各種條件運(yùn)用算法去計(jì)算分配，如果你有指定帥哥定點(diǎn)送外賣的需求，開發(fā)人員還得確認(rèn)是不是普遍需求，值不值得去設(shè)置提供這種服務(wù)呢，你說是吧？