欠陥が明らかにされる：MLOpsコース作成の興味深い現実

Interesting reality revealed Defects in MLOps course creation.

フルスタック7ステップのMLOpsフレームワーク

ボーナスレッスン：「不完全な」MLプロジェクトの裏側-レッスンと洞察

この記事は、MLOpsの良い実践を使用して、MLシステムを設計、実装、展開する方法をステップバイステップで説明する7つのレッスンのうちの最後のボーナスレッスンを表しています。コース中に、あなたはデンマークの複数の消費者タイプにわたる次の24時間のエネルギー消費レベルを予測するための本番用のモデルを構築しました。

コース中、あなたはバッチサービングアーキテクチャを使用して、MLシステムを設計、コーディング、デプロイするすべての基本を学びました。

このコースは、自分自身のMLエンドツーエンドプロジェクトを構築してスキルをレベルアップしたい中/上級のMLまたはソフトウェアエンジニアを対象としています。

現在、証明書はどこにでもあります。後で自慢できる高度なエンドツーエンドプロジェクトを構築することが、プロフェッショナルエンジニアとして認識される最良の方法です。

• RedPajamaプロジェクト：LLMの民主化を目指すオープンソースイニシアチブ
• Gorillaに会ってください：UCバークレーとMicrosoftのAPI拡張LLMは、GPT-4、Chat-GPT、およびClaudeを上回ります
• FLOPsとMACsを使用して、Deep Learningモデルの計算効率を計算する

目次：

• コース紹介
• コースレッスン
• データソース
• ボーナスレッスン：「不完全な」MLプロジェクトの裏側-レッスンと洞察
• 結論
• 参考文献

コース紹介

7つのレッスンを通じて、あなたは以下の方法を学びました：

• バッチサービングアーキテクチャの設計
• Hopsworksを機能ストアとして使用する
• APIからデータを読み取る機能エンジニアリングパイプラインの設計
• ハイパーパラメータ調整を備えたトレーニングパイプラインの構築
• W&BをMLプラットフォームとして使用して、実験、モデル、およびメタデータを追跡する
• バッチ予測パイプラインを実装する
• 自分のPythonパッケージを構築するためのPoetryの使用
• 独自のプライベートPyPiサーバーの展開
• Airflowですべてをオーケストレーションする
• FastAPIとStreamlitを使用してWebアプリケーションをコーディングするための予測値の使用
• コードをコンテナ化するためにDockerを使用する
• データ検証と整合性のためのGreat Expectationsの使用
• 時間の経過に応じた予測のパフォーマンスを監視する
• すべてをGCPに展開する
• GitHub Actionsを使用してCI/CDパイプラインを構築する

このシリーズに従っていない場合、興味があるものであれば、コースを完了した後、私が以前に言ったことをすべて理解することができます。最も重要なことは、これらのツールをなぜ使用したのか、そしてシステムとしてどのように機能するかを見ることができることです。

このコースから最大限の効果を得たい場合は、すべてのレッスンコードを含むGitHubリポジトリにアクセスすることをお勧めします。このコースは、記事の間にコードを素早く読み取り、複製するように設計されています。

コース中、以下のダイアグラムを実装する方法を学びました。ステップバイステップで説明した後、もう怖くないですね？

この最終的なボーナスレッスンでは、現在のアーキテクチャと設計の選択肢に加えて、改善できる可能性のある点について話し、コース中に行ったトレードオフを強調し、将来のプロジェクトのアイデアを提供します。

それを裏面セクションと考えてください👀

コースレッスン：

