這是「GCP ML 工程師 SEO／GEO 系列文」的最後一篇，也是總整理。前面 23 篇把 Google Cloud Professional Machine Learning Engineer（PMLE，專業機器學習工程師） 證照會考的觀念，一篇一個主題、全部用白話講過一遍。這篇把它們接起來：考試長什麼樣、六大區各考什麼、哪一篇對應哪一區、零基礎怎麼排 8 週、舊題庫的名稱要換成什麼。

先說兩件事。第一，這不是考試心得：東東還沒考 PMLE，這篇是整理官方考試指南和官方考試頁的範圍與準備重點。第二，名稱：Vertex AI 在 2026 年 4 月起改名為 Gemini Enterprise Agent Platform（簡稱 Agent Platform），2026 年 6 月 1 日起的考試指南全面用新名稱，但大家搜尋還是打 Vertex AI，所以系列文標題都保留舊名，文中附新舊對照。

為什麼你需要知道

• 不知道範圍，讀的都不會考：PMLE 不考「演算法怎麼推導」，考的是「這個情境該選哪個 Google Cloud 服務、為什麼」。讀錯方向，花一樣的時間分數差很多
• 舊題庫會害你：網路上的題庫多半是 2023 年前整理的，裡面的 AutoML Tables、Cloud Source Repositories、Vertex Explainable AI 要嘛改名、要嘛停用。現在的考題用新名稱
• 轉職要的是證照加作品：這張證照是 Google Cloud 專業級裡最偏「做出來」的一張，考試指南第一段就寫 ML 工程師要「建置、評估、產品化、最佳化 AI 方案」。準備過程本身就是作品
• 一張地圖省三個月：系列 23 篇照考試邏輯排，這篇告訴你哪篇對應哪區、先讀哪篇

1. 先搞懂：PMLE 是什麼

白話是什麼

Google Cloud 發的機器學習工程師證照。考你會不會用 Google Cloud 的服務，把機器學習模型從「有資料」做到「上線、監控、自動重訓」，包括傳統模型和生成式 AI。

比喻

汽車駕照的筆試。不考你引擎怎麼設計，考你「這個路口該怎麼做」：題目給一個公司情境（資料在哪、要多快、預算多少、法規要求什麼），四個選項全是 Google Cloud 服務的組合，你選最合理的。

來龍去脈

這張證照 2020 年推出。2024 年改版加入生成式 AI。2026 年 6 月 1 日再改版，官方考試頁寫得很清楚：反映 Vertex AI 改名為 Gemini Enterprise Agent Platform、Google Cloud 資料與分析堆疊的更新，並且優先考 Google Cloud 原生方案。

為什麼要學

考試指南定義的 ML 工程師：處理大型複雜資料集、寫可重複使用的程式、懂模型架構、資料與 ML 管線、MLOps、指標解讀，還要熟提示工程、應用開發、基礎架構、資料工程與治理的基礎概念。這份清單就是 ML 工程師的職缺描述。站上的雲端職缺大解析講過這些角色差在哪。

考試基本資料

官方考試頁列的（2026 年 10 月查）：

算一次給你看：一題幾分鐘

120 分鐘 ÷ 60 題 = 每題 2 分鐘
留 15 分鐘回頭檢查標記的題目：
(120 − 15) ÷ 60 = 每題 1 分 45 秒

數字怎麼看：PMLE 的題目是一段情境加四個選項，讀題就要 40 秒。所以「看到關鍵字就想到答案」不是偷懶，是時間上的必要：前面每一篇文章最後的「看到這些字，就想到這個」表，就是為這 1 分 45 秒準備的。

2. 六大考試區塊：各考什麼、占多少、對應哪幾篇

考試指南分六區。比重是官方給的「約」數，題數是用 60 題換算（教學估算，四捨五入後加總會超過 60）：

數字怎麼看：第 3 區加第 4 區就占 41%，也就是「訓練」和「上線」。很多零基礎讀者最怕的理論（混淆矩陣、過度擬合、資料洩漏）其實散在 2.3「評估」和 3.2「訓練」裡，不是獨立一區，但不懂它們，情境題的「為什麼」就選不出來。

每一區的子項目，白話版

第 1 區（1.1、1.2）：BigQuery ML 或 Agent Platform AutoML 建分類、迴歸、預測、分群；用 BigQuery ML 做特徵工程和預測；用 BigQuery 調校 Gemini；從 Model Garden 選模型；用 Document AI、Vision、Translate 建方案；Gemini、Imagen、Veo 的應用；成本、延遲、可用性最佳化。

第 2 區（2.1～2.3）：表格、文字、影像怎麼組織；依規模與複雜度選 BigQuery SQL、Dataflow、Spark、Python；Feature Store；PII 處理；Workbench 與 Colab Enterprise 的協作與安全；用 PyTorch、sklearn、JAX 做原型；選實驗環境（Experiments、Pipelines、Kubeflow）；評估預測式與生成式方案（含 LLM 當評審）；追蹤成品、版本、血緣。

第 3 區（3.1～3.3）：選模型類型（ARIMA、DNN、LLM）與產品（AutoML、BigQuery ML、Pipelines）；部署策略；可解釋性需求；訓練資料放 Cloud Storage 或 BigQuery；用不同 SDK 訓練（自訂訓練、Kubeflow on GKE、AutoML、Tabular Workflows）；排除訓練失敗；超參數調校；調校基礎模型與何時該調；CPU／GPU／TPU；資料平行與模型平行。

第 4 區（4.1、4.2）：批次與線上推論部署到 Agent Platform、Model Garden、Cloud Run、GKE；PyTorch、XGBoost 用預建或自訂容器；Model Registry 版本；A/B 測試與金絲雀；推論前後處理；Feature Store 服務特徵；公開與私有端點；CPU／GPU／TPU／邊緣；依吞吐量擴展；訓練與服務的調校。

第 5 區（5.1、5.2）：驗證資料與模型；用 Pipelines、Managed Service for Apache Airflow、Ray 協調，從範本或自訂；訓練與服務一致的前處理；重訓政策；用 Cloud Build 做 CI/CD/CT。

第 6 區（6.1、6.2）：防資料與模型外洩、惡意提示（正規表達式、安全過濾器、Model Armor）；監控偏見；Agent Platform 上的可解釋性；Model Monitoring 持續評估；訓練與服務偏差、資料漂移、概念漂移、特徵歸因漂移；監控與評估生成式 AI。

3. 23 篇重點整理：每篇一句話＋一個考點

照系列順序，也是建議的閱讀順序。第 1～10 篇已發布可以直接點，其他篇發布後會補上連結。

第一段：基礎觀念（第 1～4 篇）

第二段：模型評估（第 5～6 篇）

第三段：訓練時會遇到的問題（第 7～9 篇）

第四段：資料處理（第 10～13 篇）

第五段：在 GCP 上做 ML（第 14～17 篇）

第六段：MLOps（第 18～21 篇）

第七段：追蹤與基礎服務（第 22～23 篇）

4. 零基礎的 8 週準備地圖

以下是建議的排程（教學假設，依每週 8～10 小時估），不是保證：

算一次給你看：時間夠不夠

8 週 × 9 小時 = 72 小時
23 篇文章 × 1.5 小時（讀＋做筆記）= 34.5 小時
動手實驗 6 次 × 3 小時 = 18 小時
官方學習路徑與範例題 = 12 小時
總複習 = 7.5 小時
合計 72 小時 ✓

數字怎麼看：動手那 18 小時不能省。考題是情境題，自己部署過一次端點，「線上 vs 批次」「流量分割」就不用背。有 Google Cloud 經驗的人可以把前 4 週壓成 2 週，從第 14 篇開始。

5. 舊題庫看到這些，現在叫什麼

這是整個系列查官方文件查出來的名稱變動，集中在這一張表。官方改名對照表和淘汰清單是來源。

考試會用哪個名字：2026 年 6 月 1 日起的指南全面用新名稱。但有些功能的淘汰公告在指南之後（Explainable AI 是 2026 年 3 月），題目裡還可能看到舊功能名。做法：名稱記兩個、概念記一個。

考試會怎麼考：全系列關鍵字總表

每篇文末都有一張「看到這些字，就想到這個」。這裡挑出跨篇最常出現的 20 組，考前最後一晚看這張就好：

答題的三個習慣

1. 先找限制條件：題目一定藏一個限制，「低延遲」「最少工程量」「最低成本」「法規要求」「不能出專案」。限制決定答案，其他描述是背景
2. 刪掉舊名字和過度工程：選項出現已停用的服務、或「自己訓練」而題目有現成 API，先刪
3. 複選題數清楚：題目說「選兩個」就是兩個，多選少選都不給分

常見問答

GCP ML 證照（PMLE）是什麼？

Google Cloud 的 Professional Machine Learning Engineer 專業級證照，考你會不會用 Google Cloud 的服務把機器學習方案從資料做到上線、監控、重訓，涵蓋傳統模型和生成式 AI。考試 2 小時、50 到 60 題單選與複選、200 美元、英文或日文、線上監考或考試中心，沒有先決條件。

PMLE 考試範圍有哪些？比重多少？

2026 年 6 月 1 日起的指南分六區：低程式碼 AI 方案約 13%、跨團隊協作管理資料與模型約 16%、把原型放大成 ML 模型約 21%、服務與擴展模型約 20%、自動化與協調 ML 管線約 18%、監控 AI 方案約 13%。第 3 加第 4 區占 41%，是訓練和上線。

PMLE 有中文版嗎？要會寫程式嗎？

只有英文和日文。官方說不直接考寫程式，但題目會有 Python 和 SQL 片段，要看得懂。系列文裡第 15、16、22 篇的程式片段就是為了這個。

零基礎考 PMLE 要準備多久？

這篇給的是 8 週、每週 8 到 10 小時的建議排程（教學假設）：前 4 週讀基礎、評估、資料處理，後 4 週讀 GCP 服務、MLOps 並動手做，最後一週用官方範例題和學習路徑總複習。官方建議的經驗是 3 年以上業界加 1 年以上 Google Cloud，有經驗可以壓到一半。

PMLE 和 Data Engineer 證照差在哪？

Data Engineer 考的是資料怎麼進來、存、處理、分析（BigQuery、Dataflow、Spark、Pub/Sub 是主角）；PMLE 考的是資料之後怎麼訓練模型、部署、監控、自動重訓。兩張有重疊（第 23 篇的資料服務），先考哪張看你的工作：偏資料管線先 Data Engineer，偏模型先 PMLE。站上有 Data Engineer 怎麼考的文章。

舊題庫還能用嗎？

能用來練情境判斷，但名稱要自己換：Vertex AI 改 Gemini Enterprise Agent Platform、AutoML Tables 改 AutoML on Agent Platform、Cloud Functions 改 Cloud Run functions、Dataproc 改 Managed Service for Apache Spark；Vertex Explainable AI 和 Feature Store Legacy 已公告停用。第 5 節有整張對照表。考試自 2026 年 6 月 1 日起用新名稱。

考試會用 Vertex AI 還是 Gemini Enterprise Agent Platform？

2026 年 6 月 1 日起的考試指南全面用 Gemini Enterprise Agent Platform（簡稱 Agent Platform），底下的功能也跟著改（Agent Platform AutoML、Agent Platform Inference、Experiments on Agent Platform）。官方考試頁明寫這次改版是為了反映這個改名。準備時兩個名字都要認得。

PMLE 證照效期多久？

專業級證照目前是 2 年，可在續證期間內更新，流程與期間以官方續證 FAQ 為準。

要先考 Associate Cloud Engineer 嗎？

不用，PMLE 沒有先決條件。但完全沒碰過 Google Cloud 的人，建議先把第 23 篇的資料服務和站上的 GCP 學習路徑看一遍，因為考題預設你知道 BigQuery、Cloud Storage、Pub/Sub 是什麼。

考試最重的是哪一區？要先讀哪裡？

第 3 區「把原型放大成 ML 模型」21% 最重，加第 4 區「服務與擴展」20%，合計 41%。但這兩區的情境題要靠第 1 到 9 篇的基礎觀念才選得出「為什麼」，所以閱讀順序還是從第 1 篇開始，有基礎的人從第 14 篇開始。

重點整理

• PMLE：2 小時、50～60 題單複選、200 美元、英日文、無先決條件；不直接考程式但要看懂 Python 與 SQL；每題約 1 分 45 秒
• 六區比重：13／16／21／20／18／13，第 3＋4 區（訓練、上線）占 41%
• 23 篇對應：基礎（1～4）、評估（5～6）、訓練問題（7～9）、資料（10～13）、GCP 做 ML（14～17）、MLOps（18～21）、追蹤與服務（22～23）
• 8 週 72 小時：讀 34.5、動手 18、官方資源 12、複習 7.5；動手不能省
• 名稱記兩個、概念記一個：Vertex AI → Gemini Enterprise Agent Platform；Explainable AI、Feature Store Legacy 停用；Cloud Functions、Composer、Dataproc 都改名
• 答題三習慣：先找限制條件、刪舊名字和過度工程、複選題數清楚

延伸閱讀

本系列全部 23 篇

• 第 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 介紹
• 第 19 篇：機器學習的 CI/CD：程式改了、資料來了，模型自動重訓
• 第 20 篇：模型上線後會變笨？Drift 與 Training-Serving Skew 監控
• 第 21 篇：可解釋 AI 是什麼？Shapley、Integrated Gradients、XRAI
• 第 22 篇：實驗怎麼追蹤？Vertex AI Experiments、Metadata、TensorBoard
• 上一篇：第 23 篇：ML 用哪個資料服務？BigQuery、Cloud Storage、Feature Store、Bigtable 怎麼選

站上相關文章

• GCP 證照 Data Engineer 怎麼考？費用、題數、考試範圍
• GCP 學習路徑 Learning Roadmap 和八大關卡
• 雲端職缺大解析：雲端工程師、架構師、SRE、DevOps、資料工程師差在哪
• 雲端架構師薪水完整指南
• 轉職 IT 新手必學知識完整指南
• 不會寫程式，可以轉職雲端架構師嗎？
• Vertex AI 核心功能 Agent Builder、Model Builder 和 Model Garden 介紹

23 篇讀完、8 週做完，你手上會有一張證照的準備和一個真的跑過的 ML 專案。如果你想有系統地從雲端基礎一路學到在 GCP 上動手做機器學習，可以看看東東的 GCP 課程，或加 LINE 聊聊你現在的狀況，一起找出最適合你的學習順序。

The post GCP ML 證照怎麼考？PMLE 考試範圍、準備地圖與 23 篇重點整理 first appeared on 東東 GCP 教學 - GCP 實戰講師.

機器學習的資料不是「存起來」就好。訓練時要一次掃幾億筆，線上預測時要在幾十毫秒內查出一個會員的特徵，照片和模型檔又是另一種東西。一個服務做不到全部，所以 Google Cloud 有一整排：BigQuery、Cloud Storage、Bigtable、Memorystore、Feature Store，再加上處理資料的 Dataflow、Spark，和直接拿來用的 AI API。

這篇把 PMLE 筆記最後一塊「基礎服務與工具」一次整理：存在哪、怎麼算、怎麼端上桌，每個服務用一句白話加一個飲料店的情境，最後給你一張「看到什麼需求就選什麼」的表。

照系列慣例先說名稱：Vertex AI 在 2026 年 4 月起改名為 Gemini Enterprise Agent Platform（簡稱 Agent Platform），Feature Store 現在叫 Feature Store on Gemini Enterprise Agent Platform；Dataproc 改叫 Managed Service for Apache Spark；Cloud Composer 改叫 Managed Service for Apache Airflow；Cloud Functions 改叫 Cloud Run functions。文末有完整對照表。

一樣用有 2,000 間分店、50 萬名會員的連鎖飲料店當例子（教學假設）：POS 每天進 300 萬筆交易、App 有會員照片、要做流失模型和推薦。

為什麼你需要知道

• 存錯地方，模型上線就慢：線上預測要在 100 毫秒內回答，去 BigQuery 查一筆要一秒以上，整個端點就卡住。這是最常見的架構錯誤
• 算錯地方，帳單爆炸：每天 300 萬筆交易用 Python 在筆記本裡跑，記憶體爆掉；全部丟 Spark 叢集又貴。考試指南 2.1 直接寫「依規模和複雜度選前處理工具」
• 重複造輪子：Vision API 一行呼叫就能 OCR，很多人還是自己訓練模型。考試 1.2 考的就是「什麼時候用現成的 API」
• 證照必考：2.1 選前處理工具與 Feature Store、3.2 訓練資料放 Cloud Storage 還是 BigQuery、4.2 用 Feature Store 服務特徵、1.2 產業 API，這篇全包

1. 先搞懂：資料有三種用法，服務跟著分三類

白話是什麼

機器學習對資料有三種動作，每種對速度的要求不一樣：

毫秒是千分之一秒。眨一次眼大約 100～150 毫秒，線上預測的預算常常就是「一次眨眼」。

比喻：飲料店的四個地方

• BigQuery 是總部的帳本：所有交易都記在這，老闆問「哪個分店的珍奶賣最好」，一句 SQL 幾秒就有答案。但要查「這一位會員剛剛買什麼」，翻帳本太慢
• Cloud Storage 是倉庫：什麼都能放，照片、影片、模型檔、備份，按件計價，一件一件拿
• Bigtable 是櫃台的會員卡機：刷卡號，毫秒內跳出這個人的資料，而且全台 2,000 家同時刷也不卡。但它只認卡號，不能問「誰買最多」
• Memorystore 是櫃台抽屜：手伸過去就拿到，最快，但空間小、放的是最常用的幾樣

Feature Store 不是第五個倉庫，它是特徵的供應站：帳本（BigQuery）算好的特徵，自動搬一份到會員卡機（Bigtable），訓練和線上預測拿到的是同一份。

來龍去脈

這些名字對應四種資料庫家族：資料倉儲（data warehouse，給分析用）、物件儲存（object storage，放檔案）、NoSQL（不用表格、按鍵查值、能橫向擴張）、快取（cache，放記憶體的暫存）。BigQuery 是 Google 把內部的 Dremel 做成服務，Bigtable 是 2006 年那篇著名論文的服務版，Cloud Storage 對應其他雲的 S3。

為什麼要學

考題給你一個情境（延遲、資料量、資料長相），問你選哪個。分不清「分析用」和「線上查詢用」，一定選錯。

2. 四個儲存服務，各自長什麼樣

BigQuery：分析與訓練的主場

官方叫它「全代管、AI 就緒的資料平台」：無伺服器（白話：你不用開機器，丟 SQL 進去就跑），儲存和運算分開，查 TB 級資料幾秒、PB 級幾分鐘。

跟機器學習有關的：

• 欄位式儲存：一次只讀用到的欄，算特徵快又便宜（第 15 篇 BigQuery ML 直接在裡面訓練）
• 串流寫入：Storage Write API；Pub/Sub 有 BigQuery 訂閱可以把訊息直接寫進表，不用 Dataflow
• Feature Store V2 的離線倉庫就是它（下一節）
• 站上有兩篇講過：BigQuery 跟資料庫差在哪、BigQuery 計費方式

不適合：單筆低延遲查詢。它是為掃全表設計的，查一筆也要排程啟動，通常以秒計。

Cloud Storage：檔案、照片、模型檔

官方：存非結構化資料的服務，資料是物件（object，白話就是一個檔案），放在值區（bucket，白話是資料夾的最上層）。耐久度 11 個 9（一年掉一個檔的機率是千億分之一）。

機器學習用它放：訓練影像（第 13 篇的 TFRecords）、模型檔、管線的中間產物（第 18 篇）、TensorBoard 日誌（第 22 篇）。考試 3.2 寫「訓練資料放在 Cloud Storage 和 BigQuery」：表格資料放 BigQuery，檔案類放 Cloud Storage。

儲存類別（官方表）是考點，差別在「多久拿一次」：

算一次給你看：照片放哪一級

飲料店 50 萬會員、每人 20 張照片、每張 2 MB（教學假設）：

50 萬 × 20 × 2 MB = 20,000,000 MB = 20 TB

訓練封膜檢查模型（第 14 篇）用過這批照片之後，接下來 90 天內不會再碰。選 Coldline（最短 90 天剛好）。如果貪便宜放 Archive，第 100 天要重訓拿出來：

• 取回費要付
• 最短 365 天，就算第 100 天刪掉，也照 365 天收費

數字怎麼看：類別越冷，每 GB 月費越低，但最短天數和取回費越高。「多久拿一次」才是選擇依據，不是「現在想省多少」。不確定就開 Autoclass，讓 Cloud Storage 依存取頻率自動換類別。

Bigtable：線上預測查特徵

官方：稀疏表，能到幾十億列、幾千欄，存 TB 到 PB，單一鍵值（single-keyed）資料的低延遲讀寫，高吞吐。

白話：一張超大的表，每列有一個 row key（列鍵，像會員卡號），只能靠這個鍵快速查，查到就是毫秒級。欄沒用到不占空間，所以叫「稀疏」。適合時間序列、購買紀錄、IoT 資料，官方明寫「機器學習應用」。

不適合：問「誰買最多」這種要掃全表的分析，那是 BigQuery 的事。

Memorystore：最快的那一層

官方：全代管的 Redis（開源的記憶體資料庫），次毫秒存取。有 Redis、Redis Cluster，和較新的 Valkey（Redis 的開源分支）三種。

白話：資料放記憶體不放硬碟，所以最快；代價是貴、容量有限（單一 Redis 執行個體到 300 GB）。機器學習用它放：推薦結果的快取、熱門會員的特徵、Dataflow 串流處理的中間資料。

四個放一起

算一次給你看：延遲預算

線上預測端點（第 17 篇）要求 100 毫秒內回應（教學假設）：

總預算：100 ms
− 網路來回：20 ms
− 模型推論：30 ms
= 剩 50 ms 給「查特徵」

BigQuery 單筆查詢：通常 1,000 ms 以上 → 超出 20 倍，不行
Bigtable 單列讀取：毫秒級（假設 5 ms）→ 可以
Memorystore：次毫秒（假設 0.5 ms）→ 可以，但要放得下

數字怎麼看：預算越緊（例如要 20 毫秒），越要往記憶體靠；資料越大（幾 TB 的會員特徵），越要用 Bigtable 而不是 Memorystore。這題的答案不是「哪個最快」，是「在預算內、放得下、最便宜」。

3. Feature Store：訓練和線上用同一份特徵

白話是什麼

Feature Store on Gemini Enterprise Agent Platform（舊名 Vertex AI Feature Store）：把算好的特徵集中管理，訓練時從 BigQuery 拿、線上預測時從 Bigtable 拿，兩邊是同一份。官方：它是 BigQuery 資料來源上面的一層中繼資料層，直接從 BigQuery 把最新特徵值搬去線上服務。

比喻

中央廚房。各分店不自己熬珍珠（各團隊不自己算「90 天來店次數」），總部熬好一鍋（BigQuery 算好），配送到每家店的保溫桶（線上倉庫）。客人拿到的和品管抽驗的是同一鍋。

來龍去脈

第 20 篇講的訓練與服務偏差（training-serving skew）最常見的原因就是：訓練時特徵用 SQL 算，上線時工程師用另一套程式重算，兩邊不一樣。Feature Store 的存在理由就是讓它們只有一個來源。另一個理由是重用：推薦模型和流失模型都要「90 天來店次數」，算一次大家用。

現在的版本（V2）長什麼樣

線上服務有兩種：

• Bigtable online serving：給 TB 級、常更新的資料，不支援嵌入（第 11 篇的向量）
• Optimized online serving：超低延遲、支援嵌入，但已在 2026 年 2 月 17 日淘汰、2027 年 2 月 17 日停用；淘汰公告要你改用 Bigtable online serving，嵌入改用 Vector Search

Vertex AI Feature Store（Legacy），也就是舊題庫寫的 featurestore／entity type 那套，同樣 2026 年 2 月 17 日淘汰、2027 年 2 月 17 日停用，官方說要搬到 V2。

算一次給你看：同步頻率

Feature view 排程從 BigQuery 同步到線上（教學假設）：

每小時同步一次 → 線上拿到的特徵最舊 60 分鐘
改成每 10 分鐘 → 最舊 10 分鐘，但同步次數 × 6，費用跟著上升

數字怎麼看：「特徵多新鮮」和「花多少錢」是對換的。流失模型看 90 天行為，一小時一次夠；要做「剛剛買了 A 就推 B」這種即時特徵，Feature Store 的排程同步不夠，要走第 4 節的 Dataflow 串流直接寫 Bigtable。

4. 處理資料：BigQuery SQL、Dataflow、Spark、Python 怎麼選

考試指南 2.1 的原話：「依規模和複雜度選前處理工具（例如 BigQuery SQL、Dataflow、Apache Spark、記憶體內的 Python 框架）」。四個工具的分界：

Dataflow

官方：統一的串流與批次處理，全代管、自動擴縮，預設恰好一次（exactly-once）處理。用途包括「串流資料的即時 ML 分析」、ETL 進 BigQuery。

白話：寫一次 Beam 程式，歷史資料用批次跑、新資料用串流跑，邏輯同一份，正好解決第 20 篇的偏差。它有範本（templates）：Pub/Sub 到 BigQuery 這種常見流程不用寫程式。

Pub/Sub 是訊息佇列（站上有教學），白話是「郵筒」：POS 把交易丟進去，誰要就來收。官方說：訊息不用處理直接進表，用 BigQuery 訂閱就好，省掉 Dataflow；要轉換、開窗、彙總才用 Dataflow。

Managed Service for Apache Spark（舊名 Dataproc）

官方：叢集 90 秒內開好，每個 vCPU 每小時 1 美分加上機器費，整合 BigQuery、Cloud Storage、Bigtable。另有 Serverless 版：不開叢集，丟批次工作或在 BigQuery Studio 筆記本開互動 session。站上有Dataproc 是什麼。

Dataflow vs Spark 怎麼選（考試愛考）：

不寫程式的：Data Fusion、Dataprep

• Cloud Data Fusion：官方說是「全代管的資料整合服務」，用開源 CDAP，拖拉點選建 ETL 管線，批次和即時都行。白話：給不想寫程式的資料工程師
• Dataprep：筆記寫的「資料清理與探索」工具，是 Trifacta（後來被 Alteryx 收購）的產品。現況：Google 的 Dataprep 產品頁已經導向 BigQuery，主控台裡以 Alteryx Designer Cloud 的名稱出現；Google 自己主推的是 BigQuery 內建的資料準備，用 Gemini 看資料給清理建議，Dataform 排程。舊題庫看到 Dataprep，知道它是第三方工具、現在有 BigQuery 內建替代

