By アーロン・ソリンジャー & ウィル・クンツ

プロジェクトのMLOpsスタックを設計するときは、実験の指示に従って高度なカスタマイズと柔軟性を進化させることができるソリューションが必要でした。 多くの機能を含む大規模なプラットフォームを検討しましたが、いくつかの重要な領域で制限があることがわかりました。 最終的に、ラベリング、データバージョン管理、継続的インテグレーションのために個別の専用ツールを実装するアプローチを決定しました。 この記事では、このカスタムMLOpsアプローチを構築した経験について説明します。

による写真 ダンを見つける| ダン・グリンウィス on Unsplash

NBDEV

（から取られた https://github.com/fastai/nbdev)

開発にJupyterを使用する古典的な問題は、プロトタイプから本番環境に移行するために、ノートブックからPythonモジュールにコードをコピー/貼り付けする必要があったことでした。 NBDEVは、ノートブックとモジュール間の移行を自動化するため、Jupyterノートブックを本番パイプラインの公式部分にすることができます。 NBDEVを使用すると、開発者は、ノートブックが作成するモジュール、モジュールにプッシュするノートブックセル、およびテストするノートブックセルを指定できます。 NBDEVの重要な機能は、ノートブック内でのテストへのアプローチであり、NBDEVテンプレートは、CI / CDフレームワークでテストを実装するための基本的なGithubアクションも提供します。 結果のPythonモジュールは、開発者による編集を必要とせず、組み込みのPythonインポート機能を使用して、他のノートブックまたはプロジェクト全体に簡単に統合できます。

Iterative.ai：DVC / CML

（から取られた https://iterative.ai/)

機械学習パイプラインで使用されるファイルは、多くの場合、バイナリ/圧縮ファイルの大規模なアーカイブであり、gitなどの既存のバージョン管理ソリューションではアクセスできないか、法外な費用がかかります。 DVCは、大きなデータセットをファイルの内容のハッシュとして表すことでデータのバージョン管理を解決します。これにより、DVCは変更を追跡できます。 gitと同様に機能します（例： dvc add, dvc push）。 あなたが走るとき dvc add データセットでは、データセットに追加されます .gitignore によって変更が追跡されます dvc。 CMLは、Github ActionsワークフローのモデルアーティファクトをGithubの問題、プルリクエストなどに添付されたコメントに公開する機能を提供するプロジェクトです。これは、トレーニングデータの変更とその結果を考慮したプルリクエストのギャップを埋めるのに役立つため、重要です。モデルの精度と有効性。

Githubアクション

（から取られた https://github.com/features/actions)

自動テストパイプラインでモデルを構築するなど、自動コードテストが必要です。 Github Actionsは、コードのプッシュ、コミット、プルリクエストなどのテストを自動化するCircleCI、Travis、Jenkinsと競合しています。リポジトリのホストにはすでにGithubを使用しているため、Actionsを使用して別のサードパーティアプリを回避します。 このプロジェクトでは、Githubセルフホストランナーを使用して、オンプレミスGPUクラスターでジョブを実行する必要があります。

レーベルスタジオ

（から取られた https://labelstud.io/)

LabelStudioの使用方法を詳しく調べました。 ここ。 Label Studioは、データにラベルを付けるためのソリューションです。 それはうまく機能し、さまざまな環境で実行するための柔軟性があります。

なぜそれらを一緒に使用するのですか？

 
 
セットアップは、モデルをより速く展開するように設計されています。 つまり、より多くのデータサイエンティストが並行して調和して作業し、リポジトリの透明性を高め、新しい人々のオンボーディング時間を短縮します。 目標は、データサイエンティストがプロジェクトで実行する必要のあるアクティビティの種類を標準化し、明確な指示を提供することです。

以下は、このシステム設計で合理化したいタスクのリストです。

1. Label Studioからの取り込みを自動化し、それをモデルのトレーニングおよび評価アクティビティに取り込むための単一のポイントを提供します。
2. データパイプラインコードの自動テスト。つまり、プロセスで使用されるコンテナーの単体テストと再デプロイです。
3. モデルコードの自動テスト、つまり、プロセスで使用されるコンテナーの単体テストと再デプロイ。
4. 自動テストを有効にして、モデルの再トレーニングと評価基準を含めます。 モデルコードが変更されたら、新しいコードでモデルをトレーニングし、既存の既存モデルと比較します。
5. トレーニングデータが変更されたときにモデルの再トレーニングをトリガーします。

以下は、各タスクのパイプラインの説明です。

