MailchimpにおけるMLプラットフォーム構築の教訓
「MLプラットフォーム構築の教訓：Mailchimpでの成功例」
この記事は、MLプラットフォームの専門家たちがデザインの選択肢、ベストプラクティス、具体的なツールスタックの例、そして最高のMLプラットフォームの専門家からの実世界の学びをディスカッションするショー、ML Platform Podcastのエピソードでした。
このエピソードでは、Mikiko BazeleyがMailchimpでMLプラットフォームを構築する過程で得た知識を共有しています。
YouTubeで視聴することができます：
または、ポッドキャストとして聴くこともできます：
- 大きな言語モデルの謎を解き明かす：初心者のためのロードマップ
- 「ChatGPT Visionのすごい活用方法」
- 「FC-CLIPによる全局セグメンテーションの革新：統一された単一段階人工知能AIフレームワーク」
しかし、もし文書のバージョンをご希望の場合は、以下にご用意しました！
このエピソードでは、以下のことについて学ぶことができます：
- 1 MailchimpにおけるMLプラットフォームと生成AIのユースケース
- 2 Mailchimpにおける生成AIの問題とフィードバックモニタリング
- 3 MLOpsエンジニアとしてビジネスに近づく方法
- 4 MailchimpでのMLプラットフォームの機能の成功事例
- 5 Mailchimpのゴールデンパス
米子ベイズリーとは
Aurimas: 皆さん、マシンラーニングプラットフォームポッドキャストへようこそ。今日は私、Aurimasがホストで、私と一緒にコホストを務めているのは、neptune.aiの共同創設者でCEOであるPiotr Niedźwiedźです。
本エピソードには、私たちのゲストであるMikiko Bazeleyが参加しています。Mikikoはデータコミュニティで非常に有名な人物です。現在、彼女は仮想的なフィーチャーストアであるFeatureFormのMLOpsの責任者です。それ以前に、彼女はMailChimpで機械学習プラットフォームを構築していました。
ここにいてくれて嬉しいです、Miki。自己紹介をお願いします。
Mikiko Bazeley: 詳細はまさにその通りです。私は去年10月にFeatureFormに参加し、その前はMailchimpのMLプラットフォームチームで働いていました。Intuitによる140億ドルの大規模な買収（あるいはそれに近いもの）の前後、手続き中にもメールチャンプにいました。とても楽しく、時にはカオスな時期でした。
しかし、それ以前には、データアナリスト、データサイエンティストとしての数年間の経験があり、初期段階のスタートアップ企業でMLプラットフォームデータエンジニアのような変わった役割も果たしていました。スタートアップ企業でのプラットフォーム構築は非常に難しいということを学びました。
そのため、正直に言うと、過去8年間、私はデータと機械学習の価値連鎖の上下で働いてきたと言えるでしょう。つまり、仕事の転職という洒落た言い方です。
データ分析からMLOpsエンジニアリングへの転職方法
Piotr: Mikiさん、元々はデータサイエンティストでしたよね？そして後に、MLOpsエンジニアになりました。タイトルにはあまりこだわらないと思いますが、あなたができることについて話すことを好まれると聞いています。しかし、あなたが行っていることはあまり一般的ではありません。
より分析的で科学的な役割から、よりエンジニアリング的な役割にどのように移行することができたのでしょうか？
Mikiko Bazeley: 多くの人々は私のバックグラウンドがコンピュータサイエンスではないことに驚かれます。私は実際にはデータサイエンティストの役割に移行する約1年前までPythonを使っていませんでした。
大学で勉強していたのは人類学と経済学でした。私は人々がどのように働いているのかを非常に興味深く思っていました。なぜなら、正直言って、私は人々がどのように働いているのか理解していませんでした。そのため、それが論理的な研究領域に思えました。
私は常に人々が意思決定をする方法に魅了されてきました。特に、グループでの意思決定ではどのような文化的な規範や社会的な規範があるのか、それを考えずに受け入れているのか、ということについてです。大学を卒業した後、最初の仕事は美容院のフロントデスクの仕事でした。
その時点では、私はプログラミングのスキルを持っていませんでした。
バイオスタットのためのRの授業を1つ受けたくらいで、ほとんど合格点くらいでした。知能や野望の問題ではなく、単にロードマップを理解していなかったのです。その種の変更をどのように行うか、プロセスを理解していませんでした。
最初の転機は成長オペレーションとセールスハッキングに向かうことでした-その時はシリコンバレーでは成長ハッキングと呼ばれていました。そして、このような転機を実現するための手順を開発しました。したがって、成長ハッキングからデータ分析、データ分析からデータサイエンス、そしてデータサイエンスからMLOpsに進むことができました。
データサイエンスからMLOpsエンジニアへの移行の鍵となる要素は、以下の通りです:
解決したい問題と取り組みたい問題に対する真の欲求を持つこと。私はいつも自分のキャリアに焦点を合わせています-「今日どの問題に取り組みたいか」、「1〜2年後にそれが面白いと思いますか？」
2番目の要素は非常に興味深いものでした。ある年には4つの仕事をしていました。データサイエンティストとして働きながら、2つのブートキャンプでメンタリングを行い、週末には不動産テックのスタートアップに取り組んでいました。
最終的には、パンデミック中にフルタイムで取り組むためにそれを辞めました。それは素晴らしい学びの経験でしたが、経済的には汗水で報酬を受けることが最善の解決策であるかどうかは分かりませんでした。でも大丈夫です-時には情熱に従う必要があります。自分の興味に従う必要があります。
Piotr: 決断に関して、私のコンテキストでは、まだ学生だった時を思い出します。私はテックから始めたので、最初の仕事はソフトウェアエンジニアとしてのGoogleのインターンシップでした。
私はポーランド出身で、Googleから通常のソフトウェアエンジニアとしてのオファーを受けたことを覚えています。月の給料は、私が1年間に費やす金額よりも高かったです。2倍か3倍の差がありました。
その瞬間にお金の流れに従うことは非常に魅力的でした。特にキャリアの初めの段階で、多くの人々が短期的に考える傾向があると思います。数ステップ先、数年先を見るという概念は、人々が欠けているものであり、結局はより良い結果につながることがあります。
私は常に、そのような決断がある場合に自問自答します。「もし1年後に失敗して幸せではなくなったら、別の選択肢を選ぶことはできるか？」と。そして通常、答えは「はい、できます」となります。
そのような決断は困難なものですが、正しい選択をしたと思います。情熱に従いましょう。この情熱がどこに導かれるのか考えてみてください。
技術的なギャップを埋めるのに役立つリソース
Aurimas: 私も非常に似たような経歴を持っています。私は分析からデータサイエンス、それから機械学習、データエンジニアリング、MLOpsにスイッチしました。
私にとっては、データエンジニアリングとクラウドエンジニアリング、DevOpsエンジニアリングが間に入る長い旅でした。
あなたはデータサイエンスから直接転向したのですよね。その「技術的な渓谷」と呼ぶべきものをどのように乗り越えましたか？MLOpsエンジニアになるためには技術的なギャップが必要です。
Mikiko Bazeley: はい、もちろんです。また、早期の不動産スタートアップでの仕事の一環でした。私はブートキャンプがとても好きです。大学を卒業した時、私のGPAは非常に悪かったです-非常に、非常に悪かったです。
ヨーロッパでは成績の採点方法が分かりませんが、アメリカでは通常4.0システムで評価され、私のGPAは2.4でした。それはアメリカの基準で非常に悪いとされることです。そのため、大学院や修士課程に戻る機会はありませんでした。
非常に興味深かったのは、その時点では6年ほど、AutodeskやTeladocなどの企業のエグゼクティブレベルのリーダーシップと一緒に働いていたことです。これらの企業は世界的には非常によく知られています-またはアメリカ国内で非常によく知られています。
Cレベルの人々が言ったことがありました。「大学院プログラムに入るためにあなたのために推薦状を書きますよ」。
そして、大学院プログラムでは、「申し訳ありませんが、やり直しのために大学に戻ってGPAを修正する必要があります」と言われました。私は「私は20代後半です。知識は高価です。そんなことはしませんよ」と言いました。
だから私はブートキャンプの大ファンです。
データサイエンティストの役割への移行と、その後のMLOpsエンジニアの役割への移行において、私を助けたのはブートキャンプの組み合わせでした。MLOpsエンジニアの役割への移行時には、フルスタックディープラーニングという有名なワークショップも受講しました。それはDimitriとJosh Tobinによって教えられ、彼らはGantryを立ち上げたことでも知られています。私はとても楽しんで参加しました。
私は時々、人々がブートキャンプに参加すると、それで仕事が見つかると思っている場合があると思いますが、実際にはそうではありません。それは単に非常に構造化された、加速された学習形式です。
私がそれらの移行の両方で助けを得たのは、本当にメンター関係に投資することでした。たとえば、データ分析からデータサイエンスに転換する最初の時には、当時の私のメンターはRajiv Shahでした。彼は現在、Hugging Faceのデベロッパーアドボケートです。
それ以来、私はいくつかのブートキャンプでメンターを務めてきました。多くの場合、学生たちは「ああ、私のプロジェクトの評価を手伝ってくれない？」と言って接触してくることがあります。
しかし、それは業界のメンターを最大限に活用するための高価値な方法ではありません。特に、Rajiv Shahのような資格を持つ場合はそうです。
フルスタックディープラーニングコースでは、素晴らしいTAもいました。私は彼らにプロジェクトを採点してもらうために自分のプロジェクトを披露しました。しかし、データサイエンティストになる際には、Rajiv Shahに次のような質問をしました：
- マーケティングでモデルの可読性をどのように行うのか？CMOが予測を作成して結果を予測するように求めている場合。
- このモデルを本番環境にどのように展開するのか？
- データサイエンスのプロジェクトに対してどのように支持を得るのか？
- 既に持っているスキルをどのように活用するのか？
そして、それに技術スキルを組み合わせました。
私はMLOpsプラットフォームの役割でも同じことをしました。以下のような質問をしました：
- このコースでは学べないことは何ですか？
- どのようにポートフォリオを構築するのか？
- これらのギャップを埋めるにはどうすればいいのか？
私はいくつかの組み合わせでスキルを開発しました。
構造化されたカリキュラムを持つ必要がありますが、また、MLシステムの開発における多くの問題に触れるためのプロジェクトも持つ必要があります。
ブートキャンプのメンターを探しています
Piotr： メンターについてお話しいただいていますが、メンターはブートキャンプで見つけたのですか？それとも他の方法で見つけましたか？どのような仕組みですか？
Mikiko Bazeley： ほとんどのブートキャンプでは、正しいものを選ぶことが重要です。私はデータサイエンスへの移行にはSpringboardを選びました。そして、MLOpsの役割への移行でもそれを少し利用しましたが、フルスタックディープラーニングコースと独学と研究にも重点を置きました。
MLOpsのためのSpringboardのコースは終了しませんでした。なぜなら、その時点でMLOpsエンジニアの役割について4、5つの異なる企業から数件の仕事のオファーをもらっていたからです。
ブートキャンプ後の仕事探しとソーシャルメディアの存在感
Piotr： そして、ブートキャンプのおかげなんですか？というのも、多くの人々が就職のためにブートキャンプを利用していると言っていました。あなたの場合はどうでしたか？
Mikiko Bazeley： ブートキャンプ自体は私を採用マネージャーと繋げることはありませんでした。しかし、公開されたブランディングを持っていることが重要です。
私は確実にインフルエンサーではないと思います。なぜなら、私はそのような規模のオーディエンスを持っていませんから。私が実際にやっているのは、ポッドキャストの参加者の中にいる多くの人々と非常に似た方法で、自分の学びを人々と共有しようとすることです。私は自分の経験を受け入れ、「これらの種類のことが起こるかもしれませんが、こう対処することもできる」というようにフレームに沿って提示しようとします。
私は、公に建物を建て、その学習を共有することが、私が仕事を見つける上で非常に重要だったと思います。MLOps側やMLエンジニア側を特に見ると、これらの求職者がたくさんいます。
彼らをよく見かけます。データサイエンス、機械学習、Java、Python、SQL、またはブロックチェーン、コンピュータビジョンなどのヘッドラインがあります。
これは2つのことです。まず、彼らは自分のLinkedInプロフィールをウェブサイトのランディングページとして扱っていません。しかし、結局のところ、それが実際のところですよね？ランディングページを適切に扱い、訪問者を引きつけることができれば、ウェブサイトやSaaS製品と同様に訪問者を保持することができます。
しかし、さらに重要なことは、実際に人々と交流することです。人々と情報を共有する必要があります。
だから、私がブートキャンプを通っているとき、私は基本的にそれをやっていました。学んだことやプロジェクトで取り組んだことを組み合わせて、それを公に共有するだけです。
本当に興味を持つように努力しました。使い古された言葉かもしれませんが、興味深い人は興味があります。あなたは周りの問題、人々、解決策に興味を持たなければなりません。人々はそれに共感することができます。Chat GPTやGen AIの人々のようにただフェイクをしている場合は、中身がないフェイクですので、人々はつながることができません。
本当の興味を持ち、それに何かを持っている必要があります。私はそれをどうやって行ったのでしょう。ほとんどの人はそれをしないと思います。
Piotr：もう1つの要素が必要ですね。私はそれを共有するときに苦労しています。私はさまざまなことを学んでいますが、一度学ぶと、それは当然のことのように聞こえ、たぶんそれがあまりにも当たり前なのではないかと恥ずかしくなります。それから、もっと洗練されたものを共有するのを待とうと思います。しかし、それは決して来ません。
Mikiko Bazeley：詐欺師の症候群ですね。
Piotr：そうです。それを取り除かなければなりません。
Mikiko Bazeley：オーリマスさん、あなたは詐欺師の症候群から解放されたと感じていますか？
Aurimas：いいえ、決して解放されません。
Mikiko Bazeley：私も解放されません。ただ方法を見つけるだけです。
Aurimas：私が投稿するすべてのことを、他の人の時間に値するものとは思わないでしょうが、それはそう思われるようです。
Mikiko Bazeley：まるであなたが最悪の自然状態を回避するためのものを設定しなければならないようなものです。すべての不安要素をだますようにする必要があります。健康的な食事とワークアウトのようなものです。
FeatureFormと他のタイプの特徴ストアについて
Aurimas：少し現在の仕事について話しましょう、ミキ。あなたはFeatureFormのMLOpsの責任者です。かつて、私はFeatureFormのCEOと話す機会があり、その製品について良い印象を受けました。
FeatureFormとは何ですか？FeatureFormは、現在の特徴ストア市場とはどのように異なるのですか？
Mikiko Bazeley：そこに存在するさまざまなタイプの特徴ストアを理解し、FeatureFormがカテゴリー的には仮想特徴ストアという名前はあまり適切ではないことを理解することに関係していると思います。
3つのタイプの特徴ストアがあります。興味深いことに、それらはMLOpsの波とほぼ対応し、異なるパラダイムの開発方法を反映しています。
3つのタイプは：
- 1リテラル
- 2物理的
- 3仮想
ほとんどの人はリテラル特徴ストアを直感的に理解しています。リテラル特徴ストアは、文字通り特徴を保存し（定義と値を含む）、それらを提供します。それがほとんどです。非常に特化したデータストレージソリューションのようなものです。
例えば、Feast。Feastは文字通りのフィーチャーストアです。実装が容易で、リスクが低い軽量なオプションです。基本的には変換やオーケストレーション、計算は行われません。
Piotr: ミキさん、もしよければ、なぜ軽量なのでしょうか？ 文字通りのフィーチャーストアは、ストレージの代わりとなるものなのですか？
Mikiko Bazeley: 軽量というのは、Postgresのように実装するという意味です。技術的には、そんなに軽量ではありませんが、物理的なフィーチャーストアと比較すると、スペクトラム上で軽量です。
物理的なフィーチャーストアには次のようなものがあります：
- フィーチャーを保存する
- フィーチャーを提供する
- フィーチャーをオーケストレーションする
- 変換を行う
その意味では、物理的なフィーチャーストアは実装、メンテナンス、管理の面で重いと言えます。
Piotr: スペクトラム上では、物理的なフィーチャーストアが最も重いのですね？
そして、文字通りのフィーチャーストアの場合、変換は別の場所で実装されてから保存されるのですか？
Mikiko Bazeley: はい。
Aurimas: フィーチャーストア自体は、基本的にはストレージに対してアクションを実行するライブラリですよね？
Mikiko Bazeley: そうですね、ほとんど実装の詳細ですが、大抵はそうです。例えば、Feastはライブラリです。さまざまなプロバイダーが付属していて、選択肢があります。
Aurimas: S3、DynamoDB、またはRedisに対して構成することができますね。重さという点では、ストレージ上の薄いライブラリであること、ストレージ自体を管理することから来るのでしょう。
Mikiko Bazeley: まさにその通りです。
Piotr: つまり、バックエンドは存在しないということですか？このフィーチャーストアに関するメタデータを保存するコンポーネントはありませんか？
Mikiko Bazeley: 文字通りのフィーチャーストアの場合、フィーチャーとメタデータを保存するだけで、変換やオーケストレーションの重い処理は実際には行いません。
Piotr: それでは、仮想フィーチャーストアとは何ですか？物理的なフィーチャーストアは理解できますが、仮想フィーチャーストアについては興味があります。
Mikiko Bazeley: そうですね、仮想フィーチャーストアのパラダイムでは、両方の良い点を結合しようとします。
異なるタイプのフィーチャーストアにはそれぞれ使いどころがあります。物理的なフィーチャーストアはUberやTwitter、Airbnbなどの企業から生まれました。彼らはストリーミング形式で大量のデータを処理する際に問題を解決しました。
物理的なフィーチャーストアの課題は、プロバイダーや彼らの選択したプロバイダーに固執されてしまうことです。実際には置き換えることができません。例えば、物理的なフィーチャーストアでCassandraやRedisを使用したい場合、それはできません。通常、提供されるものを使うしかありません。それはまるで専用のデータ処理およびストレージソリューションのようなものです。
仮想フィーチャーストアでは、提供者を置き換えることができる文字通りのフィーチャーストアの柔軟性を取り入れようとします。例えば、BigQueryやAWS、Azureを使用することができます。
仮想フィーチャーストアが重視するのは、バージョン管理やドキュメンテーションおよびメタデータ管理、提供だけでなく、変換のオーケストレーションといった実際のフィーチャーストアの解決すべき問題です。
例えば、FeatureFormでは、それを行うためにKubernetesにネイティブです。ほとんどの場合、データサイエンティストは別の場所で変換を行いたくないと仮定しています。通常はPython、SQL、PySpark、データフレームなどで行いたい処理を行いたいということです。
彼らは単に、たとえば、デコレータで特徴をラップしたり、クラスとして書いたりできるようにしたいのです。 インフラ面について心配する必要はありません。 全ての素敵な構成を提供したり、本番へのパスを見つけたりする必要はありません。 これらをなるべくすっきりと簡単にする必要があります。
アイデアは、新しいデータサイエンティストがチームに参加することです…
皆さんはこれを経験したことがあります：新しい会社に行くと、基本的に最初の３ヶ月はConfluenceでドキュメントを探すのに時間を費やします。この予測と離反プロジェクトについて、人々のSlackチャンネルを読むことで確認しようとします。
データを追いかけます。クエリが壊れていることに気付き、「これは一体何を考えていたのか」と思います。
それからリーダーがやってきて、「あ、ちなみに数字が間違ってるよ。 これらの数字を教えてくれたけど、変わったんだ」と言います。 そして、「おお、ラインエージが必要だ。ああ、追跡が必要だ」と思います。
現在、多くの企業にとって厄介なのは規制です。ヨーロッパで事業を行う企業は、GDPRに従わなければなりませんが、これは大きな問題です。 しかし、アメリカの多くの医療会社は、たとえば医療や健康関連の企業であるため、HIPAAの下にあります。 したがって、多くの場合、弁護士がMLプロセスに関与しています。 ほとんどの人はこれに気づいていません。
エンタープライズの空間では、弁護士が、訴訟や新しい規制に直面した場合、どの特徴が使用され、どのモデルが使用されているかを追跡できるかというような問題に直面することがあります。 したがって、私たちは仮想フィーチャーストアのパラダイムでこのようなワークフローの解決を本当に目指しています。
これは、データサイエンティストがフィーチャーエンジニアリングを行う際に、つまりデータサイエンスプロセスの中で最も重要で集中的な部分であるフィーチャーエンジニアリングを行う際に、すでに非常に困難な作業に新しい言語を学ばなくてもすむようにすることです。
より広範なアーキテクチャの中の仮想フィーチャーストア
Piotr: では、ミキ、２つの視点から見てみましょう。 管理者の視点から見ると、テックスタックの一部として仮想フィーチャーストアを展開する場合、S3やBigQueryのようなストレージが必要です。 計算を実行するためのインフラストラクチャも必要です。 これはKubernetesが運用するクラスタであるか、別の何かによって提供されます。 そして、仮想フィーチャーストアは、ストレージと計算コンポーネントの上に抽象化されたものです。
Mikiko Bazeley: そうですね、実際に私たちはData Councilで講演を行いました。私たちは「マーケットマップ」と呼んでいるものを公開しましたが、これは実際には正確ではありません。私たちは、MLスタック、アーキテクチャがどのように見えるべきかについての図を公開しました。
私たちは、計算とストレージを持っていると考えていますが、これは各チームで実行されるものです。これらは、むしろMLの関心事ではなく、eコマースのウェブサイトを実行するために計算とストレージが必要です。したがって、私たちはこのeコマースのウェブサイトを例に挙げます。
その上の階層では、プロバイダが存在し、多くの人々にとって（たとえば、個々のデータサイエンティストの場合は）機械学習モデルに対してGPUへのアクセスが必要です。Sparkを使用したい場合がほとんどです。さらに、ここにはその他の提供者も含まれます。 ここで、MLの問題の少しの違いが見えてきます。
その下には、Kubernetesもあるかもしれません。なぜなら、それが会社全体のオーケストレーションをしている場合もあるからです。 したがって、仮想フィーチャーストアは、例えばSpark、Inray、Databricksといったものの上に配置されます。
ただし、それ以上に、中規模の企業などで見られるようになってきているのは、彼らのMLシステムに関する素晴らしい説明を公開している人々です。たとえば、Shopifyが「Merlin」についてのブログ記事を公開しました。 DoorDashもいくつかの非常に良い記事を公開していると思います。
しかし、現在では、人々は私たちが統一されたMLOpsフレームワークと呼ぶものにも注目し始めています。それは、あなたがZenMLなどの統一されたMLOpsフレームワークとDatabricks、Sparkなどのプロバイダーの間に仮想特徴ストアが位置するというものです。それ以下にはKubernetesとRayがあります。
エンドユーザーの視点から見た仮想特徴ストア
Piotr: これはすべてアーキテクチャの視点からの話でした。エンドユーザーの視点についてはどうでしょうか？特徴ストアのエンドユーザーとして、少なくとも一人はデータサイエンティストであると思います。データサイエンティストは仮想特徴ストアとどのように対話するのでしょうか？
Mikiko Bazeley: 理想的には、対話は最小限に留めると言えます。Gitを使用するのと同じように使うことができます。私たちの原則は、人々が正しいことを簡単に行えるようにすることです。
私がMailchimpにいたときに私のチームのスタッフエンジニアとテックリードから学んだことの一つは、前向きな意図を前提とするということです。これは素晴らしい指針だと思います。ML/MLOpsエンジニア、ソフトウェアエンジニア、データサイエンティストの間には、時々奇妙な敵意が存在すると感じることがあります。「ああ、データサイエンティストはコーディングが下手で、ひどい人たちだ」というような感じです。
その後、データサイエンティストはDevOpsエンジニアやプラットフォームエンジニアを見て、「なぜあなたは常に非常に悪い抽象化や本当にリークの多いAPIを作り出し、私たちがただ仕事をするのがとても困難になるのですか？」と考えます。ほとんどのデータサイエンティストは、インフラには興味がありません。
もし彼らがインフラに興味を持っているならば、それは彼らがMLOpsエンジニアを目指して訓練中であることを意味します。新たな旅への一歩です。
すべてのMLOpsエンジニアは、「ああ神よ、私はパイプラインのデバッグやトラブルシューティングをしようとしていました」とか、「ああ神よ、私はJupyterノートブックやピクルモデルを持っていたのに、会社にはデプロイインフラがなかった」というような話をすることができます。それが毎回のミッションのスタートです。
対話の面では、データサイエンティストはSparkクラスタなどのインフラ設定を行う必要はありません。必要なのは認証情報のみであり、それを設定ファイルに入力するだけです。その時点では、FeatureFormで「登録」という用語を使用しますが、実際にはデコレータを使用します。彼らは「これらのデータソースを使用しています。これらの特徴を作成しています。これらのトレーニングデータセットを作成しています」といったタグを追加する必要があります。当社ではバージョニングを提供し、特徴は第一級の不変のエンティティまたは市民であると述べており、同じ名前の特徴を書き換える心配や特徴を上書きすることはありません。
たとえば、同じロジックで作業している2人のデータサイエンティストがいるとしましょう。彼らは電子商取引の例で顧客の生涯価値の予測を行っているかもしれません。おそらく「顧客の旅の最初の3ヶ月に使われるお金」やどのキャンペーンを経由してきたかなどです。同じロジックで作業する2人のデータサイエンティストが提出しても、バージョンが異なっていれば、両方がその特徴にログとして記録されます。
これにより、トラッキングとラインエージも提供することができます。私たちは変換を具現化しますが、実際の特徴データは保存しません。
データセットと特徴のバージョニング
Piotr: Miki、質問です。デコレータという言葉を使用しましたが、私の思い浮かぶデコレータはPythonのデコレータです。ここではPythonのことを話しているのでしょうか？
Mikiko Bazeley: はい！
Piotr: 特徴にはバージョンがあると言いましたが、概念的にはデータセットはサンプルの集合ですよね？そして、サンプルは多くの特徴から構成されています。特徴ストアではデータセットのバージョンも付けるのでしょうか？
ミキコ・ベイズリー： はい！
ピオトル： では、バージョン管理されたフィーチャーの間を接着するためにはどのような方法がありますか？データセットをどのように表現できますか？
ミキコ・ベイズリー： データセット自体はバージョン管理しません。ソースをバージョン管理し、そのソースにはフィーチャーも含まれるという理解を持っています。フィーチャーは他のモデルのソースとして使用できるという考えです。
「DVC」といったツールを使用して、FeatureFormを利用することができます。これは何度か出てきた話題です。私たちは、完全なデータセットのバージョン管理にはあまり興味がありません。例えば、ソースにはテーブルやファイルを利用することができます。もし人々がそのソースやテーブル、ファイルに修正を加える場合、それをバリエーションとしてログに記録することができます。そして、それらを追跡します。しかし、それが本当の目的ではありません。
私たちは、より多くの注意をフィーチャーエンジニアリング側に向けたいと考えています。そのために私たちが行うのは、定義のバージョン管理です。すべてのフィーチャーは値と定義の2つのコンポーネントで構成されます。FeatureFormで純粋な関数を作成するので、私たちが保存している定義に対して同じ入力を与え、変換を行えば、理想的には同じ出力が得られるはずです。
アウリマス： フィーチャーストアの後ろに機械学習パイプラインを接続し、データセットを取得する場合、すでに事前計算された一連のフィーチャーがフィーチャーストアに保存されています。そのためには、エンティティIDのリストを提供する必要があると思いますが、これは他のフィーチャーストアと同様ですか？つまり、バージョン管理されたフィーチャーとソースが再現可能なセットになるように、エンティティIDリストと計算ロジックをバージョン管理するということです。
このように行うべきですか、それとも他にアプローチ方法がありますか？
ミキコ・ベイズリー： 質問を再度確認させてください。
基本的には、正確な結果を再現できるか、どのようにすればそれが可能になるか、ということを尋ねているのですね。
アウリマス： 学習ランの場合、はい。
ミキコ・ベイズリー： 確かに、私は以前に述べたことになりますが、データセットやデータ入力そのものはバージョン管理しません。私たちは変換をバージョン管理します。実際のロジックに関しては、個々のフィーチャーを登録することもできますが、それらのフィーチャーをラベルと一緒に結びつけることもできます。
私たちが保証するのは、開発フィーチャーに対して書いたものとまったく同じロジックが本番環境で反映されるということです。そして、それを私たちのサービングクライアントを通じて実現します。入力の保証に関しては、私たちは企業として、「ねえ、そんなに多くのツールがある。」と言っています。
それがバーチャルフィーチャーストアの哲学です。MLOpsの初期の段階では、「どれくらい速くできるか？」、「スループットはどうなっているか？」、「レイテンシーは？」といった低レベルの問題を解決していましたが、私たちはそこには焦点を当てません。私たちにはそれに集中する必要はないと考えています。
代わりに、私たちは難しいと言われている部分に注力しています。例えば、トレーニングとサービングのズレを最小限に抑えること、特に使用されているロジックを標準化することでそれを実現します。データサイエンティストはトレーニングパイプラインをパイプライン内で書いたり、Spark、SQLなどで書き直す必要がないようにします。これは再現性の保証とは言えませんが、少なくとも大いに役立つところです。
エンティティIDに関しては、例えばフロントエンドチームからAPIコールとしてエンティティIDを取得します。エンティティIDがフィーチャーや呼び出しているフィーチャーと同じバージョンである限り、同じ出力を得ることができます。
これが私たちが聞いたユースケースの一部です。例えば、異なるロジックをテストしたい場合、次のようなことができます：
- 異なるバージョンのフィーチャーを作成する
- 異なるバージョンのトレーニングセットを作成する
- データの1つのバージョンを異なるモデルに供給する
異なるモデルのパフォーマンスやフィーチャーの優れた部分を調査し、最も優れたモデルに戻すことができます。
フィーチャーストアの価値
ピオトル： まとめると、フィーチャーストアがMLチームのテックスタックにもたらす価値は、フィーチャーエンジニアリングのバックエンドのロジックのバージョン管理ですか？
特定の特徴量のバージョン付きロジックを持っていて、モデルのトレーニングに使用する場合、ソースデータへのポインタまたは特定の特徴量を計算するために使用されるソースデータへのポインタをどこかに保存することになります。これにより、基本的にはデータセットのバージョニングが行われます。
そのためには、ソースデータを持っている必要があり、それをどのようにバージョン管理するか、さらには元のデータを処理し、特徴量を計算するためのロジックもバージョン管理する必要があります。
ミキコ・ベイズリー：私が提案する価値命題の3つまたは4つの主要なポイントは、間違いなくロジックのバージョニングです。2つ目はドキュメンテーションで、これは非常に重要な要素です。誰かがなぜ特定のロジックを選んだのか全く理解できないという経験を誰もがしたことがあると思います。例えば、セールスパイプラインで顧客や契約価値を表すロジックなどです。
バージョン管理、ドキュメンテーション、変換、オーケストレーションがそれです。私たちは「一度書いて2回提供する」と言っています。その保証を提供しています。また、オーケストレーションの側面と同様に、スケジュールなどもあります。しかし、これらは3つの主要な要素です：
- バージョニング、
- ドキュメンテーション、
- 変換によるトレーニングサービスのスキューの最小化。
これらは私たちに頻繁に要求される3つの大きな要素です。
FeatureFormにおける特徴量のドキュメンテーション
ピオトル：ドキュメンテーションはどのように機能しますか？
ミキコ・ベイズリー：ドキュメンテーションには2つのタイプがあります。コードを通じたドキュメンテーションと補助的なドキュメンテーションがあります。
たとえば、補助的なドキュメンテーションには、docstringなどがあります。関数のロジックや用語の意味などを説明することができます。私たちはそれを提供しています。
ただし、コードを通じて可能な限りドキュメントを作成することも重要です。たとえば、特徴量のバージョンやトレーニングセット、使用されているソースのバージョンをリストする必要があります。作成されるリソースのタイプを明確にすることも重要です。少なくともFeatureFormの管理されたバージョンでは、ガバナンス、ユーザーアクセス制御なども提供しています。特徴量の系譜も提供しています。たとえば、特徴量をそれと一緒に使用されているモデルにリンクすることができます。私たちは、可能な限りコードを通じたドキュメンテーションを取り入れようとしています。
私たちは常に、補助的なドキュメンテーションのためにダッシュボードの機能を拡張できるさまざまな方法を模索しています。また、MLライフサイクルやMLチームのメンバー（MLOpsエンジニア、データサイエンティストなどの明確なメンバーだけでなく、弁護士などの非明確なメンバーも含む）が、どの特徴量がどのモデルで使用されているかを見える化し、アクセスできるようにするための別の方法を考えています。これらは私たちが提供しているさまざまな種類のドキュメンテーションです。
MailchimpのMLプラットフォームと生成AIのユースケース
アウリマス：FeatureFormのMLOps責任者として参加する前、あなたはMailchimpで機械学習オペレーションエンジニアとして働いており、そこでMLプラットフォームの構築に携わっていましたね。Mailchimpでのデータサイエンティストと機械学習エンジニアが解決していた問題は何でしたか？
ミキコ・ベイズリー：いくつかの問題がありました。Mailchimpに入社したとき、すでにプラットフォームチームが存在していました。非常に興味深い状況で、MLOpsとMLプラットフォームの問題は大まかに3つのチームに分かれていました。
- 私が所属していたチームは、データサイエンティストの開発およびトレーニングのためのツールの作成と環境の構築、実際の本番化作業への協力に焦点をあてていました。
- ライブモデルの提供に焦点を当てたチームがありました。
- 常に進化していたチームもありました。データの統合から始まり、MLモニタリングチームとして進化しました。私が辞めて以来、そのような役割のままです。
全体的に、すべてのチームで解決しようとしていた問題は、「Mailchimpのデータサイエンティストに対して、彼らが取り組んでいるさまざまなプロジェクトに対して、どのように受動的な本番化を提供するか」ということでした。
たとえば、商業的な価値がある場合に、生成AIのための強力なユースケースがある企業の場所として、Mailchimpを見つけました。生成AIの機能を持つ企業が出てきた場合、私がそれを基準に評価する企業はMailchimpです。とても強力なユースケースがありましたから。
Aurimas: コンテンツの生成でしたか？
Mikiko Bazeley: そうですね、まさにその通りです。Mailchimpが何のために使われているかを理解すると、より良い文脈が得られます。
Mailchimpは20年以上の歴史を持つ会社で、本社はジョージア州アトランタにあります。たくさんのお金で買収された理由の一部は、メールマーケティングソリューションから始まり、アメリカ最大のメールリストを持っているからです。しかし、ほとんどの人が知らないと思いますが、最近数年間で、彼らは小規模なVoAGIサイズのビジネスがeコマースを行いたいという需要に応えるために、大きな動きをしています。
メールマーケティングはまだ大きな要素です。そのため、NLPはもちろん非常に重要な要素です。しかし、彼らはまた、ソーシャルメディアのコンテンツ作成、仮想デジタルウェブサイトなども提供しています。彼らは実質的には小さなVoAGIサイズのビジネスのフロントエンドCRMとして位置付けようとしています。彼らはIntuitによって買収され、Intuitのバックオフィス業務（たとえば、QuickbooksやTurboTax）のフロントエンドになりました。
その文脈に基づくと、Mailchimpの目標はマーケティングを提供することです。つまり、小さなママ＆パパのお店が行う必要のあることです。Mailchimpはこれを簡単にし、自動化することを目指しています。
彼らが取り組んでいた生成AIの強力なユースケースの一つは次のとおりです：仮にあなたがTシャツショップやキャンドルショップを経営する小さなビジネスオーナーで、あなたが主事業者であるか、2、3人の従業員がいるかもしれません。あなたのビジネスはかなりスリムで、フルタイムのデザイナーやマーケティング担当者を雇う余裕はありません。
Fiverrに頼むこともできますが、ホリデーセール用のメールを送信する必要があることもあります。
それは低価値な仕事かもしれませんが、請負業者を雇うと多くの手間とお金がかかるでしょう。Mailchimpが提供するクリエイティブスタジオのプロダクトまたはサービスを通じて、彼らは次のようなことを提供していました。
そして、Leslieが言います。「ねえ、さて、テンプレートをいくつか作って」と。
キャンドルショップのLeslieは、ホリデー用のメールを送りたいとします。彼女ができることは、クリエイティブスタジオに行って、「ここに私のウェブサイトやショップなどがあります。私のブランドを考慮して、多くのメールのテンプレートを生成してください」と言うことです。最初に行われることは、メールのためのスタジオ写真とカラーパレットの生成です。
それからLeslieが言います。「さて、私のブランドを考慮したホリデーメールのテンプレートをいくつか作ってください」と、彼女の話し方やトーンを指定します。そして、彼女のショップに関する他の詳細もリストされます。そして、もちろん、メールの本文も生成されます。次に、Leslieは言います。「いくつかバージョンを作って、メールのA/Bテストができるようにしてください」。それを実現してくれます。
なぜこれが強力なビジネスユースケースだと思うかというと、Mailchimpは最大のプロバイダーです。私は意図的にメールのプロバイダーとは言わないでおきます。彼らはメールを提供していません。彼らは～
Piotr: 送信者ですね？
Mikiko Bazeley: そうですね、彼らは最大のセキュアなビジネスメールプロバイダーです。したがって、Leslieは既に構築されたメールリストを持っています。彼女はいくつかのことをすることができます。メールリストはセグメント化されています。それもMailchimpが提供しているものです。Mailchimpでは、ユーザーが独自にカスタマイズできるトリガーに基づいたキャンペーンを作成することができます。それには素晴らしいUIが用意されています。さて、Leslieは3つのメールリストを持っています。充実した支出者、VoAGI支出者、そして低支出者です。
彼女は異なるメールテンプレートをそれぞれのリストに接続することができ、彼女のビジネスに直接関連しているエンドツーエンドの自動化を実現しています。私にとって、これは強力なビジネス価値提案です。それは20年間にわたって彼らが取り組んできた製品と戦略によって「防御堀」を築いてきたためです。
彼らが提供する生成AIの機能は、彼らのミッションステートメントと直接一致しています。それが製品ではありません。その製品は、「既に10,000通のメールリストとウェブサイト、ショップとの相互作用を持っている、小規模またはVoAGIサイズのビジネスオーナーの生活を非常に簡単にする」というものです。さらに、彼らはセグメンテーションと自動化の機能も提供していますが、通常はZapierやその他の提供業者に行く必要があります。
私は、メールチンプは新しい波から大いに恩恵を受けていると考えています。他の多くの企業には当てはまらないと言えます。私がそこにいた時、MLプラットフォームエンジニアとしてそれを見るのはとてもエキサイティングでした。なぜなら、それは単に多様なモデルのアンサンブルパイプラインではなく、生成AIやLLMのテストや検証にも早期に取り組む機会を提供してくれたからです。
例えば、システムやモデルのパイプラインにそれらがある場合、実際に評価するにはどうすればよいのでしょうか？どのようにモニタリングすればよいのでしょうか？多くのチームが実際に間違っている大きな問題は、データ製品のモデルへのフィードバックです。
企業やチームは、それをどのように統合してデータサイエンス・機械学習の取り組みを豊かにし、提供できる製品をさらに充実させるかを本当に理解していません。
Piotr: ミキ、おかしな結論だけど、私たちが祝日に企業から受け取る挨拶は、個別のものではないばかりか、テキストの本文さえも人間によって書かれていないんだよ（笑）。
Mikiko Bazeley: でも、それは個別のものなんだよ。あなたのペルソナに合わせて個別化されているんだから。
関連するポッドキャストエピソード
Jason Flaksとの対話型AI製品の本番展開
詳しくはこちら
メールチンプにおける生成AIの課題とフィードバックのモニタリング
Piotr: 確かに。とにかく、興味深いことを言ったね。「企業はフィードバックデータの扱い方を知らない」と。生成AIのような問題では、フィードバックがより構造化されていないため、それはさらに困難です。
Mailchimpではどのように行われたのか、共有してもらえますか？どのようなフィードバックであり、チームはそれをどのように扱っていたのですか？どのように機能していたのですか？
Mikiko Bazeley: 去った時には、モニタリングの取り組みが始まったばかりでした。Mailchimpの文脈を理解することは役立ちます。彼らは20年の歴史を持つ私的所有会社であり、VCの資金援助を受けたことはありません。
彼らはまだ賃貸の物理データセンターを所有しており、サーバーラックも所有しています。彼らはクラウドへの移行を比較的短期間前に始めたばかりで、おそらく8年前かそれに近い時期です。
これは、一部の企業が考えるべき素晴らしい決断です。会社全体をクラウドに移行する代わりに、Mailchimpは「今のところ、データサイエンスと機械学習の取り組み、それをサポートするために必要なデータエンジニアなどは、レガシースタックのままにしておく」と言いました。
そして、彼らは徐々にシャードをクラウドに移行し、評価しました。私たちは民営で明確なノーススターを持っていたため、テクノロジーの決定を四半期ではなく年単位で行うことができました – 他の一部のテック企業とは異なります。
フィードバックに関しては、それは製品データから生成されるフィードバックです。そのうち多くは、コアのレガシースタックの中にありました。
データサイエンス/機械学習組織のデータエンジニアの主な役割は、データを移行し、レガシースタックからGCPにデータをコピーすることでした。GCP上のデータサイエンス/機械学習専門家たちのスタックは、BigQuery、Spanner、Dataflow、そしてAI Platform Notebooks（現在はVertex）でした。また、Jenkins、Airflow、Terraformなども使用していました。
ただし、データサイエンティストと機械学習の専門家にとっては、データの遅延は約1日ありました。
その時点では、物事をするのが非常に難しかった。私たちはライブサービスモデルを作ることができましたが、それは非常に一般的なパターンでしたが、多くのモデルはオフラインでトレーニングを受ける必要がありました。私たちはそれらをライブサービスにして、APIエンドポイントを公開しましたが、1〜2日の遅延がありました。
と言っても、彼らが取り組んでいたのは、例えば…これは製品との緊密な統合が必要な場所です。
例えば、フィードバックの一つは、「キャンペーンを作成する」というものでした – これを私たちは「ジャーニービルダー」と呼んでいます。中小規模ビジネスのオーナーやVoAGIのCEO、CFO、CMOなどは、すべてをやっています。彼らは「これは実際には複雑です。キャンペーンをどのように構築すればいいですか？」と言います。このフィードバックは製品を通じて入ってきたものです。
そのプロジェクトのデータサイエンティストは、「オーナーがキャンペーンで次に取るべき3つのステップまたはアクションに対する推奨を与えるモデルを構築する」と言いました。それから私たちはみんな、データエンジニアと協力して、「このデータを入手できるか？」と話し合いました。
ここでも、法務の役割が出てきて、「法的制限はありますか？」という形で出てきます。そして、それをモデルで使用できるデータセットに取り入れるために実現することです。
Piotr: このフィードバックは、ユーザーが示すニーズに基づくもので、データではないですよね？
Mikiko Bazeley: でも、両方が必要だと思います。
Aurimas: そうですね。
Mikiko Bazeley: 私はデータフィードバックを製品とフロントエンドチームなしで行うことはできないと思います。たとえば、フィードバックを共有する場所は非常に一般的ですね。または、Twitterの広告などでも同様です。
「この広告はあなたに関連していますか？」と尋ねることができます。それは「はい」か「いいえ」です。これはUIでそのオプションを提供するのは非常に簡単です。そして、多くの人々は、データフィードバックの実装が非常に簡単だと思っています。私が「簡単」と言うと、実験設計の強い理解が必要であることは否定しませんが、A/Bテスト、予測、モデルなどの多くのツールがあります。それから、結果をテーブルに書き込むだけです。それは実際には難しいことではありません。実際の難しさは、異なるエンジニアリングチームがそれに署名すること、それを設定することに同意することです。
それができたら、実験、ウェブサイト、それに関連付けられたモデルがあると、データの部分は簡単ですが、製品の購買意欲を得ること、またはエンジニアリングやビジネスチームにデータセットの豊かさに戦略的な価値があることを示すことが難しいと思います。
例えば、私が先週参加した Data Council では、生成AIのパネルディスカッションがありました。その議論から得られたことは、退屈なデータとML基盤の重要性です。それらはますます重要になります。
高品質な学術データセットがなくなってきているということです。つまり、ウェブ上のデータセットでデータが不足したときはどうなるのかということです。その場合、ファーストパーティのデータ – つまり、ビジネス自体が所有し、制御できるデータに戻るということです。
Googleが「サードパーティデータの追跡機能を廃止する」と言った時も同じ議論がありました。多くの人々が驚いていました。データフィードバックの収集を構築し、機械学習の取り組みと合わせるなら、心配する必要はありません。しかし、OpenAI APIのようなものに対して薄い包装をしている企業であれば、他の誰も提供できない価値を提供していないため、心配する必要があります。
ML基盤も同様ですね？
MLOpsエンジニアとしてビジネスに近づく
Piotr: 基準は上がりましたが、競争するためには、何か独自のものを持っている必要があります。
Mikiko Bazeley: はい、その通り。実際、私はMLOpsとデータエンジニアがエンジニアのように考えすぎていると思います…
Piotr: それについてもう少し詳しく説明していただけますか？
Mikiko Bazeley: 彼らが直面している課題を技術的なものだと思うだけではありません。時間や余裕、投資が必要なことも多々あります。その場合、会話をビジネスの戦略目標と一致させる必要があります。
私は多くのデータエンジニアやMLOpsエンジニアがそれには向いていないと思います。データサイエンティストの方がそういうことにはもっと向いていると思います。
Piotr: それは彼らがより頻繁にビジネスと関わらなければならないからですね。
Mikiko Bazeley: そうですね！
Aurimas: 開発者は直接的な価値を提供していません…
Mikiko Bazeley: 公衆衛生のようなものですね。みんながそれを重要だと思い始めるのは、水の感染症の問題で死にかかってからです。それは非常に重要ですが、人々はいつもそれがどれだけ重要なのかを表に出さないことがあります。さらに重要なことは、それを「これが最良の技術的な解決策」という視点ではなく、「これは会社にとって莫大な価値を生み出す」という視点で取り組むことです。会社は本当に2つか3つのことだけに関心があります:
- 1 収益または利益の増加
- 2 コスト削減または最適化
- 3 上記の両方の組み合わせ
MLOpsとデータエンジニアが特に機械学習スタックの構築に向けて取り組むことができれば、ビジネスパーソンやエンジニアの責任者は「なぜこのツールが必要なのか？使われない他のものと同じだ」と思うでしょう。
それに対抗する戦略は、彼らが関心を持つKPIやメトリックについて考えることです。それによる影響を示し、次に攻撃計画とメンテナンス計画も提供します。
非常に成功したMLプラットフォームチームが行っていることは、聞いた話とは完全に逆です。MLプラットフォームを構築するには、「新しいものを作り、それを使うためにこのツールを導入しました。そしてそれを使ってくれた人々が大喜びでした」という話がよく聞かれますが、それは事実ではありません。
成功したMLプラットフォームのストーリーを読み解く必要があります。彼らがしたことは、既に進行中だったプロセスの一部または段階を取り上げ、それが最適ではなかった部分に対応しました。たとえば、既に機械学習モデルを展開するためのプロダクションへの経路があったが、その方法は本当にひどかったかもしれません。
チームはもっと良い並行ソリューションを構築し、データサイエンティストをその経路に招待またはオンボーディングします。ユーザの採用に関連する手作業を行います – それが「スケールしない方法で行う」という意味です。ワークショップを行い、そのプロジェクトを進めるのを手助けします。
重要なポイントは、本当に真に優れたものを提供する必要があるということです。データサイエンティストやユーザが「私たちは既にこのことをやっているが、ひどい結果だ」という基準を持っていて、それに対してより良いものを提供する場合、おそらく「差別化された価値」という言葉があると思いますが、データサイエンティストのユーザベースがより多くのことを行うことができます。
もしもビジネスパーソンやCTOに対して「すでに100人のデータサイエンティストがモデルを推進しようとしていることを知っています。それにかかる時間はこれくらいです。それを半分に短縮するだけでなく、より満足できる方法で行い、彼らが辞めることはありません。さらに、私たちが推進したい取り組みによってXの値以上の価値を提供します。それには約6か月かかりますが、3か月に短縮することができます」と言えば、それらの基準と測定値を示すことができ、メンテナンス計画も提供できます。
これらの会話の多くは技術的な優越性についてではありません。それはその取り組みを社会化し、エグゼクティブリーダーの関心事に合わせ、MLプラットフォームの採用を困難にすることについてのものです。
MailchimpのMLプラットフォームの成功事例
Aurimas: Mailchimpの成功事例はありますか？機械学習チームとのコミュニケーションにおすすめの手法はありますか？彼らからフィードバックを得る方法はありますか？
Mikiko Bazeley：はい、まったくその通りです。私たちがうまくやったことはいくつかあります。まず、Autodeskについてお話しします。
私がAutodeskで働いていたときは、データサイエンティストとデータアナリストのハイブリッドな役割でした。Autodeskはデザイン志向の会社です。デザイン思考やユーザーストーリーの収集方法など、多くのクラスを受講させられました。私は人類学の研究でも学んだことです。つまり、どのようにして「民族誌」と呼ばれるものを作成するか、つまり「どのように人々に会い、彼らの実践について学び、彼らの関心事を理解し、彼らの言葉で話すか」ということです。
それが私がチームで最初にしたことでした。私はそこに着任して、「わぁ、Jiraにはこれらのチケットがたくさんあります。私たちはこれらの取り組むべきことがたくさんあります。」と思いました。チームはさまざまな方向に進んでいましたが、まずは「何が本当に重要なのか、すべての人が同じ基準を持っていることを確認しましょう」と思いました。
それで、いくつかのことをしました。最初に行ったのは、作成したいくつかのチケットを見直すことでした。ユーザーストーリーを見直し、データサイエンティストやMLプラットフォームチームのメンバーと話し、このフィードバックを収集するプロセスを作りました。それぞれがフィードバックを独自に評価またはグループ化し、「Tシャツサイズ」で取り組むべき課題の重要度を評価しました。その後、おおまかなロードマップや計画を立てることができました。
私たちが特定した中で、テンプレートがありました。テンプレートは少しわかりにくかったのです。さらに重要なことは、M1 Macがリリースされた時期です。それはのいくつかの機能を破壊しました。テンプレートツールの一部は、機械学習プロジェクトの種類に基づいてDockerイメージを作成し、それに構成を追加することでした。私たちが避けたかったのは、ローカル開発の必要性です。
私たちのデータサイエンティストはすべてAIプラットフォームのノートブックで作業していました。そして、その作業をローカルにダウンロードしなければならず、それを別のGitHubインスタンスにプッシュしなければなりませんでした。私たちはこのプロセスをできるだけ単純化し、特にAIプラットフォームノートブックとの接続方法を見つけることを望んでいました。
GCP内でテンプレートを作成し、それをGitHubにプッシュし、CI/CDをトリガーし、最終的にデプロイプロセスもトリガーすることができるようにしました。それは私が取り組んだプロジェクトでした。そして、それは役立ったようです。私はそれのV1に取り組みましたし、他の人々がそれをさらに進化させました。今は、データサイエンティストは開発中にリモートからローカルに奇妙なプッシュとプルをする必要がなくなりました。
それは私にとって本当に楽しいプロジェクトでした。なぜなら、私はデータサイエンティストや自分自身の仕事において、ローカルで開発するという印象を持っていました。しかし、それは少し不連続なプロセスでした。他にもいくつかありましたが、リモートとローカルの開発の行き来が大きな課題でした。それも大変なプロセスでした。なぜなら、それをJenkinsに接続する方法や、VPCを回避する方法などを考えなければならなかったからです。
最近読んでとても気に入っている本は、Marianne Bellotti著の「Kill It With Fire」という本です。古いシステムを更新し、廃棄せずに現代化する方法について書かれています。それは私がMailchimpでしていた仕事の多くです。
これまでキャリアの中で、私はMLイニシアチブが非常に新しく、すべてをゼロから構築する必要があるスタートアップで働くことに慣れていました。しかし、エンタープライズ企業のためにMLサービスやツールを構築する場合は、はるかに難しいです。実際に使用できるものには制約が多くあります。
例えば、MailchimpではGitHub Actionsを使用することができませんでした。それができればいいのですが、できませんでした。既存のテンプレートツールとデータサイエンティストが既に使っていたプロセスがありました。存在していたのですが、最適ではありませんでした。それでは、彼らが実際に使いたいと思うようなオファリングを最適化する方法はどのようにすればよいでしょうか？多くの学びがありましたが、エンタープライズの環境では進行も遅いです。スタートアップやコンサルタントと比べると、取り組めるプロジェクト数は約3分の1程度になりますが、非常に魅力的です。
関連記事
機械学習プラットフォームの構築[完全ガイド]
もっと読む
Mailchimpのチーム構造
Aurimas: データサイエンティストは直接プラットフォームを使用していたのか、あるいはプロダクトチームに組み込まれていた機械学習エンジニアも関与していたのか、興味があります。
Mikiko Bazeley: その質問には2つの答えがあります。Mailchimpは設計とエンジニアリングに重点を置いた文化を持っていました。そこで働いていた多くのデータサイエンティストは、特に成功したものは全員がソフトウェアエンジニアとしての経験を持っていました。プロセスが少し難しかったとしても、彼らは多くの場合、方法を見つけてうまくやることができました。
ただし、過去2、3年間で、Mailchimpはプロダクトとビジネスの側面により重点を置いたデータサイエンティストを採用し始めました。彼らはソフトウェアエンジニアの経験がありませんでした。そのため、MLOpsやMLプラットフォームの取り組みに関与した各チームには、「組み込みのMLOpsエンジニア」と呼ばれる役割がありました。
彼らはMLエンジニアのような存在でしたが、全く同じではありません。例えば、彼らはデータサイエンティストのためのモデルを構築しているわけではありませんでした。彼らは文字通り、プロダクションへの最終段階の手助けのみをしていました。私が一般的にMLエンジニアを考えるときの方法は、フルスタックのデータサイエンティストです。つまり、彼らはフィーチャーを作成し、モデルを開発しています。私たちには、データサイエンティストがプロジェクトを進めるのを手助けするためにいる人々がいましたが、彼らはモデルを構築していませんでした。
私たちの主要なユーザーはデータサイエンティストであり、彼らのみでした。彼らをサポートするために、チケットの回答、Slackの質問への対応、バグの優先順位付けなどを手伝う人々がいました。それはエンジニアリング関係者にもたらされ、それに取り組んだのです。各チームには、新しい機能やツールの開発に焦点を当てる人々と、データサイエンティストを手助けするために50％の時間を割り当てた人々が含まれていました。
私が辞める約6か月前にIntuitがMailchimpを買収しましたが、実際の変更が始まるのにそのくらいの期間がかかることが通常です。私がいた間に、彼らはチームを再編成して、多くの能力エンジニアが1つのチームに、そしてプラットフォームエンジニアが別のチームに集まるようにしました。しかし、私がいた当時は、各チームにはその両方が含まれていました。
Piotr: つまり、中央のMLプラットフォームチームは存在しなかったのですか？
Mikiko Bazeley: いいえ、基本的にはトレーニングと開発と、サービスと、モニタリングとインテグレーションの分野に分かれていたといえます。
Aurimas: まだ中央のプラットフォームチームは存在しましたが、複数のストリームラインチームに分かれていました。おそらく、チームトポロジーのような形式でプラットフォームの機能を提供していたのでしょう。
Mikiko Bazeley: はい、そうです。
Piotr: テックスタックやプロセスは共有されていましたか、それともデータサイエンティストやサポートスタッフを含む各MLチームが個別の領域、テックスタック、プロセスを持っていましたか。あるいは、例えば、テンプレートの共有など、いくつかの基本的な要素を共有するための取り組みがありましたか。
Mikiko Bazeley: スタックの大部分は共有されていました。組織内のチームを記述するためのチームトポロジーの方法は実際には素晴らしい方法です。素晴らしい方法です。なぜなら、そうですよね、4つのチームがありますよね？ストリームラインチーム、ヘビーサブシステムチーム、エンジェージメントとプラットフォームチームです。
各チームはプラットフォームとエンゲージメントのミックスでした。例えば、私たちが共有していたリソースはBigQuery、Spanner、Airflowなどでした。ただし、違いは、そしてこれが多くのプラットフォームチームが実際に見落としてしまうことだと思います。プラットフォームチームの目標は、特定のツールや特定のスタックの層を所有することではないことが多いのです。大きすぎて特殊化が必要な場合、プラットフォームチームの目標は、既存のツールだけでなく、時折新しいツールをも統一されたエンドユーザー体験に組み込むことです- それは私たちの場合、データサイエンティストでした。私たちが共有しているBigQuery、Airflow、その他のすばらしい機能は、他のチームも使用していましたが、彼らはプロダクションで機械学習モデルを展開することに関心がないかもしれません。実際にそれに関与していませんでした。
私たちが行ったことは、「ねえ、私たちはほぼあなたのガイドになります。これらの他の内部ツールを可能にするために」と言ったことです。私たちは抽象化を作り、提供しました。時には、必要なと思われるツールも取り入れました。たとえば、サービングチームでは使用されていなかったツールにはGreat Expectationsがあります。彼らはほとんど触れなかったのは、それは開発とトレーニングで使用するものであり、実際にはプロダクションで使うものではないからです。
他にもいくつかのものがありました…すみません。一気に思いつくことができませんが、データサイエンティストが開発やトレーニングで使用する必要がある3〜4つの他のツールがありましたが、本番では必要ありませんでした。これらのツールは本番への道筋に組み込まれることになります。
サービングレイヤーは、モデルに使用されていたDockerコンテナやイメージを受け取るPythonクライアントでした。それはAPIエンドポイントに公開され、フロントのチームがモデルから予測を取得するためのリクエストをどのようにルーティングするかを行います。
パイプライニングスタック
Piotr: パイプライニングツールを使用しましたか？例えば、モデルの自動または半自動リトレーニングを可能にするためのツールはありましたか？それともデータサイエンティストがモデルをトレーニングしてDockerイメージにパッケージ化し、それが完了した後はクローズドな感じでしたか？
Mikiko Bazeley: プロジェクトは自動化のさまざまな段階にありました。使用していた大きなツールはAirflowでした。それは会社全体で皆が使っていたものでした。Airflowとの連携方法は次のようなものでした。Airflowでは、DAG（Directed Acyclic Graph）を自分で書く必要があることが多いです。特に、cookiecutterテンプレートに組み込まれた機械学習パイプラインの種類を実行するだけであれば、実際には自動化することができます。ですので私たちは「プロジェクトをセットアップするとき、インタビュー形式の一連の質問に答えてください。Airflowが必要ですか？ はいまたはいいえ？」と言われたら、「はい」と答えた場合は、プロジェクトに関する関連情報やその他の情報が自動的に埋め込まれ、資格情報が代入されるようにしました。
Piotr: それは、彼らがそれが必要かどうかをどのように知っていたのですか？
Mikiko Bazeley: それは実際にはcookiecutterテンプレートの最適化作業の一部でした。私が最初にそこにいたとき、データサイエンティストはこれらの質問の多くを記入する必要がありました。「Airflowが必要ですか？ XYZが必要ですか？」大部分では、彼らはエンエイブルメントエンジニアに「どうすればいいですか？」と尋ねなければなりませんでした。
時折、既存のパスでサポートできるかどうかを含む、よりデザイン的なコンサルテーションが必要なプロジェクトがありました。その場合、私たちは彼らがそれを判断できるようにお手伝いし、プロジェクトをセットアップできるようにしました。
プロジェクトをセットアップしてから「いや、これは違います。実際にはこのことをやる必要があります」と指摘されると、再度プロジェクトを作り直さなければなりませんでした。最適化の一環として、「好きなパターンを選んで、設定をすべて埋めるだけ」と言ってしまえばよかったのです。ほとんどの場合、彼らは簡単にそれを理解できました。例えば、「バッチ予測ジョブですか、値を単純にコピーするだけのものですか？ライブサービスモデルですか？」この2つのパターンは、彼らにとって非常に簡単で、あとは「これが欲しい」と言えば、その特定のジョブ向けに設計されたイメージを使用するだけでした。
テンプレートプロセスが実行され、それから彼らはそれを埋めていきました。「ああ、これがプロジェクト名です、やだやだ…」Pythonのバージョンを記入する必要はありませんでした。自動的に最も安定して最新のバージョンに設定されるようにしましたが、バージョン3.2が必要であり、Pythonが3.11になっている場合は、それを指定する必要がありました。それ以外の場合、彼らはフィーチャーの作成やモデルの開発といった仕事を行うことができるはずです。
もう一つの素晴らしい部分は、ネイティブでのStreamlitサポートを提供していたことです。それもプロセスの一部でした。データサイエンティストは最初のモデルを作成しました。そして、Streamlitダッシュボードを作成しました。それを製品チームに示し、それに基づいて「はい」または「いいえ」という判断を行い、データサイエンティストがプロジェクトを進めることができるようにしました。
さらに重要なことは、新しい製品のメンバーがモデルに興味を持ち、そのモデルがどのように機能するか、またモデルが提供する機能を理解しようとしている場合、Streamlitライブラリやデータサイエンティストからリンクを受け取り、モデルが何を行っているのかを簡単に確認できることです。
Aurimas: これはUAT環境のようですね。本番前のユーザー受け入れテストです。
Piotr: もっと「オンデマンドの技術スタック」のようなものかもしれませんね。プロジェクトを指定して、技術スタックと設定を得る感じです。同じセットアップを持った似たようなプロジェクトの例です。
Mikiko Bazeley: そう、データサイエンティストにとってはそうするべきですよね？
Piotr: だからMailchimpのMLチームには、一つのワンサイズフィットオールの技術スタックだけでなく、選択肢もありました。プロジェクトごとによりパーソナライズされた技術スタックを利用できたのです。
MailchimpのML組織の規模
Aurimas: 何つくりのパスをサポートしましたか？毎日新しいテンプレートリポジトリを作成して、300のユースケースをサポートするための主な仕事をしていたチームの話を聞いたことがあります。
Piotr: そのチームの規模はどれくらいでしたか？どれくらいのMLモデルを持っていましたか？
Mikiko Bazeley: データサイエンスチームは20から25人くらいでした。エンジニアリング側では、私の部署には6人いたし、サービングチームにも6人、データ統合とモニタリングチームにはまた6人いました。そして、データプラットフォームチームもありました。彼らはデータエンジニアリングと関連が深かったですね。
彼らはMailchimpの従来のスタックからBigQueryとSpannerへのデータのコピーを維持・所有するのを手伝っていました。他にもやることはいくつかありましたが、それが主な業務でした。また、データが分析ユースケースで利用可能であることを確認することも担当していました。
そして、MLの取り組みに関与していない人々もそのデータを使用していました。そのチームには6〜8人がいました。合計で、25人のデータサイエンティストのためにエンジニアが24人、さらに製品やデータ分析の担当者もデータを使用していました。
Aurimas: 25人のデータサイエンティストに対して、さまざまなプラットフォームチームで18人いたと理解していますが、それぞれのチームには6人ずついたとおっしゃいましたね。
Mikiko Bazeley: 3番目のチームはいくつかのプロジェクトに広がっていました。モニタリングは最近のものです。彼らはMLプラットフォームの取り組みに関与するようになったのは、私がMailchimpを離れる約3か月前くらいからでした。
それ以前は、彼らはデータ統合に取り組んでいたので、アナリティクスやエンジニアリングの取り組みとは全く異なるものでしたね。
彼らは最近、もっとデータサイエンティストを採用したと思います。また、プラットフォームエンジニアリングの人員も増員していると思います。MailchimpをIntuitに、特にQuickbooksにもっと密接に結びつけることを目指しているのです。そして、MailchimpとIntuitの長期的な戦略的ビジョンにおいて、MLの能力をさらに拡充しているようです。
Piotr: そしてMiki、Mailchimpで働いていたときに本番で稼働していたMLモデルの数を覚えていますか？
Mikiko Bazeley: 最低でも25〜30くらいだったと思います。でもまだたくさんのモデルを作り出していました。そして、それらのモデルの中にはアンサンブルモデルやアンサンブルパイプラインも含まれていました。相当な数でしたね。
私のチームが解決に取り組んでいた最も難しい部分、そして私自身も取り組んでいた部分は、実験と本番の間の溝を埋めることでした。私たちは、Mailchimpで取り組んでいたプロジェクトの最適化を含めて、プロジェクトのセットアップと開発環境の努力を大幅に削減できました。
もし彼らがその数を倍増したと言っても驚きませんが、少なくとも本番でのモデルの数はかなり増えたと思います。
Piotr: アイデアから問題解決のための機械学習モデルを本番に導入するまでに、通常どれくらいの時間がかかるか覚えていますか？メディアンまたは平均時間は何でしたか？
Mikiko Bazeley: アイデアから測っているというアイデアは好きではありませんね。製品側でいろいろなことが起こる可能性があるからです。でも、製品側が順調で考えが変わらない場合、またデータサイエンティストが非常に忙しくなければ、数か月かかることもあります。主にロジックの検証や製品の賛同を得るための作業があったためです。
Piotr: バリデーションロジック？それはどういうものですか？
Mikiko Bazeley: 例えば、データセットのバリデーションです。バリデーションとは、品質のことではありません。私が意味するのは、意味の理解や異なるモデルの作成、異なる特徴の作成、そのモデルを製品チームと他のデータサイエンスチームと共有し、それをサポートする正しいアーキテクチャを持っていることを確認することです。そして、例えば、モデルがそれを必要とする場合にDockerイメージがGPUをサポートしていることを確認することなどです。それには少なくとも数ヶ月かかります。
Piotr: キーファクターについて尋ねようとしていました。一番時間がかかったのは何でしたか？
Mikiko Bazeley: 最初は、エンドツーエンドの経験に苦労しました。異なるチームがあることは少し大変でした。私が最初にそこに着任した時に収集したフィードバックでした。
基本的に、データサイエンティストは開発とトレーニング環境チームに行き、それからサービングとデプロイメントに行き、別のチームと協力する必要がありました。一つのフィードバックは「え、私たちはこれらのさまざまな障害を乗り越えなければならず、統一された経験ではない」というものでした。
もう一つ苦労した部分は戦略的なロードマップでした。例えば、私がそこに着任した時、異なる人々がまったく異なるプロジェクトに取り組んでいて、これらのプロジェクトがどんなものなのかさえわかりませんでした。時にはプロジェクトは「データサイエンティストにとってどれほど有用か？」というよりも「そのプロジェクトのエンジニアがそれに取り組むことを望んだのか？」や「それは彼らの個人的なプロジェクトだったのか？」ということの方が重要な場合もありました。そのようなプロジェクトはいくつかありました。
私が辞める時には、そこでのテックリード、Emily Curtinさん – 彼女は本当に素晴らしい人で、データサイエンティストにGPUを利用する方法について素晴らしい話をしています – と一緒に働くことができました。当時のマネージャー、Nadia Morrisさんもまだそこにいますが、私たち3人と他の数人の仕事のおかげで、実際に統一された経験を提供するためのロードマップの方向性を改善することができました。
例えば、そこでは他のプラクティスもありました。何人かのエンジニアは自分の個人的なプロジェクトで数日間、たとえば2、3晩何かを構築し、それをテストすることなく、何もしないでデータサイエンティストに提供し、「ああ、データサイエンティスト、これを使う必要があるよ」と言っていました。
Piotr: それは情熱と呼ばれています *笑い*
Mikiko Bazeley: それは、「ちょっと待って、なぜまず私たちに内部のテスト期間を作らせなかったのですか」というようなものです。そして、今私たちはデータサイエンティストを助ける必要があります、なぜなら彼らはこれらの個人的プロジェクトのツールで問題を抱えています。
私たちはそれを修正することができました。バグがないことを確認できました。そして、実際にチュートリアルや解説を作成したり、オフィスアワーを開いてそれを紹介するような実際のエンエイブルメントプロセスを設定することができました。
多くの場合、データサイエンティストはそれを見て、「うん、これは使わない、少なくともそれが壊れていない限りは現在の方法を続ける」と言うかもしれません。
MLチームの役割と彼らがどのように協力するか
read more
Mailchimpでの黄金の道
Aurimas: ストリームアライメントされたチーム内で作成されたもののうち、プラットフォームとしての機能として取り込む価値があるものはありましたか？
Mikiko Bazeley: それはかなりいい質問ですね。私は思い当たるものはありません。しかし、データサイエンティストたち、特に優れたシニアの方々が、ツールを試してみたり、それをチームに持ち帰って「これは本当に興味深いものですね」と言ったりすることが多かったです。たとえば、WhyLabsについて調べたときもそうでした。
そして、それが起こった理由だと思います。他にもいくつかありましたが、ほとんどは皆の生活をより簡単にするためのプラットフォームを構築していました。時には新しさを犠牲にしなければならないこともあり、これがプラットフォームチームが間違えるところだと思います。
Spotifyはブログ記事を書いていますね、ゴールデンパスについてね。彼らにはゴールデンパス、シルバーパス、ブロンズパスまたは銅のパスがありました。
ゴールデンパスは最もよくサポートされていました。「これに問題がある場合、サポートしているもの、メンテナンスしているものです。この問題がある場合、そのバグを優先し修正します」と言われると、85％から90％のユースケースで機能します。
シルバーパスにはゴールデンパスの要素も含まれていますが、直接サポートされていないものもありますが、相談を受けたり情報を提供されたりします。ゴールデンパスに取り込めると思えば取り込みますが、それには十分なユースケースが必要です。
その時点で、「エンジニアリソースをどこに使うか」という話になります。例えば、Creative Studioのようなプロジェクトがあります。非常に革新的ですが、サポートするのは難しいです。しかし、MailChimpは「これを提供しなければならない、私たちのユーザーのために生成AIを使って製品提供を効率化する必要がある」と言いました。その場合、どれだけのエンジニアの時間をこのシステムの作業に使えるかという問題になります。
それでも、それらのプロジェクトに関しては、必要なインフラストラクチャサポートの違いはそれほど大きくありません。特に生成AIとLLMsでは、最も大きなインフラストラクチャと運用の影響は遅延です。その次はデータのプライバシーです。そして3番目は監視と評価の要素です。しかし、他の多くのことに関しては、例えばNLPベースの推薦システムなど、必要なプロバイダを持っている限り、大幅に変わることはありません。
ですので、ゴールデンパスがありましたが、シルバーパスもありました。そして、自分のやり方で進む人もいました。私たちにはそういう人たちもいました。彼らは水際で動いていました。
その時点で、「あなたはそれをやることができますが、公式モデルでの本番環境ではないですよね？」と言えます。最善を尽くしますが、プラットフォームの問題なのか、それともその人の性格のせいなのか、考える必要があります。もしあなたが25人のうち1人または2人だけがそれをやっている場合、「まぁ、おそらくその人の問題だろう」と思います。おそらくプラットフォームのせいではないでしょう。
Piotr: そして、あなたの学識が重要な要素になるということですね！
締めの言葉
Aurimas: 実際には、私たちは約19分遅れていますので、エピソードを終了する前に、聴衆に残したい思考があるかもしれませんね？オンラインで自分を見つけることができる場所を教えてもらえますか？
Mikiko Bazeley: ええ、もちろんです。皆さんはLinkedInとTwitterで私を見つけることができます。私はさぼっていたSubstackを再活性化するつもりです。なので、皆さんはSubstackで私を見つけることができます。さらに、私は再活性化中のYouTubeチャンネルも持っていますので、そこでも私に会えます。
最後に、過去6か月間で起こっている新しいことについて多くの人々が不安や興奮を抱えていることを知っています。何人かは仕事について心配しています。
Piotr: ファンデーションモデルを指していますか？
Mikiko Bazeley: そう、ファンデーションモデルですが、機械学習の領域でもたくさんのことが進行しています。私のアドバイスは、まず、退屈な機械学習やデータインフラストラクチャ、知識は今まで以上に重要だということです。データモデリング、コーディング、テスト、ベストプラクティスの強力なスキルセットを持つことは常に価値があると言えます。
2番目のアドバイスは、どんな肩書きであっても、あるいはなりたい肩書きであっても、プロジェクトに取り組むこと、関連する領域を理解すること、そしてビジネスの言語を話せるようにすることに焦点を当てるべきだということです。
率直に言ってしまえば、私は最高のエンジニアやデータサイエンティストではありません。自分の弱点と強みを十分に理解していますが、私がキャリアの中で多くの変化を遂げ、これまで進むことができた理由は、ドメインとチーム、特に収益センターまたは利益センター（人々が呼ぶようなもの）を理解しようと努力しているからです。それは非常に重要なスキルです。人間関係のスキルと知識を身につけるべきです。
そして、人々は自分の学びをソーシャルメディアで共有すべきです。それによって仕事やスポンサーシップを獲得することができます。
Aurimas: 考えを共有していただき、時間を割いて話していただき、ありがとうございました。本当に素晴らしい経験でした。また、お聞きくださった皆様にも感謝申し上げます。次回のエピソードでお会いしましょう！
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
