タウンワークにおける機械学習API@GKEの導入

by kosuke-kitahara

Slide 1

Slide 1 text

タウンワークにおける機械学習API@GKEの導入リクルートジョブズ　商品本部　データマネジメント部コアテクノロジーグループ北原　康佑 (@KosukeKitahara) [email protected]

Slide 2

Slide 2 text

Background: - 香川高専　詫間キャンパス　情報工学科 - 東京農工大学大学院　情報工学科 - リクルートホールディングス　入社 (2017) - データサイエンティスト/MLエンジニア/サーチエンジニア Research Area: - Neuroscience 今やっていること: - タウンワークの検索ロジック/APIの開発 About Me

Slide 3

Slide 3 text

学生時代の活動【大学】Nueroscience http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0184245 【高専】デジタルアート https://www.youtube.com/watch?v=RFHBeELw1p4

Slide 4

Slide 4 text

本日のアジェンダ機械学習API@GKEについて (10 min) - タウンワークの紹介 - ジョブーブの相談部屋について - タウンワークのドメイン特性 - 誰の何を解決するのか？ - ロジックについて - アーキテクチャ@GKEの紹介 MLエンジニアが価値を発揮するためには (10 min) - ML組織のぶち当たる壁と乗り越え方 - 効果観点の検証 -> 実運用時の課題&ベストプラクティスまとめ&質疑応答 (10 min)

Slide 5

Slide 5 text

機械学習API@GKEの導入について

Slide 6

Slide 6 text

・日本最大級の求人情報提供サービス・アルバイトパート系の求人が多数タウンワークのご紹介

Slide 7

Slide 7 text

① 日常的に利用するものではないため、ユーザーのアクション数が少ない → データが少ない ② 初訪問時に具体的なニーズが顕在化していないユーザーが多い → ディレクトリ型検索が難しいタウンワークのドメイン特性

Slide 8

Slide 8 text

① 日常的に利用するものではないため、ユーザーのアクション数が少ない → データが少ない ② 初訪問時に具体的なニーズが顕在化していないユーザーが多い → ディレクトリ型検索が難しいタウンワークのドメイン特性受動的な検索でニーズを顕在化

Slide 9

Slide 9 text

Problems & Segment Problems: ・ユーザーが理想のバイトを理解していない自分のやりたいことがふわっとしていて、それをどうやって調べたらいいかユーザー本人もわからない・ディレクトリ型検索の「能動的な選択」は難しい Segment: ・バイトはしたいが、自分自身も、自分のやりたいバイトをはっきりと認知して　いないユーザー

Slide 10

Slide 10 text

Solution: ・ユーザーが持つ潜在的なニーズを引き出すサポートをする・受動的な検索体験を提供 Product: ・ジョブーブの相談部屋 Solution & Product

Slide 11

Slide 11 text

Solution: ・ユーザーが持つ潜在的なニーズを引き出すサポートをする・受動的な検索体験を提供 Product: ・ジョブーブの相談部屋 Solution & Product

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

ロジックのイメージ対話ロジック自分にはどんな仕事が向いているだろう? この仕事好きかも...!!

Slide 14

Slide 14 text

・条件付き確率場(CRF) ・情報エントロピーの最小化自分にはどんな仕事が向いているだろう? 対話ロジックこの仕事好きかも...!! ロジックのイメージ

Slide 15

Slide 15 text

ある職種が好きか尋ねた時に、得られる情報量エントロピーが最小になるような職種をユーザーに尋ねるこれを複数回繰り返すことで、ユーザーが興味のある職種を絞り込んでいくユーザーログから、ある職種が閲覧された時に別の職種が閲覧される条件付き確率を計算（すべての職種の組み合わせにおいて）ロジック情報エントロピー最小化こだわり条件による求人候補の絞り込み共起によるCRFの作成求人候補を絞り込むために、「高時給」、「WワークOK」などのこだわり条件を付与していく質問するこだわりコードは求人候補を半分ズル減らしていくようなコード

Slide 16

Slide 16 text

ロジックある職種が好きか尋ねた時に、得られる情報量エントロピーが最小になるような職種をユーザーに尋ねるこれを複数回繰り返すことで、ユーザーが興味のある職種を絞り込んでいく情報エントロピー最小化ユーザーログから、ある職種が閲覧された時に別の職種が閲覧される条件付き確率を計算（すべての職種の組み合わせにおいて）こだわり条件による求人候補の絞り込み共起によるCRFの作成求人候補を絞り込むために、「高時給」、「WワークOK」などのこだわり条件を付与していく質問するこだわりコードは求人候補を半分ズル減らしていくようなコード

