「Stitch FixにおけるMLプラットフォーム構築からの学び」

Lessons from ML Platform Building at Stitch Fix

この記事は元々MLプラットフォームポッドキャストのエピソードで、Piotr NiedźwiedźさんとAurimas GriciūnasさんがMLプラットフォームの専門家と共にデザインの選択肢、ベストプラクティス、実際の学びなどについて話し合うショーです。

このエピソードでは、Stitch FixでMLプラットフォームを構築する過程での学びをStefan Krawczykさんが共有しています。

YouTubeで視聴できます:

または、ポッドキャストとして聴くこともできます:

• 『私をすばやく中心に置いてください：主題拡散は、オープンドメインのパーソナライズされたテキストから画像生成を実現できるAIモデルです』
• 「マルチラベル分類：PythonのScikit-Learnを用いた入門」
• 「BeLFusionに出会ってください：潜在的拡散を用いた現実的かつ多様な確率的人間の動作予測のための行動的潜在空間アプローチ」

• Spotify
• Apple Podcasts

しかし、もしも書面で読むことを好む場合は、以下にあります！

このエピソードでは、以下のことについて学ぶことができます:

• 1
  Stitch FixにおけるMLプラットフォームが解決した問題
• 2
  モデルのシリアライズ
• 3
  モデルのパッケージング
• 4
  プラットフォームへのフィーチャーリクエストの管理
• 5
  Stitch FixにおけるエンドツーエンドのMLチームの構成

はじめに

Piotr: こんにちは、みなさん！Piotr NiedźwiedźとAurimas Griciūnasです。これからMLプラットフォームポッドキャストをお届けします。

今日は、非常にユニークで興味深いゲスト、Stefan Krawczykさんをお招きしました。Stefanさんはソフトウェアエンジニア、データサイエンティストであり、MLエンジニアとしての仕事をしてきました。以前の会社ではデータプラットフォームを担当し、オープンソースフレームワークであるHamiltonの共同作者でもあります。

最近知ったのですが、あなたはDAGWorksのCEOでもあるようですね。

Stefan: そうです。お招きいただきありがとうございます。話すのを楽しみにしています、Piotrさん、Aurimasさん。

DAGWorksとは何ですか？

Piotr: あなたのバックグラウンドは非常に興味深く、現在のベンチャーであるDAGWorksについてもう少し教えていただけますか？

Stefan: もちろんです。DAGWorksは、D-A-G（Directed Acyclic Graph）という言葉の略称です。私たちの考え方と問題解決の方法へのオマージュです。

私たちは、機械学習パイプラインのメンテナンスに関する人々の苦痛と苦しみを止めたいと考えています。

私たちは、ジュニアデータサイエンティストのチームがコードを書き、それを本番環境に持ち込み、メンテナンスできるようにすることを目指しています。そして、彼らが去った後でも、誰も彼らのコードを引き継ぐことに悪夢を見ないようにします。

大まかに言えば、私たちはチームがモデルパイプライン、ETL、またはワークフローをより簡単に本番環境に導入し、維持できるようにすることで、機械学習イニシアティブをより人的資本効率的にすることを目指しています。

DAGWorksは他の人気ソリューションとどこが違いますか？

Piotr: 大まかに言えば、高いレベルでの価値は素晴らしいですが、より詳しく掘り下げてみると、パイプライン周りで様々なことが起こっていますし、異なるタイプの苦痛もあります。

たとえば、AirflowやAWS SageMakerパイプラインなど、現在人気のあるものと比べて、DAGWorksのソリューションはどこに適していますか？

Stefan: 良い質問です。私たちはHamiltonの上に構築しています。Hamiltonはデータフローを記述するためのオープンソースフレームワークです。

具体的には、Hamiltonと私たちが最初に取り組んでいるのは、マイクロなモデリングの支援です。

たとえば、Airflowはマクロなオーケストレーションフレームワークです。大きなタスクやチャンクに分けることが一般的であり、そのタスク内のソフトウェアエンジニアリングは、機械学習が会社内で成長したり、新しいデータソースがあったり、新しいモデルを作成したりするときに、通常は更新や追加が必要です。

私たちが最初にターゲットにしているのは、その手続き型のPythonコードをHamiltonコードで置き換えるお手伝いです。詳細についてもう少し説明します。

アイデアは、Airflowなどのマクロタスク内のコードのソフトウェアエンジニアリングの側面でジュニアデータサイエンティストのチームがつまずかないようにすることです。

現在、Hamiltonは非常に軽量です。人々はAirflowタスク内でHamiltonを使用します。FastAPI、Flaskアプリ内のHamiltonの使用も可能ですし、ノートブック内でも使用できます。

ほぼPython関数向けのDBTと考えることができます。Pythonの書き方に非常に意見があるものです。高レベルでは、それは上位のレイヤーです。

そして、私たちはプラットフォームとオープンソースの機能を追い出して、Hamiltonのデータフロー定義を自動生成してAirflowタスクをサポートしようとしています。

初心者のデータサイエンティストにとっては、Airflow、Prefect、Dexterのいずれを使用しているかは重要ではありません。それは実装の詳細に過ぎません。使用するツールはモデルをより良くするのに役立ちません。パイプラインを実行するために使用する手段です。

2023年のMLOpsランドスケープ：トップツールとプラットフォーム

なぜDAG内にさらにDAGを持つのですか？

Piotr: これは手続き型のPythonコードですね。正しく理解しているかわかりませんが、DAG内にさらに別のDAGがあるのはなぜですか？

Stefan: モデルを反復的に改良していく際に、新しいフィーチャーを追加するからです。

新しいフィーチャーは大まかには新しい列に対応するものです。

単一のフィーチャーを計算するために新しいAirflowタスクを追加することはあまりありません。ただし、多くのメモリを必要とするような大規模なフィーチャーであれば別です。行うイテレーションはそれらのタスク内で行われます。

Hamiltonの背景について…

Hamiltonが作成されたStitch Fixでは、データサイエンティストはプロトタイプから製品へのエンドツーエンドの開発（つまり、プロトタイプから製品への移行、そして製品を引き受けること）に責任を持っていました。

チームは基本的には時系列予測を行っており、毎月または数週間ごとにビジネスの予測を作成するためにモデルを更新する必要がありました。

マクロなワークフローは変わりませんでしたが、タスクのステップ内の内容は変更されていました。

しかし、チームは非常に古いチームでした。多くのコードと、多くのレガシーコードがありました。フィーチャーの作成に関しては、彼らは数千のフィーチャーを作成していました。

Piotr: 数千のフィーチャーですか？

Stefan: ええ、時系列予測では毎月簡単にフィーチャーを追加できます。

たとえば、マーケティング費用があったり、何かをモデル化またはシミュレーションしたい場合、来月はマーケティング費用が発生する予定です。需要をどのようにシミュレートできるでしょうか。

彼らは常にコードを追加していましたが、問題はうまく設計されていなかったことです。新しいものを追加することは非常に遅く、何かが壊れないか心配していました。

各プルリクエストにシニアソフトウェアエンジニアを配置して、「デカップルしてください」「書き方に問題があります」と指摘する必要があるよりも、

私たちはHamiltonを考案しました。これは、すべてを関数として記述するパラダイムです。関数名が出力に正確に対応するようになっています。これは、フィーチャーが与えられたときに、それを正確に1つの関数にマッピングできるかどうかを示すものであり、関数名はその出力に対応し、引数の関数で計算に必要なものを宣言します。

コードを読むときには、出力と入力が非常に明確です。手続き型のコードでは一般的にスクリプト形式でドキュメントを貼り付ける場所がないため、関数のドキュメント文字列があります。

Piotr: ああ、行の上に置くことができますね。

Stefan: それは…テキストの壁を見つめることになります。

もののフローを理解するために、関数を読むだけで理解しやすくなります。

【Hamiltonを使用すると】あなたは圧倒されることはありません。ドックストリングがあり、ドキュメンテーションのための関数がありますが、デフォルトですべてのユニットテストが可能です。彼らはテストのストーリーを持っていませんでした。

