Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

今日から始める機械学習〜はてなの事例〜

3,899 views

Published on

人工知能ブームに伴ない機械学習関係のニュースを聞かない日はないほど機械学習は普及しつつありますが、自分でやってみる/自社で導入するにはまだハードルが高いと感じる方も多いかと思います。このセッションでは、いわゆるデータサイエンティストではなくアプリケーションエンジニアが機械学習を使った機能開発を行なうメリットやその楽しさについて、はてなでの事例を交えながらお話ししたいと思います。

https://event.shoeisha.jp/devsumi/20180928/session/1802/

Published in: Technology
  • Be the first to comment

今日から始める機械学習〜はてなの事例〜

  1. 1. 今日から始める機械学習 〜はてなの事例〜 株式会社はてな 吉田康久(id:syou6162) 1
  2. 2. 自己紹介 •  id:syou6162(本名: 吉田康久) •  2年前にはてなにアプリケーションエンジニア として転職 – はてなブックマーク – サーバー管理/監視システムMackerel •  Web開発:機械学習関連の開発 = 8:2 2 課金回りをやったり、権限回りの拡張を やったり、Mackerel用のプラグインを書いたり。
  3. 3. 発表のゴール •  N(=3)度目の人工知能ブーム •  しかし、自分でやってみる/自社で導入するに はまだハードルが高いと感じる方も多い? •  アプリケーションエンジニアが機械学習を使っ た機能開発を行なうメリット/楽しさについて聞 くことで「来週から自分も機械学習をやってみ よう!」と思ってもらえること 3
  4. 4. アジェンダ •  機械学習とは •  アプリケーションエンジニアが機械学習をや る楽しさ/メリット – 素朴なタスク編 – サービスの事例編 •  機械学習をやりたい! 困ったときには…? 4
  5. 5. アジェンダ •  機械学習とは •  アプリケーションエンジニアが機械学習をや る楽しさ/メリット – 素朴なタスク編 – サービスの事例編 •  機械学習をやりたい! 困ったときには…? 5
  6. 6. 機械学習とは: 3つのタイプ •  人工知能における研究課題の一つで、人間が自然に 行っている学習能力と同様の機能をコンピュータで実 現しようとする技術・手法のことである by wikipedia •  教師あり学習 –  テキスト分類、物体認識、機械翻訳など •  教師なし学習 –  クラスタリング、異常検知など •  強化学習 –  AlphaGo、自動運転など 6
  7. 7. 機械学習の典型的なプロセス 7 Model Annotate Train Test Evaluate Revise 参考: hIp://shop.oreilly.com/product/0636920020578.do
  8. 8. 機械学習の典型的なプロセス 8 Model Annotate Train Test Evaluate Revise ゴールを明確にする。そもそも 機械学習で解く必要があるか 教師あり学習(分類問題)にす るのか教師なし学習(クラスタ リング)したいのか
  9. 9. 機械学習の典型的なプロセス 9 Model Annotate Train Test Evaluate Revise 学習データにラベルを付与
  10. 10. 機械学習の典型的なプロセス 10 Model Annotate Train Test Evaluate Revise パラメータ(重み)を学習する
  11. 11. 機械学習の典型的なプロセス 11 Model Annotate Train Test Evaluate Revise 評価用データに対して 予測を行なう
  12. 12. 機械学習の典型的なプロセス 12 Model Annotate Train Test Evaluate Revise 予測がどれくらい 正確か性能を評価する
  13. 13. 機械学習の典型的なプロセス 13 Model Annotate Train Test Evaluate Revise 評価結果に基づき、 方針がこのままで よいかを検討
  14. 14. 世間での機械学習のイメージ(?) •  難しい数学が必要… •  最新のアルゴリズムが日々登場しており キャッチアップが困難… •  データサイエンティストがやるもの? •  大量のデータがないと動かない… 14
  15. 15. アジェンダ •  機械学習とは •  アプリケーションエンジニアが機械学習をや る楽しさ/メリット – 素朴なタスク編 – サービスの事例編 •  機械学習をやりたい! 困ったときには…? 15
  16. 16. 大量のデータ && 最新のアルゴリズ ムがないと動かない? •  当然そんなことはない •  はてな社内での小さなデータ && 枯れたアル ゴリズムを使った事例を紹介 – 学習データ数百件程度 – 単純パーセプトロン(1950年代に提案) 16
  17. 17. 17 参考: hIps://event.shoeisha.jp/devsumi/20180928/session/1814/
  18. 18. 18 hIps://mackerel.io/ja/ Mackerel: SaaS型の サーバー監視/管理 サービス サービス(例: はてなブログ)/ ロール(例: DB、Proxy)で 分かりやすくグルーピング 静的な閾値による アラートの発砲、Slack などへの通知をサポート Agentがサーバーの メトリックを収集、 グラフで可視化 ユーザーからのフィードバックを 日々チェック! SNS上でのサービスへの言及、 見ていますか?
  19. 19. 活用例(1) 19
  20. 20. 活用例(2) 20
  21. 21. 鯖曖昧性解消: これまで •  TwiIer Streaming API用のプラグインを使う •  正規表現をひたすら頑張る •  ルールはひたすら疲れる •  Fluentdが不調だとユーザーの反応見逃す 21
  22. 22. ルールの整備漏れ=>飯テロ問題 22
  23. 23. Mackerel sky(いわし雲) 23
  24. 24. syou6162/saba_disambiguator 24 hIps://github.com/syou6162/saba_disambiguator hIps://www.yasuhisay.info/entry/saba_disambiguator
  25. 25. 構成 CloudWatch Event 25
  26. 26. 鯖曖昧性解消の中身 26 MackerelのAPI充実していて便利! Mackerel API 充実 便利 Mackerel API 充実 便利 * 0.0 * 3.0 * - 0.1 * 1.0 スコア: 3.9 > 0 テキストを 単語に分割 単語に対する 重みをlookup
  27. 27. お手軽に始められる! •  学習データ数百件からスタート – “mackerel”でTwiIerを検索、週末にラベル付け •  パラメータの学習は手元のラップトップで – 5分もかからない •  予測(mackerel.ioに関連するtweetか)はAWS Lambda – 無料枠内で収まる – GPUなど高価な計算リソースは必要なし 27
  28. 28. 世間のイメージ vs. お手軽な機械学習 •  難しい数学が必要… – 重みの足し算ができればよい •  最新のアルゴリズムが日々登場しており キャッチアップが困難… – 超古典的なアルゴリズムで使いものになる •  データサイエンティストがやるもの? – アプリケーションエンジニアが週末でさっと •  大量のデータがないと動かない… – 数百件データがあれば始められる 28
  29. 29. サービス事例: BrandSafeはてな •  URL単位でWebページを解析、アダルトサイト や2chまとめサイトか判定する仕組み •  自社広告を出したくないサイトへの出稿を防 ぎ、ブランドイメージを安全に保つ •  鯖曖昧性解消と同じく線形分類器(重みの足 し算)を使用 •  学習データは数千件規模からスタート 29 技術的詳細: hIps://www.slideshare.net/oarat/brand-42816575
  30. 30. BrandSafeはてな 30 参考: hIp://hatenacorp.jp/solueons/brandsafe_hatena
  31. 31. 本当にそれでいいの? •  簡単なアルゴリズムより賢いアルゴリズムの ほうが何だかんだでいいのでは…? 31
  32. 32. データ数と精度の関係(機械翻訳の例) 32 hIp://www.aclweb.org/anthology/D07-1090.pdf データ数が少ないと 賢いアルゴリズムが 精度が高い データ数を増やすと 精度が上がる データ数が増えると 賢いアルゴリズムとの 差はなくなってくる!
  33. 33. 機械学習の典型的なプロセス 33 Model Annotate Train Test Evaluate Revise 機械学習はデータが命! 日々の業務の中でデータが 増えていくような形に 持っていけるとよい
  34. 34. 機械学習の典型的なプロセス 34 Model Annotate Train Test Evaluate Revise 機械学習で精度100%を目 指すのは無謀。 精度がそこまで高くなくても ユースケースをしっかり考え ればいいものができる!
  35. 35. クックパッド社の業務効率化の事例 35 精度は85%(SVM)だが、人手の チェックも入る。もしかして カテゴリの中から選択する方式 通常業務に組み込まれており、 徐々に精度がよくなっていく! 参考: hIps://techlife.cookpad.com/entry/2018/08/08/170000
  36. 36. 機械学習の典型的なプロセス 36 Model Annotate Train Test Evaluate Revise 何かと注目を浴びがち。毎週 のように新しいものが登場する。 CNN/LSTM/AIeneon/GAN? 古典的な機械学習(SVM/ロジ ステック回帰など)で十分な場 合も多い。業務知識を特徴量 に落し込みやすい!
  37. 37. 業務知識の例 •  URL •  タイトル •  ブックマーク数 •  付与されているタグ •  分類されたカテゴリ •  本文抽出された綺麗なテキスト •  はてなキーワード 37 アルゴリズムの工夫は これらを試した後で十分! 普段のドメイン知識がめ ちゃくちゃ生きる!
  38. 38. アプリケーションエンジニアが 機械学習をやる楽しさ •  学習データを追加をしていくと徐々に賢くなる – かわいいペットがどんどん賢くなる。愛着が湧く •  人手を省いて自動化できる – 辛いルール(例: 正規表現)からの脱出 – 安い、早い 38
  39. 39. アプリケーションエンジニアが 機械学習をやるメリット •  データをきちんと見るようになる –  人間は都合のいいところばかりを見がち –  性能を上げるためにはどういうユーザーが多いのかなど データから判断する癖を付けられる •  いい特徴量のありかを知っている –  「特徴量and/orデータ数 >> アルゴリズム」なことが多い –  アルゴリズムはすぐに真似されるが、データは真似できな い。自社の強みになりうる •  問題解決の手段を機械学習に閉じずに考えられる –  精度を無闇に上げなくても、ユースケースやUIを工夫する ことで解決できることも多い 39
  40. 40. アジェンダ •  機械学習とは •  アプリケーションエンジニアが機械学習をや る楽しさ/メリット – 素朴なタスク編 – サービスの事例編 •  機械学習をやりたい! 困ったときには…? 40
  41. 41. お断り •  Publicリリース前の機能のため、リリース時に 詳細が変更されている可能性があります🙏 41
  42. 42. 42 hIps://mackerel.io/ja/ Mackerel: SaaS型の サーバー監視/管理 サービス サービス(例: はてなブログ)/ ロール(例: DB、Proxy)で 分かりやすくグルーピング 静的な閾値による アラートの発砲、Slack などへの通知をサポート Agentがサーバーの メトリックを収集、 グラフで可視化
  43. 43. サーバー監視初心者の場合 •  例: アプリケーションエンジニア •  クラウドを使うようになって、サーバーも自分 で立てるようになった – しかし、サーバー監視はよく分からない •  本質的にはアプリケーションコードの開発に 集中したい 43
  44. 44. サーバー監視玄人の場合 •  インフラ周りの知識が豊富、何を監視すれば いいか経験的に知っている •  見なければいけないサービスも多く、多忙な ことも •  監視ルールを一度設定すれば終わり、では なく定期的にメンテナンスする必要がある 44
  45. 45. 機械学習による監視のサポート •  以下を実現したい – インフラの知識があまりなくても、低コストで監視 ルールが作れる – 自動的に監視ルールが更新されていく •  機械学習による異常検知機能でユーザーを サポートしたい! 45
  46. 46. 作りました🎉
  47. 47. 実例(成功事例) 47 full GCが走り負荷が一時的に上昇。 Latencyが一時的に悪化 cpu/memoryなど個別の ルールは指定していない。 ロールの指定のみ
  48. 48. 異常検知開発のプロセス 48 Model Annotate Train Test Evaluate Revise 障害の時間はごく僅か。 教師あり学習のアプロー は難しいと判断、教師なし 学習で取り組もう
  49. 49. 異常検知開発のプロセス 49 Model Annotate Train Test Evaluate Revise 教師なし学習なのでスキップ
  50. 50. 異常検知開発のプロセス 50 Model Annotate Train Test Evaluate Revise いくつかアルゴリズムがあるが 比較的シンプルなガウス分布を ベースにした方法でまず始めよう
  51. 51. ガウス分布に基づく方法 51 異常と判定 正常と判定 •  起きる確率の高い事象は 正常と見なし、低い事象は 異常と見なす •  サービスには高負荷(平日) や低負荷(休日)などの場合 がある。実際には複数のガ ウス分布を考慮 •  CPU使用率を例に挙げてい ますが、実際には約20個を 総合的に見て判定 CPU使用率 確 率
  52. 52. ガウス分布に基づく方法 52 異常と判定 正常と判定 •  起きる確率の高い事象は 正常と見なし、低い事象は 異常と見なす •  サービスには高負荷(平日) や低負荷(休日)などの場合 がある。実際には複数のガ ウス分布を考慮 •  CPU使用率を例に挙げてい ますが、実際には約20個を 総合的に見て判定 CPU使用率 確 率 特徴量を入れまくればよいわけ ではない(誤検知が多くなる)。 SREのドメイン知識を借りて必要 最小限なものに絞り込む
  53. 53. Mackerelの異常検知 •  一定期間を学習データとし、確率の低い点を 異常として検知 •  複数の負荷傾向を考慮 53 デスクで作業中 ランニングしている時間 異常と判定されるケース1 => ルールでもできそう? 活動量 心拍数 異常と判定されるケース2 => 今の自分 参考: hIps://www.yasuhisay.info/entry/mackerel_meetup_12_anomaly_deteceon
  54. 54. Mackerelの異常検知 •  一定期間を学習データとし、確率の低い点を 異常として検知 •  複数の負荷傾向を考慮 54 休日や夜間等比較的 負荷の低いケース 平日を中心とした比較的 負荷の高いケース 異常と判定されるケース1 異常と判定されるケース2 参考: hIps://www.yasuhisay.info/entry/mackerel_meetup_12_anomaly_deteceon CPU使用率 メモリ使用量
  55. 55. 異常検知開発のプロセス 55 Model Annotate Train Test Evaluate Revise いきなり本番に入れるのは 大変なので、プラグインなど 影響範囲の少ないところから
  56. 56. 異常検知開発のプロセス 56 Model Annotate Train Test Evaluate Revise 数値的な評価だけでなく、実 際に異常と判定した場合には アラートも飛ばしてみる
  57. 57. 異常検知開発のプロセス 57 Model Annotate Train Test Evaluate Revise 振り返り
  58. 58. サービスの制約を生かす •  サーバー1台毎にモデルを作ってもそこそこ 動く •  データが多いほうが性能がよい – しかし、様々なサーバーを一つのモデルに押し込 むのは無理がある •  サービス/ロールという概念を生かす – ロール毎に一つのモデルを学習する 58 何にでも適用できる汎用的なものを目指すのではなく、 サービス固有の情報や制約を生かす。アプリケーショ ンエンジニアのサービスの知識についても生きる!
  59. 59. 分かってきた問題点/解決法 59 •  低頻度なオペレーション時 にアラートが飛ぶ –  サービス影響はない •  最大試行回数を指定できる ように改善 •  全てを機械学習で解かない –  シンプルなモデルとユース ケースに合わせたヒューリス テックで十分なことも多い
  60. 60. 検知できるケース: 外れ値検知 60 仲間から外れている 以降のスライドの図は hIps://qiita.com/kenmatsu4/items/68e48a00aaebf338bedc より生成 時刻 メモリ 使用量
  61. 61. 検知できないケース1: 時系列的な外れ値検知 61 横軸でシャッフルすると 検知できない 時刻
  62. 62. 検知できないケース2: 変化検知 62 値のずれというより観測値の振舞いが 変化。周期が短かくなっている 時刻
  63. 63. 障害のケースを分析 •  「異常」には様々なケースがある •  様々なケースに対応するためにはある程度 難しい方法を使う必要がある。しかし、対応し ようとすると、誤検知も増加してしまう •  社内の障害報告キーワードから障害時のメト リックの動きの仕方を大雑把に分類 •  検知漏れに対する方針を決める 63
  64. 64. 方針: 難しいケースは諦める •  検知漏れは諦めて誤検知を減らす •  狼少年にならないように。SREと相談 •  前提: サービスメトリック監視や外形監 視など他の監視の手段がすでに存在し ている 64
  65. 65. 異常検知における機械学習の面白さ •  全てが機械学習で解決するわけではない – どこまで機械学習で解決して、どこからはルール で吸収するのか – 腕の見せどころ •  様々なユースケースを見る機会に恵まれる – B向け/C向け、自社/受託/、バッチ/オンライン •  特徴量選択の中で業務知識がさらに深まる – Mackerel自体の障害対応のときにも役に立つ 65 ドメイン知識が生かせる && アプリケーションエンジニアだからこそ発揮できる強み!
  66. 66. アジェンダ •  機械学習とは •  アプリケーションエンジニアが機械学習をや る楽しさ/メリット – 素朴なタスク編 – サービスの事例編 •  機械学習をやりたい! 困ったときには…? 66
  67. 67. 機械学習をやりたいけど… やってみたけど… •  遊んでみたいけど、ちょうどいいデータがない •  社内データなので、社外の人に相談できない •  機械学習、やってみたけど世の中的にこれは どれくらいの精度なの? •  作ってみた! しかし、触れるのが自分だけで 属人性が高いのをどうにかしたい 67
  68. 68. 練習をする場所/ 困ったときに聞ける場所 •  Kaggle •  Kaggler-ja Slack •  Machine Learning Meetup KANSAI 68
  69. 69. どんなことができるか試したい: Kaggle 参考: hIps://www.slideshare.net/HaradaKei/devsumi-2018summer 69
  70. 70. hIps://www.kaggle.com/c/jigsaw-toxic-comment-classificaeon-challenge 70
  71. 71. hIps://www.kaggle.com/c/mercari-price-suggeseon-challenge 71
  72. 72. Kaggleをやるメリット •  データがpublicなため他社の人ともディスカッションし やすい –  社内データだと社外の人に相談ができない •  自分が作ったモデルがどれくらいよいものか客観的な 指標で分かる –  機械学習タスクは手を動かしているのは自分だけ…という 状況になりがち •  多様なタスクがあるため、自分がやりたいことと似たタ スクを発見できる可能性が高い –  業務でやる前にあらかじめ「どれくらいの精度が出るの か」「最低どのくらいのデータ量が必要なのか」「どういっ た特徴量が重要なのか」の検討を付けることができる 72
  73. 73. Kaggler-ja Slack •  Kaggleや機械学習に興味がある人が集まっ ているSlack •  過去のコンペでどういった方法で解いていっ たか議論 – 日本語で議論できます! •  過去の議論がまとまっているwikiも有用 – hIps://kaggler-ja-wiki.herokuapp.com/ 73
  74. 74. Machine Learning Meetup KANSAI •  関西のIT企業が主催しているコミュニティイベ ント •  各社でどう機械学習が活用されているか、導 入までのプロセスを共有 •  hIps://mlm-kansai.connpass.com/event/ 100525/ 74
  75. 75. まとめ •  機械学習の典型的なプロセスをはてなの事例と ともに紹介 –  大事なのは特徴量やデータサイズ –  一見かっこいいアルゴリズムは最後のほうで •  データサイエンティストではなくアプリケーション エンジニアだからできることは多い –  ドメイン知識 –  機械学習に閉じない問題解決 •  小さなケースから機械学習始めてみませんか? 75

×