リブセンスにおける 機械学習システムの信頼性エンジニアリング

E60aa4f80303f3f386898546ddb3686a?s=47 Livesense Inc.
September 26, 2018

リブセンスにおける 機械学習システムの信頼性エンジニアリング

2018/09/25
Machine Learning Casual Talk #6

E60aa4f80303f3f386898546ddb3686a?s=128

Livesense Inc.

September 26, 2018
Tweet

Transcript

  1. リブセンスにおける 機械学習システムの信頼性エンジニアリング Machine Learning Casual Talk #6 田中 祥太郎

  2. 自己紹介 田中 祥太郎 / @yubessy • 株式会社リブセンス テクノロジカルマーケティング部 データプラットフォームグループ •

    ML基盤のプロダクトオーナー 各種MLシステムの開発・運用 • Python / Julia GCP / GKE / Amazon Redshift / Elasticsearch • 9月から京都オフィス勤務 MLの仕事を手伝ってもらえる学生アルバイト募集中
  3. 話したいこと • リブセンスではMLシステムについてどんな課題を抱えている (いた) か? • SREの考え方をMLシステム開発・運用に適用することはできるか? • 実際のMLシステム開発・運用にどう取り組んでいるか?

  4. リブセンスでのML利用

  5. リブセンスのサービス

  6. なぜMLを使うのか 成功報酬型ビジネスモデル • 求人票の掲載:無料 • 応募者の採用:課金 掲載無料 = 営業努力だけでは収益を上げにくい →

    データ活用によるマーケティング・UX向上に注力 → MLをはじめとする最適化手法により収益性を向上
  7. 例 コンテンツと行動ログによる求人レコメンド マッハバイト・転職会議・転職ナビで導入 • Contents-Based Filtering 求人コンテンツの類似度を利用 • Collaborative Filtering

    ユーザフィードバックを利用 BPMF(Bayesian Probabilistic Matrix Factorization)によるレコメンド http://analytics.livesense.co.jp/entry/2017/12/05/105618
  8. 例 CVR予測に基づく検索ランキング制御 マッハバイトで導入 求人のCVR (応募率・採用率) を予測 予測値に基づいて検索ランキングを制御

  9. 以前のMLシステム開発・運用

  10. 最初の導入と利用の拡大 最初:転職会議のメールマーケティングで簡単なレコメンドを導入 → 大きな効果が得られた → 他のサービスでも利用したい → 社内でのML利用の広がり • レコメンド・検索ランキング制御

    • 多腕バンディットによる導線最適化 • クチコミのタグ分類によるUX向上
  11. MLシステムがアプリケーションと密結合 • 各サービスの環境に合わせて毎回からシステムを構築し直す • 開発:MLチーム ↔ 運用:サービスチーム MLチームによる継続的改善が困難 • 精度が落ちてもMLチームだけでは手を入れられない

    • 新しい技術やリソースを投入したくても環境を容易に変更できない → つくったMLシステムが放置され負債化 開発したものの改善が進まない
  12. 負債化・属人化による問題が頻発 さまざまな問題が実際に発生 • DBのカラムの値が変化 → モデルの精度が低下 → 直すまでに数ヶ月 • 手元Macで検証

    → 本番にデプロイ → OOM (swap領域不足) 対症療法の効果は限定的 • コーディング規約・単体テスト導入 ↔ モデルの精度は保証できない → MLに対する信頼性の低下 = 機会損失の危機 「効果は出るけど負債化しやすい」
  13. MLシステムの信頼性エンジニアリング

  14. 以前の状態 これまでは問題が起きてから対応に追われていた • 問題が起きるたびに割り込みが入ってエンジニアが疲弊 • 問題対応に個々のシステムや環境ごとの知識と経験が必要 • 対応が場当たり的になり、原状回復がやっとになってしまう 開発・リリース 問題発生

    場当たり的対応・原状回復
  15. システムの信頼性についての必要十分条件を定義し、それに従って対応したい • 問題の発生を前提としてシステムを設計する • 問題のトリアージを容易にして過剰な対応を避ける • 必要な場合には要件に立ち返り、設計から見直す 目指したいこと 開発・リリース 問題発生

    トリアージ・設計の見直し 信頼性要件の定義
  16. 必要だったもの:システムの信頼性を体系的に扱う方法 SREの原則にあるサービスレベルの考え方を参考にする Site Reliability Engineering に学ぶ サービスレベル指標 (SLI) の導入 サービスレベル目標

    (SLO) の設定 SLO実現のために手段を適用
  17. MLシステムの信頼性とその指標 (=SLI) にはどんなものがあるか? → 2種類の指標に基づく信頼性が考えられそう MLシステムの信頼性とは? 通常と同じ指標で計測できる信頼性 • オンライン処理 ◦

    Web APIのレイテンシ ◦ リクエストに対するエラー率 • バッチ処理 ◦ ジョブのスループット ◦ ジョブの成功頻度 ML特有の指標が必要な信頼性 • モデルの精度 ◦ 分類モデルの誤り率 ◦ 回帰モデルの誤差 • モデルのメタ指標 ◦ ノイズに対する頑健性 ◦ 再学習時の精度の安定性
  18. 信頼性をどう評価するか?実際にSLIを計測することはできるか? → 可能なところからはじめる・既存の仕組みや過去の記録を活用 MLシステムの信頼性をどう評価するか? システム監視 ポストモーテム オフライン評価 KPIダッシュボード ※SREの原則では主に定量指標を扱うが、ここでは定性指標も含めている

  19. 信頼性の目標とそれを達成する手段は? 信頼性を定義・計測できたら、次はどうするか? → 目標 (=SLO) を設定し、それを達成するための手段を考える 疑問: • MLシステムでも、通常指標には通常と同じ水準の目標を設定すべき? •

    通常指標とML指標それぞれの問題には、別の手段で対応できる?
  20. MLシステムは通常に比べ、不安定で制御しにくい → 通常と同じSLIに対し、同水準のSLOを設定するのは非現実的 • 予測モデルの計算量が大きい → Webリクエストのレイテンシが大きくなる • 学習が確率的に失敗 →

    ジョブ監視を同様にするとアラートが飛びまくる 注意1:通常と同じ水準の信頼性を求めにくい 学習データ アルゴリズム 学習 モデル 入力データ 出力データ 予測(推論)
  21. 注意2:それぞれの信頼性は分割統治しにくい 通常の問題に見えても原因がMLにあったり、その逆もある → 通常指標とML指標で、対応手段や対応者を完全に分離するのは難しい • 少しのデータ増でOOMが発生 ← レコメンドで求人数×求人数の行列を生成 • ある日突然モデルの精度が低下

    ← キャンペーンでデータ傾向が著しく変化 事象 \ 原因 サービスやインフラの問題 MLモデル・アルゴリズムの問題 Web API やジョブのエラー Webエンジニアが対処可能 Webエンジニアだけでは対処困難 MLモデルの精度低下・不安定化 MLエンジニアだけでは対処困難 MLエンジニアが対処可能
  22. MLシステムに対してSREができること 1. MLの性質に応じた指標や目標を設定する ◦ 求められるレベルが通常とMLとで異なることを受け入れる ◦ 関係者間でサービスレベルに対する認識を合わせておく 2. 通常・ML両方の信頼性の観点から問題を捉える ◦

    MLの問題にみえてもサービスやインフラが原因のケースやその逆に注意 ◦ 通常・MLそれぞれのシステムの性質に合わせて適切な手段を選択する 3. 1と2を支える仕組みを整備する ◦ 実験的なシステムでも安全に検証が行える環境をつくる ◦ 問題の原因の切り分けをしやすいようシステムを設計する
  23. リブセンスでの取り組み

  24. MLチームにSREの役割をおく • MLE:MLモデルの発揮する価値を最大化する • SRE:システムの信頼性と開発効率を考慮して設計や運用を担う MLE, SRE が共同でプロジェクトに携わる レコメンドプロジェクト 検索順位プロジェクト

    SRE MLE SRE MLE
  25. • システムごとにどの程度の信頼性を求めるかの共通認識をつくる • 過剰な信頼性を求めることによる開発・運用コスト増を防ぐ • 不安定なシステムがクリティカルな用途で使われるのを防ぐ MLシステムをフェーズに区分 フェーズ 開発・運用の目的 サービスレベル

    SREの役割 コンセプト検証 コンセプトの実現性の検証 SLI / SLO を定めない インフラやデータの整備と提供 技術検証 最適な技術手段の検証 個別に判断 システム設計やトラブル対応の協力 実運用 継続的な価値提供 SLI / SLO を定める 安定性・メンテナンス性の維持
  26. • MLチーム内で運用を担うことで 問題対応を迅速・柔軟に • 複数のシステムを集約して 運用・管理を一元化 • サービスと疎結合にすることで 問題の原因を特定しやすく •

    開発・本番のデータソースを 一元化して結果の再現性を担保 Kubernetes を利用したコンテナベース機械学習基盤の構築 https://analytics.livesense.co.jp/entry/2018/01/18/090000 ML専用の検証・運用基盤を構築
  27. • アルゴリズムの問題と それ以外を切り分けやすく • 精度検証や問題の原因調査を コンポーネント毎に可能に • アルゴリズム実装の再利用で 管理すべきコードを削減 •

    最近では Argo Workflow を ワークフローエンジンに採用 マルチコンテナ構成による機械学習アルゴリズムとアプリケーションの疎結合化 https://analytics.livesense.co.jp/entry/2017/12/08/105045 モデルとアプリケーションを疎結合化
  28. まとめ

  29. 話したかったこと • リブセンスではMLシステムについてどんな課題を抱えている (いた) か? ◦ ML導入の効果は大きかったが、開発後の改善が難しい ◦ 負債化による問題が顕在化し、MLへの信頼性が失われかねない状況 •

    SREの考え方をMLシステム開発・運用に適用することはできるか? ◦ 原則:SLIの導入と計測・評価は部分的にはできそう ◦ 実践:SLOの設定とその実現手段はMLの性質を踏まえて考える • 実際のMLシステム開発・運用にどう取り組んでいるか? ◦ 現実的な範囲で求める信頼性を定義し、それをもとに手段を考える ◦ 信頼性と開発効率を両立できる仕組みを整備