True ML Talks #2 - 機械学習ワークフロー @ Stitch Fix

True ML Talksの初回エピソードには、大変励みになる反響をいただきました。このシリーズでは、いくつかの主要なML企業のMLパイプラインを深く掘り下げていきますが、今回のエピソードでは、 ステファン・クラフチク。

ステファンは、データサイエンスチームがモデルパイプラインを構築・保守するための共同オープンソースプラットフォームであるDAGWorksを構築しており、既存のMLOpsおよびデータインフラストラクチャに接続します（彼らの YCローンチ）彼はNextdoor、LinkedIn、Stitch Fixなどの企業でデータおよび機械学習の分野で15年以上の経験があります。以前はStitch Fixでモデルライフサイクルチームを率い、社内MLOps機械学習プラットフォーム向けのセルフサービスツール構築において豊富な経験を積みました。また、彼は定期的にカンファレンスで講演し、人気のオープンソースフレームワークであるHamiltonの著者でもあります。

📌

ステファンとの対談は、以下の4つの主要なテーマを中心に展開されます。
1. ビジネスにおける機械学習のユースケース。
2. Stitch Fixのチームがビジネス成果を最適化するためにどのように構成されているか。
3. MLスタックの構築において直面する課題、特に業界特有の課題。
4. MLインフラストラクチャの構築とスケーリングのプロセスで適用された最先端のイノベーションの概要。

全エピソードはこちらからご覧ください。

Stitch FixにおけるMLユースケース：オンラインパーソナルスタイリングサービス

1. レコメンデーションシステム → 予測とシミュレーションのためのモデルで、サイズと割り当て範囲の内訳を提供します。
2. 予測とシミュレーション → バイヤーが仕入れる服の量を決める際、どのサイズをどれくらいの顧客層に提供するかを決定する必要があります。これは、社内でシミュレーションや予測を行うために使用される、一連の予測プロセスを含みます。Stitch Fixのアルゴリズムチームは、この目的のためにモデルを構築し、サイズと割り当て範囲の内訳を提供しています。詳細はこちらをご覧ください。 こちら
3. 社内基幹業務システム → Stitch Fixは、アルゴリズムを用いて独自の社内ERPシステムを構築しました。このシステムは、在庫管理、倉庫業務、および配送料の最適化に役立っています。詳細はこちらをご覧ください。 こちら.
4. 倉庫内の経路最適化 → Stitch Fixには、倉庫内の経路を最適化し、最短経路で注文品をピッキングできるようにするチームがあります。この最適化により、注文のコストと処理時間を最小限に抑えることができます。
5. 倉庫ロジスティクス → Stitch Fixのアルゴリズムチームは、注文を満たすためにビンから服をピッキングするプロセスを最適化することにも取り組んでいます。このプロセスを迅速化することで、Stitch Fixはコストを削減し、注文処理時間を最小限に抑えることができます。

Stitch FixにおけるMLシステムワークフロー

Stitch Fixでは、機械学習（ML）システムにデータサイエンスチームとプラットフォームチームの2つのチームが取り組んでいます。

• データサイエンスチーム：データサイエンスチームは、ビジネスのさまざまな部門を支援するバーティカルに組織されており、ビジネス内の他のチームが意思決定を行うのに役立つモデルを構築する任務を負っています。
• プラットフォームチーム： プラットフォームチームは、データサイエンティストが作業を完了するために多くのエンジニアリングを行う必要がないように、抽象化とツールを構築しています。チームは、Spark、Hadoop、Kafka、インフラストラクチャ、オーケストレーションシステム、環境など、いくつかのコンポーネントに分かれています。また、レコメンデーションスタックとマイクロサービスデプロイメント、A/Bテストと実験を担当するチームもあります。チームは、モデルのトレーニング、デプロイ、メンテナンスを容易にするなど、運用化の要素に焦点を当てています。

👉

データサイエンスチームは、モデルと結果の責任を負います。プラットフォームチームは、デプロイメントインフラストラクチャとそのコンポーネントの可用性を保証します。

データサイエンスチームとプラットフォームチームの間でモデルの「引き渡し」はありませんでした。これにより、モデルの反復回数を大幅に増やすことができます。

インフラストラクチャの割り当ての処理

インフラの割り当てはプラットフォームチームが担当しており、彼らが利用可能なリソースのクォータを管理していました。データサイエンティストはUI上でノードや他のSparkクラスターをリクエストでき、コストが不当に膨れ上がらないよう、ある程度の会計処理が行われます。プラットフォームチームは、人々が手間をかけずに簡単に必要なものを手に入れられるように努め、クォータを管理し、コストを抑制するチームも存在しました。

Stitch Fixにおける機械学習とMLOpsの特有の課題

