AWS 機器學習架構框架Part 1
業務目標階段
機器學習(以下簡稱ML)是一種透過演算法在大量的資料中尋找”模式”的一種方法。本文將介紹AWS提供給我們在ML中一套經過驗證的最佳實踐。當我們在AWS中設計ML Workload並且之後的持續改進時，可以以遵循這一套最佳實踐。
AWS Well-Architected Framework協助我們理解要在AWS中要建立ML workload中的效益與風險。這一套架構框架可以讓我們學習到在雲端中設計和運行workload的佳實踐，並且持續衡量我們的維運和架構並確定需要改進領域的方法。
我們都知道，ML模型的正確性靠的是"高品質的輸入資料"進而產生精確的結果。但資料會隨著時間的推移而改變，我們需要進行監控來持續"偵測、修正和緩解"ML的"準確性和效能"問題。 這個監控步驟可能需要我們使用到最新且精煉過的資料同樣隨著時間的推移來重新訓練ML模型。
Application Workload依賴一行行的代碼來解決問題，而ML Workload使演算法能夠透過迭代(iterative)和連續循環從資料中學習。 AWS特別針對ML有另一個不同的Well-Architected Framework(AWS稱為ML Lens)，以解決這兩類工作負載之間的差異。
在AWS account中運行 ML Lens review
通常我們可以在AWS中檢視ML workload的方法就是使用AWS Well-Architected Tool。我們可以用JSON 檔案的方式來定義整個ML workload的治理與管理。
- 下載ML Lens JSON檔案。這會在稍後用到
- 登入AWS Management Console並選擇AWS Well-Architected Tool服務
- 在AWS Well-Architected Tool頁面的左邊點選Custom lenses
- 建立一個新的Custom lenses
- 選擇我們剛剛下載下來的JSON檔案
- 點選Submit & Preview或Submit
- 選擇我們剛剛submit的檔案(如下圖)
8. 點選Publish並為這一次的publish命名版本名稱
之後我們就會看到status是PUBLISHED
現在我們可以將ML Len套用在 AWS account中的workload，並與其他 AWS account和使用者共用。 如果我們的帳號由 AWS Organizations 管理，我們可以與組織或 OU 中的所有帳號共用該ML Len，而不用每個帳號都搞一個。當完成 ML Lens checklist時，我們可以識別ML workload的風險並得到評論。 工作負載報告以 PDF 格式提供，報告中會有風險和未來建議。 可以在該工具中管理和分配曝險的事項，並且可以執行定期milestone reviews。
良好架構的 ML生命週期
ML 生命週期是一個循環迭代過程，包含在開發 ML workload時跨各階段使用的說明和最佳實踐。 ML生命週期增加了清晰度和結構，讓我們的ML專案能成功。 下圖是一個的端到端ML生命週期過程並包括以下階段：
- 業務目標識別—
考慮要使用ML的組織應該清楚地理解問題以及透過解決該問題所獲得的業務價值。 我們必須能夠根據特定的業務目標和成功標準來衡量業務價值。 - ML的問題框架 —
在該階段，業務問題被定義為ML問題：觀察到什麼以及應該預測什麼（稱為label或target variable）。 確定要預測的內容以及必須如何最佳化效能和錯誤指標是此階段的關鍵步驟。 - 資料流程(資料收集、預處理、特徵工程) —
訓練準確的ML模型需要進行資料處理，將資料轉換為可用的格式。 資料處理步驟包括收集資料、準備資料和特徵工程，即從資料中建立、轉換、提取和選擇”變數(variables)”的流程。 - 模型開發(訓練、調整、評估) —
模型開發包括模型建構、訓練、調整和評估。 模型建置包括建立 CI/CD pipeline，該pipeline可自動建置、訓練並發佈到staging和production環境。 - 模型佈署(推斷、預測) —
模型經過訓練、調整、評估和驗證後，就可以將模型部署到生產環境中。 然後可以根據模型進行預測和推斷。 - 模型監控 —
模型監控系統透過早期偵測和緩解確保模型保持所需的效能水準。
ML 生命週期的各個階段本質上不一定是照以上的順序的，並且可以具有反饋循(上圖中圓圈內的箭頭方向)來中斷整個生命週期階段的循環。
如下圖所示，架構良好的ML生命週期會使用剛剛描述的ML生命週期，並將Well-Architected Framework pillars應用於每個生命週期階段。關於AWS的Well-Architected Framework pillars可參閱本部落格關於AWS Well-Architected Framework pillars的系列文章共六篇。
架構良好的ML設計原則
架構良好的 ML 設計原則是一組考量因素，是作架構良好的 ML workload的基礎。遵循Well-Architected Framework guidelines，使用這些通用設計原則來促進雲端中 ML workload的良好設計：
- 分配所有權 —
應用正確的技能和正確數量的資源以及責任和授權來提高生產力。 - 提供保護 —
將安全控制套用在託管的模型資料、演算法、運算和端點的系統和服務。 這確保了安全和不間斷的運作。 - 實現韌性 —
透過版本控制、可追溯性和可解釋性確保 ML 模型的容錯性和可復原性。 - 實現可重用性 —
使用可共用和重複使用的獨立模組化元件。 這有助於實現可靠性、提高生產力並優化成本。 - 實現可重複性 —
跨組件地（例如基礎設施、資料、模型和代碼）使用版本控制。 將變更追蹤回某個時間點的版本。 這種方法支持模型"治理和稽核標準"。 - 最佳化資源 —
對可用資源和配置進行權衡分析，以實現最佳結果。 - 降低成本 —
透過自動化或最佳化、分析流程、資源和營運來確定降低成本的可能性 - 實現自動化 —
使用pipeline、腳本編寫和CI、CD) 和CT(continuous training) 等技術來提高敏捷性、效能、維持韌性並降低成本。 - 實現持續改進 —
透過持續監控、分析和學習來發展和改善工作量。 - 最大限度地減少環境影響 —
建立永續發展目標並了解機器學習模型的影響。 使用託管服務並採用高效的硬體和軟體並最大限度地提高其利用率。
良好架構的ML
本節介紹 ML 特定的良好架構最佳實踐。 對於ML生命週期的每個階段，良好架構最佳實踐都會在卓越營運、安全性、可靠性、效能效率、成本優化和永續性這六個支柱中進行檢驗。 每個 ML 生命週期階段的最佳實踐遵循每個階段的介紹背景。
下圖 按順序說明了本文所引用的 ML 生命週期的六個階段。當存在適用於多個支柱或階段的最佳實踐時，會在影響最大的支柱或階段中進行描述。
業務目標階段
業務目標識別是ML生命週期中最重要的階段。 考量使用ML的企業應該清楚了解要解決的問題以及要獲得的業務價值。 我們必須能夠根據"特定的業務目標和成功標準"來衡量"業務價值"。 雖然這適用於任何技術解決方案，但在考量 ML 解決方案時，此步驟尤其具有挑戰性，因為 ML 是一項不斷發展的技術。
確定成功標準後，評估組織實現該目標的能力(通常需要進行gap analysis)。 目標應該是可實現的，並提供清晰的生產路徑。 從一開始就讓所有相關利害關係人參與進來，使他們與該目標以及該計劃產生的任何新業務流程保持一致。
透過確定 ML 是否是實現了"業務目標"的適當方法來開始檢視。 評估可用於實現目標的所有選項。 確定結果的準確性，同時考慮每種方法的成本和可擴展性。為了使基於ML的方法成功，確保演算法有足夠的相關、高品質的訓練資料。 仔細評估資料以確保正確的資料來源可用並可存取。
應遵循以下工作步驟來確定業務目標。
業務考量:
- 理解業務需求
- 讓受影響的利害關係人與該計劃保持一致
- 形成一個業務問題
- 確定關鍵的、必須具備的功能
- 考量此實作中可能產生的新業務流程
- 考量如何使用 ML 模型可以幫助改進的業務指標來衡量業務價值
建構ML問題:
- 根據業務問題定義ML task
- 檢視類似領域中經過驗證或已發佈的成品（如果有的話）
- 設計小型、集中的 POC，以驗證方法中存在信心不足的面向
決定優化的目標:
確定ML use case的關鍵業務績效指標，例如新業務獲取的提升、詐欺偵測率和異常偵測。 依業務需求增加CSAT。
檢視資料要求:
檢視ML專案的可行性和資料要求
成本與效能優化:
- 評估資料獲取、訓練、推斷和錯誤預測的成本
- 評估導入外部資料來源是否可以提高模型效能
生產考量:
- 檢視如何處理 ML 產生的錯誤
- 建立生產途徑
卓越維運支柱 — 最佳實踐
卓越營運支柱包括運作和監控系統以提供業務價值並持續改善支援性流程和程序的能力。 本節包含辨識業務目標時要考量的最佳實務。
實踐一:透過責任和授權養成正確的技能
AI有許多不同且不斷發展的分支，例如ML、深度學習和電腦視覺。 鑑於 ML 技術的複雜性和快速成長的性質，計劃聘請相關專家時要了解隨著 ML 的發展將需要額外的訓練。 讓團隊不斷學習新技能、持續參與和積極性，同時始終需要有"問責制和授權"。 建立ML模型是一個複雜且迭代的過程，可能會對特定實體產生偏見或不公平的預測。 在整個企業中促進和執行AI的道德使用非常重要。 AWS 為客戶提供負責任的 AI 實踐的明確指導。
執行計畫
培養技能－任何組織的員工參與度和業務成長策略的關鍵要素必須是持續學習和成展。 考慮透過有意識的員工技能發展來增加ML驅動的業務成果的策略。 打造一支成功的ML團隊包括提供有關ML 概念和演算法的訓練、端到端ML 生命週期流程（例如AWS SageMaker 中的模型訓練、調較和部署），以及透過SageMaker 具效能地使用ML 基礎設施以及透過MLOps 工具可自動化，例如 SageMaker pipeline。 根據業務需求對不同 ML 專業領域（例如電腦視覺、NLP 和強化式學習）的人員進行培訓可以提高生產力。
制定問責制和授權
透過ML應用於AI中，透過解決員工最具挑戰性的一些問題、強化員工績效並最大限度地提高生產力，改變了業務運作方式。 促進負責任地使用這些技術是促進持續創新的關鍵。 使用 AWS SageMaker Clarify 消除資料集和模型預測中的偏差可以幫助建立公平且可解釋的模型。
實踐二:討論並就模型的可解釋性水準達成一致
就使用案例所需的"模型可解釋性的可接受程度"與業務利害關係人進行討論並達成一致。 使用商定的等級作為整個ML生命週期的評估和權衡分析(tradeoff analysis)的指標。 可解釋性有助於理解預測、稽核和滿足監管要求的原因。 它對於建立信任以確保模型按預期作業是有用的。
執行計畫
- 理解業務需求 —
在受監管的產業採用AI需要信任。 這可以透過對部署的預測提供可靠的解釋來建立。 模型可解釋性對於可靠性、安全性和合規性要求尤其重要。 SageMaker Clarify 會建立可解釋性報告並偵測資料集或模型偏差。 - 就可接受的可解釋性水準達成一致 —
與整個專案的利害關係人就專案所需的可解釋性水準進行溝通。 同意可協助滿足業務要求的等級。 - 選擇良好的baseline—
Shapley 值決定每個特徵對模型預測的貢獻。 SHAP 可解釋性基準對於建立公平且可解釋的 ML 模型至關重要。 需要小心地選擇baseline，因為模型解釋是基於與baseline的偏差(deviations)（在 ML 整體脈絡中，baseline是一個hypothetical instance）。 我們可以選擇具有「低資訊內容」的baseline（例如，透過採用數字特徵的中位數或平均值以及分類特徵的模式來從訓練資料集中建立平均實例）或具有「高資訊內容」的baseline（例如，代表感興趣的特定實例類別）。 SageMaker Clarify 使用 Shapley Additive exPlanations (SHAP)，透過使用 K-menas或 K-prototypes等clustering method自動運算資料集中的baseline。
實踐三: 監控模型是否符合業務要求
由於現實世界的變化，例如資料漂移(data drift)和概念漂移(concept drift)，ML模型會隨著時間的推移而退化。 如果不進行監控，這些變化可能會導致模型隨著時間的推移而變得不準確。 制定定期監控流程非常重要，以確保ML模型持續符合業務要求，與及時擷取偏差並採取行動。
執行計畫
- 就所需的監控指標達成一致 —
明確建立想要從模型監控過程中捕捉的指標。 這些指標應與業務需求相關聯，並應涵蓋與資料集相關的統計資料和模型推論指標(inference metrics)。 - 針對偏差制定行動計畫 —
如果在資料集中或模型的輸出中偵測到不可接受的偏差，則制定行動計畫以根據偏差類型和相關指標來緩解偏差。 這種緩解措施可能包括啟動retraining pipeline、更新模型、使用更多實例增強資料集或豐富我們的特徵工程流程。
安全支柱 — 最佳實踐
安全支柱包括保護資料、系統和資產的能力，以利用雲端技術來改善安全態勢(Security Posture)。 本節包括辨識業務目標時要考量的最佳實務。
實踐一: 驗證 ML 資料權限、隱私權、軟體和授權條款
ML 程式庫和套件進行資料處理、模型開發、訓練和託管。 建立一個流程來檢視整個 ML 生命週期所需的所有軟體和 ML 程式庫的隱私和許可協議。 確保這些協議符合組織的法律、隱私和安全條款和條件。 這些條款不應對組織的業務計劃加上任何限制。
執行計畫
- 確保 ML 的資料權限 —
確認資料是否可用於ML、其用途是否合法，以及是否需要資料擁有者或資料主體的同意。 制定計劃來處理隨後撤回同意的資料主體。 確保出於合規性目的維護資料權限文件。 - 具有生命週期管理策略的Bootstrap instances —
建立生命週期配置，引用我們的package repo以及用於安裝所需套件的腳本。 - 評估需要外部查找服務的套件整合 —
根據資料隱私要求，在必要時opt out資料收集。 透過可信關係最大限度地減少資料暴露。 評估可能收集資料的 ML 套件的隱私權政策和授權條款。 - 使用預先建置的容器 —
從pre-package和驗證的容器開始，快速為常用依賴項提供支援。 例如，AWS Deep Learning Containers 包含多個深度學習框架庫和工具，包括 TensorFlow、PyTorch 和 Apache MXNet。
可靠度支柱 — 最佳實踐
可靠性支柱包括workload在預期時正確一致地執行其預期功能的能力。 在辨識業務目標時，沒有需要考量的可靠性最佳實務。
效能支柱 — 最佳實踐
效能支柱著重於有效利用運算資源來滿足需求，並隨著需求變化和技術發展保持效率。 本節包括辨識業務目標時要考量的最佳實務。
實踐一: 決定KPI
使用業務利害關係人的指南來擷取與業務使用案例相關的 KPI。 KPI 應與業務價值直接相關，以指導可接受的模型效能。 考慮到ML推論是機率性的，不會提供準確的結果。 確定 KPI 中可接受的最小準確度和最大可接受誤差。 這有助於實現所需的業務價值並管理可變結果的風險。
執行計畫
- 量化ML對業務的價值 — 考慮量測ML和自動化將如何影響業務：
— ML會降低多少成本？
— 透過擴大規模，將涵蓋多少使用者？
— 透過更快地回應"需求和供給"等變化，企業可以節省多少時間？
— 透過ML實現自動化可以消除多少小時的人工作業？
— ML能夠在多大程度上改變使用者行為，例如減少客戶流失？ - 評估風險和錯誤容忍度 — 量化ML對業務的影響。
對影響值進行排序，以確定透過ML進行最佳化的主要 KPI。 定義使用案例中 ML 模型將執行的自動推論的錯誤成本。 確定企業對錯誤的容忍度。 例如，確定成本削減估算必須偏離多少才會對業務目標產生負面影響。 最後，評估ML為企業帶來的風險，以及ML解決方案的效益是否具有足夠高的價值來超越這些風險。
成本優化支柱 — 最佳實踐
成本優化支柱包括系統在整個生命週期中的持續細致化和改進流程。 從第一個POC的初始設計到production workload的持續運行，以下提及的實踐可以使我們構建和運營具有成本意識的系統，從而實現業務成果並最大限度地降低成本，從而使業務最大化它的投資回報。 本節包括辨識業務目標時要考量的最佳實務。
實踐一: 定義整體的ROI與機會成本
評估每個使用案例的ML機會成本以解決業務問題。 確保就長期資源分配做出具有成本效益的決策。 透過預先了解ML開發流程及其資源需求，最大限度地減少未來可能的風險和失敗。 採用自動化和優化可以降低成本並提高效能。
執行計畫
- 將 ML 專案的目標指定為研究或開發。
研究專案旨在發現未經測試的ML使用案例可以實現的價值，並且回報將是長期的。 開發專案主要在實現特定的生產改進，並有望帶來更快的投資回報。 業務管理層和資料科學家都應該就專案是否以研究為導向，或者將易於理解的方法應用於眾所周知的使用案例進行開發達成一致。 - 使用標籤(Tag)，以便可以按專案和業務部門追蹤成本，從而清楚地了解投資回報率。
- 評估與驗證data pipeline、ML model以及production inferences的預期品質，以估計資料和錯誤的成本。
- 開發成本效益模型，並在整個專案發生變化時重新評估模型。 例如，外部業務環境的變化或昂貴資料來源可能需要對初始成本效益模型進行修改。
- 了解、評估和監控專案風險。
- 估計維護生產模型所需的資源成本，例如資料工程師和資料科學家。
實踐二: 使用託管服務來減少TCO
評估採用託管服務和pay-per-usage。 使用託管服務使企業能夠以更少的資源和更低的成本更有效率地運作。
執行計畫
- 使用 AWS託管 ML 服務 —
使用SageMaker 作為完全託管的ML服務，以顯著降低的成本大規模建置、訓練和部署模型。 SageMaker 三年內的TCO遠低於其他自型管理的基於雲端的 ML 選項，例如 EC2和 EKS。 SageMaker 包括 Autopilot、Feature Store、Clarify、DataWrangler、Debugger、Studio、training、模型部署、監控和pipeline等技術。 - 使用 Amazon 託管 AI 服務 —
AWS 預訓練的 AI 服務為我們的應用程式和工作流程提供現成的智慧。 AI 服務與應用程式整合，以解決常見需求，例如個人化推薦、現代化客服中心、提高安全性以及提高客戶參與度。 AWS 上的AI服務不需要ML經驗。 它們是完全託管的解決方案，採用按需付費的定價方式。 - 執行定價模型分析 —
分析工作負載的每個組成部分。 確定組件和資源是否將長期運作並有資格享受承諾折扣，例如 AWS Savings Plans。 可以使用 Savings Plans 來節省 AWS 使用量，以換取對長期使用量的承諾。 SageMaker Savings Plans 提供靈活的屬性，例如執行個體系列、執行個體大小、AWS 區域以及 SageMaker 執行個體所使用的組件。
永續性支柱 — 最佳實踐
永續性支柱著重於環境影響，特別是能源消耗和效率，因為它們是架構師指導如何減少資源使用的直接行動的重要槓桿。 本節包括辨識業務目標時要考量的最佳實務。
實踐一:定義整體環境衝擊與效益
衡量workload的影響及其對組織整體永續發展目標的貢獻。
執行計畫
提出探究性問題 —
這個workload如何支持我們的整體永續發展使命？ 我們需要儲存和處理多少資料？ 訓練模型有什麼影響？ 我們多久需要重新訓練一次？ 客戶使用此workload會產生哪些影響？ 與這個總體影響相比，生產產出是多少？ 提出這些問題將幫助我們建立具體的永續發展目標和成功標準，以供未來衡量。
