模型上線後會變笨，因為資料變了：跟訓練時不一樣叫偏差，隨時間變叫漂移，Model Monitoring 量距離超過門檻就警報。
前兩篇把模型做成管線、自動重訓、自動上線。但有一件事還沒處理：模型上線之後，怎麼知道它還準不準？ 沒人盯，模型會在你不知道的情況下慢慢變笨，推薦越來越不準、流失名單越來越離譜，等到老闆問才發現。
一樣用有 2,000 間分店、50 萬名會員的連鎖飲料店當例子（教學假設）：會員流失模型和推薦模型都上線了，這篇講怎麼監控它們。
為什麼你需要知道
- Google 自己的例子：Model Monitoring 總覽說，預測客戶終身價值的模型，客戶習慣一變，當初用來訓練的特徵可能就不再適用。這種資料的偏移叫漂移
- 等級 0 的致命傷：第 18 篇講 MLOps 等級 0 時，官方列的問題之一就是「沒有主動監控模型效能」。模型壞了沒人知道，是最常見的事故
- 監控是重訓的觸發器：第 19 篇的「效能下降就重訓」「漂移就重訓」，靠的就是這篇的警報
- 證照必考：PMLE 考試指南第 6 區「監控 AI 方案」佔 13%，6.2 直接寫「設定和使用 Model Monitoring 建立正式模型的持續評估指標」「監控常見問題（訓練／服務偏差、資料漂移、概念漂移、特徵歸因漂移）」；6.1 的「監控偏見」也在這篇
先搞懂：模型變笨的四種方式
白話是什麼
模型是用過去的資料學出來的規則。世界一變，規則就不準。官方和考試指南把「變」分成四種：
| 名稱 | 白話 | 什麼變了 | 飲料店 |
|---|---|---|---|
| 訓練／服務偏差（training-serving skew） | 上線時餵的資料，跟訓練時的不一樣 | 訓練 vs 上線 | 訓練時客單價單位是「元」，上線 API 傳來的是「百元」 |
| 資料漂移（data drift，也叫 feature drift） | 上線後，輸入資料的分布隨時間變了 | 上線初期 vs 現在 | 夏天來了，冰飲比例從 40% 變 80% |
| 概念漂移（concept drift） | 輸入沒變，但輸入和答案的關係變了 | 規則本身 | 疫情後，「兩週沒來」不再代表流失，因為大家都改外送 |
| 特徵歸因漂移（feature attribution drift） | 哪些特徵重要變了 | 模型的依據 | 以前「距上次消費天數」最重要，現在變成「是否用外送」 |
另外還有預測漂移（prediction drift）：模型輸出的分布變了，例如判「會流失」的比例從 5% 跳到 30%。它是結果，前四種是原因。
比喻
流感快篩試劑：
- 偏差：試劑是用成年人的樣本校正的，結果拿去給嬰兒用（訓練和上線的對象不同）
- 資料漂移：今年流行的病毒株變了，試劑對新株不敏感（輸入資料變了）
- 概念漂移：以前「發燒」幾乎等於流感，現在很多發燒是別的病（症狀和疾病的關係變了）
來龍去脈
Google 的機器學習規則對訓練／服務偏差的定義：「訓練時的表現和服務時的表現之間的差異」，原因有兩種：
- 訓練和服務的管線處理資料的方式不一樣
- 訓練和服務之間，資料本身變了
第 1 種是工程問題（第 10、15 篇講的前處理不一致），第 2 種就是漂移。Model Monitoring 主要抓第 2 種。
為什麼要學
考試 6.2 把這四個詞並列，題目會描述一個症狀問你「這是哪一種、該怎麼辦」。認得出來，才知道該修程式（偏差）、該重訓（漂移）、還是該重新定義問題（概念漂移）。
1. 偏差的第一種原因：訓練和上線的處理不一樣
這一種監控抓不到，因為資料看起來「正常」，只是單位、編碼、順序不一樣。要在設計時就防：
| 做法 | 本系列哪一篇 |
|---|---|
| BigQuery ML 的 TRANSFORM 子句：訓練怎麼轉，預測自動一樣轉 | 第 15 篇 |
| TFX 的 Transform（TFT）：前處理寫一次，訓練和服務共用 | 第 18 篇 |
| Feature Store：特徵算一次存起來，訓練和線上都從這裡拿 | 第 23 篇 |
| 機器學習規則第 29 條：把服務時用的特徵記下來，拿去訓練，就能比對一致性 | |
| 機器學習規則第 32 條：訓練和服務的程式碼盡量共用 |
飲料店那個「元 vs 百元」的錯，上線第一天流失模型就會把所有人判成「會流失」，監控會看到預測漂移（判流失的比例暴增），但根本原因要回去查管線。
2. Model Monitoring 怎麼量「變了多少」
白話是什麼
Model Monitoring（Vertex AI Model Monitoring，現在叫 Model Monitoring on Gemini Enterprise Agent Platform）：Google 的服務，定期把上線時收到的請求拿來跟基準比，算一個「差多少」的分數，超過門檻就通知你。
兩個版本
官方總覽說有兩個版本：
| v1（正式版，GA） | v2（預覽） | |
|---|---|---|
| 綁在哪 | Agent Platform 的端點上 | 模型版本上 |
| 監控什麼 | 線上推論的輸入特徵 | 線上、批次、甚至不在 Agent Platform 上的模型 |
| 目標 | 偏差、漂移 | 輸入特徵漂移、輸出推論漂移、特徵歸因 |
| 建議 | 需要正式支援、模型部署在端點 | 其他情況 |
v1 不用遷移，兩版可以並行。筆記裡的「Vertex AI Model Monitoring 監測 Prediction Drift／Feature Drift／Training-Serving Skew」對應的是 v1 的偏差與漂移，加上 v2 的輸出漂移。
v1 的流程
官方說明：
- 模型部署到端點、開啟監控後，每一筆推論請求記錄到 BigQuery 表
- 依取樣率抽一部分來分析（省錢）
- 每個監控視窗（預設 24 小時，最小 1 小時）算一次最近請求的特徵分布
- 跟基準分布比：
- 偏差偵測的基準＝訓練資料的分布（所以要提供訓練資料的 BigQuery 或 Cloud Storage 路徑）
- 漂移偵測的基準＝過去在上線環境看到的分布（沒有訓練資料也能用）
- 算距離分數：類別特徵用 L-infinity 距離，數值特徵用 Jensen-Shannon 散度
- 分數超過警報門檻（預設每個特徵 0.3，可各自設）→ 寄 email、寫 Cloud Logging、送 Cloud Monitoring 的通知管道（PagerDuty、Slack、Pub/Sub）
- Pub/Sub 接第 19 篇的 Cloud Run 函式 → 自動重訓
分布怎麼算：類別特徵數每個值的比例；數值特徵把範圍切成等寬區間、數每個區間的比例。基準在建監控工作時算一次，之後只有更新訓練資料才重算。自訂模型要給分析結構描述（schema），沒給的話監控會等前 1,000 筆請求自動解析。
支援哪些模型
v1 只支援表格模型：AutoML 表格，或匯入的自訂表格模型；同一端點上的模型都要是這兩種。影像、文字模型要用別的方法（例如自己記錄預測、定期人工抽查）。
3. 算一次給你看：L-infinity 距離
L-infinity 距離：兩個分布裡，每個類別的比例差，取最大的那個。白話：找出「差最多的那一格」。
流失模型的特徵 city（城市），訓練資料的分布：
| 城市 | 訓練資料 | 第 1 個月上線 | 差 |
|---|---|---|---|
| 台北 | 50% | 35% | 0.15 |
| 台中 | 30% | 30% | 0.00 |
| 高雄 | 20% | 35% | 0.15 |
L-infinity = max(0.15, 0.00, 0.15) = 0.15
0.15 < 門檻 0.3 → 不警報第 6 個月（高雄大舉展店）：
| 城市 | 訓練資料 | 第 6 個月上線 | 差 |
|---|---|---|---|
| 台北 | 50% | 10% | 0.40 |
| 台中 | 30% | 30% | 0.00 |
| 高雄 | 20% | 60% | 0.40 |
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 的考量」列了三個可以調的東西：
| 旋鈕 | 預設 | 調低 | 調高 |
|---|---|---|---|
| 警報門檻 | 每個特徵 0.3 | 更敏感，但誤報多 | 省心，但漏掉小變化 |
| 監控視窗（頻率） | 24 小時 | 反應快，但單一視窗樣本少、噪音大 | 穩定，但發現得慢 |
| 取樣率 | 自己設 | 省錢，但小變化看不到 | 準，但 BigQuery 記錄和分析費用高 |
飲料店的做法：推薦模型一天 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：端點上開監控
- 模型（表格 AutoML 或自訂表格）部署到端點
- 建監控工作：選偏差（要給訓練資料的 BigQuery 或 Cloud Storage 路徑）和／或漂移；設每個特徵的門檻（或用預設 0.3）、監控視窗、取樣率、email、通知管道
- 自訂模型給分析結構描述，或等前 1,000 筆自動解析
- 主控台看每個特徵的分布隨時間變化
- 警報 → 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_trainv2：模型版本上建監控器
- 模型註冊到 Model Registry（不在 Agent Platform 上服務的模型也可以，不用上傳模型檔）
- 建模型監控器（model monitor）綁模型版本，定義 schema（AutoML 自動有）
- 設預設的監控目標（輸入漂移、輸出漂移、特徵歸因）、訓練資料集當基準、輸出位置、通知
- 跑一次性或排程的監控工作，指標畫成時間序列
- 預覽期間 v2 本身不收費，但 BigQuery、Cloud Storage、批次推論、Cloud Logging 照收
改名對照
| 舊名稱（筆記、舊題庫） | 現在 |
|---|---|
| Vertex AI Model Monitoring | Model Monitoring on Gemini Enterprise Agent Platform（v1 GA、v2 預覽） |
| Vertex Explainable AI（特徵歸因用） | 2026 年 3 月淘汰、2027 年 3 月停用，改用 SHAP、LIME |
| Prediction Drift | Output Inference Drift（v2 的叫法） |
| Continuous Evaluation（舊的獨立功能） | 用 Model Monitoring v2 的排程工作和自己的 BigQuery 查詢實作 |
考試會怎麼考
Google Cloud Professional Machine Learning Engineer（PMLE，專業機器學習工程師） 證照，2026 年 6 月 1 日起的官方考試指南裡，這篇的內容對應到：
| 考試區塊 | 跟這篇有關的項目 |
|---|---|
| 第 6 區：監控 AI 方案（約 13%） | 6.1 符合負責任 AI 實務（監控偏見）。6.2 設定和使用 Model Monitoring 建立正式模型的持續評估指標；監控常見問題（訓練／服務偏差、資料漂移、概念漂移、特徵歸因漂移）；監控、測試、評估生成式 AI 方案 |
| 第 5 區：自動化與編排（約 18%） | 5.1 確保訓練和服務的前處理一致（偏差的第 1 種原因）；5.2 重訓政策（監控觸發） |
看到這些字，就想到這個
| 題目出現的關鍵字 | 想到 |
|---|---|
| 「上線的輸入分布跟訓練資料不一樣」「有訓練資料可以比」 | 訓練／服務偏差偵測，給訓練資料路徑 |
| 「上線後輸入分布隨時間變」「沒有訓練資料」 | 資料漂移偵測，基準是過去的上線資料 |
| 「輸入看起來正常，但準確率掉了」 | 概念漂移，要持續評估（等真實標籤） |
| 「重要特徵的貢獻突然變了」 | 特徵歸因漂移（v2，SHAP） |
| 「預測為正的比例突然暴增」 | 預測／輸出漂移，先查上游管線有沒有壞 |
| 「訓練時標準化、上線時沒有」「單位不一樣」 | 偏差的第 1 種原因：TRANSFORM、TFT、Feature Store、共用程式碼 |
| 「類別特徵的距離」 | L-infinity |
| 「數值特徵的距離」 | Jensen-Shannon 散度 |
| 「警報太多」 | 門檻調高、視窗拉長 |
| 「監控費用太高」 | 降取樣率 |
| 「警報要自動觸發重訓」 | email 以外，Cloud Logging → Pub/Sub → 重訓管線 |
| 「模型不是部署在 Agent Platform 端點」「批次推論也要監控」 | Model Monitoring v2 |
| 「某個群體被系統性誤判」 | 偏見：分段評估、特徵歸因監控 |
| 「大型語言模型的輸出品質」 | LLM-as-a-judge、人工抽查、Model Armor |
六個常見陷阱
- 以為輸入分布正常就沒事：概念漂移監控看不到，要持續評估
- 沒有訓練資料卻選偏差偵測：偏差要訓練資料當基準，沒有就用漂移
- 所有特徵都用預設 0.3：重要特徵要更敏感
- 一有警報就重訓：先查是不是上游管線壞了（偏差第 1 種原因），重訓不會修好程式錯誤
- 用 v1 監控影像模型：v1 只支援表格模型
- 警報只寄 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 聊聊你現在的狀況，一起找出最適合你的學習順序。