案例拆解:台灣物流商把 AI 排程從 PoC 推上生產線,揀貨與準點率的真實數字

四個月前,這家中部起家的第三方物流商找上我們時,手上握著一份漂亮的 PoC 報告:AI 排程引擎在歷史資料上跑出「揀貨路徑縮短 23%、模擬準點率 96%」。董事會很滿意,錢也批了。問題是,那份數字停在簡報裡整整八個月,倉庫現場一次都沒真正用過。

這不是新鮮事。我們接手的物流 AI 導入案例裡,超過一半都卡在同一道牆:模型會算,但沒人敢照它的結果出貨。

為什麼一個「跑得動」的模型會在生產線前面死掉

先把後來的真實數字放在前面,因為這才是這篇要講的重點。上線滿三個月後,這套 AI 排程在真實訂單上的表現是這樣的:

注意 PoC 值和實測值的落差。揀貨距離從承諾的 -23% 掉到 -16%,準點率也沒摸到 96%。這正是誠實的地方:PoC 用的是乾淨的歷史資料,沒有臨時退單、沒有堆高機故障、沒有某條動線因為盤點被封三小時。生產環境會把模型的漂亮數字磨掉一截。我們的工作不是去護住那個 96%,而是讓一個實際能用的 94% 真的天天在跑。

三道採用障礙,一道一道扛過去

第一道:排程組長不信任黑箱。 這位做了十一年的組長,第一週直接把 AI 的建議單擱在旁邊,照自己的方法排。我們沒有去說服他「模型比較準」——那沒用。我們的工程師搬了張椅子坐到他旁邊三天,把每一張 AI 排程單旁邊加上「為什麼這樣排」的理由欄:因為 A 區今天有兩張大單、因為這名揀貨員動線熟。組長開始逐張比對,到第二週,他自己回報「這張我會改,因為系統不知道 3 號揀貨員今天請假」。這句話很關鍵——他從對抗變成了校正者。我們立刻把「當日人力異動」做成一個他能手動輸入的欄位。信任不是靠準確率堆出來的,是靠讓人看得懂、改得動。

第二道:資料現實比 PoC 髒得多。 上線第一週,系統有 15% 的訂單排不出來,因為 WMS 裡的商品體積欄位有大量空值和明顯錯誤(有件貨標成 0.001 立方米)。PoC 階段這些髒資料被前處理腳本默默過濾掉了,生產環境不能過濾,得面對。我們花了近兩週做的不是調模型,是補一層資料清洗與異常攔截,把排不出來的訂單自動降級成「人工覆核」而不是直接卡死。這段沒有任何演算法的浪漫,但它是上線能不能站住的關鍵。

第三道:尖峰日的臨時改單。 客戶最痛的場景是下午三點電商大單湧入,原本排好的動線全部要重來。PoC 完全沒碰這塊。我們補上一個增量重排機制:不是整批重算,而是只針對受影響的區域局部調整,把重排時間從人工的四十分鐘壓到系統的九十秒。這是上線後第二個月才補的,因為前一個月我們刻意不碰它——先讓基本盤穩,再處理最尖的痛點。

我們踩過、也承認的取捨

有兩件事我們沒做漂亮。一是前六週我們高估了 WMS 資料的可用度,導致上線時程延了十天;早知道該先做一週的資料健檢再談排程。二是那 9% 沒採用系統的訂單,是冷鏈與危險品類,規則太特殊,我們評估後決定「這批就留給人工」,沒有硬把它塞進模型——因為為了 9% 去複雜化整套系統,很可能拖垮已經穩定的 91%。取捨就是取捨。

從 PoC 到生產線,真正難的從來不是那條演算法。是資料的髒、是人的不信任、是尖峰那一小時的兵荒馬亂。這些東西不會出現在 Demo 裡,只會出現在你把工程師派進倉庫、坐在組長旁邊之後。我們在 Tenten 一直是這樣做的:FDE 進場,把模型從簡報裡拉出來,一道障礙一道障礙扛,直到現場的人願意每天打開它——那一刻,這個案子才算真的上線。