エンドツーエンドのMLパイプラインの構築方法

エンドツーエンドのMLパイプライン構築方法

コミュニティのMLエンジニアから最もよく聞かれる不満の一つは、モデルの構築と展開のMLワークフローを手動で行うことがいかにコストがかかり、エラーの発生しやすいことです。彼らはトレーニングデータを前処理するためにスクリプトを手動で実行し、展開スクリプトを再実行し、モデルを手動で調整し、以前に開発されたモデルを最新の状態に保つために作業時間を費やします。

エンドツーエンドの機械学習パイプラインを構築することで、MLエンジニアは一度構築し、何度も再実行し、再利用することができます。彼らは新しいモデルの展開に重点を置くことができ、既存のモデルの保守に時間を費やす必要はありません。

もちろん、すべてがうまくいけば😉

この記事では、以下のことについて説明します：

• Pythonでトレーニング済みモデルを保存する方法
• 小売およびeコマースにおけるMLプラットフォームの構築
• MLモデルのトレーニングパイプラインの構築方法

• 1
  MLパイプラインのアーキテクチャについて、コンポーネントを含めて調査すること。
• 2
  頑健でスケーラブルなエンドツーエンドの機械学習パイプラインを構築するための機械学習エンジニアが従うべき必須の手順とベストプラクティスを学ぶこと。
• 3
  Kubeflow Pipelinesを使用してAWS上でエンドツーエンドのMLパイプラインを素早く構築および展開すること。
• 4
  エンドツーエンドのMLパイプラインの構築の課題とそれを構築するためのベストプラクティスを学ぶこと。

機械学習パイプラインとは何ですか？

機械学習パイプラインは、特定の問題を解決するための機械学習ワークフローを定義する一連のリンクされたコンポーネントまたはステップで構成されています。パイプラインを使用すると、自動化できるMLワークフローのステップをオーケストレーションできます。ここでのオーケストレーションは、ワークフローステップ間の依存関係とデータフローが適切な順序で完了することを意味します。

パイプラインを構築する目的は以下の通りです：

• ワークフローの再現性を実現する（同様の入力でパイプラインを繰り返し実行すると、類似の出力が得られる）。
• 機械学習ワークフローのエンドツーエンドのオーケストレーションを簡素化する（MLチームのほとんどの介入（自動化）なしで、多くのステップのオーケストレーションを行う）。
• データとモデルが実験フェーズから本番フェーズに移行するのにかかる時間を短縮する。
• ワークフローのためのモジュラーコンポーネントを使用して、既存のモデルのメンテナンスよりも新しいソリューションの開発に重点を置くチームに便利な自動化を提供する。
• 外部システムと統合されたエンドツーエンドのソリューションを作成および展開するためのワークフローの特定のステップを再利用することを簡単にする。

機械学習パイプラインと機械学習プラットフォームの比較

MLパイプラインは、より広範なMLプラットフォームの一部です。MLパイプラインは、MLプラットフォーム内の機械学習ワークフローを合理化、オーケストレーション、自動化するために使用されます。

パイプラインとプラットフォームは、MLOpsの関連する概念ですが、機械学習ワークフローの異なる側面を指します。MLプラットフォームは、ML / AIチームの技術スタックを標準化し、MLアプリケーションの開発、展開、運用化のためのツール、ライブラリ、インフラストラクチャを提供する環境です。

プラットフォームには通常、データ管理、特徴ストア、実験トラッカー、モデルレジストリ、テスト環境、モデルサービング、モデル管理など、MLエコシステムのコンポーネントが含まれています。これは、主にデータサイエンティストとMLEがモデルの開発と展開、データの管理、機械学習ワークフローの合理化を行うための統一された統合環境を提供するように設計されています。

機械学習パイプラインのアーキテクチャ

機械学習パイプラインのアーキテクチャは、使用ケースと本番の要件に応じてリアルタイム（オンライン）またはバッチ（オフライン）の構造になる場合があります。この記事では、リアルタイムまたはバッチの構造のニュアンスを省いた典型的なパイプラインの構造を学びます。

Semi Koenの記事では、機械学習パイプラインのアーキテクチャについて詳細な洞察を提供しています。

一般的なタイプの機械学習パイプライン

MLワークフローのステージ（データ、モデル、プロダクション）に沿って、MLパイプラインは異なるワークフローステージを解決する3つの異なるパイプラインで構成されます。以下を含みます：

• 1
  データ（または入力）パイプライン。
• 2
  モデル（またはトレーニング）パイプライン。
• 3
  サービング（またはプロダクション）パイプライン。

大規模な組織では、機能とスケールにより、各パイプラインを2つ以上のチームが担当することが多いです。これらのパイプラインは、作業システムを構築するために相互運用可能です：

