nokoのブログ

こちらは暫定のメモ置き場ですので悪しからず

MLSE機械学習基盤本番適用と運用の事例・知見共有会参加レポート

はじめに

メモ

ゼロから始めるKubeflowでの機械学習パイプライン構築

  • Reproさん
  • Cloud Composer → Kubeflow
  • プロセスに「実験デザイン」の手法を導入
    • 試行錯誤の手続きを標準化
    • 生命科学の実験デザイン」
  • TFXを導入
    • 機械学習を利用するシステムの設計思想
    • コンポーネントはストレージからデータを読み込み、処理結果をストレージに格納する
  • 実験基盤、検証基盤、サービス基盤
  • 机上実験 → パイプライン実装(FS)
  • Kubeflow Pipelines(AI Platform Pipelines)を選定
    • マネージド、スケーラビリティ、BQ、利用ライブラリを柔軟に選べる(コンテナ)
  • 可視化
    • Feature Importance
    • AUC
    • 損失
  • 通知
    • OOMとか
  • Terraform, CI/CDパイプライン
  • 残課題
    • データ取得のために似たようなコードを書いている
    • 「データサイエンスから秘密のベールを引き剥がし、退屈な仕事にする」
    • サービス基盤は「Human in the loop」
    • Feature Storeの導入
      • ただ、ハードル高い?(費用対効果)
  • 再現性
    • ノートブックの実装とパイプラインの実装は別
  • Apache Airflowはデバックが辛かった?
    • PodのOOMとか。Kubeflowなら検知できる?
    • AI Platformなら、DockerのログがCloud Monitoringに出力される?

リーガルテックにおけるMLOps構築事例の紹介

  • 研究開発チームは、マイクロサービスなAPIを提供するところまで
  • 機械学習のフローだいたいインフラ関わる説
  • 課題
    • マイクロサービス化されたAPI
    • 学習を回す場所がない
    • 実験管理・再現性の問題
      • 再度モデルを作ることができない
      • 問題が起きたときに前の状態に戻れない
      • API開発と機械学習の分離
    • →学習、評価・実験管理→デプロイ に絞って改善
  • 実験管理、モデル/データ管理はMLflow
  • 学習はAI Platform Training Job
  • モデルサービングはSeldon Core
  • 学習基盤の拡張性
    • 学習リソース管理
    • 導入・維持コスト
    • ドキュメント
    • 拡張性
  • MLflow Model Registry
    • Stageを設定し、モデルのバージョンを切り替えることが可能
  • Seldon Core
    • GKEにHelmで入る
    • 推論のPipeline化が特徴
      • エンドポイントを組み合わせ(前処理できる)
    • Dockerfile内でエンドポイント起動ができる
  • MLOpsの効果
    • アジリティ
    • 再現性
    • 自動化・非属人化
  • レポジトリ・コードの雛形化
  • MLを含んだインテグレーションテスト
  • アノテーションはツール使って人手
  • MLflowは小規模でも使いやすい

PLAIDにおけるリアルタイム予測基盤

  • KARTEの解析データはPB級
  • 予測結果は前のeventで予測済みの結果をDBから取ってくる
  • 非同期に渡しておく
  • 連続性のある事象を取り扱う場合は、過去のデータを利用することでサービス提供におけるレイテンシを守る、という事例
  • 推論APIに直接データを渡す訳ではなく、APIにDBのキャッシュを渡す
  • Cloud Spannerを利用
    • (もちろん)BQと全く同じSQLとはならない
    • Bigtableなども検討中
    • TTLがなく、キャッシュが貯まり続ける
    • 実行計画は見える
  • Prediction APIにはCloudRunを利用
    • イメージを指定すればコマンド一つでデプロイ可能
    • 切り戻しもしやすい

モバイル向け機械学習モデル管理基盤

  • サーバで推論を行う場合、1secとかかかる。滑らかな体験のためには、100msec未満が必要。
  • クライアント側で実行すれば、セキュアでもある
  • TF Liteへの変換で軽くなる
    • 情報量は落ちたり
    • モデルの蒸留に加えて、変数の型を小さくしてメモリサイズをコントロールしたり
  • Edgeモデル検証用プラットフォーム
    • モデルごとやデバイスごとの精度・性能評価などを自動化
    • 物理デバイスでのテストをパイプラインに組み込む
  • Firebase Test Lab
    • カバーできないリアルデバイスもある
  • チームとして、Kubeflowを運用している

大規模・複雑な機械学習プロダクトの継続的な改善を支える実験プラットフォーム

  • ドライブチャート
    • エンジニア30名体制
  • エッジデバイスが収集したカメラデータ、センサデータがインプット
  • エッジ時点で、ディープラーニングモデルが特徴量を抽出
  • エッジとレポートの一貫したテスト
    • 結合テストの実施
    • → Kubeflowでパイプラインを
    • Feature Storeを内製
  • Kubeflow Pipeline
    • パラメータのセット、テストデータの準備、実行環境の構築
    • 実験の実行をWeb UIで完結できる
  • feature store
    • テストで抽出した特徴量をFeature Storeに保存
    • テストパイプラインと開発者の間で特徴量を共有する
      • 必要な機能が限定的なため、内製
    • 各データがバージョンを持つ
    • バージョンが同じ特徴量をテスト間で再利用する(キャッシュ)
    • dfをそのまま入出力できるインターフェイスを提供
  • データセット生成はETL Systemへ集約
    • データガバナンスを担保
    • テストで用いたデータは永続化する

ポイント

  • 実験デザインの手法
  • TFXの思想
  • Kubeflow Pipelines(AI Platform Pipelines)でできること・利用コスト
  • Human in the loopを上手く導入するには
  • OOMの通知
  • サービングのSanity Check
  • training-servinng skew対応として、DataflowとTFTを用いた変換(Google
  • delegation
  • Feature Storeに求める役割