1. バッチサービング。機能ストア。機能エンジニアリングパイプライン。
2. トレーニングパイプライン。MLプラットフォーム。ハイパーパラメータ調整。
3. バッチ予測パイプライン。Poetryを使用したPythonモジュールのパッケージ化。
4. プライベートPyPiサーバー。Airflowですべてをオーケストレーションする。
5. GEを使用した品質と整合性のデータ検証。モデルパフォーマンスの継続的なモニタリング。
6. FastAPIとStreamlitを使用してモデルの予測を消費し、可視化する。すべてをDocker化する。
7. すべてのMLコンポーネントをGCPに展開する。GitHub Actionsを使用してCI/CDパイプラインを構築する。
8. [ボーナス]「不完全な」MLプロジェクトの裏側-レッスンと洞察

ボーナスレッスンでは、コースのトレードオフ、デザインの選択肢、およびポテンシャルの改善点を公開的に共有します。

したがって、本格的なMLシステムの構築に興味がある場合は、コースの残りを読むことを強くお勧めします👇

プロダクションレディな特徴量エンジニアリングパイプラインの構築フレームワーク

レッスン1：バッチサービング。特徴量ストア。特徴量エンジニアリングパイプライン。

towardsdatascience.com

データソース

私たちはデンマークのすべてのエネルギー消費者タイプの時間毎のエネルギー消費値を提供する無料かつオープンなAPIを使用しました[1]。

彼らは直感的なインターフェースを提供し、データを簡単にクエリして可視化できます。ここからデータにアクセスできます[1]。

データには4つの主要な属性があります:

• Hour UTC: データポイントが観測されたUTC日時。
• Price Area: デンマークは2つの価格帯に分かれています：大ベルトで分けられるDK1とDK2。DK1は大ベルトの西側にあり、DK2は大ベルトの東側にあります。
• Consumer Type: 消費者タイプはデンマークエネルギーが所有および維持する業界コードDE35です。
• Total Consumption: kWhでの総電力消費量

注意： 観測値には15日の遅れがあります。ただし、デモ用途では、リアルタイムで同じ手順をシミュレートできるため、問題ありません。

データポイントには時間ごとの解像度があります。たとえば「2023-04-15 21:00Z」、「2023-04-15 20:00Z」、「2023-04-15 19:00Z」などです。

私たちはデータを複数の時系列としてモデル化します。各ユニークな価格帯と消費者タイプタプルはそれぞれのユニークな時系列を表します。

したがって、すべての時系列の次の24時間のエネルギー消費量を独立して予測するモデルを構築します。

以下のビデオをチェックして、データがどのように見えるかをよりよく理解してください👇

コース＆データソースの概要 [著者によるビデオ]。

ボーナスレッスン：「不完全」なMLプロジェクトの舞台裏—レッスンと洞察

もう雑談は終わりにしましょう。直接舞台裏に飛びましょう🔥

全体のコード

#1. Duplicated code

異なるPythonモジュール間でかなりの重複したコードがあるため、DRY原則に反しています。

たとえば、MLパイプラインのsettings.pyやutils.pyファイル、UIのドロップダウン+ラインプロットコンポーネントなどがあります。

このコードは、他のすべてのモジュールで共有される共通モジュールにリファクタリングできます。

#2. Classes, not functions!

コードをクラスを使用してモデル化することは良い習慣ですが、私たちはコース中に関数のみを使用しました。

各パイプライン、FeaturesExtractor、Trainer、BatchPredictorなどの中央クラスを作成することができました。

また、実行のメタデータを含むプレーンな辞書を返す代わりに、RunResultクラスを作成して、データがどのように渡されるかをより細かく制御できるようにすることができました。

#3. テストがない 😟

どんなコードベースでも、コードに対して実行される変更を検証するためのユニットテストや統合テストがある方が良いです。

パイプラインの設計

#1. DAG に状態がある

DAG に状態があるため、並列で実行することは非常に簡単ではありません。問題となるのは、監視メトリックを計算するために前回の実行結果の予測が必要だからです。

したがって、定義上、同じ DAG の複数の並列インスタンスを異なる時点で実行することはできません。

いつ問題が発生するのでしょうか？