データ（入力）パイプライン（データ取得および特徴管理の手順）

このパイプラインは、生のデータを1つの場所から別の場所に輸送します。データの移動プロセス全体をカバーし、データが収集された場所からデータストリームまたはバッチ処理などを介してデータレイクや機械学習モデルなどの下流アプリケーションまでのプロセスをカバーします。

モデルトレーニングパイプライン

このパイプラインは、トレーニングデータに基づいて1つ以上のモデルをトレーニングし、事前に設定されたハイパーパラメータで評価し、微調整し、最適なモデルをパッケージ化してモデルレジストリやサービングパイプラインなどのアプリケーションに送信します。

サービングパイプライン

このパイプラインは、モデルをプロダクションで予測（またはスコアリング）サービスとしてデプロイし、パフォーマンスモニタリングを可能にする別のサービスを使用します。

この記事では、異なるパイプラインを「機械学習パイプライン」と分類しています。なぜなら、それらはワークフロー内の機能に基づいてMLアプリケーションを可能にするからです。さらに、保守中（再トレーニングと継続的なテスト中）に特にプロダクションアプリケーションを可能にするために相互運用可能です。

機械学習パイプラインの要素

一部のパイプラインは、以下の3つの要素を通じてこれらのコンポーネントに対する高レベルの抽象化を提供します：

1. トランスフォーマー：1つのデータセットを別のデータセットに変換することができるアルゴリズム。
2. エスティメータ：データセットでトレーニングされ、トランスフォーマーを生成するアルゴリズム。
3. イバリュエータ：トレーニングされたモデルの精度を調べるためのもの。

機械学習パイプラインのコンポーネント

パイプラインコンポーネントは、入力を受け取り、処理を行い、出力を生成する機械学習ワークフローの1つのステップです。これらのコンポーネントは、自動化可能なステップのためのマニュアルワークフロープロセスの実装を含みます。これには次のものがあります：

• データ取り込み（抽出とバージョニング）。
• データの検証（データ品質のチェックを行うためのテストの作成）。
• データの前処理。
• 選択した一部のアルゴリズムと実験中に使用するハイパーパラメータの範囲を指定して、モデルのトレーニングとチューニング。
• モデルのパフォーマンス分析と評価。
• モデルのパッケージ化と登録。
• モデルのデプロイ。
• モデルのスコアリング。
• モデルのパフォーマンスモニタリング。

ほとんどのツールでは、パイプラインコンポーネントには依存関係の問題を解消するためにコンテナ化できる実行可能なコードが含まれます。各ステップは、Kubeflow Pipelines、Metaflow、またはZenMLなどのオーケストレーションツールで管理できます。

以下では、各コンポーネントについて簡単に説明します。

データの取り込み、抽出、およびバージョニング

このコンポーネントは、機械学習パイプライン外部のデータソースからデータを取り込み、入力として使用します。次のステップで使用される形式（CSV、Parquetなど）にデータセットを変換します。このステップでは、生のデータとバージョン管理されたデータも変換され、その起源を追跡しやすくします。

データの検証

このステップでは、変換されたデータを入力として収集し、一連のテストとバリデータを通じて次のコンポーネントの基準を満たすかどうかを確認します。データの品質の問題をチェックし、外れ値や異常値を検出します。このコンポーネントは、データのドリフトやトレーニングとサービングの偏りの兆候をチェックし、他のコンポーネントにログを送信するか、担当するデータサイエンティストに警告を発します。

検証テストに合格した場合、データは次のコンポーネントに送信され、失敗した場合はエラーがログに記録され、実行が停止します。

データの前処理と特徴エンジニアリング

データのクリーニング、分離、および特徴エンジニアリングのステップは、前のコンポーネントからの検証済みおよび変換済みデータを入力として受け取ります。このステップで行われるプロセスは、解決しようとしている問題とデータに依存します。ここでのプロセスには、次のものが含まれる場合があります：

• 特徴選択：クリーニングおよびエンジニアリングする最適な特徴を選択します。
• 特徴クリーニング：欠損した特徴値の処理およびコード実装に基づいたキャッピング/フローリングによる外れ値の除去。
• 特徴変換：データ内のスケワー特徴の変換（該当する場合）。
• 特徴作成：既存の特徴から新しい特徴を作成するか、異なる特徴を組み合わせて新しい特徴を作成します。
• データの分割：データをトレーニング、テスト、および検証セットに分割します。
• 特徴の標準化/正規化：特徴値を同様のスケールと分布値に変換します。
• 組織全体でトレーニングと推論に使用するための特徴ストアに特徴を公開します。

