《人物》雜志發(fā)表了《外賣騎手，困在系統(tǒng)里》一文，文中從外賣騎手的視角出發(fā)，探究了目前外賣生態(tài)中外賣騎手送餐只能越來越快、越來越不顧自身安全的困局，引起大家對于外賣平臺以及其所設(shè)計(jì)出來的算法的批判，并且在引言中發(fā)起一個(gè)思考：

數(shù)字經(jīng)濟(jì)的時(shí)代，算法究竟應(yīng)該是一個(gè)怎樣的存在？[1] 

確實(shí)，算法是一個(gè)怎樣的存在呢？ 

為了研究外賣平臺所使用的算法，我們仔細(xì)閱讀了一篇由阿里本地生活智慧物流團(tuán)隊(duì)發(fā)布的論文《Order Fulfillment Cycle Time Estimation for On-Demand Food Delivery》（外賣履約時(shí)間預(yù)估）[2]。該論文首次比較系統(tǒng)地披露了外賣平臺（餓了么）目前采用哪些特征如何設(shè)計(jì)算法來預(yù)估從顧客下單到外賣員送餐到顧客手上所使用的時(shí)間，被KDD 2020（數(shù)據(jù)挖掘領(lǐng)域頂級會議）接收為口頭報(bào)告論文。

且聽我解釋。 

一、關(guān)于算法造成騎手困局的邏輯 

《外賣騎手，困在系統(tǒng)里》一文中透露出來的邏輯，或者說大家腦海里關(guān)于算法造成騎手困局的邏輯是這樣的：

首先，算法根據(jù)歷史數(shù)據(jù)決定縮短配送時(shí)間，騎手為了避免訂單超時(shí)只好狂飆、逆行、闖紅燈，而騎手的這些舉動確實(shí)把實(shí)際送餐時(shí)間縮短了，產(chǎn)生了更多的短時(shí)長數(shù)據(jù)，算法根據(jù)這些短時(shí)長數(shù)據(jù)決定再縮短配送時(shí)間。這樣惡性循環(huán)讓騎手的配送時(shí)間越縮越短，算法讓騎手越來越陷入困局。 

在這期間，算法只根據(jù)餐廳到顧客的直線距離決定騎手配送時(shí)間，而不管實(shí)際路況、天氣狀況、餐廳出餐時(shí)間、騎手等電梯時(shí)間。算法總是以盡可能縮短配送時(shí)間為目標(biāo)。 

是這樣的嗎？ 

二、算法的目標(biāo) 

首先，我們這里所說的算法，指的是通過歷史訂單等各種數(shù)據(jù)，找出影響配送時(shí)間的因素及權(quán)重，以決定下一次騎手送餐時(shí)間長短的方法。 

比如說，假如我們只把商家與下訂單者之間的距離作為因素，現(xiàn)有3個(gè)歷史訂單數(shù)據(jù)：1公里內(nèi)配送時(shí)間為15分鐘，2公里為30分鐘，3公里為45分鐘，那么我們根據(jù)這些歷史訂單數(shù)據(jù)就可以得出一個(gè)完美擬合歷史數(shù)據(jù)的算法模型：配送時(shí)間 = 距離 * 15。下一個(gè)訂單如果商家與下訂單者之間的距離是1.5公里的話，我們就可以使用這個(gè)算法模型預(yù)測騎手的配送時(shí)間為22分鐘30秒。 

通過《Order Fulfillment Cycle Time Estimation for On-Demand Food Delivery》這篇論文（下稱論文）我們知道，餓了么平臺是通過設(shè)計(jì)一個(gè)深度神經(jīng)網(wǎng)絡(luò)算法來預(yù)測訂單的配送時(shí)間。

