機器學習訓練流程設計與實務挑戰

– 15 分鐘閱讀

在機器學習系統開發中，穩健的訓練流程至關重要，它涵蓋從資料處理到模型佈署的完整生命週期。許多工程師常聚焦於模型本身而忽略流程設計，導致模型更新迭代困難。本文將探討訓練流程的各個環節，包括資料處理與清洗、模型訓練、驗證與佈署，並闡述如何構建可重複使用且可靠的機器學習系統。同時，也將區分訓練流程與推論流程的差異，並探討錯誤分析、殘差分析等技術的重要性，以及如何應對可擴充套件性、可組態性等常見挑戰。最後，文章將介紹ML管線的測試策略，包含煙霧測試、單元測試和屬性基礎測試，以確保模型的可靠性和穩定性。

訓練流程的重要性與實務挑戰

在機器學習（ML）領域中，訓練流程（Training Pipeline）是建立可靠且可重複使用的模型之關鍵步驟。許多新手工程師往往將焦點放在模型本身，而忽略了完整的訓練流程設計。實際上，訓練流程涵蓋從資料處理到模型佈署的整個生命週期，確保每個步驟的可重現性和一致性對於建立穩健的ML系統至關重要。

為什麼需要訓練流程？

以一個小型披薩連鎖店為例，該公司決定數位化並僱用了一位年輕的ML工程師Jane來開發一個AI輔助系統，以協助披薩製作人員進行視覺評估，如計算每個訂單中披薩底座上的配料數量。Jane成功訓練了一個模型並完成了初步測試，但當產品經理要求新增多個新配方時，卻發現重新訓練模型需要耗費數月的時間。主要問題在於Jane雖然完成了所有必要的步驟，但採用的是臨時（Ad Hoc）的方式，缺乏一個統一且可重現的工作流程。

訓練流程與推論流程的區別

在ML領域中，「流程」（Pipeline）一詞有多種不同的應用情境。通常，流程指的是一系列有序的步驟和過程，每個步驟是一個程式，接受輸入、執行某些操作並產生輸出。訓練流程主要關注如何準備資料、訓練模型以及生成其他相關產出，而推論流程（Inference Pipeline）則專注於如何將已訓練好的模型佈署到生產環境中進行預測。

訓練流程的主要組成

  1. 資料處理與清洗：對原始資料進行必要的轉換和清理，以確保資料品質。
  2. 模型訓練：使用處理後的資料來訓練ML模型。
  3. 模型驗證：透過各種指標和測試來評估模型的效能。
  4. 模型佈署：將訓練好的模型整合到生產系統中。

實作可重現性的關鍵

為了使訓練流程具有可重現性，必須將所有步驟自動化並記錄下來。這包括資料預處理、特徵工程、模型選擇和超引數調優等。透過使用適當的工具和平台，可以簡化流程設計並提高其可擴充套件性和可組態性。

常見挑戰與解決方案

  • 挑戰1：缺乏標準化的流程設計
    解決方案：採用標準化的流程設計工具，如Apache Airflow或Kubeflow Pipelines，以自動化和監控每個步驟。

  • 挑戰2：資料品質問題
    解決方案：實施嚴格的資料驗證和清洗機制，確保輸入資料的品質。

  • 挑戰3：模型可擴充套件性不足
    解決方案：使用可擴充套件的模型訓練框架，並結合雲端運算資源，以應對日益增長的資料量和複雜度。

錯誤分析在訓練流程中的角色

在設計ML系統時，進行錯誤分析（Error Analysis）是非常重要的一環。這有助於揭示系統的弱點並提出改進方案。透過分析損失函式（Loss）和評估指標（Metric），可以識別出模型的過擬合（Overfitting）和欠擬合（Underfitting）問題，並據此採取相應的調優措施。

殘差分析的重要性

殘差分析（Residual Analysis）用於驗證模型假設、檢測指標變化的來源、確保殘差的公平性，並進行最壞情況和最佳情況分析。這對於理解模型的表現和最佳化方向具有重要意義。

前瞻性思考

隨著ML技術的發展，未來可以考慮應用可解釋性技術（Interpretability Techniques）來進一步提升模型的透明度和可信度。例如，探究為什麼某張圖片在語義上與另一張圖片接近，這類別問題將變得越來越重要。