Hamiltonと他のフレームワークの違いについては、関数の命名と入力引数の組み合わせによって依存関係のDAGまたはグラフが作成されます。

他のフレームワークでは-

Piotr： だから、Pythonの上で何か魔法を使っているんだね？それを理解するために。

Stefan： そうだよ！

Piotr： それで、それを使ってどうですか？IDEはサポートしていますか？

Stefan： IDEは？いいえ。より多くのプラグインを提供するためのロードマップはありますが、ステップに関数を注釈付けしてステップからワークフローを手動で指定する必要がある代わりに、すべてを名前の観点で省略します。

これは長くなりましたが、チームを遅くしたのはマイクロから始めたからです。

Hamiltonへの移行により、その月間タスクにおいて彼らは４倍効率的になりました。それは非常に規定された簡単な方法で何かを追加または更新するためのものだったからです。

それはまた、コードベースに追加する場所、レビューするもの、影響を理解する方法、そしてそれをプラットフォームの他の部分と統合する方法を明確で簡単にすることができます。

ツールが付加価値をもたらしているかどうかをどのように測定しますか？

Piotr： それは、私が時々聞く質問であり、特にMLプラットフォームチームやそのリーダーから聞くことがあります。彼らは自分たちの存在を正当化する必要があります。

MLデータプラットフォームチームを運営してきたあなたとしては、どのようにそれを行いますか？私たちが構築しているプラットフォーム、データサイエンスチームやデータチームに提供しているツールが価値をもたらしているかどうかをどのように知るのですか？

Stefan： はい、それは難しい質問で簡単な答えはありません。

データ駆動できれば、それが一番です。ただし、人々のスキルセットは異なります。したがって、誰かが何かをするのにかかる時間を測定するとすると、彼らがどれだけの経験を持っているか、どれだけ初心者かを考慮に入れる必要があります。

ただし、データポイントが十分にある場合は、おおよそ何かを言えます。以前はこれだけの時間がかかっていましたが、今はこれだけの時間がかかります。したがって、比率とそこで追加される価値を得ることができます。それから、そのことが何度起こるかを数える必要があります。それにより、人間の時間、したがって給与を測定し、これだけの節約をしたと言えます。それは効率を見るだけです。

機械学習プラットフォームが助ける別の方法は、プロダクションの問題を防ぐことです。停止のコストを見積もり、その後「ねえ、もし私たちがこれらの停止を防げたら、この種の価値も提供できる」と逆算することができます。

Piotr： わかりました。

Hamiltonの使用例はありますか？

Aurimas： 少し戻る一歩を踏み出しているかもしれませんが…

私にとっては、Hamiltonは主に特徴エンジニアリングに役立つツールです。これを正しく理解していますか？それとも他の使用例がありますか？

Stefan： はい、それがHamiltonの起源です。特徴エンジニアリングの問題を構造化するのに役立つ場合、HamiltonはPythonの場合に優れています。

ほとんどの人はpandasのコードが好きではありませんが、Hamiltonはそれを構造化するのに役立ちます。しかし、Hamiltonは任意のPythonオブジェクト型と一緒に使用できます。

現在のほとんどのマシンは十分に大きいため、Airflowはすぐに必要ないかもしれません。その場合、Hamiltonでエンドツーエンドの機械学習パイプラインをモデル化できます。

リポジトリにはエンドツーエンドで行えるいくつかの例があります。Hamiltonはスイスアーミーナイフのような存在です。Adobeのメンバーがプロンプトエンジニアリングの作業を管理するのに使用している例があります。

別の人は特徴エンジニアリングにより正確に使用していますが、Flaskアプリ内で使用しています。それ以外の人々は、Pythonタイプに関係なく、データフローをオーケストレートしてPythonオブジェクトを生成するのを助けるという点を活用しています。

非常に広範で、そのルーツは特徴エンジニアリングにありますが、非常に簡単に拡張して軽量なエンドツーエンドの機械学習モデルにも適用できます。これは、エコシステムに追加する拡張機能について興奮している点です。たとえば、誰かがネプチューンを手に入れて統合することを簡単にする方法はありますか？

Piotr: そして、ステファン、この部分は興味深かったです。予想していなかったので、再確認したいと思います。

このようなAirflowによって実行されるマクロレベルのパイプラインは必要ないと仮定し、1つのマシンで行うことに問題がないとします。

モデルのトレーニングなどのステップも含めますか、それともデータに関するものですか？

Stefan: いいえ、両方です。

Hamiltonの良いところは、データフローを論理的に表現できることです。ソース、特徴化、トレーニングセットの作成、モデルのトレーニング、予測などを行い、タスクの境界を明確に指定していません。

Hamiltonでは、すべてをエンドツーエンドで論理的に定義できます。実行時には、計算したい内容を指定するだけで、要求したDAGのサブセットのみを計算します。

Piotr: しかし、トレーニングのforループはどうですか？例えば、1000回の勾配降下法の反復など、内部ではどのように機能しますか？

Stefan: そこにはオプションがあります。

今のところ、人々はそれを関数の本体に含めるだけです – つまり、トレーニングステップを包括する1つの関数だけがあるということです。

Hamiltonでは、ジュニアの人々やシニアの人々が好むのは、Python関数内で行いたいことの完全な柔軟性を持っているためです。それはコードの構造を助ける意見を持つ方法です。

なぜHamiltonには特徴ストアがないのですか？

Aurimas: GitHubリポジトリのテーブルに戻ると、注目すべき興味深い点があります。何の比較も特徴ストアとして行っていないと述べています。

ただし、それについて少し深く考えました… 特徴ストアは特徴を保存するためのものですが、同時に特徴の定義も持っており、現代の特徴プラットフォームには特徴計算および定義レイヤーも含まれています、そうですよね？

場合によっては、特徴ストアは必要ありません。トレーニング時と推論時の両方で特徴を計算するだけで十分かもしれません。だから、なぜHamiltonがそれに対応できないのでしょうか？

Stefan: まさにその通りです。私はそれを特徴定義ストアと呼んでいます。それはStitch Fixのチームが構築したものです – Gitの裏側で動作しています。

Hamiltonは、関数が実行されるコンテキストから関数を分離することを強制します。関数をモジュールにまとめるように強制されます。

Hamiltonで何かを計算する方法を知っているコードのフィーチャーバンクを構築したい場合、それを強制されます – そして、そのようなフィーチャートランスフォームを異なるコンテキストで簡単に共有して再利用できます。

それは命名、スキーマ、および入力に合わせるように強制されます。特徴の入力に関しては、適切に名前を付ける必要があります。

データを保存する必要がない場合、Hamiltonを使用してすべてを再計算することができます。ただし、データをキャッシュするためにデータを保存する必要がある場合は、Hamiltonを使用してそれを処理し、FISTのようなものにプッシュすることができます。

Aurimas: Hamiltonではなく、DAGWorksのウェブサイトで、すでに言及されているように、関数内でもモデルのトレーニングもできることを見ました。つまり、Hamiltonの関数内でモデルをトレーニングします。

それでは、そのトレーニングしたモデルをどのように保存した場所から抽出し、関数としても提供することは可能なのでしょうか、それとも不可能なのでしょうか？

Stefan: これがHamiltonが本当に軽量な部分です。それは具体化に対して意見を持っていません。アーティファクトを実際にどこにプッシュするかなど、コネクタやその他のものが関与するポイントです。

これは軽量レベルであり、Hamilton DAGにモデルの計算を依頼し、モデルを取得し、次の行で保存またはデータストアにプッシュすることができます – また、それを行うHamilton関数を記述することもできます。

関数の実行の副作用はプッシュですが、これは拡張を見るための場所であり、より自然にDAG内でプラグ可能にするためのさらなる機能を提供する場所です。モデルの構築を指定するためにモデルを保存してNeptuneに配置したいというコンテキストで実行する場所を指定すべきです。

それが私たちが向かっているところですが、現時点では、Hamiltonはその方法を制限していません。

