利益:
- コード、データ、モデルのトリオとパッケージに関連する ML の特別な課題を認識し、ビジネス ニーズに応じてモデルをオンラインまたはバッチで提示する能力。
- 段階的およびロールバック展開パターン (シャドウ、カナリア、A/B、ロールバック) を実装し、テスト済みのロールバック プランを各展開に追加する機能
- 評価しきい値で制御された CI/CD およびモデル レジストリを使用して、本番環境に導入されたモデルのデータとコードとメトリックのリンクを追跡可能に保つ機能
ノートブックで 95% の精度を達成するモデルを取得するだけでは、まだ半分にすぎません。残りの半分 (多くの場合、困難な部分) は、信頼性が高く、スケーラブルで、保守可能な方法でそのモデルを実際のユーザーに提供することです。 MLOps (機械学習オペレーション: ML モデルを実稼働環境に導入、運用、保守する規律) は、ソフトウェア エンジニアリングの DevOps プラクティスと ML 特有の課題を組み合わせたものです。この単元では、モデルを運用環境に移行する手順と、このプロセスで人工知能がどのように役立つかについて説明します。
ML が通常のソフトウェアと異なるのはなぜですか?
通常のソフトウェアでは、動作はコード内にあります。コードが変わらなければ動作も変わりません。 ML では、動作はコード、データ、モデルの両方に依存します。これら 3 つの側面により、MLOps にさらなる課題が生じます。
- データ ドリフト: 実稼働環境のデータは、時間の経過とともにトレーニングのデータから離れていきます。モデルが時代遅れになります。
- コード、データ、モデルの 3 つをバージョン管理する必要があります。この 3 つすべてをバージョン管理する必要があります。
- サイレント障害: モデルは、単に間違った予測を生成するだけで、クラッシュせず、エラーも発生せずに失敗する可能性があります。これを把握するには監視が必要です。
「実用モデル」と「実稼働対応モデル」の間には大きな違いがあるのはこのためです。
モデルのパッケージ化とプレゼンテーション
モデルを実稼働環境に導入するための最初のステップは、モデル ファイル、必要なライブラリ、前処理コード、およびバージョン情報を、再現可能な全体としてまとめてパッケージ化することです。ここではコンテナ化 (例: Docker: アプリケーションをすべての依存関係とともに隔離されたボックスに入れる) が標準です。これにより、「私のマシンでは動作していました」という問題が解消されます。
モデルを提供する 2 つの基本パターン:
- オンライン/リアルタイム (オンライン): モデルは API の背後にあり、受信リクエストごとに即時の予測を返します。低遅延は重要です。
- バッチ: モデルは大規模なデータセットを定期的に処理します (例: 夜間にすべての顧客のスコアを生成します)。遅延は関係なく、効率が重要です。
どちらが正しいかは、ビジネス ニーズによって異なります。オンラインでの即時推奨、バッチでの月次リスク スコアなどです。
ヒント: 「リアルタイム」はコストであり、デフォルトではありません。結果を数時間以内に使用する場合は、バッチの方がはるかに安価で簡単です。本当にすぐに答えが必要ですか?まずそれを聞いてください。
安全な配布戦略
新しいモデルをすべてのトラフィックに対して直接開くのは危険です。それが間違っていれば、全員が影響を受けます。安全な配布パターン:
- シャドウ デプロイメント: 新しいモデルは運用トラフィックを受信しますが、その予測はユーザーには表示されず、ログに記録されるだけです。実際のデータで安全かどうかを旧モデルと比較しています。
- カナリア展開: 新しいモデルは、最初はトラフィックの少数の割合 (例: 5%) に展開されます。問題がなければ徐々に増やしていきます。
- A/B テスト: 2 つのモデルが実際のユーザーに並行して提示され、ビジネス指標 (コンバージョン、クリック) が比較されます。
- ロールバック: 新しいモデルに問題があることが判明した場合に、古いバージョンにすぐに戻す機能。すべての展開にはロールバック計画が必要です。
注意: ロールバック計画のない展開は完了しません。数分以内に古いバージョンに戻すことができるため、運用環境で新しいモデルが予期しない動作をした場合にユーザーを保護できます。導入前にこれをテストしてください。
弱いアプローチ / 強いアプローチ
弱者: 「モデルのテストは良好で、実際に稼働し、全員に公開しました。」
Güçlü: 「モデルをコンテナ化し、バージョンとしてラベル付けしました。まず、運用トラフィックを使用してシャドウ モードで 3 日間実行し、古いモデルと予測を比較しました。偏差は許容範囲内でした。次に、5% のカナリアで開き、スループット メトリックと遅延を監視しました。問題がなければ、徐々に 100% まで上げました。事前にロールバック コマンドをテストしていました。」
違い: 強力なアプローチは段階的で、慎重で、可逆的です。リスクはあらゆる段階で限定されます。
CI/CD と自動化
ML の CI/CD (継続的インテグレーション / 継続的デプロイメント: コード変更を自動的にテストしてリリースするパイプライン) は、コードだけでなくデータとモデルのステップもカバーします。優れた ML CI/CD パイプライン: コードが変更されたときにテストを実行し、データ検証を実行し、モデルを (必要に応じて) 再トレーニングし、評価しきい値をチェックし、しきい値が維持されている場合にのみデプロイを進めます。 「トレーニングは自動、展開はしきい値ベース」という原則により、不正なモデルが静かに本番環境に漏洩することを防ぎます。
AI は、構成ファイル (YAML) のドラフト、テスト ケース、デプロイメント スクリプトの作成などのパイプラインを設定するときに非常に役立ちます。ただし、配布しきい値 (公開される値を超えるメトリック) とロールバック ポリシーはユーザーが決定します。これらはビジネスリスクに関する決定です。
再現性インフラストラクチャ
本番環境でモデルの動作を再現するために、モデル レジストリ: どのモデルがどのデータとコードでトレーニングされたか、どのモデルが受け取ったメトリクスを保持する記録です。各運用モデルについて、トレーニング データのバージョン、コード バージョン (git commit)、ハイパーパラメータ、評価スコア、デプロイメント日を追跡できる必要があります。問題が発生した場合、「どのモデルがどのデータを使用してこの予測を生成したのか?」という質問に答えられる必要があります。数分以内に。これについては単元 11 でさらに詳しく説明します。
ミニケース3個
ケース 1 - シャドウ配布によって問題が発生しました。推奨モデルはテストで古いモデルを上回りました。シャドウ モードで運用トラフィックを使用して実行すると、特定のユーザー セグメント (新規ユーザー) に対して非常に不十分な推奨事項が生成されることがわかりました。テスト データはこのセグメントを十分に代表していませんでした。モデルはユーザーに表示されることなく修正されました。直接開くと、新しいユーザー エクスペリエンスが中断されてしまいます。
ケース 2 - 取消不能な配布。チームは、ロールバック計画なしで、すべてのトラフィックに新しい料金モデルを展開しました。このモデルは予想外に一部の製品の価格を非常に安くしました。プロセスの準備が整っていなかったために、古いバージョンに戻すには数時間かかりました。深刻な収入減があった。その後、必須のロールバック テストがすべての展開に追加されました。
ケース 3 - サイレント データ ドリフト。不正パターンは何ヶ月もエラーなしで出現しました。しかし、詐欺師の戦術が変わり（データドリフト）、モデルのリコールは静かに減少しました。監視がなかったため誰も気付かなかった。予測分布監視委員会が設置されると、ドリフトは早い段階で可視化されました。 8 号機のモニタリングについて説明します。
コピー可能なテンプレート
このモデルの展開計画の草案を作成します。モデル: [機能]、使用法: [オンラインかバッチか?] 以下を含める必要があります:1) パッケージ化 (コンテナー、バージョニング)2) 増分デプロイメント戦略 (シャドウ/カナリア/A-B) とその理由3) 追跡するメトリクス (ビジネス + 技術 + 遅延)4) ロールバック計画とテスト方法5) デプロイメントのしきい値 (どのメトリクスがどの値を超える必要があるか)
この ML CI/CD パイプラインを確認してください:1) データ検証が実行されていますか?2) 評価しきい値を保持せずにデプロイメントを続行できますか (すべきではありません)?3) ロールバックは自動ですか?4) データ + コード + メトリクスはモデル レジストリで追跡されていますか?Pline 構成: [config]
オンライン プレゼンテーションとバッチ プレゼンテーションのどちらがこのモデルに適しているかを判断してください。結果が使用される期間: [インスタント / 分 / 時間 / 日] 予想されるリクエスト量: [数値] 遅延制約があるか: [ミリ秒] コストと複雑さの観点からどれをお勧めしますか?またその理由は何ですか?
このモデルのロールバック手順を作成します。- パフォーマンス低下の原因となるメトリック/しきい値は何ですか?- ロールバック手順は何ですか?- ロールバックにかかる時間 (目標) はどれくらいですか?- 運用前にこの手順をテストするにはどうすればよいですか?
プレゼンテーションパターン表
基準
オンライン（リアルタイム）
バッチ
遅延
クリティカル (ミリ秒)
取るに足らない
使用法
即時対応が必要
定期的なスコア
コスト
高い
低い
複雑さ
高い
低い
例
ライブ推奨、詐欺
月次リスクスコア
よくある間違い
- 回収の計画を立てずに配布する。間違ったモデルはユーザー全体に打撃を与えます。
- 100% のトラフィックに対して直接オープンします。時間をずらして配布することでリスクを制限します。
- 監視を確立していない。モデルは、エラーを発生させることなく、サイレントにエラーを生成します。
- 冗長なリアルタイム プレゼンテーション。バッチ処理で十分ですが、コストと複雑さが増大します。
- モデル、データ、コードのバージョンがリンクされていません。問題を再現することはできません。
- 配布しきい値なしの自動リリース。悪いモデルは静かに侵入します。
要約すると
モデルを実稼働環境に移行することは、トレーニングとは異なるエンジニアリング作業であり、多くの場合、より困難です。 ML はコード、データ、モデルのトリオに依存するため、特別な規律が必要です。パッケージ化とバージョン管理、ビジネス ニーズに合った配信パターン (オンライン/バッチ)、段階的かつ可逆的なデプロイメント、しきい値制御された CI/CD およびモデル登録です。人工知能は、このインフラストラクチャのコードと構成を生成する際の強力な助けとなります。ただし、配布のしきい値、クローバック ポリシー、リスクの決定はあなたが行います。ロールバック計画のない配布は完了しません。
アプリケーションタスク
モデルをコンテナ化 (Docker) し、バージョンのラベルを付けます。ビジネス ニーズに基づいてオンラインまたはバッチのどちらを提供するかを決定し、その理由を記述します。段階的な導入計画 (シャドウまたはカナリア) とテストされたロールバック手順を文書化します。データのバージョン、コードのコミット、評価スコアをモデル レジストリに必ず記録してください。
チェックリスト
- [ ] モデルはパッケージ化され、バージョン管理されます (コンテナー + ラベル)。
- [ ] プレゼンテーション パターン (オンライン/バッチ) はビジネス ニーズに応じて選択されました。
- [ ] 段階的な展開戦略 (シャドウ/カナリア) が実装されました。
- [ ] ロールバック手順が作成され、テストされました。
- [ ] CI/CD は、評価しきい値に達するまで展開を進めません。
- [ ] モデル レジストリには、データ + コード + メトリック リンクが保持されます。