它的做法是選擇很多影響配送時(shí)間的因素，使用歷史數(shù)據(jù)訓(xùn)練一個(gè)深度神經(jīng)網(wǎng)絡(luò)，試圖找到一組參數(shù)讓這個(gè)深度神經(jīng)網(wǎng)絡(luò)算法預(yù)測出來的配送時(shí)間跟歷史訂單的配送時(shí)間最接近（也就是最小化算法的目標(biāo)函數(shù)），這樣算法的預(yù)估配送時(shí)間就越準(zhǔn)確。也就是說，這個(gè)算法的目標(biāo)是如何讓算法更加準(zhǔn)確地?cái)M合歷史數(shù)據(jù)，而不是盡可能地縮短配送時(shí)間。 

但是現(xiàn)實(shí)中配送時(shí)間就是越縮越短呀，這是怎么回事呢？

三、算法是受歷史數(shù)據(jù)影響的 

上面說了，算法的目標(biāo)是更加準(zhǔn)確地?cái)M合歷史數(shù)據(jù)，以準(zhǔn)確地預(yù)測配送所需的時(shí)間，所以毋庸置疑，算法是受歷史數(shù)據(jù)影響的。歷史數(shù)據(jù)的結(jié)構(gòu)性變動會影響算法的參數(shù)。 

回到上面簡單的例子，假如現(xiàn)在平臺上有兩名騎手，自愿或者被動地加快了送餐速度，其中一名騎手送2公里的餐食只用了20分鐘，一名騎手送3公里的餐食只用了25分鐘，那么對于算法來說，繼續(xù)使用【配送時(shí)間 = 距離 * 15】這個(gè)算法模型來預(yù)估送餐時(shí)間就已經(jīng)不準(zhǔn)確了，它可能會自動學(xué)習(xí)并調(diào)整為【配送時(shí)間 = 10 + 距離 * 5】，以更好地?cái)M合新的數(shù)據(jù)。 

這樣的話，看下圖可知大于1公里的距離，新算法模型的預(yù)測配送時(shí)間都縮短了。這就是騎手掉入困局的原因。 

但是這是算法的責(zé)任嗎？不是的。假如騎手集體延長配送的時(shí)間，算法也會更改自身的參數(shù)去擬合新的數(shù)據(jù)，這樣新算法模型的預(yù)測配送時(shí)間都會延長（當(dāng)然這在實(shí)際中幾乎不可能發(fā)生）。 

所以說，這并不是算法的責(zé)任，因?yàn)樗焐哪康木褪峭ㄟ^最小化目標(biāo)函數(shù)來擬合歷史數(shù)據(jù)。只是算法的這個(gè)特性非常適合被人利用，然后替利用它的人背鍋。 

四、算法預(yù)估配送時(shí)間采用的因素 

想要準(zhǔn)確地根據(jù)歷史數(shù)據(jù)來預(yù)測配送時(shí)間，就必須考慮到各種影響配送時(shí)間的因素，然后通過計(jì)算機(jī)來學(xué)習(xí)訓(xùn)練出這些因素影響配送時(shí)間的權(quán)重。因此，餓了么在設(shè)計(jì)算法時(shí)，從歷史數(shù)據(jù)中提取出了很多的因素，這些因素分為以下幾類： 

1. 訂單信息：包括訂單的空間因素（用戶、餐廳的坐標(biāo)，城市、配送區(qū)塊的ID等）、訂單的時(shí)間因素（小時(shí)時(shí)刻、是否工作日等）、訂單大?。ú似窋?shù)量和價(jià)格等）； 

2. 聚合因素：包括通過騎手手機(jī)的GPS軌跡等計(jì)算出來的聚合因素； 

3. 菜品因素：比如說拉面、披薩、火鍋等不同菜品的種類等； 

4. 餐廳備餐時(shí)間； 

5. 供需關(guān)系因素：一是騎手的供需關(guān)系（騎手手上的訂單越多，送餐越慢）、二是餐廳的供需關(guān)系（餐廳手上的訂單越多，備餐越慢）； 

