機械学習のワークフロー

機械学習ワークフローのフェーズ

• ユースケースの概念と定式化
• フィージビリティスタディと探索的分析
• モデルの設計、トレーニング、およびオフライン評価
• モデルの展開、オンライン評価、および監視
• モデルのメンテナンス、診断、および再トレーニング

関連する人事と役割

• 意思決定者：財布の紐を持ち、資金とリソースを絞ることができます（利害関係者と同じである場合があります）。
• 利害関係者：問題を気にするビジネスパーソン。潜在的なソリューションのビジネス価値を述べ/定量化できます。
• ドメインエキスパート：ドメインと問題を理解し、データについても知っている人（関係者と同じかもしれません）。
• データサイエンティスト：ビジネス上の問題を明確に定義されたMLタスクに変換し、1つ以上の可能なアプローチを提案できるMLエキスパート。
• データエンジニア：データベース管理者（DBA）またはデータがどこにあるかを知っている類似者は、そのサイズと内容についてコメントできます（データサイエンティストと同じかもしれません）。
• システムアーキテクト/ DevOps：システムアーキテクトまたはビッグデータおよび本番ソフトウェアインフラストラクチャ、展開などの専門家。

ユースケースの構想と定式化

目標：データ集約型のビジネス問題を特定し、潜在的な機械学習ソリューションを提案します。

タスク：

• ユースケースを特定し、ビジネス価値を定義します（労働/コストの節約、不正防止と削減、クリック率の向上など）。
• 異常の検出や分類など、ビジネス問題を機械学習タスクとして再記述します。
• 「成功」を定義する-メトリック（AUC​​など）と最小許容パフォーマンスを選択し、潜在的なビジネス価値を定量化します。
• 関連する必要なデータと利用可能なデータソースを特定します。
• 迅速で汚れた文献レビュー。
• 必要なシステムアーキテクチャを定義します。
• 潜在的なリスクの原因を評価します。
• 適切な場合、委員会の探索的分析または実行可能性調査。

人：

• クリティカル：意思決定者、利害関係者、データサイエンティスト。
• その他：ドメインエキスパート（利害関係者が問題を知らない場合）、データエンジニア（DSがデータシステムを知らない場合）、システムアーキテクト（展開について議論する場合）。

実現可能性調査と探索的分析

目標：重要なエンジニアリングリソースが使用される前に、ユースケースを迅速に調査してリスクを取り除き、「go / no go」の推奨事項を作成します。フェーズ3（モデルトレーニング）と重複します。ただし、ここでは完全に調整されたモデルは期待できませんが、また、再利用可能なソフトウェアアーティファクトを生成することも期待していません。

タスク：

探索的データ分析（EDA）：記述統計、視覚化、ガーベッジデータ/ノイズ/外れ値の検出、S / N比の定量化。

• MLのデータの適合性を定量化する：レコードと機能の数、ラベルの入手可能性と品質。
• 実験的（トレーニング/テスト分割）プロトコルを指定します。
• 実験データセットを構築するための高速データETL（抽出、変換、ロード）およびベクトル化（これはおもちゃのサブセットにすぎない可能性があります）。
• 提案された機械学習アプローチの短いリストによる徹底的な文献レビュー。
• 予測信号の存在（または不在）を評価するために、MLモデルをトレーニングおよび評価します。
• 「go / no go」を推奨します。

人：

• データエンジニア、データサイエンティスト：データの調査、実験の実行、レポートの作成
• 利害関係者、ドメインエキスパート：必要に応じて質問への回答
• 意思決定者、利害関係者：最終レポート/推奨の使用モデル設計、トレーニン

グ、およびオフライン評価利用可能なデータ、計算リソース、時間。
将来のモデルの再トレーニングのために、信頼性が高く再利用可能なソフトウェアパイプラインを構築します。

目標

