クラウド同上

【Next’19 Tokyo レポート】Cloud AI Platformにおける機械学習モデルのライフサイクル

Author
tsk
Lv:6 Exp:1174

MLチームの新人エンジニアです

8/1 17:20~18:00@東京プリンスホテル
Speaker : 春日瑛(DeNA)、内田誠(Google Cloud)

機械学習モデル→システム

機械学習モデルは作っただけではだめで、周りの運用環境も整えることが必要となる。
運用環境が悪いとモデルの性能が出なかったりする。

学習データの齟齬、変化、劣化

プロダクション環境で学習が想定通り進まない原因としては、
分布(データの偏り)、前処理、フォーマット、特徴量の変化
が挙げられる。

モデルのバイアス、劣化

プロダクションで想定通りのモデルの性能が出ない。
特定のデータに対する高い誤差
予測精度のなだらかな劣化
これらを改善するためにモデルを継続的に学習、デプロイする仕組みをローンチする必要がある。

タクシー配車アプリMOV(DeNAの事例)

実は日本での歯医者は99%が流し、つまり路上でお客さんを捕まえる。
これは運転手の経験や運によるところが大きい。
→タクシー探客(お客さんを探す)を行うAIを使うことでより効率的にする。

現在位置から探客がうまくいくルートへの誘導を目的とした。

大まかな流れ

1.BigQueryによりタクシーのプローブ情報を収集
2.流し需要の分析
3.機械学習によるリアルタイム需要供給予測
4.Cloud Composerで定期的に最新データの読み込み、推論ジョブを5分単位で実行

※プローブ情報:実際に自動車が走行した位置や車速などの情報を用いて生成された道路交通情報

大きな問題

依存関係の複雑さ

担当者がデータ処理の流れを手動で実行しているためヒューマンエラーが起きやすい。

更新頻度の高さ

季節、天候、イベント、施設の閉館などタクシー需要動向に合わせる必要がある。
そのために最新データを常に使用する必要がある。

実験管理問題

実験段階で様々な学習を回している時
– 前回の実行パラメータは?
– YAMLを確認しよう
– あれ?なんか違う
– 参照するYAML間違えた?
といったようなミスがファイル管理(YAML)だと起きてしまう。

解決:Kubeflow Pipelineの導入

依存関係の定義

各種統計量、前処理、コンテナビルド、評価、デプロイ
をそれぞれ定義する。
それぞれのチェックをパスした場合、Cloud Composerにデプロイされる。

定期自動デプロイ

スケジュール登録し、毎日実行する。
精度に問題があればデプロされない。

実験管理機能

  • 各実験の選択・比較が可能
  • パラメータ差分の確認が容易

Kubeflowの良い点

パラメータ管理

実行時に任意のパラメータを実行できる。
モデルのハッシュ、イメージのハッシュを次のモデルに渡すことができる。

コンテナドリブン

もともとDockerベースで開発しており、親和性が非常に高い。
これはDeNAの事例の場合だからと考えられる。

ログ確認

コンテナジョブのログを確認でき、効率的なデバッグが可能となる。

Kubeflowの課題

  • 失敗時の途中再実行ができない
  • サービスアカウントでの制限をかけられない

タクシー配車アプリの概要の復習

モデルの構築

プロトタイプ→プロダクションに利用
– パッケージ、実行環境
– CPU、GPU、リソース管理
– コンテナ
– GKE+Kubeflow、AI Platform

データ検証

TensorFlow Data Validation(TFDV)
– CSV,JSON,TFRecordなど
– TBスケールのデータセットに対応
– 学習前にデータを検査

モデル検証

TensorFlow Model Analysis(TFMA)
– TensowFlowモデル
– TBスケールのテストデータセットに対応
– デプロイ前にバイアスを検証

機械学習パイプライン

  • 各々の要素タスクを統合
  • プロダクション運用のためのセキュリティ・モニタリング・アラート
    (参考)TensorFlow Extended

Kubeflow Pipelineの利用

  • フレームワーク非依存
    TnsorFlow,XGBoost,Pytorch
  • インフラ非依存
    GKE,GKE On-Prem
  • GCPインテグレーション
    Dataflow,Dataproc,AI Platform
  • エクスペリメンテーションからプロダクションへの移行
  • 再現性
  • 組み合わせ
  • 再利用
    以上のようなことが実現できた。

アーティファクトとメタデータ

  • アーティファクト
    機械学習システムのオントロジ
    データ、モデル、統計量、特徴量
  • メタデータ
    バージョン、系統依存関係、タスク実行ログ
  • 機械学習パイプラインはメタデータによるアーティファクト駆動
    転移学習、追学習、クロスバリデーション、Next-dayモデル検証、Training-Servicing Skew検知

これらを変化させることができるために、モデルの運用も容易になる。

まとめ

Cloud AI Platformの機械学習システム開発
AI Platformによってデータサイエンティストによるモデルの構築と、プロダクション環境での運用とのギャップを解決

  • モデルのローンチ→モデルをデプロイするパイプラインをローンチ
  • 手動によるモデルの管理→パイプラインによって継続的にモデルをデプロイ
  • 学習データの齟齬→メタデータ管理によって学習前にデータを検証
  • モデルのバイアス・劣化→メタデータ管理によってデプロイ前にモデルを検証

以上のように改善することができる。

感想

最近社内でも(MLのチーム内)話題になっているMLシステムの事例の参考として聞きに行きました。
MLモデルを運用するのに必要なマインドなどが非常によくまとめられていたと思います。Kubeflow Pipelineをしっかり説明する発表を聞いたのは初めてだったのでとても新鮮でした。

次の記事を読み込んでいます
次の記事を読み込んでいます