Model Registry 在 MLOps 哪個階段最重要？
原題
在企業導入的 MLOps（Machine Learning Operations）流程中，Model Registry 最常用於哪一個階段？
白話
MLOps 是讓機器學習模型從開發到上線、維護的整套工程流程，就像軟體工程（DevOps）一樣，只是對象是 AI 模型。
「Model Registry（模型登錄所）」是 MLOps 裡的一個工具。
問你：Model Registry 主要用在 MLOps 流程的哪個環節，它做什麼事？
先自己選一個答案，再看完整解析。
一句話總結
Model Registry 是 MLOps 流程中的「模型檔案室」，核心功能是集中管理模型版本、訓練紀錄與部署狀態，讓團隊隨時知道哪個版本的模型在線上跑、是誰訓練的、用了哪些超參數、現在狀態是什麼。
情境
先感受問題：模型越改越多，誰知道線上跑的是哪版？
假設「風險管家」公司的 AI 團隊在訓練詐欺偵測模型，一個月內跑了 30 次實驗：
model_v1：用 Random Forest，AUC 0.82，訓練日 5/1
model_v2：加了新特徵，AUC 0.86，訓練日 5/8
model_v3：改用 XGBoost，AUC 0.89，訓練日 5/15
model_v4：調整超參數，AUC 0.88（退步了），訓練日 5/20
…（共 30 個版本）
現在問題來了：
- 線上正在跑的是哪個版本？v3 還是 v2？
- 上週上線的版本，用了哪組超參數？資料是哪一批？
- 如果線上 AUC 突然下降，可以快速「退版」到前一個好版本嗎？
- 新工程師加入，怎麼知道過去的實驗歷史？
如果這些資訊散落在每個人的電腦裡、不同的資料夾裡，團隊就會陷入混亂。
舊方法
沒有 Model Registry，團隊怎麼管模型
在 Model Registry 出現前，工程師通常這樣管，每個方法都有致命缺點：
- 用資料夾和日期命名：model_20250515_xgboost_lr001.pkl，看起來有規律，但沒有統一格式，每個人命名習慣不同，三個月後自己都看不懂。
- 用 Excel 記錄實驗：欄位有 AUC、超參數、訓練日期，但很快就失控，工程師懶得填，資料和模型檔案的對應關係斷了。
- 用 Git 版本控制模型：模型檔案可能幾百 MB，Git 不適合存大型二進位檔案，push 超慢，repo 很快爆炸。
- 口頭溝通「線上跑哪版」：靠 Slack 訊息說「我剛部署 v3」，但訊息沉下去了，兩週後沒人記得。
- 沒有退版機制：線上模型出問題，要回到上一個版本，得翻舊資料夾、重新找檔案、手動部署，慌亂中很容易出錯。
新方法
Model Registry 統一管起來
「風險管家」的團隊導入 MLflow Model Registry 後，每次訓練完模型，工程師執行一行程式：
mlflow.log_model(model, "fraud_detector", registered_model_name="FraudDetector")
這個動作自動把以下資訊存進 Registry：
- 模型版本：自動編號 Version 1、Version 2…
- 訓練紀錄（Run ID）：對應到這次實驗的超參數、資料集版本、評估指標
- 部署狀態：Staging（測試中）/ Production（線上）/ Archived（已封存）
- 誰做的 + 什麼時候：完整的 audit trail
線上模型突然 AUC 下降，工程師到 Registry 查，發現 v4 比 v3 差，一個指令把 Production 從 v4 切回 v3，整個過程 5 分鐘。
這就是選項 C 講的：用於集中管理模型版本、訓練紀錄與部署狀態。
本題沒有程式碼，但理解 Model Registry 在 MLOps 生命週期的定位很重要。
MLOps 的完整生命週期通常分為五個階段，每個階段有對應工具：
| 階段 | 工具範例 |
|---|---|
| 資料準備與特徵工程 | Feature Store（Feast、Tecton）、DVC |
| 模型訓練與實驗追蹤 | MLflow Tracking、Weights & Biases |
| 模型版本管理 | Model Registry（MLflow、SageMaker） |
| 模型部署與服務 | KServe、BentoML、Kubernetes |
| 監控與漂移偵測 | Evidently AI、Seldon Core、WhyLogs |
Model Registry 的三個核心狀態機制：
# 模型版本的生命週期狀態
Staging → 已訓練完成，在測試環境驗證中
Production → 通過測試，部署到線上，正在服務真實流量
Archived → 已被新版本取代，封存保留（可隨時回復）
# MLflow Python SDK 操作示範
import mlflow
from mlflow.tracking import MlflowClient
client = MlflowClient()
# 把特定版本升級到 Production
client.transition_model_version_stage(
name="FraudDetector",
version=3,
stage="Production"
)
# 把舊版本降回 Archived（退版）
client.transition_model_version_stage(
name="FraudDetector",
version=4,
stage="Archived"
)
# 查詢目前哪個版本在 Production
prod_versions = client.get_latest_versions("FraudDetector", stages=["Production"])
print(prod_versions[0].version) # 輸出: 3Model Registry 和 Experiment Tracking 的區別：Experiment Tracking 記錄「這次實驗跑了什麼」（超參數、指標、artifact），Model Registry 是「把其中優秀的模型提升為正式管理對象，追蹤它的部署狀態」。前者是訓練時用，後者是訓練完準備部署時用。
錯選項
為什麼其他選項是錯的
A用於設定運算資源與執行環境以確保訓練穩定
字面在說什麼
說 Model Registry 用來設定訓練時的 GPU 數量、記憶體大小、執行環境（Python 版本、套件清單）等，確保每次訓練都能穩定執行。
為什麼不對
這是「訓練環境管理」的工作，對應工具是 Kubernetes（資源調度）、Docker（容器化執行環境）、MLflow Projects（定義可重現的執行環境）。Model Registry 不管訓練時的資源和環境，它只管「訓練完成後的模型」：版本、指標、部署狀態。
誰會選錯
把 MLOps 的不同功能混在一起的人。「穩定訓練」和「管理訓練成果」是兩個不同的關切，Registry 只負責後者。
B用於建立可重複使用的資料與特徵版本
字面在說什麼
說 Model Registry 幫你把訓練資料和特徵的不同版本管理起來，確保實驗可以重現。
為什麼不對
這是「Feature Store（特徵儲存）」和「資料版本控制」工具的工作，如 Feast、Tecton、DVC（Data Version Control）。Model Registry 管的是「模型」不是「資料」或「特徵」。雖然 Model Registry 通常會記錄「這個模型訓練時用了哪個資料集版本」，但管理資料集本身不是它的職責。
誰會選錯
看到「版本」就以為是 Model Registry 的事，但沒注意版本控制的對象不同：Registry 管模型版本，Feature Store 管特徵版本，DVC 管資料集版本，Git 管程式碼版本。
D用於追蹤模型上線後的表現與漂移情況
字面在說什麼
說 Model Registry 在模型上線後，持續監控它的準確率、資料分佈有沒有飄移（drift），確保模型效能不衰退。
為什麼不對
這是「模型監控（Model Monitoring）」的工作，對應工具是 Evidently AI、Seldon Core、WhyLogs、或自建的監控 pipeline。Model Registry 記錄的是「靜態資訊」（版本、指標、部署狀態），不負責持續追蹤線上推論的動態表現。兩者在 MLOps 生命週期裡是相鄰但不同的環節：Registry 在部署之前，Monitoring 在部署之後。
誰會選錯
因為 Registry 和 Monitoring 都和「部署」相關就混在一起的人。記住：Registry 是「管哪個版本在線上」，Monitoring 是「監控線上那個版本表現怎麼樣」，前者是靜態記錄，後者是動態追蹤。
變形題
同個考點下次怎麼變形
兩個都是 MLflow 的功能，都在追蹤模型，有什麼差別？
答案
MLflow Tracking 記錄「每一次實驗跑了什麼」：超參數、指標、artifact，像流水帳，每次訓練都有一筆 Run 紀錄。Model Registry 是從這些 Run 裡「挑選優秀的模型，正式列管」：給它名字、版本號、部署狀態，是經過篩選的正式目錄。比喻：Tracking 是實驗室筆記本，Registry 是正式的產品目錄冊。
只有 2 個人，互相說一聲就好了，不需要這麼正式的工具？
答案
小團隊仍然建議用，因為模型數量的複雜度增長比人員增長快得多。2 個人 3 個月可能跑了 50 個實驗，版本就難以追蹤。更重要的是，6 個月後回頭看「上次那個表現最好的版本是哪個」，沒有 Registry 就要翻資料夾、找 log，浪費時間。MLflow 等工具設定門檻很低，小團隊從第一個模型就建議用。
軟體工程有 CI/CD 自動化部署，AI 模型可以做到一樣嗎？
答案
可以，這就是 CI/CD for ML 的核心。完整流程：模型訓練完成 → 自動登錄到 Registry（Staging 狀態）→ 自動觸發測試 Pipeline（準確率、延遲、公平性檢查）→ 通過測試自動升級為 Production → 自動部署到 Kubernetes 服務。Registry 在這裡扮演「狀態機閘門」的角色：只有 Registry 裡狀態是 Production 的版本，才會被部署 Pipeline 取用。
AI 特有的工具，軟體工程沒有類似的東西？
答案
對應到軟體工程的 Artifact Registry（如 JFrog Artifactory、GitHub Packages）和 Container Registry（如 Docker Hub、Google Container Registry）。軟體裡存的是 JAR 檔、Docker Image，AI 裡存的是模型檔案（.pkl、.pt、SavedModel）；版本管理、環境依賴記錄、部署狀態管理的邏輯完全一樣。Model Registry 可以視為 AI 模型的 npm registry。
新版本 AUC 比舊版高 0.01，就可以上線了嗎？
答案
不只看單一指標。企業通常設定升版門檻的多個條件：主要指標（如 AUC）必須高於當前 Production 版本且達到統計顯著；延遲（latency）不能比舊版差超過 10%；公平性指標（各族群的錯誤率）必須通過；在 Staging 環境的壓力測試（高並發）要過；有些公司還要求「影子模式（Shadow Mode）」運行一週，確認實際流量下的表現才升 Production。
延伸
想再往下看，這 5 個
- 模型登錄庫（Model Registry）
正解核心：集中管理模型版本、訓練紀錄與部署狀態的工具，是 MLOps 中模型從實驗到上線的正式管理機制。 - 機器學習維運（Machine Learning Operations）
Model Registry 所屬的工程實踐框架，涵蓋資料管理、訓練、版本控制、部署、監控的完整 AI 生命週期。 - 模型版本控制（Model Versioning）
Model Registry 的核心功能之一，自動為每次訓練產生版本號並記錄超參數與指標，讓退版與追溯變得可行。 - 特徵儲存庫（Feature Store）
管理特徵版本的平台，和 Model Registry 分工明確：一管資料特徵，一管模型版本，是易混淆的近似概念。 - 金絲雀部署（Canary Deployment）
先讓少數流量接觸新版模型、確認後再擴大的部署策略，常配合 Model Registry 的版本狀態管理（Staging→Production）使用。