排程與協調：Managed Service for Apache Airflow

第 18 篇講過，Cloud Composer 現在叫 Managed Service for Apache Airflow，用 DAG 排整條資料流程：每天凌晨 Spark 算特徵 → BigQuery 更新 → Feature view 同步 → 觸發訓練管線。考試 5.1 把它和 Agent Platform Pipelines、Ray 並列為協調工具。

5. 現成的 AI API：先問「有沒有人做好了」

白話是什麼

預訓練 API（pre-trained API）：Google 已經用海量資料訓練好的模型，你丟資料進去拿結果，不用準備訓練資料、不用訓練。考試 1.2 寫「用產業專用 API（Document AI、Vision、Translate）建方案」。

比喻

買現成的手搖飲料基底，而不是自己種茶葉。自己種（自訂訓練）只有在現成的味道不對時才值得。

有哪些

怎麼判斷「用 API 還是自己訓練」

1. 任務是通用的（OCR、翻譯、情感）→ API
2. API 做得到但類別要客製（「封膜有沒有破」不在 Vision 的標籤裡）→ 第 14 篇的 AutoML 影像，或 Document AI 的自訂擷取器
3. 文字、影片的客製需求 → AutoML Text 和 Video 已停用，改 Gemini 調校
4. 以上都不行 → 自訂訓練（第 16 篇）

Vision 文件自己也說：掃描文件要 OCR 加表單欄位擷取，去用 Document AI。

6. 應用平台：程式跑在哪

筆記最後一塊「Cloud Functions、App Engine」，現況：

Cloud Run functions 的規格：HTTP 觸發最長 60 分鐘、16 GiB 記憶體 4 vCPU、一個執行個體可以同時接 1,000 個請求，映像只能放 Artifact Registry（Container Registry 已淘汰）。站上有Cloud Run Functions 簡介。

在 GCP 上怎麼做

飲料店的完整資料架構（2026 年 10 月）

1. 交易進來：POS → Pub/Sub。不用轉換的直接開 BigQuery 訂閱進 transactions 表；要算「最近 5 分鐘消費」這種開窗特徵的走 Dataflow 串流，直接寫 Bigtable
2. 照片進來：App 上傳到 Cloud Storage（Standard），訓練完 90 天沒碰自動轉 Coldline（開 Autoclass）
3. 算特徵：每天凌晨 BigQuery SQL 算 90 天來店次數等慢特徵，寫 member_features 表；舊的 Spark 程式搬到 Managed Service for Apache Spark，用 Managed Service for Apache Airflow 排 DAG
4. 登記特徵：member_features 登記成 Feature group，開特徵監控抓漂移（第 20 篇）
5. 訓練：從 BigQuery 取特徵（第 15、16 篇），模型檔放 Cloud Storage，登錄 Model Registry（第 22 篇）
6. 上線：Feature view 每小時同步到 Bigtable online serving，端點（第 17 篇）50 毫秒內查到特徵；推薦結果快取到 Memorystore
7. 現成的先用：發票用 Document AI、評論用 Natural Language API，不自己訓練
8. 觸發：Cloud Storage 新資料到 → Cloud Run functions → 啟動 Pipelines（第 19 篇）

改名對照

考試會怎麼考

Google Cloud Professional Machine Learning Engineer（PMLE，專業機器學習工程師） 證照，2026 年 6 月 1 日起的官方考試指南裡，這篇對應到：

看到這些字，就想到這個

六個常見陷阱

1. 線上預測去查 BigQuery：以秒計的延遲，端點會逾時。線上查特徵用 Bigtable、Memorystore，或 Feature Store 的線上服務
2. 把照片存進 BigQuery：非結構化檔案放 Cloud Storage，BigQuery 存路徑就好
3. 選 Feature Store（Legacy）的做法：entity type、featurestore 那套 2027 年 2 月停用，現在是 BigQuery 當離線倉庫的 V2
4. 串流也選 Spark：Spark 能做串流，但 Google Cloud 的標準答案是 Dataflow（Beam）；Spark 選在「已有 Spark 程式」
5. 自己訓練 OCR：Vision API 或 Document AI 一行呼叫，考試看到「最少工程量」就選 API
6. Archive 當一般儲存：最短 365 天，提早刪也照收，加取回費

練習情境（自己出的練習，不是真實考題）

飲料店 App 的推薦模型部署成線上端點，每次要讀該會員的 8 個特徵，要求 50 毫秒內回應。特徵每天在 BigQuery 用 SQL 算好。該怎麼把特徵端給端點？

判斷過程：

• 「50 毫秒」「線上」→ 不能直接查 BigQuery
• 「特徵已經在 BigQuery」→ Feature Store V2：BigQuery 表登記成 feature group，feature view 同步到 Bigtable online serving
• 訓練時從同一張 BigQuery 表拿，沒有訓練與服務偏差

每天 300 萬筆交易從 POS 進 Pub/Sub，要算每位會員「最近 5 分鐘消費金額」當即時特徵，也要把原始交易存進 BigQuery 給分析用。工程量最小的做法？

判斷過程：

• 「原始交易存 BigQuery、不用轉換」→ BigQuery 訂閱，不用寫程式
• 「最近 5 分鐘」是開窗彙總 → Dataflow 串流，算完寫 Bigtable 給線上用
• 不選 Spark：沒有既有 Spark 程式，Beam 一套程式批次串流都能用

供應商每月寄 2,000 張 PDF 發票，要自動抓出品項、金額、日期填進系統。團隊沒有 ML 工程師。該用什麼？

判斷過程：

• 「發票」「抓欄位」「沒有 ML 工程師」→ Document AI（發票是常見的預訓練解析器類型，或用 Form Parser）
• 不選 Vision API：它只給文字和座標，欄位要自己拼
• 不自己訓練：1.2 的重點就是先用產業 API

常見問答

機器學習的訓練資料該放 BigQuery 還是 Cloud Storage？

表格資料放 BigQuery，用 SQL 做特徵、直接 BigQuery ML 訓練，或讓自訂訓練讀 BigQuery。影像、音訊、影片、模型檔、TFRecords 這些檔案放 Cloud Storage，BigQuery 只存路徑。考試指南 3.2 兩個都列，分界就是「表格」和「檔案」。

Bigtable 和 BigQuery 差在哪？

BigQuery 是分析用的資料倉儲：用 SQL 掃全表，查 TB 級幾秒，但查一筆也以秒計。Bigtable 是 NoSQL 寬表：靠 row key 查，毫秒級、高吞吐、能到 PB，但不能做掃全表的分析。線上預測查特徵用 Bigtable，算特徵和訓練用 BigQuery。

Feature Store 是什麼？為什麼需要？

集中管理特徵的服務，讓訓練和線上預測拿到同一份特徵，避免訓練與服務偏差，也讓不同模型重用特徵。現在的 V2 版以 BigQuery 的表當離線倉庫，不用另外複製；把表登記成 feature group 和 feature，用 feature view 排程同步到 online store 的 Bigtable online serving 給端點查。

Vertex AI Feature Store（Legacy）還能用嗎？

2026 年 2 月 17 日淘汰，2027 年 2 月 17 日停用，官方要求搬到 Feature Store V2。同一天淘汰的還有 V2 的 Optimized online serving，改用 Bigtable online serving；要存和查嵌入向量改用 Vector Search。舊題庫寫的 featurestore、entity type 是 Legacy 的概念。

Dataflow 和 Dataproc 怎麼選？

Dataflow 是代管的 Apache Beam，批次和串流同一套程式，自動擴縮，預設恰好一次處理，看到「串流」「即時」「Pub/Sub」就選它。Dataproc 現在叫 Managed Service for Apache Spark，是代管的 Spark／Hadoop，選在「已經有 Spark 程式要搬上雲」「要用 MLlib、Hive」；不想管叢集用 Serverless 版。資料已經在 BigQuery、SQL 做得到，就用 BigQuery SQL 最省事。

資料前處理什麼時候用 Python 就好？

資料幾 GB 以內、能整個塞進記憶體、在探索階段，pandas 在筆記本裡最快。資料大到記憶體放不下，表格資料改 BigQuery SQL，要自訂邏輯或串流改 Dataflow，有 Spark 程式改 Managed Service for Apache Spark。考試指南 2.1 說的就是依規模和複雜度選。

Cloud Storage 的儲存類別怎麼選？

看多久拿一次：常讀的用 Standard（無最短天數、無取回費）；一個月一次 Nearline（最短 30 天）；一季一次 Coldline（90 天）；一年一次 Archive（365 天）。冷的類別月費低但有取回費和最短天數，提早刪也照最短天數收費。AI／ML 訓練要極高吞吐有單一區域的 Rapid 類別。不確定就開 Autoclass 自動換。

什麼時候該用預訓練 API 而不是自己訓練？

任務是通用的就用 API：OCR 和物件辨識用 Vision、情感和實體用 Natural Language、語音用 Speech-to-Text、翻譯用 Cloud Translation、表單發票用 Document AI、電商推薦和搜尋用 AI Commerce Search。類別要客製但影像為主用 AutoML 影像；文字和影片的客製改 Gemini 調校（AutoML Text、Video 已停用）；都不行才自訂訓練。

Dataprep 現在還在嗎？

Google 的 Dataprep 產品頁已導向 BigQuery，主控台裡以第三方的 Alteryx Designer Cloud 名稱出現。Google 主推的替代是 BigQuery 內建的資料準備功能：用 Gemini 看資料樣本給清理和轉換建議，由 Dataform 排程。舊題庫看到 Dataprep 要知道它不是 Google 自家服務。

Cloud Functions 改名了嗎？

改叫 Cloud Run functions：原本的 2nd gen 直接以 Cloud Run 服務部署，HTTP 觸發最長 60 分鐘、16 GiB 記憶體、一個執行個體可同時接 1,000 個請求；1st gen 還在。機器學習裡最常用在事件觸發：Cloud Storage 有新資料就啟動訓練管線。App Engine 還在，但官方建議新使用者改用 Cloud Run。

重點整理

• 三種動作三類服務：分析與訓練（BigQuery，秒級、掃全表）、線上查詢（Bigtable 毫秒、Memorystore 次毫秒）、放檔案（Cloud Storage，類別依多久拿一次選）
• 延遲預算：100 ms − 網路 20 − 推論 30 = 剩 50 ms 查特徵，BigQuery 以秒計所以不行；答案是「預算內、放得下、最便宜」
• Feature Store V2：BigQuery 當離線倉庫、feature view 同步到 Bigtable online serving；Legacy 與 Optimized serving 2027 年 2 月停用，嵌入改 Vector Search
• 前處理依規模與複雜度：Python（小）→ BigQuery SQL（表格）→ Dataflow（串流、自訂、Beam）→ Managed Service for Apache Spark（既有 Spark）；Pub/Sub 不轉換直接 BigQuery 訂閱
• 現成的先用：Vision、Natural Language、Speech-to-Text、Translation、Document AI、AI Commerce Search；客製才 AutoML 影像、Gemini 調校、自訂訓練
• 改名：Dataproc → Managed Service for Apache Spark、Composer → Managed Service for Apache Airflow、Cloud Functions → Cloud Run functions、Recommendations AI → AI Commerce Search

延伸閱讀

本系列

• 第 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 介紹
• 第 19 篇：機器學習的 CI/CD：程式改了、資料來了，模型自動重訓
• 第 20 篇：模型上線後會變笨？Drift 與 Training-Serving Skew 監控
• 第 21 篇：可解釋 AI 是什麼？Shapley、Integrated Gradients、XRAI
• 上一篇：第 22 篇：實驗怎麼追蹤？Vertex AI Experiments、Metadata、TensorBoard
• 下一篇：第 24 篇：GCP ML 證照怎麼考？PMLE 考試範圍、準備地圖與 23 篇重點整理

站上相關文章

• BigQuery 是資料庫嗎？跟資料庫差在哪
• BigQuery 計費方式完整指南
• 把資料上傳到 BigQuery 的各種方法
• Dataproc 是什麼？四大優勢與使用方法
• Cloud Pub/Sub 教學
• Cloud Run Functions 簡介與基本操作
• GCP 帳單爆炸防護指南
• GCP 學習路徑 Roadmap

資料放對地方、算對地方，模型才跑得快又不燒錢。如果你想有系統地從雲端基礎一路學到在 GCP 上動手做機器學習，可以看看東東的 GCP 課程，或加 LINE 聊聊你現在的狀況，一起找出最適合你的學習順序。

The post ML 用哪個資料服務？BigQuery、Cloud Storage、Feature Store、Bigtable 怎麼選 first appeared on 東東 GCP 教學 - GCP 實戰講師.

做機器學習不是訓練一次就結束。同一個流失模型，你會換學習率、換樹的深度、加一個新特徵，一週下來跑了幾十次。三週後老闆問：「上線那個版本是用哪份資料、哪組設定訓練的？」答不出來，就得全部重做。實驗追蹤（experiment tracking）就是幫你把每一次嘗試記下來的那本筆記。

這篇講 Google Cloud 上做這件事的三個工具，和它們各管什麼：Experiments（記錄每次訓練的設定與分數）、ML Metadata（記錄資料、模型、步驟之間的來源關係）、TensorBoard（把訓練過程畫成圖）。還會講實驗在哪裡做（筆記本環境）、以及做完之後模型放哪裡（Model Registry）。

照系列慣例，先說名稱：這些工具原本都掛在 Vertex AI 底下，Vertex AI 在 2026 年 4 月起改名為 Gemini Enterprise Agent Platform（簡稱 Agent Platform），工具名也跟著改。標題用 Vertex AI 是因為大家還是這樣搜；文中第一次出現時會附新名稱，文末有對照表。

一樣用有 2,000 間分店、50 萬名會員的連鎖飲料店當例子（教學假設）：資料團隊三個人，在調一個「會員會不會流失」的模型。

為什麼你需要知道

• 重現不了：三個人各自在筆記本裡跑，檔名叫 model_final_v3_真的最後.pkl。兩週後沒人記得 v3 的學習率是多少、用的是 9 月還是 10 月的資料。官方文件開頭就說：科學方法的關鍵是記下觀察和實驗的參數，資料科學也一樣
• 選錯模型：沒有並排比較，常常是「印象中那次比較好」。有追蹤才能把 24 次訓練排成一張表，照分數排序
• 稽核問不出來：金融、醫療會被問「這個預測是哪個模型版本做的？那個版本用什麼資料訓練？」這是 ML Metadata 的血緣（lineage）要回答的
• 證照必考：PMLE 考試指南 2.2「用筆記本做模型原型」、2.3「追蹤與執行 ML 實驗」直接點名 Experiments 和 ML Metadata；4.1 的 Model Registry 版本管理也在這篇

1. 先搞懂：實驗追蹤是什麼

白話是什麼

實驗（experiment）在機器學習裡指「換一組設定，訓練一次，看分數」。實驗追蹤就是每做一次，就把用了什麼設定、跑出什麼分數、用了哪份資料、產出哪個模型檔記下來，之後能查、能比、能重跑。

比喻

高中做化學實驗要寫實驗紀錄本：日期、藥品用量、溫度、觀察結果。沒寫的話，做出好結果也不知道怎麼做出來的。實驗追蹤就是機器學習的實驗紀錄本，差別是它由程式自動寫，不會漏。

來龍去脈

早期大家用 Excel 或檔名記：lr0.1_depth6_auc0.61.pkl。設定一多就亂掉，而且檔名記不了「用哪份資料」。開源社群陸續做出 MLflow、TensorBoard 這些工具；Google 把這套做法整合進 Vertex AI，分成 Experiments（記設定與分數）、ML Metadata（記關係）、TensorBoard（畫圖）三塊。它們底層是接在一起的：Experiments 的文件說，一個實驗就是 ML Metadata 裡的一個「情境」（context），時間序列指標則存在 TensorBoard。

為什麼要學

考試 2.3「追蹤與比較模型的成品、版本與血緣」整段都是這篇；實務上沒追蹤，模型上線出問題時，你連「要回滾到哪一版」都說不出來。

一次訓練要記四種東西

官方把一次執行（run）記的東西分成四類：

參數和超參數是第 3 篇講的：模型自己學的叫參數（權重），人設定的叫超參數。Experiments 文件裡的「parameters」指的是後者，也就是你設定的東西。AUC-PR 是第 6 篇講的指標，流失是少數類，所以看 AUC-PR 不看 AUC-ROC。

算一次給你看：為什麼靠記憶一定記不住

團隊想試：3 種學習率（0.1、0.05、0.01）× 4 種樹深度（4、6、8、10）× 2 種特徵組合（有沒有加「90 天來店次數」）。

組合數 = 3 × 4 × 2 = 24 次訓練
每次做 5 折交叉驗證（第 4 篇）：24 × 5 = 120 次模型訓練
每次要記 4 個參數 + 3 個指標 = 7 個數字
120 × 7 = 840 個數字

840 個數字，三個人分頭跑，靠 Excel 一定會漏、會打錯。這是追蹤工具存在的理由：它由訓練程式自動寫，一個不漏。數字變大的意義：組合數是相乘不是相加，多試一個維度就翻倍，所以第 16 篇的超參數調校會用 Vizier 這類演算法幫你挑，而不是全部跑過。

三次 run 並排比較

追蹤之後，比較就是一張表（教學假設）：

怎麼讀：run-02 比 run-01 多 0.05，是調超參數的功勞；run-03 又多 0.05，是加特徵的功勞（第 11 篇的特徵工程）。沒有這張表，你只知道「run-03 最好」，不知道好在哪，下次就不知道該往哪個方向試。

2. Experiments：記設定與分數

白話是什麼

Experiments on Gemini Enterprise Agent Platform（舊名 Vertex AI Experiments）：Google 代管的實驗紀錄本。你在訓練程式裡呼叫幾行 SDK，它就把參數、指標、成品記到雲端，主控台上可以搜尋、排序、勾選幾個 run 並排比較。

SDK（software development kit）是「給程式用的工具包」，這裡指 Python 套件 google-cloud-aiplatform，你 import 進來就能呼叫。

比喻

Google 試算表版的實驗紀錄本：每個人的訓練程式都會自動在同一張表加一列，老闆打開就能看全隊的進度，不用收 Excel。

概念：實驗、run、pipeline run

官方文件的三個名詞：

所以手動在筆記本裡試的，和第 19 篇自動管線跑的，可以放在同一個實驗裡比。

自動記錄（autolog）

最省事的用法是 autolog：開一個開關，SDK 自動把參數和指標記下來，不用一個一個寫。官方說底層用的是 MLflow 的自動記錄，支援 Keras、scikit-learn、XGBoost、LightGBM、PyTorch Lightning、Spark、statsmodels、Fastai、Gluon。注意它只記參數和指標，成品要自己記。

from google.cloud import aiplatform

aiplatform.init(project="drink-shop", location="asia-east1",
                experiment="churn-2026-10",
                experiment_tensorboard="projects/.../tensorboards/123")
aiplatform.autolog()

aiplatform.start_run("run-03")
# ... 這裡放你平常的 XGBoost 訓練程式，參數和指標會自動被記下 ...
aiplatform.log_params({"features": "base+visits_90d", "data_month": "2026-09"})
aiplatform.log_metrics({"test_auc_pr": 0.71})
aiplatform.end_run()

start_run 到 end_run 之間發生的事都算這個 run 的。沒指定 run 名稱的話，SDK 會自動取名，格式是「框架名稱-時間戳記-亂碼」，例如 xgboost-2026-10-24-10-30-15-a1b2c。

比較

主控台的 Experiments 頁面勾幾個 run 按「比較」，會出時間序列的疊圖和參數、指標對照表。用程式的話，aiplatform.get_experiment_df() 把整個實驗抓成一張 pandas 表（DataFrame，白話是「程式裡的試算表」），自己排序畫圖都行。

費用

官方說明：實驗 run 本身不另外收費，只付你訓練用掉的運算資源，加上底下 ML Metadata 和 TensorBoard 的儲存費（下面會算）。

3. ML Metadata：記來源與血緣

白話是什麼

Agent Platform ML Metadata（舊名 Vertex ML Metadata）：一個記「什麼東西從哪裡來、被用到哪裡去」的資料庫。Experiments 記的是「這次分數多少」，ML Metadata 記的是「這個模型是哪份資料、哪個步驟做出來的，後來又被部署到哪」。

中繼資料（metadata）白話是「關於資料的資料」：照片本身是資料，拍攝時間、地點、相機型號是中繼資料。

比喻

族譜。模型是一個人，族譜記它的爸媽（訓練資料、程式碼、超參數）、它的小孩（用它做出來的批次預測結果）。問「這個人的祖先裡有沒有 9 月那份有問題的資料？」，順著族譜往上查就知道。

來龍去脈

名字裡的 ML Metadata（MLMD） 是 TFX 團隊（第 18 篇）做的開源函式庫，Google 把它變成代管服務。它用圖（graph，白話是「點和線」）來存：

畫出來就是：資料（點）→ 訓練（點）→ 模型（點）→ 部署（點）→ 預測結果（點），箭頭是事件。這張圖就叫血緣圖（lineage graph）。

血緣能回答的問題

官方文件列的五個問題，每一個都是實際工作會被問的：

1. 某個模型是用哪份資料集訓練的？
2. 公司裡哪些模型用過某份資料集？（那份資料後來發現有錯，要全部重訓）
3. 哪次 run 做出最準的模型，用了什麼超參數？
4. 某個模型被部署到哪裡、什麼時候？
5. 某個時間點的預測，是哪個版本的模型做的？

第 8 篇資料洩漏抓到了，問題 2 讓你一次找出所有受影響的模型；第 20 篇監控發現飄移，問題 5 讓你確認當時跑的是哪一版。

結構與費用

• 所有紀錄放在一個 MetadataStore（每個專案、每個區域一個，通常全公司共用一個）
• 成品有型別（schema），例如 system.Model（記框架、版本、格式）、system.Dataset；型別用 YAML 寫，也可以自訂
• 定價：每 GiB 每月 10 美元，按 MB 比例計費。中繼資料很小，官方舉例存 10 MB 一個月 0.1 美元

跟 Knowledge Catalog 的分工

Google 另有一個管全公司資料目錄的服務 Knowledge Catalog（之前叫 Dataplex Catalog、更早叫 Data Catalog），也能看血緣。Pipelines 血緣文件的比較：

白話：ML Metadata 是 ML 團隊自己的族譜；Knowledge Catalog 是全公司的戶政系統，連 BigQuery 表從哪張表算出來都記。

4. TensorBoard：把訓練過程畫成圖

白話是什麼

Vertex AI TensorBoard（現在文件寫 TensorBoard in Gemini platform）：開源 TensorBoard 的代管版。TensorBoard 是 Google 開源的訓練視覺化工具，把訓練時每一步的 loss、準確率畫成曲線，還能看模型結構圖、權重分布、嵌入投影、影像和文字樣本。

比喻

心電圖。摘要指標是「最後血壓 120」，時間序列是「過程中每一秒的心跳」。心跳曲線才看得出中途有沒有異常：訓練 loss 一直降但驗證 loss 從第 150 輪開始往上，就是第 7 篇的過度擬合，要提前停止。

它能畫什麼

官方列的：

• 標量曲線：loss、準確率隨訓練步數變化（最常用）
• 計算圖：模型每一層怎麼接
• 直方圖：權重、偏差隨時間的分布，看有沒有爆掉或全變 0
• 嵌入投影：把第 11 篇的嵌入向量投影到 2D、3D 看聚不聚
• 樣本：影像、文字、音訊，看模型實際看到什麼

代管版多的東西：持久、可分享的連結（開源版要自己架伺服器，關掉就沒了）、跟 Experiments 整合（在主控台直接看時間序列）、企業級的權限控管。

跟 Experiments 的關係

Experiments 的時間序列指標就是存在 TensorBoard 裡，Experiments 只存一個指向它的參照。所以前面程式碼 aiplatform.init 要給 experiment_tensorboard，log_time_series_metrics() 記的每一步 loss 才有地方放。

費用：算一次給你看

定價頁寫得很清楚：2023 年 8 月起，TensorBoard 從每個使用者每月 300 美元的授權制，改成每 GiB 每月 10 美元的儲存制。舊題庫或舊文章還會看到 300 美元，現在不是。

飲料店那 24 次訓練（教學假設）：

每次 run 的 TensorBoard 日誌約 50 MB
24 次 × 50 MB = 1,200 MB
1 GiB = 1,024 MB → 1,200 ÷ 1,024 ≈ 1.17 GiB
1.17 GiB × 10 美元 = 每月約 11.7 美元

ML Metadata：每次 run 約 200 KB
24 × 200 KB = 4,800 KB ≈ 4.7 MB → 每月約 0.05 美元

數字怎麼看：中繼資料幾乎不花錢；花錢的是 TensorBoard 日誌，而且是每個月持續收。所以官方有一篇教你「刪除過期的 TensorBoard 實驗」。日誌量變大的原因通常是記太頻繁（每一步都記影像樣本）或實驗沒清，調低記錄頻率、定期清舊實驗就能壓下來。

5. 實驗在哪裡做：筆記本環境

實驗通常在 Jupyter 筆記本（notebook）裡做：一種可以一格一格執行程式、馬上看結果的工具，資料科學家的標配。Google Cloud 上有三種地方：

虛擬機（VM）白話是「雲端上租的一台電腦」；IAM 是 Google Cloud 的權限系統，決定誰能看、誰能改。

舊名稱注意

筆記裡寫的「Vertex AI Workbench」在淘汰清單有兩個舊版本已經停用：

• managed notebooks 和 user-managed notebooks：2025 年 4 月 14 日停止支援、不能再建；2026 年 3 月 30 日 managed 的全部刪除，user-managed 的轉成一般 Compute Engine VM
• 現在只有 Workbench instances 這一種

舊題庫看到「managed notebooks vs user-managed notebooks 怎麼選」，知道這是過去式就好。

協作與安全的最佳實務

考試 2.2 寫「設定筆記本環境時的協作與安全最佳實務」，從官方文件和Colab Enterprise 文件整理：

