本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
步驟 3。定義管道
在此步驟中,會定義管道將執行之動作的序列和邏輯。這包括離散步驟及其邏輯輸入和輸出。例如,管道開頭的資料狀態為何? 它是來自不同精細程度的多個檔案,還是來自單一平面檔案? 如果資料來自多個檔案,您是否需要所有檔案的單一步驟,或是每個檔案的個別步驟來定義預先處理邏輯? 決策取決於資料來源的複雜性及其預先處理的程度。
在我們的參考實作中,我們使用AWS Step Functions
使用 Step Functions SDK
為了定義 ML 管道,我們首先使用AWS Step Functions 資料科學 SDK (Step Functions SDK) 提供的高階 Python API 來定義管道的兩個關鍵元件:步驟和資料。如果您將管道視為定向無環圖 (DAG),步驟代表圖形上的節點,而資料會顯示為將一個節點 (步驟) 連接到下一個節點的定向邊緣。ML 步驟的典型範例包括預先處理、訓練和評估。Step Functions SDK 提供許多您可以使用的內建步驟 (例如 TrainingStep
ML 管道也需要組態參數,才能對每個 ML 步驟的行為執行精細控制。這些特殊資料預留位置稱為參數預留位置。當您定義管道時,它們的許多值都是未知的。參數預留位置的範例包括您在管道設計 (例如 AWS 區域 容器映像 URL) 期間定義的基礎設施相關參數,以及您在執行管道時定義的 ML 建模相關參數 (例如超參數)。
擴展 Step Functions SDK
在我們的參考實作中,其中一項要求是使用特定參數設定,將 ML 管道定義與具體的 ML 管道建立和部署分開。不過,Step Functions SDK 中的一些內建步驟不允許我們傳遞所有這些預留位置參數。反之,預期參數值會在管道設計期間透過 SageMaker AI 組態 API 呼叫直接取得。如果 SageMaker AI 設計時間環境與 SageMaker AI 執行時間環境相同,這就沒問題,但在實際設定中很少如此。這種管道設計和執行時間之間的緊密耦合,以及 ML 平台基礎設施將保持不變的假設,會嚴重阻礙設計管道的適用性。事實上,ML 管道會在基礎部署平台進行最細微的變更時立即中斷。
為了克服這項挑戰並產生強大的 ML 管道 (我們希望設計一次並在任何地方執行),我們透過擴展一些內建步驟來實作自己的自訂步驟,包括 TrainingStep、ModelStep 和 TransformerStep。這些擴充功能會在 ML Max 專案