本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
步驟 3. 定義管線
在此步驟中,定義管道將執行的操作的順序和邏輯。這包括離散步驟及其邏輯輸入和輸出。例如,管道開頭的數據狀態是什麼? 它是來自處於不同粒度級別的多個文件還是來自單個平面文件? 如果數據來自多個文件,您是否需要對所有文件執行單獨的步驟,還是為每個文件定義預處理邏輯需要單獨的步驟? 決定取決於數據源的複雜性以及預處理數據源的程度。
在我們的參考實現中,我們使用AWS Step Functions
使用 Step Functions SDK
為了定義 ML 管道,我們首先使用AWS Step Functions資料科學開發套件(Step Functions SDK)來定義管道的兩個關鍵組件:步驟和資料。如果將管道視為有向無循環圖 (DAG),步驟表示圖形上的節點,數據顯示為將一個節點(步驟)連接到下一個節點的定向邊。ML 步驟的典型示例包括預處理、培訓和評估。Step Functions SDK 提供了許多內置步驟(例如培訓步驟
ML 管線還需要配置參數來對每個 ML 步驟的行為執行細粒度控制。這些特殊的數據佔位符稱為參數佔位置。當您定義管道時,它們的許多值是未知的。參數佔位符的示例包括您在管道設計過程中定義的基礎架構相關參數(例如,AWS 區域或容器映像 URL)和您在運行管道時定義的 ML 模型相關參數(如超參數)。
擴展 Step Functions SDK
在我們的參考實現中,一個要求是使用特定的參數設置將 ML 管道定義與混凝土 ML 管道創建和部署分離開來。但是,Step Functions SDK 中的一些內置步驟不允許我們傳入所有這些佔位符參數。相反,參數值應在管道設計期間通過 SageMaker 配置 API 調用直接獲取。如果 SageMaker 設計時環境與 SageMaker 運行時環境相同,這可以正常工作,但在現實世界設置中很少出現這種情況。管道設計時間和運行時間之間如此緊密的耦合,以及 ML 平台基礎架構將保持不變的假設,顯著阻礙了設計管道的適用性。事實上,當底層部署平台發生最小的變化時,ML 管道會立即中斷。
為了克服這一挑戰並生成一個強大的 ML 管道(我們希望設計一次並在任何地方運行),我們通過擴展一些內置步驟來實現我們自己的自定義步驟,包括培訓步驟、模型步驟,以及變形金剛步。這些擴展名在ML Max