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