6. 騎手因素：包括騎手到餐廳的距離、騎手目前手上未完成訂單數(shù)量、訂單送達(dá)剩余時(shí)間等； 

7. 多維度相似訂單的配送段ETA：配送段預(yù)計(jì)到達(dá)時(shí)間即騎手到達(dá)用戶目的地下車后，把餐食送到用戶手中所用的時(shí)間，比如說包括騎手等電梯的時(shí)間；這部分時(shí)間的預(yù)估采用K近鄰算法找出與之維度相似的若干歷史訂單，計(jì)算加權(quán)平均時(shí)間； 

8. 氣象因素：包括氣溫、空氣質(zhì)量指數(shù)、風(fēng)速、天氣狀況等； 

因此從上面所列的因素看，算法工程師在設(shè)計(jì)算法的時(shí)候，并非沒有考慮天氣狀況、餐廳出餐時(shí)間、騎手等電梯的時(shí)間。基本上影響外賣履約時(shí)間的因素，算法都考慮進(jìn)去了。 

那為什么最后算法給出的預(yù)測時(shí)間，好像是沒有考慮這些因素呢？我們來看看論文中通過歷史數(shù)據(jù)提取這些因素進(jìn)行訓(xùn)練得出的每組因素的重要程度： 

【注：這里每組因素重要程度使用去除掉這組因素導(dǎo)致整個(gè)模型的平均絕對誤差（MAE）上升百分比來比較，如果一組因素去掉后模型的誤差上升越高，說明這組因素對于決定外賣履約時(shí)間越重要】 

由表可知，訂單信息、供需關(guān)系兩組因素是影響外賣履約時(shí)間最重要的因素，而氣象因素、聚合因素、菜品因素是通過歷史數(shù)據(jù)學(xué)習(xí)到的、影響外賣履約時(shí)間最不重要的因素。 

什么意思呢？意思就是說：算法在設(shè)計(jì)的時(shí)候是考慮了氣象、騎手騎行軌跡等因素的，但是騎手通過實(shí)際的歷史訂單數(shù)據(jù)告訴算法，這些因素對于配送時(shí)間并沒有太大的影響。 

但是怎么會沒有影響呢？高溫天氣、暴雨天氣，騎手們的送餐時(shí)間跟平常沒什么區(qū)別，原因是什么呢？就是騎手們?yōu)榱吮苊獬瑫r(shí)，風(fēng)里來雨里去嘛。 

對于這個(gè)問題，難道掌握了海量數(shù)據(jù)的外賣平臺不知道嗎？既然知道，為什么沒有采取措施調(diào)整對應(yīng)的因素權(quán)重，而是變本加厲地利用算法去壓縮時(shí)間呢？ 

五、責(zé)任在誰？ 

現(xiàn)在我們從算法角度來總結(jié)一下：算法的目的是準(zhǔn)確預(yù)估配送時(shí)間，它受歷史數(shù)據(jù)的影響，也考慮了多種因素來預(yù)估配送時(shí)間。所以說，數(shù)字經(jīng)濟(jì)時(shí)代，算法是沒有錯的。 

那么到底是誰造成了騎手們的困局呢？這就得回到這個(gè)循環(huán)，從是誰縮短了騎手的配送時(shí)間說起。在這里，主要的參與者有外賣平臺、騎手和用戶三者，我們明白，三者都是逐利的（這無可厚非）。 

其中外賣平臺是逐利的，因此它會人為地縮短騎手的預(yù)計(jì)配送時(shí)間，利用算法的特性把這個(gè)無限循環(huán)惡化的游戲玩起來； 

騎手也是逐利的，大家都想接更多的單賺更多的錢，所以一開始的時(shí)候就有一部分騎手不遵守交通規(guī)則開始逆行、闖紅燈以縮短配送時(shí)間，這迫使算法預(yù)估配送時(shí)間變短、越來越多的騎手不得不開始逆行、闖紅燈，殊不知就這樣劣幣驅(qū)逐良幣，開始陷入惡性循環(huán)； 