従来のCI / CDパイプライン

 
 
このパイプラインは、構文、ユニット、回帰、統合テストの評価を含む、プルリクエストごとの自動テストフィードバックを実装します。 このプロセスの結果は、機能的にテストされたDockerイメージをプライベートリポジトリに送信します。 このプロセスにより、最新の最良のコードが、ダウンストリームタスク用にリポジトリで利用可能な完全にテストされたイメージに含まれる可能性が最大になります。 新機能のコンテキストで開発者のライフサイクルがどのように機能するかを次に示します。

ここでは、コードの編集中にワークフローがどのように機能するかを示します。 NBDEVを使用すると、ノートブックに直接テストを書き込むなど、Jupyterノートブックから直接作業できます。 NBDEVでは、ノートブック内のすべてのセルが例外なく実行される必要があります（セルに実行しないようにフラグが付けられている場合を除く）。 （著者による画像）

データパイプライン

 
 
Label Studioには現在、保存されているラベルデータの変更時に更新を可能にするイベントフックがありません。 だから私たちは cron トリガーされたアプローチ、XNUMX時間ごとにデータセットを更新します。 さらに、ラベルスタジオのトレーニングデータセットは十分に小さいですが、更新はトレーニングパイプラインの一部として行うこともできます。 Github Actionsインターフェースを使用して、オンデマンドでデータパイプラインの更新をトリガーする機能があります。

データパイプラインはLabelStudioからフィードされ、データセットのすべてのバージョンと関連する入力をAWSS3に保存されているDVCキャッシュに保持します。 （著者による画像）

モデルパイプライン

 
 
モデリングパイプラインは、モデルトレーニングをリポジトリのCI / CDパイプラインに統合します。 これにより、各プルリクエストで、コードベースで構成された構文、ユニット、統合、および回帰テストを評価できますが、結果として得られる新しいモデルの評価を含むフィードバックを提供することもできます。

この場合のワークフローでは、構成ファイル（model_params.yaml）で指定されたモデルトレーニング実験を実行し、モデルアーティファクト（best-model.pth）を更新します（作成者による画像）

ベンチマーク評価パイプライン

 
 
ベンチマークパイプラインは、すべてのモデリングアクティビティがプロジェクトのメトリックに対して測定されることを保証するために、「公式提出」プロセスを形成します。

best-model.pthで新しくトレーニングされたモデルは、ベンチマークデータセットに対して評価され、結果は最新のコミットハッシュでタグ付けされ、AWSS3で永続化されます。 （著者による画像）

ワークフロー

 
 
これは、DVCによって使用されるDAG定義ファイルです。 ワークフローのステップとその入力をキャプチャし、ユーザーとマシン間での再現性を可能にします。

stages: labelstudio_export_trad: cmd: python pipelines/1_labelstudio_export.py --config_fp pipelines/traditional_pipeline.yaml --ls_token *** --proj_root "." params: - pipelines/traditional_pipeline.yaml: - src.host - src.out_fp - src.proj_id dataset_create_trad: cmd: python pipelines/2_labelstudio_todataset.py --config_fp pipelines/create_traditional.yaml --proj_root "." deps: - data/raw_labels/traditional.json params: - pipelines/create_traditional.yaml: - dataset.bmdata_fp - dataset.labels_map - dataset.out_fp - dataset.rawdata_dir train_model_trad: cmd: python pipelines/3_train_model.py --config_fp pipelines/model_params.yaml --proj_root "." deps: - data/traditional_labeling params: - pipelines/model_params.yaml: - dataloader.bs - dataloader.size - dataloader.train_fp - dataloader.valid_fp - learner.backbone - learner.data_dir - learner.in_checkpoint - learner.metrics - learner.n_out - learner.wandb_project_name - train.cycles labelstudio_export_bench: cmd: python pipelines/1_labelstudio_export.py --config_fp pipelines/benchmark_pipeline.yaml --ls_token *** --proj_root "." params: - pipelines/benchmark_pipeline.yaml: - src.host - src.out_fp - src.proj_id dataset_create_bench: cmd: python pipelines/2_labelstudio_todataset.py --config_fp pipelines/create_benchmark.yaml --proj_root "." deps: - data/raw_labels/benchmark.json params: - pipelines/create_benchmark.yaml: - dataset.bmdata_fp - dataset.labels_map - dataset.out_fp - dataset.rawdata_dir eval_model_trad: cmd: python pipelines/4_eval_model.py --config_fp pipelines/bench_eval.yaml --proj_root "." deps: - data/models/best-model.pth params: - pipelines/bench_eval.yaml: - eval.bench_fp - eval.label_config - eval.metrics_fp - eval.model_conf - eval.overlay_dir