再び、このコンポーネントで行われることは、データサイエンティストの初期（手動）データの準備プロセス、問題、および使用されるデータに主観的です。

モデルのトレーニングと調整

このコンポーネントは、フィーチャーストアから準備された特徴を取得するか、前のコンポーネントから準備されたデータセット（トレーニングセットと検証セット）を入力として受け取ることができます。

このコンポーネントは、事前に設定されたハイパーパラメータの範囲を使用してモデルをトレーニングします（グリッドサーチCV、ニューラルアーキテクチャサーチ、その他の技術を使用）。異なるハイパーパラメータ値のセットで複数のモデルを並列にトレーニングすることもできます。トレーニングされたモデルは、次のコンポーネントにアーティファクトとして送信されます。

モデルの評価

トレーニングされたモデルは、このコンポーネントの入力であり、検証セットで評価されます。ROC、AUC、精度、再現率、および正解率などのメトリクスに基づいて、各モデルの結果を分析することができます。メトリクスは通常、問題に基づいて設定されます。これらのメトリクスは、将来の分析のためにログに記録されます。

モデルの分析と検証

このコンポーネントは以下のようなことを行います：

• 1
  モデルが未知のデータに対して一般化できる能力を評価します。
• 2
  モデルの解釈可能性/説明可能性を分析し、展開する予定のモデルまたはモデルの品質とバイアスを理解するのに役立ちます。データスライスでのモデルのパフォーマンスやモデルの特徴の重要性を調べます。ブラックボックスモデルですか、それとも意思決定を説明できますか？

複数のモデルをトレーニングする場合、このコンポーネントは各モデルをテストセットで評価し、最適なモデルを選択するオプションを提供することもできます。

ここでは、コンポーネントはまた、モデルがターゲットの展開環境に適しているかどうかを理解するのに役立つ統計情報とメタデータも返します。たとえば：

• インフラ要件に合うには大きすぎませんか？
• 予測を返すのにどれくらい時間がかかりますか？
• 予測を行う際にどれくらいのリソース（CPU使用率、メモリなど）を消費しますか？

パイプラインが展開されている場合、このコンポーネントはトレーニングされたモデルのメトリクスを本番環境のメトリクスと比較し、それらが著しく低い場合にアラートを出すのにも役立ちます。

モデルのパッケージ化と登録

このコンポーネントは、モデルをステージング環境または本番環境に展開するためにパッケージ化します。モデルのアーティファクトと必要な設定ファイルがパッケージ化され、バージョン管理され、モデルレジストリに送信されます。

モデルをパッケージ化するための有用なテクニックとして、コンテナがあります。コンテナは、デプロイされたモデルを独立したスコアリングサービスとしてどこでも実行するためにカプセル化します。他の展開オプションも利用可能であり、本番環境の言語でデプロイされたコードを再作成するなどの方法があります。機械学習パイプラインでは、一般にコンテナを使用することが最も一般的です。

モデルの展開

パッケージ化された登録済みモデルをステージング環境（DevOpsを使用した従来のソフトウェアとして）または本番環境に展開することができます。ステージング環境は統合テストのためのものです。ステージング環境は、アプリケーションを有効にするシステム全体の他のサービスと一緒にモデルをテストできる最初の本番環境です。たとえば、推薦サービスを展開し、クライアントのリクエストをサービスにルーティングするバックエンドサーバーでそれをテストすることができます。

一部の組織では、Kubernetesのようなコンテナオーケストレーションプラットフォームでステージングを選択する場合もあります。これは、パイプラインのオーケストレーションに使用しているツールに依存します。

推奨されないですが、パッケージ化された登録済みモデルを直接本番環境に展開することもできます。

モデルのスコアリングサービス

デプロイされたモデルは、リアルタイムでクライアントのリクエストを予測します（オンラインシステムの場合）またはバッチで処理します（オフラインシステムの場合）。予測結果は、モニタリングサービスまたはオンライン評価ストアに記録され、モデルの予測パフォーマンス、特に概念/モデルの変化を監視します。

スコアリングサービスでは、キャナリーデプロイメント、シャドウモードデプロイメント、およびA/Bテストなどの展開戦略を採用することができます。たとえば、本番環境のチャンピオンモデルと複数のチャレンジャーモデルを展開することができます。これらはすべてクライアントから同じ予測リクエストを受け取りますが、結果を返すのはチャンピオンモデルのみです。他のモデルはモニタリングサービスに予測をログに記録します。

パフォーマンスのモニタリングとパイプラインのフィードバックループ

パイプラインの最後の部分は、モニタリングコンポーネントであり、データに対してチェックを実行します。また、本番環境のモデルのパフォーマンスを測定するために収集した推論評価スコア（モデルのメトリクスまたは他のプロキシメトリクス）を追跡します。