Aurimas: ただし、モデルを抽出してサービングレイヤーで使用することはできますか？

Stefan: はい。 Hamiltonの特徴の1つは、各関数で構成や異なるモジュールに基づいて関数の実装を切り替えることができることです。

例えば、関数の2つの実装を持つことができます。1つはS3からモデルを取得するためのパスを取り、もう1つはモデルまたはトレーニングデータを渡してモデルを適合させるものです。

関数の実装には柔軟性があり、それらを切り替えることができます。要するに、Hamiltonフレームワークにはネイティブのものはありません…

ただし、その実装方法には柔軟性があります。

Aurimas: 基本的にHamiltonでトレーニングとサービングの両方を行うことができますね。

それが私の聞いたことです。

Stefan: それはモデル化できます。はい。

Hamiltonによるデータバージョニング

Piotr: データバージョニングについてはどうですか？ 単純な形で言えば。

Hamiltonはコードベースのようです。コードをバージョン管理すると、おそらく特徴のレシピなどをバージョン管理しますよね？

そこに基づいて、「はい、データセットにバージョン管理があります」と言うためには、何が必要ですか？

Stefan: はい、その通りです。 Hamiltonではデータをエンコードするためにデータを記述します。Gitに保存するか、Pythonパッケージをバージョン管理するための構造化された方法がある場合、いつでも遡って計算の正確な流れを理解することができます。

ただし、ソースデータの場所とデータセットのバージョン管理の出力に関しては、あなた次第です（保存および取り込みたいものの忠実度によります）。

Hamiltonを使用してデータセットを作成したり、データセットを変換したりする場合、そのデータセットをどこかに保存します。Hamilton DAGのインスタンス化に使用したGit SHAと構成を保存し、そのアーティファクトと一緒に保存すると、ソースデータがまだある場合は常に過去に戻って再作成できます。

これはStitch Fixでプラットフォームを構築する際のものであり、Hamiltonではこれらのフック、または少なくともそれとの統合の能力があります。これはDAGWorksプラットフォームの一部です。

私たちはあなたのためにその追加のメタデータを保存してキャプチャする手段を提供しようとしており、あなたがそのコンポーネントを構築する必要がないように、それを他のシステムと接続できるようにすることができます。

サイズに応じて、データカタログを持っているかもしれません。オープンラインエージ情報を保存および出力するなど。

統合するためのアイデアや早期スタックを探していますが、それ以外では意見を持っていません。データセットのバージョニングに関しては、データだけでなく、Hamiltonで記述されている場合、変換に使用されたコードパスを再計算することができます。

Hamiltonを構築することが決定したのはいつですか？

Aurimas: Stitch Fixで行ったこととHamilton自体に少し戻るかもしれません。

Hamiltonを構築する必要があると思ったのはいつですか？

Stefan: 2019年のことです。

Hamiltonをオープンソース化したのはわずか18か月前です。これは新しいライブラリではありません- Stitch Fixでは3年以上も実行されています。

Stitch Fixの興味深い部分は、ビジネスのためにさまざまなモデリングの専門分野を持つ100人以上のデータサイエンティストを抱えるデータサイエンス組織でした。

私はデータサイエンスのためにエンジニアリングを行っていたプラットフォームチームの一員でした。私のチームの任務は、チームのためにモデルのプロダクショナル化を効率化することでした。

私たちは、「ソフトウェアエンジニアリングのハードルをどのように下げることができるか」と考えました。

答えは、彼らが優れたソフトウェアエンジニアである必要がないようなツールの抽象化とAPIを提供することであり、MLOpsのベストプラクティスは基本的に無料で提供されました。

苦労しているチームがあり、マネージャーが話し合いにやってきました。彼は言いました、「このコードベースは酷いです、助けが必要です、何か考えてくれませんか？ドキュメントとテストを行うことを優先したいですし、ワークフローを改善できれば素晴らしいです」と、要件を述べていました。

Stitch Fixでは、「データサイエンティストとの相互作用の観点から、プラットフォームからの究極のエンドユーザーエクスペリエンスやAPIは何か？」と考えていました。

私はPythonの関数は実装する必要があるオブジェクト指向のインターフェースではないと考えています。単に関数を与えて、Pythonでは関数を検査し、その形状、入出力、型の注釈などを知るためのメタプログラミングが十分にできます。

ですので、在宅勤務の水曜日にプラス1です。Stitch Fixではミーティングのない日があり、この問題について考えるための一日を確保しました。

私は「どのようにしてすべてが単体テスト可能で、ドキュメントに適した、DAGとワークフローがわかりやすく、説明しやすいものにするか」と考えました。

その場合、ハミルトンを試作し、チームに持ち帰りました。私の現在の共同創設者であり、Stich Fixの元同僚であるイライジャも、よりDAGスタイルのアプローチに近い第2の実装を考案しました。

チームは私の実装が好きでしたが、基本的にはすべてが単体テスト可能で、ドキュメントに適した、良い統合テストのストーリーを持つという前提です。

データサイエンスのコードでは、同じスクリプトに大量のコードを追加することは非常に簡単で、そのコードはどんどん成長します。ハミルトンでは、とても簡単です。何かをテストするためにすべてを計算する必要はありません。ハミルトンは、計算したいものに必要なパスのみを辿ることを知っています。

しかし、大まかな起源の話はこんなものです。

チームを移行させ、オンボードさせました。プルリクエストはより速くなりました。チームはそれが大好きです。彼らは非常に使い続けます。それは彼らの人生を以前よりも確実に簡単にしました。

ハミルトンをディープラーニングとタブラーデータに使用する

Piotr: 以前に手動で作成された1,000以上のフィーチャーに取り組んでいると言いましたね。

Hamiltonは、タブラーデータのコンテキストでより有用ですか、それとも手動で開発されたフィーチャーが多いディープラーニングタイプのデータでも使用できますか？

Stefan: 間違いなくです。 Hamiltonのルーツとハイライトは、モデルへの入力のためのタブラーデータを管理および作成しようとすることから来ています。

Stitch Fixのチームは、Hamiltonで4,000以上のフィーチャートランスフォームを管理しています。そして私は言いたいと思います-

Piotr: 1つのモデルに対してですか？

Stefan: 彼らが作成するすべてのモデルに対して、彼らは同じコードベース内で4,000以上のフィーチャートランスフォームを持っており、それを追加および管理することは彼らの作業を遅くしません。

他のタイプの質問については、「はい」と答えたいと思います。 Hamiltonは、実際には行われているソフトウェアエンジニアリングの一部を置き換えています。それは本当に、ディープラーニングのユースケースでデータフローをつなぎ合わせるために行う必要があることに依存します。

一部の人々は、「ハミルトンはLangChainに少し似ている」と言っています。私はまだLangChainを見ていませんが、大きなモデルで物事をつなぎ合わせるために使用されているものであることは知っています。

ですので、まだ正確にどこでそれらが類似していると思われるかはわかりませんが、エンコーダーを使用して手続き型のコードを持っている場合、おそらくそれをハミルトンと一緒に書き換えて使用する方法があります。

ハミルトンには非常に軽量なデータ品質ランタイムチェックの機能があります。関数の出力をチェックすることが重要な場合、拡張可能な方法でそれを行うことができます。

タブラーデータを使用している場合、Panderaがあります。スキーマを記述するための人気のあるライブラリです-それをサポートしています。それ以外の場合には、テンソルなどの他のオブジェクトタイプを使用している場合、テンソルが特定の基準を満たすことを確認するためにそれを拡張する能力を持っています。

Piotr: あなたは、ハミルトンをデータセットのテストフレームワークとして使用するために、列またはセットの列に対して統計情報を計算することもできますか？

特定の列の値を検証するのではなく、データの統計的な分布について話しています。

Stefan: すべてがPython関数であり、ハミルトンフレームワークがそれらを実行する美しさは、関数の出力に関して柔軟性があることです。そして、それはただデータフレームであるということです。

はい、我々はフレームワークに組み込む何かを作成することができます。要約統計情報を取り、それらを出力するものです。確かに、それは私たちが実験していることの一部です。