1. Stitch Fixでは、100人以上のデータサイエンティストがモデル開発に取り組んでいます。各データサイエンティストが平均2年以上の寿命を持つモデルを所有しているため、多くのチームが多数のモデルを構築しており、チームがモデルの所有権を持つことを可能にすることは大きな課題でした。使用されるライブラリやフレームワークの多様性から、Stitch Fixのプラットフォームチームは多くのソリューションを自社開発し、購入したものはごくわずかです。 標準化によって、いくつかのプラットフォームはより容易になったでしょうしかし、異なるチームはそれぞれ異なる問題と、それらの問題により適したライブラリを抱えていました。Stitch Fixのプラットフォームチームは、彼らのニーズにうまく合致するオープンソースソリューションがなかったため、Model EnvelopeやHamiltonのような独自のソリューションを構築する必要がありました。
2. モデルの作成は簡単ですが、すべてのETLを誰かが保守しなければならず、担当者が会社を辞めると問題を引き起こす可能性があります。コードを捨てるのは無駄であり、新しいチームメンバーは、以前のものが何であったかを理解し把握するまで作業が遅れてしまいます。さらに、他のチームのモデルを特徴量として利用するためにその上に構築することが多いため、考慮すべきETL間の相互依存関係も存在します。

「私がStitch Fixに長く留まった理由の一つは、まさにこれらの課題と、それらをどう解決するかを考えることでした。」 - ステファン

Stitch Fix MLプラットフォームにおけるイノベーション

1. モデルエンベロープ： Stitch Fixのプラットフォームチームは、データサイエンティストがモデルを他の必要なコンポーネントと一緒にパッケージ化し、簡単にデプロイできるシステムを構築しました。これは多くの要素を捉えるAPIベースのシステムであり、ボタン一つと追加設定で、データサイエンティストは1時間以内にモデルを本番環境にデプロイできます。このシステムはバッチジョブも可能にし、Spark上でモデルを分散実行することも容易にしました。
2. 設定駆動型ETL： Stitch Fixのプラットフォームチームは、YAMLとJinjaを使用して、データサイエンティストがモデル適合のためのSQLおよびPythonコードを含むETLプロセスを記述できるようにしました。その狙いは、オーケストレーションシステムを抽象化し、プラットフォームチームがDockerコンテナから異なるコンポーネントを入れ替えられるようにすることでした。これにより、コードベースの管理と保守が容易になりました。
3. Hamilton： Hamiltonは、データフローを記述するための宣言型マイクロフレームワークです。Stitch Fixのプラットフォームチームは、特に数千もの特徴量を簡単に扱える時系列予測における特徴量エンジニアリングを支援するためにこれを開発しました。Hamiltonは、SQLにおけるDBTと同様に、Python変換のための問題構造化を支援します。これにより、Pythonスクリプトを管理することなくデータフローを記述できます。関数がデータフローを宣言し、その定義はオフラインおよびオンラインのコンテキストで簡単に共有および実行できます。

👉

Dockerコンポーネントの入れ替えに関して、プラットフォームチームは、データサイエンティストがプラットフォームの依存関係を気にすることなく、実現したいことを記述できる「ゴールデンAPI」の作成を試みました。これは、データサイエンティストが変更のサブセットを含むテキストを提供できる、設定駆動型モデルパイプラインを通じて行われました。これにより、プラットフォームチームは、データサイエンティストチームにDockerコンテナの更新やアップグレードを要求することなく、変更を行うことができました。また、ユーザーがパイプラインを再デプロイしたり書き換えたりすることなく、ログやメタ情報をアップグレードすることも可能になりました。これにより、各チームが物事を管理・更新する必要がなくなり、データサイエンティストチームからの移行を要求することなく、プラットフォームチームがより効率的に物事を管理・更新できるようになりました。

リモート開発におけるDockerコンテナのビルド時間とデバッグ時間の改善：Stitch Fixで採用された戦略

1. コンテナ作成を高速化するためのキャッシング - Stitch Fixのプラットフォームチームは、頻繁に使用されるライブラリや環境をキャッシュすることで、Dockerコンテナの作成を高速化しようと試みました。例えば、同じ要件が再度必要になった場合に再インストールする必要がないように、キャッシングを追加しました。また、環境ファイルを保存し、圧縮してから再度プルすることで、プロセスを高速化しました。
2. コンテナのビルド時間とデバッグ時間を最小限に抑えるためのローカル開発 - Stitch Fixのプラットフォームチームは、開発者がローカルで開発するか、Dockerコンテナのビルド、実行、デバッグの全サイクルを待つことを避ける方法を見つけるよう奨励しました。彼らは、開発者向けにデータをキャッシュするために一部のデータをプルダウンするなど、他のユーザビリティ機能とともに、ETLの個々のステップでローカルループを実行できるようにしました。このアプローチは、開発およびデバッグプロセスを高速化するのに役立ちました。
3. コンテナのビルドとデバッグ時間を改善するための新しいアプローチの探求 - Stitch Fixのプラットフォームチームは、キャッシュとローカル開発によってビルドおよびデバッグ時間の改善を試みましたが、プロセスはさらに高速化できることを認識していました。一部の開発者は、特にモデル向けに、このプロセスを改善するためにDockerの変更に取り組んでいます。このアプローチには、Dockerを変更して再起動し、より良く効率的にすることが含まれます。