一部のモニタリングコンポーネントは、パイプラインの操作効率も監視し、次のようなことを含みます：

• パイプラインの健全性、
• API呼び出し、
• リクエストのタイムアウト、
• リソースの使用状況など。

完全自動化された機械学習パイプラインでは、継続的な統合（CI）、継続的なデリバリー（CD）、継続的なトレーニング（CT）が重要になります。パイプラインは、CI、CD、またはCTを実行するためにスケジュールされることもあります。また、以下の要素によってトリガーされることもあります：

• 1
  モデルのドリフト、 
• 2
  データのドリフト、
• 3
  責任者のデータサイエンティストによるオンデマンド。

多くのモデルを本番環境で実行する場合、MLパイプラインの自動化は重要な生産性の決定となります。

エンドツーエンドの機械学習パイプラインの構築方法

ほとんどのパイプラインは、以下の順序で構築します：

• 1
  コンポーネントのコード実装をスクリプト内のモジュラーな関数として定義するか、既存のコード実装を再利用します。
• 2
  モジュラースクリプトをコンテナ化して、実装が独立して分離されるようにします。
• 3
  実装をパッケージ化し、プラットフォーム上に展開します。 

モジュラースクリプト

入力を受け取り出力を返すモジュラーな関数としてコンポーネントを定義することは、MLパイプラインの各コンポーネントを構築する方法の一つです。使用する言語によって異なります。コンポーネントはドメイン固有の言語（DSL）を使用してパイプラインを形成します。

以下は、Kubeflow PipelineでMLパイプラインを定義するためのDSLで書かれたスクリプトの例です：

import kfp.dsl as dsl

def my_pipeline_step(step_name, param1, param2, ...):
    return dsl.ContainerOp(
        name = step_name,
        image = '<path to my container image>',
        arguments = [
            '--param1', param1,
            '--param2', param2,
            ...
        ],
        file_outputs = {
            'output1' : '/output1.txt',
            'output2' : '/output2.json',
            ...
        }
    )

パッケージとコンテナ
Dockerなどのコンテナツールを使用するか、別の方法を選択してコードをどこでも実行できるようにすることができます。
オーケストレーションプラットフォームとツール
パイプラインのオーケストレーションプラットフォームとツールを使用すると、パッケージ化されたスクリプトとコンテナをDAGまたはオーケストレートされたエンドツーエンドのワークフローに管理し、ステップを順次実行することができます。
機械学習パイプラインのツール
以下は、機械学習パイプラインのオーケストレーションツールやプラットフォームの例です：



1

                Metaflow。            

2

                Kedroパイプライン。            

3

                ZenML。            

4

                Flyte。            

5

                Kubeflowパイプライン。            

Metaflow
Metaflowは、元々Netflixのプロジェクトであり、オーケストレーションからバージョニング、モデリング、展開など、MLスタックのすべての要素を結びつけるクラウドネイティブのフレームワークです。 Metaflowでは、ワークフローに関連する計算のDAGとしてパイプラインを指定することができます。 NetflixはMetaflow上で数百から数千の機械学習プロジェクトを実行しており、スケーラブルなフレームワークです。
Metaflowは、データやモデルなどのアーティファクトを通常のPythonインスタンス変数として読み込み、保存することができるため、他のドメイン固有の言語（DSL）を学ぶことなく、Pythonの基本的な知識を持つ人なら誰でも使用できます。

詳細については、ドキュメントを参照して、チュートリアルやリソースページを通じて始めることができます。
Kedro
Kedroは、モジュラーなデータサイエンスパイプラインを構築するためのPythonライブラリです。 Kedroは、再利用可能なコンポーネントからなるデータサイエンスワークフローを作成するのに役立ち、データパイプラインの高速化、データサイエンスのプロトタイピングの向上、パイプラインの再現性の向上を促進します。

この記事では、Kedroを使用してMLパイプラインを構築する方法について学ぶことができます。
ZenML
ZenMLは、移植性のある本番用MLOpsパイプラインを構築するための拡張可能なオープンソースのMLOpsフレームワークです。データサイエンティストとMLOpsエンジニアが共同開発を行う際に使用されます。

詳細なZenMLのコアコンセプトについては、ドキュメントをご覧ください。
Flyte
Flyteは、大規模なMLパイプラインをオーケストレーションするためのプラットフォームです。Flyteを使用すると、展開、保守、ライフサイクル管理、バージョン管理、トレーニングなどのタスクを実行することができます。また、Feast、PyTorch、TensorFlow、whylogsなどのプラットフォームとも連携することができます。