Piotr: 例えば、3つの列間の統計的相関を計算したい場合、これは列を表す関数にどのように適合しますか？

Stefan: それは、実際の変換にしたいかどうかによります。

単に入力または出力のデータフレームを受け取る関数を記述し、その関数の本体で手動で行うことができます。

これは本当に、データサイエンティストがさまざまなことを自動的にキャプチャできるようにするためのプラットフォームの観点から行っている場合に依存します。その場合は、関数をラップする何かを呼び出すデコレータを追加し、必要な内省を行うことができます。

なぜHamiltonをオープンソースにしたのですか？

Piotr: 私はStitch Fixで始まったHamiltonの物語に戻ります。オープンソースにする動機は何でしたか？

それは私にとって興味深いことです。私はいくつかの企業にいましたが、いつもいくつかの内部ライブラリやプロジェクトがあり、それらが好きでしたが、公開して実際に使用するのはそんなに簡単ではありません。

ライセンスファイルを追加してリポジトリを公開することを指しているわけではありませんが、それを実際に生かして本当にオープンにすることを指しています。

Stefan: はい。私のチームはビルドと購入の観点から見て、スタック全体を見ていました。そして、私たちは2019年にHamiltonを作成しましたが、非常に類似したものがオープンソースで出てきているのを見て、「私たちはユニークな視点を持っていると思います」と思いました。私たちが持っていた他のツールの中で、Hamiltonは最も簡単にオープンソース化できました。

知っている人にとっては、Stitch Fixはブランディングに非常に力を入れていました。興味深い技術や事柄についてのストーリーを知りたい場合は、Stitch FixのMultithreadedブログを調べることができます。

私はその一環であるテックブランディングチームの一員でした。品質の高いコンテンツを提供することは、Stitch Fixのブランドに役立ち、採用にも役立ちました。

動機に関しては、ブランディングの観点です。高品質の基準を設定し、ブランドにとって良い見た目のものを提供することです。

そして、私たちの視点からすると、私たちのチームがHamiltonをオープンソース化するのが最も簡単であり、また最も興味深いということでした。

私たちは、MLflowに似た構成駆動型のモデルパイプラインなども構築しましたが、それはあまりユニークではないと言いたいと思います。Hamiltonは特定の問題に対するよりユニークなアングルです。そして、それらの2つが組み合わさった場合、これは良いブランディングの機会だと思いました。

そして、ライブラリの表面積に関しては、非常に小さいです。多くの依存関係は必要ありませんので、オープンソースの観点からメンテナンスすることが可能です。

要件も比較的低いです。Python 3.6以上が必要ですが、現在は3.6がサポート終了となったため、3.7が必要ですが、動作します。

その観点からすると、採用を増やすために多くの機能を追加する必要はなく、コミュニティから利用可能なものとすることができるという、かなり良いスイートスポットになっていると思います。

最後の部分は少し未知の領域でした。「コミュニティを築くためにどれくらいの時間を費やすことになるのか？」私は常にそれについてもっと時間を費やすことができなかったかもしれませんが、それがオープンソース化した経緯です。

私はちょうど数ヶ月かけてブログ記事を書くことに時間を費やしましたが、それは自分の考えを整理し、明確に表現する良い手段でもあります。

オープンソース製品のローンチ

Piotr: 外部からの受け入れについては、ローンチはどうでしたか？プロモーション方法を教えていただけますか？初日からうまくいきましたか、それとも人気を得るまでに時間がかかりましたか？

Stefan: Stitch Fixには読者数の多いブログがありましたので、それを活用しました。それに加えて、ブログを書きました。数ヶ月で数百のスターを獲得しました。参加できるSlackコミュニティもあります。

他の何かと比較するための基準はありませんが、Stitch Fix以外の人々も採用しています。イギリス政府デジタルサービスは、Hamiltonを国のフィードバックパイプラインに使用しています。

IBMの内部で、小規模な内部検索ツールのような製品に使用している人もいます。オープンソースの問題は、テレメトリーなどが難しいため、誰が本番で使用しているかわからないことです。人々は問題を作成し、質問をし、それによって私たちが助けるためのエネルギーを得ました。

Piotr: 外部の方から最初のプルリクエストはありましたか？有用なプルリクエストはありましたか？

Stefan: 幸運なことに、James Lambという人が参加してくれました。彼はいくつかのオープンソースプロジェクトに関わっており、私たちのリポジトリのドキュメントと構造に助けてくれました。

基本的には、外部の貢献者がテストを実行したりするのを容易にするために、クリーンアップや整理を行いました。彼は「このプルリクエストのテンプレートは長すぎる。どうやって短くできるか？」とフィードバックをくれました。彼のアドバイスは非常に価値があります。貢献者を怖がらせないようにするためです。

彼はいくつかの良いポインターを教えてくれ、構造を少し整えるのに役立ちました。リポジトリの整理は他の人が貢献しやすくするための重要な要素です。

Stitch Fixの最大の課題

Aurimas: スティッチフィックスでの仕事についてもう少し話を戻しましょう。Hamiltonがオープンソース化しやすかったと言いましたね？私が正しく理解しているなら、それ以外にも取り組んでいたことはたくさんあったのでしょう？パイプラインだけではなく。

スティッチフィックスでの最大の問題と、それをプラットフォームとしてどのように解決しようとしましたか？

Stefan: そうですね、6年前の状況を思い出してみてください。まだオープンソースの成熟度は高くありませんでした。スティッチフィックスでは、データサイエンティストがモデルのためにAPIを作成する場合、自分でEC2上でイメージを作成し、Flaskアプリを実行して統合する必要がありました。

私たちは基本的には、プロダクションの安定化、より良いプラクティスの確保から始めました。データサイエンティストがFastAPIの上にバックエンドをデプロイするのを簡単にするために、Pythonの関数を書くだけで済むようにするチームを支援しました。

これにより、バックエンドのマイクロサービスが安定化し、標準化されました。プラットフォームが実際のウェブサービスを所有するようになったためです。

Piotr: つまり、Lambdaインターフェースを提供しているんですね？

Stefan: 少し重たいかもしれませんが、彼らがrequirements.txtやベースのDockerイメージ、コードの存在するGitリポジトリを提供しやすくすることが目的でした。そして、Dockerコンテナを作成し、AWSに比較的簡単にデプロイすることができました。

Aurimas: テンプレートリポジトリのことですか？それともここでは別の名前で呼んでいましたか？

Stefan: まだテンプレートではありませんが、マイクロサービスを作成し、デプロイするために必要なものはいくつかありました。それができれば、ワークフローのさまざまな部分に目を向けることができました。

問題の一つはモデルのシリアライズと「本番でどのバージョンのモデルが実行されているか」です。そのために、モデルエンベロープというプロジェクトを開発しました。封筒のメタファーのように、何かを封筒に入れることができます。

例えば、モデルを挿入することもできますが、そのモデルに関してのメタデータや追加情報をたくさん挿入することもできます。モデルのシリアライズには、非常に正確なPythonの依存関係が必要です。そうでないとシリアライズの問題が発生する可能性があります。

モデルをリロードする場合、誰かが誤ったモデルをプッシュしたり、ロールバックが簡単でなかったりする問題が発生する可能性があります。Stitch Fixでは、新しいモデルが検出されると、自動的にリロードされる仕組みがありました。

しかし、それは運用の観点からはかなりの課題であり、ロールバックやテストの必要性がありました。モデルエンベロープの抽象化により、モデルを保存し、構成とUIを提供し、新しいモデルを提供し、新しいサービスを自動的にデプロイすることができました。各モデルビルドは新しいDockerコンテナであり、各サービスはイミュータブルでした。

これにより、何かをプッシュしたり、ロールバックを簡単にするためのより良い構造が提供され、単にコンテナを切り替えるだけで済みました。何かをデバッグしたい場合は、そのコンテナを取得して本番環境で実行されているものと比較することができました。