所見

1. GithubActionsワークフロー cron トリガーは非常に信頼性が高くありません。 タイミングを保証するものではありません。
2. DVCは、プッシュ時にトリガーされるGithubActionワークフロー内では明確に機能しません。 ソース制御されているトラッカーを変更し、それがコミットされると、別のGithubアクションを作成します。
3. モデルを実行するメカニズムとしてのGithubActionsオーケストレーションでは、GPUを使用するためにセルフホストランナーが必要です。 これは、クラウドまたはオンプレミスのGPUインスタンスに接続することを意味し、アクセス制御に問題があります。 たとえば、自己ホスト型のランナー構成をリポジトリから削除せずに正確なリポジトリをオープンソースにすることはできません。そうしないと、ランダムなユーザーがコードをプロジェクトにプッシュすることでトレーニングサーバーでワークロードを実行できます。
4. NBDEVの組み込みワークフローは、間違った場所でコードをテストしています。 コンパイルされたパッケージの代わりにノートブックをテストしています。 一方で、「テストはノートブックに直接書き込むことができる」と言えるのは素晴らしいことです。 一方、ノートブックを直接テストすると、ノートブックが実行されていても、NBDEVによって作成されたコードパッケージが失敗する可能性があります。 必要なのは、NBDEVでコンパイルされたパッケージを直接テストする機能です。
5. NBDEVは一方通行であるという意味で、「従来の」Python開発と相互運用しません。 これにより、プロジェクトをインタラクティブなJupyterノートブックスタイルで開発できるようになります。 Pythonモジュールを直接開発することは不可能です。 いずれかの時点で、プロジェクトを「従来の」Python開発テストに変換したい場合は、別の方法で実行する必要があります。
6. 当初、実験追跡ダッシュボードとしてWeights＆Biasesを使用していましたが、GithubActionへのデプロイに問題がありました。 私たちが言えることは、実装するためのユーザーエクスペリエンスは wandb アクションワークフローで最初の問題が発生しました。 ウェイトとバイアスを削除すると、問題はすぐに解決しました。 それ以前は、 wandb MLOpsで最高のユーザーエクスペリエンスとして際立っていました。

結論

 
 
最終的に、Github Actions、Iterative.aiツール（DVCおよびCML）、およびNBDEVを使用してコードを管理するためのこれらのツールの実装を完了するのにXNUMX週間かかりました。 これにより、次の機能が提供されます。

1. コードの記録システムとして、Jupyterノートブックから作業します。 Jupyterが好きです。 それが達成する主な使用例は、そこでJupyterサーバーをホストし、それをデスクトップに転送することによって、SSHで接続できる任意のハードウェアで直接作業できるようにすることです。 明確にするために、NBDevを使用していなくても、これを実行します。これは、代替手段がVimまたはあまり好きではないツールを使用しているためです。 VSCodeまたはPycharmを使用してリモートサーバーに接続するための過去の実験は失敗しました。 つまり、Jupyterです。
2. コードをテストし、コードが作成するモデルをテストします。 これで、CI / CDパイプラインの一部として、リポジトリへの変更の結果として生じたモデルがモデルを改善するか、悪化させるか、または同じままにするかどうかを評価できます。 これは、にマージされる前にプルリクエストですべて利用できます main.
3. トレーニング実行のオーケストレーターとしてGithubActionsサーバーを使用すると、複数のデータサイエンティストがより明確な方法で同時に作業できるようになります。 今後、コラボレーティブデータサイエンスプロセスを調整するためのこのセットアップの制限がわかります。

 
アーロン・ソリンジャー 以前は、データサイエンティストおよびソフトウェアエンジニアとして、財務、予知保全、スポーツの問題を解決してきました。 彼は現在、マルチカメラコンピュータービジョンアプリケーションに取り組んでいるHoplabsで機械学習システムコンサルタントとして働いています。

ウィル・クンツ はバックエンドソフトウェア開発者であり、やりがいのある態度と頑固な決意を課題にもたらします。 とらえどころのないバグを追跡しているのか、新しいテクノロジーにすばやく適応しているのかは関係ありません。 解決策があれば、ウィルはそれを見つけたいと思っています。

元の。 許可を得て転載。

関連する

• MLOpsのベストプラクティス
• MLOpsはエンジニアリング分野です：初心者向けの概要
• MLOpsと機械学習のロードマップ