• 權限用 IAM，不要共用帳號；Colab Enterprise 可以分享給個人、Google 群組或整個網域
• 程式碼進 Git（Workbench 可以同步 GitHub），筆記本不是版本控制
• 不要把金鑰寫在筆記本裡：筆記本預設用你的身分或服務帳戶去呼叫其他服務
• 資料不出門：用第 12 篇的 VPC Service Controls 把筆記本放進服務邊界；要自己管金鑰就開 CMEK；資料在記憶體裡也要加密就開 Confidential Computing
• 省錢：閒置自動關機別關掉；正式訓練不要在筆記本裡跑，用執行器丟到自訂訓練（第 16 篇），筆記本只做試驗

6. 選好了放哪裡：Model Registry

實驗比完、選出 run-03，下一步是把它變成正式的模型版本。Model Registry on Gemini Enterprise Agent Platform（舊名 Vertex AI Model Registry）是官方說的「管理模型生命週期的中央倉庫」。

比喻

App Store 的版本列表：同一個 App 有 1.0、1.1、2.0，每版有說明、有上架狀態；使用者下載的永遠是標「最新」的那個。

它做什麼

• 一個模型底下有多個版本，每版有說明、標籤、評估指標
• 別名（alias）：給版本貼標籤，例如 default（正式用）、candidate（候選）。第 17 篇的端點部署時指別名，換版本只要把別名移過去
• 從這裡直接部署到端點、跑批次推論、看評估
• BigQuery ML 訓練的模型可以直接登錄，不用匯出再匯入（第 15 篇）
• 可以用 Knowledge Catalog 跨專案搜尋模型

Model Registry 跟 ML Metadata 是接在一起的：登錄一個版本，血緣圖就多一個 system.Model 成品，從它往上能看到是哪個 run、哪份資料。

在 GCP 上怎麼做

完整流程（2026 年 10 月）

1. 開環境：團隊協作、快速試驗用 Colab Enterprise；要 GPU 或自訂環境用 Workbench instances。開閒置自動關機
2. 建實驗：aiplatform.init(experiment="churn-2026-10", experiment_tensorboard=...)，先建一個 TensorBoard 實例讓時間序列有地方放
3. 記錄：aiplatform.autolog() 開自動記錄；成品用 aiplatform.log_params 補資料來源、特徵清單；每一步 loss 用 log_time_series_metrics
4. 比較：主控台 Experiments 頁勾選 run 比較，或 get_experiment_df() 拉成表排序
5. 看血緣：主控台 Metadata 頁點任一成品看血緣圖；要跨專案就在 Knowledge Catalog 搜
6. 登錄：選中的模型上傳到 Model Registry，別名設 candidate，第 17 篇的流量分割驗證過再改 default
7. 自動化：第 18、19 篇的管線跑的每一次都掛進同一個實驗（pipeline run），手動和自動放在一起比
8. 清理：定期刪舊的 TensorBoard 實驗，儲存費才不會每月累加

改名對照

考試會怎麼考

Google Cloud Professional Machine Learning Engineer（PMLE，專業機器學習工程師） 證照，2026 年 6 月 1 日起的官方考試指南裡，這篇對應到：

2.3 有一條「評估生成式 AI 方案，例如 LLM 當評審（LLM-as-a-judge）」：讓一個大型語言模型幫你打另一個模型輸出的分數。這屬於生成式 AI 的評估，工具是 Agent Platform Evals，概念上也是「每次改提示詞就是一次實驗，分數要記下來比」。

看到這些字，就想到這個

五個常見陷阱

1. 用 Model Monitoring 來比較實驗：Monitoring 是第 20 篇上線後的監控，比較訓練結果是 Experiments
2. 以為 Experiments 要另外付費：run 不收費，收的是 ML Metadata 和 TensorBoard 的儲存
3. 選 managed notebooks 或 user-managed notebooks：這兩種已經停用，現在是 Workbench instances
4. 血緣只想到 ML Metadata：題目說「跨專案、跨區域、包含 BigQuery 表」要選 Knowledge Catalog
5. 把正式訓練跑在筆記本裡：筆記本是試驗用的，正式訓練用自訂訓練或管線，筆記本可以用執行器把工作丟出去

練習情境（自己出的練習，不是真實考題）

飲料店三位資料科學家各自在筆記本裡調流失模型，用 XGBoost 和 scikit-learn，老闆要一張表看出哪組設定最好，而且不想大家改太多程式。該用什麼？

判斷過程：

• 「哪組設定最好」「一張表」→ Experiments，比較 run
• 「不想改太多程式」「XGBoost、scikit-learn」→ autolog（支援這兩個框架），aiplatform.autolog() 一行
• 三個人記到同一個實驗名稱，主控台就是一張表

稽核單位要求：任一筆流失預測，都要能回答「是哪一版模型做的、那版用哪份資料訓練」。模型是用 Pipelines 每週重訓。要靠什麼？

判斷過程：

• 「哪一版」「哪份資料」→ 血緣，ML Metadata（Pipelines 的成品會自動記進去）
• 版本本身在 Model Registry，預測結果表是模型的下游成品
• 如果稽核要連 BigQuery 表的來源一起看、而且跨好幾個專案，加開 Knowledge Catalog

訓練一個神經網路，驗證分數很差。工程師想看訓練過程中 loss 怎麼變、權重有沒有異常。該用什麼？

判斷過程：

• 「訓練過程中」「loss 怎麼變」「權重分布」→ TensorBoard（標量曲線、直方圖）
• 訓練 loss 降、驗證 loss 升 → 第 7 篇過度擬合，加正則化或提前停止
• 權重直方圖全擠在 0 或爆到很大 → 學習率或初始化有問題

常見問答

實驗追蹤是什麼？為什麼需要？

每訓練一次模型，就把用的設定（參數）、跑出的分數（指標）、過程曲線、用到和產出的檔案（成品）自動記下來，之後能查、能並排比較、能重跑。沒有追蹤，幾十次訓練後就不知道哪組設定最好、上線的版本是用哪份資料做的，稽核問起來答不出來。Google Cloud 上分三個工具：Experiments 記設定與分數、ML Metadata 記血緣、TensorBoard 畫曲線。

Vertex AI Experiments 是什麼？

現在叫 Experiments on Gemini Enterprise Agent Platform，Google 代管的實驗紀錄本。一個實驗是一個資料夾，裡面每個 run 是一次訓練，記參數、摘要指標、時間序列指標和成品。用 Python SDK 的 aiplatform.init 指定實驗名稱，start_run 到 end_run 之間的紀錄都屬於那個 run；autolog 可以自動記常見框架的參數和指標。主控台能勾選多個 run 並排比較。run 本身不收費。

Vertex ML Metadata 是什麼？血緣是什麼？

ML Metadata 是記「什麼東西從哪來、被用到哪去」的資料庫，用圖來存：成品（資料、模型）和執行（訓練、部署）是點，事件是線，情境把一次 pipeline run 或一個實驗框起來。血緣就是一個成品的所有祖先和後代：模型的訓練資料、超參數、程式碼，以及它產出的預測結果。能回答哪份資料訓練了哪個模型、哪些模型用過某份資料、某筆預測是哪一版做的。每 GiB 每月 10 美元。

TensorBoard 是什麼？跟 Experiments 差在哪？

TensorBoard 是 Google 開源的訓練視覺化工具，畫 loss 和準確率隨訓練步數變化的曲線、模型結構圖、權重直方圖、嵌入投影、樣本。Vertex AI TensorBoard 是代管版，有持久可分享的連結和權限控管。Experiments 的時間序列指標就是存在 TensorBoard 裡，所以兩者是搭配用：Experiments 看「最後分數、哪組設定」，TensorBoard 看「過程中發生什麼」。

TensorBoard 怎麼收費？

2023 年 8 月起改成按儲存量計費，每 GiB 每月 10 美元，不再是過去每個使用者每月 300 美元的授權制。24 次訓練各留 50 MB 日誌大約 1.17 GiB，每月約 11.7 美元。費用每月持續收，要定期刪過期的 TensorBoard 實驗。

Workbench 和 Colab Enterprise 怎麼選？

Colab Enterprise 完全代管、不用管機器，用 IAM 分享給同事，可以從 BigQuery 直接開筆記本，適合協作和快速試驗。Workbench instances 是 Google 預裝好 JupyterLab 和深度學習套件的虛擬機，適合要掛 GPU、要自訂 conda 環境、要用執行器排程跑筆記本、要同步 GitHub 的情況。兩者都有閒置自動關機。舊的 managed notebooks 和 user-managed notebooks 已於 2025 年 4 月停止支援。

Model Registry 是什麼？

管理模型版本的中央倉庫。一個模型底下有多個版本，可以貼別名（例如 default、candidate），從這裡直接部署到端點、跑批次推論、看評估指標。BigQuery ML 訓練的模型可以直接登錄不用匯出。登錄的版本會出現在 ML Metadata 的血緣圖裡，往上能追到是哪個 run、哪份資料。

ML Metadata 和 Knowledge Catalog 的血緣差在哪？

ML Metadata 記管線的所有輸入輸出成品，但只限單一專案、單一區域，永遠開著不用設定，跟 Pipelines、Experiments、Model Registry 整合。Knowledge Catalog 是全公司的資料目錄，跨專案、跨區域，連 BigQuery、Managed Service for Apache Airflow、Managed Service for Apache Spark 的血緣都記，要每個專案開 Data Lineage API，只記能對到正式資源名稱的成品。

筆記本環境的安全最佳實務有哪些？

權限用 IAM 分給個人或群組，不共用帳號；程式碼同步到 Git，不把筆記本當版本控制；不在筆記本裡寫金鑰，用執行身分或服務帳戶；敏感資料用 VPC Service Controls 設服務邊界、需要自管金鑰就用 CMEK、要加密記憶體就開 Confidential Computing；閒置自動關機不要關；正式訓練丟到自訂訓練或管線跑，不在筆記本裡跑。

筆記寫的 Deep Learning VMs 還在嗎？

還在，現在叫 Deep Learning VM Images，是 Compute Engine 上預裝 TensorFlow、PyTorch、CUDA 的虛擬機映像，映像免費、只付 VM 錢。Workbench instances 就是在它上面再包一層代管。適合要完全控制作業系統的人；一般做實驗用 Workbench instances 或 Colab Enterprise 比較省事。

重點整理

• 實驗追蹤＝每次訓練自動記四種東西：參數（設定）、摘要指標（最後分數）、時間序列指標（過程曲線）、成品（用到和產出的檔案）；24 次訓練 × 5 折 × 7 個數字＝840 個數字，靠記憶一定漏
• Experiments：實驗是資料夾、run 是一次訓練、pipeline run 也能掛進來；autolog 自動記常見框架；run 不收費
• ML Metadata：成品和執行是點、事件是線、情境是圈，畫成血緣圖；回答「哪份資料訓練了哪個模型」「某筆預測是哪一版做的」；10 美元／GiB／月；跨專案用 Knowledge Catalog
• TensorBoard：訓練曲線、直方圖、嵌入投影；Experiments 的時間序列就存在這；按儲存量計費（10 美元／GiB／月），不再是 300 美元／人／月
• 筆記本：Colab Enterprise（協作、不管機器）、Workbench instances（GPU、排程、自訂環境）、Deep Learning VM Images（自己管）；managed／user-managed notebooks 已停用
• Model Registry：版本、別名、直接部署；BigQuery ML 模型可直接登錄；跟血緣圖相連

延伸閱讀

本系列

• 第 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 介紹
• 第 19 篇：機器學習的 CI/CD：程式改了、資料來了，模型自動重訓
• 第 20 篇：模型上線後會變笨？Drift 與 Training-Serving Skew 監控
• 上一篇：第 21 篇：可解釋 AI 是什麼？Shapley、Integrated Gradients、XRAI
• 下一篇：第 23 篇：ML 用哪個資料服務？BigQuery、Cloud Storage、Feature Store、Bigtable 怎麼選

站上相關文章

• Vertex AI 核心功能 Agent Builder、Model Builder 和 Model Garden 介紹
• 如何在 GCP 建立含 GPU 的 AI 開發環境
• BigQuery 是資料庫嗎？跟資料庫差在哪
• End-to-end Training 是什麼
• GCP 帳單爆炸防護指南
• GCP 學習路徑 Roadmap

實驗有記下來，模型才不只是「印象中那次比較好」，而是說得出為什麼好、用什麼做的。如果你想有系統地從雲端基礎一路學到在 GCP 上動手做機器學習，可以看看東東的 GCP 課程，或加 LINE 聊聊你現在的狀況，一起找出最適合你的學習順序。

The post 實驗怎麼追蹤？Vertex AI Experiments、Metadata、TensorBoard first appeared on 東東 GCP 教學 - GCP 實戰講師.

模型說 M002 會流失、說這張封膜有問題，為什麼？ 老闆問、客戶問、法規問，你答不出來，模型就只是一個黑盒子。可解釋 AI 就是打開黑盒子的工具：它不改模型，而是算出「這次預測，每個特徵各出了多少力」。

這篇有一個重要的現況：Google 的 Vertex Explainable AI 已在 2026 年 3 月 16 日淘汰，2027 年 3 月 16 日停用。概念和方法沒變（考試還是考），但工具要換成 SHAP、LIME 這類開源套件，或 BigQuery ML 內建的解釋函數。文末會整理。

一樣用有 2,000 間分店、50 萬名會員的連鎖飲料店當例子（教學假設）：流失模型（表格）和封膜檢查模型（影像）。

為什麼你需要知道

• 法規和信任：金融、醫療、保險的模型，被拒絕的人有權知道原因。BigQuery 的可解釋 AI 文件說，特徵歸因可以用來「確認模型行為符合預期、找出偏見、改進模型和訓練資料」
• 除錯：Vertex Explainable AI 總覽說，特徵歸因能抓到「標準評估方法通常會漏掉的資料問題」。第 8 篇的資料洩漏，常常是看到某個特徵貢獻大到不合理才發現的
• 監控要用：第 20 篇的特徵歸因漂移、偏見監控，底層就是這篇的方法
• 證照必考：PMLE 考試指南 6.1「Agent Platform 上的模型可解釋性」；3.1「依可解釋性需求選建模技術」；6.1「監控偏見」。筆記裡的採樣 Shapley、整合梯度、XRAI 三個名詞全在這篇

先搞懂：可解釋 AI 是什麼

白話是什麼

可解釋 AI（Explainable AI，XAI）：讓人看懂模型為什麼做出某個預測的方法。最主要的做法是特徵歸因（feature attribution）：算出每個特徵對這次預測的貢獻值，有正有負，加起來等於預測值和基準值的差。

比喻

一碗牛肉麵好吃，到底是湯、麵、肉、還是辣油的功勞？特徵歸因就是「給每樣材料打分數」：湯 +4、肉 +3、麵 +1、辣油 −1，加起來是這碗麵比「平均水準」好吃多少。

兩種解釋：局部和全域

BigQuery 的文件分得很清楚：

來龍去脈

模型越強越像黑盒子：線性迴歸（第 2 篇）的權重一看就懂，但 XGBoost 幾百棵樹、神經網路幾百萬個參數，沒人看得懂。2017 年前後，SHAP、Integrated Gradients 這些方法陸續出來，Google 把它們整合進 Vertex AI 叫 Vertex Explainable AI。現在 Google 把它淘汰，建議回頭用開源的 SHAP 和 LIME，BigQuery ML 則把解釋功能內建在 SQL 函數裡。

為什麼要學

考試 3.1 有一條「依可解釋性需求選建模技術」：題目說「法規要求能解釋每筆決定」，答案可能是選線性模型、樹模型這種本身就可解釋的，或是用特徵歸因。分不清就選錯。

1. Shapley 值：公平分功勞的數學

白話是什麼

Shapley 值（Shapley value）：把每個特徵當成一個「玩家」，算它在所有可能的合作組合裡平均貢獻多少，當作它的功勞。Vertex Explainable AI 文件說，三種特徵歸因方法都是以 Shapley 值為基礎，它來自合作賽局理論（cooperative game theory），專門處理「一群人一起做出一個結果，功勞怎麼分」。

算一次給你看：兩個員工分獎金

飲料店兩位員工 A、B，單獨做一天業績 A 是 10 杯、B 是 20 杯，一起做是 40 杯（有合作效應）。獎金怎麼分才公平？

Shapley 的算法：考慮每種加入順序，看每個人「加入時多帶來多少」：

順序 1：A 先來，B 後來
  A 加入：0 → 10，帶來 10
  B 加入：10 → 40，帶來 30

順序 2：B 先來，A 後來
  B 加入：0 → 20，帶來 20
  A 加入：20 → 40，帶來 20

A 的 Shapley 值 = (10 + 20) ÷ 2 = 15
B 的 Shapley 值 = (30 + 20) ÷ 2 = 25
15 + 25 = 40 ✓（功勞加起來等於總業績）

數字怎麼看：

• A 單獨只做 10，但分到 15，因為他跟 B 合作時貢獻更大。這就是 Shapley 值的優點：考慮了交互作用（第 11 篇的特徵交叉）
• 功勞一定加總等於結果，這是它被選為特徵歸因標準的原因

套到模型：每個「玩家」是一個特徵，「業績」是預測值減掉基準值。

線性模型的 Shapley 值：直接算

BigQuery 的文件給了一個簡單的公式：線性和邏輯迴歸的 Shapley 值＝模型權重 × 標準化後的特徵值（權重是用標準化特徵訓練出來的）。

流失模型（邏輯迴歸，第 15 篇）的權重和會員 M002 的標準化特徵值（教學假設）：

標準化是第 10 篇講的：減平均、除以標準差，0 代表「平均的會員」。

怎麼讀：

• 基準是「平均的會員」，M002 比平均多了 +2.4 的流失分數（這是進 sigmoid 之前的分數，第 2 篇）
• +1.6 來自「太久沒來」，+0.9 來自「來得少」，客單價高一點點反而讓她稍微不像會流失（−0.1）
• 正負號是方向，絕對值是力道。給客服看就是：「M002 已經 75 天沒來，是主因」

特徵多了怎麼辦：Sampled Shapley

兩個玩家只有 2 種順序，10 個特徵有 10! ＝ 3,628,800 種順序，20 個特徵算不完。Sampled Shapley（採樣 Shapley）：隨機抽一些順序來算，用平均值估計真正的 Shapley 值。

官方設定裡的 path count（路徑數）就是「抽幾條順序」，範圍 1 到 50：越多近似誤差越小，但越慢越貴。

適合誰：官方說 Sampled Shapley 適合不可微分的模型，例如樹的集成（XGBoost、隨機森林）和 AutoML 表格模型（它是樹和神經網路的混合集成）。不可微分白話是「輸出對輸入沒有平滑的斜率」，樹模型是一堆 if-else，就是這種。

2. Integrated Gradients：沿著一條路累積斜率

白話是什麼

Integrated Gradients（整合梯度，IG）：從一個基準輸入（例如全黑的圖、或全是中位數的表格）慢慢變成實際輸入，沿路每一步算「預測對每個特徵的斜率」（梯度），把斜率累積起來，就是每個特徵的貢獻。

比喻

把一張照片的亮度從全黑慢慢調到正常，看模型的「貓」分數在哪些像素變亮時跳最多，那些像素就是模型認貓的依據。官方文件的說法：想像一個滑桿，把所有像素往黑色縮放。

來龍去脈

官方描述的步驟：

1. 在縮放參數的不同區間算梯度，區間大小用高斯求積法（一種數值積分技巧）決定
2. 用加權平均近似積分
3. 平均梯度逐元素乘上原始輸入

梯度是第 3 篇講過的「該往哪調、調多少」，神經網路訓練本來就在算它，所以 IG 對神經網路特別自然。

適合誰

可微分的模型：神經網路（TensorFlow、PyTorch）。表格和影像都能用。設定裡有 step count（步數），越多越準越慢，跟 Sampled Shapley 的路徑數是同樣的取捨。

基準值很重要

兩種方法都要一個基準（baseline）：「沒有資訊」的輸入長什麼樣。官方說沒指定就用全零（影像是全黑）。但表格資料的全零常常不合理（客單價 0 元？），官方建議選有意義的基準，例如文件裡的腳踏車例子用「騎乘時間的中位數」。基準選錯，歸因的數字會跟著歪。

3. XRAI：影像看區域，不看像素

白話是什麼

XRAI：IG 算出來的是每個像素的貢獻，很碎、人看不懂。XRAI 把影像先切成一塊一塊的區域，把區域內像素的貢獻加總，排出「哪幾塊最重要」。

比喻

IG 像拿著放大鏡看每一顆沙子，XRAI 像退後一步看「這片沙灘的哪一區」。

官方的三步

1. 像素級歸因：用 IG，而且用黑色和白色兩種基準各算一次
2. 過度分割：用 Felzenszwalb 的圖論方法把影像切成很多小區塊（跟歸因無關，獨立做）
3. 選區域：把每個區塊裡的像素歸因加總算密度，排序，從最正的排到最不正的

輸出是一張疊在原圖上的熱圖，標出模型「看哪裡」。封膜檢查模型判「有問題」，XRAI 會標出封膜邊緣那一圈。如果它標的是杯子上的 logo，就知道模型學歪了（第 8 篇的洩漏：也許有問題的那批照片都是某家分店拍的）。

適合誰

影像，而且官方說特別適合自然影像（照片）。表格資料不適用。

三種方法一張表

4. 範例式解釋：找最像的訓練樣本

Vertex Explainable AI 還有第二類：範例式解釋（example-based explanations）。做法是用最近鄰搜尋，從訓練集找出跟這筆輸入最像的幾個樣本。邏輯是「相似的輸入應該有相似的預測」。

官方列的四個用途：

• 改進資料或模型：鳥被判成飛機，找出最像的訓練樣本，發現全是飛機的黑色剪影 → 要多加鳥的剪影；如果最像的都是鳥卻還判錯 → 模型太簡單，要加層
• 解讀新類型的資料：訓練時只有鳥和飛機，上線遇到無人機，看它最像哪些已標記的樣本
• 找異常值：跟所有訓練資料都不像的，就是離群值。神經網路對錯誤常常很有信心，這招能抓出來
• 主動學習：最像的樣本一半是感冒一半是流感，代表這筆很難判，值得送給醫生標記

限制：只支援能輸出嵌入（embedding，第 11 篇）的 TensorFlow 模型，樹模型、PyTorch、XGBoost 不支援。

5. 淘汰之後怎麼辦：SHAP、LIME、BigQuery ML

Vertex Explainable AI 的時程

官方淘汰清單：2026 年 3 月 16 日起不再加新功能，2027 年 3 月 16 日完全停用、API 不再提供。替代方案官方點名：SHAP 和 LIME。

SHAP

SHAP（SHapley Additive exPlanations）：開源 Python 套件，Shapley 值的工業級實作。對樹模型有 Tree SHAP（算精確的 Shapley 值，不用抽樣），對任何模型有 Kernel SHAP（抽樣近似），對神經網路也有對應的版本。第 20 篇 Model Monitoring v2 的特徵歸因用的就是 SHAP 值。

LIME

LIME（Local Interpretable Model-agnostic Explanations）：開源套件，不管模型是什麼（model-agnostic），只要它能吐出機率就能解釋。做法是在這筆資料附近製造很多擾動過的樣本，用一個簡單的線性模型去「局部模仿」黑盒子，線性模型的權重就是解釋。支援文字、表格、影像。官方範例：把「Host」和「NNTP」兩個字拿掉，分類器判「無神論」的機率從 0.58 降到 0.31。

BigQuery ML：解釋內建在 SQL 裡

BigQuery ML 的解釋功能不受淘汰影響，文件列的方法：

第 15 篇示範過 ML.EXPLAIN_PREDICT 的 top_k_features，訓練時開 enable_global_explain = TRUE 才能用 ML.GLOBAL_EXPLAIN。

本身就可解釋的模型

考試 3.1「依可解釋性需求選建模技術」的另一個答案：直接選看得懂的模型。

法規嚴、解釋比準確度重要 → 前兩種；要準又要解釋 → 後兩種加特徵歸因。

在 GCP 上怎麼做

現在（2026 年 10 月）的建議路線

1. 表格模型在 BigQuery ML：訓練時 enable_global_explain = TRUE，用 ML.EXPLAIN_PREDICT 看單筆、ML.GLOBAL_EXPLAIN 看整體，最省事
2. 自訂訓練的模型：在訓練或推論程式裡裝 shap（樹模型用 TreeExplainer，神經網路用 DeepExplainer 或 GradientExplainer），把歸因跟預測一起存到 BigQuery，方便第 20 篇的監控和第 22 篇的追蹤
3. 影像模型：SHAP 有影像的解釋器，或用開源的 XRAI 實作（Google 的 saliency 套件），輸出熱圖
4. 還在用 Vertex Explainable AI 的：2027 年 3 月前遷移。Model Registry 裡模型的 explanation 設定（方法、path count、基準）要改成在程式裡做
5. Model Monitoring v2 的特徵歸因目標用 SHAP，第 20 篇講過

基準值怎麼選

• 表格：用訓練資料的中位數或平均當基準，代表「一個典型的會員」
• 影像：黑圖是預設，XRAI 黑白各算一次
• 基準不同，歸因的絕對值會不同，比較歸因時要用同一個基準

改名對照

考試會怎麼考

Google Cloud Professional Machine Learning Engineer（PMLE，專業機器學習工程師） 證照，2026 年 6 月 1 日起的官方考試指南裡，這篇的內容對應到：

考試指南寫的還是「Agent Platform 上的模型可解釋性」，淘汰公告是 2026 年 3 月、指南是 6 月，題目可能還會出現舊功能的名字。方法名稱（Sampled Shapley、Integrated Gradients、XRAI）和適用情境是重點，不會變。

看到這些字，就想到這個

六個常見陷阱

1. 樹模型選 Integrated Gradients：IG 要可微分，樹模型用 Sampled Shapley（或 Tree SHAP）
2. 表格資料選 XRAI：XRAI 只給影像
3. 用全零當表格的基準：客單價 0 元不是「典型會員」，歸因會歪
4. 把歸因當因果：歸因是「模型怎麼想」，不是「世界怎麼運作」。模型看重「城市」可能是訓練資料的偏見
5. 以為解釋功能都沒了：淘汰的是 Vertex Explainable AI 這個服務，方法還在，SHAP 和 BigQuery ML 都能做
6. path count 設 50 跑正式推論：每筆預測都要抽 50 條路徑，延遲和費用暴增，線上用小一點、離線分析再開大

練習情境（自己出的練習，不是真實考題）