また、モデルパイプラインにそれを組み込む必要がなく、CI/CDタイプのパイプラインを挿入することもできました。現在の一般的なフレームワークでは、機械学習モデルパイプラインの最後にETLがあり、モデルを検証するためにさまざまなCI/CDチェックが行われます。

私たちはその部分を抽象化し、モデルパイプラインを作成した後でも追加できるようにしました。これにより、変更や更新が容易になり、モデルパイプラインにバグがある場合や新しいテストを作成したい場合にも、モデルパイプラインを変更する必要がありませんでした。

大まかに言うと、それがモデルエンベロープの名前でした。それはユーザーがモデルを構築し、1時間以内に本番環境に展開するのを支援しました。

バッチ側にも同等のものがありました。通常、モデルを作成してバッチのどこかで実行する場合、タスクを書かなければなりませんでした。私たちはモデルをSparkや大きなボックスで実行するための手順を提供しました。

バッチ予測を行うためにバッチタスクを書かなくてもよかったのです。企業内のある程度の成熟度に達すると、他のチームのモデルを再利用したいという要望が出てきます。その場合、私たちはその間に立って、他の人のモデルを利用するための標準的な方法を提供しました。

Stitch Fixプラットフォームでのモデルのシリアライズ

Piotr: そして、Stefan、モデルのシリアライズについて話していますが、特徴の前処理と後処理もこのモデルにシリアライズしましたか？どこで境界を設けましたか？

また、非常に関連している2つ目の質問は、モデルのシグネチャをどのように記述しましたか？RESTful APIだとすると、どのようにしましたか？

Stefan: モデルを保存するとき、関数の名前やオブジェクトへのポインタを提供する必要がありました。

その関数を使って、インスペクトして、モデル保存APIの一部として、入力トレーニングデータとサンプル出力を求めました。そのため、モデルを保存する際に実際にモデルを少し実行して、APIについてもう少しインスペクトすることができました。したがって、もし誰かがデータフレームを渡した場合、そのデータフレームのサンプルデータを提供する必要がありました。

それから、私たちはウェブサービス側でPydanticスキーマを作成しました。FastAPIを使用している場合は、ドキュメントページにアクセスして、実行しやすいRESTベースのインターフェースを確認できます。このインターフェースでは、このモデルを実行するために必要な特徴が表示されます。

したがって、モデルの結合については、Pythonをシリアライズの境界として扱っていたため、実際には関数の中に何が含まれているかによります。人々は、モデルに委譲する前に最初のステップとして特徴量化を含める関数を書くこともできました。また、それらを別々に保持するオプションもありました。その場合、呼び出し時には、リクエストに適切な特徴量を計算するために最初にフィーチャーストアにアクセスする必要がありました。

私たちは境界線がどこにあるかについてはあまり意見を持っていませんが、それはおそらく私たちが標準化を助けるために戻ってくることを試みていることです。異なるユースケースには異なるSLAがあり、異なるニーズがあります。時には継ぎ合わせることが合理的であり、時には事前計算することが容易でモデルにそれをくっつける必要はありません。

Piotr:そして、データサイエンティストのためのインターフェース、つまりこのモデルを構築し、シリアライズするための方法はPythonであり、彼らはPythonを離れませんでした。すべてがPythonで行われます。そして、私は、例えば、サンプルの入力と出力を提供するというアイデアが好きです。これは、私たちが言うなら、Pythonのやり方です。ユニットテストのように、シグネチャが保持されていることを確認する方法です。

Stefan:そうですね、それで、実際には、そのサンプルの入力と出力から、理想的には、実際にはトレーニングセットでもありました。そして、これが私たちが、あなたが示唆していたように、要約統計量を事前計算するところです。そして、誰かがモデルを保存するときに、私たちは無料で提供しようとしました。

彼らは、データの可観測性について考える必要はありませんでしたが、もしそのデータを提供した場合、私たちはそれに関する情報をキャプチャしました。したがって、問題が発生した場合、私たちはあなたが何が変わったのかを判断するのに役立つ手がかりを持っています。それはデータに関する何かでしょうか、それとも新しいPythonの依存関係を含めたのでしょうか。

また、実行された環境を内部的に調査しました。したがって、パッケージレベルで、何が含まれているかを理解できました。

したがって、モデルの本番実行時には、ソフトウェアエンジニアリングの観点から少なくとも予想どおりにすべてが実行されるようにするために、できるだけ依存関係を再現しようとしました。

Piotr:それでは、モデルのパッケージングというのは、今日の解決策のようですね。それらの封筒をどこに保存していたのですか。フレームワークの封筒はわかりますが、シリアライズされたモデルとメタデータのインスタンスはどこに保存していましたか？

Stefan:そうですね。基本的にはS3と言えます。私たちはS3に構造化された方法でそれらを保存していましたが、実際のメタデータとポインタを持つデータベースと組み合わせました。したがって、一部のメタデータはデータベースに保存され、クエリに使用することができます。

私たちは各封筒にタグを指定するシステムを持っていました。これにより、モデルと関連するタグの構造に基づいて階層的に組織化またはクエリを行うことができました。そして、それは行の単一のフィールドでした。

フィールドの1つは、シリアライズされたアーティファクトが存在する場所を指すだけでした。ですので、非常に基本的で、あまり複雑ではありませんでした。

どの機能を構築するかを決定する方法

Aurimas:よし、Stefan、それでプラットフォームチームではすべてが自然に進んでいたようですね。チームはモデルを展開する必要がありましたね？だから、封筒のフレームワークを作成し、それから彼らはセクションコードを効率的に定義することで苦労していましたね、Hamiltonを作成しました。

何か建設すべきというクレイジーな提案が誰かから持ち込まれた場合、それを拒否することはありましたか？どの機能を構築するか、どの機能を拒否するかをどのように決定していましたか？

Stefan:そうですね。私はStitch Fixでプラットフォームを構築する際のいくつかの学びをブログ記事にしています。通常、私たちが「いいえ」と言った要求は、非常に複雑なものを望んでいるが、まだ本番ではなく、まだビジネス価値がわかっていないような何かを試すことを望んでいる人からの要求です。

彼らは何かをする能力を持ちたかったが、それはまだ本番ではなく、ビジネス価値を向上させるために何かを試みているものでした。

それがビジネスの優先事項であり、この方向性を追求する必要があるとわかっていれば、私たちはそれに関して助けることができると言います。それ以外の場合、通常、これらの要求は、エンジニアリングの観点からかなり能力があると思っている人々からのものです。

そこで、私たちは「まあ、君がそれを考え出してみて、それがうまくいけば、所有権や引き受けることについて話し合うことができるよ」と言ったわけです。たとえば、私たちは1つの構成駆動型モデルパイプラインを持っていました。これはYAMLとPythonコードを組み合わせたものであり、SQLでモデルパイプラインを構築する方法を記述することができました。

ハミルトンとは異なり、よりマクロな観点からアプローチしているので、最初からサポートしたくはありませんでしたが、他の人々がそれを採用したいという要望が増え、管理や保守の複雑さの観点から再構築し、より一般的で広範なものにしました。

そして、それが「はい」か「いいえ」を言うための合理的な方法だと思うのは、まず、それがビジネス上の優先事項ではない場合は、おそらくあなたの時間には値しないと言って、彼らにそれを証明してもらい、うまくいけば、事前にその話をしている場合は採用について話し合うことができるということです。

ですから、それはあなたの負担ではありません。人々は時々感情的になることがあります。彼らがそれに愛着を持っている場合、彼らがそれをどのようにあなたに引き継ぐのかを認識している必要があります。それは考えるべきことです。

ただし、それ以外の場合、一部の人々はTensorFlowのサポート、TensorFlowに特化したサポートを希望していましたが、TensorFlowを使用しているのは1人だけでした。彼らは「うん、今すぐ何かをすることができます。何か追加できます」と言っていましたが、幸いにも、そのプロジェクトはうまくいかず、彼らは最終的に去っていきました。

したがって、私たちはそこに時間を費やさなかったことを幸せに思っています。ですから、もっと掘り下げることができます。

