Slide 1
Slide 1 text
リブセンスにおける
機械学習システムの信頼性エンジニアリング
Machine Learning Casual Talk #6
田中 祥太郎
Slide 2
Slide 2 text
自己紹介
田中 祥太郎 / @yubessy
● 株式会社リブセンス
テクノロジカルマーケティング部 データプラットフォームグループ
● ML基盤のプロダクトオーナー
各種MLシステムの開発・運用
● Python / Julia
GCP / GKE / Amazon Redshift / Elasticsearch
● 9月から京都オフィス勤務
MLの仕事を手伝ってもらえる学生アルバイト募集中
Slide 3
Slide 3 text
話したいこと
● リブセンスではMLシステムについてどんな課題を抱えている (いた) か？
● SREの考え方をMLシステム開発・運用に適用することはできるか？
● 実際のMLシステム開発・運用にどう取り組んでいるか？
Slide 4
Slide 4 text
リブセンスでのML利用
Slide 5
Slide 5 text
リブセンスのサービス
Slide 6
Slide 6 text
なぜMLを使うのか
成功報酬型ビジネスモデル
● 求人票の掲載：無料
● 応募者の採用：課金
掲載無料
= 営業努力だけでは収益を上げにくい
→ データ活用によるマーケティング・UX向上に注力
→ MLをはじめとする最適化手法により収益性を向上
Slide 7
Slide 7 text
例 コンテンツと行動ログによる求人レコメンド
マッハバイト・転職会議・転職ナビで導入
● Contents-Based Filtering
求人コンテンツの類似度を利用
● Collaborative Filtering
ユーザフィードバックを利用
BPMF(Bayesian Probabilistic Matrix Factorization)によるレコメンド
http://analytics.livesense.co.jp/entry/2017/12/05/105618
Slide 8
Slide 8 text
例 CVR予測に基づく検索ランキング制御
マッハバイトで導入
求人のCVR (応募率・採用率) を予測
予測値に基づいて検索ランキングを制御
Slide 9
Slide 9 text
以前のMLシステム開発・運用
Slide 10
Slide 10 text
最初の導入と利用の拡大
最初：転職会議のメールマーケティングで簡単なレコメンドを導入
→ 大きな効果が得られた
→ 他のサービスでも利用したい
→ 社内でのML利用の広がり
● レコメンド・検索ランキング制御
● 多腕バンディットによる導線最適化
● クチコミのタグ分類によるUX向上
Slide 11
Slide 11 text
MLシステムがアプリケーションと密結合
● 各サービスの環境に合わせて毎回からシステムを構築し直す
● 開発：MLチーム ↔ 運用：サービスチーム
MLチームによる継続的改善が困難
● 精度が落ちてもMLチームだけでは手を入れられない
● 新しい技術やリソースを投入したくても環境を容易に変更できない
→ つくったMLシステムが放置され負債化
開発したものの改善が進まない
Slide 12
Slide 12 text
負債化・属人化による問題が頻発
さまざまな問題が実際に発生
● DBのカラムの値が変化 → モデルの精度が低下 → 直すまでに数ヶ月
● 手元Macで検証 → 本番にデプロイ → OOM (swap領域不足)
対症療法の効果は限定的
● コーディング規約・単体テスト導入 ↔ モデルの精度は保証できない
→ MLに対する信頼性の低下 = 機会損失の危機
「効果は出るけど負債化しやすい」
Slide 13
Slide 13 text
MLシステムの信頼性エンジニアリング
Slide 14
Slide 14 text
以前の状態
これまでは問題が起きてから対応に追われていた
● 問題が起きるたびに割り込みが入ってエンジニアが疲弊
● 問題対応に個々のシステムや環境ごとの知識と経験が必要
● 対応が場当たり的になり、原状回復がやっとになってしまう
開発・リリース 問題発生 場当たり的対応・原状回復
Slide 15
Slide 15 text
システムの信頼性についての必要十分条件を定義し、それに従って対応したい
● 問題の発生を前提としてシステムを設計する
● 問題のトリアージを容易にして過剰な対応を避ける
● 必要な場合には要件に立ち返り、設計から見直す
目指したいこと
開発・リリース 問題発生 トリアージ・設計の見直し
信頼性要件の定義
Slide 16
Slide 16 text
必要だったもの：システムの信頼性を体系的に扱う方法
SREの原則にあるサービスレベルの考え方を参考にする
Site Reliability Engineering に学ぶ
サービスレベル指標 (SLI) の導入
サービスレベル目標 (SLO) の設定
SLO実現のために手段を適用
Slide 17
Slide 17 text
MLシステムの信頼性とその指標 (=SLI) にはどんなものがあるか？
→ ２種類の指標に基づく信頼性が考えられそう
MLシステムの信頼性とは？
通常と同じ指標で計測できる信頼性
● オンライン処理
○ Web APIのレイテンシ
○ リクエストに対するエラー率
● バッチ処理
○ ジョブのスループット
○ ジョブの成功頻度
ML特有の指標が必要な信頼性
● モデルの精度
○ 分類モデルの誤り率
○ 回帰モデルの誤差
● モデルのメタ指標
○ ノイズに対する頑健性
○ 再学習時の精度の安定性
Slide 18
Slide 18 text
信頼性をどう評価するか？実際にSLIを計測することはできるか？
→ 可能なところからはじめる・既存の仕組みや過去の記録を活用
MLシステムの信頼性をどう評価するか？
システム監視 ポストモーテム オフライン評価 KPIダッシュボード
※SREの原則では主に定量指標を扱うが、ここでは定性指標も含めている
Slide 19
Slide 19 text
信頼性の目標とそれを達成する手段は？
信頼性を定義・計測できたら、次はどうするか？
→ 目標 (=SLO) を設定し、それを達成するための手段を考える
疑問：
● MLシステムでも、通常指標には通常と同じ水準の目標を設定すべき？
● 通常指標とML指標それぞれの問題には、別の手段で対応できる？
Slide 20
Slide 20 text
MLシステムは通常に比べ、不安定で制御しにくい
→ 通常と同じSLIに対し、同水準のSLOを設定するのは非現実的
● 予測モデルの計算量が大きい → Webリクエストのレイテンシが大きくなる
● 学習が確率的に失敗 → ジョブ監視を同様にするとアラートが飛びまくる
注意１：通常と同じ水準の信頼性を求めにくい
学習データ
アルゴリズム
学習
モデル
入力データ 出力データ
予測（推論）
Slide 21
Slide 21 text
注意２：それぞれの信頼性は分割統治しにくい
通常の問題に見えても原因がMLにあったり、その逆もある
→ 通常指標とML指標で、対応手段や対応者を完全に分離するのは難しい
● 少しのデータ増でOOMが発生 ← レコメンドで求人数×求人数の行列を生成
● ある日突然モデルの精度が低下 ← キャンペーンでデータ傾向が著しく変化
事象 ＼ 原因 サービスやインフラの問題 MLモデル・アルゴリズムの問題
Web API やジョブのエラー Webエンジニアが対処可能 Webエンジニアだけでは対処困難
MLモデルの精度低下・不安定化 MLエンジニアだけでは対処困難 MLエンジニアが対処可能
Slide 22
Slide 22 text
MLシステムに対してSREができること
1. MLの性質に応じた指標や目標を設定する
○ 求められるレベルが通常とMLとで異なることを受け入れる
○ 関係者間でサービスレベルに対する認識を合わせておく
2. 通常・ML両方の信頼性の観点から問題を捉える
○ MLの問題にみえてもサービスやインフラが原因のケースやその逆に注意
○ 通常・MLそれぞれのシステムの性質に合わせて適切な手段を選択する
3. １と２を支える仕組みを整備する
○ 実験的なシステムでも安全に検証が行える環境をつくる
○ 問題の原因の切り分けをしやすいようシステムを設計する
Slide 23
Slide 23 text
リブセンスでの取り組み
Slide 24
Slide 24 text
MLチームにSREの役割をおく
● MLE：MLモデルの発揮する価値を最大化する
● SRE：システムの信頼性と開発効率を考慮して設計や運用を担う
MLE, SRE が共同でプロジェクトに携わる
レコメンドプロジェクト 検索順位プロジェクト
SRE MLE SRE MLE
Slide 25
Slide 25 text
● システムごとにどの程度の信頼性を求めるかの共通認識をつくる
● 過剰な信頼性を求めることによる開発・運用コスト増を防ぐ
● 不安定なシステムがクリティカルな用途で使われるのを防ぐ
MLシステムをフェーズに区分
フェーズ 開発・運用の目的 サービスレベル SREの役割
コンセプト検証 コンセプトの実現性の検証 SLI / SLO を定めない インフラやデータの整備と提供
技術検証 最適な技術手段の検証 個別に判断 システム設計やトラブル対応の協力
実運用 継続的な価値提供 SLI / SLO を定める 安定性・メンテナンス性の維持
Slide 26
Slide 26 text
● MLチーム内で運用を担うことで
問題対応を迅速・柔軟に
● 複数のシステムを集約して
運用・管理を一元化
● サービスと疎結合にすることで
問題の原因を特定しやすく
● 開発・本番のデータソースを
一元化して結果の再現性を担保
Kubernetes を利用したコンテナベース機械学習基盤の構築
https://analytics.livesense.co.jp/entry/2018/01/18/090000
ML専用の検証・運用基盤を構築
Slide 27
Slide 27 text
● アルゴリズムの問題と
それ以外を切り分けやすく
● 精度検証や問題の原因調査を
コンポーネント毎に可能に
● アルゴリズム実装の再利用で
管理すべきコードを削減
● 最近では Argo Workflow を
ワークフローエンジンに採用
マルチコンテナ構成による機械学習アルゴリズムとアプリケーションの疎結合化
https://analytics.livesense.co.jp/entry/2017/12/08/105045
モデルとアプリケーションを疎結合化
Slide 28
Slide 28 text
まとめ
Slide 29
Slide 29 text
話したかったこと
● リブセンスではMLシステムについてどんな課題を抱えている (いた) か？
○ ML導入の効果は大きかったが、開発後の改善が難しい
○ 負債化による問題が顕在化し、MLへの信頼性が失われかねない状況
● SREの考え方をMLシステム開発・運用に適用することはできるか？
○ 原則：SLIの導入と計測・評価は部分的にはできそう
○ 実践：SLOの設定とその実現手段はMLの性質を踏まえて考える
● 実際のMLシステム開発・運用にどう取り組んでいるか？
○ 現実的な範囲で求める信頼性を定義し、それをもとに手段を考える
○ 信頼性と開発効率を両立できる仕組みを整備