飲料店的流失模型是 XGBoost，客服部門要求每一筆「會流失」的判斷都要附三個主要原因。應該怎麼做？

判斷過程：

• 「XGBoost」「每一筆」→ 局部解釋，樹模型用 Sampled Shapley（或 SHAP 的 Tree SHAP）
• 在 BigQuery ML 的話，ML.EXPLAIN_PREDICT 加 top_k_features = 3
• 自訂訓練的話，推論程式裡用 shap.TreeExplainer，把前三名存進結果表

封膜檢查模型（神經網路）把一批正常的杯子判成有問題。工程師想知道模型到底在看照片的哪裡。應該用什麼？

判斷過程：

• 「影像」「看哪裡」→ XRAI（區域熱圖）；如果要到像素級細節用 Integrated Gradients
• 熱圖標在 logo 而不是封膜 → 訓練資料有洩漏，回頭查（第 8 篇）
• 也可以用範例式解釋找出最像的訓練照片，看是不是某家分店的拍法特殊

保險公司要用機器學習審核理賠，法規要求每個拒絕都能用人看得懂的規則解釋，而且模型要能被稽核。該怎麼選模型？

判斷過程：

• 「人看得懂的規則」「稽核」→ 3.1 的可解釋性需求，優先選本身可解釋的模型：邏輯迴歸（權重直接讀）或單棵決策樹（規則一路看）
• 準確度不夠才升級到樹集成＋SHAP，但要能證明歸因方法
• 敏感特徵（年齡、性別）的歸因要監控（6.1 偏見）

常見問答

可解釋 AI 是什麼？

讓人看懂模型為什麼做出某個預測的方法，主要做法是特徵歸因：算出每個特徵對這次預測的貢獻值，有正有負，加起來等於預測值和基準值的差。分局部解釋（這一筆每個特徵貢獻多少）和全域解釋（模型整體最看重什麼）。用途是確認模型行為合理、找偏見、除錯、改進資料，也是法規要求的解釋依據。

Shapley 值是什麼？

來自合作賽局理論的分功勞方法：把每個特徵當玩家，算它在所有加入順序裡平均帶來多少增量，當作它的貢獻。好處是考慮交互作用，而且所有特徵的貢獻加總一定等於結果。兩位員工單獨做 10 和 20 杯、合作做 40 杯，Shapley 值是 15 和 25。線性模型的 Shapley 值等於權重乘標準化後的特徵值。

Sampled Shapley、Integrated Gradients、XRAI 怎麼選？

Sampled Shapley 抽樣估計 Shapley 值，適合不可微分的模型：樹集成（XGBoost、隨機森林）、AutoML 表格。Integrated Gradients 從基準到輸入累積梯度，適合可微分的神經網路，表格和影像都能用。XRAI 在 IG 之上做區域分割，只適合影像，輸出哪一區最重要的熱圖。三種都以 Shapley 值為基礎。

基準值（baseline）是什麼？為什麼重要？

「沒有資訊」的輸入長什麼樣，歸因算的是「從基準變成實際輸入，每個特徵帶來多少變化」。預設是全零（影像是全黑），但表格資料全零常不合理（客單價 0 元），官方建議選有意義的基準，例如中位數。基準不同歸因的絕對值不同，比較時要用同一個基準。

什麼是範例式解釋？

用最近鄰搜尋從訓練集找出跟這筆輸入最像的幾個樣本，邏輯是相似輸入應有相似預測。用途：找出模型判錯的原因（最像的樣本都是另一類代表資料不夠）、解讀訓練時沒見過的新類型資料、找異常值、挑出值得人工標記的困難樣本。只支援能輸出嵌入的 TensorFlow 模型。

Vertex Explainable AI 淘汰了，還能怎麼做解釋？

Vertex Explainable AI 2026 年 3 月 16 日淘汰、2027 年 3 月 16 日停用。官方建議改用開源的 SHAP（樹模型有精確的 Tree SHAP，任何模型有 Kernel SHAP）和 LIME（不管模型是什麼，在資料附近用線性模型局部模仿）。BigQuery ML 的 ML.EXPLAIN_PREDICT、ML.GLOBAL_EXPLAIN、ML.FEATURE_IMPORTANCE 不受影響。Model Monitoring v2 的特徵歸因也是用 SHAP。

BigQuery ML 怎麼做解釋？

線性和邏輯迴歸用 Shapley 值（權重乘標準化值），另有標準誤和 p 值；提升樹和隨機森林用 Tree SHAP（精確）或近似特徵貢獻（更快），還有 Gini 重要性；ARIMA_PLUS 用 ML.EXPLAIN_FORECAST 拆趨勢季節假日。局部用 ML.EXPLAIN_PREDICT，全域用 ML.GLOBAL_EXPLAIN（訓練時要開 enable_global_explain）和 ML.FEATURE_IMPORTANCE。

法規要求模型能解釋，該怎麼選模型？

考試指南 3.1 的「依可解釋性需求選建模技術」。解釋比準確度重要時，直接選本身可解釋的模型：邏輯迴歸的權重直接讀，單棵決策樹的規則一路看。要準又要解釋，用樹集成或神經網路加特徵歸因（SHAP、IG），但要能說明方法。敏感特徵的歸因要監控有沒有偏見。

特徵歸因可以當成因果關係嗎？

不行。歸因說的是「模型怎麼想」，不是「世界怎麼運作」。模型看重「城市」可能只是訓練資料裡某個城市的流失率剛好高。歸因大到不合理反而是警訊：可能是資料洩漏（答案混進特徵），或模型學到了偏見。

path count 和 step count 要設多少？

Sampled Shapley 的 path count 是抽幾條順序，1 到 50；Integrated Gradients 的 step count 是沿路算幾步。越多近似誤差越小但越慢越貴。線上推論每筆都要算，設小一點顧延遲；離線分析或除錯再開大。

重點整理

• 可解釋 AI＝特徵歸因：每個特徵對這次預測的貢獻，加總等於預測值減基準值；局部（這一筆）vs 全域（整體）
• Shapley 值：合作賽局分功勞，考慮所有加入順序的平均增量，考慮交互作用、加總等於結果；線性模型＝權重 × 標準化值
• 三種方法：Sampled Shapley（不可微分：樹集成、AutoML 表格）、Integrated Gradients（可微分：神經網路，表格與影像）、XRAI（影像區域熱圖）；旋鈕 path count／step count；基準值要選有意義的
• 範例式解釋：最近鄰找最像的訓練樣本，除錯、新資料、異常值、主動學習；只支援 TensorFlow 嵌入
• Vertex Explainable AI 2027 年 3 月停用：改用 SHAP（Tree SHAP）、LIME；BigQuery ML 的 ML.EXPLAIN_PREDICT、ML.GLOBAL_EXPLAIN 不受影響
• 選模型：法規要解釋 → 線性、單棵樹；要準 → 集成或神經網路＋歸因。歸因不是因果

延伸閱讀

本系列

• 第 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 介紹
• 第 19 篇：機器學習的 CI/CD：程式改了、資料來了，模型自動重訓
• 上一篇：第 20 篇：模型上線後會變笨？Drift 與 Training-Serving Skew 監控
• 下一篇：第 22 篇：實驗怎麼追蹤？Vertex AI Experiments、Metadata、TensorBoard

站上相關文章

• BigQuery 是資料庫嗎？跟資料庫差在哪
• Vertex AI 核心功能 Agent Builder、Model Builder 和 Model Garden 介紹
• End-to-end Training 是什麼
• GCP Organization Policy 完全攻略
• 不會寫程式，可以轉職雲端架構師嗎？
• GCP 學習路徑 Roadmap

模型說得出「為什麼」，才能被信任、被稽核、被改好。如果你想有系統地從雲端基礎一路學到在 GCP 上動手做機器學習，可以看看東東的 GCP 課程，或加 LINE 聊聊你現在的狀況，一起找出最適合你的學習順序。

The post 可解釋 AI 是什麼？Shapley、Integrated Gradients、XRAI first appeared on 東東 GCP 教學 - GCP 實戰講師.

前兩篇把模型做成管線、自動重訓、自動上線。但有一件事還沒處理：模型上線之後，怎麼知道它還準不準？ 沒人盯，模型會在你不知道的情況下慢慢變笨，推薦越來越不準、流失名單越來越離譜，等到老闆問才發現。

一樣用有 2,000 間分店、50 萬名會員的連鎖飲料店當例子（教學假設）：會員流失模型和推薦模型都上線了，這篇講怎麼監控它們。

為什麼你需要知道

• Google 自己的例子：Model Monitoring 總覽說，預測客戶終身價值的模型，客戶習慣一變，當初用來訓練的特徵可能就不再適用。這種資料的偏移叫漂移
• 等級 0 的致命傷：第 18 篇講 MLOps 等級 0 時，官方列的問題之一就是「沒有主動監控模型效能」。模型壞了沒人知道，是最常見的事故
• 監控是重訓的觸發器：第 19 篇的「效能下降就重訓」「漂移就重訓」，靠的就是這篇的警報
• 證照必考：PMLE 考試指南第 6 區「監控 AI 方案」佔 13%，6.2 直接寫「設定和使用 Model Monitoring 建立正式模型的持續評估指標」「監控常見問題（訓練／服務偏差、資料漂移、概念漂移、特徵歸因漂移）」；6.1 的「監控偏見」也在這篇

先搞懂：模型變笨的四種方式

白話是什麼

模型是用過去的資料學出來的規則。世界一變，規則就不準。官方和考試指南把「變」分成四種：

另外還有預測漂移（prediction drift）：模型輸出的分布變了，例如判「會流失」的比例從 5% 跳到 30%。它是結果，前四種是原因。

比喻

流感快篩試劑：

• 偏差：試劑是用成年人的樣本校正的，結果拿去給嬰兒用（訓練和上線的對象不同）
• 資料漂移：今年流行的病毒株變了，試劑對新株不敏感（輸入資料變了）
• 概念漂移：以前「發燒」幾乎等於流感，現在很多發燒是別的病（症狀和疾病的關係變了）

來龍去脈

Google 的機器學習規則對訓練／服務偏差的定義：「訓練時的表現和服務時的表現之間的差異」，原因有兩種：

1. 訓練和服務的管線處理資料的方式不一樣
2. 訓練和服務之間，資料本身變了

第 1 種是工程問題（第 10、15 篇講的前處理不一致），第 2 種就是漂移。Model Monitoring 主要抓第 2 種。

為什麼要學

考試 6.2 把這四個詞並列，題目會描述一個症狀問你「這是哪一種、該怎麼辦」。認得出來，才知道該修程式（偏差）、該重訓（漂移）、還是該重新定義問題（概念漂移）。

1. 偏差的第一種原因：訓練和上線的處理不一樣

這一種監控抓不到，因為資料看起來「正常」，只是單位、編碼、順序不一樣。要在設計時就防：

飲料店那個「元 vs 百元」的錯，上線第一天流失模型就會把所有人判成「會流失」，監控會看到預測漂移（判流失的比例暴增），但根本原因要回去查管線。

2. Model Monitoring 怎麼量「變了多少」

白話是什麼

Model Monitoring（Vertex AI Model Monitoring，現在叫 Model Monitoring on Gemini Enterprise Agent Platform）：Google 的服務，定期把上線時收到的請求拿來跟基準比，算一個「差多少」的分數，超過門檻就通知你。

兩個版本

官方總覽說有兩個版本：

v1 不用遷移，兩版可以並行。筆記裡的「Vertex AI Model Monitoring 監測 Prediction Drift／Feature Drift／Training-Serving Skew」對應的是 v1 的偏差與漂移，加上 v2 的輸出漂移。

v1 的流程

官方說明：

1. 模型部署到端點、開啟監控後，每一筆推論請求記錄到 BigQuery 表
2. 依取樣率抽一部分來分析（省錢）
3. 每個監控視窗（預設 24 小時，最小 1 小時）算一次最近請求的特徵分布
4. 跟基準分布比：
   • 偏差偵測的基準＝訓練資料的分布（所以要提供訓練資料的 BigQuery 或 Cloud Storage 路徑）
   • 漂移偵測的基準＝過去在上線環境看到的分布（沒有訓練資料也能用）
5. 算距離分數：類別特徵用 L-infinity 距離，數值特徵用 Jensen-Shannon 散度
6. 分數超過警報門檻（預設每個特徵 0.3，可各自設）→ 寄 email、寫 Cloud Logging、送 Cloud Monitoring 的通知管道（PagerDuty、Slack、Pub/Sub）
7. Pub/Sub 接第 19 篇的 Cloud Run 函式 → 自動重訓

分布怎麼算：類別特徵數每個值的比例；數值特徵把範圍切成等寬區間、數每個區間的比例。基準在建監控工作時算一次，之後只有更新訓練資料才重算。自訂模型要給分析結構描述（schema），沒給的話監控會等前 1,000 筆請求自動解析。

支援哪些模型

v1 只支援表格模型：AutoML 表格，或匯入的自訂表格模型；同一端點上的模型都要是這兩種。影像、文字模型要用別的方法（例如自己記錄預測、定期人工抽查）。

3. 算一次給你看：L-infinity 距離

L-infinity 距離：兩個分布裡，每個類別的比例差，取最大的那個。白話：找出「差最多的那一格」。

流失模型的特徵 city（城市），訓練資料的分布：

L-infinity = max(0.15, 0.00, 0.15) = 0.15
0.15 < 門檻 0.3 → 不警報

第 6 個月（高雄大舉展店）：

L-infinity = max(0.40, 0.00, 0.40) = 0.40
0.40 > 門檻 0.3 → 警報：city 這個特徵有偏差

數值特徵（客單價、天數）用 Jensen-Shannon 散度，也是 0 到 1 的分數，概念一樣：兩個分布越不像分數越高，超過門檻就警報。算法用到對數，這裡不展開。

數字怎麼看：

• 門檻 0.3 是官方預設，不是真理。重要特徵設低（0.1 就警報），本來就會波動的特徵設高
• 偏差警報不一定代表模型壞了：高雄會員變多，模型對高雄會員本來就會算，只是跟訓練時的母體不同，要看效能有沒有跟著掉
• 多個特徵同時警報，通常是上游資料管線出問題（偏差的第 1 種原因），不是世界變了

4. 門檻、視窗、取樣率：三個旋鈕

官方的「使用 Model Monitoring 的考量」列了三個可以調的東西：

飲料店的做法：推薦模型一天 100 萬次請求，取樣 10% 就有 10 萬筆，夠準又省錢；流失模型每週才跑一次批次，用 v2 監控批次推論的輸出就好。

5. 監控看不到的：概念漂移和真正的效能

問題

Model Monitoring 看的是輸入的分布。概念漂移是「輸入沒變、關係變了」，輸入分布完全正常，監控不會響。

解法：持續評估

持續評估（continuous evaluation）：等真實答案回來，算模型的真實分數。

• 流失模型今天說 M002 會流失，下個月才知道她有沒有真的沒來
• 把預測記下來（Model Monitoring 本來就記在 BigQuery），一個月後跟真實結果 JOIN，算 AUC、召回率（第 5、6 篇）
• 分數掉了，就是概念漂移或其他問題，觸發重訓或重新設計特徵

筆記裡的「持續評估（Continuous Evaluation）e.g., Mean Average Precision」就是這個概念；mAP 是物件偵測常用的指標。考試指南 6.2 寫的「用 Model Monitoring 建立持續評估指標」，v2 的做法是定期跑監控工作，把指標畫成時間序列看趨勢。

延遲標籤（delayed label）是這裡的難點：答案越晚回來，效能監控越慢。所以兩種監控要並用：輸入漂移監控早期預警，持續評估確認真的壞了。

生成式 AI 也要監控

考試 6.2 最後一條「監控、測試、評估生成式 AI 方案」：大型語言模型沒有「正確答案」可以 JOIN，常用的做法是用另一個模型當評審（LLM-as-a-judge，考試指南 2.3 點名）打分、抽樣人工審核、記錄使用者的回饋（按讚、重問）。Model Armor（第 12 篇）則是監控提示詞和回答裡的安全問題。

6. 偏見監控

考試 6.1「符合負責任 AI 實務（例如監控偏見）」。偏見（bias）是模型對某些群體系統性地不公平，例如流失模型對某個城市的會員一律判「會流失」，害他們收到更多騷擾簡訊。

做法：

• 分段評估：第 19 篇驗證關卡那一招，各群體（城市、年齡層、新舊會員）分開算指標，差太多就是警訊。TFX 的 TFMA 切片評估就是做這個
• 特徵歸因監控：v2 的「特徵歸因」目標，用 SHAP 值追蹤每個特徵的貢獻。某個敏感特徵（例如性別）的貢獻突然變大，就要查。第 21 篇可解釋 AI 會講 SHAP
• 注意：v1 的特徵歸因功能依賴 Vertex Explainable AI，而它在 2026 年 3 月 16 日淘汰、2027 年 3 月 16 日停用，官方建議改用 SHAP、LIME 這類開源工具。第 21 篇細講

在 GCP 上怎麼做

v1：端點上開監控

1. 模型（表格 AutoML 或自訂表格）部署到端點
2. 建監控工作：選偏差（要給訓練資料的 BigQuery 或 Cloud Storage 路徑）和／或漂移；設每個特徵的門檻（或用預設 0.3）、監控視窗、取樣率、email、通知管道
3. 自訂模型給分析結構描述，或等前 1,000 筆自動解析
4. 主控台看每個特徵的分布隨時間變化
5. 警報 → Cloud Logging → Pub/Sub → Cloud Run 函式 → 重訓管線（第 19 篇）

gcloud ai model-monitoring-jobs create \
  --region=asia-east1 \
  --endpoint=ENDPOINT_ID \
  --display-name=churn-monitor \
  --emails=ml-team@example.com \
  --feature-thresholds=city=0.2,avg_spend=0.3 \
  --monitoring-frequency=24 \
  --bigquery-uri=bq://PROJECT.drink.member_features_train

v2：模型版本上建監控器

1. 模型註冊到 Model Registry（不在 Agent Platform 上服務的模型也可以，不用上傳模型檔）
2. 建模型監控器（model monitor）綁模型版本，定義 schema（AutoML 自動有）
3. 設預設的監控目標（輸入漂移、輸出漂移、特徵歸因）、訓練資料集當基準、輸出位置、通知
4. 跑一次性或排程的監控工作，指標畫成時間序列
5. 預覽期間 v2 本身不收費，但 BigQuery、Cloud Storage、批次推論、Cloud Logging 照收

改名對照

考試會怎麼考

Google Cloud Professional Machine Learning Engineer（PMLE，專業機器學習工程師） 證照，2026 年 6 月 1 日起的官方考試指南裡，這篇的內容對應到：

看到這些字，就想到這個

六個常見陷阱

1. 以為輸入分布正常就沒事：概念漂移監控看不到，要持續評估
2. 沒有訓練資料卻選偏差偵測：偏差要訓練資料當基準，沒有就用漂移
3. 所有特徵都用預設 0.3：重要特徵要更敏感
4. 一有警報就重訓：先查是不是上游管線壞了（偏差第 1 種原因），重訓不會修好程式錯誤
5. 用 v1 監控影像模型：v1 只支援表格模型
6. 警報只寄 email：要接 Pub/Sub 才能自動重訓

練習情境（自己出的練習，不是真實考題）

飲料店的流失模型部署在 Agent Platform 端點三個月了，團隊有當初的訓練資料。他們想知道現在進來的會員資料是不是跟訓練時差很多，差太多要收到通知。應該怎麼設？

判斷過程：

• 「有訓練資料」「跟訓練時比」→ 偏差偵測（v1），--bigquery-uri 指向訓練資料
• 「收到通知」→ email＋Cloud Logging，之後接 Pub/Sub
• 重要特徵（距上次消費天數）門檻設低一點

推薦模型的監控三個月都沒警報，但行銷部門說推薦的點擊率從 8% 掉到 5%。問題可能是什麼？該怎麼抓？

判斷過程：

• 「輸入沒警報、效果變差」→ 概念漂移（輸入和答案的關係變了）
• 解法：持續評估，把預測和真實點擊 JOIN，定期算指標；用 v2 的排程監控工作畫趨勢
• 也檢查特徵歸因有沒有變（v2）

某天早上流失模型突然把 40% 的會員判成會流失（平常 5%），同時 avg_spend 和 visits_90d 兩個特徵一起觸發偏差警報。應該先做什麼？

判斷過程：

• 「突然」「多個特徵同時」「預測比例暴增」→ 大概率是上游資料管線壞了（單位、欄位錯），不是世界變了
• 先查管線（偏差第 1 種原因），不是重訓
• 若是真的資料變了，再走重訓

常見問答

模型上線後為什麼會變笨？

模型是用過去的資料學出來的規則，世界一變規則就不準。四種變法：訓練／服務偏差（上線資料跟訓練資料不一樣）、資料漂移（上線後輸入分布隨時間變）、概念漂移（輸入沒變但輸入和答案的關係變了）、特徵歸因漂移（重要特徵的貢獻變了）。Google 的例子是客戶習慣改變後，當初訓練用的特徵不再適用。

Training-serving skew 和 drift 差在哪？

偏差是「上線 vs 訓練」的差異，基準是訓練資料的分布，所以要提供訓練資料；漂移是「現在 vs 之前」的差異，基準是過去在上線環境看到的分布，沒有訓練資料也能用。Google 的機器學習規則補充，偏差還有一種原因是訓練和服務的管線處理資料的方式不一樣，這種要在設計時用 TRANSFORM、Feature Store 防，監控抓不到。

概念漂移是什麼？怎麼發現？

輸入資料的分布沒變，但輸入和答案之間的關係變了，例如疫情後「兩週沒來」不再代表流失。因為輸入分布正常，Model Monitoring 的偏差和漂移偵測不會響，要靠持續評估：等真實答案回來，把預測和真實結果 JOIN 算 AUC、召回率，分數掉了才知道。難點是答案常常要等很久（延遲標籤）。

Model Monitoring 怎麼算「差多少」？

v1 用 TFDV 算分布：類別特徵數每個值的比例，數值特徵切成等寬區間數比例。然後算最新分布和基準分布的距離：類別特徵用 L-infinity 距離（每格比例差取最大），數值特徵用 Jensen-Shannon 散度，都是 0 到 1。超過你設的門檻（預設每個特徵 0.3）就判定為偏差或漂移並警報。

Model Monitoring v1 和 v2 差在哪？

v1 是正式版，綁在 Agent Platform 端點上，監控線上推論輸入特徵的偏差和漂移，只支援表格模型，警報寄 email、Cloud Logging、Cloud Monitoring 通知管道。v2 是預覽版，綁在模型版本上，多了輸出推論漂移和特徵歸因（SHAP），可以監控批次推論和不在 Agent Platform 上服務的模型，用一次性或排程的監控工作把指標畫成時間序列。v1 不用遷移，兩版可並行。

警報門檻、監控視窗、取樣率要怎麼設？

門檻預設每個特徵 0.3，重要特徵設低（更敏感）、本來就會波動的設高（少誤報）。監控視窗預設 24 小時、最小 1 小時，短的反應快但樣本少噪音大。取樣率決定分析多少比例的請求，低省錢但小變化看不到；請求量大的模型取樣 10% 通常就夠。

監控警報怎麼自動觸發重訓？

v1 的警報除了 email，可以寫 Cloud Logging、送 Cloud Monitoring 的通知管道（PagerDuty、Slack、Pub/Sub）。設 Cloud Logging 的篩選條件或直接用 Pub/Sub 管道，Cloud Run 函式訂閱後啟動重訓管線，這是第 19 篇講的架構。但收到警報先確認不是上游管線壞了，再決定重訓。

影像或文字模型怎麼監控？

Model Monitoring v1 只支援表格模型。影像、文字模型可以用 v2（綁模型版本、不限端點）監控輸出分布和特徵歸因，或自己記錄預測和信心分數到 BigQuery、定期人工抽查、等真實標籤回來做持續評估。生成式 AI 則用 LLM-as-a-judge 打分、人工審核、使用者回饋。

怎麼監控模型有沒有偏見？

兩招：分段評估，把各群體（城市、年齡、新舊會員）分開算指標，差太多就是警訊，TFX 的 TFMA 切片評估做這個；特徵歸因監控，用 v2 的 SHAP 值追蹤每個特徵的貢獻，敏感特徵的貢獻突然變大就要查。考試指南 6.1 把「監控偏見」列在負責任 AI 底下。

Vertex Explainable AI 淘汰了，特徵歸因監控還能用嗎？

Vertex Explainable AI 在 2026 年 3 月 16 日淘汰、2027 年 3 月 16 日停用，官方建議改用 SHAP、LIME 等開源工具。Model Monitoring v2 的特徵歸因目標用的是 SHAP 值。第 21 篇可解釋 AI 會細講替代方案。

重點整理

• 四種變笨：偏差（上線 vs 訓練）、資料漂移（現在 vs 之前）、概念漂移（關係變了，輸入正常）、特徵歸因漂移（重要性變了）；另有預測漂移是結果
• 偏差的第 1 種原因（處理不一致）監控抓不到，靠 TRANSFORM、TFT、Feature Store、共用程式碼防
• Model Monitoring：請求記到 BigQuery → 取樣 → 每個視窗算分布 → 跟基準比（偏差＝訓練資料、漂移＝過去上線）→ 距離（類別 L-infinity、數值 Jensen-Shannon）→ 超過門檻（預設 0.3）→ email、Cloud Logging、Pub/Sub
• 算一次：城市分布差最大的那格 0.15 不警報、0.40 警報
• 三個旋鈕：門檻（敏感 vs 誤報）、視窗（快 vs 噪音）、取樣率（省錢 vs 漏）
• 概念漂移要持續評估（等真實標籤 JOIN 算指標）；生成式 AI 用 LLM-as-a-judge
• v1 GA、端點、表格；v2 預覽、模型版本、批次與外部模型、輸出漂移與 SHAP 特徵歸因；Explainable AI 2027 年停用

延伸閱讀

本系列

• 第 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 介紹
• 上一篇：第 19 篇：機器學習的 CI/CD：程式改了、資料來了，模型自動重訓
• 下一篇：第 21 篇：可解釋 AI 是什麼？Shapley、Integrated Gradients、XRAI

站上相關文章

