youichiro blog 🐈‍⬛
Published on

MLOps: 機械学習における継続的デリバリーと自動化のパイプライン

Google の MLOps に関するドキュメントを自分用にまとめる

https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning

機械学習(ML)システムの

  • 継続的インテグレーション(CI)
  • 継続的デリバリー(CD)
  • 継続的トレーニング(CT)

の実装と自動化について説明する

効果的な ML を適用するためには次の要素がある

  • 大規模なデータセット
  • 低価格のオンデマンドコンピューティングリソース
  • クラウドプラットフォームでの ML 専用のアクセラレータ
  • ML 研究分野の急速な進歩

MLOps は、ML システム開発(Dev)と ML システムオペレーション(Ops)の結合を目的とする ML エンジニアリングの文化と手段である

MLOps を実践することで、以下のような ML システム構築の全てのステップで自動化とモニタリングを推進できる

  • 結合
  • テスト
  • リリース
  • デプロイ
  • インフラストラクチャ管理

次の図のように、実際の ML システムの中で ML コードはごく一部であり、必要となる周辺要素は膨大で複雑

DevOps と MLOps

DevOps は大規模なソフトウェアシステムの開発と運用における一般的な手法で、CI と CD の 2 つのコンセプトが導入される
ML システムも同様の手法を適用できるが、次の点で他のソフトウェアシステムと異なる

  • チームスキル
    • ML プロジェクトのチームにはデータサイエンティストや ML リサーチャーが含まれ、経験豊富なソフトウェアエンジニアではない場合がある
  • 開発
    • ML には実験的性質があるため、何が機能し、何が機能しなかったかを追跡して再現性を維持することが課題になる
  • テスト
    • ML システムのテストは、一般的な単体テストと結合テストに加えて、データ検証、トレーニングされたモデル品質評価、モデル検証が必要
  • デプロイ
    • ML システムではマルチステップパイプラインをデプロイして、デプロイモデルを自動的に再トレーニングする必要がある
  • 本番環境
    • ML モデルは絶えず変化するデータプロファイルによってパフォーマンスが低下する可能性がある
    • そのため、データの概要統計を追跡し、モデルのオンラインパフォーマンスをモニタリングして、値が想定と異なる場合に通知を送信またはロールバックする必要がある

また、CI/CD においても次のような大きな違いがある

  • CI
    • コードとコンポーネントのテストと検証だけでなく、データ、データスキーマ、モデルのテストと検証も行う
  • CD
    • 単一のサービスではなく、モデル予測サービスを自動的にデプロイする
  • CT
    • ML システムに固有のプロパティであり、自動的にモデルを再トレーニングして提供する

ML のデータサイエンスの手順

ML プロジェクトでは、ML モデルを本番環境に提供するプロセスに次のステップがある

  1. データ抽出
  2. データ分析
    • モデルで想定されるデータスキーマと特性を理解する
    • モデルに必要なデータ準備と特徴量エンジニアリングを特定する
  3. データの準備
    • データクリーニングを行い、データ変換と特徴量エンジニアリングを適用する
    • output: 特定の形式で分割されたデータ
  4. モデルのトレーニング
    • 準備したデータでアルゴリズムを実装し、ML モデルをトレーニングする
    • さらに、ハイパーパラメータ調整アルゴリズムにより、最高性能の ML モデルを入手する
    • output: トレーニングされたモデル
  5. モデルの評価
    • テストデータにおけるモデル出力の品質評価を行う
    • output: モデルの品質を評価するための指標
  6. モデルの検証
    • モデルの予測性能が特定のベースラインより優れていることを確認する
  7. モデルの提供
    • 検証済みモデルを対象環境にデプロイする
    • このデプロイは次のいずれかになる
      • オンライン予測を提供する REST API を使用したマイクロサービス
      • エッジまたはモバイルデバイスへの組み込みモデル
      • バッチ予測システムの一部
  8. モデルのモニタリング
    • モデルの予測性能をモニタリングし、必要に応じて新しいイテレーションを呼び出す

MLOps レベル 0: 手動プロセス

特徴

  • データ分析、データ準備、モデルトレーニング、検証などの各手順を手動で行う
  • モデルを作成するデータサイエンティストと、予測サービスとしてモデルを提供するエンジニアが分離されている
    • トレーニングサービススキューが発生する可能性がある
      • モデルのトレーニング時と提供時で、以下のような要因でパフォーマンスに差が生まれる
        • データハンドリングの違い
        • データの違い
        • モデルとアルゴリズムの間のフィードバックループの違い
  • モデルの変更が少ないことを前提としており、新しいモデルバージョンは年に数回しかデプロイされない
  • CI がない
  • CD がない
  • デプロイは ML システム全体ではなく、予測サービスとしてのトレーニング済みモデルのデプロイのみ
  • パフォーマンスモニタリングがない

MLOps レベル 1: ML パイプラインの自動化

レベル 1 の目標は、ML パイプラインを自動化することにより、モデルの継続的トレーニングを実行すること

