Upgrade to Pro — share decks privately, control downloads, hide ads and more …

機械学習を実用化するエンジニアリングスキル

shibuiwilliam
February 09, 2023

 機械学習を実用化するエンジニアリングスキル

Developer Summit 2023 Inspiredの登壇資料。
https://event.shoeisha.jp/devsumi/20230209/session/4140/

shibuiwilliam

February 09, 2023
Tweet

More Decks by shibuiwilliam

Other Decks in Technology

Transcript

  1. 自己紹介 shibui yusuke • もともと文学部の大学院卒。 • いろいろ → Launchable(いまここ) •

    MLOps & リサーチ & データ基盤 & バックエンド & インフラ & セールス & マーケティングエンジニア ◦ エンジニア採用中! • もともとクラウド基盤の開発、運用 • Github: @shibuiwilliam • FB: yusuke.shibui cat : 0.55 dog: 0.45 human : 0.70 gorilla : 0.30 物体検知 2 https://www.launchableinc.com/careers/senior-software-engineer/
  2. クラウドを作っていた時代の私の原体験 • 2010年、新卒入社した日本のSIerで最初の仕事は会社初のパブリッククラウドの開発と拡販。 ◦ AWSの東京データセンター設置が2011年3月。 ◦ まだ国産クラウドがグローバルカンパニーと戦える可能性の合った時代。 • 物理サーバビジネスで商売していたエンジニア、営業から社内競合として反発。 ◦

    「インフラエンジニアはどうなってしまうんですか・・・?」 • 機械学習エンジニアやデータサイエンティストが将来、新しい技術に置換されない理由はない。 • 新しい技術の実用化、運用、拡販は常に発生する課題である。
  3. • 条件:人、金、時間は有限 • 必要: ◦ 企画:最初の課題解決を成し、再現性を証明する ◦ 技術:変更できるシステムを作る ◦ チーム:スキルとモチベーションを一致させる

    • 有効な場合はあるけど、必要とは限らない: ◦ MLOpsや機械学習基盤 ◦ Kaggleの知識 ◦ 知名度 機械学習を実用化するための エンジニアリングスキル 注目されることが多い こっちのほうが重要
  4. 失敗例(経験談) • tl;dr 価値が出るかわからないのにすごい作り込む • 「最高の」需要予測モデルを作るのに半年かかった • その学習コードが100,000行、100Pythonファイル、10コンフィグファイルで構成され、 1学習にCPU 100coreで12時間かかる

    • 経過時間のほとんどはデータの集計 • オフライン評価は高いが、オンラインでは検証していない • 時系列データをランダム分割している • 反リーダブルコード、非テスト駆動開発 • 最初から高度な自動化と基盤運用が求められる • 作ったエンジニアは運用しない(開発だけ外部に委託契約) • 安定運用するまでに開発物の納入から 1年かかった
  5. 手間 ≠ 価値 little effort huge effort small impact large

    impact MUST Wait until you need it Are you sure? Low risk starting point ここを目指す 必要になってから ここから始めて
  6. 機械学習の施策におけるEffortとImpact little effort huge effort small impact large impact 実績のある既存手法の実用化

    例:ECや検索の推薦 共通基盤や R&Dの伴うモデル開発 例:MLOps、ML基盤 既存システムの再構築や 間違った技術選択 例:基盤の移行、 Fortranで機械学習 既存モデルの活用 例:コピペ、再学習 ここを目指す 必要になってから ここから始めて
  7. 手間≠価値 発注 納入 購入 インフラ クラウド、ネットワーク、アカウント データ基盤 ML基盤 共通基盤 (ログ、モニタリング、

    CI/CD・・・) 推論基盤 BI ML パイプライン 需要予測 基本モデル 需要予測 モデルA 需要予測 モデルB 俺の最強ML基盤
  8. 課題を解くための価値ある施策から始める 発注 納入 購入 インフラ クラウド、ネットワーク、アカウント データ基盤 ML基盤 共通基盤 (ログ、モニタリング、

    CI/CD・・・) 推論基盤 BI ML パイプライン 需要予測 基本モデル 需要予測 モデルA 需要予測 モデルB 今すぐ必要ではないし、 必要になるとも限らない 最低限のビジネス的な 評価すべき価値
  9. 実験(評価と失敗と修正)をプランニングする • 解きたい課題に対して既存のデータと手法が有効か否かを調べるためには実験が必要。 • 課題が解けていることを証明するためには評価が必要。 • 求める評価に至らない場合(実験が失敗した場合)には修正が必要。 • 実験は時間的・金銭的制約の中で実施しなければならない。 ルールベースや

    統計手法 Logistic回帰等 簡単なモデル 特徴量の工夫と GBDT 資金力と意地と Neural Network 諦める オフライン 評価 本番システムで 評価 現状調査と データ収集 本来の実験のゴールはここ ここが一番 たいへんなことが多い 諦めも大事 ここはまだ過程 調査 -> 本番で実験の サイクルを早くしたい
  10. AI商店の需要予測のプランニング PoC・初期フェーズ 発展・拡大フェーズ 需要予測の実用化 オフライン評価 分析と開発 オンライン評価 需要予測 システム開発 現状調査

    課題定義 GO/NO GO判断 需要予測の 自動化開発 チーム化、採用 オフライン評価 分析と開発 現状調査 課題定義 オンライン評価 課題の再定義 開発・運用 スタイルの確立 基盤の整備
  11. やらないことを決める PoC・初期フェーズ 発展・拡大フェーズ 需要予測の実用化 オフライン評価 分析と開発 オンライン評価 需要予測 システム開発 現状調査

    課題定義 GO/NO GO判断 需要予測の 自動化開発 チーム化、採用 オフライン評価 分析と開発 現状調査 課題定義 オンライン評価 課題の再定義 開発・運用 スタイルの確立 基盤の整備 まずはここで成功させる。 こっちは後回しにする。
  12. 手間を最初から見通すことは難しい エンジニアの手間 初の機械学習 実用化 新しい開発 機能 企画時に見えている手間 実際に発生する手間 機能開発は最初に手間が発生 更には機能改善と運用の手間が積み重ねで発生

    運用 再学習 調整 ディープラーニングに 挑戦 モデル更改 リファクタ リング 追加の機械学習 実用化 再学習 リファクタリ ング 機械学習基盤 構成管理 アップデート 再学習 調整 再学習 リファクタリ ング 再学習 調整 モデル更改 リファクタ リング 再学習 リファクタリ ング 再学習 調整 企画時に見えている手間と本当の手間が乖離していくと、 エンジニアの生産性が悪く見えてくる
  13. 基盤の整備 発展させていくための優先順位を考える PoC・初期フェーズ 発展・拡大フェーズ 需要予測の実用化 オフライン評価 分析と開発 オンライン評価 需要予測 システム開発

    現状調査 課題定義 GO/NO GO判断 需要予測の 自動化開発 チーム化、採用 オフライン評価 分析と開発 現状調査 課題定義 オンライン評価 課題の再定義 開発・運用 スタイルの確立 成功 どこから手を付ける?
  14. 新しいものが出たらすぐ便利になるのではなく、 新しいものが再現性を持って実用化されてから便利になる Machine learning Deep learning Generative AI Platform 2011

    2012 2013 2023 2022 2021 2020 2014 2015 2016 2017 2019 2018 BigQuery dbt Kubeflow AlexNet DCGAN TensorFlow DQN AlphaGo AlphaZero XGBoost LightGBM ONNX PyTorch Anaconda GoogleNet ResNet Kaggle SageMaker Keras Core ML MediaPipe TensorRT Nvidia K80 Jupyter Notebook Google Colab Word2Vec Vertex AI MLflow Spark CLIP BERT GPT-3 OpenAI Hidden debt paper Diffusion model HuggingFace AutoML Optuna Katib ChatGPT Snowflake Airflow Cycle GAN Style GAN Magenta VAE CatBoost Flax TFServing TorchServe Stable Diffusion Nvidia A100 TPU Transformer イノベーション イノベーション イノベーション イノベーション イノベーション イノベーション イノベーション イノベーション イノベーション イノベーション イノベーション イノベーション CodeX BQML
  15. 理論から学習へ、学習から推論へ 理論 公開コードまたは 数式から実装 バッチ推論 多くの場合学習と 同じ技術で可能 推論API 学習したモデルを サーバにロードして

    外部リクエストを 受けられるようにする Edge AI 学習したモデルで デバイスにロードして 推論する 公開モデル 再利用可能な 学習済みモデルとして 公開される 学習 数週間〜数ヶ月 数週間〜数ヶ月 数ヶ月〜 論文公開 ここに至るのは 極一部
  16. 変更するつもりで作る • 機械学習モデルやライブラリ、基盤は頻繁に更 新、変更される。 • すべての新しいライブラリや基盤が 後方互換性を保っているとは限らないし、 新しいモデルが常に良いとも限らない。 • 変更頻度と変更難易度を考慮してシステムを設

    計するスキルが求められる。 • 変更がうまくいかない場合はロールバック できるようにしておく。 変更難易度 変更頻度 高 低 低 高 学習データ 学習済みモデル 推論API MLライブラリの更新 GPU データ基盤 ML基盤 永続データ 推論ライブラリ 評価指標 バッチ処理 推論を使う外部システム MLライブラリを変更
  17. 推論から考える • 常に推論できるモデル( =本番システムで使えるモデル)を学習する。 • 推論の優先順位 ◦ まずはルールベースや統計処理で対応可否を検討する。 ◦ 機械学習が必要な場合はバッチ推論(学習と同じシステム構成で可能)を検討する。

    ◦ バッチ推論が利用不可の場合(入力が動的に変わる)、同期推論や非同期処理を検討する。 ▪ ONNXやTensorFlowServing、TorchServeを活用可能なモデルを優先して選ぶ。 ▪ 推論ライブラリを使えない場合はサーバで稼働させた場合のパフォーマンスと安定性を 重点的に検証する。 ◦ ユーザ端末でリアルタイム処理が必要な場合は Edge AIを検討する。 ▪ 本当にリアルタイム性が必要か立ち止まって考える。 ▪ Edge AIで使えるモデルは選択肢が少なく、モデルの更新リリースが難しいことを考慮する。 • 学習の考慮事項 ◦ 推論で活用可能なモデルを学習する。 ◦ 学習基盤はメンバー数とモデル数に応じて徐々に導入する。一度に全部入れる必要はない。 ◦ 【超重要】以下 4点を疎かにしてはいけない。 ▪ リーダビリティ、テスト、インターフェイス、ライブラリ管理。 選択肢 難易度 多 少 難 易
  18. 基盤、共通システムをどう選ぶか • 技術選定の方針:安い、早い、簡単なものを選ぶ。「有名」というだけで選ばない。 ◦ 安い、早い、簡単は導入後の生産性を左右する。生産性はエンジニアのモチベーションを左右する。 • 導入の手順:安い、早い、簡単かつ取り返しのつかないところから導入していく。 ◦ (前提:DWH、データ基盤) ◦

    実験管理・モデル管理: MLflow、DVC、Weights&Bias、各種クラウド ◦ データ・モデルモニタリング: Grafana、Great Expectations、各種クラウド ◦ 学習パイプライン:Airflow、Argo Workflow、Prefect、各種クラウド ◦ 統合的な機械学習基盤:各種クラウド ◦ その他(Feature Store、Explainable AI、アノテーション・・・) 安い、早い、簡単 No Yes
  19. バッチ学習 + バッチ推論 • 定期的に学習と推論を実行する。 • 推論の利用が固定値かつ定期更新で良い場合に有効。 • 学習と同じ方法で推論することが可能であるため、 インフラやコードを学習と推論で共有できる。

    • 用途例:需要予測、推薦等。 ◦ テーブルデータで使うことが多く、逆に画像や テキストデータだと有効でないことが多い。 • 必要なスキルセット ◦ 学習基盤と学習パイプライン ◦ 推論結果をDBに保存 ◦ 最低限のモニタリング • あると便利なスキルセット ◦ BI ◦ ドリフト検知 DB バッチ 学習 ML基盤 バッチ 推論 Model DB CI/ CD DWH CT レポジト リ 実験 環境 ここを変更するの は簡単。 推論結果を出力す るテーブルはしっ かり設計したほう が良い。
  20. バッチ学習 + 同期推論 or 非同期推論 • 定期的に学習したモデルを推論器としてデプロイ。 • リクエストに応じて推論する用途で有効。 •

    学習と推論で異なるコード、ライブラリ、インフラ、ライフサイクルが 必要になる。 • 用途例:推薦、検索、違反検知、異常検知。 ◦ 多様な用途で利用可能だが、ワークフローが複雑になると 開発運用が難しくなる。 • 必要なスキルセット ◦ 学習基盤と学習パイプライン ◦ Web APIや非同期処理 ◦ 推論器のビルドと CI/CD • あると便利なスキルセット ◦ BI ◦ ドリフト検知 ◦ API開発と運用 実験 環境 バッチ 学習 ML基盤 CI/ CD DWH ビルド 推論 API 運用 管理 CI/ CD レポジト リ インターフェイスと パフォーマンスが 重要。 ビルドとCIがボト ルネックになるこ とも多い。 推論モデルを目 標に設計する。 Model DB CT
  21. バッチ学習 + 同期推論 or 非同期推論 + A/Bテスト • リクエストグループに応じて推論する APIを分散する。

    • 本番システムで複数の推論モデルを比較する場合に有効。 • 学習と推論で異なるコード、ライブラリ、インフラ、ライフサイクルが 必要になる。 • 学習と推論リリースは比較対象との優位性によって判定する。 • 用途例:Webやアプリ等、ユーザ次第で有効なアルゴリズムが変動する用途。 ◦ A/Bグループとモデルの対応次第では複雑なライフサイクルが 必要になる。 • 必要なスキルセット ◦ 学習基盤と学習パイプライン ◦ Web APIや非同期処理 ◦ 推論器のビルドと CI/CD ◦ A/Bの分割と学習、推論のライフサイクル管理 • あると便利なスキルセット ◦ BI ◦ ドリフト検知 ◦ API開発と運用 実験 環境 バッチ 学習 ML基盤 CI/ CD DWH 推論 API 管理/ 監視 CI/ CD レポジト リ A/B proxy 推論 API リリースを制 御する。 振り分けルールと バックアッププランが 鍵。 ビルド Model DB CT
  22. プログラムマネジメントスキル チームマネジメントスキル フェーズによってチャレンジする機能を選ぶ 機能によって必要なスキルは異なる • 初期フェーズ:0->1を作るチャレンジ ◦ ベースラインになる推薦を作る ◦ 作った推薦アイテムを本番で公開する

    ◦ 推薦の価値・可視化を分析する • 発展フェーズ:自動化・共通化・高度化するチャレンジ ◦ 推薦とシステムの品質を維持・改善する ◦ 既存の基盤を活用する ◦ 特定ドメインの専門知識を実用化する • 分割・専門化フェーズ:巨大システムを疎結合にするチャレンジ ◦ チームを分割しマネジメントする ◦ 共通課題を仕組みで解決する 早く安くリーズナブルな規模と品質で開発、運用す るスキル 共通化・自動化するソフトウェアスキル 複雑なドメインナレッジと分析力 Item2Item 人気順 BI バッチ推薦 User2Item CI/CT/CD A/Bテスト Personalize 推薦 基盤 共通 基盤 R&D チーム 基盤 チーム 評価
  23. 機械学習を実用化するためにMLOpsが必要とは限らない MLOpsを実践するために機械学習基盤が必要とは限らない 機械学習 MLOps 機械学習基盤 解決する手段 定期的な 改善が必要 数が増えて 共通化

    自動化したい 共通化したい 機械学習を 使うシステム 組み込む 解決する 共通化したい 課題解決に必要 データで解決 できる課題 課題解決に必要とは 限らない
  24. 初期は小さく成功するためのエンジニアリング DB Log DWH 推薦 テーブル 学習 バッチ 検索 API

    BI 推薦 API 定期的に推薦リストを 作成して記録しておく 推薦テーブルから検索 推薦の評価
  25. 複雑性・エッジケースを内包する DB Log DWH 推薦 テーブル Model DB 学習 基盤

    検索 API BI A/B proxy ML API 推薦 API CI/ CD 実験 評価 管理 Auto Scale 監視 CT
  26. 失敗例:理想のチームを作ったはずが・・・ ML/DSチーム 6名 • データ分析 • モデル開発 MLOpsチーム 5名 • ML基盤開発、運用 •

    MLライブラリ開発 • MLの本番システムへの組み込み ML基盤やライブラリが 使いにくい 研究できない モデルのリリース・修正が 拒否される ML/DSのコードが汚い ML基盤とシステムの 運用が大変 モデルを修正 してくれない コスト管理や コードレビューが 厳しい ML/DSが基盤や ライブラリを使わない ドキュメントがない 新しいML手法が 基盤でサポート されてない
  27. PoC 理想的なチームの成長とスキルセット・モチベーションの遷移 機械学習 導入開始 実用化 自動化・基盤化 完全自動化 複数システム 機械学習 エンジニア一人

    機械学習エンジニア複数 + PM 機械学習エンジニア + バックエンドエンジニア + PM プロダクト別チーム 一人でML+ ドメイン+ バックエンド + 突破力 ML ドメイン バックエンド ML ドメイン バックエンド フロントエンド マネジメント 基盤 SRE マネジメント ML ドメイン バックエンド フロントエンド 新しいことが得意な 一人から始まる 組織化・仕組み化された チームになる プロダクトごとに 自己完結する安定したチームへ 疎結合化、サイロ化 基盤 SRE DS 新事業 R&D 研究や新規事業が別チームへ 初期の小さなチームになる 再現性の証明 0->1 0->1 開発 1->10 1->10 開発 運用 修正 10->100 定型化 修正 調整 定型化 研究 研究 管理 管理 育成 成長 研究 研究 0->1 0->1 研究 スキルセット フェーズの説明 モチベーション 安定開発
  28. PoC 失敗例の考察 機械学習 導入開始 実用化 自動化・基盤化 完全自動化 複数システム 機械学習エンジニア 0->1

    1->10 研究 ML ドメイン 1->10 バックエンド 基盤 マネジメント MLOpsチーム バックエンドエンジニア + 基盤エンジニア 開発 運用 定型化 管理 新しいMLモデルを 開発、実用化したい 新しいML基盤で 仕組みを作りたい • MLOpsチームの導入目的: ◦ 人数が増えて開発が非効率になっていた MLプロジェクトを共通化、自動化、効率化する。 • MLチームの受け止め方: ◦ これまでうまくいっていた開発を一方的に変えられる。 MLチーム
  29. PoC 失敗例の打開案 機械学習 導入開始 実用化 自動化・基盤化 完全自動化 複数システム 機械学習エンジニア バックエンド・

    基盤エンジニア 機械学習エンジニア + バックエンドエンジニア + PM プロダクト別チーム 1MLチーム ドメイン別 チーム MLOps チーム MLチーム 試した施策1 チーム統一 • 各メンバーのチームを統合して役割・スキルを統一する。 • お互いに教え合う文化とリーダーシップが必要。 試した施策2 ドメイン分割 • ドメイン・プロダクトレベルでチームを分割する。 • 「ユーザの課題解決」にフォーカスする目的の共有。 • スキルセットは分散する。
  30. PoC・実験フェーズ • モチベーション ◦ 0->1 ◦ 初めての機械学習プロジェクトを完遂 • スキルセット ◦

    行動力・説明力・調整力 ◦ 機械学習 ◦ バックエンド ◦ ドメインナレッジ • システム ◦ データ ◦ 最悪ラップトップ1台でも良い DB Log DWH 分析 環境
  31. 初期の実用化フェーズ • モチベーション ◦ 0->1 ◦ 初めての機械学習プロジェクトを完遂 ◦ 運用で安定・改善 •

    スキルセット ◦ 評価とフィードバックループを作る ◦ バックエンド ◦ 機械学習パイプライン • システム ◦ DWHとワークフロー(バッチ) ◦ DBと推論サーバ DB Log DWH 推薦 テーブル 学習 バッチ 検索 API 推薦 API
  32. 拡張・成長・再現性の証明フェーズ • モチベーション ◦ 機械学習活用の再現、拡張 ◦ 高度・複雑な課題解決 • スキルセット ◦

    評価とフィードバックループを作る ◦ バックエンド ◦ 機械学習パイプライン ◦ 再利用性 • システム ◦ ワークフローの再利用 ◦ プロキシと推論サーバ ◦ 管理(モニタリングとBI) ◦ CI/CD 検索 API DB Log DWH 学習 バッチ BI A/B proxy ML API 推薦 API CI/ CD 監視
  33. 仕組み化・共通化・自動化フェーズ • モチベーション ◦ 共通化・自動化・基盤開発 ◦ システマチックな課題解決 • スキルセット ◦

    CI/CD/CT ◦ 評価と品質管理 ◦ 機械学習基盤 ◦ サービスディスカバリと推論 API ◦ チームマネジメント ◦ ドキュメンテーション • システム ◦ 機械学習基盤 ◦ ワークフロー管理 ◦ インフラ管理 ◦ 実験管理 DB Log DWH 推薦 テーブル Model DB 学習 基盤 検索 API BI A/B proxy ML API 推薦 API CI/ CD 実験 評価 管理 Auto Scale 監視 CT
  34. 分割・専任化フェーズ • モチベーション ◦ 開発・運用生産性の向上 ◦ コミュニケーションコスト削減 ◦ 大規模開発と育成 ◦

    多様性の受容 • スキルセット ◦ マネジメント ◦ 調整力・俯瞰力 ◦ ドキュメンテーション ◦ 他人の作った基盤を使う能力 • システム ◦ チームコミュニケーション ◦ データとインフラの共通基盤 ◦ システムの個別化・独立化 インフラ クラウド、ネットワーク、アカウント データ基盤 ML基盤 共通基盤 (ログ、モニタリング、 CI/CD・・・) ユーザインタフェース (Web、スマホ、その他) バックエンド バックエンド バックエンド 機械学習 機械学習 機械学習