AI 方法論知識地圖 · 部署與維運

建立 CI/CD

持續整合/部署

在互動地圖中開啟 回AI 方法論知識地圖

觀念教學

模型改一版就要重測、重打包、重上線 — 手動做十次總會出一次包,CI/CD 把這條路鋪成自動化輸送帶。

核心觀念

CI/CD(Continuous Integration / Continuous Deployment,持續整合/持續部署)自動化模型的訓練、測試、部署流程:程式或資料一更新,管線自動跑版本控制 → 自動測試 → 模型註冊 → 自動部署。在 MLOps 裡再加上 CT(持續訓練),三個「持續」才算完整閉環。

白話理解

金融風控團隊每週更新模型:工程師推送新程式,CI 自動跑程式測試與資料驗證;通過後 CD 自動把新模型註冊、部署到預備環境,再漸進切流量。人只負責審核,不負責搬運。

管線四站

  • 版本控制:程式、資料、模型組態全部進版控,壞了能回滾
  • 自動測試:除了測程式,還要驗資料品質與模型效能門檻 — 這是 ML 管線比純軟體多出的部分
  • 模型註冊:通過驗證的模型存入註冊表,記錄版本與指標
  • 自動部署:金絲雀(Canary)或藍綠部署漸進上線,出事秒回滾

管線健康度用三個指標量:部署頻率(多久能上一版)、部署成功率(上版不翻車的比例)、Lead Time(從提交到上線的時間)。

🎯 口訣:CI 管整合測試、CD 管自動上線、CT 管自動重練 — 少一個都不算閉環。

iPAS 考點

考縮寫對應:CI = 持續整合(測試程式與資料)、CD = 持續交付/部署(自動部署模型)、CT = 持續訓練(自動觸發再訓練)。陷阱是把 CT 說成傳統 DevOps 原有環節 — 錯,CT 是 MLOps 才加上的。情境題給「模型更新頻繁、人工部署常出錯」,答案方向就是建立 CI/CD 自動化管線。

應用場景

模型版本控制自動化測試模型註冊 (Model Registry)Pipeline 自動化

評估指標

部署頻率部署成功率Lead Time

iPAS 歷屆考題詳解(3 題)

先自行作答,再展開詳解。題目出處均為 iPAS AI 應用規劃師正式考題,著作權屬原主辦單位。

114年第二梯次中級AI應用規劃師第一科人工智慧技術應用與規劃 第29題

某AI開發團隊為提升模型開發效率及品質控制,計畫實施持續整合(Continuous Integration, CI)流程。下列哪一項做法最符合 CI的核心實踐,且能有效減少整合風險?

  1. A在主分支(Main Branch)每日固定時間手動合併並執行完整測試流程
  2. B每次程式碼提交(Commit)後自動觸發建置、單元測試及靜態程式碼分析
  3. C於模型訓練完成後,定期安排開發團隊回顧並合併程式碼
  4. D透過自動化部署腳本,將模型在特定時間點批次釋出到測試環境
看正解與逐選項詳解

正解:B

正確答案:(B) 【正解解析】 持續整合(Continuous Integration, CI)的核心實踐是:每次程式碼提交(Commit)即自動觸發建置(Build)、單元測試與靜態程式碼分析,使整合問題在最小變更範圍內立即顯現,定位與修復成本最低。「自動化」與「高頻率」是 CI 的兩大關鍵;依賴人工作業或批次累積變更,都會使問題擴大並延後暴露,故 (B) 最符合 CI 的核心實踐並能有效減少整合風險。 【為何其他選項錯了?】 - (A):每日固定時間以人工方式合併與測試,頻率低且依賴手動作業,問題可能累積一整天才被發現,正是 CI 要改善的工作模式。 - (C):待模型訓練完成才定期回顧與合併,整合週期過長,衝突與缺陷集中在後期一次處理,違背「持續」整合的精神。 - (D):以自動化腳本在特定時間點批次釋出至測試環境屬於部署(CD)範疇,且批次釋出不符合每次提交即時驗證的 CI 要求。 提示:CI 的判斷準則:每次提交、自動觸發、快速回饋;人工、定期、批次皆為反面特徵。
115年第一次中級AI應用規劃師第一科人工智慧技術應用與規劃 第43題

