モデルはそれ自体で動作するわけではありません。モデルのトレーニング、検証、デプロイ、監視を行うパイプラインこそが実際の製品であり、モデルはその成果物の一つに過ぎません。

MLモデルがノートブックで機能することを証明しました。次に、それを本番環境で必要とします。つまり、予測を大規模に提供し、新しいデータで再トレーニングし、ドリフトを監視し、新しいモデルが現在のモデルよりもパフォーマンスが悪い場合にロールバックすることです。動作するプロトタイプと本番環境のMLシステムとの間には、途方もないギャップがあります。データインジェスト、特徴量エンジニアリング、トレーニング、検証、デプロイ、監視を繰り返し可能な自動化されたプロセスとして処理するパイプラインが必要です。これがないと、あなたの「AI製品」は、データサイエンティストが毎週手動で再実行するノートブックにすぎません。
Explore more design patterns and system architectures
MicrocosmWorksは、MLflowやWeights & Biasesといったツールを使用してモデルレジストリパターンを実装しており、すべてのモデルバージョンを、その学習データのスナップショット、ハイパーパラメータ、評価指標とともに追跡します。当社のデプロイメントパイプラインはカナリアリリースをサポートしており、新しいモデルがトラフィックのごく一部にサービスを提供する間、主要なパフォーマンス指標を監視し、精度やレイテンシが定義されたしきい値を超えて劣化した場合に備えて自動ロールバックトリガーを備えています。これにより、パフォーマンスの低いモデルが影響を与えるのは、制御されたごく一部のユーザーに留まり、それ以上の影響は与えないことが保証されます。
MicrocosmWorksは、トレーニングとサービングのインフラストラクチャを分離し、アーティファクトストアを介して接続されたMLパイプラインを設計しています。これにより、再学習ジョブは一時的なGPUクラスター上で実行され、本番の推論エンドポイントとリソースを競合することはありません。データドリフトの検出時や固定スケジュールで再学習をトリガーするために、Kubeflow PipelinesやApache Airflowのようなオーケストレーションツールを使用します。自動化されたバリデーションゲートにより、再学習されたモデルは、現在のバージョンよりも優れた性能を発揮した場合にのみ本番環境に昇格されます。このアーキテクチャにより、モデルはサービングのダウンタイムなしに継続的に改善されます。
MicrocosmWorksは、すべての本番MLパイプラインにドリフト検出機能を組み込んでいます。これは、特徴量分布のためのKolmogorov-Smirnov testのような統計的テストや、グラウンドトゥルースラベルが利用可能になり次第、それらに対する予測精度を追跡するパフォーマンス監視ダッシュボードを利用して行われます。ドリフトが設定されたしきい値を超えると、当社のパイプラインは最新のデータで自動的に再トレーニングをトリガーするか、ドリフトパターンが予期せぬものである場合は手動レビューのためにチームにアラートを送信します。このプロアクティブなアプローチにより、ダウンストリームのビジネス指標を通じてモデルの劣化が気付かれるよりも数週間早く検知できます。
MicrocosmWorksは、チームを1時間あたり15ドルから45ドルで請求し、エンドツーエンドのMLパイプラインを構築します。データ取り込み、特徴量エンジニアリング、トレーニングオーケストレーション、モデルレジストリ、サービングインフラストラクチャを網羅する典型的なプロダクションパイプラインは、データ複雑性およびコンプライアンス要件に応じて10〜20週間かかります。当社は、トレーニングワークロードにスポットインスタンスを使用し、実際の推論需要に基づいたオートスケーリングによりサービングインフラストラクチャを適切にサイズ調整することで、コストを削減します。すべてのエンゲージメントは、本格的な構築が始まる前に、詳細なアーキテクチャ計画とコスト予測を作成する2週間のディスカバリースプリントから開始されます。
MicrocosmWorksは、各トレーニング実行におけるコードバージョン、データセットハッシュ、環境設定、ランダムシード、ハイパーパラメータを自動的に記録する実験追跡インフラストラクチャを構築することで、過去のあらゆる実験を数ヶ月後でも完全に再現できるようにしています。当社は、依存関係のバージョンを固定したトレーニング環境をコンテナ化し、GitとDVC(Data Version Control)を併用して、コード変更と連携してデータセットをバージョン管理します。これにより、あるデータサイエンティストのマシンでは機能するものの、チームでは再現できないという一般的な問題を解消します。
AI/MLパイプラインアーキテクチャは、MLライフサイクルを明確で自動化されたステージに分割します。具体的には、データインジェストと検証、特徴量エンジニアリングとストレージ、モデルトレーニングとハイパーパラメータチューニング、モデル評価と検証、モデルサービングと推論、および継続的な監視です。各ステージはバージョン管理され、再現可能で、観測可能です。このアーキテクチャは、バッチ(スケジュールされた再トレーニング)とオンライン(リアルタイムの特徴量計算)の両方のワークフローをサポートします。フィーチャーストアは、特徴量エンジニアリングとモデルトレーニングを分離し、モデル間での特徴量の再利用と、トレーニングとサービング間での一貫した特徴量を可能にします。
このパイプラインは、データソース(データベース、API、イベントストリーム)から、特徴量を計算しフィーチャーストア(サービング用にはオンライン、トレーニング用にはオフライン)に保存する特徴量エンジニアリング層を経由して流れます。トレーニングオーケストレーターは、実験を実行し、パラメータとメトリクスをログに記録し、モデルレジストリに保存されるバージョン管理されたモデルアーティファクトを生成します。デプロイメントパイプラインは、自動化されたカナリア評価によってモデルをステージングから本番環境へと昇格させます。モデルサービングは、A/Bテストをサポートするロードバランサーの背後で動作します。監視層は、予測ドリフト、データドリフト、およびビジネスメトリクスを追跡し、再トレーニングをトリガーします。
| 層 | テクノロジー |
|---|---|
| トレーニング | PyTorch, TensorFlow, scikit-learn, XGBoost, Hugging Face Transformers |
| オーケストレーション | Kubeflow, SageMaker Pipelines, Airflow, Prefect, Dagster |
| フィーチャーストア | Feast, Tecton, SageMaker Feature Store |
| モデルサービング | TorchServe, Triton Inference Server, SageMaker Endpoints, FastAPI |
| 実験トラッキング | MLflow, Weights & Biases, Neptune |
| 監視 | Evidently AI, WhyLabs, カスタムPrometheusメトリクス |
| 使用すべきケース | 避けるべきケース |
|---|---|
| 定期的な再トレーニングが必要な本番環境のMLモデルがある場合 | MLが問題を解決するかどうかまだ探求している段階 — ノートブックから始める |
| 複数のモデルが特徴量を共有し、一貫した特徴量エンジニアリングが必要な場合 | 四半期ごとに再トレーニングされるモデルが1つだけの場合 — スクリプトとcronジョブで十分な場合がある |
| バージョン管理されたデータ、コード、モデルによる再現可能なトレーニングが必要な場合 | MLコンポーネントがホスト型LLMへの単一のAPI呼び出しである場合(代わりにAI SDKパターンを使用) |
| モデルのパフォーマンス低下がビジネスメトリクスに直接影響する場合 | チームにパイプラインを運用するMLエンジニアリングスキルがない場合 |
MWは「本番環境ファースト」の考え方でMLパイプラインを構築します。モデルの最適化よりも前に、サービングと監視のインフラストラクチャから着手します。堅牢なパイプラインに組み込まれた平凡なモデルは、ノートブック内の優れたモデルに勝ります。私たちのパイプラインには、自動データ検証(Great Expectations)、トレーニングサービングスキューテスト、シャドウモードデプロイメント(新しいモデルがトラフィックを受信するが結果を返さない)、およびメトリクス回帰時の自動ロールバックを伴う段階的ロールアウトが含まれます。私たちは、ヘルスケア、フィンテック、コンピュータビジョン分野で、1日あたり5000万以上の予測を処理するパイプラインを展開してきました。
ファインチューニングなしでLLMにデータへのアクセスを可能にします。RAGは、汎用言語モデルとドメイン固有の知識との間のギャップを埋めます。