True ML Talks #5 - 機械学習プラットフォーム @ Simpl

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
True ML Talksの新しいエピソードをお届けします。今回は、深く掘り下げていきます。 Simplの MLプラットフォームについて、お話を伺います。 Sheekha。
Sheekha氏はSimplのデータサイエンスディレクターです。Simplは、インドを代表する「ファーストタップチェックアウト」ネットワークを構築しており、BNPL(後払い)から分割払い支援、その他多くの付加価値サービスまで、あらゆる製品を加盟店に提供しています。彼らはインド全土で26,000以上の加盟店と提携しており、最大の通信ネットワークであるJIOプラットフォームや、国内最大級のフードデリバリーサービスであるZomatoなど、多数の企業が含まれます。
📌
Sheekha氏との対談では、以下の点について取り上げます。
- SimplにおけるMLユースケース
- Simpl MLインフラストラクチャの概要
- MLトレーニングのコスト管理
- トレーニングと推論パイプラインの個別管理
- MLモデル再トレーニングの自動化
- Simplの自社開発への進出
- リアルタイムシステムとデータサイエンスモデルに関する考慮事項
- MLデプロイメントをソフトウェアのようにシンプルにする
- データサイエンスにおけるエンジニアリング原則の定着
全編はこちらからご覧ください。
SimplにおけるMLユースケース
- 不正防止とリスク評価: SimplのMLシステムは、すべての取引を分析し、シンプルなルール、フィルター、機械学習モデル、ニューラルネットワークシステムを用いて、アカウント乗っ取り、個人情報盗難、その他の不審な活動などのリスクの高い取引を特定します。このシステムは不正な取引を防止でき、それにより金銭的損失や優良顧客へのサービス提供不能といった事態を防ぎます。
- 信用審査: SimplのMLシステムは、ユーザーから提供されたオンボーディングデータを分析することで、信用審査の決定を支援します。このシステムは、ユーザーが利用できる信用額と、その利用限度額を決定します。Simplのチームは信用審査プロセスに関与しており、よりリアルタイムなパイプラインとシステムへの移行を進めています。
- カスタマーサポート: SimplのMLシステムは、期日通りの支払いが困難な顧客への対応を支援します。このシステムは、顧客に今後の支払いを通知したり、両者にとって都合の良い代替支払いプランを提案したりできます。Simplのチームは、顧客と協力して最善の解決策を見つけ、良好な顧客体験を保証します。
Simplが不正検知にMLをどのように活用しているかについて、興味深いニュース記事を見つけました。
Simplのデータサイエンスチーム
Simplのデータサイエンスチームは、28人のデータサイエンティストと16人のデータエンジニアで構成されています。このチームは、他のエンジニアリングチームと共にSimplの中核を担っており、独立したDevOpsチームも持っています。チームはML、ニューラルネットワークシステム、ルール、グラフデータベース、グラフ機械学習モデルに取り組んでおり、不正ユーザーのコミュニティを分析しています。
Simplのデータサイエンスチームの技術スタックとワークフロー
現在の技術スタックの観点から見ると、同社はすべてをクラウド上に置いており、オンプレミスシステムは一切ありません。
Simplのデータサイエンスチームは、データエンジニアリングチームが構築したPythonノートブックとライブラリを備えたリモートマシンを使用し、データベースに接続して探索的データ分析(EDA)を実行します。データ分析が完了すると、データエンジニアリングチームの協力を得て、モデルをデプロイするためのパイプラインを構築します。バッチモデルの場合、チームはスケジューリングにAirflowを使用しています。
モデルの監視は、Simplのダッシュボードを使用して出力の変化を追跡することで行われます。MLOpsに関しては、Simplは現在この分野に投資しています。不正防止システムについては、同社は類似のメールIDや電話番号を分析するためにバッチシステムを使用するモデルを持っています。チームはまた、取引の速度と取引額に基づいてリアルタイムで取引を監視するツールもいくつか持っています。
Simplは、取引監視のためにニューラルネットワークモデルも導入しました。このモデルは、現在のペイロードと過去1年間の履歴データを組み合わせ、取引を許可するか拒否するかを決定するためにニューラルネットモデルに投入します。データエンジニアリングチームは、ピークトラフィックを管理し、70〜80ミリ秒という低いSLAを確保するためにFlinkパイプラインを構築しました。
📌
特徴量ストア:
特徴量ストアとは、機械学習モデルのトレーニングに使用される、データの個々の測定可能な特性や性質である特徴量を保存・管理するための一元化されたリポジトリです。
Simplは現在、 特徴量ストアとしてDynamoDBを使用しています リアルタイムの可用性を実現しています。しかし、これは費用がかかるため、長期的にはコストを削減するために内部特徴量ストアを構築する取り組みが進められています。
Simplにおけるデータサイエンスの進化について、興味深いブログを見つけました。
MLモデルのコスト管理:課題と解決策
機械学習(ML)モデルの実装とスケーリングに伴うコスト管理は、極めて重要な課題です。特に、大量のデータを必要とし、Flinkパイプラインや仮想マシンなどの高価なリソースを使用するモデルにとっては、この点が非常に重要になります。
MLチームはテラバイト級のデータを扱っており、トレーニングジョブには仮想マシンの使用が不可欠です。モデルのメリットとコストのバランスを取ることが極めて重要となります。
コストを削減するため、チームはDevOpsチームやデータエンジニアリングチームと協力し、費用対効果の高い選択肢を模索しています。また、DynamoDBの使用コストを削減するために、内部特徴量ストアの構築にも取り組んでいます。さらに、重要度の低いタスクにはスポットインスタンスを利用するというコスト削減策も採用しています。
しかし、コスト管理は継続的なプロセスであり、モデルの費用対効果を常に評価する必要があります。最適なコスト削減策を決定する際には、適合率と再現率のバランス、優良ユーザーの獲得コストといった要素も考慮に入れる必要があります。
📌
MLチームとDevOpsチーム間の連携:
機械学習プロジェクト用の仮想マシンをプロビジョニングするには、DevOpsチームとデータサイエンスチーム間の連携が不可欠であり、通常、最低3日間のリードタイムが必要です。DevOpsチームは、データサイエンスチームからのものを含め、複数のリクエストを受け取りますが、これらはコストを考慮し、データエンジニアリングチームとの協力のもとで対応する必要があります。緊急のリクエストの場合、DevOpsチームはコストへの影響を考慮せずにプロビジョニングプロセスを迅速化できます。データサイエンスチームは、プロジェクトのデプロイ計画において、この3日間のタイムラグを考慮に入れています。
トレーニングパイプラインと推論パイプラインを個別に管理する:メリットとデメリット
トレーニングパイプラインと推論パイプラインを個別に管理すると、システム全体の効率に影響を与える様々な問題が発生する可能性があります。主な理由としては、モデルの出所を追跡したり、コードを保持したり、結果を再現したりすることが困難になる点が挙げられます。また、特にスタートアップ企業では、人為的なミスや問題の増殖につながることもあります。
一方、これらのパイプラインを個別に管理することで、システムに対する柔軟性と制御が向上し、各プロセスを独立して最適化できるようになります。また、必要に応じてトレーニングパイプラインや推論パイプラインに新しいリソースを追加することで、システムをより簡単にスケールすることも可能です。
しかし、理想的には、これらのパイプラインを統合し、再トレーニングも同じプロセスに組み込むことが望ましいでしょう。そうすることで、パイプラインを個別に管理することに伴う問題を回避できます。それでも、個別に管理することによる柔軟性と制御は維持できます。全体として、これらのパイプラインを個別に管理するか、統合して管理するかは、組織の具体的なニーズと利用可能なリソースによって決定されます。
MLモデルの再トレーニングにおける自動化の重要性
MLモデルの再トレーニングは、その精度と関連性を維持するために不可欠な要素です。しかし、手動での再トレーニングは時間がかかり、エラーが発生しやすいという問題があります。そのため、プロセスを効率的、信頼性があり、スケーラブルなものにする上で、自動化が極めて重要な役割を果たします。
再学習を自動化することで、組織は再学習をトリガーする特定の間隔を設定し、モデルが定期的に更新されるようにすることができます。これにより、自動化によって手動での介入が不要になるため、時間とリソースの節約にもつながります。
しかし、特殊なハードウェアやソフトウェアを必要とする複雑なモデルの再学習を自動化する際には、課題が生じる可能性があります。そのような場合、自動化されたソリューションが導入されるまでは、手動での再学習が必要になるかもしれません。
Simplの内製化への挑戦
機械学習プロジェクトでSageMakerを利用する際の課題
SageMakerの利用は、機械学習プロジェクトで大規模なデータセットを扱う際、データサイエンスチームにとって画期的なものでした。しかし、このプラットフォームには、チームの生産性に影響を与える可能性のあるいくつかの課題が依然として存在します。
- リソースの割り当て: 複数の人が同時にSageMakerにログインすると、大きなファイルやモデルの読み込みが、全員のシステムをクラッシュさせる可能性があります。これは、リクエストを開始した人だけでなく、他の全員にも影響します。このことは、チーム側でそのような問題を管理できるシステムの必要性を浮き彫りにしています。
- GPUの実行コスト: 大量のデータを処理するために不可欠なニューラルネットワークモデル用のGPUインスタンスの実行コストは非常に高価になる可能性があり、チームはそれらを使用する際に注意する必要があります。コストを節約するために、彼らは一定期間アイドル状態の場合にノートブックをシャットダウンするシステムを構築しました。しかし、彼らは使用状況に応じてスケールアップおよびスケールダウンする、より自動化されたシステムへの移行を望んでいます。
SageMakerはチームにとって有用なプラットフォームでしたが、Kubernetesのようなまだ試していない他の選択肢も存在します。しかし、SageMakerを使用するという決定は、主に大量のデータを処理できる高速なシステムの必要性によって推進されました。
より良いSageMakerバージョンの構築計画
同社は、自社独自の機械学習プラットフォームであるSageMakerの改良版を開発する計画です。当初はR&Dの実験であったこのプロジェクトは、現在、社内開発が可能なより大規模なチームの恩恵を受けています。彼らの仮想システムはSageMakerのいくつかの機能を備えていたものの、分散コンピューティングが不足していました。Pyコンソール統合を通じて現在の仮想マシンに分散コンピューティングを追加することで、必要なソリューションが提供されるでしょう。
ユーザーアクセス制御管理とデータアクセシビリティのために、同社は様々なIAMロールを構築し、コスト管理のためにデータチームに子アカウントを割り当てました。しかし、FinTech企業として扱う機密データや、RBIによる定期的な監査を考慮すると、まださらなる作業が必要です。
外部プラットフォームを利用することもできましたが、同社はSageMakerの自社版を内製することを選択しました。彼らの決定は戦略的であり、データアクセシビリティやコストに関連する制約に基づくものではありません。プラットフォームに対するより大きな制御を持つことで、彼らはより効率的にスケールし、成長できます。同社はすでにDASを介して一部のシステムで分散コンピューティングを使用しています。
規模が拡大し、チームが大きくなるにつれて、内製できるなら、なぜしないのか?
- シーカ
リアルタイムシステムとデータサイエンスモデルに関する考慮事項
- リアルタイムシステムでは、厳格なSLAを遵守する必要があり、負荷分散は不均一になる可能性があり、特定のピーク時間帯にはワークロードが高くなることがあります。
- リアルタイムシステムをデプロイする際には、レイテンシーと負荷分散を考慮することが不可欠です。
- データサイエンスモデルは、「見栄え」のためではなく、実際のビジネスインパクトのために作成されるべきです。
- モデルの影響を測定するために指標が使用されます。例えば、阻止できる不正行為の量や、影響を与えることができる優良ユーザーの数などです。
- リスクチームとCFOは、コストとビジネスへの影響の観点から、どの点に納得できるかについて決定を下します。
- DynamoDBの書き込みや読み込みの量といったバックエンドコストは、望ましい影響と一致するように、モデルのビジネス指標と結びつけて考慮する必要があります。
MLデプロイメントをソフトウェアのようにシンプルに:開発者の生産性向上
Scikit-learnのようなライブラリのおかげで、MLモデルの開発は容易になりましたが、パイプラインやMLOpsシステムを持たない中小企業にとっては、プロジェクトを開始して稼働させるまでの時間は依然として長いです。パイプラインのセットアップ、データのクリーンアップ、テストの検証、モデルのデプロイには2〜3ヶ月かかることがあります。さらに、そのプロセスに標準化がないため、モデルのバグを見つけるのは困難です。したがって、企業は開発者の生産性を向上させるために、モデル開発をソフトウェア開発と同じくらいシームレスにするシステムを必要としています。そのシステムは、柔軟性、容易な統合、既存システムの上での構築を可能にするべきです。また、バグ発見、データの入出力監視、フィードバックループの標準化も備えているべきです。
データサイエンスにおけるエンジニアリング原則の定着の重要性
データサイエンスの分野では、MLモデルの成功裡かつ効率的なデプロイメントを確実にするために、データサイエンティストがエンジニアリングスキルを持つ必要性への注目が高まっています。
- データサイエンティストは、MLモデルの効率的なデプロイメントを確実にするために、エンジニアリングスキルを持つ必要があります。モデルのSLAに影響を与える可能性のあるバグを特定するためには、優れたコーディングプラクティスをデータサイエンティストに根付かせるべきです。
- データサイエンティストがPandasのような特定のツールを好むことは、リアルタイムでデプロイされた際にパフォーマンスの低下を招く可能性があります。MLモデルの効率的なデプロイメントを確実にするために、データサイエンティストは最も効率的なツールとその使用法を認識している必要があります。
私たちのデータサイエンティストには、すべて、さらにはフィルターでさえもデプロイしてほしいと思うでしょう。
- シーカ
シーカからのその他の考察
MLOps:自社開発か、購入か
- カスタマイズ:大規模なカスタマイズには、サードパーティのMLプラットフォームを採用するのではなく、ゼロからの構築が必要になる場合があります。
- データ機密性:機密データを扱う企業にとって、厳格なユーザーアクセス制御管理は極めて重要であり、特定のセキュリティ要件に合わせてカスタマイズできる社内システムが必要になる場合があります。
- コスト意識:中小企業にとっては、社内MLOpsシステムを構築する方が費用対効果が高い場合がありますが、市場が成熟するにつれて、より良いROIのために最終的にはサードパーティプラットフォームに投資する可能性があります。
LLM
シーカは大規模言語モデル(LLM)とその周辺の新しい開発に興味を示しましたが、現時点では、それらを業務で使用していません。しかし、特にチャットボットとの統合において、LLMの興味深いユースケースを模索していることを認めました。
LLMには多くの興味深いユースケースが間違いなくあると予見しています。
- シーカ
TrueMLシリーズの以前のブログを読む
引き続きTrueMLの YouTubeシリーズ を視聴し、TrueMLのすべての ブログシリーズを読む。
TrueFoundry は、Kubernetes上で動作するMLデプロイメントPaaSであり、開発者のワークフローを加速させ、モデルのテストとデプロイにおいて完全な柔軟性を提供しつつ、インフラチームには完全なセキュリティと制御を保証します。当社のプラットフォームを通じて、機械学習チームが デプロイおよび監視 を15分で、100%の信頼性、スケーラビリティ、そして数秒でのロールバック機能を備え、これによりコストを削減し、モデルをより迅速に本番環境にリリースできるようになり、真のビジネス価値の実現を可能にします。
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.















.webp)
.webp)


.png)

.png)