この記事では、ソフトウェアエンジニアであり、Union.aiのテクニカルエバンジェリストであるSamhita Allaによって、FlyteのMLOpsへの適用方法が簡略化されて説明されています。始めるには、ドキュメントを参照してください。
Kubeflow Pipelines
Kubeflow Pipelinesは、Kubernetesクラスタ上で直接ポータブルでスケーラブルかつ再現可能なエンドツーエンドの機械学習ワークフローを構築およびデプロイするためのオーケストレーションツールです。Kubeflow Pipelinesを次のステップで定義できます：
ステップ1：各コンポーネントのコード実装を実行可能ファイル/スクリプトまたは事前に構築されたコンポーネントを再利用して記述します。
ステップ2：ドメイン固有の言語(DSL)を使用してパイプラインを定義します。
ステップ3：定義したワークフローをビルドしてコンパイルします。
ステップ4：ステップ3では、直感的なPython SDK for pipelinesを介してパイプラインを実行するためにトリガーできる静的なYAMLファイルが作成されます。
Kubeflowは複雑であり、開発の反復サイクルが遅いため、Flyteのような他のK8sベースのプラットフォームを使用することでパイプラインの構築が容易になっています。ただし、Google Kubernetes Engine (GKE)のようなクラウド管理サービスをデプロイすることも簡単です。
PrefectやArgoなど、他のオーケストレーションツールも参考にすることができます。この記事は、10以上のオーケストレーションツールを比較していますので、役立つ情報が得られるかもしれません：Best Workflow and Pipeline Orchestration Tools。
デモ：エンドツーエンドのMLパイプラインの例
この例では、Kaggleの有名なTitanic MLコンペティションを基に、Kubeflow Pipelinesを使用してMLパイプラインを構築します。このプロジェクトでは、機械学習を使用して、Titanicの船難で生存した乗客を予測するモデルを作成します。
データセットには、経済的地位（クラス）、性別、年齢、生存に関する情報も提供されています。
前提条件

このデモでは、MiniKFを使用してAWS上にKubeflowをセットアップします。Arrikto MiniKFは、Kubeflowを始める最も速く簡単な方法です。また、MiniKFを使用してGoogle Cloudやローカルコンピュータを含む任意の場所にKubeflowをセットアップすることもできます。詳細は、ドキュメントを参照してください。
AWSアカウントがまだない場合は、作成してください。
Arrikto MiniKFをAWS Marketplace経由で使用する場合、この記事の執筆時点では1時間あたり0.509ドルかかります。デモは1時間未満で完了するため、このデモに従って3ドル以上の費用をかけることはありません。
このデモではArrikto MiniKF v20210428.0.1を使用します。このバージョンには以下がインストールされます：

Kubeflow v1.3
Kale v0.7.0 – ノートブックから始まる完全なデータサイエンスワークフローを実行するためのKubeflowのオーケストレーションツール
Kubernetes (Minikube v1.22.0を使用)



このデモステップは、執筆時点での最新のArrikto MiniKF v20221221.0.0でも機能します。AWS Marketplaceを介してMiniKFでKubeflowを展開する方法を学ぶために、公式ドキュメントのチュートリアルに従ってください。
MiniKFでKubeflowを展開した場合は、Kubeflowダッシュボードに移動してプロジェクトを設定します：

始めるには、(1)「Notebooks」をクリックし、(2)「+NEW SERVER」をクリックします。
ノートブックサーバーに名前を指定します：

他の項目はデフォルトのままにして（もちろん要件に応じて変更してください）、データボリュームのカテゴリーの「ADD VOLUME」をクリックします：

指定したサーバー名と「-vol-1/」がサフィックスとして追加された新しいデータボリュームが表示されます：

ノートブックサーバーを起動できます：

リソースの数に応じて、設定に数分かかる場合があります。緑色のチェックマークが表示されたら、「CONNECT」をクリックします：

これにより、Jupyterlabランチャーに移動し、新しいノートブックを作成したり、ターミナルにアクセスしたりできます：

ターミナルを起動すると、次のコマンドを入力します（データボリューム名を入力することを忘れないでください）：
$ cd <ここにデータボリューム名を入力>

$ git clone https://github.com/NonMundaneDev/layer-demo-kubeflow.git

(3) `layer_kubeflow_titanic_demo.ipynb`ノートブックを起動します：

最初のコードセルを実行した後、現在のカーネルで変更が反映されるようにカーネルを再起動します：

Kaleは、ノートブックのステップをKubeflow Pipelinesで実行できる機械学習パイプラインにコンパイルするのに役立ちます。ノートブックをMLパイプラインに変換するには、
(1) Kaleアイコンをクリックし、
(2) 有効にします：