Piotr: それは製品マネージャーの役割のようですね。

Stefan: そうですね、Stitch Fixでは製品マネージャーはいませんでした。組織にはプログラムマネージャーがいました。私たちのチームは自分たち自身の製品マネージャーでした。だから私は時間の一部を人々やマネージャーと話をして、彼らの苦情を理解し、ビジネス上で価値のあるものとは何か、どこに時間を費やすべきかを理解することに費やしていました。

Piotr:

私はNeptuneで製品を運営していますが、技術に詳しい人々、エンジニア、コードを書いたり抽象的に考えたりできる人々と関わるのは、いいことでもあり、同時に挑戦的なことです。

非常にしばしば、フィーチャーリクエストの最初のイテレーションを聞くと、それは実際には解決策です。問題は聞こえません。私はこのテストが好きで、他のMLプラットフォームチームもそれから学ぶことができると思います。それが本番環境で動いているかどうか？

それは動作しているものなのか、将来的に本番環境に移行する予定のものなのか？最初のフィルターとして、このヒューリスティックを気に入っています。

Stefan: 私たちにはたくさんの思い出がよみがえってきましたね。例えば、「これができる？」と聞かれることがあります。そこで問題は何か、と尋ねることが実際には最初の反応となるべきです。なぜなら、彼らが特定のタスクにその特定のハンマーを見つけたかもしれないからです。

たとえば、ハイパーパラメータの最適化を行いたいと言っていましたが、「この方法でできますか？」と尋ねると、私たちは少し高いレベルで実際にそれを行うことができると気づきました。したがって、常に尋ねるべき重要な質問は、「実際に解決しようとしている問題は何ですか？」です。

また、「ビジネス上の価値は何ですか？」とも尋ねることができます。これがどれだけ重要かを本当に知るためにです。

チームからの賛同の獲得

Piotr: データサイエンティストが機能を求めてあなたにやってくる方法については学びました。では、コミュニケーションの2番目の部分はどのように機能し、提案したことを人々やチームに従わせるためにどのようにしましたか？組織内で基準を設定するにはどうしましたか？

Stefan: はい、理想的には、私たちが持っているイニシアチブのどれかについて、特定のユースケース、狭いユースケース、それを必要とし、開発したものを採用し、使用するチームを見つけました。何かを開発しても誰も使わないのは最悪です。それは見栄えが悪く、マネージャーは「誰が使っているのか？」と言います。

• だから、まず明確なユースケースと必要性を持つパートナーがいることを確認する必要があります。そして、それが成功した後に拡大について考え始めることです。なぜなら、ユースケースとストーリーとして使用できるからです。理想的には、週に1回または2週に1回の共有が行われます。私たちは「アルゴリズム」と呼ばれるものを持っていました。そこでは、数分間立ち上がって話すことができました。

• そして、はい、確かに、Stitch Fixでは、データサイエンティストがツールを使用しない選択肢を持っていないように、内部で開発ツールの普及活動を行わなければなりませんでした。彼らが自分自身でエンジニアリングを行いたい場合にも、私たちのツールを使用しなくてもよいのです。だから、私たちは確かに、これらの苦情をあなたから取り除くことができるというルートを辿る必要がありました。あなたはそれについて考える必要はありません。私たちが構築したものがあります。それを使用している人がいます。そして、彼らは特定のユースケースでそれを使用しています。だから、認知度が重要です。解決策について知っている人がいて、選択肢であることを確認する必要があります。
• ドキュメンテーション、実際には、Sphinxドキュメントを簡単に書くことができるツールがありました。だから、私たちは実際には、あらゆる種類のモデルエンベロープ、他のツール、ハミルトンに対して、Sphinxドキュメントのセットアップを行っていました。だから、もし人々がそれを望むなら、ドキュメントにアクセスできるようにするために、私たちはそれを示すことができました。

• もう一つは、私たちが入れたテレメトリです。プラットフォームの良いところは、好きなだけテレメトリを入れることができるということです。だから、実際には、誰かが何かを使用していてエラーが発生した場合、私たちはSlackのアラートを受け取りました。そして、私たちはそれに対応し、彼らに尋ねました、「何をしているのですか？」

おそらく、彼らが正しく作業を行うことに成功するように、彼らと関わろうとしました。オープンソースではそれはできません。残念ながら、それは少し侵襲的です。しかし、それ以外の場合、ほとんどの人々は四半期に数回、数回の採用にしか取り組むことができません。

だから、それはただ、正しい場所に正しいものを持っている必要があります。彼らが始めるための瞬間を持っているときに、それを始められるようにするために、それをできるだけ小さなジャンプにするためのドキュメントの例や方法を見つけようとする必要があります。

プラットフォームを作成するためのチームをどのように編成しましたか？

Aurimas: それでは、MLプラットフォームの初めからStitch Fixにいたのですか、それとも初めから進化したのですか？

Stefan: ええ、私がそこに着いたときは、かなり基本的な小さなチームでした。私がそこにいた6年間で、かなり成長しました。

Aurimas: それがどのように作成されたのか知っていますか？なぜ正しいタイミングでプラットフォームチームを持つことが決定されたのですか？

Stefan: いいえ、その答えは知りませんが、エリック・コルソンとジェフ・マグヌッソンという2人の人物が指導的な役割を担っていました。

ジェフ・マグヌッソンは、エンジニアがETLを書くべきではないという有名な記事を書いています。もし検索すれば、Stitch Fixの哲学を説明するこの記事が表示されます。そこで、私たちは全スタックのデータサイエンティストを作り出したかったのです。彼らがすべてを端から端まで行えるなら、より速くより良く作業が進むことができます。

ただ、その仮説には、雇うことができないスケールの制限があります。すべてのスキルを持つ人々を雇うのは難しいです。データサイエンス、全スタック、ですよね？それで、その場合、彼らのビジョンは、ツールを作るためのプラットフォームチームだということでした。

私はデータを知らないかもしれませんが、機械学習の取り組みに関する私の知識は、一般にエンジニアとデータサイエンティストの比率が1：1または1：2くらいだということです。しかし、Stitch Fixでは、エンジニアリング、パイプラインをサポートするために焦点を当てたプラットフォームチームを単純に考えると、その比率は安全です。

比率は1対10に近かったです。そのため、エンジニアとデータサイエンティストができることのレバレッジの観点では、少し違いがあると思います。プラットフォームが現在何をするのかを理解する必要がありますし、それを伝える方法も知っておかなければなりません。

ですから、Piotrさんが前に質問した、プラットフォームチームの効果をどのように測定するかという点に関して、彼らがどのような会話をしてヘッドカウントを得たのかはわかりませんが、少しの助けが必要な場合もあるかもしれません。少なくとも、これは2次的なチームになる可能性があるということを伝えるために、少しの助けが必要です。直接的に影響を与える機能を生み出すわけではありませんが、それを行っている人々をより効果的かつ効率的にすることができれば、それは価値のある投資となるでしょう。

Aurimas: エンジニアとデータサイエンティストと言った場合、Machine Learning Engineerもエンジニアと考えるのですか、それともむしろデータサイエンティストと考えるのですか？

Stefan: はい、私はそれらを区別しています。データサイエンティストと機械学習エンジニアの区別は、オンラインのようなことをもう少し行うという意味合いがあると言えるかもしれません。ですから、もう少しエンジニアリングが必要です。しかし、それほど大きな差はないと思います。実際には、私の希望は、人々がHamiltonを使用すると、彼らがより多くのことをすることができるようになり、データサイエンティストから機械学習エンジニアにタイトルを切り替えることができるということです。

それ以外の場合は、私はそれらをデータサイエンティストのカテゴリにまとめて考えています。ですから、私が話していたのは特にプラットフォームエンジニアリングです。

Aurimas: わかりました。Stitch Fixの年数を通じて、チームの構成がどのように変化しましたか？データサイエンティストとエンジニアで構成されるエンドツーエンドの機械学習チームの構成を変更しましたか？