總之，完善的訓練流程設計、嚴謹的錯誤分析和持續的模型最佳化，是開發高效、可靠ML系統的關鍵所在。

訓練流程：定義與架構

訓練流程（Training Pipeline）是機器學習（Machine Learning, ML）模型開發中的關鍵概念，負責將原始資料轉換為可佈署的模型。該流程涉及多個步驟，每一步驟的輸出皆為下一步驟的輸入，形成有向無環圖（Directed Acyclic Graph, DAG）結構。

訓練流程 vs. 推理流程

在機器學習領域中，「流程」（Pipeline）一詞可能引起歧義，因為它既可以指訓練模型所使用的訓練流程，也可以指在生產環境中執行模型進行預測的推理流程（Inference Pipeline）。為了區分這兩者，我們定義：

  • 訓練流程：用於訓練模型的流程，輸入為完整資料集和相關後設資料，輸出為訓練好的模型。它是一種高層次的抽象。
  • 推理流程：用於在生產環境中執行模型的流程，輸入為原始資料，輸出為預測結果。它是一種較低層次的抽象，通常作為訓練流程的一部分或在生產環境中使用。

典型訓練流程的步驟

典型的訓練流程包括以下七個主要步驟：

  1. 資料擷取（Data Fetching）：從資料來源下載資料並使其可供後續步驟使用。
  2. 預處理（Preprocessing）：準備資料以供模型訓練使用，包括特徵選取等步驟。
  3. 模型訓練（Model Training）：使用預處理後的資料訓練模型，是整個流程中最複雜且耗時的步驟。
  4. 模型評估與測試（Model Evaluation and Testing）：計算評估指標並進行測試，以確保模型表現良好且運作正常。
  5. 後處理（Postprocessing）：準備模型以供佈署使用，可能包括模型格式轉換、量化等最佳化步驟。
  6. 報告生成（Report Generation）：生成相關報告和指標，用於評估模型表現和實驗結果。
  7. 成品封裝（Artifact Packaging）：將模型和其他相關檔案封裝成可輕易佈署至生產環境的格式。

各步驟詳解

資料擷取

負責下載資料並提供給後續步驟。本文不探討資料工程相關內容。

預處理

根據特定任務的不同，預處理步驟也有所不同。通常包括特徵選取等動作，這些動作只在訓練階段進行，並凍結選取的特徵供後續步驟使用。

模型訓練

是訓練流程的核心，涉及使用預處理後的資料來訓練模型。這一步驟通常是整個流程中最耗時且最複雜的部分，尤其是在根據深度學習的系統中。

模型評估與測試

評估模型的表現並進行測試，以確保其運作正常。評估涉及計算指標，而測試則是一系列檢查，以確認模型是否按預期工作。

後處理

在評估和測試之後進行，用於準備模型以供佈署。可能包括將模型轉換為目標平台支援的格式，或應用其他最佳化技術。

成品封裝

是訓練流程的最後一步，負責將模型和其他相關檔案（如前處理器引數的組態檔案）封裝成易於佈署的格式。目標是使輸出盡量與訓練流程無關，以便簡化佈署和分離訓練與佈署流程。

報告生成

是一種特殊的成品，可能包括驗證/測試指標、錯誤分析、視覺化圖表等。這些報告對於確認訓練成功至關重要，並可用於實驗追蹤和重現。

重點整理

  • 訓練流程是一種高層次的抽象，用於描述如何從原始資料到訓練好的模型。
  • 推理流程則是一種較低層次的抽象，用於在生產環境中執行已訓練好的模型。
  • 完整的訓練流程涉及多個步驟，每一步驟都有其特定的功能和目標。
  • 正確理解和設計訓練流程對於開發高效、可靠的機器學習系統至關重要。

訓練管線的工具與平台

在機器學習系統設計中，與訓練管線、推論管線、佈署管線和監控服務相關的工具和實踐常被歸因於機器學習運作（MLOps）。由於MLOps是一個相對較新的領域，因此對於平台和工具尚未有公認的標準。一些工具相對較為知名，如MLflow、Kubeflow、BentoML、AWS Sagemaker、Google Vertex AI和Azure ML，而其他的則正在獲得關注或仍處於開發初期。

訓練管線平台的特點