Kaleは、ノートブックの探索プロセスの一環として実行するべきステップとスキップするべきステップを自動的に検出します。このノートブックでは、Kaleはすべてのステップを入力を受け取り、出力アーティファクトを返すコンポーネントに分類します。
(1) パイプラインの説明やその他の詳細を編集することができます。完了したら、
(2) 「コンパイルして実行」をクリックしてください：

すべてがうまくいけば、以下のようなビジュアルが表示されるはずです。 「実行中のパイプラインを表示」の横にある「表示」をクリックすると、新しいタブが開きます：

Kaleを介して実行したKubeflowパイプラインのDAG（有向非巡回グラフ）をパイプラインUIで表示し、パイプラインの実行を確認できるはずです：

次に、servingステップのモデルが返した結果を確認するには、「randomforest」ステップをクリックして「Visualizations」に移動し、「Static HTML」セクションにスクロールして最後のセルの予測結果を表示します：

この場合、ノートブックのservingステップに渡されたダミーデータに基づいて、モデルはこの特定の乗客が難破船で生き残れないと予測しました。
また、モデルが提供するURLエンドポイントを取得する手順は次のとおりです：

サイドバーの「Models」をクリックし、すでにモデルが提供されていることを確認します。Predictor、Runtime、Protocolを確認します。 モデル名をクリックしてください。
本番環境で提供されるモデルの詳細を表示するダッシュボードが表示されます。
(1) エラーをデバッグするためのメトリクスやログでモデルを本番環境で監視できます。また、
(2) 「外部URL」と 
(3) 「内部URL」という、他のサービスリクエストやクライアントからモデルにアクセスできるエンドポイントが表示されます。 「外部URL」はカスタムURLにリダイレクトできます。

今のところ、ターミナルを介して「内部URL」エンドポイントを使用してモデルにアクセスします。エンドポイントをコピーしてJupyterlabターミナルに戻り、次のコマンドで変数にエンドポイントを保存します：
$ export MODEL_DEPLOYMENT_URL=<ここに内部URLエンドポイントを入力してください>

$ curl --header "Content-Type: application/json; format=pandas-records"   --request POST   --data  '{"instances": [[3, 0, 4, 1, 2 ,3, 0, 1, 0, 8, 3, 6, 2]]}'  $MODEL_DEPLOYMENT_URL

パイプラインのノートブックからの応答と同じ応答が得られるはずです：

おめでとうございます！Kubeflowを使用してエンドツーエンドのパイプラインを構築しました。
MLパイプラインに関連する課題
MLパイプラインを使用する際に遭遇する可能性のあるいくつかの課題は次のとおりです：



1

                インフラストラクチャとスケーリングの要件。            

2

                複雑なワークフロー間の依存関係。            

3

                ワークフローのスケジューリングはジレンマです。            

4

                パイプラインの再現性。            

5

                実験の追跡。            

インフラストラクチャとスケーリングの要件
優れたインフラストラクチャ上で実行するべき機械学習パイプラインのメリットは、エクセレントなインフラストラクチャを持つことです。Uber、Airbnbなどの企業は、インフラストラクチャをホストし、それを社内で構築する予算を持っています。これは、主にクラウドインフラストラクチャに頼る小規模な企業やスタートアップにとっては現実的ではありません。
データ、トレーニング、およびプロダクションパイプラインを実行するためのクラウドインフラストラクチャを使用すると、適切に監視しないと指数関数的なコストと請求書につながる可能性があります。また、異なるワークフローコンポーネントが大幅に異なるインフラストラクチャのニーズを要求する場合もあります。
機械学習パイプラインは、効率的かつスケーラブルに実験を実行できるようにするものですが、リソースと予算に制約がある場合、この目的が妨げられる可能性があります。
複雑なワークフロー間の依存関係
パイプラインワークフローの実装は、パイプラインステップの複雑な相互依存関係により複雑になる場合があります。これらの依存関係は成長し、管理が困難になることがあります。
複雑なワークフロー間の依存関係のスケーリングも問題となる場合があります。たとえば、モデルのトレーニングはデータ変換よりも多くの計算リソースを使用する場合があります。
ワークフローのスケジューリングのジレンマ
機械学習パイプラインのワークフローをスケジュールし、エラーや予期しない状況に対して耐性を持たせることは非常に難しいことです。ワークフロースケジューラを使用する場合、ジョブが失敗した場合にオーケストレータが取るべきすべてのアクションを指定することは難しい場合があります。
パイプラインの再現性
複数の相互接続されたステージで数十から数百のパイプラインをスケールで実行すると、さまざまなデータ変換、アルゴリズムパラメータ、およびソフトウェアの依存関係が関与することで、パイプラインの再現性に影響を与える可能性があります。

        しばしば忘れられがちですが、モデルを生成するために使用されるインフラストラクチャ、コード、および設定は正しくバージョン管理されておらず、再現可能な状態にありません。
