「設計一個 ML 訓練 + 服務 pipeline」是 MLOps 味道最濃的系統設計題。它不考你會不會調模型，而考你能不能把「資料 → 特徵 → 訓練 → 部署 → 監控」串成一條可重現、可版本化、能安全上線又能回滾的生產線。新手常只畫一個「訓練→部署」箭頭就沒了；資深的分水嶺，在於能講清楚 feature store 的一致性、模型版本治理、漸進式部署這三塊。
這篇用端到端 pipeline 貫穿，重點放在你今天指定的兩個核心——feature store 與模型版本——並補齊訓練流水線、部署策略與監控，每段附面試官追問。
⏱️ 設計主軸：整條 pipeline 要回答一個問題——「任何一次線上預測，我能不能完整重現它用了哪個模型、哪些特徵、哪份資料？」答得出來，這題就穩了。
Step 1 — 釐清需求
- 任務型態：批次預測（離線打分，如每日推薦）還是即時線上推論（< 100ms）？兩者的服務架構天差地別。
- 規模 / 頻率：多少特徵、多少模型、多久重訓一次（每天？每小時？觸發式？）。
- 約束：延遲、可重現性、合規（資料血緣、可審計）、團隊協作（多人改特徵/模型）。
🎤 面試官追問：「你的系統是離線批次還是線上即時？」（這決定了要不要 online feature store、要不要低延遲模型服務。）「重訓頻率由什麼觸發？」（排程 / 資料量 / 指標衰退。）
Step 2 — 端到端架構鳥瞰
┌─────────────────── Feature Store ───────────────────┐
│ 離線(Offline store) 線上(Online store) │
│ 訓練取特徵、回填 低延遲讀取(Redis 類) │
└─────────▲───────────────────────────▲───────────────┘
│ 同一套特徵定義 │
原始資料 ──► 特徵工程 ──► 訓練 Pipeline ──► Model Registry ──► 服務
(logs/DB) (batch/stream) (可重現) (版本+metadata) (線上/批次)
│
監控(資料漂移/指標/延遲) ◄── 預測日誌 ◄──┘
兩條主線:離線(訓練) 與 線上(服務),它們在 feature store 交會。下面逐塊拆。
Step 3 — Feature Store（這題的核心之一）⭐
Feature store 的存在就是為了解一個老問題:訓練和服務用的特徵不一致(training-serving skew)。它的設計重點:
- 雙儲存,單定義:
- 離線 store(如數倉/Parquet):存歷史特徵,給訓練與批次打分用,容量大、可回溯。
- 線上 store(如 Redis/低延遲 KV):存最新特徵值,給即時推論用,毫秒級讀取。
- 關鍵:兩者由同一份特徵定義/轉換邏輯產生,避免「離線 Spark 算一套、線上 Java 又算一套」的偏差。
- Point-in-time 正確性:組訓練樣本時,特徵值必須取「標籤事件當下」的版本,不能用未來資訊(否則 label leakage,離線虛高、線上崩盤)。
- 特徵版本與血緣:每個特徵有定義版本、來源、計算邏輯,可審計、可回溯。
- 共享與重用:不同模型共用特徵,避免重複造輪子;新人能查到「有哪些特徵可用」。
🎤 面試官追問:「線上 store 的特徵怎麼保持新鮮?」(streaming 即時更新 + batch 回填的 lambda 架構;依特徵時效決定。)「point-in-time join 為什麼重要?」(不做就會用到未來特徵,訓練分數造假。)「線上 store 掛了怎麼辦?」(降級用預設值/上一版快取,並有告警。)
Step 4 — 訓練 Pipeline（可重現是底線）
訓練不該是「某人在筆電上跑一個 notebook」,而是可重現、可排程、可追溯的流水線:
- 步驟:取資料 → point-in-time 組特徵 → 切分(train/val/test,注意時間切分防洩漏)→ 訓練 → 離線評估 → 產出模型 artifact + metadata。
- 可重現性三要素:鎖定資料版本、特徵版本、程式碼/超參版本。同樣輸入要能產出同樣模型。
- 編排:用 workflow orchestrator(Airflow / Kubeflow / Metaflow 之類)管 DAG、重試、排程、回填。
- 觸發:定時、資料到位、或監控偵測到指標衰退時自動重訓。
🎤 面試官追問:「怎麼確保半年後能重現這個模型?」(版本化資料+特徵+程式碼+環境,artifact 連同 metadata 存進 registry。)「為什麼時間序列要按時間切分而非隨機切分?」(隨機切會把未來資料漏進訓練集。)
Step 5 — 模型版本與 Registry（這題的核心之二）⭐
模型不是檔案,是帶 metadata 的版本化產物。Model registry 負責治理:
- 每個模型版本記什麼:模型 artifact、訓練用的資料/特徵版本、超參、離線指標、訓練時間、產出者、對應的特徵 schema。
- 生命週期狀態:
staging(待驗證)→production(線上)→archived(退役)。一鍵切換/回滾。 - 模型 ↔ 特徵綁定:模型版本必須綁定它依賴的特徵版本與 schema,否則新模型配舊特徵會悄悄出錯。
- 可回滾:production 永遠能一鍵切回上一個已知良好版本——這是安全上線的保險。
🎤 面試官追問:「線上要同時跑 A/B 兩個模型版本怎麼管?」(registry 標記 + 服務層按流量路由到不同版本。)「模型和特徵 schema 不一致會怎樣?」(特徵順序/型別對不上→預測全錯且不報錯,所以要 schema 校驗。)
Step 6 — 服務與漸進式部署（安全上線）⭐
新模型絕不直接全量上線,要漸進式放量:
- 服務型態:
- 線上即時:模型服務(REST/gRPC),線上 store 取特徵,低延遲;可用 batching、GPU、快取優化。
- 批次:排程跑離線打分,寫進結果表/線上 store。
- 漸進式部署策略:
- 影子模式(Shadow):新模型跟著線上流量跑但不影響使用者,只比對預測差異,先驗證穩定性與一致性。
- 金絲雀(Canary)/灰度:先放 1% → 5% → 50% → 100%,每階段看指標與護欄。
- A/B test:科學量化新模型對業務指標的影響(見前一篇排序系統)。
- 隨時可回滾:任何階段指標異常,一鍵切回舊版。
🎤 面試官追問:「影子模式和金絲雀差在哪?」(影子不影響使用者、只收預測;金絲雀真的服務一小部分流量。)「怎麼決定金絲雀放量速度?」(看護欄指標穩定度 + 樣本量是否足夠顯著。)
Step 7 — 監控與資料閉環
模型上線才是開始,要持續盯三類訊號:
- 資料/特徵層:輸入分布漂移(data drift)、特徵缺失率、線上線下特徵一致性。
- 模型層:預測分布漂移、線上指標(若有 label)、模型 staleness。
- 系統層:延遲(各分位)、吞吐、錯誤率、線上 store 命中率。
- 閉環:預測 + 真實回饋寫回離線 store,成為下次重訓的資料;偵測到衰退就觸發重訓。
🎤 面試官追問:「沒有即時 label 的任務(如風控)怎麼監控模型好壞?」(用 proxy 指標 + 資料漂移 + 延遲標籤回填;設定漂移告警。)「training-serving skew 上線後怎麼抓?」(線上記錄實際送進模型的特徵,和離線重算比對。)
一張表收束
| 模組 | 解決什麼 | 面試送分點 |
|---|---|---|
| Feature Store | 訓練/服務特徵一致 | 雙儲存單定義、point-in-time |
| 訓練 Pipeline | 可重現、可排程 | 鎖資料/特徵/程式碼版本 |
| Model Registry | 模型版本治理 | 模型綁特徵 schema、可回滾 |
| 漸進式部署 | 安全上線 | 影子 → 金絲雀 → A/B |
| 監控閉環 | 持續可靠 | 三層漂移 + 回滾觸發 |
回答框架口訣
被問「設計 ML pipeline」時照這條線走:
- 釐清離線批次 vs 線上即時(決定整體架構)
- 畫端到端兩條主線(離線訓練 / 線上服務,在 feature store 交會)
- 重點講 Feature Store(雙儲存單定義、point-in-time、避免 skew)
- 講訓練可重現(版本化資料/特徵/程式碼)
- 講 Model Registry(版本、模型綁特徵 schema、可回滾)
- 講安全上線(影子 → 金絲雀 → A/B,隨時回滾)
- 收在監控閉環(三層漂移 + 觸發重訓)
記住一句話:ML pipeline 的難點不是訓練模型,而是「一致性」(特徵)、「可重現」(訓練)、「可治理」(版本)、「可安全上線」(部署)——把這四件事串成閉環,你就答好了這題。