DSOps #6-2

公開用

Transcript

1. DSOps研修 6回 DS/MLタスクと価値 金子 雄祐 1
2. 概要 • DS/ML職がタスクのどこで価値を出していくのか? • Dynalystの事情と照らし合わせつつ話す
3. DS/ML職の価値の出し方とは? 3
4. DSチームがプロダクト所属か横断組織所属かによって役割が大きく違う • 横断組織所属 ◦ やるタスクと役割が明確 ◦ 例: MLモデルの推論APIとその更新機能、大規模データ基盤など ◦ 班によって担当するタスクが違う • プロダクト所属 ◦ DSの担当範囲がはっきりしていない ◦ プロダクトや人によってやるタスクの範囲が違う 前提: 横断組織? プロダクト所属? 以後ではプロダクト所属のDSについて話していく
5. ML/DS開発のフロー 仮説立て 調査 モデリング オフライン 検証 プロダクト 実装 A/B test 評価 DS
 ML
 5
6. ML開発を細分化する
 データ分析タスク • 仮説検証 • 調査 • KPI設計 • プロダクトの意思決定 に関わる分析など データサイエンスタスク • MLモデルのオフライ ン検証 • 本番環境でのA/Bテス トの評価 データエンジニアリングタス ク • ログを出す部分 • テーブルやカラムの 追加 MLエンジニアリングタスク • MLモデルのプロダク ト実装 • MLOps データアナリスト データサイエンティスト 機械学習エンジニア
7. チームでどうML開発をこなすか？ 1. それぞれのメンバーが全部のフローやる 2. メンバーがフローを分業する
8. それぞれが全部やる事例: Dynalyst • DynalystではDS全員がそれぞれ一連のML開発フローを担当 • 流れの一例 ◦ 仮説からデータの調査
 ◦ オフライン検証によってA/BすべきMLモデルを決める
 ◦ PythonとScalaでバッチ学習の実装、Scalaで推論側の実装
 ◦ A/Bテスト1: 期待通りにMLモデルが動作しているかの確認
 ▪ 学習ジョブがコケないか、パラメータが引けているかなど
 ◦ A/Bテスト2: 既存モデルとの性能比較
9. それぞれが全部やるメリット / デメリット メリット • DS視点でのシステム設計ができる ◦ システム的な実現可能性 / 相性などを考慮し てDSタスクに取り組める ◦ 事前にML開発の工数を予想できる ◦ A/Bテストしやすい設計を考えられる • データから実装のおかしい部分を発見できる ◦ DS / バックエンドで分業しにくい部分 • 誰かに頼まなくていい • 全部をやらない場合でも、バックエンドエン ジニアとの会話がスムーズになる デメリット • 全員がDSとエンジニアリングに習熟する必要 がある • 大人数になるとワークしない ◦ A/Bの待ち時間を考慮すると、所属人数x2く らいの開発タスクが同時期に走る ◦ 人数が増えるほどコンフリクトが起きやすく なる • 個人の裁量が大きすぎて責務が大きすぎる?
10. 分業する事例: プロダクトK • 体制 ◦ DS ◦ 研究組織のクリエイティブ領域の人 ◦ ML(Ops)エンジニア • それぞれの役割 ◦ DSメンバー：分析・モデル研究開発＋マイナーアップデートは自分で導入までやる(特徴量追加等) ◦ AILabメンバー：分析・モデル研究開発 ◦ MLOpsエンジニア：MLOpsまわりの新システム開発＋改善＋Lab, DSが開発した新規モデルの導入 • DSもエンジニアリングを行うが, 比重がDSタスク>>>エンジニアリング
11. 分業のメリデメ(体感) • メリット ◦ それぞれがDSタスク / MLエンジニアリングタスクに集中できる • デメリット ◦ 分業によるコミュニケーション齟齬が起きやすい ▪ 認識のズレがでてきそう
12. 結局全部やるのと分業はどちらがいいのか? 12 • Dynalystのチーム運営をする中での(金子の)考え • 正直に言うと「全部やってくれたほうがマネージャーとしては楽」 ◦ 「仮説立て」→ 「実装」 → 「ビジネスインパクト出しました」という流れで価値出しまし た，というのは評価しやすいし，アピールもしやすい • プロジェクトが長期化していることや個人の責任が大きすぎることが最近の悩み ◦ 仮説立て = 「改善できそうなネタ」を最初に立案するのがDS個人に担われている ◦ 普通に半年くらい同じことやってたりする ▪ タスクの種類によっては違うが... ◦ もっといいプロジェクトの持ち方はないのか? • 分業できるならしたいけど，かといって他の会社の話聞いててもそこまで分業はしてなさげ ◦ 「DSチーム」って結局何を達成できてればいいの? • Dynalystの現状の課題感から考えてみる
13. Dynalystのチーム課題 • 現状の体制 ◦ DSメンバー 5 ~ 10人 ◦ DSメンバーについては程度の差はあるが基本全員が分析から実装までやる • 現状の課題感 ◦ プロジェクトの長期化 ◦ MLのソースコードすべてを把握している人がいない ◦ SEがやるべき実装とDSがやるべき実装の区分が曖昧 ◦ 結局個人プロジェクトの寄せ集めでしかない ▪ 分業するならどういうプロジェクトが立てられる?
14. ML/DS開発のフロー(再) 仮説立て 調査 モデリング オフライン 検証 プロダクト 実装 A/B test 評価 DS
 ML
 14
15. 分解例 1 仮説立て 調査 モデリング オフライン 検証 プロダクト 実装 A/B test 評価 DS
 ML
 15 立案・分析専任
 立案・分析専任
 プロダクト実装専任

16. 分解例 2 仮説立て 調査 モデリング オフライン 検証 プロダクト 実装 A/B test 評価 DS
 ML
 16 立案専任
 手を動かす専任
 評価専任

17. DynalystDSチームとしてどうしたいか？ • ある程度DSタスクとエンジニアリングを分業できるようにする ◦ DSタスクだけで成果を出したい人も働けるようにしたい ▪ 現状のDynalyst DSチームは分析力が上がる機構がない ▪ 分析だけでoutputを出したロールモデルが少ない ◦ MLエンジニアリングに興味を持ってそれメインでやれる人を育てる/採用する必要 • DSチームとしてのチーム力を付けたい ◦ 結局個人プロジェクトの集積に過ぎないのでは? という疑問 ◦ チームに居る中でベストプラクティスの共有とかがあればいい ▪ notionなどでの事例管理 • 「全部やる」人が一番評価される状況からの脱却
18. 「全部やらない」DS/MLがどう価値を出す？ • それぞれ以下の価値をどこで出すかが問題? ◦ エンジニアリングをやらないDS ◦ DSタスクをやらないMLエンジニア • エンジニアリングやらないDS ◦ 事業の意思決定をするようなデータ分析 ◦ MLで何が解けるかを理解しているからこそ出てくる改善案 ◦ 結局ビジネス理解に基づいた「課題発見能力」と「戦略性」が一番重要になってくる? • DSタスクをやらないMLエンジニア ◦ DSタスクを全部放棄してもいいのか?(事前分析や可視化) ◦ KPI設計やプロダクトの意思決定に関わる ◦ 例 : 本質的じゃない指標の最適化のタスクだけやってていいのか?
19. Q ML/DS的に「全部やらなくても」outputの価値を 最大化するにはどこを担保すればいいと思いますか?