— Ketan Umare、Union.aiの共同創設者兼CEO、MLOps.community 2022でのAMAセッションにて。

他の場合では、特定のハードウェア構成でパイプラインを構築し、オペレーティングシステムおよび異なるライブラリの依存関係で実行する場合、これらの環境の違いが機械学習パイプラインの再現性に影響を与える可能性があります。
MLパイプラインのベストプラクティス
コミュニティの会話を見たり、BrainlyやHypefactorsなどの企業のエンジニアと話したり、Netflix、Lyft、Spotifyなどからのトップな学びをまとめたりすることで、MLパイプラインのベストプラクティスのいくつかを学びましょう。
機械学習パイプラインを追跡する

        私たちは、ユーザが気づかないように、起動するパイプラインごとに自動的に実験トラッカーを添付しています。私たちにとって、これにより最低限のパラメータが追跡されることが保証されます…原則として、私たちはパイプラインと一緒に実験トラッキングツールを使用することをお勧めします。これによって再現性が確保されます。
— Simon Stiebellehner、TMNLのMLOpsリードエンジニアおよびMLEクラフトリード、「Differences Between Shipping Classic Software and Operating ML Models」MLOps LIVE.

パイプラインの再現性とデバッグ可能性を高めるために、以下のようなプラクティスを探索することが重要です：

バージョン管理 – コード、データ、設定、ライブラリの依存関係、パイプラインのメタデータ、アーティファクトなどの依存関係を管理し、パイプラインのバージョンを簡単に追跡および比較するためのバージョン管理を行います。
システムガバナンスの実装 – パイプラインのステップに応じて、パイプラインの実行のメタデータやMLアーティファクトの系統を分析して、システムガバナンスの質問に答えることができます。たとえば、特定の時間にどのバージョンのモデルが本番環境で使用されていたかをメタデータから判断することができます。
neptune.aiやMLflowなどの専用のツールとフレームワークの使用 – パイプラインのトラッキングと管理をサポートする専用のツールやフレームワークを使用することで、包括的なトラッキングとモニタリング機能を提供することができます。

トラッキングツールを使用することで、以下のことが可能になります：

実験結果のログ記録
パイプラインコンポーネントの可視化
チームメンバー間の協力を容易にするためのステップの詳細のドキュメント作成
実行中のパイプラインのパフォーマンスをモニタリングし、パイプラインの進化を追跡することが容易になる
パイプラインの進行状況の管理

ReSpo.Visionは、MLを使用したスポーツデータ分析において、単視点カメラのスポーツ放送ビデオから3Dデータを抽出しています。このプロセスでは多くのkedroパイプラインを実行しています。
ReSpo.VisionのCTOであるWojtek Rosińskiは、「kedroとNeptuneを一緒に使用すると、複数のマシンで同時に実行されるパイプラインの進捗状況を簡単に追跡することができます。多くのパイプラインを同時に実行するため、それぞれを快適に追跡することはほぼ不可能です。Neptuneを使用すると、異なるパラメータを使用して複数のパイプラインを簡単に実行し、UIを介して結果を比較することもできます。」と述べています。
以下に、NeptuneのUIでの表示例を示します。

Neptuneは、KedroやZenMLなどのツールとネイティブに統合されています。ただし、組み込みの統合がなくても、使用している他のパイプラインツールで使用することができます。

neptune.aiの始め方を確認する
ReSpo.Visionが実験とパイプラインの追跡を行っている方法について詳しく読む

パイプラインのコンポーネントを小さな関数にまとめる
パイプラインの再利用可能なコンポーネント（小さな関数として定義される）を使用して、パイプライニングツールとSDKを使用してパイプラインを構築します。ZenMLのパイプラインワークフローに従う例を以下に示します：
import numpy as np
from sklearn.base import ClassifierMixin
from sklearn.svm import SVC

from zenml.steps import step


@step
def svc_trainer(
    X_train: np.ndarray,
    y_train: np.ndarray,
) -> ClassifierMixin:
    """sklearnのSVC分類器を訓練します。"""
    model = SVC(gamma=0.001)
    model.fit(X_train, y_train)
    return model


このようにすることで、カスタムのワークフローや事前に構築されたコンポーネントを使用してワークフローを実装できます。これにより、新しいパイプラインの構築が容易になり、既存のパイプラインのデバッグや他の組織のテクノロジーサービスとの統合も容易になります。

        モジュールレベルでの読み込みは行わないでください。これは通常、問題が発生することがあります。モジュールの読み込みに時間がかかり、失敗することは避けたいです。
