$30 off During Our Annual Pro Sale. View Details »

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

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. Developers Summit 2023 Inspired
    機械学習を実用化する
    エンジニアリングスキル
    2023/02/09 Yusuke Shibui

    View Slide

  2. 自己紹介
    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/

    View Slide

  3. ● 発売中!
    ● https://www.amazon.co.jp/dp/4798169447/
    ● 発売中!
    ● https://www.amazon.co.jp/dp/4798173401/

    View Slide

  4. 今日話すこと
    ● 機械学習によってユーザに価値を届けるための
    ○ 企画
    ○ 技術
    ○ チーム
    失敗談と学びをベースに話します。

    View Slide

  5. 今日話さないこと
    ● 機械学習やAIの理論や作り方
    ● 機械学習基盤の作り方や MLOpsの実践方法
    ● エンジニアの採用・育成方法

    View Slide

  6. クラウドを作っていた時代の私の原体験
    ● 2010年、新卒入社した日本のSIerで最初の仕事は会社初のパブリッククラウドの開発と拡販。
    ○ AWSの東京データセンター設置が2011年3月。
    ○ まだ国産クラウドがグローバルカンパニーと戦える可能性の合った時代。
    ● 物理サーバビジネスで商売していたエンジニア、営業から社内競合として反発。
    ○ 「インフラエンジニアはどうなってしまうんですか・・・?」
    ● 機械学習エンジニアやデータサイエンティストが将来、新しい技術に置換されない理由はない。
    ● 新しい技術の実用化、運用、拡販は常に発生する課題である。

    View Slide

  7. ユーザに価値を与える
    機械学習を目指して

    View Slide

  8. 機械学習を使う必要がないなら使わないほうが良い
    ● 「機械学習で改題解決するコスト」 > 「ソフトウェアで課題解決するコスト」
    ● ただし、「機械学習で解決する価値」   「ソフトウェアで解決する価値」



    View Slide

  9. 機械学習で解決したほうが良い課題
    課題:人間や社会にとって不都合なこと、手間なこと、遅いこと、不正確なこと・・・
    ソフトウェアで解決できる課題:解決方法をコンピュータシステムに組み込めるもの
    機械学習で解決できる課題:解決方法に関連するデータとモデルが存在するもの
    機械学習で解決したほうが良い課題:
    機械学習を使うことで得られる効果が他の手法より大きいもの

    View Slide

  10. 機械学習で解決するために必要なもの

    View Slide

  11. なにから手を付けて良いのかわからない

    View Slide

  12. 最初から必要なスキルセットを見通すことは難しい
    データを集
    める
    モデルを
    学習する
    オフライン評
    価する
    課題を
    決める
    ここまで一人でできた
    ここから先どうしよう・・・

    View Slide

  13. ● 条件:人、金、時間は有限
    ● 必要:
    ○ 企画:最初の課題解決を成し、再現性を証明する
    ○ 技術:変更できるシステムを作る
    ○ チーム:スキルとモチベーションを一致させる
    ● 有効な場合はあるけど、必要とは限らない:
    ○ MLOpsや機械学習基盤
    ○ Kaggleの知識
    ○ 知名度
    機械学習を実用化するための
    エンジニアリングスキル
    注目されることが多い
    こっちのほうが重要

    View Slide

  14. 課題に対する企画、技術、チーム
    課題
    企画
    技術
    チーム
    ゴール

    View Slide

  15. 企画とプロダクト

    View Slide

  16. 最近よく聞かれること
    「機械学習を使うためにはMLOps(または機械学習基盤)が必要なんですか?」

    View Slide

  17. はじめての機械学習プロジェクト
    あなたは日本全国に小売店を展開する「AI商店」で働く機械学習エンジニアです。
    企業初の機械学習プロジェクトを立ち上げようとしています。
    発注
    納入
    購入

    View Slide

  18. AI商店の評価できる課題から始める
    発注
    納入
    購入
    需要予測
    納入遅延予測
    レジ自動化
    在庫管理
    自動化
    導線分析
    温度管理
    自動化
    防犯分析
    発注自動化

    View Slide

  19. 失敗例(経験談)
    ● tl;dr 価値が出るかわからないのにすごい作り込む
    ● 「最高の」需要予測モデルを作るのに半年かかった
    ● その学習コードが100,000行、100Pythonファイル、10コンフィグファイルで構成され、
    1学習にCPU 100coreで12時間かかる
    ● 経過時間のほとんどはデータの集計
    ● オフライン評価は高いが、オンラインでは検証していない
    ● 時系列データをランダム分割している
    ● 反リーダブルコード、非テスト駆動開発
    ● 最初から高度な自動化と基盤運用が求められる
    ● 作ったエンジニアは運用しない(開発だけ外部に委託契約)
    ● 安定運用するまでに開発物の納入から
    1年かかった

    View Slide

  20. 機械学習を使うプロダクトを企画する
    ● 評価できる課題から始める
    ● 手間≠価値
    ● 実験(評価と失敗と修正)をプランニングする
    ● やらないことを決める

    View Slide

  21. 手間 ≠ 価値
    little effort huge effort
    small impact
    large impact
    MUST
    Wait until you
    need it
    Are you sure?
    Low risk
    starting point
    ここを目指す 必要になってから
    ここから始めて

    View Slide

  22. 機械学習の施策におけるEffortとImpact
    little effort huge effort
    small impact
    large impact
    実績のある既存手法の実用化
    例:ECや検索の推薦
    共通基盤や
    R&Dの伴うモデル開発
    例:MLOps、ML基盤
    既存システムの再構築や
    間違った技術選択
    例:基盤の移行、
    Fortranで機械学習
    既存モデルの活用
    例:コピペ、再学習
    ここを目指す 必要になってから
    ここから始めて

    View Slide

  23. 手間≠価値
    発注
    納入
    購入
    インフラ
    クラウド、ネットワーク、アカウント
    データ基盤 ML基盤
    共通基盤
    (ログ、モニタリング、
    CI/CD・・・)
    推論基盤
    BI
    ML
    パイプライン
    需要予測
    基本モデル
    需要予測
    モデルA
    需要予測
    モデルB
    俺の最強ML基盤

    View Slide

  24. 課題を解くための価値ある施策から始める
    発注
    納入
    購入
    インフラ
    クラウド、ネットワーク、アカウント
    データ基盤 ML基盤
    共通基盤
    (ログ、モニタリング、
    CI/CD・・・)
    推論基盤
    BI
    ML
    パイプライン
    需要予測
    基本モデル
    需要予測
    モデルA
    需要予測
    モデルB
    今すぐ必要ではないし、
    必要になるとも限らない
    最低限のビジネス的な
    評価すべき価値

    View Slide

  25. 実験(評価と失敗と修正)をプランニングする
    ● 解きたい課題に対して既存のデータと手法が有効か否かを調べるためには実験が必要。
    ● 課題が解けていることを証明するためには評価が必要。
    ● 求める評価に至らない場合(実験が失敗した場合)には修正が必要。
    ● 実験は時間的・金銭的制約の中で実施しなければならない。
    ルールベースや
    統計手法
    Logistic回帰等
    簡単なモデル
    特徴量の工夫と
    GBDT
    資金力と意地と
    Neural Network
    諦める
    オフライン
    評価
    本番システムで
    評価
    現状調査と
    データ収集
    本来の実験のゴールはここ
    ここが一番
    たいへんなことが多い
    諦めも大事
    ここはまだ過程
    調査 -> 本番で実験の
    サイクルを早くしたい

    View Slide

  26. AI商店の需要予測のプランニング
    PoC・初期フェーズ 発展・拡大フェーズ
    需要予測の実用化
    オフライン評価
    分析と開発
    オンライン評価
    需要予測
    システム開発
    現状調査
    課題定義
    GO/NO GO判断
    需要予測の
    自動化開発
    チーム化、採用
    オフライン評価
    分析と開発
    現状調査
    課題定義
    オンライン評価
    課題の再定義
    開発・運用
    スタイルの確立
    基盤の整備

    View Slide

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

    View Slide

  28. どこから作る?
    ● Jupyter NotebookでPoCモデルを作ってオフラインで試す
    ● モデルとコードを作って多様な店舗で試す
    ● 学習をバッチシステムに組み込んで自動化する
    ● 機械学習基盤を作って学習と推論を自動化する
    ● 全店舗にEnd-to-endでMLOpsを導入する
    little effort impact???
    huge effort

    View Slide

  29. どこから作る?
    ● Jupyter NotebookでPoCモデルを作ってオフラインで試す
    ● モデルとコードを作って多様な店舗で試す
    ● 学習をバッチシステムに組み込んで自動化する
    ● 機械学習基盤を作って学習と推論を自動化する
    ● 全店舗にEnd-to-endでMLOpsを導入する
    little effort impact???
    huge effort
    作る
    作らな

    View Slide

  30. 手間を最初から見通すことは難しい
    エンジニアの手間
    初の機械学習
    実用化
    新しい開発
    機能
    企画時に見えている手間 実際に発生する手間
    機能開発は最初に手間が発生
    更には機能改善と運用の手間が積み重ねで発生
    運用
    再学習
    調整
    ディープラーニングに
    挑戦
    モデル更改
    リファクタ
    リング
    追加の機械学習
    実用化
    再学習
    リファクタリ
    ング
    機械学習基盤
    構成管理
    アップデート
    再学習
    調整
    再学習
    リファクタリ
    ング
    再学習
    調整
    モデル更改
    リファクタ
    リング
    再学習
    リファクタリ
    ング
    再学習
    調整
    企画時に見えている手間と本当の手間が乖離していくと、
    エンジニアの生産性が悪く見えてくる

    View Slide

  31. 手間を最初から見通すことは難しいが、
    価値を見通すことはもっと難しい
    ここのどこか
    ここのどこか

    View Slide

  32. AI商店の現状の需要予測
    システムの全体像(現状) 販売実績
    発注
    納入

    View Slide

  33. 初期の需要予測システム
    (Laptopで実行)
    AI商店の需要予測PoCシステム
    学習
    推論
    評価
    分析と展開
    評価と分析
    予測
    データ
    発注
    納入
    実績
    データ

    View Slide

  34. 基盤の整備
    発展させていくための優先順位を考える
    PoC・初期フェーズ 発展・拡大フェーズ
    需要予測の実用化
    オフライン評価
    分析と開発
    オンライン評価
    需要予測
    システム開発
    現状調査
    課題定義
    GO/NO GO判断
    需要予測の
    自動化開発
    チーム化、採用
    オフライン評価
    分析と開発
    現状調査
    課題定義
    オンライン評価
    課題の再定義
    開発・運用
    スタイルの確立
    成功
    どこから手を付ける?

    View Slide

  35. 技術

    View Slide

  36. 新しいものが出たらすぐ便利になるのではなく、
    新しいものが再現性を持って実用化されてから便利になる
    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

    View Slide

  37. 理論から学習へ、学習から推論へ
    理論
    公開コードまたは
    数式から実装
    バッチ推論
    多くの場合学習と
    同じ技術で可能
    推論API
    学習したモデルを
    サーバにロードして
    外部リクエストを
    受けられるようにする
    Edge AI
    学習したモデルで
    デバイスにロードして
    推論する
    公開モデル
    再利用可能な
    学習済みモデルとして
    公開される
    学習
    数週間〜数ヶ月 数週間〜数ヶ月 数ヶ月〜
    論文公開
    ここに至るのは
    極一部

    View Slide

  38. 動物画像SNS

    View Slide

  39. レコメンデーション
    ここになにを
    表示する?
    人気の動物写真
    ユーザが好きそうな動物写真
    検索条件で人気の動物写真
    似ている動物写真
    簡単・安い
    難しい・高い


    ・並




    調
    フィル
    タリング
    ランク学習
    類似画像検索



    効果

    View Slide

  40. 失敗例:変更困難な基盤
    DB Log DWH
    Model
    DB
    学習
    基盤
    検索
    API
    API
    ANN
    CI/
    CD
    DL
    監視
    CT
    hard coded

    View Slide

  41. 変更するつもりで作る
    ● 機械学習モデルやライブラリ、基盤は頻繁に更
    新、変更される。
    ● すべての新しいライブラリや基盤が
    後方互換性を保っているとは限らないし、
    新しいモデルが常に良いとも限らない。
    ● 変更頻度と変更難易度を考慮してシステムを設
    計するスキルが求められる。
    ● 変更がうまくいかない場合はロールバック
    できるようにしておく。
    変更難易度
    変更頻度


    低 高
    学習データ
    学習済みモデル
    推論API
    MLライブラリの更新
    GPU
    データ基盤
    ML基盤
    永続データ
    推論ライブラリ
    評価指標
    バッチ処理
    推論を使う外部システム
    MLライブラリを変更

    View Slide

  42. 推論から考える
    ● 常に推論できるモデル( =本番システムで使えるモデル)を学習する。
    ● 推論の優先順位
    ○ まずはルールベースや統計処理で対応可否を検討する。
    ○ 機械学習が必要な場合はバッチ推論(学習と同じシステム構成で可能)を検討する。
    ○ バッチ推論が利用不可の場合(入力が動的に変わる)、同期推論や非同期処理を検討する。
    ■ ONNXやTensorFlowServing、TorchServeを活用可能なモデルを優先して選ぶ。
    ■ 推論ライブラリを使えない場合はサーバで稼働させた場合のパフォーマンスと安定性を
    重点的に検証する。
    ○ ユーザ端末でリアルタイム処理が必要な場合は Edge AIを検討する。
    ■ 本当にリアルタイム性が必要か立ち止まって考える。
    ■ Edge AIで使えるモデルは選択肢が少なく、モデルの更新リリースが難しいことを考慮する。
    ● 学習の考慮事項
    ○ 推論で活用可能なモデルを学習する。
    ○ 学習基盤はメンバー数とモデル数に応じて徐々に導入する。一度に全部入れる必要はない。
    ○ 【超重要】以下 4点を疎かにしてはいけない。
    ■ リーダビリティ、テスト、インターフェイス、ライブラリ管理。
    選択肢 難易度

    少 難

    View Slide

  43. 基盤、共通システムをどう選ぶか
    ● 技術選定の方針:安い、早い、簡単なものを選ぶ。「有名」というだけで選ばない。
    ○ 安い、早い、簡単は導入後の生産性を左右する。生産性はエンジニアのモチベーションを左右する。
    ● 導入の手順:安い、早い、簡単かつ取り返しのつかないところから導入していく。
    ○ (前提:DWH、データ基盤)
    ○ 実験管理・モデル管理:
    MLflow、DVC、Weights&Bias、各種クラウド
    ○ データ・モデルモニタリング:
    Grafana、Great Expectations、各種クラウド
    ○ 学習パイプライン:Airflow、Argo Workflow、Prefect、各種クラウド
    ○ 統合的な機械学習基盤:各種クラウド
    ○ その他(Feature Store、Explainable AI、アノテーション・・・)
    安い、早い、簡単
    No
    Yes

    View Slide

  44. オフラインで実験
    ● オフラインでモデルの学習を実験する。
    ● 用途例:機械学習の
    PoCや開発
    ● 必要なスキルセット
    ○ 学習モデル開発、評価
    ○ モデル管理
    ○ GPU等のインフラ管理
    実験
    Laptop or Google Colab
    Model
    DB
    DWH
    レポジト

    View Slide

  45. バッチ学習 + バッチ推論
    ● 定期的に学習と推論を実行する。
    ● 推論の利用が固定値かつ定期更新で良い場合に有効。
    ● 学習と同じ方法で推論することが可能であるため、
    インフラやコードを学習と推論で共有できる。
    ● 用途例:需要予測、推薦等。
    ○ テーブルデータで使うことが多く、逆に画像や
    テキストデータだと有効でないことが多い。
    ● 必要なスキルセット
    ○ 学習基盤と学習パイプライン
    ○ 推論結果をDBに保存
    ○ 最低限のモニタリング
    ● あると便利なスキルセット
    ○ BI
    ○ ドリフト検知
    DB
    バッチ
    学習
    ML基盤
    バッチ
    推論
    Model
    DB
    CI/
    CD
    DWH
    CT
    レポジト

    実験
    環境
    ここを変更するの
    は簡単。
    推論結果を出力す
    るテーブルはしっ
    かり設計したほう
    が良い。

    View Slide

  46. バッチ学習 + 同期推論 or 非同期推論
    ● 定期的に学習したモデルを推論器としてデプロイ。
    ● リクエストに応じて推論する用途で有効。
    ● 学習と推論で異なるコード、ライブラリ、インフラ、ライフサイクルが
    必要になる。
    ● 用途例:推薦、検索、違反検知、異常検知。
    ○ 多様な用途で利用可能だが、ワークフローが複雑になると
    開発運用が難しくなる。
    ● 必要なスキルセット
    ○ 学習基盤と学習パイプライン
    ○ Web APIや非同期処理
    ○ 推論器のビルドと
    CI/CD
    ● あると便利なスキルセット
    ○ BI
    ○ ドリフト検知
    ○ API開発と運用
    実験
    環境
    バッチ
    学習
    ML基盤
    CI/
    CD
    DWH
    ビルド
    推論
    API
    運用
    管理
    CI/
    CD
    レポジト

    インターフェイスと
    パフォーマンスが
    重要。
    ビルドとCIがボト
    ルネックになるこ
    とも多い。
    推論モデルを目
    標に設計する。
    Model
    DB
    CT

    View Slide

  47. バッチ学習 + 同期推論 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

    View Slide

  48. PoC:機械学習の有効性と有用性を証明する
    DB Log DWH
    検索
    API
    分析
    環境
    Prove ML or not ML

    View Slide

  49. プログラムマネジメントスキル
    チームマネジメントスキル
    フェーズによってチャレンジする機能を選ぶ
    機能によって必要なスキルは異なる
    ● 初期フェーズ:0->1を作るチャレンジ
    ○ ベースラインになる推薦を作る
    ○ 作った推薦アイテムを本番で公開する
    ○ 推薦の価値・可視化を分析する
    ● 発展フェーズ:自動化・共通化・高度化するチャレンジ
    ○ 推薦とシステムの品質を維持・改善する
    ○ 既存の基盤を活用する
    ○ 特定ドメインの専門知識を実用化する
    ● 分割・専門化フェーズ:巨大システムを疎結合にするチャレンジ
    ○ チームを分割しマネジメントする
    ○ 共通課題を仕組みで解決する
    早く安くリーズナブルな規模と品質で開発、運用す
    るスキル
    共通化・自動化するソフトウェアスキル
    複雑なドメインナレッジと分析力
    Item2Item
    人気順
    BI
    バッチ推薦
    User2Item
    CI/CT/CD
    A/Bテスト
    Personalize
    推薦
    基盤
    共通
    基盤
    R&D
    チーム
    基盤
    チーム
    評価

    View Slide

  50. 機械学習を実用化するためにMLOpsが必要とは限らない
    MLOpsを実践するために機械学習基盤が必要とは限らない
    機械学習
    MLOps
    機械学習基盤
    解決する手段
    定期的な
    改善が必要
    数が増えて
    共通化
    自動化したい
    共通化したい
    機械学習を
    使うシステム
    組み込む
    解決する
    共通化したい
    課題解決に必要
    データで解決
    できる課題
    課題解決に必要とは
    限らない

    View Slide

  51. 初期は小さく成功するためのエンジニアリング
    DB Log DWH
    推薦
    テーブル
    学習
    バッチ
    検索
    API
    BI
    推薦
    API
    定期的に推薦リストを
    作成して記録しておく
    推薦テーブルから検索
    推薦の評価

    View Slide

  52. 定期的なモデル改善のためにMLOpsのプラクティスを取り入れる
    複数モデルの開発と運用を共通化・自動化するために基盤を作る
    機械学習
    MLOps
    機械学習基盤
    解決する手段
    定期的な
    改善が必要
    数が増えて
    共通化
    自動化したい
    共通化したい
    機械学習を
    使うシステム
    組み込む
    解決する
    共通化したい
    データで解決
    できる課題

    View Slide

  53. 複雑性・エッジケースを内包する
    DB Log DWH
    推薦
    テーブル
    Model
    DB
    学習
    基盤
    検索
    API
    BI
    A/B
    proxy
    ML
    API
    推薦
    API
    CI/
    CD
    実験
    評価
    管理
    Auto
    Scale
    監視
    CT

    View Slide

  54. チーム

    View Slide

  55. 失敗例:理想のチームを作ったはずが・・・
    ML/DSチーム 6名
    ● データ分析
    ● モデル開発
    もともとあった

    View Slide

  56. 失敗例:理想のチームを作ったはずが・・・
    ML/DSチーム 6名
    ● データ分析
    ● モデル開発
    MLOpsチーム 5名
    ● ML基盤開発、運用
    ● MLライブラリ開発
    ● MLの本番システムへの組み込み
    もともとあった 新設!

    View Slide

  57. 失敗例:理想のチームを作ったはずが・・・
    ML/DSチーム 6名
    ● データ分析
    ● モデル開発
    MLOpsチーム 5名
    ● ML基盤開発、運用
    ● MLライブラリ開発
    ● MLの本番システムへの組み込み
    ML基盤やライブラリが
    使いにくい
    研究できない
    モデルのリリース・修正が
    拒否される
    ML/DSのコードが汚い
    ML基盤とシステムの
    運用が大変
    モデルを修正
    してくれない
    コスト管理や
    コードレビューが
    厳しい
    ML/DSが基盤や
    ライブラリを使わない
    ドキュメントがない
    新しいML手法が
    基盤でサポート
    されてない

    View Slide

  58. 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
    研究
    スキルセット
    フェーズの説明
    モチベーション
    安定開発

    View Slide

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

    View Slide

  60. PoC
    失敗例の打開案
    機械学習
    導入開始
    実用化
    自動化・基盤化
    完全自動化
    複数システム
    機械学習エンジニア
    バックエンド・
    基盤エンジニア
    機械学習エンジニア +
    バックエンドエンジニア +
    PM
    プロダクト別チーム
    1MLチーム
    ドメイン別
    チーム
    MLOps
    チーム
    MLチーム
    試した施策1 チーム統一
    ● 各メンバーのチームを統合して役割・スキルを統一する。
    ● お互いに教え合う文化とリーダーシップが必要。
    試した施策2 ドメイン分割
    ● ドメイン・プロダクトレベルでチームを分割する。
    ● 「ユーザの課題解決」にフォーカスする目的の共有。
    ● スキルセットは分散する。

    View Slide

  61. PoC・実験フェーズ
    ● モチベーション
    ○ 0->1
    ○ 初めての機械学習プロジェクトを完遂
    ● スキルセット
    ○ 行動力・説明力・調整力
    ○ 機械学習
    ○ バックエンド
    ○ ドメインナレッジ
    ● システム
    ○ データ
    ○ 最悪ラップトップ1台でも良い
    DB Log DWH
    分析
    環境

    View Slide

  62. 初期の実用化フェーズ
    ● モチベーション
    ○ 0->1
    ○ 初めての機械学習プロジェクトを完遂
    ○ 運用で安定・改善
    ● スキルセット
    ○ 評価とフィードバックループを作る
    ○ バックエンド
    ○ 機械学習パイプライン
    ● システム
    ○ DWHとワークフロー(バッチ)
    ○ DBと推論サーバ
    DB Log DWH
    推薦
    テーブル
    学習
    バッチ
    検索
    API
    推薦
    API

    View Slide

  63. 拡張・成長・再現性の証明フェーズ
    ● モチベーション
    ○ 機械学習活用の再現、拡張
    ○ 高度・複雑な課題解決
    ● スキルセット
    ○ 評価とフィードバックループを作る
    ○ バックエンド
    ○ 機械学習パイプライン
    ○ 再利用性
    ● システム
    ○ ワークフローの再利用
    ○ プロキシと推論サーバ
    ○ 管理(モニタリングとBI)
    ○ CI/CD
    検索
    API DB Log DWH
    学習
    バッチ
    BI
    A/B
    proxy
    ML
    API
    推薦
    API
    CI/
    CD
    監視

    View Slide

  64. 仕組み化・共通化・自動化フェーズ
    ● モチベーション
    ○ 共通化・自動化・基盤開発
    ○ システマチックな課題解決
    ● スキルセット
    ○ CI/CD/CT
    ○ 評価と品質管理
    ○ 機械学習基盤
    ○ サービスディスカバリと推論 API
    ○ チームマネジメント
    ○ ドキュメンテーション
    ● システム
    ○ 機械学習基盤
    ○ ワークフロー管理
    ○ インフラ管理
    ○ 実験管理
    DB Log DWH
    推薦
    テーブル
    Model
    DB
    学習
    基盤
    検索
    API
    BI
    A/B
    proxy
    ML
    API
    推薦
    API
    CI/
    CD
    実験
    評価
    管理
    Auto
    Scale
    監視
    CT

    View Slide

  65. 分割・専任化フェーズ
    ● モチベーション
    ○ 開発・運用生産性の向上
    ○ コミュニケーションコスト削減
    ○ 大規模開発と育成
    ○ 多様性の受容
    ● スキルセット
    ○ マネジメント
    ○ 調整力・俯瞰力
    ○ ドキュメンテーション
    ○ 他人の作った基盤を使う能力
    ● システム
    ○ チームコミュニケーション
    ○ データとインフラの共通基盤
    ○ システムの個別化・独立化
    インフラ
    クラウド、ネットワーク、アカウント
    データ基盤 ML基盤
    共通基盤
    (ログ、モニタリング、
    CI/CD・・・)
    ユーザインタフェース
    (Web、スマホ、その他)
    バックエンド バックエンド バックエンド
    機械学習 機械学習 機械学習

    View Slide

  66. まとめ

    View Slide

  67. ユーザに価値を与える機械学習を目指して
    ● 企画・プロダクト:課題から始める、 Little effortから始める
    ● 技術:再現性を証明する、変更するつもりで作る
    ● チーム:スキルセットとモチベーションを一致させる

    View Slide

  68. ありがとうございました!

    View Slide