Stefan: それは本当に彼らの問題に依存していました。予測チームはオフラインバッチの作業が中心でした。それで十分で、オンラインの観点からもあまり複雑なエンジニアリングは必要ありませんでした。

しかし、パーソナライゼーションチームでは、SLAやクライアント対応の問題が重要になりましたので、経験が少し豊富な人材の採用を始めました。彼らはまだそれに取り組んでいませんが、DAGWorksでは低いソフトウェアエンジニアリングのハードルを下げてモデルパイプラインの構築と維持を支援しようとしています。

私たちがオンラインで推奨を生成する場合、それを簡素化するものはありません。そのため、時間の経過とともに多くのマイクロサービスを管理したり、SLAに対応したりする場合、より強力なエンジニアリングのスキルセットが必要です。

この場合、ソフトウェアエンジニアリングのスキルが低い優れたモデラーである場合を除いて、それはマージし始めた分野です。

Aurimas: 技術的ではない役割については、プロジェクトマネージャーや専門家などをそのMLチームに組み込みますか？それとも純粋にデータサイエンティストだけですか？

Stefan: データサイエンティストチームが連携する相手によって、一部はデータサイエンティストチームの役割に降りかかります。つまり、組織内の誰かとパートナーシップを組んでいる場合、その2つの間の共同作業になります。明示的なプロダクトマネージャーの役割はありませんでした。

私は、Stitch Fixが成長し始めたときに、プロジェクト管理が課題になったと思います。どのように導入するか、誰がそれを行うのかという点です。ですから、スケールによります。

プロダクトが何をしているか、それが触れているものによって、それが必要になるかどうかが異なります。しかし、私がそこにいたときに組織は、より効率的かつ効果的に運営するための方法を考えていました。そして、どのようにチームの範囲を定めるか、機械学習を提供するチームの境界線を正確に引く方法についても考えていました。

例えば、倉庫で在庫を管理している在庫チームと一緒に作業している場合、そこではチームの構造はまだ形成中です。私がいたときは別々でしたが、彼らは一緒に働いていましたが、異なるマネージャーでした。

お互いに報告しあうようなものですが、彼らは同じイニシアチブに取り組んでいました。だから、小規模の時はうまく機能しました。現在の状況については、そこの誰かに尋ねる必要がありますが、それ以外の場合は、企業の規模と機械学習のイニシアチブの重要性に依存すると言えます。

モデルの監視と本番運用

Piotr: モデルの監視と本番への展開について質問したいと思います。ソフトウェアの領域に似ているようですね。データサイエンティストはここにおり、ソフトウェアエンジニアと一緒に仕事をしています。MLプラットフォームチームはこのDevOpsチームになるかもしれません。

それが本番であることを確認する人々はどうなっているのでしょうか？そして、それはどのように機能していましたか？

Stefan: モデルエンベロープにより、デプロイメントは無料で提供されました。これはつまり、データサイエンティストが責任を持つのはモデルだけであるということです。

そして、モデルが本番環境に到達することはないようにするために、CIの検証ステップが十分にあるように構造化しました。

したがって、本番環境で壊れる可能性があるのはインフラの変更だけであり、その場合、データサイエンティストは責任を持つことができません。

その他の場合は、もし彼らが責任を持っているならば、私たちのチームの責任でした。

私たちは、50以上のサービスのオンコールを担当していました。なぜなら、私たちが展開しているモデルの数がそんなに多かったからです。そして私たちは最前線にいました。だって、何か問題が起きるとしたら、おそらくインフラに関連したものだったからです。

私たちは最初のポイントでしたが、彼らもコールチェーン上にいました。実際、一歩引いて考えると、どのモデルが展開されても、私たちは両方ともオンコールでした。展開されて実行されていることを確認するためにです。しかし、それから私たちは少し分岐しました。インフラの場合は何もできないので、最初のエスカレーションを行いますが、それ以外の場合はオンコールでなければなりません。モデルが実際に奇妙な予測をしている場合は、それを修正することはできません。その場合、デバッグと診断を行う必要があるのはあなたです。

Piotr: データに関連する何かですね？データの漂流。

Stefan: はい、データの漂流、上流の何かなどです。だからこそ、より良いモデルの観測性とデータの観測性が助けになります。それを捉えて利用しようとしています。

さまざまな方法がありますが、私たちが設定したもののうちの一つは、トレーニング時に入力をキャプチャできるということです。また、ウェブサービスを制御していたため、ログを記録し、受け取ったものを出力することもできました。

そのため、ビルドと調整のためのパイプラインを持っていました。トレーニングサービングSKUがあるかどうかを尋ねたい場合、データサイエンティストや機械学習エンジニアとして、それを構築する必要はありませんでした。単にサービスにログインするだけでした。

その後、いくつかの他の設定を有効にしましたが、それからは製品の特徴とトレーニングの特徴を比較するために観測性の解決策にプッシュできる方法を提供しました。

Piotr: データサイエンティストにとって非常に使いやすいインターフェースを提供したようですね。

Stefan: はい、それがアイデアです。実を言うと、それが私がDAGWorksで再現しようとしているもので、Stitch Fixで構築した経験を誰もが持てるような抽象化を提供することです。

しかし、データサイエンティストは移行が嫌いです。だから、プラットフォームの観点からものを変えたいと思った場合、データサイエンティストに「移行する必要があります」と言う必要はありません。だから、私たちはこうしたAPIの境界に重点を置いたのです。私たちの人生を簡単にするためだけでなく、彼らの人生も簡単にするためです。

Piotr: Stitch Fixで働いていたときのデータサイエンティストとMLプラットフォームチームの人数について共有できますか？

ステファン：ピーク時は、データサイエンティストとプラットフォームチームの合計で150人ぐらいいたと思います。

ピオトル：チームは1:10の比率でしたか？

ステファン：プラットフォームチームがありましたので、合計で1:4か1:5ぐらいだったと思います。UIに協力するプラットフォームチームと、マイクロサービスやオンラインアーキテクチャに特化したプラットフォームチームがありました。パイプラインには関係しない部分です。

なので、実際のエンジニアリング面では、APIの統合や機械学習、その他のビジネスに関する作業が必要でした。実際の比率は1:4か1:5でしたが、プラットフォームチームの大きな役割があり、プラットフォームの構築、統合、デバッグ、機械学習の推奨などの作業に協力していました。

アウリマス：しかし、機械学習チームの規模はどうでしたか？一つのチームに数百人いたわけではないですよね？

ステファン：そうですね、チームによって異なりましたが、8人から10人ぐらいでした。大きなチームもあれば、5人のチームもありました。

実際には、ビジネスに関わる垂直と協力する人に依存していました。イギリスとアメリカには地区があり、それぞれのビジネスラインもありました。例えば、メンズ、ウィメンズ、キッズなどです。

それぞれの組み合わせごとにデータサイエンティストがいると考えられます。必要な場所や必要でない場所に依存していましたが、チームは3人から8人から10人ぐらいでした。

MLOpsエンジニアとして価値を持つには？

ピオトル：データサイエンティストになる方法については多くの情報やコンテンツがあります。しかし、MLOpsエンジニアやMLプラットフォームチームのメンバーになる方法については、その桁数少ないですね。

あなたは、MLプラットフォームチームのメンバーにとって価値のある人物となるためには何が必要だと思いますか？そして、典型的なMLプラットフォームチームの構成はどうなっていますか？どのような人材が必要でしょうか？

ステファン：人々が何をしようとしているかを理解するためには共感する必要があると思います。少し機械学習やモデリングを経験したことがあると、人々が何をしようとしているのか尋ねることができます。

ある程度高いレベルで、何ができるのかを理解していることは役立ちます。そして、自分で何かを構築し、それに関連する苦労を経験したことも、共感するのに役立ちます。私の経験では、私は元々オペレーターでした。

モデルを構築しましたが、実際のモデル構築よりも、人々が効果的かつ効率的に作業できるようにするためのインフラに興味を持ちました。MLOpsでは、ベンダーオプスという言葉があります。