— Ketan Umare, Union.aiの共同創設者兼CEO、MLOps.community 2022におけるAMAセッションにて。

下の例は、Prefectオーケストレーションツールを使用して関数として定義されたステップの別の例です：
@task
def split_data(data: pd.DataFrame):
    # データセットをランダムに70％のトレーニングデータと30％のテストデータに分割します。
    X = data.drop("rented_bikes", axis=1)
    y = data.rented_bikes
    X_train, X_test, y_train, y_test = train_test_split(
        X, y, train_size=0.7, test_size=0.3, random_state=42
    )
    return X_train, X_test, y_train, y_test

@task
def train_model(X_train: pd.DataFrame, y_train: pd.DataFrame):
    # モデルインスタンスを作成します：GBRT（勾配ブースティング回帰木）
    model = GradientBoostingRegressor()
    # モデルのトレーニング
    model.fit(X_train, y_train)
    return model


パイプラインのテストを記述する
別のベストプラクティスは、パイプラインのすべての側面をカバーするテストスイートを作成し、コンポーネントからパイプラインの実行までをテストすることです。可能な限り（およびユースケースによる）、これらのテストを自動化する意思を持つことも重要です。

        LyftLearn Servingに適用できる一意のテストファミリーであるモデル自己テストを使用して、モデルが基礎となるトレーニングまたはサービングコンテナイメージの連続した変更中でも期待どおりに機能し続けることを保証しています。
— LyftのProduct ManagerであるMihir Mathur、「Powering Millions of Real-Time Decisions with LyftLearn Serving」ブログ記事（2023年）より。

パイプラインのコンポーネントを小さな関数にまとめることで、テストが容易になります。Lyftのモデル自己テストの例を示します。モデルの入力と期待される出力の一部のサンプルを`test_data`という関数で指定しています：
class SampleNeuralNetworkModel(TrainableModel):

    @property

    def test_data(self) -> pd.DataFrame:

        return pd.DataFrame(

            [

                # 入力 `[1, 0, 0]` は出力 `[1]` に近い値を生成するはずです

                [[1, 0, 0], 1],

                [[1, 1, 0], 1],

            ],

            columns=["input", "score"],

        )

ローカルでテストを書いてください。ほとんどの場合、スタックやセットアップがローカルテストを不可能にする場合、ユーザーはおそらく本番でテストを行うことになるでしょう。ステップをコンテナ化することで、本番に展開する前にパイプラインをローカルまたは別の環境でテストすることが容易になります。
どのようなパイプラインテストを書くべきですか？ Eugene Yanは、効果的なパイプラインテストのスコープマップを含む記事で、ユニットテスト、統合テスト、機能テスト、エンドツーエンドテストなどを挙げています。詳細な記事をご覧ください。
結論
エンドツーエンドの機械学習パイプラインの構築は、現代の機械学習エンジニアにとって重要なスキルです。徹底的なテストと検証、モニタリングとトラッキング、自動化とスケジューリングなどのベストプラクティスに従うことで、パイプラインの信頼性と効率性を確保できます。
各パイプラインステージのコンポーネント、構造、および課題についての堅固な理解を持つことで、MLワークフローを効率化する堅牢でスケーラブルなパイプラインを構築できます。
パイプライニングを楽しんでください！

参考文献

Kubeflow Pipelines入門 – YouTube
Kedroを使ったデータサイエンスパイプラインの構築と管理 – neptune.ai
MetaflowがNetflixの愛されるデータサイエンスフレームワークになった経緯・Julie Amundson
https://mlops-community.slack.com/archives/C02NLLRUVN3/p1660842600835749
Flyte: MLOpsを簡単にする – MLOps Community
https://mlops-community.slack.com/archives/C02NLLRUVN3/p1660844981495249


                  
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
                  

                    MLOps                  

                  

                  

                    

                      Share:















                    
                  
                  

                  

                    
                      
                    
                    
                      
                    
                  
                  
                        

        

          
Was this article helpful?
        

        

          
             Yes, thanks!
          
          
             Not, really
          
        

        
93 out of 132 found this helpful
      
                  
Related articles
        

        MLモデルの最適化とデバッグにSHAP値を使用する方法

        高度なグラフニューラルネットワークを使用した交通予測

        世界的な障壁を取り払ってアクセスを可能にする

        私たちの人種的正義の取り組みについての最新情報

        ロボット用の物理シミュレータを公開する

        AGIの現実世界の課題

        DeepMind ポッドキャストがシーズン2で復活します
                  

                    

                      
                      
Pythonでトレーニング済みモデルを保存する方法
                    
                    

                    

                      
                        
                      
                      
CVモデルの構築と展開：コンピュータビジョンエンジニアからの教訓