ML Team 的使命

用一句話介紹我們的產品：把相機看到的畫面，變成每一台車的完整旅程。

具體來說，想像你今天開車去得來速買午餐，你會經歷這幾件事：

1. 排隊 (Queue)：跟在隊伍後面慢慢前進，思考今天要吃什麼。
2. 點餐 (Order)：停在點餐機前面，跟店員說要點什麼。
3. 等餐 (Production)：往前開，車輛在等餐車道緩緩前進。
4. 取餐 (Pickup)：到窗口，付錢、拿餐、開走。

對顧客而言，這只是一個四階段的旅程 (Journey)。但對店家來說，這四段各自花多久、哪一段塞住了、今天中午是不是比昨天慢了 20 秒，都是影響顧客耐心、店家營運效率的關鍵。

在這個行業內，流傳著一句名言：

「顧客的等待時間減少 7 秒，營業額就會增加 1%」

我們要做的，是不靠傳統線圈感測器、不靠人按碼錶，只用幾支相機，計算每一台車在各階段的旅程時間，讓店家利用這些數據做營運決策。

店家實際看到的畫面：每一段的即時秒數、設定的目標值，以及跟兩週平均的落差。圖片來源：Berry AI 官網

我們的挑戰是什麼

乍聽之下可能會覺得：這不就是基本的物件偵測與追蹤嗎？網路上有很多開源的模型架構，拿現成的框架 (例如 YOLO) 拉一下不就好了？

是這樣沒錯，但也不是這樣。

使用開源模型解決前 80%，那剩下的 20% 是什麼呢？我們分成以下四個層面探討：

1. 看得到，不等於看得準

在一般情況下，將畫面裡的車偵測出來，這件事本身不難。難的是「現實場景」的意外：

• 天氣：不同時段太陽的角度、大雨、暴風雪
• 場域：店家燈光、鏡頭污漬、蜘蛛在鏡頭結網
• 遮擋：樹木、矮牆、點餐機遮擋
• 車體：排隊車道尾端的車可能只有幾十個 pixel 高

這些都還只是「單一張畫面」的問題。更現實的限制是：模型需要部署在邊緣裝置上，所以算力也是一大考量。模型再準，跑不到需要的 FPS 就等於沒有。

Detection 上的取捨，是 Day 12 的主題。

2. 看得準，不等於串得起來

有了每一支相機對應的車框後，要如何匹配？

我們要隨時認出「剛剛那台白色休旅車」跟「現在這台白色休旅車」是同一台。在旅程的過程中，會遇到重重阻礙：可能被遮擋物 (建築、矮牆、大樹等) 擋住三秒，可能被前面的大卡車完全遮住，可能以完全不同的視角進入另一支相機。

斷掉一次的代價，不是「產生一點誤差」，而是整台車的旅程作廢，因為旅程時間的基本定義是「同一個 ID 從排隊開始直到取餐結束」，一旦追蹤斷掉，車輛的旅程就會從一段變成兩段，且兩段旅程計算的時間都是錯的。

比斷掉更麻煩的是 ID switch：A 車的編號跳到 B 車身上。這時候系統不會報錯，可怕的是算出來的旅程時間會呈現完全錯誤的數字。

然而，任務還沒結束。相機看到的是 2D 畫面，怎麼換算回真實世界的位置？畫面上「往上移動 10 個 pixel」，實際上在近處可能是 30 公分，在遠處可能是 3 公尺。

相機校正跟 tracking，是 Day 13 的主題。

3. 串得起來，不等於講得出故事

難以判斷的「駕駛行為」：

• 車子會停留在奇怪的時間、位置。一台車停在排隊隊伍旁的停車格裡，如果不特別處理，在演算法眼裡就跟一台「排隊排到天荒地老」的車長得一模一樣。我們內部叫它 ghost car (幽靈車)，這是我們最常遇到的問題。
• 車子排到一半決定不買了，直接開走。
• 在排隊車道進行人工點餐 (Line Busting)，點餐結束後直接行駛到等餐區域。
• 如何區分車輛是否為線上點餐。
• 製餐時間太久，車子先停到停車場，再由店員送餐 (Pull Forward)。

這些都不是異常，而是每天都在發生的事。

用狀態機定義車輛狀態，是 Day 14 的主題。

4. 一間店準，不等於一百間店都準