バックフィル時です。たとえば、直近2か月間の毎時バックフィルを行いたい場合、プログラムを順次実行すると永遠にかかります。

解決策としては、監視コンポーネントを別の DAG に移動することをお勧めします。

#2. リソースバージョンに “:latest” を使用しない

“:latest” タグを使用してリソースにアクセスする場合、例えば:

• モデルのアーティファクト、
• データ（Feature Store feature view またはトレーニングデータセット）、
• 最適な構成アーティファクトなど。

…あなたは ML パイプラインの複数の実行間に依存関係を導入します。

微妙な問題ですが、説明しましょう 👇

2つの ML パイプライン A & B を並列実行するとします。パイプライン A はまず新しいデータセットバージョンを生成します。その後、何らかの理由でパイプライン B がパイプライン A よりも先にトレーニングパイプラインを開始し、パイプライン A が生成した最新のデータセットバージョンにアクセスします。

これは並列計算における「競合状態」とも呼ばれます。

この場合、同じパイプラインのタスク間でリソースのバージョンをハードコーディングすることで簡単に解決できます。

たとえば、「 dataset:latest 」ではなく、「 dataset:v3 」にアクセスすることができます。

見ていただいたように、バックフィルを行う際にはスピードが重要です。そのため、長期的には DAG を並列実行することが不可欠です。

Airflow

#1. Docker タスクを使用する

これは必ずしも問題ではありませんが、Python 環境の代わりにコードを Docker コンテナに含めることができます — タスク Docker デコレーター ドキュメント [2]。

主な利点は、システムをよりスケーラブルにすることです。

しかし、コースで学んだプロセスは非常に似ています。Python パッケージを PyPi レジストリにプッシュする代わりに、Docker イメージを Docker レジストリにプッシュするだけです。

#2. 小さく、アトミックなタスク

私たちの場合、DAG 内のタスクには多くのロジックが含まれています。基本的にはアプリケーション全体を実行します。

これは必ずしも悪いことではありませんが、それをより小さなピースに分割することは良い習慣です。そのため、デバッグ、監視、失敗したポイントから DAG を再開することがより簡単になります。

たとえば、Python で GCS からデータを読み書きする代わりに、Airflow の GCS オペレーターのいずれかを使用することができます — GCS Airflow オペレーター [3]。

#3. Airflow からハイパーパラメータの調整設定を注入する

現在、ハイパーパラメータの調整設定は configs/gridsearch.py ファイルにハードコードされています。

これは非常に柔軟性がなく、構成を変更する唯一のオプションは git に新しいバージョンをプッシュすることです。

解決策としては、設定を YAML ファイルから注入することで、Airflow ワークフローに簡単に追加できるようにすることができます。

ML モデル用の素晴らしい YAML 構成ツールである Hydra by facebookresearch があります。ぜひ試してみてください。後で感謝することでしょう。

モニタリング

#1. システムの健全性を監視しない

API の /health エンドポイントを定期的に ping することにより、システムの健全性を監視するメカニズムを簡単に追加できました。

これは UI 上の緑色 / 赤色のパネルで反映できます。

#2. アラートがない

MAPE メトリックを常に監視することに基づいて、次のようなアラートシステムを追加できました:

• 警告 [threshold_B > MAPE > threshold_A]: エンジニアに何か問題があることを知らせます。
• アラーム [MAPE > threshold_B > threshold_A]: エンジニアに何かが間違っていることを知らせ、ハイパーパラメータ調整ロジックをトリガーします。

#3. UIの充実

各時系列にMAPEメトリックを追加することができました。

#4. 車輪の再発明をしないでください！

私たちは例としてミニモニタリングツールを実装しましたが、実際のシナリオでは、EvidentlyAIやArizeなどの既存のツールを活用する必要があります。

これらのツールおよびパッケージはすでにプロのソリューションを提供しているため、価値を追加することに集中できます。

#5. ドリフトのモニター

