本文（初稿）

MLOpsの歩き方

MLOpsとは

技術的負債の論文からの定義みたいなもの
- モデリングはごく一部で、実際にはその周辺の話が多い
MLCT, MLSE, OpMLといったカンファレンスやミートアップ、研究会も
大まかな課題
- DS vs Eng
  - 典型的なML workflow
  - (ボツ)典型的なML pj workflow
    - ビジネス課題を定式化する & KPI設計
    - 機械学習をしないで良い方法を考える
    - システム設計を考える
    - 学習データ（特徴量）の設計をする
    - 実データの収集と前処理をする
    - 探索的データ分析とアルゴリズムの選定をする
    - 学習・パラメータチューニング
    - システムに組み込む
- 実験結果を再現する難しさ
- 継続的な改善
話さないけど大事な話
- ビジネスの目的とKPIと予測性能

MLOpsとしての共通課題

役割の溝・組織の溝
- DS vs Eng
- コンウェイの法則
- 予測結果がいつの間にか利用される
  - データの流れを追いづらい
Data defines everything
- CACE: Change Anything Change Everything
- Monitoring, updating models
- Pipeline jungle
  - Dataや予測結果への意図しないdependency
- アプローチ
  - Schema for data
決定的なテストがしづらい
- 乱択アルゴリズムが入るため、決定的には記述できない
- アプローチ
  - Gold standardを用意してmetricsをモニタリングする
  - データ自体の検証をする
  - ノイズを加えても頑健に動くかを検証する
Productionization
- データの場所と処理の場所の違い
  - DWHとラップトップ
- 実験の場所と本番の場所の違い
  - ラップトップとバッチ処理サーバー
- Quality of code
  - DSはJupyter notebookを好みEngはそれを押し込めたがる
- Complex dependency
  - GPU周り
  - native dependency
  - Python libraryのversion
- デプロイどうするの？
  - Batch style (shared DB)
    - 予測結果をshared DBに格納する
  - On demand style
    - RPC/REST server
    - Containerが便利
    - ONNX, PMML, PFAなどの中間表現
    - TF servingのような頑健なserving server
  - Inference on edge
    - Model conversion
    - Federated learning
Reproducibility
- repeatability: "running the same experiment and getting the same result in the same lab" ref: [1]
- 実験自体の再現性
  - 属人性を低減させる
- 本番環境での再現性
  - ラップトップとサーバでの実行を同一のものに担保する
Versioning
- 問題が発生したときに
  - 切り戻しができるか
  - Debugしやすい状況を作れるか
- 管理対象
  - Model
  - Pipeline
  - Data

どのようなアプローチがあるか？

Data management
- データのクオリティの確認と検証、モニタリング
  - Google TFX
    - Data validation
    - Schema for data
  - Airbnb Zipline
  - Uber Michelangelo
- 適切な権限管理と強いSLA(service level agreement)の設定が重要（TFX）
- Data dependencyについてはTFXくらいしか言及されていない
特徴量の共有
柔軟なデータの処理
Deployment
前処理やML frameworkの抽象化