用戶也是逐利的，大家都想要在更短的時(shí)間內(nèi)拿到外賣，于是對外平臺和騎手的配送時(shí)間提出了要求。 

所以說，對于騎手的困局，外賣平臺、部分騎手、用戶三者都是有責(zé)任的（當(dāng)然最大的責(zé)任方在外賣平臺）。而算法只是任人打扮利用、專門背鍋的小姑娘。 

六、如何破解困局？ 

那么如何破解目前的這個(gè)困局呢？有人說騎手團(tuán)結(jié)起來建立一個(gè)工會就能解決，有人說要讓外賣平臺跟騎手簽訂勞動合同，這些從不同領(lǐng)域的角度出發(fā)的方法或許會有效果，可以留給專業(yè)人員去討論，我們不討論。 

然而甚至有人說要加強(qiáng)程序員的培訓(xùn)和價(jià)值導(dǎo)向？試想一群程序員參加完價(jià)值導(dǎo)向培訓(xùn)之后回到辦公室，加班到凌晨2點(diǎn)，第二天9點(diǎn)之前又通過釘釘打卡來上班，領(lǐng)導(dǎo)批評說模型產(chǎn)生的實(shí)際效益還不夠好，再把騎手的預(yù)估時(shí)間縮短幾分鐘吧，不然你們這個(gè)月的績效就別指望了。這多魔幻現(xiàn)實(shí)主義呀。 

那么到底如何破解困局呢？在我看來，這還得看這場游戲中到底誰在獲利誰在虧損。 

外賣平臺通過這個(gè)游戲提高效率，肯定是獲利的；部分騎手一開始是獲利的，但是大家都為了時(shí)間不顧生命危險(xiǎn)拼命趕單時(shí)，便是虧損的；用戶享受到了非常便捷快速的外賣服務(wù)，也是獲利的。 

還有誰呢？還有就是社會大眾。騎手為了省時(shí)逆行闖紅燈，社會大眾徒增了很多道路交通安全上面的危險(xiǎn)，是虧損的。涉及到社會大眾的問題，使用屬于大眾的公權(quán)力來解決是一個(gè)合理的選擇。 

面對外賣平臺，需要有監(jiān)督和懲罰機(jī)制，當(dāng)懲罰也被列入考慮因素的時(shí)候，便能迫使平臺去規(guī)范自身的行為； 

面對騎手，上海推行的電子馬甲騎手扣分制，便是一個(gè)思路：每個(gè)騎手必須穿上印有編號的電子馬甲，一個(gè)季度內(nèi)扣完36分不允許再上路。 

面對用戶，平臺應(yīng)該給予騎手對于用戶給差評的申訴機(jī)制，以及騎手和用戶之間的雙向評分機(jī)制，避免用戶無理要求以及隨意給差評。 

至于算法，不管是不是數(shù)字經(jīng)濟(jì)時(shí)代，關(guān)鍵的都不是算法，而是資本和人。

引用：

[1] 人物.外賣騎手，困在系統(tǒng)里[EB/OL].https://mp.weixin.qq.com/s/Mes1RqIOdp48CMw4pXTwXw,2020-09-08.

[2] Lin Zhu, Wei Yu, Kairong Zhou, Xing Wang, Wenxing Feng, Pengyu Wang, Ning Chen, and Pei Lee. 2020. Order Fulfillment Cycle Time Estimation for On-Demand Food Delivery. In Proceedings of the 26th ACM SIGKDD Conference on Knowledge Discovery and Data Mining USB Stick (KDD ’20), August 23–27, 2020, Virtual Event, USA. ACM, New York, NY, USA, 10 pages. https://doi.org/10.1145/3394486.3403307

本文首發(fā)于微信公眾號“Alfred數(shù)據(jù)室”，轉(zhuǎn)載請聯(lián)系原作者！