機器學習的 CI/CD：程式改了，Cloud Build 自動測試、部署管線；資料來了，排程或 Pub/Sub 觸發自動重訓。
上一篇把訓練流程做成管線（MLOps 等級 1）。這篇往前走一步到等級 2：管線本身改版時怎麼自動測試、自動上線；以及管線要什麼時候自己跑：每週固定、新資料到了、模型變笨了。
一樣用有 2,000 間分店的連鎖飲料店當例子（教學假設）：會員流失模型每週一重訓，推薦模型每天重訓，而且分析師每隔幾週會改特徵工程的程式。
為什麼你需要知道
- 管線也會改：分析師加一個特徵、換一個模型架構，管線的程式就變了。沒有 CI/CD，新版管線還是靠人手動測試、手動上傳，等級 1 做到一半
- 重訓的時機是錢：重訓太勤是浪費 GPU，太懶是模型變笨。「什麼時候重訓」要有政策，不是感覺
- 筆記裡的三條都要更新：「Cloud Build＋Cloud Source Repositories」的後者已不開放新客戶；「Cloud Storage 觸發＋Cloud Function」現在叫 Cloud Run functions；「Cloud Scheduler 定期觸發」還在，但 Pipelines 自己也有排程 API
- 證照必考：PMLE 考試指南第 5.2 節「自動化模型重訓」：決定適當的重訓政策；用 CI/CD/CT 管線（例如 Cloud Build）部署模型。整個第 5 區佔 18%
先搞懂：CI、CD、CT 三個詞
白話是什麼
| 縮寫 | 全名 | 白話 | 觸發 | 產出 |
|---|---|---|---|---|
| CI | 持續整合（Continuous Integration） | 程式一改，自動跑測試、自動打包 | 程式碼推到版本庫 | 測過的程式包、容器映像檔 |
| CD | 持續交付（Continuous Delivery） | 打包好的東西自動部署到正式環境 | CI 成功 | 上線的新管線、新模型服務 |
| CT | 持續訓練（Continuous Training） | 資料一來，用既有管線自動重訓 | 排程、新資料、效能下降 | 新模型 |
CI 和 CD 是軟體界本來就有的，CT 是 ML 特有的：程式沒改，但資料變了，也要重做一次。
比喻
連鎖飲料店的總部：
- CI：研發部改了配方，先在中央廚房試做、試喝（測試），通過才印成新的配方卡（打包）
- CD：新配方卡自動發到 2,000 間分店（部署），不用總部一間一間打電話
- CT：配方沒改，但每天早上進新鮮水果，各店照既有配方重新備料（重訓）
來龍去脈：兩條不同的管線
Google 的 MLOps 架構文件特別區分兩件事：
| CT 管線 | CI/CD 管線 | |
|---|---|---|
| 做什麼 | 用新資料訓練新模型 | 部署新的管線實作 |
| 跑的是 | 已經部署好的那條管線 | 建置、測試、部署管線的流程 |
| 什麼時候 | 排程、新資料、效能下降 | 管線程式碼改了 |
| 產出 | 新模型（推到 Model Registry）、新的預測服務 | 新版管線（包含新的元件、新的 DAG） |
官方原話：「要用新資料訓練新模型，執行先前部署的 CT 管線；不部署新的管線或元件。」「要部署新的管線實作，需要 CI/CD 管線。」考題常把這兩條混在一起問，分清楚就能選對。
為什麼要學
等級 2 的定義就是「CI/CD 管線自動化」。考試 5.2 寫「用 CI/CD/CT 管線部署模型」，三個字母一起考。
1. 什麼時候重訓：重訓政策
白話是什麼
重訓政策（retraining policy）：事先決定「什麼情況下重新訓練模型」。考試 5.2 第一條就是「決定適當的重訓政策」。
官方 MLOps 文件列的五種觸發：
| 觸發 | 白話 | 適合 | 飲料店 |
|---|---|---|---|
| 手動 | 有人按按鈕 | 剛起步、模型很少變 | 第一次上線 |
| 排程 | 每天／每週／每月固定跑 | 新標好的資料規律地出現 | 流失模型每週一（上週誰沒回來已經確定） |
| 新資料到了 | 資料不定期出現，到了就跑 | 資料來源不規律 | 新菜單上架、新分店開幕 |
| 效能下降 | 線上模型分數明顯變差 | 有監控（第 20 篇） | 推薦點擊率連續三天掉 |
| 資料分布改變 | 特徵的分布跑掉（概念漂移） | 有監控 | 夏天來了，冰飲比例暴增 |
官方補充：排程的頻率看資料模式變化多快和重訓多貴。
算一次給你看：重訓多勤才划算
推薦模型一次重訓 110 元（第 18 篇算過的管線費用）。每天重訓 vs 每週重訓：
每天：365 × 110 = 40,150 元／年
每週：52 × 110 = 5,720 元／年
每天比每週多花 34,430 元／年值不值得，看模型不重訓會壞多快。假設推薦模型一週不更新，點擊率平均掉 0.1%（教學假設）：
一天 100 萬次推薦 × 0.1% = 1,000 次點擊／天
一年少 1,000 × 365 = 365,000 次點擊只要一次點擊的價值超過 34,430 ÷ 365,000 ≈ 0.09 元，每天重訓就划算。飲料店一次點擊帶來的訂單遠超過這個數，所以推薦模型每天重訓。
反過來，封膜檢查模型的資料（封膜機沒換、鏡頭沒換）幾乎不變，每天重訓是浪費，只在監控發現效能下降時重訓。
數字怎麼看：
- 資料變化快（使用者行為、季節）→ 重訓勤
- 資料幾乎不變（物理規則、設備）→ 靠監控觸發
- 重訓越貴（大模型、多 GPU）→ 越要用「效能下降」而不是「固定排程」
2. 程式改了：Cloud Build 做 CI/CD
白話是什麼
Cloud Build：Google 代管的「建置機器」。你寫一份設定檔（cloudbuild.yaml）列出步驟，它從版本庫抓程式、照步驟執行（跑測試、打包容器）、產出成品。官方說每個建置步驟都在一個 Docker 容器裡跑，像在腳本裡執行指令一樣。
版本庫（repository）是存程式碼、記錄每次修改的地方，GitHub 是最常見的。
比喻
總部的試做間。研發部一交新配方（推程式碼），試做間自動：試做（測試）→ 印配方卡（打包容器）→ 存進配方庫（Artifact Registry）→ 通知各店換新 SOP（部署管線）。
觸發：什麼時候建置
官方觸發條件文件：連接 GitHub、Bitbucket 等版本庫，設定建置觸發條件（build trigger）：
| 觸發 | 白話 |
|---|---|
| 推到分支（push to a branch） | 程式碼推到某個分支（例如 main）就建置 |
| 推新標籤（push new tag） | 打了版本標籤（例如 v2.0）才建置，適合正式發布 |
| 拉取請求（pull request） | 有人提出合併請求時先建置測試，過了才准合併 |
分支是程式碼的平行版本（開發用一條、正式用一條），合併請求是「我改好了，請審核後併進去」。可以設不同分支觸發不同的建置流程（開發分支只跑測試、主分支才部署）。
一次建置做什麼：官方的步驟
MLOps 架構文件列的 ML 管線 CI/CD 典型步驟：
- 把版本庫複製到 Cloud Build 的工作目錄
- 跑單元測試和整合測試（元件裡的函數對不對、整條管線接不接得起來）
- 可選：靜態分析（Pylint 檢查程式風格和明顯錯誤）
- 測試過了，每個管線元件各建一個容器映像檔，用
$COMMIT_SHA（這次修改的識別碼）當標籤 - 映像檔推到 Artifact Registry
- 把元件設定裡的映像檔網址換成新的
- 編譯管線成 YAML（第 18 篇講的）
- 編譯好的管線上傳到 Artifact Registry（當範本）
- 可選：用測試參數跑一次管線當整合測試
官方的版本庫通常放：管線定義的 Python、各元件的程式和規格、每個元件的 Dockerfile、測試、cloudbuild.yaml、設定檔、探索用的筆記本。
變數替換
Cloud Build 提供建置時才知道的變數：$COMMIT_SHA、$REPO_NAME、$BRANCH_NAME、$TAG_NAME、$PROJECT_ID、$BUILD_ID。用途是讓映像檔標籤、管線名稱帶上版本資訊，之後追血緣（第 22 篇）才知道這個模型是哪次修改訓練出來的。
Cloud Source Repositories 怎麼了
筆記寫「Cloud Build＋Cloud Source Repositories（程式碼變更觸發）」。Cloud Source Repositories 是 Google 自家的 Git 版本庫，但現在的文件首頁第一條就是「遷移說明」，已不開放給新客戶。現在的標準做法是 GitHub（或 GitLab、Bitbucket）＋Cloud Build，考題看到 Cloud Source Repositories 就把它當 GitHub 理解。
3. 資料來了、時間到了：觸發 CT 管線
白話是什麼
管線部署好了，要讓它自己跑。官方架構文件的做法（Figure 6）：
Cloud Scheduler ─┐
Managed Airflow ─┼→ Pub/Sub 主題 → Cloud Run 函式 → Agent Platform SDK 啟動管線
Cloud Logging ───┘三個名詞：
- Pub/Sub：Google 的訊息服務，像公司的公告欄。誰都可以貼公告（發布訊息到主題），訂閱的人看到公告就行動
- Cloud Run functions（舊名 Cloud Functions）：一小段程式，有事件發生才執行、跑完就收。這裡它訂閱公告欄，看到訊息就呼叫 Agent Platform SDK 的
PipelineJob跑管線。官方有一篇教學就是這個做法 - Agent Platform SDK：用 Python 操作 Agent Platform 的套件，
PipelineJob可以建立、執行管線
誰來貼公告
官方列了三個發布者，對應三種觸發：
| 發布者 | 對應的觸發 | 飲料店 |
|---|---|---|
| Cloud Scheduler | 排程：到時間就貼公告 | 每週一 06:00 貼「重訓流失模型」 |
| Managed Service for Apache Airflow（舊名 Cloud Composer） | 新資料到了：資料工程流程的最後一步貼公告，例如 BigQuery 匯入完新資料 | 每天交易資料匯進 BigQuery 完成後貼「重訓推薦模型」 |
| Cloud Logging | 效能下降／漂移：日誌符合條件就貼公告，例如 Model Monitoring（第 20 篇）發出偏差或漂移警報 | 監控發現夏天冰飲比例暴增，貼「重訓」 |
Cloud Scheduler 是代管的 cron（定時器）服務，目標可以是 HTTP 端點、Pub/Sub 主題。官方提醒它是「至少一次」送達，極少情況會重複送，所以管線要能承受重複執行（跑兩次結果一樣，叫冪等）。
更簡單的排程：Pipelines 自己的排程 API
純排程的話，不用繞 Pub/Sub。Agent Platform Pipelines 有排程 API：用 cron 表達式（例如 0 6 * * 1 是每週一 06:00）設定頻率，可以指定開始和結束時間、暫停和恢復、限制同時執行數。
筆記的「Cloud Storage 觸發＋Cloud Function」現在怎麼做
新資料是檔案（例如每天一批封膜照片丟進 Cloud Storage）時，用 Eventarc：它是 Google 的事件路由服務，Cloud Storage「新檔案建立」的事件可以直接觸發一個 Cloud Run 函式，函式再啟動管線。這就是筆記那條的現代版。
三種做法怎麼選
| 情況 | 做法 |
|---|---|
| 只是固定時間跑 | Pipelines 排程 API 最簡單 |
| 很多來源都可能觸發、或要接現有的資料流程 | Pub/Sub＋Cloud Run 函式，大家貼同一個公告欄 |
| 新檔案進 Cloud Storage 就跑 | Eventarc＋Cloud Run 函式 |
| 整間公司的資料流程最後一步要重訓 | Managed Service for Apache Airflow 的 DAG 最後呼叫管線或貼公告 |
4. 重訓完要不要上線：模型驗證關卡
白話是什麼
自動重訓的風險：新資料有問題、新模型比舊的差，管線照樣把它部署上去。所以 CT 管線裡一定要有模型驗證（model validation）這一步，官方 MLOps 文件把它列為等級 1 的必要元件。
比喻
新一批珍奶煮好了，先給店長試喝、跟昨天的比，比昨天好才上架。差了就倒掉，繼續賣昨天的。
驗證什麼
官方列的三件事：
- 評估指標跟基準比：新模型的分數（第 5、6 篇的 AUC、召回率）要比目前上線的模型好，或至少不差
- 分段表現：整體分數好，但某一群（新會員、某個城市）變差也不行。TFX 的 TFMA 切片評估（第 18 篇）就是做這個
- 基礎設施相容：模型真的能被服務載入、回應正常（TFX 的 InfraValidator）
通過的模型才註冊到 Model Registry、部署（通常先用第 17 篇的流量分割做金絲雀）。TFX 把「通過驗證」叫 blessing（祝福），沒被祝福的模型 Pusher 不會推。
算一次給你看
流失模型目前上線版 AUC 0.850。驗證門檻設「新模型要比舊的高 0.005 以上才換」：
新模型 A：AUC 0.862 → 0.862 − 0.850 = 0.012 ≥ 0.005 → 部署
新模型 B：AUC 0.853 → 0.853 − 0.850 = 0.003 < 0.005 → 不部署，繼續用舊的
新模型 C：AUC 0.871，但「新會員」這一段 AUC 從 0.80 掉到 0.72 → 整體好、分段差 → 不部署數字怎麼看：
- 門檻設 0 代表「不比舊的差就換」，太寬鬆，隨機波動也會換；設太高永遠換不了。常見做法是用驗證集的波動範圍來定
- 分段檢查是防「平均掩蓋問題」，第 9 篇的類別不平衡在這裡會再咬你一次
在 GCP 上怎麼做
飲料店的完整架構
- 版本庫：GitHub 放管線程式、元件、Dockerfile、測試、
cloudbuild.yaml - CI/CD：Cloud Build 觸發條件設「推到
main」→ 測試 → 建元件映像檔推 Artifact Registry → 編譯管線上傳範本 - CT 觸發：
- 流失模型：Pipelines 排程 API，每週一 06:00
- 推薦模型：Airflow 的資料匯入 DAG 最後一步發 Pub/Sub → Cloud Run 函式啟動管線
- 封膜模型：Model Monitoring 警報 → Cloud Logging → Pub/Sub → 重訓
- 管線內容：驗證資料（TFDV 或自己寫）→ 訓練 → 評估並跟舊模型比→ 通過才註冊 Model Registry → 部署到端點（流量分割 10%）
- 監控（第 20 篇）回頭觸發第 3 步
權限
Cloud Build 和 Cloud Run 函式各自用服務帳戶執行，要有啟動管線、寫 Artifact Registry、部署模型的權限。官方文件提醒，Cloud Run 函式部署時會自動用到 Cloud Storage、Cloud Build、Artifact Registry，權限要一起給。
改名對照
| 舊名稱（筆記、舊題庫） | 現在 |
|---|---|
| Cloud Source Repositories | 已不開放新客戶，改用 GitHub、GitLab、Bitbucket＋Cloud Build |
| Cloud Functions | Cloud Run functions |
| Cloud Storage Trigger（觸發 Cloud Function） | Eventarc 觸發 Cloud Run 函式 |
| Cloud Composer | Managed Service for Apache Airflow |
| Container Registry | Artifact Registry |
| Vertex AI Pipelines、Vertex AI Model Monitoring | Agent Platform Pipelines、Model Monitoring on Agent Platform |
考試會怎麼考
Google Cloud Professional Machine Learning Engineer（PMLE，專業機器學習工程師） 證照，2026 年 6 月 1 日起的官方考試指南裡，這篇的內容對應到：
| 考試區塊 | 跟這篇有關的項目 |
|---|---|
| 第 5 區：自動化與編排 ML 管線（約 18%） | 5.2 自動化模型重訓：決定適當的重訓政策；在 CI/CD/CT 管線中部署模型（例如 Cloud Build）。5.1 建立和編排管線（第 18 篇） |
| 第 6 區：監控 AI 方案（約 13%） | 6.2 監控結果觸發重訓（第 20 篇） |
看到這些字，就想到這個
| 題目出現的關鍵字 | 想到 |
|---|---|
| 「程式碼推上去就自動測試、打包、部署管線」 | Cloud Build 觸發條件（推到分支／標籤／PR） |
| 「管線本身改版」「新元件」 | CI/CD 管線（不是 CT） |
| 「程式沒改、用新資料重訓」 | CT 管線，跑既有管線 |
| 「每週固定重訓」「cron」 | Pipelines 排程 API，或 Cloud Scheduler |
| 「資料匯入 BigQuery 完成後重訓」「多個來源都可能觸發」 | Pub/Sub＋Cloud Run 函式啟動管線 |
| 「新檔案進 Cloud Storage 就重訓」 | Eventarc 觸發 Cloud Run 函式 |
| 「整間公司的資料流程最後一步」 | Managed Service for Apache Airflow |
| 「監控發現漂移就重訓」 | Model Monitoring 警報 → Cloud Logging → Pub/Sub |
| 「什麼時候該重訓」「重訓頻率」 | 重訓政策：資料變化速度 × 重訓成本 |
| 「新模型比舊的差卻上線了」 | 管線缺模型驗證，加「跟上線模型比」的關卡 |
| 「整體分數好但某群人變差」 | 分段評估（TFMA 切片） |
| 「模型是哪次程式修改訓練的」 | 映像檔標 $COMMIT_SHA，血緣追蹤 |
| 「排程重複觸發」 | Cloud Scheduler 至少一次送達，管線要冪等 |
| 「Cloud Source Repositories」 | 已不開放新客戶，當 GitHub 理解 |
六個常見陷阱
- 把「用新資料重訓」答成要重新部署管線：那是 CT，跑既有管線就好
- 所有模型都每天重訓：封膜檢查這種資料不變的，靠監控觸發就好
- 自動重訓沒有驗證關卡：壞模型直接上線
- 只看整體 AUC：分段變差沒抓到
- 新資料進 Cloud Storage 還用 Cloud Scheduler 輪詢：事件驅動（Eventarc）才對
- Cloud Functions、Cloud Composer、Container Registry 的舊名：考題用新名，認不出來就選錯
練習情境（自己出的練習，不是真實考題）
飲料店的分析師改了推薦模型的特徵工程程式，推到 GitHub 的主分支。團隊希望自動跑測試、重新打包元件、更新正式環境的管線，不要人工介入。應該怎麼做？
判斷過程：
- 「程式改了」「自動測試、打包、更新管線」→ CI/CD 管線，用 Cloud Build
- 觸發條件設「推到主分支」；步驟：測試 → 建映像檔（標 $COMMIT_SHA）→ 推 Artifact Registry → 編譯管線 → 上傳範本
- 不是 CT：這題沒有新資料
每天凌晨交易資料匯進 BigQuery，匯入是 Managed Service for Apache Airflow 管的。團隊要在匯入完成後自動重訓推薦模型，而且未來可能有別的系統也要能觸發重訓。應該怎麼接？
判斷過程：
- 「匯入完成後」「未來別的系統也要觸發」→ Pub/Sub 主題當公告欄，Cloud Run 函式訂閱後啟動管線
- Airflow 的 DAG 最後一步發布訊息
- 不用 Cloud Scheduler：時間不固定（看匯入何時完成）
自動重訓上線兩個月後，發現有一週上線的模型比前一週差很多，但管線沒有擋下來。應該加什麼？
判斷過程：
- 「比前一週差卻上線」→ 缺模型驗證關卡
- 加一步：新模型跟目前上線的模型在同一份驗證資料上比，差超過門檻才部署；加分段評估
- 部署時用流量分割金絲雀（第 17 篇），再差也只影響 10%
常見問答
機器學習的 CI/CD 是什麼？跟一般軟體差在哪？
CI 是程式一改就自動測試、打包，CD 是自動部署到正式環境，這兩個跟一般軟體一樣。ML 多了 CT 持續訓練：程式沒改但資料變了，就用既有管線自動重訓。Google 的 MLOps 文件把「部署新管線實作」的 CI/CD 管線和「用新資料訓練」的 CT 管線分開，前者在管線程式碼改版時跑，後者在排程、新資料、效能下降時跑。
什麼時候該重訓模型？
考試叫這個「重訓政策」。五種觸發：手動、排程（每天／每週）、新資料到了、效能下降、資料分布改變。選哪種看資料變化多快和重訓多貴：使用者行為這種變得快的每天重訓，設備資料這種幾乎不變的靠監控觸發。可以算一次：每天比每週多花的重訓費，跟不重訓造成的損失比。
Cloud Build 在 ML 裡做什麼？
它是 CI/CD 的核心：從 GitHub 這類版本庫抓程式，照 cloudbuild.yaml 的步驟在容器裡執行。ML 管線的典型步驟：跑單元和整合測試、每個元件建容器映像檔並用 $COMMIT_SHA 標籤、推到 Artifact Registry、編譯管線成 YAML 上傳當範本、可選跑一次管線做整合測試。觸發條件可設推到分支、推新標籤、拉取請求。
Cloud Source Repositories 還能用嗎？
Google 自家的 Git 版本庫，現在文件首頁第一條就是遷移說明，已不開放給新客戶。現在的做法是 GitHub、GitLab 或 Bitbucket 接 Cloud Build。舊題庫看到 Cloud Source Repositories，當 GitHub 理解就好。
管線怎麼定期自動跑？
兩種做法。簡單的：Agent Platform Pipelines 自己的排程 API，用 cron 表達式設頻率，可設開始結束時間、暫停恢復。通用的：Cloud Scheduler 定時發訊息到 Pub/Sub 主題，Cloud Run 函式訂閱後用 Agent Platform SDK 的 PipelineJob 啟動管線。Cloud Scheduler 是至少一次送達，管線要能承受重複執行。
新資料到了怎麼自動觸發重訓？
看資料怎麼來。資料工程流程匯入 BigQuery 完成：Managed Service for Apache Airflow 的 DAG 最後一步發 Pub/Sub 訊息，Cloud Run 函式啟動管線。新檔案進 Cloud Storage：Eventarc 把「新檔案建立」事件送給 Cloud Run 函式。筆記裡的「Cloud Storage Trigger 加 Cloud Function」就是後者的舊說法。
監控發現模型變差怎麼自動重訓？
Model Monitoring（第 20 篇）發出偏差或漂移警報時會寫進 Cloud Logging，設一個日誌篩選條件，符合就發布到 Pub/Sub 主題，Cloud Run 函式收到後啟動重訓管線。官方架構文件把 Cloud Logging 列為三種發布者之一。
自動重訓怎麼避免壞模型上線？
CT 管線裡加模型驗證關卡：新模型跟目前上線的模型在同一份驗證資料上比，評估指標要好過門檻；分段（新會員、各城市）也要檢查，避免整體好但某群人變差；還要確認模型能被服務正常載入。TFX 的 Evaluator 和 InfraValidator 做這些，通過叫 blessing，Pusher 才推。部署再用流量分割做金絲雀。
Cloud Functions 改名了嗎？
是，現在叫 Cloud Run functions，併入 Cloud Run 底下。部署時會自動用 Cloud Storage 存原始碼、Cloud Build 建映像檔、Artifact Registry 存映像檔。事件觸發走 Eventarc 或 Pub/Sub。同時期 Cloud Composer 改名 Managed Service for Apache Airflow，Container Registry 由 Artifact Registry 取代。
MLOps 等級 2 跟等級 1 差在哪？
等級 1 是訓練流程做成管線、自動持續訓練，但管線程式碼改版還是手動測試、手動部署。等級 2 把這一段也自動化：程式推上版本庫就由 Cloud Build 測試、打包、部署新管線，監控結果回頭觸發新一輪。官方列的六個階段：開發實驗、管線 CI、管線 CD、自動觸發、模型 CD、監控。
重點整理
- 三個詞：CI 程式改了自動測試打包、CD 自動部署、CT 資料來了自動重訓（ML 特有）
- 兩條管線：CT 管線跑既有管線產出新模型；CI/CD 管線部署新的管線實作。考題最愛混
- 重訓政策：手動、排程、新資料、效能下降、漂移；看資料變化速度 × 重訓成本；算一次每天 vs 每週的差額
- 程式改了：GitHub → Cloud Build 觸發（推分支／標籤／PR）→ 測試 → 建映像檔標
$COMMIT_SHA推 Artifact Registry → 編譯管線上傳範本。Cloud Source Repositories 已不開放新客戶 - 資料來了：排程 API（純排程）；Pub/Sub＋Cloud Run 函式（多來源：Cloud Scheduler、Airflow、Cloud Logging 警報）；Eventarc（新檔案進 Cloud Storage）
- 驗證關卡：新模型跟上線模型比、分段檢查、服務相容；通過才部署，再用流量分割金絲雀
- 改名：Cloud Functions → Cloud Run functions；Cloud Composer → Managed Service for Apache Airflow；Container Registry → Artifact Registry
延伸閱讀
本系列
- 第 1 篇：機器學習有哪幾種？監督式、非監督式、強化學習一次看懂
- 第 2 篇：分類和迴歸差在哪？一個例子搞懂，附 MAE、RMSE 計算
- 第 3 篇：特徵、標籤、超參數是什麼？機器學習 5 個必懂名詞
- 第 4 篇：訓練集、驗證集、測試集怎麼切？時間序列為什麼不能亂切
- 第 5 篇：混淆矩陣是什麼？用快篩搞懂準確率、精確率、召回率、F1
- 第 6 篇：ROC 曲線和 AUC 怎麼看？門檻怎麼調、AUC-PR 差在哪
- 第 7 篇：過度擬合是什麼？正則化、Dropout、提前停止 3 招解決
- 第 8 篇：資料洩漏是什麼？模型考試作弊的 3 種常見情況
- 第 9 篇：類別不平衡怎麼辦？過取樣、欠取樣與 Upweighting
- 第 10 篇：資料前處理怎麼做？標準化、遺失值、高基數類別
- 第 11 篇：特徵工程是什麼？特徵交叉、詞嵌入、資料增強一次看懂
- 第 12 篇：機器學習的資料隱私怎麼保護？DLP、聯邦學習、VPC Service Controls
- 第 13 篇：訓練資料讀太慢？TFRecords、tf.data 與 prefetch 加速
- 第 14 篇：Vertex AI AutoML、BigQuery ML、自訂訓練怎麼選？
- 第 15 篇：BigQuery ML 入門：只會 SQL 也能訓練模型
- 第 16 篇：Vertex AI 自訂訓練：容器、分散式訓練、GPU 與 TPU
- 第 17 篇：模型部署怎麼選？線上預測 vs 批次預測、流量分割
- 上一篇：第 18 篇：MLOps 是什麼？Vertex AI Pipelines、Kubeflow、TFX 介紹
- 下一篇：第 20 篇：模型上線後會變笨？Drift 與 Training-Serving Skew 監控
站上相關文章
- 容器技術是什麼？從零開始看懂 Docker 與容器化應用
- 雲端職缺大解析：雲端工程師、架構師、SRE、DevOps、資料工程師差在哪？
- Kubernetes 是什麼？白話解釋＋判斷你是否真的需要它
- 使用 GCP Service Account 開發程式的小技巧和注意事項
- BigQuery 是資料庫嗎？跟資料庫差在哪
- GCP 學習路徑 Roadmap
程式改了自己測、資料來了自己訓、壞模型自己擋，這才叫自動化。如果你想有系統地從雲端基礎一路學到在 GCP 上動手做機器學習，可以看看東東的 GCP 課程，或加 LINE 聊聊你現在的狀況，一起找出最適合你的學習順序。