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

by tonouchi510

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介    　登内雅人（Masato Tonouchi）  　　　　　　　　　　　　　　　　　　　　株式会社ミクシィ   　　　　　　　　　　　　　　　　　　　　みてね事業部 DataEngineeringグループ MLエンジニア   Twitter: @tono2700, GitHub: @tonouchi510    ● 業務：顔認識系の研究開発、MLOps、バックエンド   ● 趣味：筋トレ、格闘技、個人開発、七輪   ● 浜松でリモートワーク中 

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

※2021年3月 

Slide 6

Slide 6 text

季節ごとに届く1秒動画 1秒動画、フォトブックやプリントで驚きの振り返り  四季版 https://www.youtube.com/watch?v=DLuCAAlYrks 月番（プレミアムプランのみ配信） https://www.youtube.com/watch?v=olTGnZnt2sY ● 動画がたまると、三ヶ月に一回「1秒動画」が自動で作られ配信されます  ● 日々の成長がダイジェストで見れる、みてねの大人気機能です 

Slide 7

Slide 7 text

自動作成フォトブック、プリント、年賀状などオリジナル商品 ● 投稿した写真を使って様々な商品を作成・購入することができます  ● 取り扱う商品はフォトブック、 DVD、写真プリントなど、現在 11種類  ● フォトブックと写真プリントは毎月写真が自動で選択され、簡単に作成できます  1秒動画、フォトブックやプリントなどで驚きの振り返り 

Slide 8

Slide 8 text

人物ごとのアルバム  ● みてねにアップロードされた写真・動画を   プログラムで自動判定し、お子さまごとに   表示します。    ● 家族みんな（よく一緒に写っているご家族   のみなさま）や、子どもたち（兄弟や姉妹）   というまとまりでも振り返ることができます。  

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Data Engineering グループ  ● 「家族アルバムみてね」における「1秒動画」や「自動提案フォトブック」、「人物ごとのアルバム」といったコンテンツの自動生成・自動提案・自動分類機能の開発を担当   ● 機械学習エンジニア、サーバーサイドエンジニアが協力し、開発を進めている   ○ 現在、機械学習エンジニアは私一人... （ご応募お待ちしてます）         https://team-blog.mitene.us/みてね-data-engineering-チームの取り組み-33188cbbc284  

Slide 11

Slide 11 text

研究開発環境 

Slide 12

Slide 12 text

人物ごとのアルバム解析システムのアーキテクチャ（再掲） 

Slide 13

Slide 13 text

以前の研究開発の仕方と課題  ● 機械学習の実験には、データ抽出・加工・トレーニング・評価など、一つの実験を   行うのに多くの工程が必要  ● これまでのやり方  ○ 本番システム（データ）はAWS、実験はGCPで行っていた   ○ クラウドだけでなく、プロジェクトも複数にまたがっていた    

Slide 14

Slide 14 text

以前の研究開発環境と課題  ● 機械学習の実験には、データ抽出・加工・トレーニング・評価など、一つの実験を   行うのに多くの工程が必要  ● これまでのやり方  ○ 本番システム（データ）はAWS、実験はGCPで行っていた   ○ クラウドだけでなく、プロジェクトも複数にまたがっていた     Compute Engine https://docs.google.com/presentation/d/1fD1AwQo4E9Un6012zyPEb7NvUAGlzF6L-vo5DbUe4NQ  https://aws.amazon.com/jp/architecture/icons/  BigQuery Vertex AI WorkBench

Slide 15

Slide 15 text

以前の研究開発環境と課題  ● 一つ実験においても、色々とコードやデータが散在していて、手順が複雑化していた   ● 実験設定と結果の対応も管理しづらくなっていた     => 時間とともに、もしくは担当者の転•退職とともに忘れ去られ、再現が難しくなる           => 一箇所に集約させ、手順を単純化したい   ・同じ条件で新しい期間のデータセットを作りたいけど、どこ　でやってたっけ？・ここのパラメータって何を指定するんだっけ？・このスクリプトの実行の順番、これでいいんだっけ？

Slide 16

Slide 16 text

● 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 

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Slide 21

Slide 21 text

実験管理・再現性の改善  https://www.kubeflow.org/docs/components/pipelines/introduction/  実行した時の・パイプラインバージョン・パラメータ・実験結果（精度など）・日付やステータスも記録してくれる

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

AI Platform Pipelinesで解決された課題まとめ  ● 実験設定・結果の記録の自動化  ○ 過去のジョブの履歴をみにいけば、パラメータ設定と結果が一目でわかる   ● 高い再現性、属人性排除  ○ 研究開発に関するタスクは全て一つのダッシュボードに集約   ○ やりたいタスクのパイプラインを選んでパラメータ入力してボタンを押すだけ   ● その他  ○ 実験結果の可視化も可能  ○ 途中でジョブが失敗した時の自動リトライ   ○ Kubernetes使っていることによるリソースの効率活用  