• BigQuery 是資料庫嗎？跟資料庫差在哪
• Vertex AI 核心功能 Agent Builder、Model Builder 和 Model Garden 介紹
• GCP 9 大資訊安全威脅與因應方案
• 雲端職缺大解析：雲端工程師、架構師、SRE、DevOps、資料工程師差在哪？
• GCP 帳單爆炸防護指南
• GCP 學習路徑 Roadmap

模型上線不是結束，是開始盯著它的第一天。如果你想有系統地從雲端基礎一路學到在 GCP 上動手做機器學習，可以看看東東的 GCP 課程，或加 LINE 聊聊你現在的狀況，一起找出最適合你的學習順序。

The post 模型上線後會變笨？Drift 與 Training-Serving Skew 監控 first appeared on 東東 GCP 教學 - GCP 實戰講師.

上一篇把訓練流程做成管線（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 和 CD 是軟體界本來就有的，CT 是 ML 特有的：程式沒改，但資料變了，也要重做一次。

比喻

連鎖飲料店的總部：

• CI：研發部改了配方，先在中央廚房試做、試喝（測試），通過才印成新的配方卡（打包）
• CD：新配方卡自動發到 2,000 間分店（部署），不用總部一間一間打電話
• CT：配方沒改，但每天早上進新鮮水果，各店照既有配方重新備料（重訓）

來龍去脈：兩條不同的管線

Google 的 MLOps 架構文件特別區分兩件事：

官方原話：「要用新資料訓練新模型，執行先前部署的 CT 管線；不部署新的管線或元件。」「要部署新的管線實作，需要 CI/CD 管線。」考題常把這兩條混在一起問，分清楚就能選對。

為什麼要學

等級 2 的定義就是「CI/CD 管線自動化」。考試 5.2 寫「用 CI/CD/CT 管線部署模型」，三個字母一起考。

1. 什麼時候重訓：重訓政策

白話是什麼

重訓政策（retraining policy）：事先決定「什麼情況下重新訓練模型」。考試 5.2 第一條就是「決定適當的重訓政策」。

官方 MLOps 文件列的五種觸發：

官方補充：排程的頻率看資料模式變化多快和重訓多貴。

算一次給你看：重訓多勤才划算

推薦模型一次重訓 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）：

分支是程式碼的平行版本（開發用一條、正式用一條），合併請求是「我改好了，請審核後併進去」。可以設不同分支觸發不同的建置流程（開發分支只跑測試、主分支才部署）。

一次建置做什麼：官方的步驟

MLOps 架構文件列的 ML 管線 CI/CD 典型步驟：

1. 把版本庫複製到 Cloud Build 的工作目錄
2. 跑單元測試和整合測試（元件裡的函數對不對、整條管線接不接得起來）
3. 可選：靜態分析（Pylint 檢查程式風格和明顯錯誤）
4. 測試過了，每個管線元件各建一個容器映像檔，用 $COMMIT_SHA（這次修改的識別碼）當標籤
5. 映像檔推到 Artifact Registry
6. 把元件設定裡的映像檔網址換成新的
7. 編譯管線成 YAML（第 18 篇講的）
8. 編譯好的管線上傳到 Artifact Registry（當範本）
9. 可選：用測試參數跑一次管線當整合測試

官方的版本庫通常放：管線定義的 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 是代管的 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 函式，函式再啟動管線。這就是筆記那條的現代版。

三種做法怎麼選

4. 重訓完要不要上線：模型驗證關卡

白話是什麼

自動重訓的風險：新資料有問題、新模型比舊的差，管線照樣把它部署上去。所以 CT 管線裡一定要有模型驗證（model validation）這一步，官方 MLOps 文件把它列為等級 1 的必要元件。

比喻

新一批珍奶煮好了，先給店長試喝、跟昨天的比，比昨天好才上架。差了就倒掉，繼續賣昨天的。

驗證什麼

官方列的三件事：

1. 評估指標跟基準比：新模型的分數（第 5、6 篇的 AUC、召回率）要比目前上線的模型好，或至少不差
2. 分段表現：整體分數好，但某一群（新會員、某個城市）變差也不行。TFX 的 TFMA 切片評估（第 18 篇）就是做這個
3. 基礎設施相容：模型真的能被服務載入、回應正常（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 上怎麼做

飲料店的完整架構

1. 版本庫：GitHub 放管線程式、元件、Dockerfile、測試、cloudbuild.yaml
2. CI/CD：Cloud Build 觸發條件設「推到 main」→ 測試 → 建元件映像檔推 Artifact Registry → 編譯管線上傳範本
3. CT 觸發：
   • 流失模型：Pipelines 排程 API，每週一 06:00
   • 推薦模型：Airflow 的資料匯入 DAG 最後一步發 Pub/Sub → Cloud Run 函式啟動管線
   • 封膜模型：Model Monitoring 警報 → Cloud Logging → Pub/Sub → 重訓
4. 管線內容：驗證資料（TFDV 或自己寫）→ 訓練 → 評估並跟舊模型比→ 通過才註冊 Model Registry → 部署到端點（流量分割 10%）
5. 監控（第 20 篇）回頭觸發第 3 步

權限

Cloud Build 和 Cloud Run 函式各自用服務帳戶執行，要有啟動管線、寫 Artifact Registry、部署模型的權限。官方文件提醒，Cloud Run 函式部署時會自動用到 Cloud Storage、Cloud Build、Artifact Registry，權限要一起給。

改名對照

考試會怎麼考

Google Cloud Professional Machine Learning Engineer（PMLE，專業機器學習工程師） 證照，2026 年 6 月 1 日起的官方考試指南裡，這篇的內容對應到：

看到這些字，就想到這個

六個常見陷阱

1. 把「用新資料重訓」答成要重新部署管線：那是 CT，跑既有管線就好
2. 所有模型都每天重訓：封膜檢查這種資料不變的，靠監控觸發就好
3. 自動重訓沒有驗證關卡：壞模型直接上線
4. 只看整體 AUC：分段變差沒抓到
5. 新資料進 Cloud Storage 還用 Cloud Scheduler 輪詢：事件驅動（Eventarc）才對
6. 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 聊聊你現在的狀況，一起找出最適合你的學習順序。

The post 機器學習的 CI/CD：程式改了、資料來了，模型自動重訓 first appeared on 東東 GCP 教學 - GCP 實戰講師.

前面 17 篇把「一個模型從資料到上線」走完了。問題是：這些步驟你是手動做的。資料更新了要重訓、換了特徵要重跑、上線要再部署一次，每次都靠人記得順序、靠人按按鈕。模型一多、重訓一頻繁，就會出事。

MLOps 就是解決這件事的方法，管線（pipeline）是它的核心工具。這篇講 MLOps 是什麼、管線長什麼樣、Google Cloud 上的 Vertex AI Pipelines（現在叫 Agent Platform Pipelines）怎麼用、Kubeflow 和 TFX 這兩個框架差在哪。

一樣用有 2,000 間分店的連鎖飲料店當例子（教學假設）：會員流失模型每週要用新資料重訓一次，推薦模型每天重訓。

為什麼你需要知道

• 模型上線後會壞：Google 的 MLOps 架構文件說得很直接，模型在真實世界常常壞掉，因為環境變了、資料變了，模型沒跟著變。解法是頻繁重訓，而頻繁重訓靠手動做不到
• 手動流程的隱形成本：飲料店兩個模型，一個每週、一個每天重訓，一年要手動跑 400 多次，每次十幾個步驟。漏一步、順序錯一步，上線的就是壞模型
• 筆記裡的名稱改了：Vertex AI Pipelines 現在叫 Agent Platform Pipelines，Cloud Composer 改名 Managed Service for Apache Airflow
• 證照必考：PMLE 考試指南第 5 區「自動化與編排 ML 管線」佔 18%，5.1 要你會「驗證資料和模型」「用代管或非代管服務、從範本或自訂方案建管線（Agent Platform Pipelines、Managed Service for Apache Airflow、Ray）」；第 2.3 節也考「選實驗環境（Experiments、Pipelines、Kubeflow Pipelines）」

先搞懂：MLOps 是什麼

白話是什麼

MLOps（Machine Learning Operations）：把軟體工程界管程式的那套方法（DevOps）搬到機器學習上，讓模型的建立、測試、上線、重訓變成自動、可重複、可追蹤的流程。

DevOps 是「開發」（Development）和「維運」（Operations）合在一起的做法：程式一改，自動測試、自動部署，而不是工程師手動上傳檔案。

比喻

一間手搖飲店，老闆自己調配方、自己煮，口味靠經驗。要開到 2,000 間分店，就得把配方寫成 SOP（標準作業流程）：第一步秤糖、第二步煮茶、第三步封膜，每間店照做、品質一樣，配方改了只要更新 SOP。

MLOps 就是把「做模型」寫成 SOP，而且是機器會自己照做的 SOP。

來龍去脈：跟 DevOps 差在哪

官方文件說 ML 系統跟一般軟體有幾個不同：團隊成員不是軟體工程師（資料科學家）、要做很多實驗、測試要多測資料和模型、部署的不只是程式而是一整條會自動重訓的管線、模型會因為資料變化而衰退。

所以 MLOps 比 DevOps 多了一個 CT（持續訓練，Continuous Training）：程式沒改，但資料變了，就自動重訓。

三個成熟度等級

官方文件把 MLOps 分成三級，這是考題和實務都常用的框架：

筆記本（notebook）是在網頁上邊寫程式邊看結果的工具，例如 Agent Platform Workbench、Colab。

等級 0 的最大問題，官方點出三個：模型沒人監控品質；沒有頻繁重訓；沒有持續實驗新做法。等級 1 解決前兩個，等級 2 解決第三個。這篇講等級 1 的核心工具（管線），第 19 篇講等級 2 的 CI/CD，第 20 篇講監控。

為什麼要學

考題會描述一個團隊的現狀（「資料科學家在筆記本訓練好交給工程師」「每季手動重訓」），問你「該怎麼改善」，答案幾乎都是「建管線」。認得出這是等級 0 的症狀，就能選對。

1. 管線：把步驟串成一張圖

白話是什麼

ML 管線（ML pipeline）：把機器學習的工作流程寫成一連串的步驟，每一步做一件事（準備資料、訓練、評估、部署），步驟之間用「輸出接輸入」串起來。官方 Pipelines 簡介的定義：「一個可攜、可擴展的 MLOps 工作流程描述，由一系列叫做管線任務的步驟組成」。

比喻

工廠的生產線。原料進來，第一站洗、第二站切、第三站包裝，每一站只管自己的事，上一站的成品是下一站的原料。

兩個名詞

官方說元件有三部分：輸入（參數或成品）、輸出、邏輯（程式碼，容器化的話還包含容器映像檔）。成品（artifact）是步驟產生的東西：資料集、模型檔、評估報告。

管線是一張圖：DAG

步驟之間的依賴關係形成一張 DAG（有向無環圖）。白話：箭頭有方向（A 做完才能做 B）、不會繞圈（B 不能又回頭等 A）。

官方的例子，四個步驟：

準備資料 → 訓練模型 → 評估模型
                   └→ 部署模型

• 準備資料不依賴任何步驟，可以第一個跑（或跟別的平行）
• 訓練模型要等準備資料的輸出
• 評估和部署都只要訓練好的模型，所以可以同時跑

官方特別說：預設任務是平行跑的，有依賴才會串起來。這是管線比「照順序執行的腳本」快的原因。

為什麼要學

考試 5.1 的「建立和編排管線」就是在問這個。而且元件可以重用：飲料店的「從 BigQuery 抓資料並驗證」元件，流失模型和推薦模型都能用。

2. Vertex AI Pipelines：無伺服器地跑管線

白話是什麼

Vertex AI Pipelines（2026 年 4 月起叫 Gemini Enterprise Agent Platform Pipelines）：Google 代管的管線執行服務。你定義好管線，它負責開機器、照 DAG 跑每一步、記錄每一步的輸入輸出。官方用語是「以無伺服器的方式自動化、監控、治理 ML 系統」，無伺服器就是你不用管機器（第 14 篇）。

比喻

你寫好 SOP，Google 提供工廠和工人，照 SOP 生產，每一批都有生產紀錄。

用哪個框架寫管線

Agent Platform Pipelines 可以跑兩種框架定義的管線：Kubeflow Pipelines（KFP） 和 TensorFlow Extended（TFX）。兩個下面會分別講。

一條管線的生命週期

官方分四個階段：

任務在哪裡算：官方說任務可以用 Agent Platform 的隨需運算（底層是 Kubernetes），也可以委派給別的引擎：BigQuery、Dataflow、Managed Service for Apache Spark。例如「準備資料」那一步其實是一句 BigQuery SQL，管線只是去觸發它、等它做完。

預建元件：Google Cloud Pipeline Components

GCPC 是 Google 做好的一組 KFP 元件，官方列的功能：建資料集、匯出資料到 Cloud Storage、用 AutoML 訓練、跑自訂訓練工作、上傳模型做批次推論、建端點部署線上推論。

好處（官方列的）：

• 好除錯：直接顯示元件底下啟動的資源
• 標準成品型態：輸入輸出用統一的型態，ML Metadata 自動追蹤血緣
• 帳單標籤自動傳遞：元件啟動的資源會帶上管線的標籤，配合帳單匯出到 BigQuery 就能算出一次管線執行花多少錢
• 省成本：它直接啟動 Google Cloud 資源，不用先開一個容器在那邊空等

中繼資料和血緣

每一次執行，Agent Platform ML Metadata 會記下每一步用了什麼輸入、產出什麼成品。所以你可以回答「上線的這個模型是用哪天的資料、哪個版本的程式訓練的」。這個第 22 篇會專門講。

為什麼要學

考題看到「無伺服器」「代管」「ML 專用的管線」「追蹤成品血緣」，就是 Agent Platform Pipelines。

3. Kubeflow Pipelines：框架中立的管線

白話是什麼

Kubeflow Pipelines（KFP）：開源的管線框架，官方定義是「用容器在 Kubernetes 系統上建立和部署可攜、可擴展的 ML 工作流程的平台」。

Kubernetes 是管理大量容器的系統，站上有一篇Kubernetes 是什麼。可攜是「寫一次，換個地方也能跑」。

比喻

樂高積木。每個元件是一塊積木（一個容器），用 Python 把積木拼成管線，拼好的東西可以搬到任何支援 KFP 的地方跑。

來龍去脈

Kubeflow 原本是 Google 內部「在 Kubernetes 上跑 TensorFlow」的專案開源出來的，後來變成一整套 ML 平台，Pipelines 是其中最常用的一塊。2025 年 Kubeflow 成為 CNCF（雲端原生運算基金會）的畢業專案，代表它是業界標準等級的開源軟體。

Agent Platform Pipelines 跑的就是 KFP 格式的管線，差別是你不用自己架 Kubernetes。筆記裡的「Vertex AI Pipelines（KFP 託管服務）」就是這個意思。

怎麼寫：Python 函數就是元件

KFP 的 SDK 讓你用 Python 函數定義元件（叫 lightweight component），不用自己做容器：

from kfp import dsl

@dsl.component(packages_to_install=["google-cloud-bigquery"])
def prepare_data(project: str, out_table: str) -> str:
    # 用 SQL 從 BigQuery 整理出會員特徵表
    ...
    return out_table

@dsl.component(base_image="asia-docker.pkg.dev/vertex-ai/training/pytorch-gpu.2-4.py310:latest")
def train_model(table: str, model_dir: dsl.Output[dsl.Model]):
    # 訓練，把模型存到 model_dir.path
    ...

@dsl.pipeline(name="churn-weekly")
def churn_pipeline(project: str):
    data = prepare_data(project=project, out_table="drink.member_features")
    train_model(table=data.output)

• @dsl.component：這個函數是一個元件，可以指定要裝的套件或用哪個容器映像檔
• @dsl.pipeline：這個函數描述管線，裡面呼叫元件、把輸出接到輸入，KFP 自動算出 DAG
• 編譯成 YAML 後，用 Agent Platform 的 PipelineJob 執行

要用 Google 的服務（AutoML、自訂訓練、部署端點），直接拿 GCPC 的預建元件來接，不用自己寫。

為什麼要學

KFP 不綁框架：PyTorch、scikit-learn、XGBoost 的程式都能包成元件。飲料店的 PyTorch 推薦模型（第 16 篇）要做成管線，用 KFP。

4. TFX：TensorFlow 的全家桶管線

白話是什麼

TFX（TensorFlow Extended）：Google 用來部署正式 ML 管線的平台，專為 TensorFlow 設計，附一整套標準元件，從讀資料到部署都幫你定義好。

比喻

KFP 是樂高積木，自己拼；TFX 是模型套件（已經切好的零件＋組裝說明書），照著組就是一台完整的車，但零件是 TensorFlow 規格的。

標準元件：一條標準的管線長這樣

TFX 官方指南列的標準元件，照順序：

背後的四個函式庫

• TFDV（TensorFlow Data Validation）：StatisticsGen、SchemaGen、ExampleValidator 用的，資料驗證。筆記裡的「TFX SDK（標準化組件，TFDV）」就是這個
• TFT（TensorFlow Transform）：Transform 用的，前處理寫一次，訓練和服務都套用，解決訓練／服務偏差
• TFMA（TensorFlow Model Analysis）：Evaluator 用的，可以切片評估（例如只看台北的會員、只看新會員），找出整體分數好但某群人很差的情況
• MLMD（ML Metadata）：記錄每一步的成品和血緣

要搭配什麼

官方說 TFX 的資料處理靠 Apache Beam（Dataflow 跑的就是 Beam，第 23 篇），編排器可以選 Apache Airflow、Kubeflow Pipelines，或 Agent Platform Pipelines。

為什麼要學

考題看到「資料驗證」「schema」「偵測資料異常」「TensorFlow 全家桶」「標準化元件」，就是 TFX（或它的 TFDV）。考試指南 5.1 第一條「驗證資料和模型」，TFX 的 ExampleValidator 和 Evaluator 就是標準答案之一。

5. KFP、TFX、Airflow、Ray：怎麼選

怎麼選：

• ML 流程、要血緣追蹤、無伺服器 → Agent Platform Pipelines（用 KFP 或 TFX 寫）
• 全 TensorFlow、要標準的資料驗證和評估 → TFX
• PyTorch 或混合框架 → KFP
• 整個公司的資料流程（每天從十個系統抓資料、清洗、再觸發 ML）→ Managed Service for Apache Airflow，它也可以在流程裡觸發一條 Agent Platform 管線
• 已經有自己的 Kubernetes 團隊、要完全控制 → GKE 上的 Kubeflow（考試指南 3.2 有列）
• 大量平行的 Python 運算（例如大規模資料處理或強化學習）→ Ray

Managed Service for Apache Airflow 是 Google 在 2026 年把 Cloud Composer 改的名字，官方文件寫「Cloud Composer 正演變為 Managed Service for Apache Airflow」。舊題庫看到 Cloud Composer 就是它。

6. 管線快取：沒改的步驟不要重跑

白話是什麼

管線快取：管線執行時，每一步先看 ML Metadata 裡有沒有「一模一樣的執行」，有就直接拿上次的輸出、跳過這一步。

快取鍵（判斷「一模一樣」的依據）是三樣東西的組合：

1. 這一步的輸入：參數的值、輸入成品的 ID
2. 這一步的輸出定義：輸出參數和成品的名稱
3. 元件規格：映像檔、指令、參數、環境變數，連順序都算

而且只有同名的管線才共用快取。

算一次給你看

飲料店的流失模型管線五步（數字是教學假設）：

分析師只改了評估那一步的門檻（第 6 篇），重跑管線：

前三步的輸入、輸出定義、元件規格都沒變 → 命中快取，跳過
只跑評估 + 部署 = 5 + 5 = 10 分鐘，2 + 1 = 3 元
省下 75 分鐘（88%）、107 元（97%）

數字怎麼看：

• 越前面、越貴的步驟（訓練）越常被快取省掉，因為它的輸入通常沒變
• 反過來的陷阱：每週的新資料如果用同一個表名、同樣的參數，「準備資料」這一步的輸入看起來一樣，快取會跳過它，整條管線用上週的資料重訓，你還以為更新了。解法：抓資料那一步關掉快取（task.set_caching_options(False)），或把日期當參數傳進去，讓快取鍵不一樣
• 整條管線關快取：PipelineJob(..., enable_caching=False)

筆記裡的「管道快取（Pipeline Caching）減少重複運行時間／成本」就是這個，考試會從正反兩面考。

在 GCP 上怎麼做

建第一條管線

1. 把現有的筆記本程式拆成函數：抓資料、訓練、評估各一個
2. 用 KFP 的 @dsl.component 包成元件；要用 AutoML、自訂訓練、部署端點，直接接 GCPC 元件
3. @dsl.pipeline 組起來，kfp.compiler.Compiler().compile() 編成 YAML
4. 用 aiplatform.PipelineJob(template_path="pipeline.yaml", ...).run() 跑一次，在主控台看 DAG 圖和每一步的日誌
5. 跑順了，上傳 YAML 到 Artifact Registry 當範本，用排程 API 設每週一跑（第 19 篇講其他觸發方式）
6. 抓資料那一步關快取

觸發方式

官方 MLOps 文件列的五種：手動、排程（每天／每週有新標好的資料）、新資料到了（不定期）、模型效能下降（第 20 篇的監控觸發）、資料分布明顯改變（概念漂移）。第 19 篇會講在 GCP 上各怎麼接。

費用

管線執行本身有執行費，加上每一步啟動的資源費（訓練的 GPU、BigQuery 的查詢）。用 GCPC 元件，資源會自動帶管線的標籤，帳單匯出到 BigQuery 就能算每一次執行的總花費。

改名對照

考試會怎麼考

Google Cloud Professional Machine Learning Engineer（PMLE，專業機器學習工程師） 證照，2026 年 6 月 1 日起的官方考試指南裡，這篇的內容對應到：

看到這些字，就想到這個

六個常見陷阱

1. 把管線當成排程腳本：管線的重點是元件化、平行、血緣追蹤，不只是「定時跑」
2. 抓資料的步驟沒關快取：每週重訓其實都用同一份舊資料
3. PyTorch 專案選 TFX：TFX 是 TensorFlow 專用，混合框架用 KFP
4. 整個公司的 ETL 流程硬塞進 Agent Platform Pipelines：那是 Airflow 的事，ML 管線可以被 Airflow 觸發
5. 等級 1 就以為做完了：管線程式碼本身的改版還是手動部署，要到等級 2 才算完整
6. 忘記 Cloud Composer 改名了：考題寫 Managed Service for Apache Airflow 就是它

練習情境（自己出的練習，不是真實考題）

飲料店的資料科學家每週一早上手動在筆記本跑完流失模型，把模型檔用 email 寄給工程師部署。上個月有兩次忘了跑，一次寄錯版本。應該怎麼改善？

判斷過程：

• 「手動」「筆記本」「寄檔案」「忘了跑」→ MLOps 等級 0 的典型症狀
• 解法：把步驟做成 Agent Platform Pipelines 管線（KFP 元件），排程每週一自動跑，評估通過就自動部署
• 模型進 Model Registry（第 17 篇）而不是 email

推薦模型用 PyTorch，流失模型用 XGBoost，團隊想用同一套方式管兩條管線，而且要知道每個上線的模型是用哪份資料訓練的。應該用什麼？

判斷過程：

• 「PyTorch＋XGBoost」→ KFP（框架中立），不是 TFX
• 「同一套方式」「哪份資料」→ Agent Platform Pipelines，ML Metadata 自動記血緣
• 訓練、部署用 GCPC 預建元件

團隊全用 TensorFlow，最近兩次重訓後模型變差，追查發現上游系統改了欄位格式，但管線照樣訓練上線了。應該加什麼？

判斷過程：

• 「欄位格式變了沒被擋下」→ 缺資料驗證
• 「全 TensorFlow」→ TFX，加 StatisticsGen → SchemaGen → ExampleValidator，異常就停止管線
• 再加 Evaluator 比較新舊模型，沒變好不部署（第 19 篇）

常見問答

MLOps 是什麼？

把軟體工程的 DevOps 做法搬到機器學習上，讓模型的建立、測試、上線、重訓變成自動、可重複、可追蹤的流程。比 DevOps 多一個 CT（持續訓練）：程式沒改但資料變了就自動重訓。Google 的 MLOps 文件分三級：等級 0 全手動在筆記本做，等級 1 訓練流程做成自動管線持續訓練，等級 2 連管線程式碼的改版都走 CI/CD。

ML 管線是什麼？跟寫一個腳本差在哪？

管線是把 ML 工作流程寫成一連串步驟（任務），每步是一個元件加具體輸入，步驟之間用輸出接輸入，形成一張 DAG。跟腳本的差別：沒有依賴的步驟自動平行跑；元件可以在不同管線重用；每一步的輸入輸出都被 ML Metadata 記下來可以追血緣；沒改的步驟可以用快取跳過。

Vertex AI Pipelines 是什麼？

Google 代管、無伺服器的管線執行服務，2026 年 4 月起叫 Gemini Enterprise Agent Platform Pipelines。它可以跑 Kubeflow Pipelines 或 TFX 定義的管線：你定義、編譯成 YAML、建一次執行或排程重複執行，它負責開機器、照 DAG 跑、記錄血緣。任務可以委派給 BigQuery、Dataflow、Spark 算。Google Cloud Pipeline Components 提供 AutoML、自訂訓練、部署等預建元件。

Kubeflow Pipelines 和 TFX 差在哪？

KFP 是框架中立的管線框架，用 Python 函數或容器當元件，PyTorch、scikit-learn、XGBoost 都能用，彈性高。TFX 是 TensorFlow 專用的管線平台，附一整套標準元件（ExampleGen、StatisticsGen、SchemaGen、ExampleValidator、Transform、Trainer、Evaluator、Pusher 等）和函式庫（TFDV 資料驗證、TFT 轉換、TFMA 評估），全 TensorFlow 的團隊照著組就有完整管線。兩種都能在 Agent Platform Pipelines 上跑。

TFDV 是什麼？

TensorFlow Data Validation，TFX 裡做資料驗證的函式庫。StatisticsGen 用它算統計量，SchemaGen 用它推出資料結構（每欄型態、值域），ExampleValidator 用它檢查新資料有沒有異常（遺失值、型態不對、分布跑掉）。考試看到資料驗證、schema、偵測異常，就是它。

Cloud Composer 和 Vertex AI Pipelines 怎麼選？

