「這個 AI 最近好像判斷都怪怪的。」
這句話，幾乎每一個做過 AI 上線的人，都有機會在某個時候聽到這個回饋。
有一個案子，模型上線的時候表現很不錯，整體準確率達到我們設定的門檻，BU 也很滿意，大家開了個慶功宴，把它算做是一個成功案例。
接著，大家就繼續忙下一個專案了。
幾個月後，BU 的主管傳了一封訊息過來：「你們的 AI 最近判斷的怎麼有點不對勁？有幾筆我覺得明顯應該是 A，它判成 B 了。」
我們重新拿出 Golden Dataset 跑了一遍，發現整體準確率從上線時的 90%，悄悄滑落到了 81%。沒有任何人知道它是什麼時候開始退步的，也不知道退步的原因，是資料分佈變了？是業務情境更新了？還是模型供應商悄悄推了版本？
這九個百分點的差距，在我們毫無所知的情況下，可能已經累積了幾個月。
為什麼模型會退步？
傳統程式上線之後，除非有 bug 或需求異動，系統基本上不會自己表現變差或是壞掉。這個直覺很深根，我們習慣把「上線」當成一個終點。
但 AI 模型不是這樣。它是一個活在特定時間切片的學習系統，當它學習的那個時代過去之後，世界繼續往前走，它的判斷卻停在原地。
具體來說，讓模型退步的原因通常有三類：
資料漂移（Data Drift）。 業務的實際輸入分佈，隨著時間偏離了當初建模時的訓練資料。例如，新的銷售通路帶來了新型態的表單填寫習慣，輸入的文字風格和當初標注的樣本有了明顯差異。模型沒有學過這些新的輸入模式，碰到它們就開始犯錯。
業務情境更新。 公司推出了新產品、法規更新了分類標準、某個以前常見的輸入類型消失了、一個以前罕見的類別突然變成了主流等，這些都會讓模型原本學到的判斷邏輯和現實脫節。
模型本身的版本迭代。 雲端模型供應商（OpenAI、Anthropic 等）會定期更新底層模型。有時候新版本整體效能更好，但在你的特定任務上，某些邊緣行為可能改變了。如果你沒有監控機制，這種靜默的版本升級可能在你不知情的狀況下影響了線上表現。
這三類原因有一個共同特點：它們都是漸進式發生的，沒有明確的「出錯時刻」，不像傳統程式的 bug 會噴出 error log。AI 模型的退步，是一個慢慢滑落的過程，等到人工察覺，問題通常已經累積了很久。
沒有監控，你不知道退步什麼時候發生
這是大多數 AI 專案在上線後最大的空白：根本不知道模型是否還在正常運作。
在傳統維運框架裡，大家習慣監控的是系統層面的指標，API 回應時間、錯誤率、服務可用率。這些指標如果正常，大家就認為系統沒問題。但對 AI 模型來說，這些完全測不到真正重要的東西。API 的呼叫成功，不代表模型的判斷品質維持在上線時的水準。
要真正監控模型表現，需要的是品質層面的指標，而不只是系統層面的指標。
最基本的做法，是建立定期批次評估機制。定期（例如每週或每兩週）從線上的實際輸入中，抽取一定比例的案例，與 Golden Dataset 的測試集一起跑批次評估，得到一個量化的準確率快照。把這個數字和上線時的基準做比較，就能看出模型是否在退步、退步的幅度多大。
批次評估的頻率應該和業務量與業務變化速度掛鉤。如果業務量大、情境變化快（例如因應新法規或新產品線的調整），建議提高評估頻率。如果業務相對穩定，每月一次也可以是合理的起點。
Feedback Loop 的設計：讓人工複核的結果有地方去
監控只是第一步，讓整個系統持續改善，需要的是一個完整的 Feedback Loop。
