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