特徴

  • テストの自動化
  • ライブパイプライントリガーに基づいて、本番環境で新しいデータを使ってモデルが自動的にトレーニングされる
  • コンポーネントとパイプラインをモジュール化し、再利用・再構成可能な状態にする
    • 開発環境と本番環境でコードを再現可能にする
    • パイプライン内の各コンポーネントを分離し、各コンポーネントは独自のランタイム環境、異なる言語とライブラリを持つことができる
  • 本番環境の ML パイプラインを用意し、新しいデータでトレーニングされたモデルを予測サービスに提供するデプロイ手順を自動化する
  • レベル 0 ではモデルのデプロイのみだったが、レベル 1 ではトレーニングパイプライン全体をデプロイする

追加コンポーネント

  • データの検証
    • モデルトレーニング前に、モデルを再トレーニングするか、パイプラインを停止するかを決定する
    • 以下の場合に自動的に決定を行う
      • データスキーマスキュー
        • 想定するスキーマに準拠しないデータが入力された場合、パイプラインを停止して調査する必要がある
      • データ値のスキュー
        • データパターンが変化しており、モデルの再トレーニングをトリガーして変化をキャプチャする必要がある
  • モデルの検証
    • 新しいデータでのモデルのトレーニングが終了後、生成された評価指標値を現在のモデルと比較し、パフォーマンスが優れていることを確認する
  • Feature Store
    • Feature Store は、一元化されたリポジトリで、特徴量の定義、保存、アクセスを標準化するもの
    • 特徴値の高スループットのバッチ機能と、低レイテンシのリアルタイムでのレスポンスの両方の API が必要
    • データサイエンティストが以下を行うのをサポートする
      • 同じ特徴量や類似の特徴量を、再作成するのではなく、見つけ出し再利用する
      • 特徴量とメタデータを関連付ける
      • 最新の特徴量を提供する
      • Feature Store をテストやトレーニング、サービス提供のデータソースとして使用することで、トレーニングサービングスキューを防ぐ
        • トレーニングで使用される特徴量が、サービス提供時に使用される特徴量と同じになる
        • Feature Store からオフライン抽出してテストを実行できる
        • CT 時に最新の特徴量を使用できる
  • メタデータ管理
    • パイプラインを実行するたびに、メタデータストアは次のメタデータを保存する
      • 実行されたパイプラインとコンポーネントのバージョン
      • パイプラインの各ステップの開始日時、終了日時、かかった時間
      • パイプラインに渡されたパラメータの引数
      • パイプラインの各手順で生成されたアーティファクト(データの保存場所、異常値、統計量、抽出した語彙など)
        • 途中で失敗した場合、失敗した手順から再開できる
      • 前のトレーニング済みモデルのパスや評価指標
        • ロールバックしたり評価指標の比較したりできる
  • ML パイプライントリガー
    • ユースケースに応じて本番環境のパイプラインを自動化して、新しいデータでモデルを再トレーニングできる
      • オンデマンド(手動実行)
      • スケジューリング
      • 新しいトレーニングデータが利用可能になったとき
      • モデルのパフォーマンスが低下したとき
      • データ分布の大幅な変更があったとき

MLOps レベル 2: CI/CD パイプラインの自動化

CI/CD を自動化することで、データサイエンティストは特徴量エンジニアリング、モデルアーキテクチャ、ハイパーパラメータに関する新しいアイデアを迅速に探索できる

この MLOps には次のコンポーネントが含まれる

  • ソースリポジトリ
  • サービスのテストとビルド
  • デプロイ
  • モデルレジストリ
  • Feature Store
  • ML メタデータストア
  • ML パイプラインオーケストレーター

CI/CD 自動化パイプラインのステージ

  1. 開発とテスト
    • 新しいアルゴリズムとモデルを繰り返し試行する
    • output: ソースコードをソースリポジトリに push する
  2. パイプラインの継続的インテグレーション(CI)
    • ソースコードをビルドしてテストを実行する
    • output: 後のステージでデプロイされるコンポーネント(パッケージ、実行可能ファイル、アーティファクト)
  3. パイプラインの継続的デリバリー
    • CI で生成されたアーティファクトを対象環境にデプロイする
    • output: デプロイされたパイプライン
  4. 自動トリガー
    • スケジュールまたはトリガーに基づいて、本番環境でパイプラインが自動的に実行される
    • output: モデルレジストリにトレーニング済みモデルを push する
  5. モデルの継続的デリバリー
    • トレーニング済みモデルを予測サービスとして提供する
    • output: デプロイされた予測サービス
  6. モニタリング
    • ライブデータに基づいてモデルのパフォーマンスに関する統計情報を収集する
    • output: パイプラインを実行するトリガーまたは新しいテストサイクルを実行するトリガー

本番環境に ML を実装することは、モデル予測用の API をデプロイすることだけでなく、新しいモデルの再トレーニングとデプロイを自動化できる ML パイプラインをデプロイすることを意味する
CI/CD を設定すると、データやビジネス環境の急速な変化に対応できる