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

MoT/コネヒト/Kanmu が語るプロダクト開発xデータ分析 - 分析から機械学習システムの開発まで一人で複数ロールを担う大変さ

MoT/コネヒト/Kanmu が語るプロダクト開発xデータ分析 - 分析から機械学習システムの開発まで一人で複数ロールを担う大変さ

MoT/コネヒト/Kanmu が語るプロダクト開発xデータ分析の登壇スライドです.
https://kanmu.connpass.com/event/270440/

プロジェクト推進・データ分析から機械学習システムの開発まで一人で複数ロールを担って進めていく苦労話とそこでの経験・知見を紹介しています.

Masataka Kashiwagi

January 26, 2023
Tweet

More Decks by Masataka Kashiwagi

Other Decks in Technology

Transcript

  1. 自己紹介 名前:柏木 正隆(Masataka Kashiwagi) 所属:コネヒト株式会社 - 機械学習エンジニア 出身:大阪府 SNS Twitter:@asteriam_fp(あと50人ぐらいでフォロワー数1000人🙏)

    Podcast:@double_m2ml お仕事 • レコメンドエンジンの開発 • 検索システムのデータ整備(←最近のメインのお仕事) • MLOpsの推進 MLOps勉強会の運営メンバーとしても活動してます! Twitterアイコン
  2. アジェンダ ☑ 自己紹介 ☑ 会社・サービス紹介 □ 分析から機械学習システムの開発まで一人で複数ロールを担う大変さ - 機械学習のライフサイクルとロール -

    ここ最近の経験を紹介 - プロジェクト初期フェーズの話 - 機械学習モデル開発の話 - 機械学習システム運用の話 □ まとめ 本発表はデータ分析要素あまり無くてすいません󰢛 ※ 本資料は後ほど公開します!
  3. フェーズ毎の実施内容 Business and Data Understanding • ビジネス課題の整理 ◦ MLタスクへの落とし込み •

    施策立案/KPIの設定 • PoCの実施/プロトタイプ作成 • データ収集/加工/整備/可視化 Model Development • 特徴量の整備 • モデル作成/評価 • モデルデプロイ • サービング Model Operations • モニタリング ◦ データドリフト ◦ モデルの性能 ◦ パフォーマンス • CI/CD/CT • MLプロセスの見直し データアナリスト データサイエンティスト データサイエンティスト 機械学習エンジニア 機械学習エンジニア
  4. フェーズ毎の実施内容 Business and Data Understanding • ビジネス課題の整理 ◦ MLタスクへの落とし込み •

    施策立案/KPIの設定 • PoCの実施/プロトタイプ作成 • データ収集/加工/整備/可視化 Model Development • 特徴量の整備 • モデル作成/評価 • モデルデプロイ • サービング Model Operations • モニタリング ◦ データドリフト ◦ モデルの性能 ◦ パフォーマンス • CI/CD/CT • MLプロセスの見直し データアナリスト データサイエンティスト データサイエンティスト 機械学習エンジニア 機械学習エンジニア 各フェーズ,専門的な知識・経験が求められる!
  5. 主なプロジェクトをピックアップ • レコメンドシステムの新規開発 ◦ フェーズ:PdMとの施策立案段階する初期フェーズから(Business and Data Understanding) ◦ ロール:データサイエンティスト・MLエンジニア(・データエンジニア)

    • 検閲システムのプロダクション導入 ◦ フェーズ:PoCを終えてプロダクションに移行するフェーズから(Model Development) ◦ ロール:MLエンジニア • 検索システムのデータ基盤の構築 ◦ フェーズ:検索基盤を1から構築するフェーズから(Business and Data Understanding) ◦ ロール:データエンジニア(・検索エンジニア?)
  6. レコメンドシステムの新規開発において... 機械学習のライフサイクル毎に見てみると... Business and Data Understanding Model Development Model Operations

    • As is ~ To beなどの議論 with PdM ◦ ユーザーへの良い影響とは? ◦ 発散→徐々にスコープを絞る ◦ ROIが本当にあるか? • 要件・制約条件のヒアリング ◦ どんなアイテム出すか ◦ 除外したいアイテムは? ◦ 期待値調整 • KPIの設定 ◦ CTR?滞在時間? • ABテストの実験計画 • プロジェクトのスケジューリング • データ分析 • レコメンド提供形態の検討 • レコメンドモデルの開発 ◦ 実験管理 • モデル評価 • 学習パイプラインの構築 ◦ 設計 & 検証 • ML-APIの開発 • デプロイメント • アラート設定 • システム運用手順の整理 ◦ 再学習手順 ◦ エラー時の対応 • モニタリング ◦ パフォーマンス確認用のダッ シュボード作成 ◦ オフライン評価指標とビジネ スメトリクスの連携 • 改善案のプランニング
  7. DS & DEで苦労したことの一例 Business and Data Understandingのフェーズでは,2つの役割を担う必要があった データサイエンティスト - スケジューリング

    → 大抵予定通りに行かない😇 - ログがアプリ側で出力できていない...アプリ ケーションエンジニアに依頼 & 開発期間を 確保 - (当たり前だが)ドメインの理解 - 指標一つ決めるにも,なぜPdMはそれを選択 しているのか... データエンジニア - 機能・非機能要件の整理 - フィジビリティスタディ & チェック - 運用を意識した仕組み作り - 安定的なデータインジェスト - コード管理
  8. • What・Whyを意識してPdMと議論する ◦ ついついHowの事を考えがちになる → どんなMLモデルを作ればいいか? ◦ スコープ決め・期待値調整・ML導入によるROIの確認などは特に大事! • 定性・定量の両面で議論できるようにするのが大事

    ◦ レコメンドモデルのオフライン指標は良いが,定性的にも良さげか ◦ ダッシュボードを作成し,数値をチーム内で確認できるようにする • データの品質・信頼性といった観点 ◦ 後段の機械学習モデルの性能やパイプラインのエラーに繋がる → ユーザー影響にも繋がる ◦ データの話はPdM含めてもっと議論しても良いと思う プロジェクトで大事 & 意識してたこと
  9. Ref. 1. ML Experiment Tracking: What It Is, Why It

    Matters, and How to Implement It Experiment tracking vs ML model management vs MLOps Model Managementにおいて • Experiment Tracking • Model Deployment は大事な要素!
  10. 再現性を担保するための取り組み “実験管理ツールを導入して,必要な情報を記録しチームで情報を共有できる仕組みが必要” ※ 元々共通の実験管理は行われていなかった状態 実験管理ツール(SageMaker Experiments)を導入 - 再現性に必要な情報を記録可能🎉 - Code/Data/Environment/Model

    parameters - 本番への接続がスムーズに! - メトリクスを使った議論が可能に🎉 - チーム内で実験結果の共有が可能に🎉 - 一方で,コード管理は未だ上手い方法を模索中 Amazon SageMaker Experiments
  11. モデル学習後のデプロイメントが複雑だと... - メンテナンスコストが高い - プロセスが複雑だと,オペレーションミスが発生する可能性も - 素早くモデルをプロダクションに適用できない場合も - e.g. 既存のものだと...

    - ETLは自動化されているが,モデル作成 & デプロイは手動 モデルデプロイメントの仕組みを構築 (モデルデプロイの話はレコメンドシステムとは別システムの話になりますが,MLエンジニアとしての苦労話として...)
  12. モデル学習からデプロイメントまで自動化 独自のカスタムコンテナ イメージを利用 実験管理はSageMaker Experimentsを使用 Step Functionsを用いてパイプライン全体を管理 ・学習にはSageMaker Training Jobを利用

    ・実験結果をExperimentsとシームレスに接続 ・それ以外はProcessing Jobを利用 アーティファクトはS3に保存 モデルのデプロイまでStep Functions内で完結 デプロイ後はSageMakerでエンドポイントをホスティング カスタムコンテナイメージを利 用し,独自の推論処理を実装 Ref. 1. SageMakerとStep Functionsを用いた機械学習パイプラインで構築した検閲システム(前編) 2. SageMakerとStep Functionsを用いた機械学習パイプラインで構築した検閲システム(後編)
  13. モデル学習からデプロイメントまで自動化 “複雑なステップを踏まずにプロセスをシンプルにしたい” ※ 元々モデルデプロイメントの仕組みは整っていなかった状態 SageMakerとStep Functionsによる一気通貫したパイプラインの構築 - 低コストでモデル学習からデプロイメントまで可能🎉 - AWS特有の記述を意識せずシンプルにできる

    - 手動オペレーションが入らないので,素早くサービスインできる状態までいける🎉 - ML-APIからのエンドポイントの切り替えでいつでも使える状態に! - パイプラインにすることで,実験結果を取得するジョブも簡単に追加可能🎉
  14. MLSysの運用と改善 • システム運用手順の整理 - アラートやエラーが発生した場合に,どのように動くか対応はどう するかなど曖昧になっている部分が多かった → ユーザー影響 - 取り組み:

    - テンプレートを作成し,ドキュメンテーション - アラートパターン(エラーパターン)毎の対応を定義 - アラートレベル:warn or critical - エラー時に実際どのように動くかを予め決めておく - 関係者同士での合意形成 - 何を監視すべきか,通常の業務の中でどのように取り入れてい くかを議論することで運用レベルを上げる 手順書(runbook)
  15. MLSysの運用と改善 • オンライン/オフラインメトリクスを横断して見れるダッシュボードの作成 - モデルの改善がビジネスメトリクスの改善に繋がっているのかわかりにくい → 紐付けて見れると分析しやすい - 取り組み: -

    モデル学習のパイプラインに実験結果を抽出して保存できる処理を追加 → S3にデータを保存 - S3 → Athena → redashと連携し,BIツールで見れる仕組みを構築 - 連携項目 - ハイパーパラメータ,オフラインメトリクス,モデルパス,学習時間 ...etc メトリクスダッシュボード アーキテクチャー
  16. 色んなことを紹介しましたが... • ユーザーにとって何がベストなのかを考えるので,正直ロールはあまり気にしていない ◦ 専門的なポジションの人が居るなら,その人に任せる ◦ 居ない & その人が忙しいなら,自分がする気持ち ▪

    わからないことは聞いて教えて貰う & 勉強する ◦ What & Whyを大事に,Howから入らずバランス良く(エンジニアとしてこだわりは持ちたいが柔軟に!) • 属人化しない取り組みが大事! ◦ 人が少ないと属人化しがちだが,少しでもいいのでできることを増やす ▪ チームでオーバーラップする部分を増やす ◦ 自動化することも考えるが,使われない & メンテナンスされないと負債になるので注意 ◦ 統一化されたドキュメントでの合意形成 ▪ 再現性 / テンプレート活用(Design Doc) • キャプチャー/gifなどを使って,わかりやすく