某電商平台的演算法工程師開發了一個新版商品推薦模型,在離線 A/B 測試中,新模型的各項評估指標(AUC、NDCG@10)均顯著優於現行線上模型。然而,離線測試無法完全反映真實使用者的互動行為(點擊、購買、停留時間)。在正式全面上線前,若希望在可控制風險下量化真實業務指標,應採用下列何種線上驗證策略?

  1. A影子模式(Shadow Mode):新舊模型同時產生預測,但僅顯示舊模型結果,於後端比較輸出差異
  2. B回測(Backtesting):使用歷史日誌模擬模型表現作為上線依據
  3. C金絲雀發布(Canary Release):將1–5%使用者流量導向新模型,量測 CTR、CVR 等指標並逐步擴量
  4. D負載測試(Load Testing):於測試環境進行高流量壓力測試後直接全面上線
看正解與逐選項詳解

正解:C

正確答案:(C) 【正解解析】 題幹的需求有三項:取得真實使用者互動、量化真實業務指標(CTR、CVR)、風險可控。金絲雀發布(Canary Release)同時滿足三者:先將 1–5% 流量導向新模型,由真實使用者實際互動,量測業務指標並與對照組比較;表現良好即逐步擴量,出現異常則立即回滾,將影響範圍限制在小比例流量內。這是推薦系統上線驗證的業界標準流程,常與 A/B 測試機制搭配執行。 【為何其他選項錯了?】 - (A):影子模式中使用者只看到舊模型的結果,新模型的預測僅在後端執行;沒有實際曝光就不會產生點擊與購買,無法量測 CTR、CVR 等真實業務指標。影子模式適合驗證系統穩定性與輸出差異,而非業務成效。 - (B):回測使用歷史日誌,存在曝光偏差,無法反映使用者對新推薦結果的真實反應,只能作為離線參考,不能替代線上驗證。 - (D):負載測試僅驗證系統承受流量的能力,與推薦品質無關;壓測通過即全面上線,等於未經業務指標驗證就承擔全量風險。 提示:題幹同時出現「真實使用者」「量化業務指標」「風險可控」即對應金絲雀發布;影子模式無曝光、回測用歷史資料、壓測只驗效能。
115年第一次中級AI應用規劃師第一科人工智慧技術應用與規劃 第47題

某電商平台將新的推薦模型部署至線上系統,為降低風險,團隊採用漸進式部署策略(Phased Rollout),先將新模型流量從 5%逐步提升至 100%。在部署初期,團隊發現轉換率(Conversion Rate)略有提升,但在流量提升至 30%時,系統延遲(Latency)明顯上升,且部分使用者體驗變差。請問在此情境下,最適當的下一步策略為何?

  1. A立即將新模型全面部署至 100%,以觀察整體效果並評估系統表現變化
  2. B還原(Rollback)至舊模型並停止新模型測試流程,以確保系統穩定與使用者體驗品質
  3. C維持目前 30%流量並持續觀察,即使延遲問題存在也暫不進行調整
  4. D暫停流量提升,針對延遲問題進行效能分析與優化後再繼續部署
看正解與逐選項詳解

正解:D

正確答案:(D) 【正解解析】 先判讀現況:業務面的轉換率有提升,問題出在非功能面,流量升至 30% 時延遲明顯上升、體驗變差,顯示系統容量或服務效率在較高負載下出現瓶頸。漸進式部署的標準作法是:一旦發現異常先暫停擴量,將風險凍結在目前範圍;接著進行效能分析(定位瓶頸,如模型推論、特徵查詢、資源配置)與優化(擴容、快取、批次策略、模型加速),確認延遲回到服務水準協議(SLA)之內,再繼續提升流量。此作法既保留有效益的新模型,也不犧牲使用者體驗。 【為何其他選項錯了?】 - (A):延遲問題尚未解決就直接部署至 100%,會將效能瓶頸擴大到全體使用者,完全違背漸進式部署的風險控管精神。 - (B):立即回滾過早;轉換率有提升代表模型本身具業務價值,問題在系統效能而非模型品質,應先解決效能再繼續部署,不必放棄已驗證的效益。 - (C):延遲惡化與體驗變差已是明確訊號,維持流量而不處理,瓶頸不會自行消失,只會持續累積使用者體驗與營運損害。 提示:漸進式部署的處理原則:指標異常先暫停擴量,分析修復並驗證後再前進;回滾保留給無法修復或損害重大的狀況。

相關節點