Slide 17

Slide 17 text

- 二つの集合に含まれている要素のうち共通要素が占める割合例) カフェのバイトを検索したユーザーが10人いて、コンビニのバイトを検索したユーザーが10人で、カフェとコンビニの　バイトを検索したユーザーが5人いた場合: 共起 https://mieruca-ai.com/ai/jaccard_dice_simpson/

Slide 18

Slide 18 text

共起によるCRFの作成・先ほどの共起をベイズの定理を用いて条件付き確率に直す・全中職種xiの条件付き確率に対してユーザーがその求人を好む確率を共起を用いて計算する (x_i = 1: 職種x_iが好き, x_i = 0: 職種x_iが好きじゃない) 例) x_1 (カフェ) が好き ∩ x_2 (コンビニ) が好きじゃない ∩ x_3 (レストラン)が好き、な時に x_i (居酒屋)が好きな確率

Slide 19

Slide 19 text

ある職種が好きか尋ねた時に、得られる情報量エントロピーが最小になるような職種をユーザーに尋ねるこれを複数回繰り返すことで、ユーザーが興味のある職種を絞り込んでいくロジック情報エントロピー最小化ユーザーログから、ある職種が閲覧された時に別の職種が閲覧される条件付き確率を計算（すべての職種の組み合わせにおいて）こだわり条件による求人候補の絞り込み共起によるCRFの作成求人候補を絞り込むために、「高時給」、「WワークOK」などのこだわり条件を付与していく質問するこだわりコードは求人候補を半分ズル減らしていくようなコード

Slide 20

Slide 20 text

- 聞いて非常に驚く情報・・・情報量が大きい - 聞いても驚かない情報・・・情報量が小さい情報量 http://web.tuat.ac.jp/~s-hotta/info/slide5.pdf

Slide 21

Slide 21 text

- 情報量の平均(期待値) 平均情報量 (= 情報エントロピー) http://web.tuat.ac.jp/~s-hotta/info/slide5.pdf 事象系Aのすべての事象の生起確率が等しい(一様分布)のとき、情報エントロピーが最大となる = 何が起こるか全くわからない状態

Slide 22

Slide 22 text

情報エントロピーの一例 http://web.tuat.ac.jp/~s-hotta/info/slide5.pdf

Slide 23

Slide 23 text

情報エントロピーを最小化するとは？・エントロピー最小 = ユーザーの好みが完全に特定された状態例) カフェが好き(x_{カフェ} = 1)で、それ以外の職種が好きじゃない時に、エントロピーが最小になる → 人によって、カフェもコンビニも好きということはあり得るが、エントロピーを最小化していくことでユーザーの好みを絞り込むことができる

Slide 24

Slide 24 text

仮にその職種をユーザーが好むことが判明した場合に、情報エントロピーが最小になるような職種x_jが気になるかどうか質問する情報エントロピーの最小化

Slide 25

Slide 25 text

Slide 26

Slide 26 text

なぜ半分ずつ原稿を減らしているのか？原稿数を限られた質問回数の中で適切な数に減らす必要あり・減らす原稿が多すぎる場合 : 求人原稿候補が少なくなり過ぎてしまう・減らす原稿が少なすぎる場合 : 求人原稿候補が多くなり過ぎてしまう →　半分ずつ減らすような質問をしよう

Slide 27

Slide 27 text

こだわりコードによる求人原稿候補の絞り込み初期条件情報エントロピー最小化による職種候補の絞り込み UI ロジックとUXの最適なバランスを考えてこのようなUIに決定 (質問数が多すぎるとユーザーが途中で離脱してしまう、など )

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

インフラについて

Slide 33

Slide 33 text

Kubernetes コンテナ化アプリケーションの自動デプロイ、スケーリング、アプリ・コンテナの運用等を迅速かつ効率よくできるようにしたオープンソースのプラットフォーム https://qiita.com/MahoTakara/items/85096f8b2632c802ab22

Slide 34

Slide 34 text

Google Kubernetes Engine (GKE) Kubernetesの技術を組み込んだ、コンテナ化されたアプリケーションをデプロイするためのマネージド環境・簡単かつ頻繁に公開・高い信頼性と自己回復力・リソースに合わせたデプロイ・無理なくスケールして需要に対応 https://cloud.google.com/kubernetes-engine/

