AI Engineer 面試日練 — 2026-09-30：ML System Design

🌏 English version

今日主題

星期三輪到 ML System Design，但今天不重複「六階段框架設計一個推薦系統」這種已經練過的完整走法，改聚焦在候選人最容易跳過、面試官卻最愛深挖的後半段——監控。多數人準備 ML System Design 時把心力都花在資料管線跟模型架構,但 2026 年的面試越來越常在「上線之後」才開始真正刁難：你怎麼知道模型壞了、壞在哪一層、壞了之後要不要自動修。今天選的練習題是 TikTok 的真實面試題「設計一套模型監控系統」,因為這題幾乎把 ML System Design 面試裡最容易被略過的細節（飄移偵測、分層監控、警報後的決策）全部收在同一題裡。

核心概念速記

資料飄移 vs 概念飄移：兩種完全不同的「壞掉」

資料飄移（data drift）是輸入特徵的分布變了，但特徵跟標籤之間的關係沒變——比如某款新手機上市後，裝置指紋特徵的分布整個位移，但「這個裝置指紋代表什麼樣的使用者」這件事本身沒變。概念飄移（concept drift）更麻煩，是輸入跟輸出之間的關係本身變了——同樣一組使用者行為特徵，在疫情前後代表的購買意圖完全不同。面試時最簡單的講法是：資料飄移是輸入變了但答案的邏輯沒變，概念飄移是連答案的邏輯本身都變了。這個分別很重要，因為資料飄移有時候靠重新校正特徵分布就能撐過去，概念飄移幾乎一定要重新訓練，因為模型學到的映射關係已經是錯的。

多層次監控：不要等業務指標掉了才發現

一套完整的監控系統要疊四層，缺一層就會有盲區。第一層是輸入特徵分布，拿即時分布跟訓練時的基準分布比對（常用 population stability index 或 KL divergence），這一層最快，但只能抓到「輸入變了」，抓不到模型判斷邏輯壞掉。第二層是模型輸出分布，追蹤預測分數或信心值的分布有沒有系統性位移，這層能提早發現模型「變得不確定」。第三層是效能指標本身，像準確率、precision、recall，但這層天生有延遲，因為真實標籤（ground truth）往往要等使用者行為發生後才拿得到。第四層是業務指標，像 CTR、營收、客訴量，這層最終但也最慢，等業務指標掉下來，代表前三層的警報早就該響了。面試官在意的是你知道這四層各自的延遲跟盲區,而不是背出「要做監控」這四個字。

A/B 測試的三個陷阱

設計 ML 系統的 A/B 測試框架，光講「切流量、比指標」不夠，面試官想聽的是你知道哪裡會出錯。第一個陷阱是流量分配不均，如果實驗組跟對照組的使用者輪廓本身就有差異（例如新使用者比例不對稱），結果會被這個差異汙染而不是模型差異。第二個是外部因素干擾，像行銷活動、季節性、甚至競品的同期活動，都可能讓兩組的差異看起來像模型效果，其實不是。第三個是統計顯著性方法選錯，常見的錯誤包括結果還沒跑滿就提前偷看（peeking）、樣本比例不匹配（sample ratio mismatch）沒被檢查出來就直接信了p-value。這三個陷阱背後有同一個共通原則：漂亮的整體數字如果沒拆開看逐日趨勢跟樣本組成，很可能是雜訊或新鮮感效應（novelty effect），不是真正的模型改善。

警報之後怎麼辦：自動重訓的回饋迴圈風險

這是監控系統設計裡最常被漏掉、面試官卻最想聽到的一段：警報響了之後呢？直接自動重訓聽起來很吸引人，但藏著一個危險的回饋迴圈——如果模型的錯誤預測會反過來影響它未來收到的訓練資料，自動重訓可能會讓系統越訓越偏。舉例來說，詐欺偵測模型攔下一筆交易之後，這筆交易的真實結果（到底是不是詐欺）可能永遠拿不到標籤，於是模型只能從「它放行的交易」裡學習，逐漸對自己攔下的那類模式失去校正能力；推薦系統如果只根據「使用者點了什麼」重訓，也會讓系統越推越窄，因為使用者根本沒機會看到訓練分布之外的內容。穩妥的做法是把警報分兩級：小幅度飄移先觸發人工複核，只有明確且可解釋的飄移（例如已知的上游 schema 變更）才允許自動重訓，且重訓後一定要先過 shadow traffic 驗證再全量上線。

2026 年新增的一層：GenAI 系統把「評估」變成新的系統設計