Cloud Composer 現在叫 Managed Service for Apache Airflow，是通用的工作流排程服務，適合整個公司的資料工程流程（每天從多個系統抓資料、清洗、觸發下游）。Agent Platform Pipelines 是 ML 專用，有元件、成品、血緣追蹤、快取。常見的組合是 Airflow 管整體流程，其中一步觸發一條 Agent Platform 管線。

管線快取是什麼？什麼時候要關？

管線執行時，每一步先查 ML Metadata 有沒有輸入、輸出定義、元件規格都一樣的執行，有就直接用上次的輸出、跳過這步，省時間和錢。要關的情況：抓資料那一步，因為資料更新了但表名和參數沒變，快取會跳過它、用舊資料重訓。用 task.set_caching_options(False) 關單步，或 PipelineJob 的 enable_caching=False 關整條。

管線怎麼定期自動跑？

編譯好的 YAML 上傳到 Artifact Registry 當管線範本，用 Agent Platform 的排程 API 設定每天或每週執行。其他觸發方式：新資料到了、模型效能下降、資料分布改變，第 19 篇講怎麼接 Cloud Build、Pub/Sub、Cloud Scheduler。

一定要用 Google 的管線服務嗎？

不一定。考試指南 5.1 寫「代管或非代管服務」：代管是 Agent Platform Pipelines、Managed Service for Apache Airflow；非代管是自己在 GKE 上架 Kubeflow，要完全控制或已經有 Kubernetes 團隊才值得。另有 Ray on Agent Platform 給大規模平行 Python 運算。

Vertex AI Pipelines 改名了嗎？

是。Vertex AI 在 2026 年 4 月改名為 Gemini Enterprise Agent Platform，Vertex AI Pipelines 改叫 Agent Platform Pipelines，Vertex ML Metadata 改叫 Agent Platform ML Metadata，Vertex AI Experiments 改叫 Experiments on Agent Platform。同時期 Cloud Composer 改名 Managed Service for Apache Airflow，Dataproc Serverless 改名 Managed Service for Apache Spark。KFP 和 TFX 是開源專案，名稱沒變。

重點整理

• MLOps：DevOps 搬到 ML，多了 CT 持續訓練；三級：0 手動筆記本、1 管線自動化、2 管線本身也 CI/CD
• 管線：元件（獨立程式）＋輸入＝任務，串成 DAG，沒依賴的平行跑；成品被 ML Metadata 記血緣
• Agent Platform Pipelines（原 Vertex AI Pipelines）：無伺服器跑 KFP 或 TFX 管線；定義 → 編譯 YAML → 執行（一次／排程／範本）→ 監控；任務可委派 BigQuery、Dataflow、Spark；GCPC 預建元件
• KFP：框架中立，Python 函數當元件；TFX：TensorFlow 全家桶，標準元件 ExampleGen → StatisticsGen → SchemaGen → ExampleValidator → Transform → Trainer → Evaluator → Pusher，函式庫 TFDV／TFT／TFMA／MLMD
• 怎麼選：ML 管線 → Agent Platform Pipelines；TensorFlow＋資料驗證 → TFX；混合框架 → KFP；通用資料流程 → Managed Service for Apache Airflow（舊名 Cloud Composer）；自管 → GKE 上的 Kubeflow；平行 Python → Ray
• 快取：輸入＋輸出定義＋元件規格一樣就跳過；只改評估步驟可省近九成；抓資料那步要關

延伸閱讀

本系列

• 第 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 批次預測、流量分割
• 下一篇：第 19 篇：機器學習的 CI/CD：程式改了、資料來了，模型自動重訓

站上相關文章

• Kubernetes 是什麼？白話解釋＋判斷你是否真的需要它
• 容器技術是什麼？從零開始看懂 Docker 與容器化應用
• Dataflow 是什麼？跟 Apache Beam 有什麼關係？
• 雲端職缺大解析：雲端工程師、架構師、SRE、DevOps、資料工程師差在哪？
• End-to-end Training 是什麼
• GCP 學習路徑 Roadmap

把做模型的步驟寫成機器會自己照做的 SOP，模型才能一直是新的。如果你想有系統地從雲端基礎一路學到在 GCP 上動手做機器學習，可以看看東東的 GCP 課程，或加 LINE 聊聊你現在的狀況，一起找出最適合你的學習順序。

The post MLOps 是什麼？Vertex AI Pipelines、Kubeflow、TFX 介紹 first appeared on 東東 GCP 教學 - GCP 實戰講師.

模型訓練好了（第 14 到 16 篇），接下來要讓它真的能用：App 要能問它「這位會員會不會流失」，行銷部門要能拿到一整張名單。這篇講的就是「模型怎麼上線」：兩種拿到預測的方式、端點怎麼設、新舊版本怎麼換、機器怎麼自動增減、要花多少錢。

一樣用有 2,000 間分店、50 萬名會員的連鎖飲料店當例子（教學假設），兩個模型：

• 猜你想點推薦模型：會員一打開 App 就要看到推薦，等不了
• 會員流失預測模型：行銷部門每週一早上要一張「這週該追誰」的名單

為什麼你需要知道

• 模型不上線等於沒做：訓練完的模型只是 Cloud Storage 裡的一個檔案，要有人能呼叫它才有價值
• 部署比訓練更花錢：訓練跑完機器就收掉；線上端點的機器只要部署著就一直算錢，不管有沒有人用。選錯方式，一個月帳單比訓練貴十倍
• 筆記裡的名稱改了：Vertex AI Endpoints、Online Prediction、Batch Prediction 現在叫 Agent Platform Inference、線上推論、批次推論；更早的 AI Platform Prediction 已在 2025 年 4 月關閉
• 證照必考：PMLE 考試指南第 4 區「服務與擴展模型」佔 20%，4.1 部署批次和線上推論、容器、Model Registry、推出策略（A/B 測試、金絲雀部署）、前後處理；4.2 擴展線上服務、公開和私人端點、硬體選擇

先搞懂：推論是什麼、兩種拿法

白話是什麼

推論（inference）：把新資料丟進訓練好的模型，拿到它的輸出。以前叫預測（prediction），Google 的文件現在統一用「推論」，這篇兩個詞混用，意思一樣。

Google 的推論總覽說，拿推論有兩種方法：

同步是「送出請求、站在那裡等答案」；非同步是「送出請求先走，好了再來拿」。

比喻

• 線上推論是櫃台現點現做：客人站在櫃台等，店員要隨時在、飲料機要隨時開著，就算半夜沒客人也要有人顧店
• 批次推論是中央廚房：晚上把明天 2,000 間店的食材一次備好，白天配送。不用隨時待命，但客人現在點的東西拿不到

來龍去脈

線上推論要先部署（deploy）：把模型放到一台或多台隨時開著的機器上，等請求進來。這些機器叫端點（endpoint），本質上是一個網址，應用程式把資料 POST 過去就拿到答案。

批次推論不用端點：你告訴 Agent Platform「模型在這、資料在那（BigQuery 表或 Cloud Storage 檔案）、結果放哪」，它臨時開機器算完、把結果寫到你指定的地方、機器收掉。

為什麼要學

考題最常考的判斷就是這個：看到「即時」「App 回應」「低延遲」選線上；看到「每天晚上」「整批」「不急」選批次。選錯不只考試扣分，實務上帳單差十倍。

1. 線上推論：端點怎麼設

部署時決定的三件事

官方部署文件說，部署模型時會建三種資源，各決定一件事：

副本（replica）就是「跑著同一個模型的一台機器」，開 3 個副本就是 3 台機器同時接請求。

官方提醒：部署後這些設定不能改，要改就重新部署。例外是擴展設定（最少／最多副本數、擴展指標）可以不重新部署直接改。

端點有四種

官方端點類型文件的比較表，整理成白話：

怎麼選：

• 一般情況選專用公開端點，官方說它更快、跟其他使用者的流量隔離、請求可以更大、逾時更長
• 公司內部系統呼叫、不想走公網 → Private Service Connect 端點
• 要放進 VPC Service Controls 的邊界 → 共用公開或私人端點
• 微調過的 Gemini 模型只能部署到共用公開端點

Private Service Connect（私人服務連線）是讓你的內網直接接到 Google 的服務，不經過公開網際網路，不需要公開 IP。

容器：預建、自訂、還是自訂推論例程

跟訓練一樣（第 16 篇），模型要包在容器裡才能跑：

• 預建推論容器：Google 準備好的 TensorFlow（含效能最佳化版）、PyTorch、scikit-learn、XGBoost 容器，模型檔放 Cloud Storage 就能用
• 自訂容器：自己寫 HTTP 伺服器。官方要求：監聽 AIP_HTTP_PORT 環境變數指定的埠、提供健康檢查路徑（10 秒內回 200 才算活著）和推論路徑、請求格式是 {"instances": [...]}、回應是 {"predictions": [...]}
• 自訂推論例程（Custom Prediction Routine，CPR）：中間地帶。官方說明：你只寫前處理和後處理的 Python 程式（實作 Predictor 介面），HTTP 伺服器和 Dockerfile 它幫你準備，還能先在本機部署測試

前處理是「資料進模型前先整理」（例如第 10 篇的標準化），後處理是「模型輸出後再加工」（例如把機率換成「高／中／低」風險等級，或套商業規則）。考試指南 4.1 直接寫「開發推論前處理和後處理的解決方案」，答案就是 CPR 或自訂容器。

筆記裡的「自訂預測例程（CPR）」現在的正式名稱是 custom inference routine，縮寫沒變。

Model Registry：模型的倉庫

Model Registry 是集中管理模型的地方：匯入模型、管版本、貼別名（例如把要上線的版本標成 default）、從這裡部署到端點或跑批次推論、看評估結果。

• 自訂訓練的模型要先匯入才會出現；AutoML 的模型訓練完自動進來；BigQuery ML 的模型用 model_registry = 'VERTEX_AI' 註冊（第 15 篇）
• 官方部署文件寫明：模型要在 Model Registry 看得到才能部署

2. 流量分割：新版本怎麼換上去

問題

推薦模型 v2 訓練好了，離線評估比 v1 好。但離線好不代表上線好（第 8 篇的資料洩漏、第 20 篇的偏差都可能讓分數虛高）。直接全換，萬一 v2 有問題，所有會員同時受影響。

白話是什麼

流量分割（traffic split）：同一個端點上放兩個以上的模型，設定每個模型接多少比例的請求。

官方的說法：把新模型加到同一個端點，先服務一小部分流量，逐步提高比例，直到 100%。好處是應用程式不用改端點網址，也不會突然大變。

比喻

新配方的珍奶，先在 10% 的訂單裡用新配方，看客人反應和退貨率，沒問題再 50%、再 100%。客人還是走同一個櫃台，不知道後面換了配方。

兩種常見用法

金絲雀這個名字來自礦工帶金絲雀下礦坑，鳥先倒就知道有毒氣：用一小部分流量當探子。

考試指南 4.1 直接點名「實作模型推出策略（例如 A/B 測試和金絲雀部署）來比較模型版本」，在 Agent Platform 上的做法就是流量分割。

反過來：一個模型、多個端點

官方也列了「一個模型部署到多個端點」的理由：測試環境和正式環境用不同資源；不同應用程式有不同的效能要求（SLO，服務水準目標），要求高的部署到機器多的端點，要省錢的部署到機器少的端點。

滾動部署（預覽功能）

要同一個模型換新版本、沿用原本的機器，可以用滾動部署：新版本的副本一台一台換掉舊的，流量依「準備好的副本數」比例逐漸移過去。新副本的健康檢查一直不過，就自動退回舊版本。

算一次給你看：金絲雀怎麼看數字

推薦模型 v1 的點擊率（推薦的飲料真的被點）是 8%，v2 離線評估說會到 10%。上線用 90／10 流量分割，一天 100 萬次推薦：

v2 分到的流量 = 1,000,000 × 10% = 100,000 次
v2 實際點擊率 7.5% → 7,500 次點擊
v1 的 900,000 次 × 8% = 72,000 次點擊

v2 實際比 v1 差（7.5% < 8%），但只影響了 10 萬次，損失是 100,000 × (8% − 7.5%) = 500 次點擊。如果直接全換，損失是 1,000,000 × 0.5% = 5,000 次。

數字怎麼看：

• 分給新版本的比例越小，風險越小，但要更久才累積到夠多樣本做判斷。10% 一天 10 萬次，統計上已經夠；如果一天只有 1,000 次推薦，10% 只有 100 次，要跑好幾天
• 看的指標要是商業指標（點擊率、轉換率），不是離線的 AUC。這就是 A/B 測試的意義

3. 自動擴展：機器怎麼自己增減

白話是什麼

自動擴展（autoscaling）：請求變多就自動加副本，變少就減，你只設上下限。

官方自動擴展文件的規則：

• 預設目標：沒有 GPU 的部署，讓 CPU 使用率維持 60%；有 GPU 的部署，看 CPU 或 GPU 使用率較高的那個維持 60%
• 可以用 autoscalingMetricSpecs 改指標和目標，例如 GPU 的 accelerator/duty_cycle 目標 70%
• 設 minReplicaCount（最少幾台）和 maxReplicaCount（最多幾台）
• 每 15 秒算一次目標副本數，但採用過去 5 分鐘內最高的那個目標。所以突然的尖峰會讓它 15 秒內加機器，但要等尖峰過了 5 分鐘才會減

筆記裡的「自動擴展根據流量／CPU 調整 minReplicaCount」就是這個。

算一次給你看

官方給的公式：

目標副本數 = 向上取整（目前副本數 × 目前使用率 ÷ 目標使用率）

向上取整是小數一律進位（3.33 → 4）。

推薦模型現在 2 個副本，中午尖峰 CPU 衝到 100%：

目標 = 向上取整（2 × 100% ÷ 60%）= 向上取整（3.33）= 4 個副本

半夜 10 個副本，使用率掉到 1%：

目標 = 向上取整（10 × 1% ÷ 60%）= 向上取整（0.17）= 1 個副本

但如果你設了 minReplicaCount = 2，半夜最少還是 2 台。

數字怎麼看：

• 目標使用率設低（例如 40%），機器會多開、反應快但貴；設高（例如 80%），省錢但尖峰時延遲可能飆高
• 新機器開起來要時間（官方說調整副本數之後還有啟動延遲），所以不能把 minReplicaCount 設到剛好，要留餘裕
• 每個副本只跑一個容器，容器如果只用一條執行緒，多核心機器也吃不滿，使用率上不去就不會擴展。官方建議從「一個核心一個 worker」開始調

縮到零（預覽功能）

官方文件有一節「Scale To Zero」，沒流量時副本降到 0，不算錢。目前是預覽階段，用之前要確認你的區域和機型支援。沒有這個功能的話，線上端點最少 1 個副本一直在算錢，這是線上和批次最大的費用差別。

機型怎麼選

官方的運算資源文件：

• 線上推論沒有公式，建議把模型放到幾種機型上實測延遲、成本、併發、吞吐量，有範例筆記本可以跑
• 每個副本會保留約 1 個 vCPU 給系統，所以單核機器等於沒得用
• 大機器可能總成本更低：因為副本數少。GPU 每小時貴，但延遲低、總成本可能反而低
• 推論也支援 Spot VM 和預留，跟訓練一樣（第 16 篇）
• GPU 選項從 T4、L4 到 A100、H100 都有，也支援 TPU 做線上推論

4. 批次推論：不用端點，算完就走

怎麼做

官方批次推論文件：建一個 BatchPredictionJob，指定模型、輸入、輸出、機型、副本數。

輸入格式：

三個限制：

• 輸入、輸出、模型要在同一個區域（或多區域）
• 批次推論不會自動擴展：資料一開始就知道多少，系統直接切給 starting_replica_count 個副本，max_replica_count 會被忽略
• BigQuery ML 的模型要先註冊到 Model Registry 才能這樣跑

副本數怎麼算：算一次

官方建議：用最小的機型、靠增加副本數來提高吞吐量（比換大機器更線性、更好預測）。而且工作至少跑 10 分鐘才划算，因為每個副本啟動要約 5 分鐘，這 5 分鐘也算錢。

官方公式：

副本數 = N ÷ (T × (60 ÷ Tb))
N：批次數（筆數 ÷ 每批筆數）
T：希望幾分鐘跑完
Tb：一個副本處理一批要幾秒

飲料店 50 萬名會員，每批 100 筆，希望 10 分鐘內跑完，實測一個副本 1 秒處理一批：

N = 500,000 ÷ 100 = 5,000 批
副本數 = 5,000 ÷ (10 × (60 ÷ 1)) = 5,000 ÷ 600 ≈ 8.3 → 9 個副本

數字怎麼看：

• 官方的經驗值：幾千筆 → 副本數幾十；幾百萬筆 → 幾百
• 想 5 分鐘跑完就要 17 個副本，但每個副本啟動就要 5 分鐘，不划算。批次推論不是越快越好，是夠用就好
• 跑完機器就收掉，沒有閒置費用。這就是流失名單用批次的理由：一週跑一次，每次十幾分鐘，其他時間一毛不花

5. 不一定要用 Agent Platform 的端點

考試指南 4.1 列了四個部署的地方：「Agent Platform、Model Garden、Cloud Run、GKE」。

Cloud Run 的 GPU 規則：一個執行個體一張 GPU，L4 至少要配 4 個 CPU 和 16 GiB 記憶體，不用預留。

在 GCP 上怎麼做

線上推論的流程

1. 模型進 Model Registry（匯入、AutoML 自動、BQML 註冊）
2. 建端點（選專用公開，或 Private Service Connect）
3. 部署：選模型版本、機型、GPU、minReplicaCount／maxReplicaCount、流量比例
4. 應用程式對端點網址送 {"instances": [...]}，拿到 {"predictions": [...]}。專用端點用 use_dedicated_endpoint=True
5. 換版本：加第二個模型到同一端點，調流量比例；或用滾動部署
6. 不用了解除部署，不然副本一直算錢

gcloud ai endpoints deploy-model ENDPOINT_ID \
  --region=asia-east1 \
  --model=MODEL_ID \
  --display-name=recsys-v2 \
  --machine-type=n1-standard-4 \
  --min-replica-count=2 \
  --max-replica-count=10 \
  --traffic-split=0=90,DEPLOYED_MODEL_V1_ID=10

批次推論的流程

1. 模型在 Model Registry
2. 資料整理成 BigQuery 表（或 JSON Lines、TFRecord 放 Cloud Storage），跟模型同區域
3. 建 BatchPredictionJob：機型用小的、副本數用公式估
4. 結果寫到 BigQuery 表或 Cloud Storage，行銷部門直接查
5. 要定期跑，接 Cloud Scheduler 或 Pipelines（第 18、19 篇）

改名對照

考試會怎麼考

Google Cloud Professional Machine Learning Engineer（PMLE，專業機器學習工程師） 證照，2026 年 6 月 1 日起的官方考試指南裡，這篇的內容對應到：

看到這些字，就想到這個

六個常見陷阱

1. 每週跑一次的名單用線上端點：副本 24 小時算錢，批次推論跑十幾分鐘就收掉
2. 要即時回應卻選批次：批次是非同步，App 等不到
3. 新版本直接全量換：沒有流量分割，出問題全部受影響
4. 私人端點（VPC 對等互連）想做流量分割：官方明寫一個私人端點只能一個模型、不支援流量分割；要私人又要分割，用 Private Service Connect 端點
5. 批次推論設了 max_replica_count 以為會自動擴展：批次不會，只看 starting_replica_count
6. 部署了忘記解除：測試完的端點放著，每個月默默扣錢

練習情境（自己出的練習，不是真實考題）

飲料店的推薦模型要在 App 裡即時顯示，尖峰在中午和晚上，半夜幾乎沒人用。工程師部署了 v2，想先確認不會比 v1 差。應該怎麼做？

判斷過程：

• 「即時」→ 線上推論，專用公開端點
• 「尖峰、半夜沒人」→ 自動擴展，minReplicaCount 設小（例如 1 或 2）、maxReplicaCount 設大
• 「先確認 v2」→ 流量分割，v1 90%、v2 10%，看點擊率，沒問題再加

行銷部門每週一早上要一張「可能流失的會員」名單，50 萬名會員的特徵表在 BigQuery。應該怎麼做？

判斷過程：

• 「每週一次」「整張表」→ 批次推論，不用端點
• 「BigQuery」→ 輸入直接指定 BigQuery 表，輸出也寫 BigQuery
• 副本數用公式估，小機型、跑 10 分鐘左右；接 Cloud Scheduler 每週自動跑

公司的 ERP 系統（在自家機房）要呼叫模型，資安要求不能經過公開網際網路，而且之後要能做新舊版本的流量分割。應該用哪種端點？

判斷過程：

• 「不經過公網」→ 私人的兩種
• 「要流量分割」→ 私人端點（VPC 對等互連）不支援，選 Private Service Connect 專用私人端點

常見問答

模型部署怎麼選線上預測還是批次預測？

看要不要馬上拿到答案。應用程式要即時回應（App 一打開就推薦、客服機器人回話）用線上推論：先把模型部署到端點，機器一直開著，同步回應。一次處理累積的大量資料、不急著要（每週名單、每晚重算分數）用批次推論：不用端點，建一個批次推論工作，臨時開機器算完寫到 BigQuery 或 Cloud Storage，機器收掉。線上端點只要部署著就算錢，批次只付跑的時間。

端點是什麼？有哪幾種？

端點是部署好的模型對外的網址，應用程式把資料送過去就拿到預測。四種：專用公開端點（推薦，10 MB、逾時可到 1 小時、串流、流量隔離）、共用公開端點（1.5 MB、60 秒、每分鐘 30,000 次）、Private Service Connect 專用私人端點（推薦，內網、不走公網、支援流量分割）、私人端點（VPC 對等互連，一個端點只能一個模型、不支援流量分割）。專用公開端點不支援 VPC Service Controls。

流量分割是什麼？怎麼做金絲雀部署？

同一個端點放兩個以上的模型，設定每個接多少比例的請求。金絲雀部署是新版本先接一小部分（例如 10%），看商業指標沒問題再逐步加到 100%，應用程式不用改網址。A/B 測試則是兩版各接一半，比較哪個指標好。要換同一個模型的新版本、沿用原本機器，可以用滾動部署（預覽），健康檢查失敗會自動退回。

自動擴展怎麼運作？

你設最少和最多副本數，Agent Platform 依使用率自動增減。預設目標是 CPU 使用率 60%，有 GPU 則看 CPU 或 GPU 較高者；可以改成 GPU duty cycle 之類的指標和目標。每 15 秒用公式「向上取整（目前副本數 × 目前使用率 ÷ 目標使用率）」算目標，但採用過去 5 分鐘內最高的目標，所以加機器快、減機器慢。縮到零目前是預覽功能。批次推論不會自動擴展。

批次推論的副本數要設多少？

官方建議用最小的機型、靠增加副本數提高吞吐量，而且工作至少跑 10 分鐘才划算，因為每個副本啟動約 5 分鐘也計費。公式是副本數 = 批次數 ÷（希望的分鐘數 × 60 ÷ 一個副本處理一批的秒數）。例如 50 萬筆、每批 100 筆、10 分鐘、每批 1 秒，算出約 9 個副本。幾千筆大約幾十個副本，幾百萬筆大約幾百個。

自訂推論例程（CPR）是什麼？

介於預建容器和自訂容器之間：你只寫前處理和後處理的 Python 程式（實作 Predictor 介面，需要時再加 Handler），HTTP 伺服器和 Dockerfile 由 Agent Platform SDK 幫你產生，還能先在本機部署測試。前處理像把輸入標準化、呼叫外部服務補資料，後處理像把模型輸出轉成業務格式或套商業規則。考試指南 4.1 的「推論前處理和後處理」就是指這個。

自訂推論容器有什麼要求？

要自己跑一個 HTTP 伺服器，監聽 AIP_HTTP_PORT 環境變數指定的埠；提供健康檢查路徑，10 秒內回 200 才算健康，否則會被視為不健康；提供推論路徑，請求格式是 {“instances”: […]}，回應是 {“predictions”: […]}。映像檔要放在 Artifact Registry。

一定要用 Vertex AI 的端點嗎？

不一定。考試指南列了四個地方：Agent Platform 端點（全代管、有流量分割和監控）、Model Garden（Gemini 和開源模型一鍵部署）、Cloud Run（無伺服器容器，有 L4 和 RTX PRO 6000 GPU，沒流量可縮到零，適合輕量服務）、GKE（自己管 Kubernetes，要完全控制或超大規模）。輕量 API 想省閒置費用，Cloud Run 常是更便宜的選擇。

部署後哪些設定可以改？

官方說部署時決定的區域、容器、運算資源部署後不能改，要改就重新部署。例外是擴展設定：最少副本數、最多副本數、必要副本數和擴展指標可以用 mutateDeployedModel 直接改，不用重新部署；機型不能改。

Vertex AI Endpoints 改名了嗎？

是。Vertex AI 在 2026 年 4 月改名為 Gemini Enterprise Agent Platform，Vertex AI Prediction 和 Endpoints 現在叫 Agent Platform Inference，Online Prediction 和 Batch Prediction 改稱 Online Inference 和 Batch Inference，Model Registry 改叫 Agent Platform Model Registry。更早的 AI Platform Prediction 已在 2025 年 4 月 7 日關閉，所有模型和部署都已刪除。

重點整理

• 兩種推論：線上（同步、先部署到端點、低延遲、機器一直算錢）vs 批次（非同步、不用端點、處理累積資料、跑完收機器）
• 部署的三件事：端點決定區域、模型決定容器、DeployedModel 決定機器；部署後只有擴展設定能改
• 端點四種：專用公開（推薦）、共用公開（1.5 MB、60 秒）、Private Service Connect（推薦，內網）、私人（VPC 對等互連，不能流量分割）
• 流量分割：同一端點多模型；金絲雀 90／10 逐步加，A/B 各 50；一模型多端點分測試／正式；滾動部署換版本沿用機器
• 自動擴展：預設 60%，目標副本 = 向上取整（目前 × 使用率 ÷ 目標）；每 15 秒看 5 分鐘最高；批次不自動擴展
• 批次副本數：小機型多副本、至少跑 10 分鐘；N ÷ (T × 60 ÷ Tb)
• 容器：預建、自訂（AIP_HTTP_PORT、健康檢查 10 秒）、CPR 只寫前後處理
• 別的地方：Model Garden、Cloud Run（GPU、縮到零）、GKE；Vertex AI Prediction 現在叫 Agent Platform Inference

延伸閱讀

