はてなにおける機械学習の取り組み

はてなにおける機械学習の取り組み

1. 1. はてなにおける 機械学習の取り組み id:syou6162 MACHINE LEARNING Meetup KANSAI#1 1
2. 2. 自己紹介 •  id:syou6162(本名: 吉田康久) •  前職: NTTコミュニケーション科学基礎研究所 – 自然言語処理や機械学習の研究に従事(4年) •  2年前にはてなに転職 – はてなブックマーク – サーバー管理/監視システムMackerel •  Web開発:機械学習関連の開発 = 8:2 2
3. 3. 自己紹介 •  id:syou6162(本名: 吉田康久) •  前職: NTTコミュニケーション科学基礎研究所 – 自然言語処理や機械学習の研究に従事(4年) •  2年前にはてなに転職 – はてなブックマーク – サーバー管理/監視システムMackerel •  Web開発:機械学習関連の開発 = 8:2 3 関西にはアカデミアの研究所はたくさんあるけど、 インダストリーはそうでもない。meetupや論文読 み会等を通じて機運を高めていきたいですね! Pycon mini Osakaでも話します!
4. 4. 自己紹介 •  id:syou6162(本名: 吉田康久) •  前職: NTTコミュニケーション科学基礎研究所 – 自然言語処理や機械学習の研究に従事(4年) •  2年前にはてなに転職 – はてなブックマーク – サーバー管理/監視システムMackerel •  Web開発:機械学習関連の開発 = 8:2 4 R&D部門がない組織で機械学習を 使ったサービス開発の参考になると幸いです
5. 5. 発表のゴール •  はてなの事例を通じて – 機械学習を使ったサービス開発の 難しさ – その難しさを乗り越えていくための 技術的/組織的な取り組み方 •  が見えてくる 5
6. 6. はてなって機械学習使ってるの? 6
7. 7. はてなでの機械学習の利用事例 •  はてなブックマークのカテゴリ判定 •  はてなブックマークのスパム判定 •  はてなブックマークのトピックページ •  BrandSafe はてな •  エリアガイド •  Mackerelの異常検知 7 表には出てこないものも 多いけど、色々なところで 機械学習使っています!
8. 8. はてなブックマークのカテゴリ判定 8
9. 9. エリアガイド 9 hTp://area.b.hatena.ne.jp/
10. 10. Mackerelの異常検知 •  一定期間を学習データとし、確率密度の低い 点を異常として検知 •  教師なし学習の問題設定 10 デスクで作業中 ランニングしている時間 異常と判定されるケース1 => ルールでもできそう? 参考: hTps://speakerdeck.com/sugiyama88/mackerel-meetup-number-11 hTp://www.yasuhisay.info/entry/2018/02/16/001000 活動量 心拍数 異常と判定されるケース2 => 今の自分
11. 11. Mackerelの異常検知 •  一定期間を学習データとし、確率密度の低い 点を異常として検知 •  教師なし学習の問題設定 11 休日や夜間等比較的 負荷の低いケース 平日を中心とした比較的 負荷の高いケース 異常と判定されるケース1 参考: hTps://speakerdeck.com/sugiyama88/mackerel-meetup-number-11 hTp://www.yasuhisay.info/entry/2018/02/16/001000 異常と判定されるケース2 cpu memory
12. 12. 発表のゴール •  機械学習を使ったサービス開発の 難しさ •  その難しさを乗り越えていくための技術 的な取り組み – 古典的な問題設定 – R&D要素の強い問題設定 •  組織的な取り組み方 12
13. 13. 機械学習アプリケーションの難しさ •  挙動の把握が難しい •  属人性が高くなりやすい •  再現性が低くなりやすい •  継続的な開発がしにくい 13
14. 14. 挙動の把握が困難 •  機械学習を利用しないアプリケーション – コードを見れば挙動の把握は大体できる •  機械学習を利用するアプリケーション – コードのみからは挙動の把握ができない – コード×データがあれば挙動の推測は不可能では ないが、知識と経験が必須 – Deep Learningはさらに把握が難しい – 誤判定でユーザーに説明が必要な場面も 14
15. 15. 属人性 / 再現性 •  属人性が高い –  機械学習タスクは実験を通じた試行錯誤が必要 –  普段のサービス開発と異なり、レビューが難しい •  問題設定、実験方法、本番投入などで段階的にレビューが 必要 •  再現性が低い –  コードだけでなくモデルやデータの管理が不十分 –  管理ノウハウが発展途上 •  何をどうやって管理すればよいのか –  実験を行なった人でも再現できないことも… 15
16. 16. 継続的開発 •  機械学習システムも継続的な開発が必要 – Webアプリケーション開発と一緒 •  継続的開発のためには有効性を示す – モデル改善の有効性をきちんと計測できるように •  実験上はもちろん、本番環境でも – APIのバージョニング •  複数のバージョンのモデルを同時に動かせるように 16
17. 17. 発表のゴール •  機械学習を使ったサービス開発の 難しさ •  その難しさを乗り越えていくための技術 的な取り組み – 古典的な問題設定 – R&D要素の強い問題設定 •  組織的な取り組み方 17
18. 18. BrandSafeはてなリニューアル •  BrandSafeはてなとは? – URL単位でWebページを解析、アダルトサイトや 2chまとめサイトか判定する仕組み – 自社広告を出したくないサイトへの出稿を防ぎ、 ブランドイメージを安全に保つ •  Pythonでリニューアル – 元々Perlで書かれていた – はてなブックマークとの密結合を解消 – 機械学習部分も見直し 18 技術的詳細: hTps://www.slideshare.net/oarat/brand-42816575
19. 19. BrandSafeはてなの問題設定と目的 •  問題設定 – 教師あり機械学習 – 対象はテキストデータ •  目的 – 属人性を低く、再現性を高くする •  何をどこをどのように管理するのか明確に – 継続的な開発ができるように •  きちんとコード/モデル/データのバージョン管理をする •  性能のトラッキング 19
20. 20. 教師あり機械学習の開発フロー 元データ 学習データ 特徴ベクトル モデル テストデータ 特徴ベクトル 判定結果 アノテーション 前処理 特徴量抽出 機械学習アルゴリズム 20 学習時 テスト時
21. 21. 前処理、特徴量抽出、アルゴリズム、 モデル(リニューアル前) •  基本的にコードでバージョン管理できる部分 •  基本的にはPerlのコードをGitで管理 •  一部のモデルパラメータはDBで保存 – バージョン管理はされていないので、巻き戻しで きない 21
22. 22. 前処理、特徴量抽出、アルゴリズム、 モデル(リニューアル後) •  scikit-learnを利用、pythonのエコシステムに乗る •  モデルファイルもバージョン管理 •  挙動が把握しやすい/解釈性の比較的高い線形 モデル(SVM、ロジステック回帰)を使うことが多い •  LSTMやCNNも試したが、複雑性の割に性能がほ ぼ変わらず現段階では不採用 –  教師データ数もそれほど多くないことも関係している かも 22
23. 23. 学習データ管理（リニューアル前） •  決まった管理方法はなかった – 基本はGoogle Driveに置く – 個人PC上あり、危うく消えるところだったものも… •  データはURLとラベルを保存、本文はDBから 取得 – 本文に変更があれば、再現性は担保できない… 23
24. 24. 学習データの管理（リニューアル後） •  置き場所を決める – Google Driveはそのまま – 現状はそこまでサイズが大きくない – DBでもよいが、リニューアル前はDBアクセスがボ トルネックになり、実験の試行錯誤がやりづらい •  データの固定 – データに本文、前処理の結果などを含める – バージョン毎に管理 •  データを変えたら、一括してバージョンを変更 24
25. 25. データ収集方法とアノテーション基準(1) •  機械学習においてデータは最重要 –  「データを増やす」はモデル改善の主要なアプ ローチ – データが悪ければよいモデルでもうまくいかない •  集めた元データとアノテーション結果、だけで はなく「データ収集方法」と「アノテーション基 準」も記録 25
26. 26. データ収集方法とアノテーション基準(2) •  データ収集方法 – 収集方法でデータの性質も異なってくる •  例1: はてなブックマークの特定タグが付いた記事 •  例2: 特定の単語でGoogle検索して出てきた記事 – 気を付けないとバイアスがかかり性能が悪化 •  テスト時のデータと性質が違うデータ – なぜそのアプローチも取ったか分かるとよい – 特徴量へのヒントにもなる 26
27. 27. データ収集方法とアノテーション基準(3) •  アノテーション基準 –  基準が揺れると作ったデータやモデルは無駄になる –  例: アダルト判定の基準 •  サイドバーの内容は考慮するのか •  アダルト広告は考慮するのか –  例: スパム判定 •  過去記事は考慮するのか •  ドメイン知識を持っていない場合は特に綿密に –  例: 営業担当とアノテーション基準について議論 27
28. 28. データ収集方法とアノテーション基準(4) •  文書化 – 試行錯誤していると後回しになりがち – まとめたものをGoogle Docsやリポジトリにcommit – 最近ならJupyter Notebookでもよいですね •  今回は使わなかった特徴量集合の試行錯誤 の様子が分かると、改善時の手間が減らせる 28 能動学習を使った効率的なアノテーション方法も やっています。興味ある方は懇親会で!
29. 29. 発表のゴール •  機械学習を使ったサービス開発の 難しさ •  その難しさを乗り越えていくための技術 的な取り組み – 古典的な問題設定 – R&D要素の強い問題設定 •  組織的な取り組み方 29
30. 30. 30 hTps://mackerel.io/ja/ Mackerel: SaaS型の サーバー監視/管理 サービス サービス(例: はてなブログ)/ ロール(例: DB、Proxy)で 分かりやすくグルーピング 静的な閾値による アラートの発砲、Slack などへの通知をサポート Agentがサーバーの メトリックを収集、 グラフで可視化
31. 31. 監視における課題と 機械学習の活用 •  監視における課題 – ミドルウェアなどの知識が必要 – 監視ルールのメンテナンスは手間がかかる •  機械学習を用いた異常検知の利点 – データから学習、自動的に監視ルールを決めて アラートできる – 知識がなくても、何かが異常であることが分かる 31
32. 32. 再掲: Mackerelの異常検知 •  一定期間を学習データとし、確率密度の低い 点を異常として検知 •  教師なし学習の問題設定 32 休日や夜間等比較的 負荷の低いケース 平日を中心とした比較的 負荷の高いケース 異常と判定されるケース 参考: hTps://speakerdeck.com/sugiyama88/mackerel-meetup-number-11 hTp://www.yasuhisay.info/entry/2018/02/16/001000 どのように試行錯誤したか紹介します
33. 33. タスク着手時の障壁 •  社内で機械学習を使った異常検知の知見を 持っている人がゼロ •  教科書は読んだが、実データに対してどれだ けうまくいくか分からない – 検知漏れがないか/誤検知がないか – うまく行かない例も説明可能/人間が納得できそ うなものか 33
34. 34. 調査フェイズ •  課題の性質を明らかにすることが目的 •  社内の過去の障害事例を分析 – 絶対数の多い障害パターンは? – 障害の要因は? – どういった特徴量であれば捉えられる? •  生の事例と向き合う 34
35. 35. プロトタイプフェイズ •  典型事例だった障害に対して様々な方法を ひたすら試す – ライブラリの使用/自前、手段は問わない – 既存のツールでは異常を捉えられるのか試す •  手法の得手不得意や計算量の肌感覚を掴む •  進め方についてサブ担当が適宜レビュー •  手元だけでは誤検知の多さが分かりにくい – 実際のデータを定常的に流してみる 35 http://www.yasuhisay.info/entry/2017/11/06/163000
36. 36. アルゴリズム決定フェイズ •  学習時/予測時の計算機コスト •  挙動が人間に説明可能か(サポート対応必須) •  機械学習に詳しくないチーム内のエンジニアが レビュー可能か/引き継ぎ可能か –  直感的に理解可能か –  チューニングを頑張らないと精度が出ない、だとダメ •  手元で過去のモデルを使って再現が容易に行な えるか 36
37. 37. 実装フェイズ •  アルゴリズムがfixされたらチーム内外で輪講 •  機械学習に詳しくないエンジニアにもレビュー やサブタスクを担当してもらい知見を共有 •  社内の実際のデータも使ってテストを動かす 37
38. 38. 発表のゴール •  機械学習を使ったサービス開発の 難しさ •  その難しさを乗り越えていくための技術 的な取り組み – 古典的な問題設定 – R&D要素の強い問題設定 •  組織的な取り組み方 38
39. 39. 組織的な取り組み(1) •  各サービスに機械学習詳しい人物がいても1 人か2人。いないときもある – 専門的なレビューを受けるのはなかなか難しい… •  サービス横断の機械学習会を設立、知見を 集約 •  各サービスで機械学習案件が必要なときは 機械学習会が専門的観点でレビュー •  半月に一度、定例会で近況をまとめる 39 hTp://developer.hatenastaff.com/entry/2018/01/11/081000
40. 40. 組織的な取り組み(2) •  はてなの教科書に機械学習講義を追加、属 人性が下がるように •  実データを使った練習問題も用意 •  Perl/Scala/Pythonによるお手本実装、サブ会 メンバーによる回答レビュー 40 hTp://developer.hatenastaff.com/entry/hatena-textbook-machine-learning-01-2016
41. 41. 組織的な取り組み(3) •  そもそもR&Dに近いような案件に取り組める 土壌作り •  論文読み会/輪講会 – 新規性や技術的な正確性よりも着眼点の面白さ や自社サービスにどう生かせそうかを議論 •  機械学習ハッカソン 41 hTp://developer.hatenastaff.com/entry/2017/04/28/130000 hTp://developer.hatenastaff.com/entry/2017/09/27/170000 hTp://developer.hatenastaff.com/entry/2017/09/27/170000
42. 42. 発表のゴール •  はてなの事例を通じて – 機械学習を使ったサービス開発の 難しさ – その難しさを乗り越えていくための 技術的/組織的な取り組み方 •  が見えてくる 42
43. 43. 43
44. 44. 発表時には使わなかった おまけスライド 44
45. 45. 高度な機械学習を使ったサービス: トピックページ 45 •  似た話題をトピックとしてクラスタリング •  複数のタイトルからトピックタイトルを生成 •  重要文抽出や文圧縮(構文解析や要約技 術などを使用) hTp://bookmark.hatenastaff.com/entry/2015/02/05/190331
46. 46. アダルト まとめサイト Ruby gem Golang GAE 分離平面 iPhone Swii エンジニア 転職 サーバー監視 Mackerel iPhone アプリ おすすめ データ収集方法とアノテーション基準(5) 能動学習による効率的なアノテーション 46 機械学習 Python アフィリエイトサイト
47. 47. アダルト まとめサイト Ruby gem Golang GAE 分離平面 iPhone Swii エンジニア 転職 サーバー監視 Mackerel iPhone アプリ おすすめ データ収集方法とアノテーション基準(5) 能動学習による効率的なアノテーション 47 機械学習 Python アフィリエイトサイト この辺ばかりアノテーションしていても -  精度は上がらない -  精神は病むので、つらい -  しかし、ランダムに選ぶとこの辺がたくさん…
48. 48. アダルト まとめサイト Ruby gem Golang GAE 分離平面 iPhone Swii エンジニア 転職 サーバー監視 Mackerel iPhone アプリ おすすめ データ収集方法とアノテーション基準(5) 能動学習による効率的なアノテーション 48 機械学習 Python アフィリエイトサイト 分離平面に近い(=分類器があまり自信がない) 事例から優先的にアノテーション
49. 49. •  同じ400件をアノテーションするならば、より精度 が高い分類器を作れる400件のほうがよい 49 hTp://www.yasuhisay.info/ entry/2017/05/18/080000 hTps://github.com/syou6162/go- ackve-learning データ収集方法とアノテーション基準(5) 能動学習による効率的なアノテーション 注意: 実験結果は趣味プロジェクト の結果であり、社内データを 使ったものではありません。
50. 50. 特徴量抽出での工夫: 共通で使える特徴量抽出器を用意 50 タスクA タスクB タスクC 特徴量抽出A 特徴量抽出B 特徴量抽出C 学習データA 学習データB 学習データC 分類器A 分類器B 分類器C •  各タスクで学習データ作成/特徴量抽出を頑張る必要がある •  少量の教師データではカバーできなかった語は誤判定の要 因
51. 51. 共通で使える特徴量抽出器を用意 51 タスクA タスクB タスクC 特徴量抽出A 特徴量抽出B 特徴量抽出C 学習データA 学習データB 学習データC 分類器A 分類器B 分類器C 共通特徴量抽出
52. 52. 特徴量抽出での工夫: 様々なタスクで使えるリソースを整備 52 タスクA タスクB タスクC 特徴量抽出A 特徴量抽出B 特徴量抽出C 学習データA 学習データB 学習データC 分類器A 分類器B 分類器C 共通特徴量抽出 タスクに依存しないデータセット(wikipediaなど)から 埋め込みベクトルやクラスタリング特徴量を作成。 誤判定が減って、性能も上がる
53. 53. Mackerelとは? 53 •  SaaS型のサーバー管理/監視ツール •  サーバーからメトリックを収集、グラフで可視化 やルールに基づいた監視や通知などをサポート
54. 54. 54 hTp://hatenacorp.jp/solukons/brandsafe_hatena
55. 55. 混合ガウス分布を用いた異常検知 •  一定期間を学習データとし、確率密度の低い 点を異常として検知 •  閾値監視では困難だったケースも検知できる 55 休日や夜間等比較的 負荷の低いケース 平日を中心とした比較的 負荷の高いケース 異常と判定されるケース
56. 56. 混合ガウス分布を用いた異常検知 •  一定期間を学習データとし、確率密度の低い 点を異常として検知 •  閾値監視では困難だったケースも検知できる 56 休日や夜間等比較的 負荷の低いケース 平日を中心とした比較的 負荷の高いケース 異常と判定されるケース •  比較的、R&D要素の強い機能開発 •  どのように試行錯誤したか紹介します
57. 57. 教師あり機械学習の開発フロー 元データ 学習データ 特徴ベクトル モデル テストデータ 特徴ベクトル 判定結果 アノテーション 前処理 特徴量抽出 機械学習アルゴリズム 57 学習時 テスト時
58. 58. 技術的取り組み 組織的取り組み 古典的な問題設 定 (例: テキスト分類) •  コード/データのバージョン管 理による再現性の担保 •  データ作成/アノテーション基 準の統一、ツールの整備 •  異なるプロジェクトでも使える データの整備 •  はてな機械学習の教科書 の整備 •  チームをまたいだレビュー 体制の整備 R&D要素の強い 新規の問題設定 (例: 異常検知) •  捨てることを前提に素早くい くつかプロトタイプ作成 •  過去のデータを手元で簡単 に検証できるように •  シンプルで頑健に動くモデル を優先して採用 •  論文読み会/輪講会 •  アイディアを試す場として ハッカソンを開催 •  サブ担当を付けて問題設 定や実験方針から相談 発表のゴール 58 •  挙動の把握が難しい/属人性が高くなりやすい •  再現性が低くなりやすい/継続的な開発がしにくい 難しさ 難しさを解決するための取り組み