社内で構築していないソリューションを統合し導入する場合、抽象化や緊密な統合のどの部分を理解する必要があります。

共感力、バックグラウンド、そしてソフトウェアエンジニアリングのスキルセットが必要です。私のブログポストでは、2層のAPIとしてフレーム化しています。

理想的には、ベンダーのAPIを直接公開するべきではありません。常に制御できるようなバリアを設けるべきです。提供するプラットフォームの利用者が意思決定をする必要がないようにするためです。

例えば、アーティファクトをどこに保存するかなど、そのような決定をプラットフォームが行うべきです。ベンダーのAPIで提供する必要があるかもしれませんが、それはプラットフォームが決定できるようにするべきです。

これは、もしベンダーAPIの管理や保守の経験があるなら、次回は少し上手になるだろうというようなことを言う場所です。しかし、それ以外の場合は、そうですね。

また、DevOpsのバックグラウンドがあるか、自分自身で展開するためにものを構築したことがある場合、つまり、小規模な場所で働いていた場合、あなたは統合できるツールセットと生産上の影響をある程度理解することができます。

だってDatadogだけでサービスの展開をかなり合理的な方法で行うことができるから、そうでしょう？

しかし、モデル内部を本当に理解したい場合、なぜトレーニングやサービングが重要かを理解する必要がある場合は、それを行ったことがあること、それを行う必要がある理由を理解するための共感を持っていることが重要だと思います。そうすれば、全体像、つまりエンドツーエンドでの物事の適合具合、マクロな視点を持っていることで、より良いマイクロな意思決定ができると思います。

MLOpsはDevOpsの拡張です。分岐ではありません。MLOpsスタートアップのCEOとしての私の考え

MLプラットフォームチームの前途

Piotr: わかりました。ステファン、質問があります。カバーしたいトピックに関しては、かなり順調に進んでいると思います。アジェンダを見ていますが、聞くべきことがありますか、または話したいことはありますか？

ステファン: 良い質問です。

さて、私もアジェンダを見ています。うーん、将来について考えると、私にとってはStitch Fixはデータサイエンティストがエンドツーエンドで何かを行うことを可能にしようとしました。

私が解釈した方法は、データプラクティショナー全般がより自己サービス、エンドツーエンドの作業を行えるようにすることで、彼らはビジネスドメインのコンテキストを取り入れて何かを作り出すことができます。

したがって、価値があるかどうかを理解するためのより良いフィードバックループがあります。従来の方法では、人々はまだこの種の引き渡しモデルにとどまっています。つまり、どのような場合に、どのようなソリューションを設計するためのツールを提供しようとしていますか？

それは、データサイエンティストが自己サービスを行うためにソフトウェアエンジニアになる必要があることを意味しますか？逆に言えば、低コード、ノーコードというものもありますが、それは制約があると思います。ほとんどのソリューションはSQLやカスタムDSLのようなものであり、他の仕事にも応用するための知識やスキルセットを取り入れることにはあまり適していないと思います。つまり、同じツールを使用している場合にのみ機能するわけではありませんよね？

だから、私の信念は、自己サービスを可能にするために必要なソフトウェアエンジニアリングのレベルを簡素化できれば、同じ人がより多くのことを行うことができるため、より多くの価値を提供できるということです。

しかし、それが適切な方法で構築されている場合、これはHamiltonとDAGWorksのテーゼであり、時間の経過に伴ってものをより簡単に維持することができるので、誰かが去ったとしても誰もが悪夢を見ることはありません。それは、Stitch Fixでは、プロダクションに到達することは非常に簡単になっていましたが、ビジネスが非常に速いペースで進み、他のことがあったため、チームは半分の時間を機械学習パイプラインを維持するために費やしていました。

だからこそ、私は、あなたがもっともっとエンジニアリングをする必要がある場合に、それを可能にするソフトウェアエンジニアリングスキルのレベルについて、どう考えているか知りたいです。

Aurimas: 具体的に何を意味していますか？

Stefan: 自己サービスが将来だと言っているんですが、もし本当にそうなら、その自己エンジニアリングのスキルセットは何が必要なんですか？

Aurimas: 少なくとも私の考えでは、将来的には自己サービスが主流になると思いますが、現時点ではデータサイエンティストが端から端まで利用できるプラットフォームは存在しないと言えます。

私の経験から言うと、データサイエンティストとプラットフォームの間にまだ機械学習エンジニアが必要なのが実情です。しかし、現在のデータサイエンティストのスキルセットを持つ人が端から端まで作業できるようになることを目指すべきだと思います。それが私の考えです。

Piotr: それは種類の競争だと思いますね。6年前は難しかったことが今日では簡単になりましたが、同時に技術も複雑になっています。

例えば、私たちは今日、優れた基礎モデルやエンコーダーを持っています。私たちが構築しているモデルはますます他のサービスに依存しています。そして、データセット、前処理、トレーニング、後処理、モデルのパッケージング、独立したウェブサービスといった抽象化ではなくなるでしょう。

外部サービスにもますます依存するようになっています。ですので、もちろん自己サービスに対応することを目標にしていますが、この領域の技術と方法の発展により、種類の競争になると思います。私たちは何かを解決する一方で、別の複雑さを導入することになるでしょう。特に最先端のことをしようとする場合、最初に使いやすくすることを考えるのではなく、それができるかどうかを考えています。

新しい技術は通常、使いやすくはありません。一般的になってくると、使いやすくなるようにしています。

Stefan: 私は言いたいこと、または彼が言っていることを飛ばしてしまうかもしれませんが、APIを設計するために使っているテクニックの一つは、実際にはまずAPIを設計しようとすることです。

Piotrが言っていることは、エンジニアにとって非常に簡単です。私自身もこの問題に直面しました。下から上に進むことです。つまり、この機能を構築したいと思い、それをどのように利用するかを公開したいと思います。

しかし、私はそれを逆にすること、つまり最初にAPIを使用する人がどのような経験を得るのか、その経験から逆に考えることは非常に啓発的な経験だと思います。何ができるかを簡素化するためには、ボトムアップでこれらの懸念をすべて含めることは非常に簡単です。エンジニアの自然な傾向として、誰でも何でもできるようにすることを目指すからです。

しかし、物事を簡素化したい場合は、本当に次のような質問をする必要があります。つまり、80-20は何か？これはPythonの精神であり、バッテリーが含まれているということです。

どのようにすれば、可能な限り多くの人々が簡単に使用できるようにできるでしょうか？

最後の言葉

Aurimas: 同意します、実際に同意します。

時間が残りわずかですので、たぶん最後の質問、Stefanさん、何かアイデアをリスナーに提案したいですか？今がそのタイミングです。

Stefan: そうですね。

もし同僚の仕事を引き継ぐのが怖くてたまらない、または新しく会社に入る人で、引き継ぐパイプラインや自分が引き継ぐものに恐怖を感じている場合、私はあなたからの意見を聞きたいと思います。Hamiltonですが、まだ非常に初期のオープンソースプロジェクトです。非常に使いやすいです。私たちは入力と意見によって形作られるロードマップを持っています。モデルパイプラインをチームで維持し協力するための簡単な方法をお探しの場合は、ぜひご連絡ください。個々の人がモデルを構築する一方で、チームがそれを所有しているからです。

私はそれをうまくやるためには異なるスキルセットと規律が必要だと思います。だから、ハミルトンをチェックして、あなたの意見を教えてください。そして、DAGWorksプラットフォームからは、まだ現在のところクローズドベータ版になっています。プラットフォームを試してみたい場合は、ウェイトリスト、早期アクセスフォームに記入してください。

それ以外の場合は、ハミルトンを検索して、GitHubで星をつけてください。あなたの経験を教えてください。私たちはあなたのML ETLやパイプラインが成長するにつれて、メンテナンスの負担が増えないようにしたいと思っています。

ありがとうございました。

Aurimas: それでは、今日はここにいてくれてありがとうございました。本当に良い会話でした。ありがとうございました。

Stefan: Piotrさん、Aurimasさん、お招きいただきありがとうございました。

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