背景與目標

從 Day 11 開始，我們已經完成：

• Day 11：Popular Top-10 baseline 建立並註冊到 MLflow。
• Day 12：Optuna 自動化調參 + MLflow 紀錄。
• Day 13：封裝成 Pipeline。
• Day 14：加入更多特徵 (genre/type)。
• Day 15：統一推論輸出格式，存推薦結果為 artifacts。
• Day 16：做模型解釋（TF-IDF 權重：單一樣本 + 全資料集）。
• Day 17：訓練模型並註冊到 Registry，設定 Stage = Staging，再用 mlflow models serve 啟動 REST API。

👉 今天我們要 總結這段流程，整理一份完整的「企業級推薦系統開發 → 部署」藍圖，幫助我們把前面學的點串成一條線。

模型開發與部署流程總覽

1. 模型實驗（Experiment Tracking）

• 使用 MLflow Experiment 來記錄每次 run：

  • params（參數，如 max_features, min_df）
  • metrics（指標，如 Precision@10）
  • artifacts（推薦清單 JSON, 特徵重要性 JSON）

好處：

• 每個實驗都有紀錄，方便比較。
• 能快速找到最佳模型。

2. 模型註冊（Model Registry）

• 用 mlflow.pyfunc.log_model(..., registered_model_name="AnimeRecsysModel") 註冊模型。

• 每次訓練會新增一個版本：

  • v1: Popular Top-10
  • v2: TF-IDF
  • v3: （未來可能是 user-based CF）

Registry 提供：

• 版本控制（v1, v2, v3…）
• Stage 管理（Staging, Production, Archived）
• 團隊協作（誰負責 Promote/Archive）。

3. 模型解釋（Explainability）

• 單一樣本：知道某部動畫的主要特徵（ex: kids, comedy）。
• 全資料集：知道最常用來區分動畫的 genre/type。

意涵：

• 幫助 PM/商務部門理解推薦邏輯。
• 提高模型透明度。
• 減少「黑箱」疑慮。

4. 模型部署（Serving）

兩種方式：

1. 快速 Demo：mlflow models serve -m "runs:/<run_id>/model"

   • 適合測試，但不建議正式使用。

2. 企業級部署：mlflow models serve -m "models:/AnimeRecsysModel/Staging"

   • 使用 Registry 管理版本。
   • 可透過 Promote 把最佳模型推到 Production。

完整流程圖

(實驗)  Train Models → MLflow Tracking
          │
          ▼
(選模)  MLflow UI → 比較 metrics/artifacts
          │
          ▼
(登錄)  MLflow Model Registry
          │
   ┌──────┴────────┐
   │               │
 (Staging)      (Production)
   │               │
   ▼               ▼
 mlflow models serve   →   實際對外 API

實務建議

• 日常實驗：放在 Experiment，跑很多 run。
• 穩定模型：註冊到 Registry，給 version 與 Stage。
• API 提供服務：只允許 Staging/Production 的模型能進行model serve。
• 模型切換：只要在 Registry 把 Stage Promote，就能無縫切換 API 背後的模型。

重點總結

• MLflow 的好用之處在於 追蹤 + 註冊 + 部署 一條龍。

• Day 11–17 我們已經完成一個小型企業級推薦系統：

  • 實驗追蹤：所有 run 都有紀錄。
  • 模型註冊：模型版本化管理，避免 run 遺失。
  • 模型解釋：讓推薦系統更透明。
  • 模型部署：一行指令 serve 成 REST API。

👉 接下來 Day 19，我們要進一步學習 CI/CD 架構設計，讓這套流程可以自動化運行，不用辛苦靠手動。