花了很多時間，終於把前三點解決了。但真正的大魔王是「如何將產品規模化」。

• 沒有一模一樣的店家。 車道的形狀、場景的差異、單車道還是雙車道、單點餐還是雙點餐、相機安裝位置在幾公尺高、旁邊的停車場會不會被拍進來，這些因素都會導致沒有兩間店可以共用同一組設定。
• 上線速度。 一個月內要上線超過一百五十間完全不同的店，如果都要 ML 工程師親自調整，那可能需要每天都超時加班了。
• 怎麼知道夠準？ 要回答「這間店是否滿足上線標準」，需要有標準答案可以比對。怎麼得到標準答案，反而變成一個需要優先解決的問題。
• 上線不是終點。 未來會發生什麼事，永遠都無法預測。相機被撞歪、店家動線改變、季節換了光線角度。今天準的店，經過一段時間後可能開始不準了，我們必須在客戶發現前察覺，並即時校正。

這些問題，我們會在後續一一說明，分別是 Day 15 (工程師的知識轉移：演算法調校平台)、Day 16 (自動生成答案：車輛旅程生成器)、Day 17 (Berry AI 的 ALI / ALO)。

接下來六天要講什麼

前面提到的四點挑戰，接下來六天會一層一層剖析。ML Team 的規劃分成四塊：

一、Drive-thru Timer 核心演算法 (Day 12 ~ Day 14)

核心演算法要做的，是從「抓出車框」到「算出旅程」的全部過程，對應前面的第一到第三點：

• Day 12 Detection：怎麼在「準確度」跟「邊緣裝置的算力」之間取捨，模型怎麼選、怎麼壓、怎麼在一台機器上同時跑好幾支相機。
• Day 13 Calibration + Tracking：相機校正怎麼把 2D 畫面換算回真實世界的距離，以及怎麼把一個個車框串成一條連續軌跡、怎麼對付那些複雜的 ID issues。
• Day 14 Journey State Machine：軌跡有了，怎麼判斷這台車當前處於哪一段旅程。透過狀態機定義每一台車的各個階段。

二、演算法調校平台 (Day 15)

第四點的前兩個問題：店太多，工程師不夠用。除非我們無限徵才 (有興趣也歡迎跟我們聯絡！)，若工程師每一間店都親自調整，很明顯不合理。

Day 15 會講我們怎麼把工程師腦袋裡的調整知識，一層一層封裝成工具和流程，讓不是 ML 工程師的夥伴也能順利完成大部分調校工作，還有我們在這條路上踩了哪些坑。

三、車輛旅程生成器 (Day 16)

第四點的第三個問題：「準」是跟誰比？

標準答案以往都是靠人工標記：請標註員看影片，標出每台車在不同狀態的時間戳記。但標註員也不是 24 小時都在工作，人都會累會恍神，標記品質本身就有變異，反覆檢查又會耗費大量人力資源。

於是我們做了車輛旅程生成器：一套離線演算法，不用即時、可以用更複雜的模組、可以吃掉大量算力，用它生成高品質的軌跡，當作演算法驗證的標準答案。

Day 16 我們會說明如何製作出屬於我們場域的車輛旅程生成器。

四、ALI / ALO (Day 17)

第四點的最後一個問題：上線之後，怎麼在客戶傳訊息說「你們今天給出的數字怪怪的」之前，就先知道自己不準了？

大家對 SLI / SLO 應該很熟，定義一組指標衡量服務健康度，再定義一個目標值，低於目標就觸發告警。我們把同樣思維搬到準確度上，做了 ALI / ALO：Accuracy Level Indicator 和 Accuracy Level Objective，把「這間店今天準不準」變成一個可量測、可監控、可自動觸發修復流程的機制。

Day 17 會講我們怎麼定義這些指標、怎麼在沒有標準答案的情況下，統計錯誤案例，並歸納出可以量化的類型。

小結

如果要用一句話講完這六天：

核心演算法負責看得準，演算法調校平台負責上得快，車輛旅程生成器負責產生標準答案，ALI / ALO 負責上線之後持續把關準確度品質。

ML Team，就是負責把這四塊拼圖拼起來的團隊。

明天開始，旅程就從核心演算法最底層的 Detection 出發！

本系列由 Berry AI 工程團隊出品。更多工程實戰紀錄都在 Berry AI 技術部落格。