如果今天的監控題換成 LLM 或 agent 系統，多一組完全不同的指標要顧：faithfulness／hallucination rate（RAG 生成內容有沒有紮根在檢索到的來源）、每次查詢的成本與延遲分布、guardrail 觸發率。2026 年的 ML System Design 面試圈子裡流傳一句話：「評估方法論就是新的系統設計」，意思是面試官現在更在意你怎麼量化一個沒有單一正確答案的生成系統，而不是你畫出的架構圖多漂亮。傳統 ML 監控抓的是分布飄移，LLM 監控除了飄移之外，還要多顧「這次生成有沒有亂講」跟「這次呼叫花了多少錢」,這兩件事在傳統分類或回歸模型的監控框架裡根本不存在。

今日練習題

題目

設計一套模型監控系統，涵蓋飄移偵測、效能追蹤，以及離群值處理。

來源：TikTok（收錄於 Aced／原 Exponent 的 2026 ML System Design 面試指南）　難度：進階　環節：onsite system design 深挖

拆解思路

1. 先釐清問題：先問清楚監控對象是哪個模型（推薦排序？內容安全分類器？兩者的監控需求差很多）、目前已經有哪些 log（特徵值、預測分數、使用者互動）、上線頻率跟允許的重訓 cadence。同時確認規模——TikTok 這個等級的流量代表每天要處理數十億次預測，不可能對全部流量做即時分布比對，要先講清楚會用取樣而不是全量計算。
2. 建立框架：用「特徵分布 → 預測分布 → 延遲效能指標 → 業務指標」四層監控管線，每層配對應的偵測方法（PSI／KL divergence 抓分布位移、confidence score 追蹤抓模型不確定性上升、延遲標籤到位後算 precision/recall、業務儀表板抓最終影響）。
3. 深入核心：真正的取捨在警報閾值怎麼調——閾值太敏感會製造警報疲勞，工程師開始無視警報；閾值太寬鬆會漏掉真正的飄移。再深入到警報之後的決策樹：小幅飄移先人工複核，明確且可解釋的飄移才允許自動重訓，重訓後一定先跑 shadow traffic 比對再全量替換，避免回饋迴圈把模型越訓越偏。
4. 收尾：總結四層監控加上兩級警報決策，並主動提出如果有更多時間會補上：針對不同內容類型（例如敏感內容分類器 vs 一般推薦排序）分開設定飄移閾值，因為兩者對誤報跟漏報的容忍度完全不同。

範例回答（面試時可以這樣講）

我會把監控拆成兩個維度：偵測什麼、以及偵測到之後做什麼，因為多數候選人只答前半段。偵測層面，我會建四層管線——用 population stability index 追蹤輸入特徵分布相對訓練基準的位移，同時追蹤模型輸出分數的分布，因為輸出分布往往比輸入分布更早反映出模型開始「不確定」；再加上延遲標籤到位後計算的 precision/recall，跟最終的業務指標像互動率或申訴量。考慮到 TikTok 這個規模每天有數十億次預測，我不會對全量做即時比對，會用分層取樣，並針對高風險內容類型（像涉及安全的分類器）拉高取樣率。

警報之後是我認為最容易被漏掉、但面試官最想聽的部分。我不會讓系統偵測到飄移就自動重訓，因為這會有回饋迴圈風險——如果模型的錯誤預測影響了它未來收到的訓練資料，自動重訓可能會讓系統越訓越偏。我會分兩級：小幅飄移先觸發人工複核跟根因排查；只有明確可解釋的飄移（比如已知的上游 schema 變更）才允許自動重訓，而且重訓後的模型一定要先過 shadow traffic 比對，確認沒有引入新的問題才全量替換。這個設計比「偵測到就自動重訓」更貼近生產環境會踩的坑。

自我核對清單

用這張表檢查你的回答有沒有漏掉關鍵點：

延伸閱讀

• Machine Learning System Design Interview (2026 Guide) - Aced（原 Exponent） — 六階段框架、監控與飄移在 2026 年被獨立列為考點，附完整真實題庫（含 TikTok 這題）
• ML System Design interview questions I wish I knew before my interviews — 逐一拆解 A/B 測試陷阱與飄移偵測後的決策問題，是今天練習題拆解思路的主要參考
• AIMLInterviews：GenAI/LLM System Design (2026) — 補充 LLM 系統監控（faithfulness、cost、guardrail）跟傳統 ML 監控的差異

參考資料

• Machine Learning System Design Interview (2026 Guide) — 六階段框架、監控段落、真實題庫「Design a monitoring system for TikTok」出處
• ML System Design interview questions I wish I knew before my interviews — 資料飄移／概念飄移定義、A/B 測試三陷阱、監控後決策樹的討論來源
• AIMLInterviews - ml-system-design.md — GenAI/LLM System Design 段落，「評估方法論是新的系統設計」一句的出處