本系列

• 第 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
• 下一篇：第 18 篇：MLOps 是什麼？Vertex AI Pipelines、Kubeflow、TFX 介紹

站上相關文章

• 容器技術是什麼？從零開始看懂 Docker 與容器化應用
• Kubernetes 是什麼？白話解釋＋判斷你是否真的需要它
• Vertex AI 核心功能 Agent Builder、Model Builder 和 Model Garden 介紹
• GCP Cloud Armor 完整教學
• GCP 帳單爆炸防護指南

模型上線的方式選對，帳單和使用者體驗才會都好看。如果你想有系統地從雲端基礎一路學到在 GCP 上動手做機器學習，可以看看東東的 GCP 課程，或加 LINE 聊聊你現在的狀況，一起找出最適合你的學習順序。

The post 模型部署怎麼選？線上預測 vs 批次預測、流量分割 first appeared on 東東 GCP 教學 - GCP 實戰講師.

第 14 篇說，AutoML 和 BigQuery ML 做不到的事（自訂架構、特定框架、幾十張 GPU）就走自訂訓練。這篇把它拆開：程式怎麼打包、機器怎麼選、多台怎麼分工、超參數怎麼自動調、要花多少錢。

一樣用有 2,000 間分店的連鎖飲料店當例子（教學假設）：研究團隊用 PyTorch 寫好了「猜你想點」推薦模型，有自訂的損失函數，資料是 50 萬名會員三年的交易紀錄，放在 Cloud Storage。現在要把它放到雲端上跑。

為什麼你需要知道

• GPU 很貴，選錯更貴：一張高階 GPU 一小時的租金，比一台普通機器一天還貴。機型選錯、該用 Spot 沒用、4 張 GPU 跑出 1 張的效果，錢就這樣燒掉
• 這是「自己煮」的那條路：第 14 篇的比喻，Google 只出爐子。爐子有幾種、怎麼開、幾個人一起炒，都要自己決定
• 筆記裡的名稱全改了：Vertex AI Training 現在叫 Agent Platform Managed Training，底下分無伺服器訓練和訓練叢集；更早的 AI Platform Training 已經在 2025 年 4 月關閉
• 證照必考：PMLE 考試指南第 3.2 節「用不同 SDK 訓練模型（Agent Platform 自訂訓練、GKE 上的 Kubeflow…）」「排除訓練失敗」「超參數調校」，第 3.3 節「評估 CPU、GPU、TPU」「GPU 和 TPU 上的資料平行與模型平行分散式訓練」。整個第 3 區佔 21%，是最大的一區

先搞懂：自訂訓練是什麼

白話是什麼

自訂訓練（custom training）：你自己寫訓練程式，用任何框架；Agent Platform 負責開虛擬機器、裝加速器、把你的程式跑起來、跑完把機器收掉，只收用到的時間。

虛擬機器（VM）是雲端上租來的一台電腦，站上有一篇 Compute Engine 是什麼。

比喻

自己煮，但廚房是租的、按小時算。你帶著食譜（程式）和食材（資料）進去，想用幾個爐（GPU）、幾間廚房（機器）自己說，煮完走人，只付用到的時間。

來龍去脈

官方容器總覽描述的流程：

1. 用你選的框架寫訓練程式
2. 決定用預建容器還是自訂容器
3. 資料放在 Agent Platform 讀得到的地方（Cloud Storage、Bigtable），跟訓練同一個專案和區域
4. 建好 Docker 映像檔，推到 Artifact Registry
5. 建自訂工作（CustomJob）送出
6. Agent Platform 依設定開一台或多台機器（叫訓練執行個體），跑你的映像檔
7. 成功或遇到無法復原的錯誤，就停掉所有程序、清掉資源

名稱的演變：最早叫 AI Platform Training（舊題庫還看得到，官方淘汰清單寫 2025 年 4 月 7 日關閉）→ Vertex AI custom training → 2026 年 4 月起叫 Gemini Enterprise Agent Platform Managed Training，底下分兩種跑法（第 6 節）。

為什麼要學

這是 PMLE 第 3 區的主軸，也是「能不能真的把一個研究模型放上雲端」的分水嶺。

1. 容器：預建的還是自己做

白話是什麼

容器（container）：把程式和它需要的所有東西（框架、函式庫、系統工具）打包成一個標準箱子，到哪台機器都能原樣跑。Docker 是做這種箱子最常用的工具，箱子的設計圖叫 Dockerfile，做好的箱子叫映像檔（image）。站上有一篇容器是什麼。

比喻

出國比賽的行李箱。裡面裝好球拍、球鞋、水壺，到了場地打開就能上場，不用在當地到處找器材。

預建容器：Google 幫你裝好了

Google 提供預建容器，常用框架都有：TensorFlow、PyTorch、scikit-learn、XGBoost，分 CPU 和 GPU 版本，映像檔名稱像 pytorch-gpu.2-x、tf-gpu.2-17、xgboost-cpu.2-1。

用預建容器時，你不用碰 Docker，只要把訓練程式打包成 Python 套件放到 Cloud Storage，建工作時指定「用哪個預建容器」就好。

自訂容器：四種情況才需要

官方容器總覽列的好處，反過來就是「什麼時候要自己做」：

套回飲料店：研究團隊的 PyTorch 模型如果只用標準套件，預建的 PyTorch GPU 容器就夠；如果用了特殊的推薦系統函式庫，就要自訂。

做 GPU 容器有一個特別要求：官方建議用 nvidia/cuda 當基底映像檔，裡面已經裝好對應版本的 CUDA 和 cuDNN（NVIDIA 讓程式能用 GPU 的兩個基礎套件），環境變數也設好了。

自訂容器的流程

官方步驟：寫 Dockerfile（裝相依套件、複製訓練程式、設定進入點）→ 本機 build → 推到 Artifact Registry（Google 的映像檔倉庫，可以想成放 Docker 箱子的雲端儲物櫃）→ 建工作時用這個映像檔的網址。

為什麼要學

考題看到「預建容器不支援的框架」「特定版本」「非 ML 相依」就是自訂容器；看到「標準 TensorFlow／PyTorch 程式、最少設定」就是預建容器。

2. CustomJob：告訴 Google 要幾台、什麼機器

白話是什麼

自訂工作（CustomJob）是一張「訂單」，寫清楚：用哪個容器、幾台機器、每台什麼規格、幾張 GPU、跑多久要停。

官方文件的核心欄位是 WorkerPoolSpec（工作池規格）：

用指令建一個工作長這樣：

gcloud ai custom-jobs create \
  --region=asia-east1 \
  --display-name=drink-recsys \
  --worker-pool-spec=machine-type=n1-standard-16,replica-count=1,accelerator-type=NVIDIA_TESLA_T4,accelerator-count=2,executor-image-uri=asia-docker.pkg.dev/vertex-ai/training/pytorch-gpu.2-4.py310:latest,local-package-path=.,script=train.py

程式裡拿得到的環境變數

訓練程式不用寫死路徑，Agent Platform 會給三個環境變數（程式啟動時可以讀到的設定值）：

資料怎麼讀，第 13 篇講過：Cloud Storage 會掛在 /gcs/ 底下。

3. CPU、GPU 還是 TPU：怎麼選

三種硬體的白話

• CPU：電腦的大腦，什麼都會做，但同時只能做幾件事
• GPU：原本畫遊戲畫面的晶片，擅長同時做幾千個簡單算術，NVIDIA 做的最常見
• TPU：Google 自己設計、專門做機器學習的晶片。官方簡介說它專門做「大型矩陣運算」，有晶片上的高頻寬記憶體，可以接成一組（叫 slice）擴大規模。程式要先經過 XLA 編譯器翻成 TPU 能跑的機器碼

矩陣運算可以想成「一大批數字同時相乘相加」，神經網路的每一層就是在做這件事。

官方的選擇指南

Cloud TPU 簡介直接列了三種硬體各適合什麼：

TPU 不適合：需要頻繁分支或大量逐元素運算的程式、需要高精度算術、主訓練迴圈有自訂運算。

套回飲料店：推薦模型有自訂損失函數（自訂運算）、用 PyTorch，而且不是訓練幾週的規模 → GPU。要是改成標準架構、資料大到要訓練好幾天，才考慮 TPU。

GPU 有哪些、怎麼搭機型

官方運算資源文件列的 GPU（2026 年 10 月）：從入門的 T4、L4，到 V100、A100（40GB／80GB），再到 H100、H200、B200、GB200 這些訓練大型語言模型用的。P100 在 2026 年 9 月 15 日停止支援。

三個規則：

• GPU 要配對的機型：A2、N1 或 G2 系列。例如 A100 配 a2-highgpu-1g（1 張）到 a2-megagpu-16g（16 張），L4 配 g2-standard-*，T4、V100 配 n1-*
• 張數有固定選項：T4 可以 2 張或 4 張，不能 3 張
• 機型要撐得起 GPU：官方的例子是 n1-standard-32（32 核、120 GB 記憶體）配 V100 至少要 4 張，因為每張 V100 最多只能搭配 12 核、76 GB，2 張不夠、3 張不行
• 機型太小（例如 n1-highmem-2）配 GPU，CPU 不夠可能連日誌都寫不出來

TPU 的設定方式

TPU 在自訂訓練裡只能用一個工作池、一個副本。各世代的設定：

控制費用的三個開關

官方運算資源文件開頭就講「管理成本與可用性」：

Spot 和 Dynamic Workload Scheduler 都是在 CustomJob 的 scheduling.strategy 設定。

4. 分散式訓練：多台一起跑

白話是什麼

一台機器、一張 GPU 跑太慢，就讓很多台一起跑。分兩種分法：

考試指南 3.3 兩個詞都點名了，但考題以資料平行為主。

同步還是非同步

TensorFlow 的分散式指南把資料平行再分兩種：

• 同步：所有機器各算一批，等大家都算完，把梯度（第 3 篇講的「該往哪調」）加總平均，一起更新。靠 all-reduce 演算法交換梯度，GPU 之間預設用 NVIDIA 的 NCCL 函式庫
• 非同步：各機器自己算、自己更新，靠參數伺服器（parameter server）存共同的模型參數。快但不穩

常見的策略

Agent Platform 怎麼分工

官方分散式訓練文件：你在 CustomJob 裡列出最多四個工作池（workerPoolSpecs[]），順序決定角色：

Agent Platform 會把這個結構寫進 CLUSTER_SPEC 或 TF_CONFIG 環境變數，程式讀它就知道自己是誰、同伴在哪。

Reduction Server：讓 GPU 少花時間傳梯度

多台 GPU 同步訓練時，每一步都要把梯度傳來傳去，機器越多、傳得越久。Google 的 Reduction Server 是專門幫忙「加總梯度」的一群便宜機器，讓 GPU 專心算。

官方的條件：GPU 工作者、TensorFlow 或 PyTorch 的多機訓練、容器要支援（預建的 TF／PyTorch 容器，或自訂容器裝 NCCL 2.7 以上和 Google 的 fast socket）。做法是在第三個工作池放 Reduction Server 的映像檔（asia-docker.pkg.dev/vertex-ai-restricted/training/reductionserver:latest），不用 GPU，官方建議用 n1-highcpu-16 這種頻寬高的機型，而且 reducer 的總出口頻寬要跟 worker 相當。

算一次給你看：多 GPU 到底省多少

飲料店的推薦模型，單張 T4 要跑 10 小時。改成 4 張 GPU 做同步資料平行（數字是教學假設）：

理想狀況：10 小時 ÷ 4 = 2.5 小時
實際有梯度交換的開銷，假設效率 85%
實際時間 = 10 ÷ (4 × 0.85) ≈ 2.9 小時

費用（假設一張 GPU 每小時 100 元，教學假設）：

1 張 × 10 小時 × 100 元 = 1,000 元
4 張 × 2.9 小時 × 100 元 = 1,176 元
多付 18%，換 3.4 倍快

再開 Spot VM（假設打 6 折）：

1,176 × 0.6 ≈ 706 元
比單張全價還便宜，而且快 3.4 倍

批次大小也要跟著變：每張 GPU 一批 64 張，4 張同時算，全局批次變成 64 × 4 = 256。批次變大，常見的做法是學習率（第 3 篇）也按比例調大，不然收斂會變慢。

數字怎麼看：

• 效率 85% 是「梯度交換」吃掉的，機器越多、網路越慢，這個數字越低。Reduction Server 就是在拉高它
• 加 GPU 不會無限變快：16 張時效率可能掉到 60%，10 ÷ (16 × 0.6) ≈ 1 小時，但費用 16 × 1 × 100 = 1,600 元。要時間就加機器，要省錢就少機器＋Spot
• Spot 的前提是程式會存檢查點（AIP_CHECKPOINT_DIR），被收回時才不用從頭來

5. 超參數調校：讓 Google 幫你試

第 15 篇講過 BigQuery ML 用 num_trials 自動試超參數。自訂訓練也有對應的服務：超參數調校工作（HyperparameterTuningJob）。

官方定義的三種資料：輸入資料（訓練資料）、參數（模型訓練中學到的權重）、超參數（控制訓練過程本身的設定，例如幾層、每層幾個節點、學習率）。超參數在一次訓練中通常固定，要調它就得跑很多次訓練。

怎麼運作

1. 你定義要調哪些超參數和範圍（例如學習率 0.0001 到 0.1、隱藏層 1 到 4 層）
2. 定義目標指標和方向（例如最大化準確率、最小化損失）
3. Agent Platform 跑很多次試驗（trial），每次用不同的值，記錄結果，用結果決定下一次試什麼
4. 跑完回報最好的那組和每一次的摘要

程式要配合兩件事

• 每個要調的超參數做成命令列參數（程式啟動時從外面給的值），用 argparse 接
• 用 cloudml-hypertune 套件的 report_hyperparameter_tuning_metric 把每次的分數回報給 Agent Platform

演算法

預設是貝氏最佳化（Bayesian optimization）：根據前幾次的結果，猜下一組最可能更好的值，比亂試省很多次。也可以選 GRID_SEARCH（格狀搜尋，所有組合都試）或 RANDOM_SEARCH（隨機）。官方還提到，對相似的模型反覆調校時，它會跨工作學習、越調越有效率。

另有條件式超參數：例如「訓練方法選 DNN 時才需要調層數」。

6. 兩種跑法：無伺服器訓練 vs 訓練叢集

第 14 篇提過，自訂訓練現在分兩種模式：

訓練叢集的官方文件補充的特色：用開源的 Slurm 介面（高效能運算界的標準排程工具）管工作；自動處理硬體故障（偵測錯誤、重啟或更換節點、從檢查點續跑）；內建 Llama、Gemma 這類模型的訓練配方。目前要聯絡業務申請才能用。

第三條路 Ray on Agent Platform：用開源的 Ray 框架做分散式 Python，本來就用 Ray 的團隊適合。

飲料店的推薦模型是每週重訓一次的正式工作、不能排隊 → 第 14 篇的練習情境選了訓練叢集；如果只是研究團隊的實驗，無伺服器訓練＋Spot 就好。

在 GCP 上怎麼做

整條流程

1. 寫程式：模型存到 AIP_MODEL_DIR，檢查點存到 AIP_CHECKPOINT_DIR，程式能從檢查點續跑（Spot 被收回、機器重啟都靠這個，官方文件有一節就叫「確保能承受重啟」）
2. 選容器：標準框架用預建容器＋Python 套件；特殊需求做自訂容器推到 Artifact Registry
3. 資料：Cloud Storage 或 BigQuery，跟訓練同一區域（第 13 篇）
4. 建 CustomJob：主控台、gcloud ai custom-jobs create、Python SDK 都行；設機型、GPU、台數、timeout、Spot
5. 多台：第二個工作池放 workers，有需要在第三個放 Reduction Server
6. 要調參：改建 HyperparameterTuningJob，程式加 cloudml-hypertune
7. 看進度：日誌在 Cloud Logging，TensorBoard 看曲線（第 22 篇）
8. 跑完：模型在 Cloud Storage，註冊到 Model Registry，部署（第 17 篇）

權限

訓練工作預設用 Agent Platform 的服務代理身分存取同專案的 Cloud Storage；要限制存取範圍，可以指定自訂的服務帳戶（給程式用的身分，第 12 篇提過）。

改名對照

考試會怎麼考

Google Cloud Professional Machine Learning Engineer（PMLE，專業機器學習工程師） 證照，2026 年 6 月 1 日起的官方考試指南裡，這篇的內容對應到：

看到這些字，就想到這個

六個常見陷阱

1. TPU 當萬靈丹：有自訂運算、需要高精度、分支多的程式，TPU 反而慢或跑不了
2. GPU 張數亂填：T4 只能 2 或 4 張，填 3 會失敗；機型 CPU 太小配 GPU 連日誌都出不來
3. 多 GPU 卻沒改程式：沒用分散式策略，4 張 GPU 只有 1 張在動
4. 用 Spot 卻不存檢查點：被收回就從頭來，省的錢全賠回去
5. 分散式工作池順序放錯：第 0 個一定是主要副本，第 2 個才是參數伺服器／Reduction Server
6. 調校時忘了回報指標：沒呼叫 report_hyperparameter_tuning_metric，Agent Platform 不知道哪組好

練習情境（自己出的練習，不是真實考題）

研究團隊用 PyTorch 寫了推薦模型，有自訂損失函數，單張 GPU 要跑 10 小時。他們想在 3 小時內跑完，預算有限，而且這只是實驗，可以中斷重跑。應該怎麼設？

判斷過程：

• 「PyTorch」「自訂損失函數」→ GPU（不是 TPU），預建 PyTorch GPU 容器
• 「3 小時內」→ 4 張 GPU 同步資料平行（DDP），一台 4 張用 MirroredStrategy 等級的設定就好，不用多台
• 「預算有限」「可以中斷」→ Spot VM，程式要存檢查點
• 無伺服器訓練即可，不需要訓練叢集

同一個模型要變成每週重訓的正式工作，資料成長到用 8 台機器、每台 8 張 GPU。工程師發現加了機器之後，每一步大部分時間在等梯度傳輸。應該怎麼做？

判斷過程：

• 「等梯度傳輸」「多節點 GPU」→ Reduction Server，放在 workerPoolSpecs[2]，用 n1-highcpu-16 不配 GPU
• 「正式工作」「每週」→ 考慮預留或訓練叢集保證有機器
• 容器要是預建 TF／PyTorch，或自訂容器裝 NCCL 2.7+

團隊要訓練一個標準架構的大型語言模型，要跑三週，沒有自訂運算，批次很大。應該選什麼硬體？

判斷過程：

• 「矩陣運算為主」「三週」「大批次」「沒有自訂運算」→ TPU
• 自訂訓練用 TPU：一個工作池、一個副本，選 v5e／v6e 機型＋tpuTopology
• 框架版本要符合（v5e 要 TensorFlow 2.15+ 或 PyTorch 2.1+ 或 JAX 0.4.6+）

常見問答

Vertex AI 自訂訓練是什麼？

你自己寫訓練程式（任何框架），打包成容器，Agent Platform 負責開虛擬機器、裝 GPU 或 TPU、跑程式、跑完收機器，只收用到的時間。流程是：寫程式、選預建或自訂容器、資料放同區域的 Cloud Storage、建 CustomJob 指定機型和台數、模型存到 Cloud Storage。Vertex AI 在 2026 年 4 月改名為 Gemini Enterprise Agent Platform，這個服務現在叫 Agent Platform Managed Training。

預建容器和自訂容器怎麼選？

預建容器是 Google 裝好的 TensorFlow、PyTorch、scikit-learn、XGBoost 映像檔，分 CPU 和 GPU 版，標準程式直接用、不用碰 Docker。四種情況才需要自訂容器：預建的沒有你要的框架或版本、有非 ML 的相依套件或二進位檔、想預先裝好相依套件讓啟動更快、要用任意框架做分散式訓練。GPU 用的自訂容器建議以 nvidia/cuda 當基底映像檔。

訓練該用 CPU、GPU 還是 TPU？

官方 TPU 簡介的指南：CPU 適合快速原型、小模型、很多自訂 C++ 運算、被 I/O 卡住的模型；GPU 適合有自訂 PyTorch 或 JAX 運算、用到 TPU 不支援的運算、中大型模型；TPU 適合矩陣運算為主、主訓練迴圈沒有自訂運算、要訓練幾週、大模型大批次、超大嵌入。TPU 不適合分支多、需要高精度、有自訂運算的程式。

資料平行和模型平行差在哪？

資料平行是每台機器都有完整的模型，各算不同的資料，每步把梯度加總平均再更新，絕大多數情況用這種；模型平行是模型太大一張 GPU 裝不下，把模型切成幾塊放不同機器，大型語言模型才需要。資料平行又分同步（all-reduce 等大家算完一起更新，GPU 間用 NCCL）和非同步（參數伺服器，各自更新）。

MultiWorkerMirroredStrategy 是什麼？

TensorFlow 的分散式策略之一，做多台機器、每台多張 GPU 的同步資料平行訓練：每台都有模型的完整複本，用 all-reduce 交換梯度。一台機器多張 GPU 用 MirroredStrategy，TPU 用 TPUStrategy，非同步的參數伺服器架構用 ParameterServerStrategy。PyTorch 對應的是 DistributedDataParallel。Agent Platform 會把機器結構寫進 TF_CONFIG 環境變數給程式讀。

Reduction Server 是什麼？

Google 提供的一群專門幫忙加總梯度的機器，讓多台 GPU 同步訓練時 GPU 不用花時間互傳梯度。條件是 GPU 工作者、TensorFlow 或 PyTorch 多機訓練、容器支援（預建 TF／PyTorch 容器或裝了 NCCL 2.7 以上的自訂容器）。做法是在 CustomJob 的第三個工作池放 Reduction Server 映像檔，不用 GPU，官方建議 n1-highcpu-16 這種頻寬高的機型。

Spot VM 可以用來訓練嗎？

可以，而且是省錢的主要方法。Spot VM 是 Google 多出來的閒置機器，大幅折扣，但隨時可能被收回。前提是訓練程式要定期把檢查點存到 AIP_CHECKPOINT_DIR，被收回重啟後從檢查點續跑。在 CustomJob 的 scheduling.strategy 設定。要保證有機器則用預留，GPU 不急可以用 Dynamic Workload Scheduler 排隊等。

自訂訓練怎麼調超參數？

建超參數調校工作（HyperparameterTuningJob）：定義要調的超參數和範圍、目標指標和方向（最大化準確率或最小化損失）、試驗次數。程式要把每個超參數做成命令列參數，並用 cloudml-hypertune 套件回報每次的指標。預設用貝氏最佳化，也可選格狀或隨機搜尋，還支援條件式超參數。BigQuery ML 的對應做法是 num_trials。

無伺服器訓練和訓練叢集差在哪？

無伺服器訓練是送出 CustomJob 後 Google 開機器、跑完收掉、用多少付多少，適合實驗和不需要保證馬上有機器的工作。訓練叢集是先保留一批專屬高階 GPU，用 Slurm 介面管工作、自動處理硬體故障、內建大模型訓練配方，適合大規模長時間的關鍵訓練，目前要聯絡業務申請。另有 Ray on Agent Platform 給用 Ray 框架的團隊。

訓練程式要存到哪裡？

Agent Platform 給三個環境變數：AIP_MODEL_DIR 存訓練完的模型（之後註冊到 Model Registry 直接用）、AIP_CHECKPOINT_DIR 存檢查點、AIP_TENSORBOARD_LOG_DIR 存 TensorBoard 紀錄，都是 Cloud Storage 路徑。訓練資料則掛在 /gcs/ 底下讀，要跟訓練同一個區域。

Vertex AI Training 改名了嗎？

是。Vertex AI 在 2026 年 4 月改名為 Gemini Enterprise Agent Platform，Vertex AI Training 改叫 Agent Platform Managed Training，底下分 Serverless Training（無伺服器訓練）和 Training Clusters（訓練叢集）。更早的 AI Platform Training 已在 2025 年 4 月 7 日關閉。舊題庫的 Vertex AI custom training 就是現在的 Agent Platform 自訂訓練，功能一樣。

重點整理

• 自訂訓練：自己寫程式、打包容器，Agent Platform 開機器、跑完收掉；舊名 Vertex AI Training，現在叫 Agent Platform Managed Training
• 容器：預建（TensorFlow、PyTorch、scikit-learn、XGBoost）夠用就不用自己做；框架不支援、特定版本、非 ML 相依、要更快啟動才做自訂容器，推到 Artifact Registry
• CustomJob：WorkerPoolSpec 設機型、GPU 種類與張數、台數、容器；程式用 AIP_MODEL_DIR、AIP_CHECKPOINT_DIR
• 硬體：CPU 原型小模型；GPU 自訂運算、中大型；TPU 矩陣運算為主、訓練數週、大批次，不適合自訂運算與高精度。GPU 要配 A2／N1／G2 機型、張數有固定選項
• 分散式：資料平行（同步 all-reduce、非同步參數伺服器）vs 模型平行；工作池順序＝角色（主要副本、工作者、參數伺服器／Reduction Server、評估者）；MultiWorkerMirroredStrategy、DDP
• 算一次：4 張 GPU 效率 85% → 2.9 小時，多付 18% 換 3.4 倍快；開 Spot 再打折，但要存檢查點
• 超參數調校工作：命令列參數＋cloudml-hypertune 回報指標，預設貝氏最佳化
• 兩種跑法：無伺服器訓練（計程車）vs 訓練叢集（包月租車，Slurm，要申請）

延伸閱讀

本系列

• 第 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 也能訓練模型
• 下一篇：第 17 篇：模型部署怎麼選？線上預測 vs 批次預測、流量分割

站上相關文章

• 如何在 GCP 上建立含 GPU 的 AI 開發環境
• 容器技術是什麼？從零開始看懂 Docker 與容器化應用
• Kubernetes 是什麼？白話解釋＋判斷你是否真的需要它
• Google VM 平台 Compute Engine 是什麼？
• 很多人嫌 GCP 的主機價格很貴？真的貴嗎？
• GCP 帳單爆炸防護指南

機器選對、程式打包好，模型才跑得起來、錢才花得值。如果你想有系統地從雲端基礎一路學到在 GCP 上動手做機器學習，可以看看東東的 GCP 課程，或加 LINE 聊聊你現在的狀況，一起找出最適合你的學習順序。

The post Vertex AI 自訂訓練：容器、分散式訓練、GPU 與 TPU first appeared on 東東 GCP 教學 - GCP 實戰講師.