Stefan Krawczyk氏によるMLOpsツールに関する推奨事項

ビジネスへの影響とSLAに基づいてツールを選択することが重要です。シングルノードで実行できることは、オーケストレーションシステムで最適化されるべきです。データバージョニングとモデルレジストリについては、S3に構造化されたパス構造で保存し、メタデータを一緒に保存する方法が有効かもしれません。モデルレジストリに関しては、MLflowのようなオープンソースツールが役立つはずですが、 TrueFoundryのようなホスト型管理ソリューションもあります。

モデルがビジネスにもたらす価値を理解するために、スタックにA/Bテストシステムを導入することが重要です。これにより、モデルが与える影響に基づいて、MLOpsの実践にどこに投資すべきかについて意思決定を行うのに役立ちます。

MLOpsツールの推奨事項  

1. ライブラリとフレームワークの異質性を考慮する：使用されているライブラリとフレームワークに大きな異質性がある場合、既製のソリューションではニーズに合わない可能性があるため、社内ソリューションを構築する必要があるかもしれません。
2. 標準化により一部のプラットフォームが容易になる可能性：異なるチームが異なる問題を抱えている場合でも、特定のツールやプロセスを標準化することで、 MLOpsプラットフォームを 構築および保守しやすくなります。
3. ニーズに合うオープンソースソリューションがない場合、自社で構築する：ニーズにうまく合うオープンソースソリューションがない場合、MLOpsの目標を達成するためには、Model EnvelopeやHamiltonのような独自のソリューションを構築する必要があるかもしれません。

機械学習におけるETLに関する課題

機械学習において、抽出、変換、ロード（ETL）は、生データを価値ある洞察に変換するための重要なプロセスです。しかし、機械学習システムにおけるETLは、対処すべきいくつかの課題を提起します。

機械学習システムにおけるETLは、上流の変更により機能しなくなることがあり、データ実務者がモデルへの入力を追跡することを困難にし、ETLの保守を難しくします。ETLの複雑さも時間とともに増大し、チームが追いつくことを困難にしています。

DAGWorks：データサイエンスチーム向けのオープンソースETLプラットフォーム

前述の課題を解決するため、DAGWorksはデータサイエンスチーム向けのオープンソースETLプラットフォームを構築しており、これによりエンジニアリングへの依存を減らします。このオープンソースは、前述のHamiltonを中心に展開されています。Hamiltonは、ソフトウェアエンジニアリングのバックグラウンドを持たないデータ実務者が、本番環境で動作するコードを記述し、既存のインフラストラクチャ上で機械学習ETLアーティファクトを管理することを可能にします。Hamiltonはまた、中央の機能定義ストアとリネージを提供し、デバッグを容易にし、コンプライアンスケースにも使用できます。

Hamiltonは、AirflowやArgoなどの様々なオーケストレーションツールと連携できる抽象化レイヤーとして設計されています。Stefanは、データサイエンティストは物事がどこで実行されるかのトポロジーを気にする必要はなく、代わりにモデルの構築とイテレーションに集中すべきだと考えています。DAGWorksは、データ品質プロバイダーを書き直すことなく簡単に変更できる方法と抽象化を模索しています。

HamiltonはMetaflowのようなツールを補完するものであり、それらを置き換えようとしているわけではありません。むしろ、タスク内のミクロな部分をモデル化できるようにすることで、これらのシステム上で人々がより生産的になることを可能にします。全体として、DAGWorksはデータサイエンスチームが機械学習ETLアーティファクトを管理および保守しやすくすることを目指しています。

以下は、ステファンとそのチームによる興味深い記事をいくつかご紹介します。  

Stitch Fixでプラットフォームを構築して学んだこと

無料でのデプロイ - Stitch Fixのデータサイエンティストのための機械学習プラットフォーム

機能、コンテキスト、データ — Stitch FixにおけるML Opsの実現

シリーズの以前の投稿を読む

‍

True ML Talks #1 - Machine Learning Workflow @ Gong

Learn how Gong, a revenue intelligence platform, uses machine learning to analyze customer interactions and provide insights to revenue teams. Discover the challenges of managing ML workflows, data privacy, and data security.

TrueFoundry Blog TrueFoundry

‍

TrueMLの YouTubeシリーズを視聴し、 すべてのTrueML ブログシリーズを読み続けてください。

TrueFoundry は、Kubernetes上のMLデプロイメントPaaSであり、開発者のワークフローを高速化し、モデルのテストとデプロイにおいて完全な柔軟性を与えながら、インフラチームには完全なセキュリティと制御を保証します。私たちのプラットフォームを通じて、機械学習チームが デプロイおよび監視を モデルを15分で、100%の信頼性、スケーラビリティ、そして数秒でのロールバック機能をもって行えるようにします。これにより、コストを削減し、モデルをより迅速に本番環境にリリースできるようになり、真のビジネス価値の実現を可能にします。