上千間門市、每天數十萬台車的旅程，現在請回答一個問題：今天有幾台是算錯的？這個問題聽起來應該要有答案，畢竟我們是一家靠提供準確資料吃飯的公司，但在很長一段時間裡，我們的答案是「不知道」，因為我們沒有時間每天都去確認數十萬台車的錄影。

先講結論：我們把 SRE 那套 SLI / SLO 的想法，搬到了演算法準確度上面，現在每家店每天都會自動拿到一張成績單，不及格的會自己舉手。

上線前有答案，上線後沒有

前面幾天講完了整條產線：偵測、單相機與跨相機追蹤、旅程狀態機，一台車的影像最後變成一串結構化的事件。上線之前，這些事件準不準是有答案的。我們有標註好的資料，一條軌跡一條軌跡去比對，每間店上線前的調校靠的就是這套客觀指標。

上線之後，答案消失了。不可能派人去看上千間店每天的每一段錄影，客戶的判斷又時常是主觀的，也很難準確說出事件內容與發生時間。

過去的流程是：客戶反映 → 工程師找原因 → 調整 → 回報，它能運作，但觸發條件是「客戶已經不爽了」，當門市數量往上增加，不僅流程上不夠及時，也沒有足夠多的人力去應對。

借一個現成的概念

這個問題有個完全不相關的領域早就解掉了：SRE。它面對的是「服務有沒有在正常運作」，而 Google SRE 那本書的解法是：用 SLI (Service Level Indicator) 決定拿什麼數字代表服務是好的，用 SLO (Service Level Objective) 決定那個數字要到多少才算及格，它把主觀感受變成了可以被監控、被告警、被自動化的數字。

於是有了很直接的類比：ALI (Accuracy Level Indicator) 與 ALO (Accuracy Level Objective)，不及格的店自動進入後續處理，不用等客戶通知我們。但實作起來有幾個難點。

難點一：沒有標準答案，怎麼知道哪裡錯了

在討論錯誤有哪些型態之前，得先回答一個更根本的問題：要怎麼知道某一台車算錯了？上線前有標註資料可以比對，上線後沒有，所以我們能用的，只有資料本身的內部矛盾。意思是：我們在監控的不全然是「這台車對不對」，更像是「這台車合不合理」。一台車在旅程中途消失了、一台車從來沒出現在起點就突然出現在終點、一台車在某個區域停留了三十分鐘 — 這些都不需要標準答案就能判定不合理。物理世界有它的規則，而違反規則的資料，高機率是錯的。

難點二：窮舉所有的錯誤，並進行分類

SLI 好定義，是因為服務的錯誤很單純：HTTP 500、逾時、連線失敗，都是二元的，而且不需要看上下文就能判定。演算法的錯誤不是，它是連續的、有型態的，而且同一個模式會依據當時的情境被定義為對或錯。這些錯誤大致分兩類。斷掉的軌跡 (broken track) 是一台車開到一半被跟丟、隨後又重新抓到，同一台車被當成兩台；幽靈車 (ghost car) 是系統以為有車，但那不是車、或那台車早就走了。

但麻煩的是，最該被列出來的那幾種，剛好是最容易被漏掉的。有些錯誤很直觀，結果就是多算或少算一台，一眼就看得出來；有些錯誤卻會產出一段看起來完全合理的旅程，然後悄悄汙染統計。例如一台車在排隊的前半段或取餐的後半段被跟丟，殘留的那段軌跡依然走完了完整的狀態旅程，所以它不會出現在任何錯誤計數裡，但它就是錯的。它偽裝成了正確的資料。窮舉的難處就在這裡：漏掉的永遠是沒想到的那些，而那些通常最危險。

所以第一件工作非常燒腦：把所有錯誤模式條列出來，接著再做錯誤類型的歸類，最後為這幾大類錯誤設計對應的指標來追蹤。

做完之後

服務上線後，每家店的旅程紀錄自動跑過指標計算產出 ALI，對照事先訂好的 ALO，不及格的自動進入處理流程，處理完重新驗證。指標都上了 Grafana，一個看板就能看到所有門市的分布。

這整套機制的價值，除了能在更早的時間點觸發警告與優化，也讓跟客戶對齊準確度議題時，對話更有數據依據，以前無論對客戶或內部的非工程團隊，討論準確度的起點常常是「incident 的描述與數量」或「客戶覺得這家店怪怪的」，最大的問題是沒有量化數據當依據，討論很容易被主觀感受牽著走。

小結

我認為 ALI / ALO 最難的部分不是寫 code，而是定義「什麼叫做不合理」以及「哪些樣本需要處理」。哪種程度的錯誤是客戶會在意的，這是產品問題，門檻沒辦法由工程單方面決定。回頭看，這套機制真正的價值，也不在指標算得多精準，而在於我們終於把「準確度」從一種感受，變成了一個可以被討論、被追蹤、被改善的問題。

參考資料

• Google SRE Book

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