上一篇說，資料已經在 BigQuery、團隊會 SQL，就用 BigQuery ML。這篇就把它從頭到尾做一遍：怎麼寫、它背後幫你做了什麼、資料怎麼切、超參數怎麼調、要花多少錢。

一樣用有 2,000 間分店、50 萬名會員的連鎖飲料店當例子（教學假設），要做的是會員流失預測：哪些會員下個月不會再來？會員表和交易表都已經在 BigQuery 裡。

為什麼你需要知道

• 最低門檻的機器學習：Google 官方簡介說得很直接，以前做 ML 要會 Python 和 ML 框架，把「最懂資料的人」排除在外；BigQuery ML 讓會 SQL 的人也能做。官方的「需要什麼知識」那段寫著：用預設設定，沒什麼 ML 知識也能建模型
• 資料不用搬：幾 TB 的表搬去 Python 環境，光搬就要半天。BigQuery ML 把 ML 帶到資料旁邊
• 前面 14 篇學的東西都用得上：資料切分（第 4 篇）、評估指標（第 5、6 篇）、過度擬合（第 7 篇）、類別不平衡（第 9 篇）、前處理（第 10 篇）、特徵工程（第 11 篇）在 BigQuery ML 裡都有對應的開關。這篇會一個一個對回去
• 證照必考：PMLE 考試指南第 1.1 節整節都是它：用 BigQuery ML 建分類、迴歸、預測、分群模型；用 BigQuery ML 做特徵工程和特徵選擇；用 BigQuery ML 產生預測

先搞懂：BigQuery ML 是什麼

白話是什麼

BigQuery ML：在 BigQuery 裡用 SQL 指令建立、訓練、使用機器學習模型。模型跟表格一樣存在 BigQuery 的資料集裡。

幾個名詞先講：

• BigQuery：Google 的資料倉儲，存大量表格資料、用 SQL 查，站上有BigQuery 是什麼
• SQL：查詢表格的語言。SELECT 姓名 FROM 會員表 WHERE 年齡 > 30 這種句子
• 資料集（dataset）：BigQuery 裡放表格的資料夾；表（table）就是一張表格；檢視（view）是存起來的查詢結果，看起來像表
• NULL：欄位裡的「空值」，代表沒填或不知道

比喻

倉庫旁邊的廚房（上一篇的比喻）。這篇要講的是這間廚房的爐子怎麼開、菜單上有什麼、哪些調味是自動的、瓦斯費怎麼算。

來龍去脈

BigQuery ML 剛推出時只有線性迴歸和邏輯迴歸兩種，現在官方清單已經有十幾種：監督式的線性／邏輯迴歸、DNN、Wide & Deep、提升樹、隨機森林、AutoML；非監督式的 K-means、矩陣分解、自動編碼器、PCA；時間序列的 ARIMA_PLUS；還能匯入外面訓練的模型、遠端呼叫 Gemini。

為什麼要學

這是 Google Cloud 上最快能看到結果的機器學習方式。會 SQL 的人，一個下午就能從資料表做出第一個模型。

1. 三句 SQL 做完一個模型

第 0 步：準備一張表

機器學習要的是「一列一個樣本、每欄一個特徵、其中一欄是答案」（第 3 篇）。先用 SQL 把會員表和交易表整理成這樣：

• visits_90d：最近 90 天來幾次；avg_spend：平均客單價；days_since_last：距離上次消費幾天；member_months：加入幾個月；city：城市
• churned：標籤，1 代表這位會員接下來一個月沒再來（流失），0 代表有來

答案欄怎麼來？用歷史資料「回頭看」：拿去年 6 月的會員狀態當特徵、7 月有沒有來當答案。這一步要小心資料洩漏（第 8 篇），特徵只能用 6 月以前知道的事。

第 1 句：CREATE MODEL 訓練

CREATE OR REPLACE MODEL `drink.churn_model`
OPTIONS (
  model_type = 'LOGISTIC_REG',
  input_label_cols = ['churned'],
  auto_class_weights = TRUE,
  enable_global_explain = TRUE
) AS
SELECT visits_90d, avg_spend, days_since_last, member_months, city, churned
FROM `drink.member_features`;

一行一行翻譯：

注意 member_id 沒有被 SELECT 進去。會員編號對「會不會流失」沒有意義，放進去只會讓模型記答案（第 7 篇過度擬合）。

第 2 句：ML.EVALUATE 評估

SELECT * FROM ML.EVALUATE(MODEL `drink.churn_model`);

不給它資料，它會自動用訓練時切出來的評估資料算分數（切法下一節講）。分類模型會回傳一列：

迴歸模型回傳的是 mean_absolute_error（MAE）、mean_squared_error、r2_score 這些（第 2 篇）。

要用別的門檻（第 6 篇），加 STRUCT(0.3 AS threshold) 這個參數；預設是 0.5。想看整張混淆矩陣用 ML.CONFUSION_MATRIX，想畫 ROC 曲線用 ML.ROC_CURVE。

第 3 句：ML.PREDICT 預測

SELECT member_id, predicted_churned, predicted_churned_probs
FROM ML.PREDICT(
  MODEL `drink.churn_model`,
  TABLE `drink.member_features_today`,
  STRUCT(0.3 AS threshold)
);

• 輸入是今天的會員特徵表，欄位名稱要跟訓練時一樣
• 輸出多兩欄：predicted_churned（預測的答案，0 或 1）和 predicted_churned_probs（每個類別的機率）。欄位名稱規則是 predicted_ 加上標籤欄的名字
• threshold 設 0.3：機率超過 30% 就判定會流失。流失預測寧可多抓（第 5 篇講的「追召回率」），門檻就調低

這是批次預測：一次對整張表算完，結果就是一張新的表，可以直接拿去寄挽留優惠。要做「會員一打開 App 就即時算」的線上預測，要走 Model Registry，第 17 篇講。

加碼：ML.EXPLAIN_PREDICT 看為什麼

SELECT * FROM ML.EXPLAIN_PREDICT(
  MODEL `drink.churn_model`,
  TABLE `drink.member_features_today`,
  STRUCT(3 AS top_k_features)
);

官方說明：它是 ML.PREDICT 的加強版，每一列多回傳「哪幾個特徵對這筆預測貢獻最大」，top_k_features 預設 5 個。例如 M002 被判會流失，是因為 days_since_last = 75（75 天沒來）貢獻最大。第 21 篇可解釋 AI 會細講。

筆記裡寫的「BQML.PREDICT」「BQML.EXPLAIN_PREDICT」，正確名稱是 ML.PREDICT 和 ML.EXPLAIN_PREDICT。

2. 它幫你自動做了什麼：前處理

第 10 篇講的標準化、遺失值、One-hot，BigQuery ML 在 CREATE MODEL 時預設就自動做。官方自動前處理文件：

遺失值（NULL）怎麼補

套回例子：某位會員 avg_spend 是 NULL（從沒消費過），自動補成所有會員的平均客單價。這不一定是你要的（沒消費過跟平均客單價差很多），要自己控制就用下面的 TRANSFORM。

特徵怎麼轉換

所以 city 這種文字欄直接丟進去就好，它會自動變成「台北、台中、高雄…」各一欄。

想自己控制：TRANSFORM 子句

第 11 篇講的特徵工程，用 TRANSFORM 寫在 CREATE MODEL 裡：

CREATE OR REPLACE MODEL `drink.churn_model_v2`
TRANSFORM (
  ML.QUANTILE_BUCKETIZE(avg_spend, 5) OVER () AS spend_bucket,
  ML.FEATURE_CROSS(STRUCT(city, spend_bucket)) AS city_x_spend,
  visits_90d, days_since_last, member_months, churned
)
OPTIONS (model_type = 'LOGISTIC_REG', input_label_cols = ['churned']) AS
SELECT * FROM `drink.member_features`;

• ML.QUANTILE_BUCKETIZE(avg_spend, 5)：客單價切成 5 個等人數的分桶（第 10 篇）
• ML.FEATURE_CROSS：城市 × 客單價桶的特徵交叉（第 11 篇）
• 官方手動前處理文件列的函數還有 ML.STANDARD_SCALER、ML.MIN_MAX_SCALER、ML.BUCKETIZE、ML.IMPUTER（自己決定遺失值怎麼補）、ML.NGRAMS 等

TRANSFORM 最大的好處：訓練時怎麼轉，ML.PREDICT 時自動用同樣的方式轉，連分桶的切點都沿用訓練時算的。這正是第 10 篇講的「訓練和上線前後不一致」（training-serving skew，第 20 篇會再講）的解法。官方特別寫了一句：分析函數在 TRANSFORM 裡用，訓練時收集的統計值會自動套用到預測輸入。

想把「轉換」和「訓練」分開管理，可以建一個只做轉換的模型（transform-only model），用 ML.TRANSFORM 看它轉出來的結果長什麼樣。

3. 資料怎麼切：AUTO_SPLIT 的規則

第 4 篇講過訓練集、驗證集要分開。BigQuery ML 用 DATA_SPLIT_METHOD 選項控制，官方說明的預設值是 AUTO_SPLIT，規則是：

算一次

飲料店 50 萬名會員 → 超過 50,000 列
評估資料 = 10,000 列（固定）
訓練資料 = 500,000 − 10,000 = 490,000 列
評估比例 = 10,000 ÷ 500,000 = 2%

資料越多，評估比例越小，因為 10,000 列已經夠算出穩定的分數，多切只是浪費訓練資料。

其他切法

官方邏輯迴歸教學用的就是自己切：加一欄 dataframe，標 training、evaluation、prediction 三種，訓練時只選 training 的列，評估時把 evaluation 的列餵給 ML.EVALUATE。

評估資料的用途，官方寫得很清楚：用提前停止來避免過度擬合（第 7 篇）。每一輪訓練完看評估資料的損失有沒有進步，進步幅度小於 MIN_REL_PROGRESS 就停，開關是 EARLY_STOP（預設開）。

4. 超參數怎麼調

第 3 篇說超參數是「訓練前自己決定的設定」，例如正則化強度 L1_REG、L2_REG（第 7 篇）、學習率。手動一個一個試很累，BigQuery ML 的超參數調校讓它自己試：

CREATE OR REPLACE MODEL `drink.churn_model_tuned`
OPTIONS (
  model_type = 'LOGISTIC_REG',
  input_label_cols = ['churned'],
  num_trials = 20,
  l1_reg = HPARAM_RANGE(0, 1),
  l2_reg = HPARAM_CANDIDATES([0, 0.1, 1, 10])
) AS
SELECT * FROM `drink.member_features`;

• num_trials = 20：試 20 組
• HPARAM_RANGE(0, 1)：在 0 到 1 之間找
• HPARAM_CANDIDATES([...])：從這幾個值裡挑
• 跑完用 ML.TRIAL_INFO 看每一組的分數，ML.EVALUATE 預設回傳最好的那組

支援調校的模型：線性／邏輯迴歸、K-means、矩陣分解、自動編碼器、提升樹、隨機森林、DNN、Wide & Deep。AutoML 本來就內建自動調校；ARIMA_PLUS 用 AUTO_ARIMA 自動找趨勢參數。

5. 不只分類：時間序列和分群

時間序列：ARIMA_PLUS

飲料店要預測每間分店未來 30 天的銷量，官方教學的寫法：

CREATE OR REPLACE MODEL `drink.sales_forecast`
OPTIONS (
  model_type = 'ARIMA_PLUS',
  time_series_timestamp_col = 'sale_date',
  time_series_data_col = 'daily_sales',
  time_series_id_col = 'store_id',
  holiday_region = 'TW'
) AS
SELECT sale_date, daily_sales, store_id FROM `drink.daily_sales`;

SELECT * FROM ML.FORECAST(MODEL `drink.sales_forecast`,
  STRUCT(30 AS horizon, 0.8 AS confidence_level));

• time_series_id_col：一次幫 2,000 間分店各做一個模型
• holiday_region：把台灣的假日效應算進去（官方教學用美國假日舉例）
• ML.FORECAST 的 horizon = 30 是預測未來 30 天，confidence_level = 0.8 是給 80% 的預測區間（上下界）
• 官方簡介提到，ARIMA_PLUS 會自動處理異常值、季節性、假日；ML.EXPLAIN_FORECAST 可以把趨勢、季節性拆開看

不想管模型，官方簡介說可以用 AI.FORECAST 函數搭內建的 TimesFM 模型（預覽階段）直接預測。

分群：K-means

不知道會員分幾種，想讓模型自己找（第 1 篇的非監督式學習）：model_type = 'KMEANS'，不用 input_label_cols，因為沒有答案。預測結果是每位會員屬於哪一群（CENTROID_ID），ML.CENTROIDS 看每一群的中心長什麼樣。

推薦：矩陣分解

「猜你想點」：model_type = 'MATRIX_FACTORIZATION'，輸入是「誰買過什麼、評幾分」，ML.RECOMMEND 回傳每位會員對每種飲料的預測評分。官方定價頁註明矩陣分解只開放給 Editions 或有保留算力的客戶。

要更強的模型

BOOSTED_TREE_CLASSIFIER（XGBoost）、DNN_CLASSIFIER、AUTOML_CLASSIFIER 這些寫法一樣是 SQL，但官方簡介說它們是「在 Agent Platform 訓練」：BigQuery 把工作送去 Agent Platform（原 Vertex AI）算完再拿回來。你感覺不到差別，只有費用算法不同（下一節）。

6. 要花多少錢：算一次

官方定價頁的 BigQuery ML 段落，重點是：

• 按量計費（on-demand）時，依「操作類型」收費：建模型、評估、檢查、預測各有價格
• 評估、檢查、預測跟一般查詢同價，而且算在每月 1 TiB 的免費額度裡
• 建模型（CREATE MODEL）是另一個價格，依輸入查詢處理的資料量計算
• 超參數調校：每一組試驗都是一次建模型，費用是所有試驗的總和
• 時間序列開 auto-ARIMA：會試很多候選模型，處理的位元組數要乘上候選模型數（AUTO_ARIMA_MAX_ORDER 設 5 時最多 42 個）
• 迭代式模型最多跑 50 輪就停
• 用 Editions（買算力）的話，BigQuery ML 包含在裡面；外部訓練的模型（DNN、提升樹、AutoML）要另外用 ML_EXTERNAL 類型的保留算力

官方頁面有一個計算範例，美國多區域的建模型價格是每 TiB 312.5 美元。套到飲料店（台灣區域價格請看定價頁，這裡用官方範例的數字）：

會員特徵表 2 GB
建模型費用 = 2 ÷ 1,024 TiB × 312.5 美元 ≈ 0.61 美元

超參數調校 20 組試驗
= 20 × 0.61 ≈ 12.2 美元

ARIMA_PLUS 開 auto-ARIMA、AUTO_ARIMA_MAX_ORDER = 5
銷售表 500 MB × 42 個候選模型 = 21 GB 的處理量
≈ 21 ÷ 1,024 × 312.5 ≈ 6.4 美元

數字怎麼看：

• 一個 2 GB 的表建模型不到 1 美元，這就是「最快看到結果」的代價，很便宜
• 超參數調校和 auto-ARIMA 是倍數在長，試驗組數和候選模型數決定費用
• ML.PREDICT 對 50 萬列預測，就是掃一次表的查詢費，通常在免費額度內
• 內建模型可以先 dry run（試跑不執行）估處理量；外部訓練的模型不能

站上有一篇 BigQuery 計費方式，按量和 Editions 的差別那篇講得更細。

在 GCP 上怎麼做

1. 從哪裡下 SQL

官方簡介列的入口：Google Cloud 主控台的查詢編輯器、bq 命令列工具、REST API、BigQuery 裡的 Colab Enterprise 筆記本、外部工具（Jupyter、BI 平台）。會 Python 的人也可以用 BigQuery DataFrames（bigframes），官方教學每一步都有 SQL 和 DataFrames 兩種寫法。

2. 資料先進 BigQuery

CSV、Cloud Storage、串流、其他資料庫都有辦法，站上有一篇把資料上傳到 BigQuery 的各種方法。

3. 要線上預測：註冊到 Model Registry

ML.PREDICT 是批次。要做「App 一打開就即時算流失機率」，官方文件的做法是在 CREATE MODEL 加上：

OPTIONS (
  model_type = 'LOGISTIC_REG',
  input_label_cols = ['churned'],
  model_registry = 'VERTEX_AI',
  vertex_ai_model_id = 'churn_model'
)

模型會自動註冊到 Agent Platform 的 Model Registry，不用匯出、不用自己做服務容器，就能部署成端點做線上預測、管版本。需要 roles/aiplatform.admin 權限，而且要先開 Agent Platform API。部署的細節第 17 篇講。

4. 改名對照

考試會怎麼考

Google Cloud Professional Machine Learning Engineer（PMLE，專業機器學習工程師） 證照，2026 年 6 月 1 日起的官方考試指南裡，這篇的內容對應到：

看到這些字，就想到這個

六個常見陷阱

1. 把會員編號當特徵丟進去：模型會記答案，評估分數虛高、上線沒用
2. 時間序列用預設的 AUTO_SPLIT：預設是隨機切，未來的資料會混進訓練集（第 4、8 篇），要用 SEQ
3. 訓練前自己在外面做標準化，預測時忘了做：訓練和上線不一致。放進 TRANSFORM 就不會忘
4. 不平衡資料忘了 auto_class_weights：模型全猜「不流失」也有 95% 準確率，召回率卻是 0
5. 以為 ML.PREDICT 是即時的：它是批次，線上預測要走 Model Registry 部署端點
6. 超參數調校的費用當成一次：是試驗組數的倍數

練習情境（自己出的練習，不是真實考題）

飲料店的分析師要用 BigQuery 裡的會員資料預測流失，流失會員只佔 5%。她希望寧可多抓一些可能流失的人，也不要漏掉。應該怎麼設定？

判斷過程：

• 「BigQuery 裡」「分析師」→ BigQuery ML，LOGISTIC_REG
• 「只佔 5%」→ auto_class_weights = TRUE
• 「寧可多抓」→ 追召回率，ML.PREDICT 的 threshold 調低（例如 0.3），用 ML.EVALUATE 加同樣的 threshold 確認召回率

同一家店要預測每間分店未來兩週的日銷量，資料是過去三年的每日銷售表。分析師直接用預設設定訓練，發現評估分數好得不像真的。問題出在哪？

判斷過程：

• 「好得不像真的」→ 懷疑資料洩漏（第 8 篇）
• 「時間序列」「預設設定」→ AUTO_SPLIT 是隨機切，未來的資料跑進訓練集
• 解法：用 ARIMA_PLUS 這類時間序列模型，或一般模型改 data_split_method = 'SEQ' 依時間切

模型上線後，工程師發現預測結果跟訓練時差很多。追查發現訓練前分析師用 Python 把客單價做了分桶，但上線時的 SQL 沒有分桶。怎麼避免？

判斷過程：

• 「訓練和上線的前處理不一樣」→ 訓練／服務偏差（第 20 篇）
• 解法：把分桶寫進 CREATE MODEL 的 TRANSFORM 子句（ML.QUANTILE_BUCKETIZE），ML.PREDICT 會自動用訓練時的切點

常見問答

BigQuery ML 怎麼入門？

三句 SQL：CREATE MODEL 指定模型類型和標籤欄、用 SELECT 給訓練資料；ML.EVALUATE 看精確率、召回率、AUC 這些分數；ML.PREDICT 對一張表批次預測，輸出多兩欄 predicted_標籤名 和機率。資料全程留在 BigQuery，不用寫 Python。官方的邏輯迴歸教學用美國人口普查資料走一遍，照著做一個下午就能完成。

BigQuery ML 支援哪些模型？

內建的有線性迴歸、邏輯迴歸、K-means 分群、矩陣分解（推薦）、PCA、ARIMA_PLUS 時間序列、貢獻分析；透過 Agent Platform 訓練的有 DNN、Wide & Deep、自動編碼器、提升樹（XGBoost）、隨機森林、AutoML；還能匯入 TensorFlow、ONNX、XGBoost 模型，或遠端呼叫 Gemini。寫法都是 CREATE MODEL 加 model_type。

BigQuery ML 會自動做前處理嗎？

會。訓練時數字欄自動標準化（提升樹和隨機森林除外），文字、布林、日期欄自動 One-hot 編碼，時間戳記自動拆成年月星期等，NULL 數字補平均值、NULL 類別當成額外的類別。想自己控制就用 TRANSFORM 子句，裡面可以用 ML.STANDARD_SCALER、ML.BUCKETIZE、ML.FEATURE_CROSS、ML.IMPUTER 等函數，而且預測時會自動套用同樣的轉換。

BigQuery ML 的資料怎麼切訓練集和評估集？

預設 AUTO_SPLIT：少於 500 列全部訓練；500 到 50,000 列隨機切 20% 評估；超過 50,000 列固定抽 10,000 列評估；有開超參數調校則 80% 訓練、10% 評估、10% 測試。時間序列資料要改用 SEQ 依順序切，否則未來的資料會混進訓練集。也可以用 CUSTOM 自己標，或 NO_SPLIT 另外準備評估資料。

BigQuery ML 怎麼處理類別不平衡？

邏輯迴歸模型在 CREATE MODEL 加 auto_class_weights = TRUE，它會依每個類別出現頻率的反比加權，少數類別的每一筆都算比較重。另外在 ML.PREDICT 和 ML.EVALUATE 用 threshold 參數調門檻，流失預測這種寧可多抓的情境把門檻調低。

ML.PREDICT 和 ML.EXPLAIN_PREDICT 差在哪？

ML.PREDICT 只給預測結果和機率；ML.EXPLAIN_PREDICT 是它的加強版，每一列多回傳貢獻最大的幾個特徵和貢獻值，top_k_features 預設 5 個。想看模型整體哪些特徵最重要，訓練時開 enable_global_explain，再用 ML.GLOBAL_EXPLAIN 查。筆記裡的 BQML.PREDICT、BQML.EXPLAIN_PREDICT 是舊寫法，正確名稱是 ML.PREDICT、ML.EXPLAIN_PREDICT。

BigQuery ML 可以調超參數嗎？

可以。CREATE MODEL 設 num_trials 指定試幾組，超參數用 HPARAM_RANGE 給範圍或 HPARAM_CANDIDATES 給候選值，跑完用 ML.TRIAL_INFO 看每組分數。支援線性／邏輯迴歸、K-means、矩陣分解、自動編碼器、提升樹、隨機森林、DNN、Wide & Deep。費用是每一組試驗的總和。

BigQuery ML 能做時間序列預測嗎？

能。model_type 設 ARIMA_PLUS，指定時間欄和數值欄，用 time_series_id_col 可以一次對很多個序列（例如每間分店）各建一個模型，holiday_region 加入假日效應。預測用 ML.FORECAST 給 horizon（預測幾期）和 confidence_level（預測區間）。它會自動處理異常值、季節性、假日。不想管模型可以用 AI.FORECAST 搭內建的 TimesFM。

BigQuery ML 要多少錢？

按量計費時，評估和預測跟一般查詢同價，算在每月 1 TiB 免費額度內；建模型另外計價，依輸入查詢處理的資料量算，官方範例美國多區域是每 TiB 312.5 美元，2 GB 的表約 0.61 美元。超參數調校是試驗組數的倍數，auto-ARIMA 是候選模型數的倍數。用 Editions 的話 BigQuery ML 包在裡面，外部訓練的模型要用 ML_EXTERNAL 保留算力。

BigQuery ML 的預測是即時的嗎？

ML.PREDICT 是批次預測，一次對整張表算完。要做即時的線上預測，在 CREATE MODEL 加 model_registry = ‘VERTEX_AI’ 把模型註冊到 Agent Platform 的 Model Registry，不用匯出、不用自己做服務容器，就能部署成端點。

不會寫 SQL 能用 BigQuery ML 嗎？

官方簡介提到 Google Cloud 主控台有圖形介面可以操作模型（預覽階段），也可以用 BigQuery DataFrames 寫 Python。但 BigQuery ML 的設計初衷就是給會 SQL 的人，SQL 是它最完整的介面，建議至少學會 SELECT、WHERE、GROUP BY 這幾個基本句型。

重點整理

• 三句 SQL：CREATE MODEL（model_type＋input_label_cols＋AS SELECT）→ ML.EVALUATE（precision、recall、roc_auc…）→ ML.PREDICT（predicted_標籤名＋機率，threshold 可調）
• 自動前處理：數字標準化、類別 One-hot、NULL 補平均值或當額外類別；要自己控制用 TRANSFORM，預測時自動套用同樣轉換，解決訓練／服務偏差
• 資料切分：AUTO_SPLIT 預設 < 500 全訓練、500～50,000 切 20%、> 50,000 抽 10,000 列；時間序列用 SEQ
• 不平衡：auto_class_weights = TRUE；超參數：num_trials＋HPARAM_RANGE／HPARAM_CANDIDATES
• 其他模型：ARIMA_PLUS＋ML.FORECAST（時間序列）、KMEANS（分群）、MATRIX_FACTORIZATION（推薦）、BOOSTED_TREE／DNN／AUTOML（在 Agent Platform 訓練）
• 費用：評估、預測同一般查詢價；建模型依處理量另計；調校和 auto-ARIMA 是倍數
• 線上預測：model_registry = 'VERTEX_AI' 註冊到 Model Registry 再部署端點；函數名稱是 ML.PREDICT 不是 BQML.PREDICT

延伸閱讀

本系列

• 第 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、自訂訓練怎麼選？
• 下一篇：第 16 篇：Vertex AI 自訂訓練：容器、分散式訓練、GPU 與 TPU

站上相關文章

• BigQuery 是什麼？功能、組成元件、特色和優勢完整介紹
• BigQuery 是資料庫嗎？跟資料庫差在哪
• 把資料上傳到 BigQuery 的各種方法和步驟
• BigQuery 計費方式完整介紹
• BigQuery 成功案例：Home Depot 導入 GCP 的案例解析
• GCP 證照 Data Engineer 怎麼考？

會 SQL 就能做機器學習，這是最低門檻的起點。如果你想有系統地從雲端基礎一路學到在 GCP 上動手做機器學習，可以看看東東的 GCP 課程，或加 LINE 聊聊你現在的狀況，一起找出最適合你的學習順序。

The post BigQuery ML 入門：只會 SQL 也能訓練模型 first appeared on 東東 GCP 教學 - GCP 實戰講師.