できれば、データと概念のドリフトを監視することも役立ちます。しかし、ほぼリアルタイムのGTがあるため、これは単なる余裕です。

Webアプリ-予測ダッシュボード

#1. UIの充実

UIは非常に基本的です。たとえば、データが無効である場合（検証スイートをパスしない場合）に、テキストとアラートを追加することでUIを充実させることができます。

#2. データを素朴な方法でリクエストしています

APIへの私たちのリクエストは非常に素朴です。通常、これらの手順は、300、400、および500の応答コードの異なる動作をキャッチする一連の例外によって保護されます。

#3. 設定がハードコードされています

設定を.envファイルを使用してインジェクションすることができます。これにより、プログラムをより構成可能にすることができます。WebアプリFastAPIコードと同様です。

デプロイおよびCI/CDパイプライン

#1. 部分的なCI実装

CI/CDパイプラインを完全に完了するためには、WebアプリDockerイメージをビルドし、それらをDockerレジストリにプッシュし、GCP VMにデプロイする際にそこからプルすることができるようにする必要があります。

Poetryを使用してPythonパッケージをビルドする場合も同様です。

これは本に書かれている通りです。

また、テストがある場合は、コードをデプロイする前に実行する必要があります。

別のアイデアは、コードがPEP8規則を使用して書かれていることを確認するためにflake8などのコマンドを実行することです。

#2. 別のVMでPyPiをホストする

また、PyPiサーバーをAirflowコンポーネントとは完全に独立して別のVMにホストすることが推奨されます。

これにより、システムはよりモジュール化され、柔軟になります。

#3. .envファイルをGCSバケットにホストする

.envファイルを手動で完了してコピーする代わりに、GCSバケットに保存し、CI/CDパイプライン内で自動的にダウンロードすることができます。

#4. インフラストラクチャを自動化する

手動で必要なGCPリソースをすべて設定するのはどれだけ退屈なことか…これは小さいインフラストラクチャです。インフラストラクチャの100または1000のコンポーネントがある場合、どうなるでしょうか。

そのため、TerraformなどのIoCツールを使用してインフラストラクチャの作成を自動化することが推奨されます。

結論

ここまで来てくれた方に感謝し、私のFull Stack 7-Steps MLOps Frameworkコースに従ってくれたことを深く感謝します🙏

このボーナスレッスンでは、完璧なシステムはなく、時間制約、リソース制約、悪い計画によって常にある程度のトレードオフをしなければならないことを見ました：

• 時間制約、
• リソース制約、
• 悪い計画。

誰もがまだ学習中であり、すべてを知っているわけではないことを見て、あなたは次の素晴らしいプロジェクトを構築するために言い訳をすることはありません🔥

LinkedInでつながり、このコースの後に構築した素晴らしいプロジェクトを共有していただければ幸いです。

GitHubリポジトリにアクセスするには、ここをクリックしてください。

💡私の目標は、機械学習エンジニアがMLシステムの設計とプロダクション化でレベルアップするのを支援することです。LinkedInでフォローするか、週刊ニュースレターに登録して、より深い洞察を得てください！

🔥このような記事を読んで楽しんでいただける場合は、VoAGIメンバーになることを検討してください。私の紹介リンクを使用すると、コストをかけずに私をサポートしながら、VoAGIの豊富なストーリーの無制限のアクセスを楽しむことができます。

私の紹介リンクでVoAGIに参加してください – Paul Iusztin

VoAGI会員として、読んだ作家に会費の一部が支払われ、すべてのストーリーに完全にアクセスできます…

pauliusztin.medium.com

ありがとうございます ✌🏼 !

参考文献

[1] Denmark APIからのDE35産業コードごとのエネルギー消費量、デンマークエネルギーデータサービス

[2] タスクDockerデコレータ、Airflowドキュメント

[3] GCS Airflowオペレータ、Airflowドキュメント

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