機器學習作業
機器學習作業（也稱為 MLOps）是將 DevOps 原則套用至 AI 注入的應用程式。 若要在組織中實作機器學習作業，必須有特定的技能、流程和技術。 目標是提供健全、可調整、可靠且自動化的機器學習解決方案。
在本文中，瞭解如何規劃資源以支持組織層級的機器學習作業。 檢閱以使用 Azure 機器學習 在企業中採用機器學習作業為基礎的最佳做法和建議。
什麼是機器學習作業？
新式機器學習演算法和架構可讓您更輕鬆地開發可進行精確預測的模型。 機器學習作業是將機器學習納入企業應用程式開發的結構化方式。
在範例案例中，您已建置一個機器學習模型，其超過您所有的精確度預期，並給企業贊助商留下深刻的印象。 現在是時候將模型部署到生產環境了，但可能不像您預期的那樣容易。 組織可能需要具備人員、流程和技術，才能在生產環境中使用您的機器學習模型。
經過一段時間，您或同事可能會開發比原始模型更好的新模型。 取代生產環境中所使用的機器學習模型，會對組織造成一些重要考慮：
- 您會想要實作新的模型，而不會中斷依賴已部署模型的商務作業。
- 基於法規目的，您可能需要說明模型的預測，或如果新模型中的數據產生異常或有偏差的預測，您可能需要重新建立模型。
- 您在機器學習定型和模型中使用的數據可能會隨著時間而變更。 透過數據中的變更，您可能需要定期重新定型模型，以維持其預測精確度。 必須指派人員或角色來提供數據、監視模型的效能、重新定型模型，並在模型失敗時修正模型。
假設您有一個應用程式，可透過 REST API 提供模型的預測。 即使是像這樣的簡單使用案例，也可能會導致生產環境中發生問題。 實作機器學習作業策略可協助您解決部署考慮，並支援依賴 AI 內建應用程式的商務作業。
某些機器學習作業工作適用於一般 DevOps 架構。 範例包括設定單元測試和整合測試，以及使用版本控制來追蹤變更。 其他工作對機器學習作業而言更為獨特，可能包括：
- 針對基準模型啟用連續實驗和比較。
- 監視傳入數據以偵測 數據漂移。
- 觸發模型重新定型，並設定災害復原的復原。
- 建立可重複使用的數據管線來定型和評分。
機器學習作業的目標是要縮小開發與生產之間的差距，並更快為客戶提供價值。 若要達成此目標，您必須重新思考傳統的開發和生產程式。
並非所有組織的機器學習作業需求都相同。 大型跨國企業的機器學習作業架構可能與小型初創公司建立的基礎結構不同。 組織通常會在成熟度、模型目錄和經驗成長時開始小型並建置。
機器學習作業成熟度模型可協助您查看組織在機器學習作業成熟度規模上的位置，並協助您規劃未來的成長。
機器學習作業與 DevOps
機器學習作業與數個關鍵領域的DevOps不同。 機器學習作業具有下列特性：
- 探索在開發和作業之前。
- 數據科學生命週期需要彈性的工作方式。
- 數據品質和可用性限制進度的限制。
- 所需的作業工作比 DevOps 還要多。
- 工作小組需要專家和領域專家。
如需摘要，請檢閱 機器學習作業的七個原則。
探索在開發和作業之前
數據科學專案與應用程式開發或數據工程專案不同。 數據科學專案可能會讓它用於生產環境，但通常比傳統部署更涉及步驟。 在初始分析之後，可能會發現無法使用可用的數據集來達成業務成果。 更詳細的探索階段通常是數據科學專案中的第一個步驟。
探索階段的目標是定義和精簡問題。 在此階段，數據科學家會執行探勘數據分析。 他們會使用統計數據和視覺效果來確認或偽造問題假設。 項目關係人應該了解專案可能不會超過此階段。 同時，請務必讓此階段盡可能順暢地進行快速轉機。 除非要解決的問題包含安全性元素，否則請避免使用程式和程式來限制探勘階段。 應該允許數據科學家使用他們偏好的工具和數據。 此探勘工作需要實際數據。
當項目關係人確信數據科學專案可行且可提供實際商業價值時，專案可以移至實驗和開發階段。 在這個階段，開發做法變得越來越重要。 擷取此階段所完成之所有實驗的計量是很好的作法。 也請務必納入原始檔控制，以便比較模型，並在不同版本的程式代碼之間切換。
開發活動包括重構、測試和自動化可重複實驗管線中的探索程序代碼。 組織必須建立應用程式和管線來提供模型。 在模組化元件和連結庫中重構程式代碼有助於提升重複使用性、測試和效能優化。
最後，為模型提供服務的應用程式或批次推斷管線會部署到預備或生產環境。 除了監視標準應用程式的基礎結構可靠性和效能，在機器學習模型部署中，您必須持續監視數據的品質、數據配置檔，以及效能降低或漂移的模型。 機器學習模型也需要經過一段時間的重新定型，才能在不斷變化的環境中保持相關。
數據科學生命週期需要彈性的工作方式
由於數據的性質和品質一開始不確定，如果您將一般 DevOps 程式套用至數據科學專案，則可能無法達成業務目標。 探索和實驗是整個機器學習程序的週期性活動和需求。 Microsoft Teams 會使用專案生命週期和工作程式，以反映數據科學特定活動的性質。 Team 資料科學 Process 和 資料科學 生命週期程式是參考實作的範例。
數據品質和可用性限制進度的限制
若要讓機器學習小組有效地開發機器學習服務內嵌的應用程式，建議針對所有相關工作環境存取生產數據。 如果由於合規性需求或技術限制而無法存取生產數據，請考慮使用 Azure 機器學習、Just-In-Time 存取或數據移動管線來實作 Azure 角色型訪問控制 （Azure RBAC），以建立生產數據複本並增強用戶生產力。
機器學習需要更大量的作業工作
與傳統軟體不同，機器學習解決方案的效能會持續面臨風險，因為解決方案相依於數據品質。 為了在生產環境中維持質化解決方案，您必須 持續監視和重新評估數據和模型品質。 預期生產模型需要及時重新定型、重新部署和調整。 這些工作除了日常安全性、 基礎結構監視和合規性需求，而且需要專業專業知識。
機器學習小組需要專家和領域專家
雖然數據科學專案與一般IT專案共用角色，但機器學習工作的成功高度取決於擁有基本的機器學習技術專家和領域主題專家。 技術專家具有正確的背景，可進行端對端機器學習實驗。 領域專家可以藉由分析及合成數據或限定數據以供使用，來支持專家。
數據科學專案特有的常見技術角色包括領域專家、數據工程師、數據科學家、AI 工程師、模型驗證程式和機器學習工程師。 若要深入瞭解一般數據科學小組中的角色和工作，請參閱Team資料科學 Process。
機器學習作業的七個原則
當您打算在組織中採用機器學習作業時，請考慮將下列核心原則套用為基礎：
針對程式代碼、數據和實驗輸出使用版本控制。 不同於傳統軟體開發，數據對機器學習模型的品質有直接影響。 您應該將實驗程式代碼基底版本設定為版本，但也設定數據集的版本，以確保您可以重現實驗或推斷結果。 模型之類的版本控制實驗輸出可以節省成本，以及重新建立這些輸出的計算成本。
使用多個環境。 若要將開發和測試與生產工作分開， 請在至少兩個環境中複 寫您的基礎結構。 用戶訪問控制對於每個環境可能不同。
以程式代碼的形式管理您的基礎結構和組態。 當您在工作環境中建立和更新基礎結構元件時，請使用 基礎結構即程式代碼，因此不會在您的環境中開發不一致。 以程式代碼的形式管理機器學習實驗作業規格，讓您可以輕鬆地在多個環境中重新執行及重複使用實驗的版本。
追蹤和管理機器學習實驗。 追蹤機器學習實驗的關鍵效能指標和其他成品。 當您保留作業效能的歷程記錄時，您可以對實驗成功進行量化分析，並增強小組共同作業和靈活度。
測試程式代碼、驗證數據完整性，並確保模型品質。測試測試程式代碼基底，以取得正確的數據準備和特徵擷取函式、數據完整性和模型效能。
機器學習持續整合和傳遞。 使用 持續整合 （CI） 為您的小組自動化測試。 將模型定型納入連續定型管線的一部分。 在發行中包含 A/B 測試，以確保生產環境中只會使用定性模型。
監視服務、模型和數據。 當您在機器學習作業環境中提供模型時，請務必監視服務的基礎結構運行時間、合規性和模型品質。 設定監視 以識別數據和模型漂移，並瞭解是否需要重新定型。 請考慮設定自動重新定型的觸發程式。
Azure 機器學習 的最佳做法
Azure 機器學習 提供資產管理、協調流程和自動化服務，以協助您管理機器學習模型定型和部署工作流程的生命週期。 檢閱最佳做法和建議，以在人員、流程和技術的資源區域中套用機器學習作業，這些作業全都由 Azure 機器學習 支援。
人員
在專案小組中工作，以充分利用組織中的專家和領域知識。 為每個項目設定 Azure 機器學習 工作區，以符合使用案例隔離需求。
將一組責任和工作定義為角色，以便將機器學習作業專案小組上的任何小組成員指派給並履行多個角色。 使用 Azure 中的自定義角色來定義一組適用於 Azure 的細微 Azure RBAC 作業，機器學習 每個角色都可以執行。
標準化專案生命週期和敏捷式方法。 Team 資料科學 Process 提供參考生命周期實作。
平衡小組可以執行所有機器學習作業階段，包括探索、開發和作業。
處理
在程式代碼範本上標準化，以便重複使用程式碼，並加速新專案或新小組成員加入項目的時間。 使用 Azure 機器學習 管線、作業提交腳本和 CI/CD 管線作為新範本的基礎。
使用版本控制。 從 Git 支援的資料夾提交的作業會自動追蹤存放庫元數據與 Azure 機器學習 中的作業，以重現性。
針對實驗輸入和輸出使用版本控制，以重現性。 使用 Azure 機器學習 數據集、模型管理和環境管理功能來加速版本控制。
建立 實驗回合的執行歷程記錄 ，以進行比較、規劃和共同作業。 使用 MLflow 之類的實驗追蹤架構來收集計量。
當模型未聚合時，在程式中提早終止定型。 使用實驗追蹤架構和 Azure 機器學習 中的執行歷程記錄來監視作業執行。
定義實驗和模型管理策略。 請考慮使用像冠軍一樣的名稱來參考目前的基準模型。 挑戰者模型是候選模型，在生產環境中可能優於冠軍模型。 在 Azure 機器學習 中套用標記，以標記實驗和模型。 在銷售預測等案例中，可能需要數月的時間來判斷模型的預測是否準確。
將 CI 提升為持續定型，方法是在組建中包含模型定型。 例如，使用每個提取要求，在完整數據集上開始模型定型。
藉由在數據範例上執行自動化組建，縮短取得機器學習管線品質意見反應所需的時間。 使用 Azure 機器學習 管線參數來參數化輸入數據集。
針對機器學習模型使用持續部署 （CD），在 Azure 環境中將部署和測試即時評分服務自動化。
在某些受管制產業中，您可能需要先完成模型驗證步驟，才能在生產環境中使用機器學習模型。 自動化驗證步驟可能會加速傳遞時間。 當手動檢閱或驗證步驟仍是瓶頸時，請考慮您是否可以認證自動化模型驗證管線。 使用 Azure 機器學習 中的資源標籤，指出資產合規性和候選專案以供檢閱或作為部署的觸發程式。
請勿在生產環境中重新定型，然後在不進行整合測試的情況下直接取代生產模型。 即使模型效能和功能需求可能看起來不錯，在其他潛在問題中，重新定型的模型可能會有較大的環境使用量並中斷伺服器環境。
當生產數據存取僅適用於生產環境時，請使用 Azure RBAC 和 自定義角色 來提供選取數目的機器學習從業者讀取許可權。 某些角色可能需要讀取相關數據探索的數據。 或者，在非生產環境中提供數據複本。
同意 Azure 機器學習 實驗的命名慣例和標籤，以區分重新定型基準機器學習管線與實驗性工作。
技術
如果您目前透過 Azure Machine Learning 工作室 UI 或 CLI 提交作業，而不是透過 SDK 提交作業，請使用 CLI 或 Azure DevOps 機器學習 工作來設定自動化管線步驟。 此程式可能會藉由直接從自動化管線重複使用相同的作業提交，以減少程式代碼使用量。
使用事件型程序設計。 例如，在註冊新模型之後，使用 Azure Functions 觸發離機模型測試管線。 或者，當重大管線無法執行時，將通知傳送至指定的電子郵件別名。 Azure 機器學習 會在 Azure 事件方格 中建立事件。 多個角色可以訂閱事件通知。
當您使用 Azure DevOps 進行自動化時，請使用適用於 機器學習 的 Azure DevOps 工作，以使用機器學習模型作為管線觸發程式。
當您開發機器學習應用程式的 Python 套件時，您可以將它們裝載在 Azure DevOps 存放庫中做為成品，並將其發佈為摘要。 藉由使用此方法，您可以整合 DevOps 工作流程，以建置套件與 Azure 機器學習 工作區。
請考慮使用預備環境來測試機器學習管線系統與上游或下游應用程式元件的整合。
為您的推斷端點建立單元和整合測試，以增強偵錯，並加速部署時間。
若要觸發重新定型，請使用 數據集監視器 和 事件驅動工作流程。 訂閱數據漂移事件，並將機器學習管線的 觸發程式自動化以進行重新定型。
適用於組織機器學習作業的 AI Factory
數據科學小組可能會決定它可以在內部管理多個機器學習使用案例。 採用機器學習作業可協助組織設定專案小組，以提升解決方案的品質、可靠性和可維護性。 透過平衡的小組、支援的程式和技術自動化，採用機器學習作業的小組可以調整並專注於開發新的使用案例。
隨著組織中的使用案例數目增加，支援使用案例的管理負擔會以線性方式成長，甚至更多。 組織面臨的挑戰是如何加速上市時間、支援更快速評估使用案例可行性、實作可重複性，以及針對一系列專案的最佳可用資源和技能集。 對於許多組織而言，開發 AI Factory 是解決方案。
AI Factory 是可重複的商務程式和標準化成品系統，可協助開發和部署一組大型機器學習使用案例。 AI Factory 會優化小組設定、建議的做法、機器學習作業策略、架構模式，以及專為商務需求量身打造的可重複使用範本。
成功的 AI Factory 依賴可重複的程式和可重複使用的資產，協助組織有效率地從數十個使用案例調整為數千個使用案例。
下圖摘要說明 AI Factory 的主要元素：
針對可重複的架構模式進行標準化
可重複性是 AI Factory 的重要特性。 數據科學小組可以藉由開發一些可重複的架構模式來加速項目開發，並改善專案之間的一致性，這些模式涵蓋其組織大部分的機器學習使用案例。 當這些模式就緒時，大部分的專案都可以使用模式來取得下列優點：
- 加速設計階段
- 跨專案重複使用工具時，加速IT和安全性小組的核准
- 加速開發，因為可重複使用的基礎結構即程式代碼範本和項目範本
架構模式可以包含，但不限於下列主題：
- 專案每個階段的慣用服務
- 數據連線和控管
- 專為產業、商務或數據分類需求量身打造的機器學習作業策略
- 實驗管理冠軍和挑戰者模型
促進跨小組共同作業和共用
共用程式代碼存放庫和公用程式可以加速機器學習解決方案的開發。 程式代碼存放庫可以在專案開發期間以模組化的方式開發，使其足以用於其他專案中。 它們可以在中央存放庫中提供，讓所有數據科學小組都能存取這些存放庫。
共用和重複使用智慧財產權
若要最大化程式代碼重複使用，請在專案開頭檢閱下列智慧財產權：
- 設計為在組織中重複使用的內部程序代碼。 範例包括套件和模組。
- 在其他機器學習專案中建立的數據集，或可在 Azure 生態系統中取得的數據集。
- 具有類似架構和商務問題的現有數據科學專案。
- GitHub 或 開放原始碼 可加速專案的存放庫。
任何專案回顧都應該包含動作專案，以判斷專案的專案是否可以共用和一般化，以便更廣泛地重複使用。 組織可以共用和重複使用的資產清單會隨著時間而擴展。
為了協助共用和探索，許多組織已引進共用存放庫來組織代碼段和機器學習成品。 Azure 機器學習 中的成品，包括數據集、模型、環境和管線，都可以定義為程序代碼，因此您可以在專案和工作區之間有效率地共用。
專案範本
為了加速移轉現有解決方案並最大化程式代碼重複使用的程式，許多組織都會在專案範本上標準化以啟動新專案。 建議搭配 Azure 機器學習 使用的專案範本範例包括 Azure 機器學習 範例、資料科學 生命週期程式，以及 Team 資料科學 Process。
中央數據管理
取得探索或生產環境使用數據存取權的程序相當耗時。 許多組織會集中數據管理，將數據產生者和數據取用者結合在一起，以便更輕鬆地存取機器學習實驗的數據。
共用公用程式
您的組織可以使用全企業集中式儀錶板來合併記錄和監視資訊。 儀錶板可能包含錯誤記錄、服務可用性和遙測，以及模型效能監視。
使用 Azure 監視器計量來建置 Azure 機器學習 和相關服務的儀錶板，例如 Azure 儲存體。 儀錶板可協助您追蹤實驗進度、計算基礎結構健全狀況和 GPU 配額使用率。
專業機器學習工程小組
許多組織都實作機器學習工程師的角色。 機器學習工程師專門建立和執行健全的機器學習管線、漂移監視和重新定型工作流程，以及監視儀錶板。 工程師對於將機器學習解決方案產業化的整體責任，從開發到生產。 工程師會與數據工程、架構設計人員、安全性和作業密切合作，以確保所有必要的控件都已就緒。
雖然數據科學需要深入的領域專業知識，但機器學習工程更注重技術性。 差異讓機器學習工程師更具彈性，因此他們可以處理各種專案，並與各種商務部門合作。 大型數據科學實務可能受益於專業機器學習工程小組，可推動跨各種使用案例和商務領域的自動化工作流程的重複性和重複使用。
啟用和檔
請務必為新的和現有的小組和使用者提供 AI Factory 程式的明確指引。 指引有助於確保一致性，並減少機器學習工程小組在將專案產業化時所需的工作。 請考慮特別針對您組織中的各種角色設計內容。
每個人都有獨特的學習方式，因此下列指引類型的混合有助於加速採用 AI Factory 架構：
- 具有所有成品連結的中央中樞。 例如，此中樞可能是 Microsoft Teams 或 Microsoft SharePoint 網站上的頻道。
- 針對每個角色所設計的訓練和啟用計劃。
- 方法的高階摘要簡報和隨附影片。
- 詳細的檔或劇本。
- 操作說明影片。
- 整備評估。
Azure 影片系列中的機器學習作業
關於 Azure 中機器學習作業的影片系列說明如何為機器學習解決方案建立機器學習作業，從初始開發到生產環境。
倫理學
道德在 AI 解決方案的設計中扮演了重要角色。 如果未實作道德原則，定型的模型可能會顯示其定型數據中存在的相同偏差。 結果可能是專案已停止。 更重要的是，組織的聲譽可能會面臨風險。
為了確保組織所代表的主要道德準則會在專案之間實作，組織應該提供這些原則的清單，以及從測試階段的技術觀點驗證這些原則的方法。 使用 Azure 機器學習 中的機器學習功能，瞭解什麼是負責任的機器學習，以及如何將它建置到您的機器學習作業中。
下一步
深入瞭解如何組織和設定 Azure 機器學習 環境，或觀看 Azure 中機器學習作業的實作影片系列。
深入瞭解如何使用 Azure 機器學習 管理組織層級的預算、配額和成本：