時間が私のMLモデルを殺した!

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
私たちは皆、90%、88%、 87%、 85% あるいは、MLモデルの途方もない割合が本番環境にデプロイされない、というものです。正直なところ、誰がこれをどのように計算したのか全く分かりませんし、私も同じくらい困惑しています。 この人と同じくらい。しかし、それは本題ではありません。理想的には、その数字よりもはるかに重要なのは なぜ 多くの企業が機械学習からビジネス価値を引き出すのに苦労しているのか—まだ!
これを理解するため、私たちは200人以上の人々と1対1で1時間ずつ会話をしました。その目的は、MLモデル構築のワークフローを理解することであり、これには以下が含まれます。 ビジネス要件の策定、それをスプリントに落とし込むこと、データ収集、モデル構築、本番環境対応、デプロイ、再学習、A/Bテスト、デバッグ、モニタリング、オブザーバビリティ など、そしてこの一連のプロセスのどのステップからでも、どのステップへでもループを閉じること。これには、ビジネスリーダー、エンジニアリングリーダー、プロダクトマネージャー、データサイエンティスト、DevOps、データエンジニア、MLエンジニアといった多様な視点が含まれます!これらの定性的な会話の後、私たちは客観的なアンケート調査も実施し、一般的な問題についてより広い視野を得ました。その結果は以下で確認できます。 こちら。
応用機械学習は比較的新しい分野であり、パイプラインのほぼすべての部分に問題が存在する一方で、私たちの会話から、ある一つの圧倒的かつ顕著なテーマが浮かび上がってきました。それは—
MLモデルの構築とローンチのあらゆるステップ内およびステップ間の時間差が、エンジニアリングチームとリーダーシップチームの自信と士気を低下させ、MLモデルを頓挫させているのです!
ソフトウェアの世界では、私たちはデータに基づいた意思決定を行うことに慣れています。迅速な結果を求め、A/Bテストを実施し、コストを正当化します。そして、もしプロジェクトが十分なROIを達成できない場合、 妥当な 期間内に、そのプロジェクトは打ち切るべきだと教えられます。そして 時間 は、MLが非常に多くを要するものです!これは、理由は異なるものの、あらゆる種類の企業に当てはまります。
- アーリーステージのスタートアップ(シードからシリーズCまで)
- ウォルグリーン、ターゲット、シーメンスのような伝統的な巨大企業
- Uber、Amazon、Netflixなどのテック大手
これを詳しく見ていきましょう。
アーリーステージのスタートアップ
多くの場合、機械学習パイプラインの構築とデプロイには、多様なスキルセットが必要です。
- ビジネスユースケースの理解 — (通常はプロダクトマネージャー)
- データロギングと処理パイプライン — (通常はデータエンジニア)
- モデルの実験と構築 — (通常はデータサイエンティスト)
- 推論APIの作成とデプロイ — (通常はMLエンジニア)
- モデルのスケーリング、ステージング、本番パイプライン — (通常はDevOpsチーム)
- A/Bテストフレームワーク、監視と可観測性、再学習パイプライン
非常に頻繁に、スタートアップはスキルセットの全範囲をカバーするために異なる人材を雇うリソースがありません。スタートアップは、1〜2人の非常に優秀な人材を雇えば、 経験豊富で何でもこなせる と信じ込んでいますが、そのような「伝説上の生き物」は、創業者の夢の中にしか存在しないということに彼らは気づいていません!
結局のところ、採用されたデータサイエンティストやMLエンジニアは、「スタートアップでは、物事を成し遂げるために必要なことは何でもやる」という一般的な格言に従おうとします。しかし、この分野(急速に変化している)の技術の学習曲線は非常に急峻で、結果的に 多くの時間がかかってしまいます これら異なる各部分を学習し、実装するのに。当然のことながら、この新人が構築したパイプラインは、しばしば完璧ではなく、さまざまな箇所で破綻し始めます。それが場当たり的なプロジェクトの連鎖を引き起こし、エンジニアリングリソースを浪費する典型的な理由となります!この時点で、不満を抱いた創業者は厳しい決断を下します。「よし、我々はまだ機械学習の準備ができていない。シンプルで、保守が容易な、ただ機能するルールベースのシステムを構築しよう。基本に戻ろう!」
ウォルグリーンやターゲットのような伝統的な巨大企業
大企業において、MLモデルの導入に時間がかかりすぎる理由は、技術的なものと同じくらい(あるいはそれ以上に)組織的なものです。通常、カスタマーサクセスや営業チームのビジネスユーザーが顧客との電話を終え、機械学習プロジェクトのアイデアを思いつきます。このアイデアは、プロダクトマネージャーによる解釈、リソース配分、スプリント計画会議を経て、最終的にデータサイエンティストの手に渡ります。このアイデアが、組織がすでにモデルに投入するデータ(例えばユーザーのクリックストリームなど)を持っているような、比較的シンプルなものであったと仮定しましょう。
データサイエンティストはモデルを構築しますが、ビジネスユーザーから迅速なフィードバックを得る方法がありません。なぜなら、
- ノートブックはビジネス担当者には専門的すぎる
- Excelシートに保存された結果はインタラクティブではない
- データサイエンティストは通常、モデルを迅速にホストし、APIを公開するためのスキルセットを持っていません。
ビジネスユーザーからのフィードバックがなければ、データサイエンティストはどうやって知るのでしょうか?
- 彼らのモデルはビジネスユーザーが求めた問題を解決しているのか、それとも意図が伝言ゲームで失われてしまったのか?
- 重要な境界条件を見落としていないか、それを見落とせば顧客を激怒させてしまうようなものはないか?
- モデルに偏りをもたらしたり、特定のユーザー層に悪影響を与えたりする可能性のあるデータソースを使用していないか?
上記のすべてがうまくいったとしても、ビジネスユーザーの最初の直感が正しかったと誰が断言できるでしょうか?最終的なフィードバックはエンドユーザーからしか得られません。しかし、どうすればモデルをエンドユーザーの手に届けられるのでしょうか?
ええ、その通りです。エンジニアリングチームとプロダクトチームを巻き込む必要があります。再びリソース配分会議やスプリント計画が行われ、最終的にモデルは製品に統合されます。これには数ヶ月かかることもあり、その頃にはビジネスユーザーは製品の優先順位が変わっていることに気づくかもしれません!そして、恐ろしい言葉が発せられます。「このプロジェクトにこれ以上リソースを投資しても無駄だ。これ以上の無駄な投資はやめよう!」
UberやAmazonのようなテックジャイアント
言うまでもなく、これらの企業は最も時代の先を行っており、MLモデルを本番環境に投入するのに数ヶ月もかけることはめったにありません。しかし、これらのトップ企業であっても、そうした話がないわけではありません。そして、この文脈において、彼らは非常にユニークな問題を抱えています。
非常に多くの大手テクノロジー企業が、特徴量ストアの構築からアルゴリズムの実装、依存関係の管理、デプロイ、モデル推論など、あらゆる機能を備えた独自のMLOpsプラットフォームを構築しています。あらゆるユースケースに対応するこのような汎用プラットフォームを構築することは、困難なエンジニアリング課題であり、これらのシステムは最終的に次のような前提を置くことになります。
- これらは、データサイエンティストが使用すると想定される最も一般的なライブラリです。
- データサイエンティストが「既成の」アルゴリズムを使用する限り、すべてがスムーズに機能しますが、独自のモデルを開発したい場合は、X、Y、Zのステップを実行する必要があります。
これらの前提を検証し、それらが現実的ではないことを主張しましょう。MLアルゴリズムとツールセットは常に進化しており、これらの企業が取り組んでいる最先端の問題には、最先端のソリューションが必要です。つまり、企業がMLに注力しようとすればするほど、カスタムソリューションが必要になり、専門のエンジニアリングリソースを投入する必要性が高まるのです!
まさにこの理由から、データサイエンスチームは既成のソリューションで妥協してしまうことが非常に多く、それは莫大な機会費用を伴います。データサイエンティストや企業が、より困難な道、つまりプラットフォームを進化させ、カスタムの高度なソリューションを構築することを許可する道を選択した場合、ご想像の通り、ビジネスケースを作成し、適切なリソースを確保し、多くの組織の人々と話し合う必要があります。それがプラットフォームの改善につながるかどうかに関わらず、確実に遅延を招きます!
そして、これらの多くの投資の後、物事が計画通りに進まず、ユーザーにリリースされた際に、次のプロジェクトではより簡単な既成のルートを選択するという強化が生まれるのです。
結論と次のステップ
MLモデルが「時間がかかりすぎる」というテーマが、様々な理由で、すべてのユーザーとの会話で明確になりました。
- 人的資源やツールキットがすべて揃っておらず、最適なソリューションを繰り返し検討し見つけ出す時間もあまりないスタートアップは、MLプロジェクトを断念する際に、ルールベースのシステムで妥協してしまいます!
- 組織的な課題を抱える大手伝統企業は、MLプロジェクトが実現するまでに時間がかかりすぎたためそれらを断念し、正当なビジネスインパクトを生み出すことに頻繁に失敗します。
- 現代のテクノロジー企業は MLOpsプラットフォーム 本番環境向けに最適化されているものの、自由な実験にはあまり適していないため、結局「既成の」サポートされているアルゴリズムやライブラリで妥協してしまいます。そうでなければ、機械学習の可能性を最大限に活用するには時間がかかりすぎます。
これほど幅広い企業に共通するこのテーマを見て、私たちは驚きました。
MLモデルに時間がかかりすぎること、そしてビジネスインパクトとフィードバックサイクルが遅れることが、多くのMLモデルが日の目を見ない主な理由の一つです。
私たちは、ビジネスユーザーとデータサイエンティスト間のシームレスなコミュニケーションを可能にし、MLソリューションに多くの組織リソースを費やす前に、消費者からの迅速なフィードバックでビジネスインパクトを検証できるような解決策を提供できれば、機械学習への信頼と投資を増やし、その投資をはるかに実り多いものにすると考えています。
私たちはまだこの問題に対する完全な解決策を持っているとは主張しませんが、現在取り組んでいます。賢明な人々と話し合い、この問題を完全に解決できないまでも、どのように軽減できるかを検討しています。
これほど大きな問題には、多様な視点が結集する必要があると強く信じています。この問題に共感される方、ご意見をお持ちの方、問題解決のアイデアをお持ちの方、あるいは私たちのアイデアを聞きたい方は、ぜひコメントいただくか、私たちにご連絡ください。
個人的なご連絡は nikunjbjj@gmail.com までお願いいたします。。私と共同創設者のLinkedInはこちらです。
このブログはMediumに初掲載されました。 https://medium.com/@nikunjbajaj/time-killed-my-ml-model-48521fad6c4 2021年8月30日に
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
The fastest way to build, govern and scale your AI
















.webp)




.png)








.webp)
.webp)








