Upgrade to Pro — share decks privately, control downloads, hide ads and more …

第22回 MLOps 勉強会:みてねのMLOps事情

tonouchi510
August 10, 2022

第22回 MLOps 勉強会:みてねのMLOps事情

tonouchi510

August 10, 2022
Tweet

More Decks by tonouchi510

Other Decks in Technology

Transcript

  1. 第22回 MLOps 勉強会
 みてねのMLOps事情
 株式会社ミクシィ
 みてね事業部 DataEngineering グループ 
 登内

    雅人

  2. 自己紹介
 
  登内 雅人(Masato Tonouchi)
                     株式会社ミクシィ 
                     みてね事業部 DataEngineeringグループ MLエンジニア

    
 Twitter: @tono2700, GitHub: @tonouchi510
 
 • 業務:顔認識系の研究開発、MLOps、バックエンド 
 • 趣味:筋トレ、格闘技、個人開発、七輪 
 • 浜松でリモートワーク中

  3. 家族アルバム みてね について


  4. 子どもの写真・動画を家族で共有し、
 コミュニケーションして楽しむサービス


  5. ※2021年3月


  6. 季節ごとに届く1秒動画 1秒動画、フォトブックやプリントで驚きの振り返り
 四季版 https://www.youtube.com/watch?v=DLuCAAlYrks 月番(プレミアムプランのみ配信) https://www.youtube.com/watch?v=olTGnZnt2sY • 動画がたまると、三ヶ月に一 回「1秒動画」が自動で作られ 配信されます


    • 日々の成長がダイジェストで 見れる、みてねの大人気機能 です

  7. 自動作成フォトブック、プリント、年賀状など オリジナル商品 • 投稿した写真を使って様々な 商品を作成・購入することが できます
 • 取り扱う商品はフォトブック、 DVD、写真プリントなど、現在 11種類


    • フォトブックと写真プリントは毎 月写真が自動で選択され、簡 単に作成できます
 1秒動画、フォトブックやプリントなどで驚きの振り返り

  8. 人物ごとのアルバム
 • みてねにアップロードされた写真・動画を 
 プログラムで自動判定し、お子さまごとに 
 表示します。
 
 • 家族みんな(よく一緒に写っているご家族

    
 のみなさま)や、子どもたち(兄弟や姉妹) 
 というまとまりでも振り返ることができます。 

  9. 人物ごとのアルバム 解析システムのアーキテクチャ


  10. Data Engineering グループ
 • 「家族アルバム みてね」における「1秒動画」や「自動提案フォトブック」、「人物ごとのアルバム」といったコ ンテンツの自動生成・自動提案・自動分類機能の開発を担当 
 • 機械学習エンジニア、サーバーサイドエンジニアが協力し、開発を進めている

    
 ◦ 現在、機械学習エンジニアは私一人... (ご応募お待ちしてます) 
 
 
 
 https://team-blog.mitene.us/みてね-data-engineering-チームの取り組み-33188cbbc284 

  11. 研究開発環境


  12. 人物ごとのアルバム 解析システムのアーキテクチャ(再掲)


  13. 以前の研究開発の仕方と課題
 • 機械学習の実験には、データ抽出・加工・トレーニング・評価など、一つの実験を 
 行うのに多くの工程が必要
 • これまでのやり方
 ◦ 本番システム(データ)はAWS、実験はGCPで行っていた 


    ◦ クラウドだけでなく、プロジェクトも複数にまたがっていた 
 

  14. 以前の研究開発環境と課題
 • 機械学習の実験には、データ抽出・加工・トレーニング・評価など、一つの実験を 
 行うのに多くの工程が必要
 • これまでのやり方
 ◦ 本番システム(データ)はAWS、実験はGCPで行っていた 


    ◦ クラウドだけでなく、プロジェクトも複数にまたがっていた 
 
 Compute Engine https://docs.google.com/presentation/d/1fD1AwQo4E9Un6012zyPEb7NvUAGlzF6L-vo5DbUe4NQ
 https://aws.amazon.com/jp/architecture/icons/
 BigQuery Vertex AI WorkBench
  15. 以前の研究開発環境と課題
 • 一つ実験においても、色々とコードやデータが散在していて、手順が複雑化していた 
 • 実験設定と結果の対応も管理しづらくなっていた 
 
 => 時間とともに、もしくは担当者の転•退職とともに忘れ去られ、再現が難しくなる

    
 
 
 
 
 => 一箇所に集約させ、手順を単純化したい 
 ・同じ条件で新しい期間のデータセットを作りたいけど、どこ でやっ てたっけ? ・ここのパラメータって何を指定するんだっけ? ・このスクリプトの実行の順番、これでいいんだっけ?
  16. • AI Platform Pipelines
 ◦ AI系の実験に関する様々なタスクを集約 
 • AI Platform

    Workbench (Notebook) 
 ◦ 一部デバッグとかで使用
 • その他
 ◦ CloudTPU, Optuna(on KFP) 
 
 言語・フレームワーク
 • Python, Golang
 • TensorFlow(v2), Kubeflow Pipelines 
 現在の研究開発環境
 https://github.com/kubeflow/kubeflow, https://github.com/GoogleCloudPlatform, 
 https://github.com/jupyter, https://github.com/tensorflow

  17. AI Platform Pipelines に実験関連タスクを集約
 https://www.kubeflow.org/docs/components/pipelines/introduction/
 パイプライン一覧画面を見れば、用意されている全ての実験関連ジョブが見れる 


  18. 一連の工程をパイプライン化
 https://www.kubeflow.org/docs/components/pipelines/introduction/
 データセット作成
 • BigQueryからクエリで抽出 
 • 画像データ ダウンロード 


    • データ加工
 • 保存
 
 実験
 • トレーニング
 • 評価
 • 分析・可視化
 • などなど

  19. 一連の工程をパイプライン化
 https://www.kubeflow.org/docs/components/pipelines/introduction/
 データセット作成
 • BigQueryからクエリで抽出 
 • 画像データ ダウンロード 


    • データ加工
 • 保存
 
 実験
 • トレーニング
 • 評価
 • 分析・可視化
 • などなど
 パイプライン化 一連のステップをひとまとめに
  20. 一連の工程をパイプライン化
 https://www.kubeflow.org/docs/components/pipelines/introduction/
 データセット作成
 • BigQueryからクエリで抽出 
 • 画像データ ダウンロード 


    • データ加工
 • 保存
 
 実験
 • トレーニング
 • 評価
 • 分析・可視化
 • などなど
 パイプライン化 一連のステップをひとまとめに パラメータを指定し、実行するだけ
  21. 実験管理・再現性の改善
 https://www.kubeflow.org/docs/components/pipelines/introduction/
 実行した時の ・パイプラインバージョン ・パラメータ ・実験結果(精度など) ・日付やステータス も記録してくれる

  22. 実験結果の可視化
 
 
 
 
 
 
 他にもTensorBoardポッドをボタン一つで起動できたり 
 https://www.kubeflow.org/docs/components/pipelines/introduction/


  23. AI Platform Pipelinesで解決された課題 まとめ
 • 実験設定・結果の記録の自動化
 ◦ 過去のジョブの履歴をみにいけば、パラメータ設定と結果が一目でわかる 
 •

    高い再現性、属人性排除
 ◦ 研究開発に関するタスクは全て一つのダッシュボードに集約 
 ◦ やりたいタスクのパイプラインを選んでパラメータ入力してボタンを押すだけ 
 • その他
 ◦ 実験結果の可視化も可能
 ◦ 途中でジョブが失敗した時の自動リトライ 
 ◦ Kubernetes使っていることによるリソースの効率活用 

  24. Vertex ではなく AI Platformを使っている理由
 • 実験結果を分けて管理したかった
 ◦ Vertex Pipelinesにはkubeflow pipelinesのexperimentに値する機能がない

    
 • CloudTPU(preemptible)を使いたかった
 ◦ Vertex Pipelinesだと パイプラインからTPUノード管理できない 
 • その他細かい機能でもまだ未対応のものが多かった
 
 今のところ、AI Platform Pipelinesは実験用途、Vertex Pipelinesは本番のバッチ処理用 途に適してそう?

  25. Kubeflow Pipelinesの実装パターンに関する記事も書きました
 • みてねブログ
 ◦ Kubeflow Pipelines の実装パターン例を公開します | by

    Tonouchi | Jul, 2022 | mitene / FamilyAlbum Team
 • サンプルリポジトリ
 ◦ https://github.com/tonouchi510/kfp-project 
 
 フォルダ構成だったり、いくつかのパイプラインの実装例を載せています。optunaを kubeflow上で使うためのパイプラインとかも
 興味あれば是非読んでみてください

  26. その他
 • フレームワーク:基本 TensorFlow(v2)
 ◦ 世の中的にはPytorchが多そう? 
 ▪ メリット:書きやすさ、公開実装が多さ、というのを良く聞く 


    ▪ 公開実装があれば、気になる論文の手法をすぐ試せる利点はある 
 • 公開実装を使うデメリット
 ◦ ただし、公開実装をサービスに移植するのを繰り返すと、モデルの数だけ実装パターンがあり、開 発・運用面でデメリットが出てくる 
 ◦ 例えば、ある論文で読んだデータオーグメンテーション手法や損失関数などを、どちらのモデルにも 取り入れたいと考えた時、モデルAとBが異なるフレームワークやAPIで実装をされていたら、大抵 の場合別々に実装して取り入れなければならなくなる 
 ◦ サービスに組み込む際の実装も多様化する 
 => 回避するために、できるだけ統一した実装パターンにする 

  27. TensorFlowのデザインパターンの具体例も記事にしてます
 リンク:https://medium.com/mitene-team/tensorflow-design-pattern-e4274cbbda8d
 
 • 論文の手法を取り入れたり、カスタマイズしたくなるのは主に以下 
 ◦ 損失関数
 ◦ Data

    Augmentation
 ◦ 前処理
 ◦ モデル
 ◦ トレーニングステップ(例:GAN, Contrastive Learningなどの特殊なループ) 
 • 必要な部分だけに注目して変更し、他はほぼ同じ仕組みで動くように実装 

  28. 人物ごとのアルバムの解析システム


  29. 人物ごとのアルバム(再掲)
 • みてねにアップロードされた写真・動画を 
 プログラムで自動判定し、お子さまごとに 
 表示します。
 
 • 家族みんな(よく一緒に写っているご家族

    
 のみなさま)や、子どもたち(兄弟や姉妹) 
 というまとまりでも振り返ることができます。 

  30. 解析システムアーキテクチャ(再掲)


  31. 解析の流れ
 画像アップロード時
 1. 画像から顔画像を検出する
 2. 顔画像から姿勢推定モデルで向きを推定する 
 3. 向きを揃えた顔画像を入力し、年齢・性別推定と特徴ベクトル抽出を行う 


    年齢推定:4.2 歳
 性別推定:女
 特徴ベクトル(512次元)
 顔検出

  32. 解析の流れ
 クラスタリング処理 & 人物への紐付け
 1. 家族ごとに前約1ヶ月の期間の顔特徴ベクトルを取得する 
 2. 特徴ベクトル(512次元)を使ってクラスタリング 


    3. クラスタごとに、含まれる顔の年齢・性別推定結果から平均値を出す 
 4. みてねの登録情報(子供の生年月日・性別)とクラスタの平均値を利用して、 
 クラスタを人物に対応づける
 年齢推定平均: 5.2, 性別推定平均: 女 
 年齢推定平均: 0.9, 性別推定平均: 男 
 みてね登録情報 ・◯子ちゃん => 5歳、女の子 ・◯男くん => 1歳、男の子
  33. 解析の流れ
 クラスタリング処理(解析済みの期間がある場合)
 1. 解析対象の顔特徴ベクトルを取得する際に、前回解析時に人物に紐づいた
 クラスタのノード(特徴ベクトル)も一緒に取得し、クラスタリング
 a. この際、前回分はクラスタ初期値が設定される
 2. 前回のクラスタに併合されたノードがその人物に分類される
 3.

    新しいクラスタに対しては、前ページの3, 4のステップ
 クラスタA
 クラスタB
 クラスタC
 は、まだ未解析の ノード(今回分)
  34. 効果測定


  35. 効果測定をやる背景
 • モデル・アルゴリズム改善によるビジネスインパクトを測定したい
 ◦ モデルを10%向上したからといって、収益が10%向上するわけではない 
 ◦ 実際のビジネスへの貢献度を測りたい 
 


  36. 効果測定をやる背景
 • モデル・アルゴリズム改善によるビジネスインパクトを測定したい
 ◦ モデルを10%向上したからといって、収益が10%向上するわけではない 
 ◦ 実際のビジネスへの貢献度を測りたい 
 


    • 最終的な推論品質への影響を測定したい
 ◦ 複雑な解析システムの場合、モデル単体の改善とシステム全体の推論品質の改善も異なる 
 ▪ 例:顔分類モデルの精度が10%上がっても、「人物ごとのアルバム」の分類精度 
 が10%上がるわけではない 
 ▪ 年齢推定モデルの精度が5%向上 => だから何? 
 

  37. 効果測定をやる背景
 • モデル・アルゴリズム改善によるビジネスインパクトを測定したい
 ◦ モデルを10%向上したからといって、収益が10%向上するわけではない 
 ◦ 実際のビジネスへの貢献度を測りたい 
 


    • 最終的な推論品質への影響を測定したい
 ◦ 複雑な解析システムの場合、モデル単体の改善と解析システムの品質の改善も異なる 
 ▪ 例:顔分類モデルの精度が10%上がっても、「人物ごとのアルバム」の分類精度 
 が10%上がるわけではない 
 ▪ 年齢推定モデルの精度が20%向上 => だから何? 
 
 • 問題に気づけるようにしたい
 ◦ 特徴抽出モデルの精度を10%向上 
 ▪ 更新前の特徴ベクトルとの互換性の問題もあるため、実験環境だけでは不十分 
 ▪ 特徴ベクトルの互換性が不十分で実は分類精度が落ちている可能性も 
 この辺りも解説し てます => スライド
  38. 効果測定の方法
 • ビジネス上の指標
 ◦ モデルの性能ではなく、モデルを導入する目的となるビジネス課題に対する効果測定 
 ◦ A/Bテストで KPI 等の指標で比較する

    
 
 • モデル・解析処理の精度監視
 ◦ A/Bテストで モデル単体もしくは最終的な推論結果の品質を比較する 

  39. 効果測定の方法
 • ビジネス上の指標
 ◦ モデルの性能ではなく、モデルを導入する目的となるビジネス課題に対する効果測定 
 ◦ A/Bテストで KPI 等の指標で比較する

    
 
 • モデル・解析処理の精度監視
 ◦ A/Bテストで モデル単体もしくは最終的な推論結果の品質を比較する 
 いずれにしろ、A/Bテストできる仕組みがあることがほぼ前提になってくる A/Bテストのことを初めから考えて設計するべきだった
  40. 効果測定の方法
 • ビジネス上の指標
 ◦ モデルの性能ではなく、モデルを導入する目的となるビジネス課題に対する効果測定 
 ◦ A/Bテストで KPI 等の指標で比較する

    
 
 • モデル・解析処理の精度監視
 ◦ A/Bテストで モデル単体もしくは最終的な推論結果の品質を比較する 

  41. 効果測定の方法:ビジネス上の指標
 • ビジネス上の指標(理想だが難しい)
 ◦ モデルの性能ではなく、モデルを導入する目的となるビジネス課題に対する効果測定 
 ◦ A/Bテストで KPI 等の指標で比較する

    
 • 難しさ
 ◦ 基本的にかなり遅れて数値に反映される 
 ◦ 季節性や市場状況(競合)など、色んな部分に影響を受けてしまう 
 
 • みてねの現状
 ◦ 理想:人物ごとのアルバムの改善による課金率の向上 
 => 遅れて反映される & 他の機能リリースもある中で測るのは難しい 
 ◦ その他指標
 ▪ 人物ごとのアルバムの誤分類に関連するCS問い合わせの数 
 • ユーザがAIの誤りに気づけるケース
 ▪ 人物ごとのアルバムの閲覧数など 

  42. 効果測定の方法
 • ビジネス上の指標
 ◦ モデルの性能ではなく、モデルを導入する目的となるビジネス課題に対する効果測定 
 ◦ A/Bテストで KPI 等の指標で比較する

    
 
 • モデル・解析処理の精度監視
 ◦ A/Bテストで モデル単体もしくは最終的な推論結果の品質を比較する 

  43. 効果測定の方法:モデル・解析処理の精度監視
 • モデル・解析処理の精度監視
 ◦ A/Bテストで モデル単体もしくは最終的な推論結果の品質を比較する 
 • 難しさ
 ◦

    本番運用を開始すると、正解データがない 
 ◦ モデル単体の推論結果に意味がある場合は、その推論タスクの精度を見れば良いが、 
 そうでないシステムの場合は、最終的な生成物(E2E)の品質・価値で 
 比較しなければ意味がない 
 
 • みてねの現状
 ◦ 顔画像の人物への紐付き率のトラッキング 
 ▪ 正解がないので合っているかはわからないが、モデル更新前後で全体としての比率が大幅 に変わったら何らか問題が生じている可能性 
 ▪ かなり間接的な指標しかなかった 
 ◦ 問題検知も限定的 & 効果測定にはならない 

  44. 新しく計測できるようにしたもの
 • E2E精度
 ◦ 特定のAIモデル・アルゴリズム更新が、最終的な推論結果にどれくらい影響したか 
 
 • 正解データがない中で、どうやって計測するか
 ◦

    定期的にサンプリングして人力で教師ラベルをアノテーションし、精度を測る 
 ◦ ユーザーに介入してもらう(間違いの訂正率などをみる等) 
 ◦ 疑似的な正解ラベルを用意して精度を測る・トラッキングする 
 指標設計

  45. 新しく計測できるようにしたもの
 • E2E精度
 ◦ 特定のAIモデル・アルゴリズム更新が、最終的な推論結果にどれくらい影響したか 
 
 • 正解データがない中で、どうやって計測するか
 ◦

    定期的にサンプリングして人力で教師ラベルをアノテーションし、精度を測る 
 ◦ ユーザーに介入してもらう(間違いの訂正率などをみる等) 
 ◦ 疑似的な正解ラベルを用意して精度を測る・トラッキングする 
 指標設計

  46. 解析の流れ(再掲)
 クラスタリング処理(解析済みの期間がある場合)
 1. 解析対象の顔特徴ベクトルを取得する際に、前回解析時に人物に紐づいた
 クラスタのノード(特徴ベクトル)も一緒に取得し、クラスタリング
 a. この際、前回分はクラスタ初期値が設定される
 2. 前回のクラスタに併合されたノードがその人物に分類される 


    3. 新しいクラスタに対しては、前ページの3, 4のステップ 
 クラスタA
 クラスタB
 クラスタC

  47. 疑似ラベルを使って異常を検知
 • クラスタの混ざり
 ◦ 異なる疑似ラベルが混ざったクラスタが形成されてしまった状況 
 • クラスタの消滅
 ◦ 前回あった疑似ラベルのクラスタがなくなってしまった状況

    
 • クラスタの分裂
 • その他
 ※使用しているアルゴリズム特有の話も入ってきてしまうので、ある程度省略
 
 何らか検知された場合 
 誤分類とする

  48. 壊れ検知を使った効果測定
 • クラスタリング結果が壊れ検知した割合をトレースする
 ◦ モデル更新前後で変化を見る 
 
 • 疑似ラベルが間違っている場合は?
 ◦

    あくまで検知できるのはクラスタ混ざりや消失等のみ 
 ◦ 分類が間違っていてもクラスタ混ざり等が発生していなければ、壊れ検知されないため、 
 実際よりも良い値で指標が記録されてしまう? 
 ▪ ※分類誤りがあれば、大抵、いずれ壊れ検知に引っかかる想定 
 • あくまで限界精度として捉え、トラッキングする
 ◦ 例:壊れ検知率が20% => 分類が成功しているのは最大でも80%(70%, 60%の可能性も) 
 完璧な成功率は出せなくとも、効果測定の1指標として使える
  49. 現状の効果測定の指標まとめ
 ビジネス指標
 • CSの問い合わせ数
 ◦ 人物ごとのアルバムに異常がある場合に問い合わせが来る 
 • 人物ごとのアルバムの閲覧数
 解析の品質


    • 顔画像の人物への紐付き率
 • 壊れ検知率

  50. まとめ
 • みてねの研究開発とMLOps事情を紹介しました
 • 機械学習システムを構築する際は、A/Bテストできる設計を初めから
 しておくべきだった
 • 正解データはなくても、うまく疑似ラベルを設計することができれば、
 効果測定できることを紹介しました
 


    興味を持っていただけた方、アイデアのある方は是非ご応募お待ちしています。
 ・みてね 採用情報
 ・【家族アルバム みてね】機械学習エンジニア募集要項 Data Engineering グループ