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

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

Transcript

1. Developers Summit 2023 Inspired 機械学習を実用化する エンジニアリングスキル 2023/02/09 Yusuke Shibui
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/
3. • 発売中！ • https://www.amazon.co.jp/dp/4798169447/ • 発売中！ • https://www.amazon.co.jp/dp/4798173401/
4. 今日話すこと • 機械学習によってユーザに価値を届けるための ◦ 企画 ◦ 技術 ◦ チーム 失敗談と学びをベースに話します。
5. 今日話さないこと • 機械学習やAIの理論や作り方 • 機械学習基盤の作り方や MLOpsの実践方法 • エンジニアの採用・育成方法
6. クラウドを作っていた時代の私の原体験 • 2010年、新卒入社した日本のSIerで最初の仕事は会社初のパブリッククラウドの開発と拡販。 ◦ AWSの東京データセンター設置が2011年3月。 ◦ まだ国産クラウドがグローバルカンパニーと戦える可能性の合った時代。 • 物理サーバビジネスで商売していたエンジニア、営業から社内競合として反発。 ◦ 「インフラエンジニアはどうなってしまうんですか・・・？」 • 機械学習エンジニアやデータサイエンティストが将来、新しい技術に置換されない理由はない。 • 新しい技術の実用化、運用、拡販は常に発生する課題である。
7. ユーザに価値を与える 機械学習を目指して
8. 機械学習を使う必要がないなら使わないほうが良い • 「機械学習で改題解決するコスト」　＞　「ソフトウェアで課題解決するコスト」 • ただし、「機械学習で解決する価値」　　　「ソフトウェアで解決する価値」 ＞ ＝ ＜
9. 機械学習で解決したほうが良い課題 課題：人間や社会にとって不都合なこと、手間なこと、遅いこと、不正確なこと・・・ ソフトウェアで解決できる課題：解決方法をコンピュータシステムに組み込めるもの 機械学習で解決できる課題：解決方法に関連するデータとモデルが存在するもの 機械学習で解決したほうが良い課題： 機械学習を使うことで得られる効果が他の手法より大きいもの
10. 機械学習で解決するために必要なもの
11. なにから手を付けて良いのかわからない
12. 最初から必要なスキルセットを見通すことは難しい データを集 める モデルを 学習する オフライン評 価する 課題を 決める ここまで一人でできた ここから先どうしよう・・・
13. • 条件：人、金、時間は有限 • 必要： ◦ 企画：最初の課題解決を成し、再現性を証明する ◦ 技術：変更できるシステムを作る ◦ チーム：スキルとモチベーションを一致させる • 有効な場合はあるけど、必要とは限らない： ◦ MLOpsや機械学習基盤 ◦ Kaggleの知識 ◦ 知名度 機械学習を実用化するための エンジニアリングスキル 注目されることが多い こっちのほうが重要
14. 課題に対する企画、技術、チーム 課題 企画 技術 チーム ゴール
15. 企画とプロダクト
16. 最近よく聞かれること 「機械学習を使うためにはMLOps（または機械学習基盤）が必要なんですか？」
17. はじめての機械学習プロジェクト あなたは日本全国に小売店を展開する「AI商店」で働く機械学習エンジニアです。 企業初の機械学習プロジェクトを立ち上げようとしています。 発注 納入 購入
18. AI商店の評価できる課題から始める 発注 納入 購入 需要予測 納入遅延予測 レジ自動化 在庫管理 自動化 導線分析 温度管理 自動化 防犯分析 発注自動化
19. 失敗例（経験談） • tl;dr 価値が出るかわからないのにすごい作り込む • 「最高の」需要予測モデルを作るのに半年かかった • その学習コードが100,000行、100Pythonファイル、10コンフィグファイルで構成され、 1学習にCPU 100coreで12時間かかる • 経過時間のほとんどはデータの集計 • オフライン評価は高いが、オンラインでは検証していない • 時系列データをランダム分割している • 反リーダブルコード、非テスト駆動開発 • 最初から高度な自動化と基盤運用が求められる • 作ったエンジニアは運用しない（開発だけ外部に委託契約） • 安定運用するまでに開発物の納入から 1年かかった
20. 機械学習を使うプロダクトを企画する • 評価できる課題から始める • 手間≠価値 • 実験（評価と失敗と修正）をプランニングする • やらないことを決める
21. 手間 ≠ 価値 little effort huge effort small impact large impact MUST Wait until you need it Are you sure? Low risk starting point ここを目指す 必要になってから ここから始めて
22. 機械学習の施策におけるEffortとImpact little effort huge effort small impact large impact 実績のある既存手法の実用化 例：ECや検索の推薦 共通基盤や R&Dの伴うモデル開発 例：MLOps、ML基盤 既存システムの再構築や 間違った技術選択 例：基盤の移行、 Fortranで機械学習 既存モデルの活用 例：コピペ、再学習 ここを目指す 必要になってから ここから始めて
23. 手間≠価値 発注 納入 購入 インフラ クラウド、ネットワーク、アカウント データ基盤 ML基盤 共通基盤 （ログ、モニタリング、 CI/CD・・・） 推論基盤 BI ML パイプライン 需要予測 基本モデル 需要予測 モデルA 需要予測 モデルB 俺の最強ML基盤
24. 課題を解くための価値ある施策から始める 発注 納入 購入 インフラ クラウド、ネットワーク、アカウント データ基盤 ML基盤 共通基盤 （ログ、モニタリング、 CI/CD・・・） 推論基盤 BI ML パイプライン 需要予測 基本モデル 需要予測 モデルA 需要予測 モデルB 今すぐ必要ではないし、 必要になるとも限らない 最低限のビジネス的な 評価すべき価値
25. 実験（評価と失敗と修正）をプランニングする • 解きたい課題に対して既存のデータと手法が有効か否かを調べるためには実験が必要。 • 課題が解けていることを証明するためには評価が必要。 • 求める評価に至らない場合（実験が失敗した場合）には修正が必要。 • 実験は時間的・金銭的制約の中で実施しなければならない。 ルールベースや 統計手法 Logistic回帰等 簡単なモデル 特徴量の工夫と GBDT 資金力と意地と Neural Network 諦める オフライン 評価 本番システムで 評価 現状調査と データ収集 本来の実験のゴールはここ ここが一番 たいへんなことが多い 諦めも大事 ここはまだ過程 調査 -> 本番で実験の サイクルを早くしたい
26. AI商店の需要予測のプランニング PoC・初期フェーズ 発展・拡大フェーズ 需要予測の実用化 オフライン評価 分析と開発 オンライン評価 需要予測 システム開発 現状調査 課題定義 GO/NO GO判断 需要予測の 自動化開発 チーム化、採用 オフライン評価 分析と開発 現状調査 課題定義 オンライン評価 課題の再定義 開発・運用 スタイルの確立 基盤の整備
27. やらないことを決める PoC・初期フェーズ 発展・拡大フェーズ 需要予測の実用化 オフライン評価 分析と開発 オンライン評価 需要予測 システム開発 現状調査 課題定義 GO/NO GO判断 需要予測の 自動化開発 チーム化、採用 オフライン評価 分析と開発 現状調査 課題定義 オンライン評価 課題の再定義 開発・運用 スタイルの確立 基盤の整備 まずはここで成功させる。 こっちは後回しにする。
28. どこから作る？ • Jupyter NotebookでPoCモデルを作ってオフラインで試す • モデルとコードを作って多様な店舗で試す • 学習をバッチシステムに組み込んで自動化する • 機械学習基盤を作って学習と推論を自動化する • 全店舗にEnd-to-endでMLOpsを導入する little effort impact??? huge effort
29. どこから作る？ • Jupyter NotebookでPoCモデルを作ってオフラインで試す • モデルとコードを作って多様な店舗で試す • 学習をバッチシステムに組み込んで自動化する • 機械学習基盤を作って学習と推論を自動化する • 全店舗にEnd-to-endでMLOpsを導入する little effort impact??? huge effort 作る 作らな い
30. 手間を最初から見通すことは難しい エンジニアの手間 初の機械学習 実用化 新しい開発 機能 企画時に見えている手間 実際に発生する手間 機能開発は最初に手間が発生 更には機能改善と運用の手間が積み重ねで発生 運用 再学習 調整 ディープラーニングに 挑戦 モデル更改 リファクタ リング 追加の機械学習 実用化 再学習 リファクタリ ング 機械学習基盤 構成管理 アップデート 再学習 調整 再学習 リファクタリ ング 再学習 調整 モデル更改 リファクタ リング 再学習 リファクタリ ング 再学習 調整 企画時に見えている手間と本当の手間が乖離していくと、 エンジニアの生産性が悪く見えてくる
31. 手間を最初から見通すことは難しいが、 価値を見通すことはもっと難しい ここのどこか ここのどこか
32. AI商店の現状の需要予測 システムの全体像（現状） 販売実績 発注 納入
33. 初期の需要予測システム （Laptopで実行） AI商店の需要予測PoCシステム 学習 推論 評価 分析と展開 評価と分析 予測 データ 発注 納入 実績 データ
34. 基盤の整備 発展させていくための優先順位を考える PoC・初期フェーズ 発展・拡大フェーズ 需要予測の実用化 オフライン評価 分析と開発 オンライン評価 需要予測 システム開発 現状調査 課題定義 GO/NO GO判断 需要予測の 自動化開発 チーム化、採用 オフライン評価 分析と開発 現状調査 課題定義 オンライン評価 課題の再定義 開発・運用 スタイルの確立 成功 どこから手を付ける？
35. 技術
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
37. 理論から学習へ、学習から推論へ 理論 公開コードまたは 数式から実装 バッチ推論 多くの場合学習と 同じ技術で可能 推論API 学習したモデルを サーバにロードして 外部リクエストを 受けられるようにする Edge AI 学習したモデルで デバイスにロードして 推論する 公開モデル 再利用可能な 学習済みモデルとして 公開される 学習 数週間〜数ヶ月 数週間〜数ヶ月 数ヶ月〜 論文公開 ここに至るのは 極一部
38. 動物画像SNS
39. レコメンデーション ここになにを 表示する？ 人気の動物写真 ユーザが好きそうな動物写真 検索条件で人気の動物写真 似ている動物写真 簡単・安い 難しい・高い 検 索 ・並 び 替 え 協 調 フィル タリング ランク学習 類似画像検索 ？ ？ ？ 効果
40. 失敗例：変更困難な基盤 DB Log DWH Model DB 学習 基盤 検索 API API ANN CI/ CD DL 監視 CT hard coded
41. 変更するつもりで作る • 機械学習モデルやライブラリ、基盤は頻繁に更 新、変更される。 • すべての新しいライブラリや基盤が 後方互換性を保っているとは限らないし、 新しいモデルが常に良いとも限らない。 • 変更頻度と変更難易度を考慮してシステムを設 計するスキルが求められる。 • 変更がうまくいかない場合はロールバック できるようにしておく。 変更難易度 変更頻度 高 低 低 高 学習データ 学習済みモデル 推論API MLライブラリの更新 GPU データ基盤 ML基盤 永続データ 推論ライブラリ 評価指標 バッチ処理 推論を使う外部システム MLライブラリを変更
42. 推論から考える • 常に推論できるモデル（ =本番システムで使えるモデル）を学習する。 • 推論の優先順位 ◦ まずはルールベースや統計処理で対応可否を検討する。 ◦ 機械学習が必要な場合はバッチ推論（学習と同じシステム構成で可能）を検討する。 ◦ バッチ推論が利用不可の場合（入力が動的に変わる）、同期推論や非同期処理を検討する。 ▪ ONNXやTensorFlowServing、TorchServeを活用可能なモデルを優先して選ぶ。 ▪ 推論ライブラリを使えない場合はサーバで稼働させた場合のパフォーマンスと安定性を 重点的に検証する。 ◦ ユーザ端末でリアルタイム処理が必要な場合は Edge AIを検討する。 ▪ 本当にリアルタイム性が必要か立ち止まって考える。 ▪ Edge AIで使えるモデルは選択肢が少なく、モデルの更新リリースが難しいことを考慮する。 • 学習の考慮事項 ◦ 推論で活用可能なモデルを学習する。 ◦ 学習基盤はメンバー数とモデル数に応じて徐々に導入する。一度に全部入れる必要はない。 ◦ 【超重要】以下 4点を疎かにしてはいけない。 ▪ リーダビリティ、テスト、インターフェイス、ライブラリ管理。 選択肢 難易度 多 少 難 易
43. 基盤、共通システムをどう選ぶか • 技術選定の方針：安い、早い、簡単なものを選ぶ。「有名」というだけで選ばない。 ◦ 安い、早い、簡単は導入後の生産性を左右する。生産性はエンジニアのモチベーションを左右する。 • 導入の手順：安い、早い、簡単かつ取り返しのつかないところから導入していく。 ◦ （前提：DWH、データ基盤） ◦ 実験管理・モデル管理： MLflow、DVC、Weights&Bias、各種クラウド ◦ データ・モデルモニタリング： Grafana、Great Expectations、各種クラウド ◦ 学習パイプライン：Airflow、Argo Workflow、Prefect、各種クラウド ◦ 統合的な機械学習基盤：各種クラウド ◦ その他（Feature Store、Explainable AI、アノテーション・・・） 安い、早い、簡単 No Yes
44. オフラインで実験 • オフラインでモデルの学習を実験する。 • 用途例：機械学習の PoCや開発 • 必要なスキルセット ◦ 学習モデル開発、評価 ◦ モデル管理 ◦ GPU等のインフラ管理 実験 Laptop or Google Colab Model DB DWH レポジト リ
45. バッチ学習 + バッチ推論 • 定期的に学習と推論を実行する。 • 推論の利用が固定値かつ定期更新で良い場合に有効。 • 学習と同じ方法で推論することが可能であるため、 インフラやコードを学習と推論で共有できる。 • 用途例：需要予測、推薦等。 ◦ テーブルデータで使うことが多く、逆に画像や テキストデータだと有効でないことが多い。 • 必要なスキルセット ◦ 学習基盤と学習パイプライン ◦ 推論結果をDBに保存 ◦ 最低限のモニタリング • あると便利なスキルセット ◦ BI ◦ ドリフト検知 DB バッチ 学習 ML基盤 バッチ 推論 Model DB CI/ CD DWH CT レポジト リ 実験 環境 ここを変更するの は簡単。 推論結果を出力す るテーブルはしっ かり設計したほう が良い。
46. バッチ学習 + 同期推論 or 非同期推論 • 定期的に学習したモデルを推論器としてデプロイ。 • リクエストに応じて推論する用途で有効。 • 学習と推論で異なるコード、ライブラリ、インフラ、ライフサイクルが 必要になる。 • 用途例：推薦、検索、違反検知、異常検知。 ◦ 多様な用途で利用可能だが、ワークフローが複雑になると 開発運用が難しくなる。 • 必要なスキルセット ◦ 学習基盤と学習パイプライン ◦ Web APIや非同期処理 ◦ 推論器のビルドと CI/CD • あると便利なスキルセット ◦ BI ◦ ドリフト検知 ◦ API開発と運用 実験 環境 バッチ 学習 ML基盤 CI/ CD DWH ビルド 推論 API 運用 管理 CI/ CD レポジト リ インターフェイスと パフォーマンスが 重要。 ビルドとCIがボト ルネックになるこ とも多い。 推論モデルを目 標に設計する。 Model DB CT
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
48. PoC：機械学習の有効性と有用性を証明する DB Log DWH 検索 API 分析 環境 Prove ML or not ML
49. プログラムマネジメントスキル チームマネジメントスキル フェーズによってチャレンジする機能を選ぶ 機能によって必要なスキルは異なる • 初期フェーズ：0->1を作るチャレンジ ◦ ベースラインになる推薦を作る ◦ 作った推薦アイテムを本番で公開する ◦ 推薦の価値・可視化を分析する • 発展フェーズ：自動化・共通化・高度化するチャレンジ ◦ 推薦とシステムの品質を維持・改善する ◦ 既存の基盤を活用する ◦ 特定ドメインの専門知識を実用化する • 分割・専門化フェーズ：巨大システムを疎結合にするチャレンジ ◦ チームを分割しマネジメントする ◦ 共通課題を仕組みで解決する 早く安くリーズナブルな規模と品質で開発、運用す るスキル 共通化・自動化するソフトウェアスキル 複雑なドメインナレッジと分析力 Item2Item 人気順 BI バッチ推薦 User2Item CI/CT/CD A/Bテスト Personalize 推薦 基盤 共通 基盤 R&D チーム 基盤 チーム 評価
50. 機械学習を実用化するためにMLOpsが必要とは限らない MLOpsを実践するために機械学習基盤が必要とは限らない 機械学習 MLOps 機械学習基盤 解決する手段 定期的な 改善が必要 数が増えて 共通化 自動化したい 共通化したい 機械学習を 使うシステム 組み込む 解決する 共通化したい 課題解決に必要 データで解決 できる課題 課題解決に必要とは 限らない
51. 初期は小さく成功するためのエンジニアリング DB Log DWH 推薦 テーブル 学習 バッチ 検索 API BI 推薦 API 定期的に推薦リストを 作成して記録しておく 推薦テーブルから検索 推薦の評価
52. 定期的なモデル改善のためにMLOpsのプラクティスを取り入れる 複数モデルの開発と運用を共通化・自動化するために基盤を作る 機械学習 MLOps 機械学習基盤 解決する手段 定期的な 改善が必要 数が増えて 共通化 自動化したい 共通化したい 機械学習を 使うシステム 組み込む 解決する 共通化したい データで解決 できる課題
53. 複雑性・エッジケースを内包する DB Log DWH 推薦 テーブル Model DB 学習 基盤 検索 API BI A/B proxy ML API 推薦 API CI/ CD 実験 評価 管理 Auto Scale 監視 CT
54. チーム
55. 失敗例：理想のチームを作ったはずが・・・ ML/DSチーム　6名 • データ分析 • モデル開発 もともとあった
56. 失敗例：理想のチームを作ったはずが・・・ ML/DSチーム　6名 • データ分析 • モデル開発 MLOpsチーム　5名 • ML基盤開発、運用 • MLライブラリ開発 • MLの本番システムへの組み込み もともとあった 新設！
57. 失敗例：理想のチームを作ったはずが・・・ ML/DSチーム　6名 • データ分析 • モデル開発 MLOpsチーム　5名 • ML基盤開発、運用 • MLライブラリ開発 • MLの本番システムへの組み込み ML基盤やライブラリが 使いにくい 研究できない モデルのリリース・修正が 拒否される ML/DSのコードが汚い ML基盤とシステムの 運用が大変 モデルを修正 してくれない コスト管理や コードレビューが 厳しい ML/DSが基盤や ライブラリを使わない ドキュメントがない 新しいML手法が 基盤でサポート されてない
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 研究 スキルセット フェーズの説明 モチベーション 安定開発
59. PoC 失敗例の考察 機械学習 導入開始 実用化 自動化・基盤化 完全自動化 複数システム 機械学習エンジニア 0->1 1->10 研究 ML ドメイン 1->10 バックエンド 基盤 マネジメント MLOpsチーム バックエンドエンジニア + 基盤エンジニア 開発 運用 定型化 管理 新しいMLモデルを 開発、実用化したい 新しいML基盤で 仕組みを作りたい • MLOpsチームの導入目的： ◦ 人数が増えて開発が非効率になっていた MLプロジェクトを共通化、自動化、効率化する。 • MLチームの受け止め方： ◦ これまでうまくいっていた開発を一方的に変えられる。 MLチーム
60. PoC 失敗例の打開案 機械学習 導入開始 実用化 自動化・基盤化 完全自動化 複数システム 機械学習エンジニア バックエンド・ 基盤エンジニア 機械学習エンジニア + バックエンドエンジニア + PM プロダクト別チーム 1MLチーム ドメイン別 チーム MLOps チーム MLチーム 試した施策1 チーム統一 • 各メンバーのチームを統合して役割・スキルを統一する。 • お互いに教え合う文化とリーダーシップが必要。 試した施策2 ドメイン分割 • ドメイン・プロダクトレベルでチームを分割する。 • 「ユーザの課題解決」にフォーカスする目的の共有。 • スキルセットは分散する。
61. PoC・実験フェーズ • モチベーション ◦ 0->1 ◦ 初めての機械学習プロジェクトを完遂 • スキルセット ◦ 行動力・説明力・調整力 ◦ 機械学習 ◦ バックエンド ◦ ドメインナレッジ • システム ◦ データ ◦ 最悪ラップトップ1台でも良い DB Log DWH 分析 環境
62. 初期の実用化フェーズ • モチベーション ◦ 0->1 ◦ 初めての機械学習プロジェクトを完遂 ◦ 運用で安定・改善 • スキルセット ◦ 評価とフィードバックループを作る ◦ バックエンド ◦ 機械学習パイプライン • システム ◦ DWHとワークフロー（バッチ） ◦ DBと推論サーバ DB Log DWH 推薦 テーブル 学習 バッチ 検索 API 推薦 API
63. 拡張・成長・再現性の証明フェーズ • モチベーション ◦ 機械学習活用の再現、拡張 ◦ 高度・複雑な課題解決 • スキルセット ◦ 評価とフィードバックループを作る ◦ バックエンド ◦ 機械学習パイプライン ◦ 再利用性 • システム ◦ ワークフローの再利用 ◦ プロキシと推論サーバ ◦ 管理（モニタリングとBI） ◦ CI/CD 検索 API DB Log DWH 学習 バッチ BI A/B proxy ML API 推薦 API CI/ CD 監視
64. 仕組み化・共通化・自動化フェーズ • モチベーション ◦ 共通化・自動化・基盤開発 ◦ システマチックな課題解決 • スキルセット ◦ CI/CD/CT ◦ 評価と品質管理 ◦ 機械学習基盤 ◦ サービスディスカバリと推論 API ◦ チームマネジメント ◦ ドキュメンテーション • システム ◦ 機械学習基盤 ◦ ワークフロー管理 ◦ インフラ管理 ◦ 実験管理 DB Log DWH 推薦 テーブル Model DB 学習 基盤 検索 API BI A/B proxy ML API 推薦 API CI/ CD 実験 評価 管理 Auto Scale 監視 CT
65. 分割・専任化フェーズ • モチベーション ◦ 開発・運用生産性の向上 ◦ コミュニケーションコスト削減 ◦ 大規模開発と育成 ◦ 多様性の受容 • スキルセット ◦ マネジメント ◦ 調整力・俯瞰力 ◦ ドキュメンテーション ◦ 他人の作った基盤を使う能力 • システム ◦ チームコミュニケーション ◦ データとインフラの共通基盤 ◦ システムの個別化・独立化 インフラ クラウド、ネットワーク、アカウント データ基盤 ML基盤 共通基盤 （ログ、モニタリング、 CI/CD・・・） ユーザインタフェース （Web、スマホ、その他） バックエンド バックエンド バックエンド 機械学習 機械学習 機械学習
66. まとめ
67. ユーザに価値を与える機械学習を目指して • 企画・プロダクト：課題から始める、 Little effortから始める • 技術：再現性を証明する、変更するつもりで作る • チーム：スキルセットとモチベーションを一致させる
68. ありがとうございました！