AWS 機器學習架構框架Final Part
監控
模型監控系統必須取得資料，將該資料與訓練資料集進行比較，定義偵測問題的規則，並發送告警。 當由事件啟動或由人為啟動時，此程序會依照定義的排程重複。 監控階段偵測到的問題包括：資料品質、模型品質、偏差漂移(bias drift)和特徵歸因偏差(feature attribution drift)。
上圖列出了監控的關鍵組件，包括：
- 模型可解釋性(Model explainability) —
監控系統使用可解釋性來評估模型的合理性以及預測是否可信。 - 偵測偏差 (Detect drift)—
監控系統偵測資料和concept drifts，啟動告警，並將其送到告警管理系統。 資料漂移是指跟訓練的資料相比，資料分佈的顯著變化。 concept drifts是指目標變數的屬性改變。 任何類型的漂移都會導致模型效能下降。 - Model update pipeline —
如果告警管理器發現任何的模型偏差，它將啟動Model update pipeline以進行重新訓練。 如下圖所示。資料準備、CI/CD/CT 和Feature pipelines在此過程中也將處於運作狀態。
卓越營運支柱 — 最佳實踐
卓越營運支柱包括"運行和監控"系統以提供業務價值並持續改善支援流程和程序的能力。 本節包括在生產中監控模型時要考慮的最佳實踐。
實踐一: 啟用模型的可觀察性與可追蹤性
建立模型監控機制以識別並主動避免任何推論問題。 隨著時間的推移，ML模型的表現可能會因漂移而降低。 監控歸因於模型效能的指標。 對於real time inference endpoints，量測託管endpoint的底層運算資源的運作狀況以及endpoint回應的狀況。 建立lineage以將託管模型追溯到版本化input和模型工件以進行分析。
執行計畫
- 使用SageMaker Model Monitor —
持續監控生產環境中SageMaker ML 模型的品質，並與使用 SageMaker Model Monitor 進行訓練的結果來比較。 - 使用 CloudWatch —
SageMaker Model Monitor 自動將指標傳送至 CloudWatch，以便收集和分析 ML 模型的使用統計資料。 - 使用 SageMaker Model Dashboard—
從 SageMaker 控制台在集中式入口網站中檢視、搜尋和探索模型。 使用 SageMaker Model Monitor 設定監控並追蹤real-time inference endpoints上託管的模型的效能。 尋找違反資料品質、模型品質、偏差和可解釋性設定的閾值的模型 - 使用SageMaker Clarify —
識別模型訓練期間或模型生產過程中可能出現的各種類型的偏差。 這有助於透過檢偵測潛在偏差並幫助解釋模型所做的預測來改進ML模型。 SageMaker Clarify 有助於解釋這些模型如何使用特徵歸因(feature attribution)方法進行預測。 它也監控模型在生產環境中做出的偏差漂移或特徵歸因漂移的推論。 SageMaker Clarify 提供的工具可產生模型治理報告，可以使用該報告給風險和合規團隊以及外部監管機構。 - 使用 SageMaker ML lineage tracking來追蹤model pipeline —
Lineage tracking建立並儲存有關ML工作流程從資料準備到模型部署的步驟的資訊。 保留model discovery experiments的運作記錄。 透過追蹤model lineage artifacts以進行稽核和合規性驗證來建立模型治理。 - 使用 SageMaker Model Cards簡化模型資訊收集 —
這會記錄模型資訊，例如業務需求、關鍵決策以及模型開發和評估期間的觀察結果，以支援審核工作流程、註冊、稽核、客戶查詢和監控。 SageMaker Model Card提供儲存模型資訊（例如，效能目標和風險等級）以及訓練和評估結果（例如，偏差或準確性測量），從而簡化了整個模型生命週期的文件記錄。 - 使用SageMaker 的自動驗證功能 —
SageMaker Inference能夠使用相同的即時推論請求資料，將新模型與生產模型的效能進行比較。SageMaker 可用於將生產模型收到的推論請求副本路由到新模型，並產生儀表板以即時顯示關鍵指標之間的效能差異。
實踐二:同步"架構和配置"，並檢查跨環境的偏差
確保所有系統和配置在開發和部署階段都相同。 否則，因為系統架構的不一致，相同的演算法可能會導致不同的推論結果。 確保模型在Development、Staging和Production環境中獲得相同範圍的準確性。 在正常升級過程中需要納入此類的檢查。
執行計畫
- 使用 CloudFormation —
CloudFormation 提供了一個對相關 AWS 和第三方資源集合進行建模的簡單方法。 CloudFormation會快速、一致地配置這些資源，並透過將基礎架構視為代碼來管理它們的整個生命週期。 可以根據需求來使用 CloudFormation template將整個Stack作為一個單元建立、更新和刪除，而無需單獨管理資源。 也可以跨多個 AWS account和 AWS region管理和配置Stack。 這將跨環境同步架構和配置。 - 使用SageMaker Model Monitor —
持續監控生產環境中 的SageMaker ML模型的品質，並與使用 SageMaker Model Monitor 進行訓練的結果進行比較。 設定告警，在模型品質出現偏差時發出通知。 及早主動偵測這些偏差使我們能夠採取糾正措施。 這些操作可以包括重新訓練模型、審核上游系統以及修復品質問題，而無需手動監控模型或建立額外的工具。 Model Monitor提供不需要編碼的監控能力； 還可以透過加入代碼自訂分析來靈活地監控模型。
安全支柱 — 最佳實踐
安全支柱包括保護資料、系統和資產的能力，以利用雲端技術來提高安全性。 本節包括在生產環境中監控模型時要考慮的最佳實踐。
實踐一: 限制合法使用者的存取
使用最低特權權限來呼叫已部署的模型端點。 對於工作負載環境外部的使用者，透過安全 API 提供存取權限。
執行計畫
- 使用安全的inference API endpoints —
託管模型，以便模型的使用者可以安全地對其進行推論。 讓使用者能夠使用 API 來定義關係、限制對基本模型的存取並提供對模型互動的監控。 - Secure inference endpoints —
只有授權方才能對 ML 模型進行推論。 像對待任何其他 HTTPS API 一樣對待inference endpoints。 確保遵循 AWS Well-Architected Framework的指導來提供網路控制，例如限制對特定 IP 範圍的存取和機器人控制。 這些 API 呼叫的 HTTPS 請求應進行簽名，以便驗證請求者身份，並在傳輸過程中保護請求的資料。
實踐二: 監控人與資料的互動是否有異常活動
確保啟用data access logging。 稽核異常資料存取事件，例如來自異常位置的存取事件或超出該實體基線的活動。 使用支援異常活動告警的服務和工具，並將其使用與資料分類結合來評估風險。 評估使用服務來幫助監控資料存取事件。
執行計畫
- 啟用data access logging—
驗證是否擁有所有人為的 CRUD（create/read/update/delete）操作的資料存取日誌記錄，包括誰存取了哪些東西、他們採取了哪些操作以及何時存取的詳細資訊。 - 將資料分類 —
使用 Macie 對S3 中的訓練和推論資料進行保護和分類。 Macie 是一項完全託管的安全服務。 它使用 ML 來自動發覺、分類和保護 AWS 中的敏感資料。 此服務可識別敏感資料，例如個人識別資訊 (PII) 或智慧財產權。 - 監控和保護 —
使用 GuardDuty 監控惡意和未經授權的活動。 這將能夠保護 AWS account、workload和儲存在S3 中的資料。
可靠度支柱 — 最佳實踐
可靠性支柱包括workload可以有正確一致地執行其預期功能的能力。 本節包括在監控生產中部署的模型時要考慮的最佳實踐。
實踐一:允許model endpoint的自動擴展
實行允許自動縮放model endpoint的功能。 這有助於確保可靠地處理預測(prediction)，以滿足不斷變化的workload需求。 包括對endpoint的監控，以確定啟動"新增或刪除"資源以支援當前需求的閾值。收到擴展請求後，制定解決方案來擴展支援該endpoint的後端資源。
執行計畫
- 為 SageMaker endpoints配置自動擴充 —
SageMaker 支援託管模型的自動擴充 。 SageMaker Endpoints 可以設定自動擴充。 這可以確保隨著應用程式中流量的增加，Endpoint可以保持相同等級的服務可用性。 自動縮放是雲端的關鍵功能。 它允許自動水平地(horizontally)配置新資源來處理增加的使用者需求或系統負載。 自動擴充也是建立事件驅動架構的關鍵組成部分，也是任何分散式系統的必備功能。 - 使用 Elastic Inference —
透過Elastic Inference，可以在 AWS 中選擇最適合應用程式的整體運算和記憶體需求的 CPU 執行個體。 單獨配置適量的 GPU 推論加速，可以有效率地利用資源並降低成本。 - 將Elastic Inference 與 EC2 Auto Scaling 結合使用 —
建立 Auto Scaling group時，可以指定配置 EC2 instance所需的資訊。 這包括 Elastic Inference accelerators。 為此，使用instance configuration和 Elastic Inference accelerator指定launch template。
實踐二: 透過託管的版控策略確保一個recoverable endpoint
確保負責託管模型預測的endpoint以及負責產生該endpoint的所有元件都是fully recoverable。 其中一些元件包括model artifacts、container images與endpoint configurations。 確保所有必需的組件均受版控，並可在lineage tracker system中追蹤。
執行計畫
- 使用 SageMaker Pipelines 和專案實行 MLOps 最佳實踐 —
SageMaker Pipelines 是一項用於建立ML pipeline的服務。 它以版本化、可預測的方式自動開發、訓練和部署模型。 SageMaker 專案使資料科學家和開發人員團隊能夠協作解決ML業務問題。 SageMaker 專案是一個Service Catalog的產品，可建立end-to-end ML 解決方案。 SageMaker Projects entities包括pipeline executions、registered models、endpoints、datasets與code repositories。 - 使用IaC工具 —
使用 CloudFormation 定義和建置基礎設施，包括model endpoints。 將 CloudFormation 代碼儲存在 git 儲存庫（如 AWS CodeCommit）中，以便可以對基礎架構代碼進行版控。 - 使用ECR(Elastic Container Registry) —
將容器儲存在 ECR（Docker 容器的artifact repository）中。 當更新容器時，ECR 會自動為容器建立version hash，從而允許rollback到先前的版本。
效能效率支柱 — 最佳實踐
效能效率支柱著重於有效利用運算資源來滿足需求，並隨著需求變化和技術發展保持效率。 本節包括在生產環境中監控模型時要考慮的最佳實踐。
實踐一:評估模型的可解釋性
根據業務可解釋性要求的限制來評估模型效能。 合規性要求、業務目標或兩者都可能要求模型的推論能夠直接解釋。 評估可解釋性需求以及可解釋性和模型複雜性之間的權衡。 然後選擇模型類型或評估指標。 這種方法可以清楚地了解在特定輸入資料的情況下獲得特定推論的原因。
執行計畫
使用 SageMaker Clarify 解釋模型結果 —
SageMaker Clarify 透過偵測潛在偏差並幫助解釋模型所做的預測來幫助改進ML 模型。 它可以識別模型訓練或生產環境中可能出現的各種類型的資料偏差。 SageMaker Clarify 有助於解釋這些模型如何使用特徵歸因(feature attribution)方法進行預測。 它也監控模型在生產環境中所做的偏差或特徵歸因漂移(feature attribution drift)的推論。 SageMaker Clarify 提供的公平性和可解釋性功能可建立偏差較少且更易於理解的ML模型。 它還提供產生模型治理報告的工具。
實踐二: 評估Data drift
了解Data drift對模型效能的影響。 在資料發生漂移的情況下，模型可能會產生不準確的預測。 考慮一種透過重新訓練來監控和適應data drift的策略。
執行計畫
使用 SageMaker Model Monitor 和 SageMaker Clarify —
SageMaker Model Monitor 可即時偵測模型和concept drift並發送告警以便可立即採取行動，從而維護高品質的 ML 模型。 透過監控模型的品質來偵測模型和concept drift。 自變數（Independent variables也稱為features）是 ML 模型的輸入，因變數(dependent variables)是模型的輸出。 此外，SageMaker Model Monitor 與 SageMaker Clarify 整合，可識別 ML 模型中的潛在偏差。
實踐三: 監控、偵測與處理模型效能下降
由於資料品質、模型品質、模型偏差和模型可解釋性等原因，模型效能可能會隨著時間的推移而下降。 持續即時監控 ML 模型的品質。 確定重新訓練和更新模型的正確時間和頻率。 設定告警，以便在觀察到模型效能出現任何偏差時通知並開始行動。
執行計畫
- 監控模型效能 —
SageMaker Model Monitor 持續監控生產環境中 SageMaker ML模型的品質。 在模型投入生產之前，在訓練期間建立baseline。 在生產環境中收集資料並比較模型推論的變化。 對資料統計中漂移的觀察表明模型可能需要重新訓練。 漂移的時間將制定重新訓練的時間表。 使用 SageMaker Clarify 來辨識模型偏差。 CloudWatch 設定告警，以發送有關資料品質意外偏差或變更的通知。 - 執行自動擴展-
SageMaker 為託管模型提供自動擴展功能，可根據需求動態調整支援endpoint的底層運算。 此功能可確保endpoint能夠動態支援需求，同時減少operational overhead。 - 監控endpoint metrics—
SageMaker 也會輸出endpoint metrics以監控endpoints的使用和運作狀況。 SageMaker Model Monitor 能夠監控生產環境中的 ML 模型，並在出現資料品質問題時發出告警。 創建一種機制，使用 OpenSearch Service 等服務來聚合和分析模型預測endpoint metrics。 OpenSearch 服務支援 Kibana 進行儀表板和視覺化。 將託管指標追溯到版本化輸入的可追溯性允許分析可能影響當前營運績效的變更。
實踐四: 建立一個自動化再訓練框架
監控資料和模型預測(model predictions)。 根據定義的指標進行模型效能分析，以識別由於資料和concept drift而導致的錯誤。 自動執行模型再訓練，以在固定的計劃時間間隔內或當模型變異數達到定義的閾值時減輕這些錯誤。 當有足夠的新資料可用時，也可以開始自動模型重新訓練。
執行計畫
- 確定再訓練機會 —
使用 SageMaker Model Monitor 監控生產環境中的資料統計和 ML 推論。 如果data drift超出定義的閾值，則開始再訓練。 此外，可以依照定義的規劃時間間隔（以滿足業務要求）或在有其他訓練資料可用時啟動再訓練。 AWS 支援根據放入 S3 bucket的新資料自動啟動再訓練的機制。 確保將其他資料合併到模型中時支援模型版控。 這使得能夠使用用於建立版本化工件的元件的組合版本來重新建立無意中刪除的模型工件。 - 使用SageMaker Pipelines —
可以使用 SageMaker Pipelines 發展retraining pipeline，從而支援運步驟的方式建立和管理進行。 - 使用 Step Functions —
可以使用適用於 SageMaker 的Step Functions Data Science SDK來自動訓練ML模型。 定義工作流程中的所有步驟並設定事件來啟動流程。 為了偵測 S3 bucket中是否存在新的訓練要，CloudTrail 與 CloudWatch Events 結合，可以啟動 AWS Step Function workflow，以在training pipeline中啟動再訓練任務。 - 使用第三方工具 —
使用第三方部署編排工具（例如 Jenkins）與 AWS 服務 API 整合，以便在新資料可用時自動執行模型再訓練。
實踐五: 檢查更新的資料/特徵以進行再訓練
建立一個框架，根據資料波動性(volatility)和可用性以預定時間執行資data exploration與feature engineering。 模型訓練中未考慮的新特徵可能會影響模型推論的準確性。
執行計畫
使用SageMaker Data Wrangler 探索不斷變化的資料 —
評估業務環境的變化率，以設定驗證和可能更改模型輸入資料和功能的計劃。 使用SageMaker Data Wrangler 分析資料並探索新功能。 建立一個團隊，定期評估並可能變動的features並重新訓練模型。
實踐六: 包含人機互動監控
使用人機互動監控來有效監控模型效能。 在自動化決策過程時，模型結果的人工標記(human labeling)是模型推論的可靠品質測試。將人工標籤與模型推論進行比較，以估計模型效能下降。 透過模型再訓練來執行緩解措施。
執行計畫
使用 Augmented AI 進行人工審核 —
學習如何設計模型推論的品質保證系統。 建立SME(subject matter experts)團隊來審核生產環境中的模型推論。 使用 Augmented AI對low-confidence predictions或random prediction samples進行人工審核。 Augmented AI使用 IAM、SageMaker 和 S3 中的資源來建立和執行人工審核工作流程。
成本優化支柱 — 最佳實踐
成本優化支柱包括系統在整個生命週期中的持續細緻化和改進過程。 從第一個PoC的初始設計到Production workload的持續運行，採用本文中的實踐可使構建和運營具有成本意識的系統，從而實現業務成果並最大限度地降低成本，讓業務最大化它的投資回報。 本節包括在生產中監控模型時要考慮的最佳實踐。
實踐一: 透過 ML 活動監控使用情況和成本
使用cloud resource tagging來管理、識別、組織、搜尋和過濾資源。 標籤有助於按用途、所有者、環境或其他標準對資源進行分類。 透過使用標記來管理和優化部署階段的成本，使用 ML 活動類別（例如再訓練和託管）將成本與資源關聯起來。 標記對於產生帳單報告非常有用，其中包含按關聯資源劃分的成本細項。
執行計畫
- 使用 AWS tagging—
Tagging是我們或 AWS 指派給 AWS 資源的標籤。 每個標籤由一個key和一個value組成。 對於每個資源，每個tag key必須是唯一的，且每個tag key只能有一個value。 可以使用標籤來組織資源，並使用成本分配標籤來詳細追蹤成本。 AWS 使用cost allocation tags在成本分配報表上組織資源成本。 這可以對 AWS 成本進行分類和追蹤。 AWS 提供兩種類型的成本分配標籤：AWS-generated tag 與user-defined tags。 - 使用 AWS Budgets 追蹤成本 —
AWS Budgets 可追蹤 SageMaker 成本，包括開發、訓練和託管。 可以設定告警，並在成本或使用量超出（或預計超出）預算金額時收到通知。 建立預算後，可以在 AWS Budgets 控制台上追蹤進度。
實踐二: 監控ML模型的ROI
將模型部署到生產環境中後，建立報告功能來追蹤正在交付的價值。 例如：
- 如果使用模型來支援收到多少新客戶：與基準相比，使用模型的建議時獲得了多少新客戶以及他們的支出是多少。
- 如果使用模型來預測何時需要維護：透過優化維護週期可以節省哪些成本。
有效的報告能夠將 ML 模型提供的價值與持續的運作時成本進行比較，並採取適當的措施。 例如，如果ROI相當高，是否可以透過某種方式將其擴展到類似的商業問題。 如果ROI 為負，是否可以透過補救措施來解決這個問題，例如透過使用server less inference來減少模型延遲，或者透過改變模型準確性和模型複雜性之間的折衷來減少運作時間成本，或者分層添加一個更簡單的模型對提交給完整模型的案例進行分類或過濾。
執行計畫
使用儀表板報告 — 使用QuickSight 等儀錶板工具來開發以業務為中心的報告，用來呈現透過使用該模型在業務 KPI 方面所帶來的價值。
實踐三: 監控 endpoint使用狀況與調整instance fleet
確保高效的運算資源用於在生產環境中來運作模型。 監控endpoint使用情況並調整instance fleet的規模。 對託管模型使用自動縮放。 自動縮放會動態調整為模型配置的instance數量，以回應workload的變化。
執行計畫
- 使用CloudWatch 監控 SageMaker endpoints—
CloudWatch 收集原始資料並將其處理為可讀取的近乎即時的指標。 使用 CPU Utilization、GPU Utilization、Memory Utilization、GPU Utilization 等指標來查看endpoint的資源利用率，並使用這些資訊來調整endpoint instance的大小。 - 將自動擴展與 SageMaker 結合使用 —
SageMaker 支援自動擴展，可監控workload並動態調整容量，以盡可能低的成本保持穩定且可預測的效能。 當workload增加時，自動擴展會帶出更多的instance。 當workload減少時，自動擴充會刪除不必要的instance，進而降低運算成本。 SageMaker 會自動嘗試跨AZ指派instance。 因此，AWS強烈建議您為每個peoduction endpoint部署多個instance以實現高可用性。 如果使用的是 VPC，請在不同的AZ中至少設定兩subnet，以便SageMaker 可以跨這些AZ分發instance。 - 仔細確定資源置入 —
FSx for Lustre 可以作為SageMaker 的輸入資料來源。 當 FSx for Lustre 用作輸入資料來源時，SageMaker ML 訓練作業可透過去除初始化 S3 下載步驟來加速。 但是，作為最佳實踐，最好在同一AZ中部署 FSx for Lustre 和 SageMaker。 跨AZ或 VPC 部署它們可能會導致巨大的成本。
永續性支柱 — 最佳實踐
永續發展支柱著重於環境影響，特別是能源消耗和效率，因為它們是架構師指導採取直接行動以減少資源使用的重要槓桿。 本節包括在生產中監控模型時要考慮的最佳實踐。
實踐一: 衡量事物的效率
衡量每個工作單元所配置資源的workload效率，不僅可以衡量workload的業務成功程度，還可以衡量其事物效率。 使用此衡量標準作為永續發展改善流程的基準。
執行計畫
- 使用每個工作單元的配置資源作為關鍵績效指標 —
將配置的資源除以所實現的業務成果，以確定每個工作單元的配置資源。 這將標準化"可持續發展 KPI" 並比較一段時間內的績效。 - 建立基準 —
了解workload為完成一個工作單元而配置的資源（例如，訓練模型或進行預測） - 預估改進 —
預估改進來為所配置資源的數量減少以及相對於每個工作單元所配置的基準資源的百分比變化。 量化一段時間內改善帶來的淨收益，以顯示改善活動的投資回報。
實踐二: 只在必要時再訓練
由於模型漂移、穩健性要求或新的ground truth data可用，模型通常需要再訓練。 不要隨意再訓練，而是在生產中監控 ML 模型，自動偵測模型漂移，並且只在模型的預測效能低於定義的 KPI 時進行再訓練。
執行計畫
- 確定關鍵績效指標 —
與業務利害關係人一起確定可接受的最小準確度和可接受的最大誤差。 - 監控生產環境中部署的模型 —
使用 SageMaker Model Monitor 自動偵測模型偏差 - 自動化再訓練pipeline —
使用 SageMaker Pipelines、適用於SageMaker 的 AWS Step Functions Data Science SDK或第三方工具來自動化再訓練pipeline。
