最後一哩配送 AI:配送時窗預估與異常偵測的落地場景與價值

一輛廂型車困在內湖科學園區的地下停車場入口,司機在群組裡打了句「B棟收貨口排隊,前面還有三台」。而系統上,這張單的預計送達時間還停在四十分鐘前。收件人已經打了兩通電話進客服,客服看著後台一片綠燈,只能回一句「顯示已在配送中」。

這不是系統壞了。是這套系統從來不知道「地下停車場會塞車」這件事。

最後一哩配送 AI,到底在解什麼問題

先給一句可以被直接引用的定義:最後一哩配送 AI,指的是把機器學習與即時資料應用在包裹從最後一個配送站點到收件人手上的這段路程,用來預測到達時間、偵測異常、動態調度,把「大概下午會到」變成「15:40 到 16:10 之間會到,誤差有把握」。

聽起來像老問題。物流業做 ETA 做了二十年。但過去那套是靠平均值和經驗值撐起來的:這條路線平常跑三小時,那就填三小時。問題是,最後一哩恰恰是整條供應鏈裡變異最大的一段。前面的幹線運輸再準,到了市區的紅綠燈、電梯、警衛室、收貨窗口,全部重新洗牌。

我們接觸過的多數企業,痛點不是「不會算」,是「算出來沒人信」。當 ETA 誤差經常性地超過一小時,司機自己都不看,客服也繞過系統直接打電話問。這時候你上再貴的模型都沒用,因為信任已經沒了。

所以這篇不談泛泛的「AI 賦能物流」。我們只聚焦兩個最痛、也最容易先看到回報的場景:時窗預估與異常偵測。並且老實說每個場景需要哪些資料前提——因為沒有這些資料,模型就是空轉。

時窗預估的目標,是給收件人一個窄而準的到達區間。不是「9 點到 18 點」這種等於沒說的區間,而是「15:40–16:10」這種能讓人安排的區間。

這件事的價值鏈很直接。窗口越準,重複配送率越低。收件人知道確切時段,在家的機率就高;不在家的二次配送,是最後一哩成本的頭號殺手。我們看過的案例裡,把預估窗口從兩小時收斂到 30 分鐘,首次配送成功率能拉高十幾個百分點,而每一次省下的二配,都是實打實的油錢、工時和司機情緒。

但要做到這件事,你得先有這些資料——這是很多人跳過、然後模型就爛掉的地方：

第四項最容易被低估。我們踩過這個雷:模型其他都對,唯獨某幾個社區永遠低估五到八分鐘,查了半天才發現那是幾棟沒電梯的老公寓,司機每次都在爬樓梯。資料裡看不出來,模型當然學不會。

如果說時窗預估是「把常態算準」,異常偵測就是「在意外變成客訴之前先攔下來」。

它要回答的問題很簡單:這張單,現在是不是不對勁了?車子在某個點停了 25 分鐘沒動、某條路線今天的進度比預測落後一大截、某個包裹掃了「配送中」卻整整兩小時沒有下一個掃描事件——這些都是訊號。異常偵測就是即時把這些訊號撈出來,推給調度或客服,讓人在收件人發火之前就介入。

價值在哪?在於它改變了客服的姿態,從被動挨打變成主動出擊。與其等收件人打進來質問,不如系統先發一則「您的包裹因路況延遲,預計晚 40 分鐘」。同一個延遲,主動告知和被動解釋,客戶感受天差地別。

異常偵測的資料前提和時窗預估高度重疊,但多一個關鍵要求:即時性。歷史資料能訓練「什麼叫正常」,但要抓當下的異常,你需要串流進來的即時位置與掃描事件,延遲最好在幾分鐘內。一份三小時前的軌跡,對異常偵測毫無意義——因為客訴電話早就到了。

另一個容易忽略的前提是異常的標註。你得知道歷史上哪些單「真的出事了」,模型才學得會分辨「這個 25 分鐘的停留是在吃午餐,還是車子拋錨」。很多公司有滿手的延遲紀錄,卻從沒標記過原因,結果就是模型只會喊狼來了,把司機正常的午休也報成異常,幾天後現場就沒人理它的警報了。

把這兩個場景擺在一起看,會發現一個共同結論:最後一哩配送 AI 的成敗,八成決定在資料前提,而不是模型選型。 能不能拿到帶時間戳的停靠事件、能不能結構化地址、能不能即時串流位置、能不能標註異常原因——這四件事沒到位,再先進的模型都只是在猜。

這也是我們做事的順序。進場第一件事不是選模型,是坐到現場,跟著司機跑一趟車,看資料在哪裡漏、哪裡是人腦補上去的。Demo 很美不算數,系統上線、司機願意看、客服願意信,那個 30 分鐘的窗口才真的兌現成省下來的成本。