Slide 35

Slide 35 text

Stackdriver Logging Monitoring CLB Redis iPhone iPhone iPhone ・・・ GKE Monitoring, Logging & Alerting Request Request 情報エントロピー取得求人原稿リスト取得

Slide 36

Slide 36 text

Stackdriver Logging Monitoring CLB Redis iPhone iPhone iPhone ・・・ GKE Monitoring, Logging & Alerting Request Request kube-legoによるHTTPS通信の実現 (https://github.com/jetstack/k ube-lego) 情報エントロピー取得求人原稿リスト取得

Slide 37

Slide 37 text

ロジックコンバージョン率リフト A 1.00 - B (今回のロジック) 1.06 106% 効果ロジックAのコンバージョン率を 1.0とした場合

Slide 38

Slide 38 text

ここまでさらっとお話ししてきましたが

Slide 39

Slide 39 text

機械学習組織が価値を発揮するためには

Slide 40

Slide 40 text

【前提】独立した組織構造 MLチームエンジニアチーム PO プロダクト

Slide 41

Slide 41 text

【前提】独立した組織構造 MLチームエンジニアチーム PO プロダクト施策提案

Slide 42

Slide 42 text

【前提】独立した組織構造 MLチームエンジニアチーム PO プロダクト施策提案壁

Slide 43

Slide 43 text

- 独立した組織構造になっていて声が届きにくい - How寄りの施策はなかなかできない - How寄りの施策を提案しがち - エンジニアチームはアジャイル開発体制を敷いており - ROIや工数管理の観点でなかなか着手優先度が上がらない MLエンジニアが施策を提案するときの壁

Slide 44

Slide 44 text

- 独立した組織構造になっていて声が届きにくい - How寄りの施策はなかなかできない - How寄りの施策を提案しがち - エンジニアチームはアジャイル開発体制を敷いており - ROIや工数管理の観点でなかなか着手優先度が上がらない MLエンジニアが施策を提案するときの壁どうやってこの壁を乗り越えたか？

Slide 45

Slide 45 text

Problem-Solution Fit - リーンキャンバスの活用 https://kigyotv.jp/news/lean-canvas/

Slide 46

Slide 46 text

Problem-Solution Fit - リーンキャンバスの活用 https://kigyotv.jp/news/lean-canvas/

Slide 47

Slide 47 text

Problem-Solution Fit - リーンキャンバスの活用 https://kigyotv.jp/news/lean-canvas/ POやエンジニアに対して、説明性、納得度の高い提案ができるようになった

Slide 48

Slide 48 text

MLチームエンジニアチーム PO プロダクト施策提案壁

Slide 49

Slide 49 text

オーソドックスな仕事の進め方課題の特定 (何に困っているのか？) ユーザーセグメントの設定 (誰が困っているのか？) どうやって解決するのか？ Productへの落とし込み (UI) リーンキャンバスの活用効果検証

Slide 50

Slide 50 text

MLチームの案件着手方法もっとも価値を提供できそうな機械学習手法の選定統計機械学習アセットの活用課題の特定 (何に困っているのか？) ユーザーセグメントの設定 (誰が困っているのか？) どうやって解決するのか？ Productへの落とし込み (UI) リーンキャンバスの活用効果検証

Slide 51

Slide 51 text

- Amazon Alexa、Google Homeの登場 - 情報検索のトップカンファレンスであるSIGIRや機械学習のトップカンファレンスであるKDDでも会話型システムのWorkshopやSessionが組まれている - Workshop @KDD 2018 (https://cai.kdd2018.a.intuit.com/) - Workshop & Session@SIGIR 2018(http://sigir.org/sigir2018/program/program-at-a-glance/) [余談] 会話型システムの流行

Slide 52

Slide 52 text

【方針】効果検証速度を重視 Proof of Concept (PoC) - 効果観点の検証 - - 効果検証ができること効果観点 - Fail Safeであること（安全に切り戻せるか） - 社内で定められたセキュリティーは担保されているかシステム観点

Slide 53

Slide 53 text

リーンキャンバスの活用 PoC フェーズ効果出た！

Slide 54

Slide 54 text

リーンキャンバスの活用 PoC フェーズ効果出た！効果が出た先で別の壁にぶち当たる壁

Slide 55

Slide 55 text

- 障害発生時のレポートフローの整備 - 障害発生時の切り戻し方 - 誰が対応するか - 休日対応するかどうか PoCフェーズと実運用フェーズの間の壁 - 効果検証ができること効果観点 - Fail Safeであること（安全に切り戻せるか） - 社内で定められたセキュリティーは担保されているか - Alerting, Monitoringはきちんと行われているかシステム観点運用観点

Slide 56

Slide 56 text

Slide 57

Slide 57 text

座組みの整理 - エンジニアに染み出してもらい、フィードバックをもらいやすいチーム作った MLチームエンジニアチーム PO プロダクトエンジニア MLエンジニア共同チーム

Slide 58

Slide 58 text

連携試験を実施してもらう API わたしエンジニア

Slide 59

Slide 59 text

連携試験を実施してもらう API わたしエンジニア問題発生

Slide 60

Slide 60 text

問題発生 - 連携試験ができなかった - 「エラー起きたけど、これってなんでエラーなんですか？」

Slide 61

Slide 61 text

問題発生 - 連携試験ができなかった - 「エラー起きたけど、これってなんでエラーなんですか？」エンジニアの思うFail Safeと、MLエンジニアの思うFail Safeが違う

Slide 62

Slide 62 text

Fail Safeの認識の違い - エンジニア - エラー発生時のこけ方が色々 (4xx, 5xx, エラーオブジェクトの活用) - MLエンジニア - こけ方が一つしかない

Slide 63

Slide 63 text

「Fail Safeであれば良い」が呪いに - 障害発生時のレポートフローの整備 - 障害発生時の切り戻し方 - 誰が対応するか - 休日対応するかどうか - 効果検証ができること効果観点 - Fail Safeであること（安全に切り戻せるか） - 社内で定められたセキュリティーは担保されているか - Alerting, Monitoringはきちんと行われているかシステム観点運用観点

Slide 64

Slide 64 text

こけかたを学ぶ必要が出てくる - 知識獲得 - エンジニアからテストについて学ぶ - 勧められた本をきちんと読む - 知識活用 - Decision Tableを用いてテスト作成 - それをエンジニアにフィードバックをもらいながら修正 - 重要なこと - ある程度リテラシーを揃えた上で会話を行うことで議論がスムーズになるため、テストに関してソフトウェア工学一般の知識を身につけること - エンジニアとのより密なコミュニケーション

Slide 65

Slide 65 text

より密なチームに MLチームエンジニアチーム PO プロダクトエンジニア MLエンジニア共同チーム

Slide 66

Slide 66 text

リリースできた

Slide 67

Slide 67 text

MLエンジニアが価値を発揮するためには - スキルの獲得 - 統計機械学習の知識 - テストに関するソフトウェア工学一般の知識 - 説明責任と相手を納得させる能力 - リーンキャンバスの活用 - Problem-Solution Fitをしっかり - How寄りの施策は他者が動いてくれない - 組織構造の見直し - 機械学習組織ははみ出しがち - エンジニアと密なコミュニケーションでフィードバックをもらえる座組みに

Slide 68

Slide 68 text

- ML APIをGKEに構築 - 対話型検索による新たな UXの提供 - CRFと情報エントロピーを活用したユーザーの嗜好の推定 - MLエンジニアが価値を発揮するには - スキルの獲得 - テストに関するソフトウェア工学一般の知識 - Problem-Solution Fitをしっかり - 組織構造の見直し - エンジニアと密なコミュニケーションでフィードバックをもらえる座組みにまとめ

Slide 69

Slide 69 text

- Embeddingとか活用してみたい - 「MLエンジニアが最大限価値を発揮するためには」、「会社としてMLエンジニアを最大限活かすためには」、これらのテーマについていろんな方の情報を聞いて整理したい Future Works

Slide 70

Slide 70 text

- Embeddingとか活用してみたい - 「MLエンジニアが最大限価値を発揮するためには」、「会社としてMLエンジニアを最大限活かすためには」、これらのテーマについていろんな方の情報を聞いて整理したい Future Works この後の時間でぜひ意見交換、議論させてください！！

Slide 71

Slide 71 text

We Are Hiring !! リクルートジョブズ　コアテクノロジーグループでは、 - データエンジニア - MLエンジニアを募集しています！ご興味のある方はリクルートジョブズのサイトへいらしてください。