Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
DSOps #6-2
Search
Yusuke Kaneko
February 28, 2022
0
22k
DSOps #6-2
公開用
Yusuke Kaneko
February 28, 2022
Tweet
Share
More Decks by Yusuke Kaneko
See All by Yusuke Kaneko
効果検証、入門の入門(後半)
ykaneko1992
3
380
Kdd 2021 読み会(clustering for private interest-based advertising & learning a logistic model from aggregated data)
ykaneko1992
0
20
企業の中の経済学
ykaneko1992
0
28
DSOps #1
ykaneko1992
3
32k
DSOps #2
ykaneko1992
0
27k
DSOps #4
ykaneko1992
0
30k
DSOps #5-1
ykaneko1992
0
27k
DSOps #5-2
ykaneko1992
0
27k
DSOps #6-1
ykaneko1992
0
26k
Featured
See All Featured
Designing on Purpose - Digital PM Summit 2013
jponch
115
6.9k
Fontdeck: Realign not Redesign
paulrobertlloyd
81
5.2k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
107
49k
The Cult of Friendly URLs
andyhume
78
6k
Music & Morning Musume
bryan
46
6.1k
Designing Experiences People Love
moore
138
23k
The Power of CSS Pseudo Elements
geoffreycrofte
72
5.3k
Measuring & Analyzing Core Web Vitals
bluesmoon
1
40
Thoughts on Productivity
jonyablonski
67
4.3k
KATA
mclloyd
29
13k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
27
4.2k
Facilitating Awesome Meetings
lara
49
6k
Transcript
DSOps研修 6回 DS/MLタスクと価値 金子 雄祐 1
概要 • DS/ML職がタスクのどこで価値を出していくのか? • Dynalystの事情と照らし合わせつつ話す
DS/ML職の価値の出し方とは? 3
DSチームがプロダクト所属か横断組織所属かによって役割が大きく違う • 横断組織所属 ◦ やるタスクと役割が明確 ◦ 例: MLモデルの推論APIとその更新機能、大規模データ基盤など ◦ 班によって担当するタスクが違う
• プロダクト所属 ◦ DSの担当範囲がはっきりしていない ◦ プロダクトや人によってやるタスクの範囲が違う 前提: 横断組織? プロダクト所属? 以後ではプロダクト所属のDSについて話していく
ML/DS開発のフロー 仮説立て 調査 モデリング オフライン 検証 プロダクト 実装 A/B test
評価 DS ML 5
ML開発を細分化する データ分析タスク • 仮説検証 • 調査 • KPI設計 • プロダクトの意思決定
に関わる分析など データサイエンスタスク • MLモデルのオフライ ン検証 • 本番環境でのA/Bテス トの評価 データエンジニアリングタス ク • ログを出す部分 • テーブルやカラムの 追加 MLエンジニアリングタスク • MLモデルのプロダク ト実装 • MLOps データアナリスト データサイエンティスト 機械学習エンジニア
チームでどうML開発をこなすか? 1. それぞれのメンバーが全部のフローやる 2. メンバーがフローを分業する
それぞれが全部やる事例: Dynalyst • DynalystではDS全員がそれぞれ一連のML開発フローを担当 • 流れの一例 ◦ 仮説からデータの調査 ◦ オフライン検証によってA/BすべきMLモデルを決める
◦ PythonとScalaでバッチ学習の実装、Scalaで推論側の実装 ◦ A/Bテスト1: 期待通りにMLモデルが動作しているかの確認 ▪ 学習ジョブがコケないか、パラメータが引けているかなど ◦ A/Bテスト2: 既存モデルとの性能比較
それぞれが全部やるメリット / デメリット メリット • DS視点でのシステム設計ができる ◦ システム的な実現可能性 / 相性などを考慮し
てDSタスクに取り組める ◦ 事前にML開発の工数を予想できる ◦ A/Bテストしやすい設計を考えられる • データから実装のおかしい部分を発見できる ◦ DS / バックエンドで分業しにくい部分 • 誰かに頼まなくていい • 全部をやらない場合でも、バックエンドエン ジニアとの会話がスムーズになる デメリット • 全員がDSとエンジニアリングに習熟する必要 がある • 大人数になるとワークしない ◦ A/Bの待ち時間を考慮すると、所属人数x2く らいの開発タスクが同時期に走る ◦ 人数が増えるほどコンフリクトが起きやすく なる • 個人の裁量が大きすぎて責務が大きすぎる?
分業する事例: プロダクトK • 体制 ◦ DS ◦ 研究組織のクリエイティブ領域の人 ◦ ML(Ops)エンジニア
• それぞれの役割 ◦ DSメンバー:分析・モデル研究開発+マイナーアップデートは自分で導入までやる(特徴量追加等) ◦ AILabメンバー:分析・モデル研究開発 ◦ MLOpsエンジニア:MLOpsまわりの新システム開発+改善+Lab, DSが開発した新規モデルの導入 • DSもエンジニアリングを行うが, 比重がDSタスク>>>エンジニアリング
分業のメリデメ(体感) • メリット ◦ それぞれがDSタスク / MLエンジニアリングタスクに集中できる • デメリット ◦
分業によるコミュニケーション齟齬が起きやすい ▪ 認識のズレがでてきそう
結局全部やるのと分業はどちらがいいのか? 12 • Dynalystのチーム運営をする中での(金子の)考え • 正直に言うと「全部やってくれたほうがマネージャーとしては楽」 ◦ 「仮説立て」→ 「実装」 →
「ビジネスインパクト出しました」という流れで価値出しまし た,というのは評価しやすいし,アピールもしやすい • プロジェクトが長期化していることや個人の責任が大きすぎることが最近の悩み ◦ 仮説立て = 「改善できそうなネタ」を最初に立案するのがDS個人に担われている ◦ 普通に半年くらい同じことやってたりする ▪ タスクの種類によっては違うが... ◦ もっといいプロジェクトの持ち方はないのか? • 分業できるならしたいけど,かといって他の会社の話聞いててもそこまで分業はしてなさげ ◦ 「DSチーム」って結局何を達成できてればいいの? • Dynalystの現状の課題感から考えてみる
Dynalystのチーム課題 • 現状の体制 ◦ DSメンバー 5 ~ 10人 ◦ DSメンバーについては程度の差はあるが基本全員が分析から実装までやる
• 現状の課題感 ◦ プロジェクトの長期化 ◦ MLのソースコードすべてを把握している人がいない ◦ SEがやるべき実装とDSがやるべき実装の区分が曖昧 ◦ 結局個人プロジェクトの寄せ集めでしかない ▪ 分業するならどういうプロジェクトが立てられる?
ML/DS開発のフロー(再) 仮説立て 調査 モデリング オフライン 検証 プロダクト 実装 A/B test
評価 DS ML 14
分解例 1 仮説立て 調査 モデリング オフライン 検証 プロダクト 実装 A/B
test 評価 DS ML 15 立案・分析専任 立案・分析専任 プロダクト実装専任
分解例 2 仮説立て 調査 モデリング オフライン 検証 プロダクト 実装 A/B
test 評価 DS ML 16 立案専任 手を動かす専任 評価専任
DynalystDSチームとしてどうしたいか? • ある程度DSタスクとエンジニアリングを分業できるようにする ◦ DSタスクだけで成果を出したい人も働けるようにしたい ▪ 現状のDynalyst DSチームは分析力が上がる機構がない ▪ 分析だけでoutputを出したロールモデルが少ない
◦ MLエンジニアリングに興味を持ってそれメインでやれる人を育てる/採用する必要 • DSチームとしてのチーム力を付けたい ◦ 結局個人プロジェクトの集積に過ぎないのでは? という疑問 ◦ チームに居る中でベストプラクティスの共有とかがあればいい ▪ notionなどでの事例管理 • 「全部やる」人が一番評価される状況からの脱却
「全部やらない」DS/MLがどう価値を出す? • それぞれ以下の価値をどこで出すかが問題? ◦ エンジニアリングをやらないDS ◦ DSタスクをやらないMLエンジニア • エンジニアリングやらないDS ◦
事業の意思決定をするようなデータ分析 ◦ MLで何が解けるかを理解しているからこそ出てくる改善案 ◦ 結局ビジネス理解に基づいた「課題発見能力」と「戦略性」が一番重要になってくる? • DSタスクをやらないMLエンジニア ◦ DSタスクを全部放棄してもいいのか?(事前分析や可視化) ◦ KPI設計やプロダクトの意思決定に関わる ◦ 例 : 本質的じゃない指標の最適化のタスクだけやってていいのか?
Q ML/DS的に「全部やらなくても」outputの価値を 最大化するにはどこを担保すればいいと思いますか?