Data Gateway Talk vol.5に参加してきました
本日、Data Gateway Talk vol.5に参加してきました。LTの内容などイベントについてまとめてみます。 data-gateway-talk.connpass.com
※殴り書き状態なので徐々にきれいにしておきます
※記載内容や章立ては私の解釈で勝手に書いてます
- データ視覚化について：奥田さん（スイッチ・メディア・ラボ）
- 「データ分析」の解像度を上げたい：松村さん（Wantedly)
- GBDTアルゴリズム：やっしーさん（工学院大学）
- Hivemallを使ってSQLで機械学習：馬場さん（ブレインパッド）
- SHAP(SHapley Additive exPlanations)で機械学習モデルを解釈する：morishitaさん
- リサーチデータと付き合うために大事なこと：池澤さん（FiNC）
- 意思決定に回帰分析を利用した話と3つの学び：Futamiさん(Retty)
- データ分析とベンチャーと上場...：太田さん（ブレインパッド、CDTO）
データ視覚化について：奥田さん（スイッチ・メディア・ラボ）
ドメイン知識
視聴率では見えないもの 視聴率が高い番組にCM出稿 →リーチさせたい人にリーチできてないかも
リーチ率など数値がわかったとしてどう伝えるか →意思決定を促進できるデータを伝える（知りたいこと、次につながること）
見せ方の話 →ユニークリーチ、重複リーチ
分析も大事だが、意思決定に結び付く見せ方を考えるのは大事
「データ分析」の解像度を上げたい：松村さん（Wantedly)
課題
businessチームからのSQL作成依頼殺到 売上を聞かれてその次は？ →データ分析に対する期待値が違う
分析とは
正解はないが自分なりの解釈が重要 「A or B」という問いに対して買いを出すこと Ex. 施策としてよかった？前よりよい？→Yes/No どっちがよい？→A or B or C
Yes/Noの基準 これまでとの比較、目標との比較、などなど
本当に知りたいことを推し量る能力が必要 事実のみ伝えればよい場合もある
判断基準
普遍的なものではなく、その場の前提条件に基づいて導出される
まとめ
- A or B という問い
- 事実＝数字
- 判断基準
- 解
GBDTアルゴリズム：やっしーさん（工学院大学）
Dgtalk from ShoichiYashiro
www.slideshare.net
勾配ブースティング
前の弱分類期の予測値の誤差を新しい弱分類器が引き継いで小さくしていく手法
XGBoost
分割検出の際の勾配統計のキャッシュミスが問題となる（速度・精度低下につながる）
LightGBM
最適な枝分かれを探すための計算コストの削減 →演算量が少なくて軽い
CatBoost
新しい木を生成する際に（聞き取れず）
実証
速い順 LightGBM > CatBoost > XGBoost
Hivemallを使ってSQLで機械学習：馬場さん（ブレインパッド）
Hivemall
Hadoop →ビッグデータを扱うためのミドルウェアで並列分散処理 Hive →Hadoop上でDBMS機能提供
Hivemall →HiveQLクエリを使って学習から予測まで機械学習の一連の処理を行う機械学習ライブラリ
モデルや学習結果はテーブルで管理
Hivemallの使いどころ
デジマケで機械学習するとなると 環境用意のリソース、加工・転送の実装、運用コストが問題となる →HivemallならDBだけで一連のフローが実現可能
SHAP(SHapley Additive exPlanations)で機械学習モデルを解釈する：morishitaさん
動機
予測した理由を知りたい 例：なぜ「返済確率が低い」と予測したか、理由が知りたい
貢献度による差分の分解
どうやって効果を分解するか？ →線形モデル以外だと分解が難しい →協力ゲーム理論を使う
報酬のフェアな配分
3人に報酬をフェアに分配するには？ →限界貢献度を使う
限界貢献度 →A君が参加したときの報酬の増加分 →順番に依存してしまう
順番による依存を解消するため、平均的な限界貢献度(Shapley Value)を使う
機械学習にShapleyValueに応用：SHAP
特徴量をプレイヤーと見立てる
特徴量がないときの予測値をどう作るか？ →「ない」変数は周辺化して消してしまう
可視化
Shap.dependence_plor(........) Shap.suummary_plot(......)
まとめ
SHAPを用いることで「なぜその予測値を出したのか」を特徴量の貢献度に分解して解釈できる
リサーチデータと付き合うために大事なこと：池澤さん（FiNC）
事例：アンケートツールの導入
アンケートデータがたまってので分析しようとしたが...
課題
手動で管理・集計 ツールログイン権限 APIがない データ形式が特殊 →分析レポートを出すのにコスト、手動対応が大変
解決策
S3 → Jenkins → Redshift、分析レポートはRedashで可視化
まとめ
導入前に、導入後に問題が起きないかを想定しておく 社内で使えるようデータ整形する 自動化できる箇所は自動化
反省
自分だけで課題に取り組もうとしない →知見のある人を巻き込むべき 困っている人と議論する
意思決定に回帰分析を利用した話と3つの学び：Futamiさん(Retty)
回帰分析の手順
課題設計
・意思決定者の把握、意思決定の内容を把握 →やらないと差し戻しが起こる
分析設計
・説明変数をMECEに ・交互作用の掛け合わせは後から行う
事例 プッシュ通知と新規/既存の組み合わせで重回帰分析 →本当にこの組み合わせでインパクトするか？
分析評価
・予測誤差の精度は参考程度 ・p値や信頼区間から影響度を評価 ・意外な説明変数があった場合は考察が必要
まとめ
・意思決定 ・MECEな分析設計 ・効きそうな説明変数を選ぶ
データ分析とベンチャーと上場...：太田さん（ブレインパッド、CDTO）
ベンチャー時代のBrainPad
もっとデータを活用しようという思想に共感 上場を体験できる 泥臭いことを若いうちに経験しておきたい
・組織が半年で変わる ・残業がとても多い ・バックグラウンドやスキルがバラバラ ・上場にあたり売上重視な雰囲気に
組織の変化
・前はマネジメントが専任でなく、裁量が大きい ・大きな仕事がとれるようになった
お金の話
・福利厚生を含めると大手には勝てない
経営陣との距離感
・ 経営陣との距離感が近いことが一番よかった ・会社を立ち上げて経営している人の話は刺激的
Quick&Dirty
・完璧である必要はないので、早くアウトプットを出すスタイル ・フィードバックを多くもらえるので結果的にアウトプットの質が向上する＆安心して仕事ができる →プライドが邪魔をするので常に意識
プレイヤーからマネジメントへ
・リーダーになったが結局自分でやってしまった →「株式者おおたまん」だと思ってやってみな という言葉をもらう →何をしたいのかを本気で考え、そのために何ができるのかを本気で考える
好循環の自己強化ループに自分をまきこむ
登壇する→知ってもらえる→声がかかる