Slide 24

Slide 24 text

Vertex ではなく AI Platformを使っている理由  ● 実験結果を分けて管理したかった  ○ Vertex Pipelinesにはkubeflow pipelinesのexperimentに値する機能がない   ● CloudTPU(preemptible)を使いたかった  ○ Vertex PipelinesだとパイプラインからTPUノード管理できない   ● その他細かい機能でもまだ未対応のものが多かった    今のところ、AI Platform Pipelinesは実験用途、Vertex Pipelinesは本番のバッチ処理用途に適してそう？ 

Slide 25

Slide 25 text

Kubeflow Pipelinesの実装パターンに関する記事も書きました  ● みてねブログ  ○ Kubeflow Pipelines の実装パターン例を公開します | by Tonouchi | Jul, 2022 | mitene / FamilyAlbum Team  ● サンプルリポジトリ  ○ https://github.com/tonouchi510/kfp-project     フォルダ構成だったり、いくつかのパイプラインの実装例を載せています。optunaを kubeflow上で使うためのパイプラインとかも  興味あれば是非読んでみてください 

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

TensorFlowのデザインパターンの具体例も記事にしてます  リンク：https://medium.com/mitene-team/tensorflow-design-pattern-e4274cbbda8d    ● 論文の手法を取り入れたり、カスタマイズしたくなるのは主に以下   ○ 損失関数  ○ Data Augmentation  ○ 前処理  ○ モデル  ○ トレーニングステップ（例：GAN, Contrastive Learningなどの特殊なループ）   ● 必要な部分だけに注目して変更し、他はほぼ同じ仕組みで動くように実装  

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

人物ごとのアルバム（再掲）  ● みてねにアップロードされた写真・動画を   プログラムで自動判定し、お子さまごとに   表示します。    ● 家族みんな（よく一緒に写っているご家族   のみなさま）や、子どもたち（兄弟や姉妹）   というまとまりでも振り返ることができます。  

Slide 30

Slide 30 text

解析システムアーキテクチャ（再掲） 

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

解析の流れ  クラスタリング処理 & 人物への紐付け  1. 家族ごとに前約１ヶ月の期間の顔特徴ベクトルを取得する   2. 特徴ベクトル（512次元）を使ってクラスタリング   3. クラスタごとに、含まれる顔の年齢・性別推定結果から平均値を出す   4. みてねの登録情報（子供の生年月日・性別）とクラスタの平均値を利用して、   クラスタを人物に対応づける  年齢推定平均: 5.2, 性別推定平均: 女   年齢推定平均: 0.9, 性別推定平均: 男   みてね登録情報・◯子ちゃん => 5歳、女の子・◯男くん => 1歳、男の子

Slide 33

Slide 33 text

解析の流れ  クラスタリング処理（解析済みの期間がある場合）  1. 解析対象の顔特徴ベクトルを取得する際に、前回解析時に人物に紐づいた  クラスタのノード（特徴ベクトル）も一緒に取得し、クラスタリング  a. この際、前回分はクラスタ初期値が設定される  2. 前回のクラスタに併合されたノードがその人物に分類される  3. 新しいクラスタに対しては、前ページの3, 4のステップ  クラスタA  クラスタB  クラスタC  は、まだ未解析のノード（今回分）

Slide 34

Slide 34 text

効果測定 

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

効果測定をやる背景  ● モデル・アルゴリズム改善によるビジネスインパクトを測定したい  ○ モデルを10%向上したからといって、収益が10％向上するわけではない   ○ 実際のビジネスへの貢献度を測りたい     ● 最終的な推論品質への影響を測定したい  ○ 複雑な解析システムの場合、モデル単体の改善とシステム全体の推論品質の改善も異なる   ■ 例：顔分類モデルの精度が10%上がっても、「人物ごとのアルバム」の分類精度   が10%上がるわけではない   ■ 年齢推定モデルの精度が5%向上 => だから何？    

Slide 37

Slide 37 text

効果測定をやる背景  ● モデル・アルゴリズム改善によるビジネスインパクトを測定したい  ○ モデルを10%向上したからといって、収益が10％向上するわけではない   ○ 実際のビジネスへの貢献度を測りたい     ● 最終的な推論品質への影響を測定したい  ○ 複雑な解析システムの場合、モデル単体の改善と解析システムの品質の改善も異なる   ■ 例：顔分類モデルの精度が10%上がっても、「人物ごとのアルバム」の分類精度   が10%上がるわけではない   ■ 年齢推定モデルの精度が20%向上 => だから何？     ● 問題に気づけるようにしたい  ○ 特徴抽出モデルの精度を10%向上   ■ 更新前の特徴ベクトルとの互換性の問題もあるため、実験環境だけでは不十分   ■ 特徴ベクトルの互換性が不十分で実は分類精度が落ちている可能性も   この辺りも解説してます => スライド