利用可能なデータ、計算リソース、および時間を考慮して、可能な限り最高のパフォーマンスのモデルをトレーニングします。将来的にモデルを再トレーニングするための、信頼性の高い再利用可能なソフトウェアパイプラインを構築します。

タスク

• 実験の完全なセットを計画します。
• 構成可能、完全にテスト済み、スケーラブル、自動化可能なデータETLおよびベクトル化パイプライン。
• 構成可能、完全にテスト済み、スケーラブル、自動化可能なトレーニングコードをモデル化します。
• 「オフライン」（ライブではなく、保留中のデータ上）モデルの評価コード。構成可能、完全にテスト済み、スケーラブル、自動化可能。
• モデルの設計、トレーニング、および評価。
• モデルトレーニングの調整とデバッグ。
• 競合モデル、ハイパーパラメーターの徹底的な経験的比較。
• 実験とモデルのパフォーマンスをこれまでに文書化します。
• 展開可能なアーティファクト（変換、モデルなど）を保存します。

人

• データエンジニア：ETL、必要に応じてインフラストラクチャでDSを支援します。
• データサイエンティスト：モデルのトレーニングと評価を計画および実行し、「レポート」を作成します（ツールによって自動化）。
• 関係者、ドメインエキスパート：必要に応じて質問に答えます。進行状況/パフ

ォーマンスに関する「レポート」を使用します。意思決定者、関係者：進捗/パフォーマンスに関する「レポート」を使用します。モデルの展開、オンライン評

価、監視

目標

• トレーニングされたモデルをサービスとして展開し（必要に応じて変換し）、他のソフトウェア/プロセスと統合します。
• 展開されたモデルのステータス、パフォーマンス、および精度を監視および記録します。

タスク

• REST APIなどを介して、モデルを消費可能なソフトウェアサービスとして展開（および変換）します
• 試用版の展開と実験を計画および実行します。
• 制御されたステージング環境に展開し、ライブデータのパフォーマンスと精度を測定しますが、公開しません。
• A / Bテストを設定および管理して、たとえば新しいモデルと古いモデルを比較します。
• 展開のエラーをログに記録して検出します。たとえば、スキーマがライブデータと一致しないため、変換が失敗します。ベクトル化された無効なデータ入力サイズが原因でモデルが失敗します。
• ライブデータのモデルのパフォーマンスと精度をログに記録して追跡します。-予測スループットが低い（サーバーを追加する必要がある場合があります）精度が低い（モデルをロールバックする必要がある場合があります）。

人

• 「ゲートキーパー」：誰かまたは一部のグループがモデルの「祝福」に責任を負う必要があります。つまり、モデルを公開することを決定します。
• システムアーキテクト：モデルを展開し、モデルのステータスとパフォーマンスを監視します。
• データサイエンティスト：A / Bテスト（または他のトライアル展開）を計画し、モデルの正確性に関するレポートを使用します。
• 関係者、ドメインエキスパート：必要に応じて質問に答えます。モデルの精度に関するレポートを使用し、フィードバックを提供します。

モデルのメンテナンス、診断、および再トレーニング

目標

• 長期間にわたって展開モデルの精度を監視および記録します。
• 展開されたモデルの統計を収集して、トレーニングと展開にフィードバックします。

タスク

• 展開されたモデルが「古くなる」までの時間など、展開されたモデルの統計を収集します（つまり、ライブデータの精度が許容可能なしきい値を下回ります）。 モデルの不正確さのパターン（新しい機能を考慮したり、誤った仮定を修正するためにモデルアーキテクチャを再設計する必要がある場合があります）。
• トラッキングパフォーマンスからの洞察に基づいて、新しい仮説または実験を策定します。

人

• システムアーキテクト：モデルの状態とパフォーマンスを監視します。
• データサイエンティスト：モデルの精度に関するレポートを使用します。
• ステークホルダー、ドメインエキスパート：必要に応じて質問に答える。 モデルの精度に関するレポートを使用し、フィードバックを提供する。