典型的訓練管線平台需要具備以下特點：

  • 解析依賴關係：由於管線是一個有向無環圖（DAG），因此解析步驟之間的依賴關係並按正確順序執行至關重要。
  • 可重現性：給定一組引數和管線版本（例如，由git提交指定），管線應該每次都產生相同的結果。
  • 與計算資源整合：使用者應該能夠在特定的計算例項（例如，具有X個CPU核心和N個GPU的虛擬機器）或例項叢集上執行作業。
  • 工件儲存：一旦訓練管線執行完成，其工件應該可用。實驗追蹤可以被視為此功能的一個子集。
  • 快取中間結果：由於管線中的許多步驟計算成本高昂，因此快取中間結果以節省資源和時間非常重要。

除了功能特點外，從業人員還需要考慮平台的非功能性需求，包括成本效益和資料隱私（尤其是在醫療保健或法律等敏感領域）。

選擇適當的工具

選擇適當的工具取決於問題規模和公司的基礎設施。大型公司通常擁有自己的機器學習平台和工具，可以在大規模上運作，而較小的公司則傾向於使用開源工具和雲端服務的組合。每個工具都有其採用成本，因此選擇適合特定問題的正確工具非常重要。目前尚無一體適用的解決方案，不同的工具適用於不同的需求。

訓練管線的可擴充套件性

可擴充套件性對於某些問題的訓練管線來說是一個關鍵屬性。當處理龐大的資料集時，單一機器可能無法處理，因此需要可擴充套件的解決方案。

垂直擴充套件與水平擴充套件

有兩種經典的軟體工程方法可以實作擴充套件：垂直擴充套件和水平擴充套件。

  • 垂直擴充套件意味著升級硬體或用更強大的節點替換訓練機器。其優點是簡單易行，但其侷限性在於無法無限制地升級硬體。
  • 水平擴充套件涉及將負載分散到多台機器上。第一級水平擴充套件是使用多個GPU機器；在這種情況下，機器學習工程師通常需要對管執行緒式碼進行小幅更改。

詳細程式碼範例與解析

以下是一個使用Python和Kubernetes進行水平擴充套件的簡單範例：

from kubernetes import client, config

# 組態Kubernetes客戶端
config.load_kube_config()

# 建立一個新的Kubernetes客戶端例項
v1 = client.CoreV1Api()

# 定義一個Pod範本，用於執行訓練作業
pod_template = {
    "apiVersion": "v1",
    "kind": "Pod",
    "metadata": {"name": "training-pod"},
    "spec": {
        "containers": [{
            "name": "training-container",
            "image": "training-image:latest",
            "resources": {"requests": {"cpu": "2", "memory": "4Gi"}, "limits": {"cpu": "2", "memory": "4Gi"}}
        }]
    }
}

# 建立Pod
v1.create_namespaced_pod(namespace="default", body=pod_template)

#### 內容解密：
此程式碼範例展示瞭如何使用Kubernetes Python客戶端建立一個新的Pod來執行訓練作業。首先，我們載入Kubernetes組態並建立一個CoreV1Api客戶端例項。然後，我們定義了一個Pod範本，指定了要使用的容器映像和資源請求/限制。最後，我們使用`create_namespaced_pod`方法在預設名稱空間中建立Pod。這種方法允許我們水平擴充套件訓練作業到多個機器上。

10.4 可組態性

在機器學習（ML）領域中，訓練管線（training pipeline）的可組態性（configurability）是至關重要的。當設計訓練管線的可組態性時，ML 工程師需要在兩個極端之間找到平衡：組態不足（underconfiguration）和組態過度（overconfiguration）。

組態不足的問題

組態不足意味著訓練管線的靈活性不夠，難以更改模型的架構、資料集、預處理步驟等。許多引數被硬編碼（hardcoded），使得理解和修改管線變得困難。這通常是 ML 開發早期階段的問題，因為當管線小而簡單時，很容易理解和更改。因此，沒有軟體工程背景的研究人員可能認為引入適當的軟體抽象是不必要的，導致程式碼不斷增加但缺乏結構。

組態過度的問題

組態過度同樣不是理想的。典型的 ML 管線具有許多與資料集處理、模型架構、特徵工程和訓練過程相關的超引數（hyperparameters）。在現實中，很難預測所有可能的使用案例和可以更改的引數。沒有經驗的開發人員可能會嘗試涵蓋所有可能的情況，並引入盡可能多的抽象層。最終，這些額外的抽象層只會增加複雜度。