Slide 38

Slide 38 text

効果測定の方法  ● ビジネス上の指標  ○ モデルの性能ではなく、モデルを導入する目的となるビジネス課題に対する効果測定   ○ A/Bテストで KPI 等の指標で比較する     ● モデル・解析処理の精度監視  ○ A/Bテストでモデル単体もしくは最終的な推論結果の品質を比較する  

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

Slide 41

Slide 41 text

効果測定の方法：ビジネス上の指標  ● ビジネス上の指標（理想だが難しい）  ○ モデルの性能ではなく、モデルを導入する目的となるビジネス課題に対する効果測定   ○ A/Bテストで KPI 等の指標で比較する   ● 難しさ  ○ 基本的にかなり遅れて数値に反映される   ○ 季節性や市場状況（競合）など、色んな部分に影響を受けてしまう     ● みてねの現状  ○ 理想：人物ごとのアルバムの改善による課金率の向上   => 遅れて反映される & 他の機能リリースもある中で測るのは難しい   ○ その他指標  ■ 人物ごとのアルバムの誤分類に関連するCS問い合わせの数   ● ユーザがAIの誤りに気づけるケース  ■ 人物ごとのアルバムの閲覧数など  

Slide 42

Slide 42 text

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

新しく計測できるようにしたもの  ● E2E精度  ○ 特定のAIモデル・アルゴリズム更新が、最終的な推論結果にどれくらい影響したか     ● 正解データがない中で、どうやって計測するか  ○ 定期的にサンプリングして人力で教師ラベルをアノテーションし、精度を測る   ○ ユーザーに介入してもらう（間違いの訂正率などをみる等）   ○ 疑似的な正解ラベルを用意して精度を測る・トラッキングする   指標設計 

Slide 45

Slide 45 text

Slide 46

Slide 46 text

解析の流れ（再掲）  クラスタリング処理（解析済みの期間がある場合）  1. 解析対象の顔特徴ベクトルを取得する際に、前回解析時に人物に紐づいた  クラスタのノード（特徴ベクトル）も一緒に取得し、クラスタリング  a. この際、前回分はクラスタ初期値が設定される  2. 前回のクラスタに併合されたノードがその人物に分類される   3. 新しいクラスタに対しては、前ページの3, 4のステップ   クラスタA  クラスタB  クラスタC 

Slide 47

Slide 47 text

疑似ラベルを使って異常を検知  ● クラスタの混ざり  ○ 異なる疑似ラベルが混ざったクラスタが形成されてしまった状況   ● クラスタの消滅  ○ 前回あった疑似ラベルのクラスタがなくなってしまった状況   ● クラスタの分裂  ● その他  ※使用しているアルゴリズム特有の話も入ってきてしまうので、ある程度省略    何らか検知された場合   誤分類とする 

Slide 48

Slide 48 text

壊れ検知を使った効果測定  ● クラスタリング結果が壊れ検知した割合をトレースする  ○ モデル更新前後で変化を見る     ● 疑似ラベルが間違っている場合は？  ○ あくまで検知できるのはクラスタ混ざりや消失等のみ   ○ 分類が間違っていてもクラスタ混ざり等が発生していなければ、壊れ検知されないため、   実際よりも良い値で指標が記録されてしまう？   ■ ※分類誤りがあれば、大抵、いずれ壊れ検知に引っかかる想定   ● あくまで限界精度として捉え、トラッキングする  ○ 例：壊れ検知率が20% => 分類が成功しているのは最大でも80%（70%, 60%の可能性も）   完璧な成功率は出せなくとも、効果測定の１指標として使える

Slide 49

Slide 49 text

現状の効果測定の指標まとめ  ビジネス指標  ● CSの問い合わせ数  ○ 人物ごとのアルバムに異常がある場合に問い合わせが来る   ● 人物ごとのアルバムの閲覧数  解析の品質  ● 顔画像の人物への紐付き率  ● 壊れ検知率 

Slide 50

Slide 50 text

まとめ  ● みてねの研究開発とMLOps事情を紹介しました  ● 機械学習システムを構築する際は、A/Bテストできる設計を初めから  しておくべきだった  ● 正解データはなくても、うまく疑似ラベルを設計することができれば、  効果測定できることを紹介しました    興味を持っていただけた方、アイデアのある方は是非ご応募お待ちしています。  ・みてね採用情報  ・【家族アルバムみてね】機械学習エンジニア募集要項 Data Engineering グループ  