前幾天看到 Uber Eats 搶單神器的新聞，當下第一個直覺是十分敬佩，竟然有人想的到這種商業模式 XD
但也讓人好奇，搶單神器的原理是甚麼？為了猜測原理還是得從 Uber Eats 本身的演算法下手，查了一下 Uber Eats 目前的算法(Ref，不過這是2018的資料，有大神查到更新的話也麻煩跟我說)，先簡單介紹 UE 在接到客戶下單後到外送師手上的媒合過程需要考量哪些：
- 媒合時間：太早媒合會讓外送師在餐廳乾等，太晚則會讓餐點涼掉
- GPS的誤差會讓追蹤外送師的路徑不准，所幸可以搭配手機的陀螺儀來猜測外送師現在是在騎乘中、休息中、步行中
- 可以用該餐廳的歷史數據來改善整個流程
總之，藉由 GPS 定位(Location Data)以及陀螺儀的移動數據(Motion Data)，可以把外送師分成四個階段：
- 被分派到工作了
- 已經抵達餐廳
- 出發外送
- 抵達顧客地點，等待接洽
不過首先的問題是：當外送師被定位在餐廳附近時，UE 怎麼區分他是在找停車位還是在等餐廳出餐？
解決方法就是透過陀螺儀提供的 Motion Data 數據來取得外送師的移動速度判別，判別後就可以產生並且記錄每一步 (停車、等出餐、走回車上、出發去顧客地點) 的時間點，加以整理後的數據如下，這些數據後來就可以利用機器學習或統計模型加以訓練與分析。
(restaurant1, driver1, timestamp1, parked)
(restaurant1, driver1, timestamp2, waiting_at_restaurant)
(restaurant1, driver1, timestamp3, walking_to_car)
(restaurant1, driver1, timestamp4, enroute_to_eater)
另外也利用了送餐過程中的兩個特性：
- 必須按照送餐過程的順序，也就是：出發→停車→等餐→取車→出發
- 前後動作相關，如果上一秒還在停車，那這一秒在停車的機會就大
也就是每趟旅途都必定可以畫成像這樣單向的時間軸：
不過這種方式 UE 也承認還是有一些問題：
- 儀器的數據是有雜訊的，特別是 GPS 的數據不連續而且有時候可能會誤差幾個街道
- 這些時間點都是推算出來的，因為餐廳間的差異太大，在大量數據下沒辦法取得每一家公司的 Ground truth
在優化方面，因為整個流程可以看做是單向的圖，因此 UE 是採用(至少 2018 年是 XD) 條件隨機域 (Conditional Random Field，CRF) 來抓取資料中非線性的關係。
不過原文也有說可以利用 Hidden Markov Models 跟 Recurrent Neural Networks.
對所有的送餐紀錄加以分析，就可以得到上圖的數據，並且可以抓出在整個送餐時間中，花在停車、交通、等餐的時間各為多少，接著透過機器學習與統計分析就可以讓外送師盡量在餐點剛好完成時抵達，同時最小化每趟的送餐時間。
不負責任地猜測搶單神器的原理
以下不負責的猜測送餐神器的可能原理 XD
- 透過 GPS 假造定位資訊，讓騎士瞬間出現在已準備好餐點的餐廳旁。
- 透過 Motion Data 讓騎士在找停車位時就讓 UE 誤判現在已經在等餐的階段，把這段拖延時間的鍋甩給餐廳。不過這有個前提是 UE 會差異化每位外送師外送師提前抵達、
- 假造 GPS 定位資訊，讓外送師提前抵達、完成，可以提早開始接下一擔。
實際如何可能只有寫出送餐神器的工程師知道了。
工商服務
這是我開的粉專，覺得有趣或有幫助的話可以幫我點個讚嗎 Q_Q
Ref：
How Trip Inferences and Machine Learning Optimize Delivery Times on Uber Eats