以下是一個組態過度的程式碼範例：

class Config(BaseConfig):
    def __init__(self):
        self.data_config = DataConfig()
        self.model_config = ModelConfig()
        self.training_config = TrainingConfig()
        self.inference_config = InferenceConfig()
        self.environment_config = EnvironmentConfig()

class DataConfig(BaseConfig):
    def __init__(self):
        self.train_data_config = TrainDataConfig()
        self.validation_data_config = ValidationDataConfig()
        self.test_data_config = TestDataConfig()

config = Config(
    data_config=DataConfig(
        train_data_config=TrainDataConfig(
            # ...
        ),
        validation_data_config=ValidationDataConfig(
            # ...
        ),
        test_data_config=TestDataConfig(
            # ...
        ),
    ),
    # ...
)

內容解密：

這段程式碼展示了一個多層次的組態結構，試圖涵蓋所有的組態可能性。然而，這種做法使得組態變得過於複雜，增加了使用和維護的難度。Config 類別包含了多個子組態類別，如 DataConfig、ModelConfig 等，每個子組態類別又可能包含更多的子組態類別。這種多層次的結構雖然看似靈活，但實際上卻增加了理解和修改組態的困難度。

尋找平衡

為了在兩個極端之間找到良好的平衡，需要評估各種引數被更改的機率。例如，幾乎可以肯定資料集會被更新，而模型內部的啟用函式（activation functions）被更改的可能性則相對較低。因此，使資料集可組態而忽略啟用函式是合理的。可更改的引數對於不同的管線來說是不同的，因此找到良好平衡的唯一方法是考慮在接下來的幾個月中哪些潛在的實驗是低垂的果實（low-hanging fruits）。Google 團隊提供了一份有用的，適用於根據深度學習的管線，參見 https://github.com/google-research/tuning_playbook。

超引數調優策略

在初步決定哪些超引數是可調的之後，確定調優策略是非常重要的。當計算資源有限時，手動實驗（hand-crafted experiments）是更可取的。當資源充足時，使用自動化的超引數調優方法（如簡單的隨機搜尋或更先進的貝葉斯最佳化）是有意義的。用於超引數調優的工具（如 Hyperopt、Optuna 和 scikit-optimize）可以是 ML 平台的一部分，並可能決定組態檔案的外觀。

根據我們的經驗，廣泛的超引數調優更適用於小型資料集，因為在合理的時間內可以執行大量的實驗。當單個實驗需要數週時，更實際的做法是依靠 ML 工程師的直覺並手動執行幾個實驗。值得注意的是，使用較小資料集進行的實驗可能有助於建立這種直覺，儘管並非每個結論都可以推廣到大型訓練執行。

組態訓練管線

找到合適的方法來組態訓練管線是非常重要的（如圖 10.5 所示）。

@startuml
skinparam backgroundColor #FEFEFE

title 機器學習訓練流程設計與實務挑戰

|開發者|
start
:提交程式碼;
:推送到 Git;

|CI 系統|
:觸發建置;
:執行單元測試;
:程式碼品質檢查;

if (測試通過?) then (是)
    :建置容器映像;
    :推送到 Registry;
else (否)
    :通知開發者;
    stop
endif

|CD 系統|
:部署到測試環境;
:執行整合測試;

if (驗證通過?) then (是)
    :部署到生產環境;
    :健康檢查;
    :完成部署;
else (否)
    :回滾變更;
endif

stop

@enduml

此圖示展示了訓練管線的基本元件及其相互關係。模型（Model）是核心，它生成報告（Reports）並進行推理（Inference）。資料（Data）是模型的輸入，而組態（config）則控制著模型和推理過程。

內容解密：

這個圖表使用 Plantuml 語法繪製，展示了訓練管線的主要元件及其關係。模型是核心元件，它接收資料輸入並根據組態進行處理，最終生成報告和進行推理。這種視覺化表示有助於理解訓練管線的工作流程和各元件之間的依賴關係。

最典型的作法是專門使用一個檔案（通常使用 YAML 或 TOML 等特定語言編寫），其中包含所有可更改的值。另一種流行的作法是使用像 Hydra（https://hydra.cc/）這樣的函式庫。我們曾經見過的一種反模式（antipattern）是將組態分散在訓練管線檔案中，同一個引數在多個檔案中被指定，並且具有不同的優先順序別（例如，批次大小可以從檔案 X 中讀取，但如果沒有在那裡指定，則嘗試從檔案 Y 中取得）。這在實驗階段可能會導致錯誤，特別是當實驗由不熟悉該特定管線的經驗不足的工程師執行時。

綜上所述，設計一個適當可組態的訓練管線需要在靈活性和複雜度之間取得平衡，並選擇合適的超引數調優策略，以確保模型的最佳效能。

機器學習訓練流程的測試策略

在機器學習（ML）專案中，測試是確保模型可靠性和穩定性的關鍵步驟。然而，由於ML模型的複雜性和訓練過程的耗時性，測試ML管道（pipelines）是一項具有挑戰性的任務。本篇文章將探討如何在ML專案中實施有效的測試策略，以確保模型的正確性和可靠性。

為什麼測試ML管道如此重要？

測試ML管道有多個重要目的：

  1. 避免迴歸錯誤：在引入變更時，測試可以幫助檢測是否引入了新的錯誤。
  2. 提高迭代速度：透過及早發現缺陷，測試可以加快開發迭代的速度。
  3. 改善管道設計：測試迫使工程師找到可組態性和穩定性之間的適當平衡，從而改善管道的整體設計。

測試策略：煙霧測試和單元測試

對於ML管道的測試，建議結合高層級的煙霧測試（smoke tests）和低層級的單元測試（unit tests）。

煙霧測試

煙霧測試應該盡可能快速執行，通常使用小型資料集、減少訓練輪數或簡化模型。它檢查管道是否能夠無錯誤地執行並產生合理的輸出。例如，檢查損失函式是否在小型資料集上減少。

from unittest.mock import patch, Mock
import torch
from training_pipeline import train, get_config

class DummyResnet(torch.nn.Module):
    def __init__(self):
        super().__init__()
        self.model = torch.nn.Sequential(torch.nn.AdaptiveAvgPool2d(1),
                                         torch.nn.Conv2d(3, 2048, 1))

    def forward(self, x):
        return self.model(x).squeeze(-1).squeeze(-1)

def test_train_pipeline():
    config = get_config()
    config["dataset_path"] = "/path/to/fixture"
    config["num_epochs"] = 1
    mock = Mock(wraps=DummyResnet)
    with patch('training_pipeline.models.Resnet', mock):
        result = train(config)
        assert mock.call_count == 1
        assert result['train_loss'] < 0.5
        assert result['val_loss'] < 1

單元測試

單元測試關注於管道中的個別元件。至少應該對最關鍵的元件進行單元測試，例如模型轉換過程。確保轉換後的模型與原始模型產生相同的結果。

屬性基礎測試

屬性基礎測試是一種軟體測試方法，透過生成隨機輸入並驗證系統是否滿足某些屬性或不變數。在ML專案中，可以用來驗證訓練好的模型是否表現如預期。一些可以測試的屬性包括：

  • 一致性：給定相同的輸入資料，模型應該產生相同的輸出。
  • 單調性：模型的輸出應該隨著某些輸入特徵的變化而單調變化。
  • 對變換的不變性：模型對某些輸入資料的變換應該保持不變。
  • 魯棒性：模型對輸入資料的小擾動應該保持穩定。
  • 否定性：對於某些輸入資料的否定，模型應該給出相反的預測。

內容解密：

上述屬性基礎測試涵蓋了多個重要的模型評估導向：

  1. 一致性確保模型對於相同輸入始終給出相同輸出，檢查模型的確定性行為。
  2. 單調性驗證特定特徵變化時模型的輸出是否符合預期邏輯，例如房屋面積與價格的正相關關係。
  3. 對變換的不變性檢查模型是否具備處理不同形式輸入的能力，例如圖片旋轉或音量調整。
  4. 魯棒性評估模型對微小擾動的穩定性，確保實際應用中的可靠性。
  5. 否定性驗證模型是否能夠正確處理語義對立的輸入，例如情感分析中「喜歡」與「討厭」的區分。

這些屬性測試能夠有效驗證模型的行為是否符合預期，確保其在實際應用中的穩定性和可靠性。

設計檔案的考量

雖然通常不會在設計檔案中包含詳細的測試列表，但建議提前考慮並在檔案中提及。這有助於在實作過程中參考和遵循。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。