iosdc2021で発表する資料です https://fortee.jp/iosdc-japan-2021/proposal/840828ad-6669-41d0-84ed-b8a1b861afc5

1. 1
MediaPipeを使ったARアプリ開発事例
カメラをかざして家の中で売れるものを探そう

2. 2
● カメラをかざすと写っている商品のカテゴリ・値
段・売れやすさを予測
● Mercari(iOS)の出品タブにて
一部ユーザに提供中
● iPhone7以降のiOS端末に対応
「 かざして売れるかチェック」の紹介

3. 3
「かざして売れるかチェック」のしくみ
※実験段階

4. 4
1. EdgeAIとは
2. 「かざして売れるかチェック」ができるまで
3. サービスとして提供するための工夫
今日の内容
iOS x AI の2つの知識が必要になるテーマですが、
できるだけAI初心者にもわかりやすいようにお話していきます
Presenter:
Chica Matsueda (Mercari EdgeAI Team)

5. 5
EdgeAIとは

6. 6
EdgeAI技術とは？
自動運転が周りの状況を認識するAIを端
末内で計算していなかった場合...
サーバーに状況を送って返ってくる
数百msecの間にもう事故は
起こってしまう！
あぶない！

7. 7
● リアルタイム性
○ e.g. 自動運転・カメラの自動フォーカスや顔検出
● 外部通信をしないことによる安全性
○ e.g. スマートスピーカーのウェイクキーワード (OK, Google)の判別
■ 室内のおしゃべり全部サーバーに送ってたらプライバシーの問題がありますよね ...
● Edge上での学習による最適化
○ e.g. IME (端末上で個別ユーザーに最適化されていく )
EdgeAIが提供する価値

8. 8
● カメラのフィルタ
● Instagramのライブのフィルタ
● ARゲーム (Pokémon GO)
EdgeAI技術のモバイル領域での活用
引用: Instagram blog
Introducing Face Filters in Instagram Live

9. 9
AI × UX

10. 10
● ML Kit (Firebase)
FirebaseSDKで気軽に使える
● CoreML (Apple)
Apple端末のための高性能なframework.
iOS内蔵なのでframework分の容量が増えないのが嬉しい
● MediaPipe (Google)
ストリーミング処理に特化、カスタマイズ性の高いframework
モバイル端末上でAIを走らせるためのframework

11. 11
● iOSでもAndroidでも提供したい → ML Kit / MediaPipe
● 自作モデルを利用したい → ALL
● ストリーミングメディアのリアルタイムな推論 → MediaPipe
● 電池消費を抑えるためのチューニングがしたい → MediaPipe
「かざして売れるかチェック」の技術選定

12. 12
ストリーミングメディアに対して推論を実行
するパイプラインを構築するためのフレー
ムワーク
以下のようなサンプルが準備されている
● Face Detection
● Hand Tracking
● Object Detection/Tracking
● Hair Segmentation
● ...
MediaPipeとは？
引用: https://mediapipe.dev/

13. 13
MediaPipe活用事例
● Google Meets
- 背景変更・ぼかし
● Olympic pictgram
by @KzhtTkhs -san
tweet:
https://twitter.com/KzhtTkhs/status/1420390042564927
489

14. 14
MediaPipeには便利な処理のテンプレート(カリキュレータ)が
複数準備されている
MediaPipe - 処理のテンプレート

15. 15
カリキュレータつないで自由にパイプラインを作れる
e.g. 物体検出のパイプライン
MediaPipe - パイプライン
引用: https://mediapipe.dev/

16. 16
なぜMediaPipeはストリーミングメディアの推論が早いのか？
15fpsで動作させたい場合
最も時間のかかるカリキュレータ
が
1/15secで処理できれば良い

17. 17
「かざして売れるかチェック」
ができるまで

18. 18
1. モバイル端末向けにモデルをチューニング
2. モデルのTFLite変換と量子化
3. パイプラインの実装
4. MediaPipeのフレームワーク化
5. Mercari本体への実装
リリースまでに必要なタスク

19. 19
モバイル端末向けモデルの要件
● 過度な計算負荷のないモデル
● 大きすぎないモデル
今回必要になるモデル
● 物体検出
● 特徴量抽出 (＝画像のベクトル変換)
○ 他のPJでも使っている共通モデルがあり、更新不可
モバイル端末向けモデル

20. 20
モデル概要
● アーキテクチャ: ssdlite-mobilenet-v2
● クラス数: 90
● モデルサイズ: 18MB
● 物体を同時に複数検出
MediaPipeの準備している物体追跡サンプル
引用: https://mediapipe.dev/

21. 21
モデルアーキテクチャごとにMercariのデータセットに対する精度を検証
※アーキテクチャ: ディープラーニングモデルの種類
※mobilenet-v2: 高性能な軽量モデルで有名な物体検出・クラス分類に使われるアーキテクチャ
※Precision: 検出した物体のうち正解だった物体の割合予想した矩形と正解の矩形がどれだけかぶっているか, mAP
※Recall: すべての物体の中で検出できた物体の割合, AR@100
アーキテクチャの選定
アーキテクチャ モデルサイズ Precision Recall
ssd-mobilenet-v2 18MB 0.56 0.66
ssdlite-mobilenet-v2 12.1MB 0.56 0.67
ssdlite-mobilenet-v3-small 3.7MB 0.38 0.36
ssd-mobilenet-v2-fpnlite 11MB - -

22. 22
SSDLite-mobilenet-v2のモデルをクラス数を変えて性能比較
全結合層(クラス分類をするレイヤー)の重みはモデルサイズに影響
今回の物体検出ではクラス分類は必要ないため
1クラスに。
クラス数の削減によるモデルの軽量化
クラス数 モデルサイズ 500枚の画像の推論にかかった時間
600 クラス 49MB 60sec
90 クラス 17MB 35sec
1 クラス 12MB 32sec

23. 23
TensorFlow Lite
● モバイルデバイスやIoTデバイス上でAIを利用するためのフレームワーク
● MLKitやMediaPipeの中でも使われている
● 従来のモデルを量子化することで、モデルサイズを小さくすることができる
● モバイルで利用するためにはTensorFlowのモデルTensorFlowLiteモデルに
コンバートする必要有 ＜自作モデルを使うとなるとこれだけでもかなり大変
○ 詳しくは: TensorflowモデルをTFLiteにconvertする方法とconvertツールの比較
モデルのTensorFlow Lite変換・量子化

24. 24
TFLiteの重みの量子化オプション
Technique Benefits Hardware
Dynamic range quantization
重みをuint8に量子化
4x smaller CPU
Float16 quantization
重みをfloat16に量子化
2x smaller
GPU acceleration
CPU, GPU
サーバーで学習・推論するモデルは float32 で情報が保持されている

25. 25
量子化すると重みは具体的にどうなる？
モデルサイズ 重みの値の例
float32 - -0.12345678
float16 float32 の 1/2 -0.1235
uint8 float32 の 1/4 0~255
なるほど
エッ?!

26. 26
uint8に重みを量子化する場合は
量子化を意識したモデルのトレーニング(=QA)をし直す必要がある
注意点1: 量子化する前提で再トレーニングをする必要有
物体検出モデル Precision
QAなし + uint8に重みを量子化 0.365
QAあり + uint8に重みを量子化 0.415

27. 27
● GPU利用時はCPUよりも3倍ほど速度が挙がる(ios端末の場合)
注意点2: uint8量子化した場合GPUを計算に使えない

28. 28
TFLiteモデルを量子化する際の現実的な選択肢
精度
モデル
サイズ
GPU利用
uint8に重みを量子化 + QA ○ 1/4 ☓
float16に重みを量子化 ◎ 1/2 ○
MediaPipeの物体検出まわりのカリキュレータが
GPU用のみ用意されていることからこちらを選択

29. 29
モバイル端末向けの工夫をした結果
※特徴量抽出モデルについては
float16量子化のみ行い 16MB -> 8MB
17MB
12MB
6MB
クラス数削減
重み量子化

30. 30
パイプラインの実装

31. 31
● Bazelでビルドされており、frameworkとしての配布なし
=> ios_frameworkとしてBazelでビルド
● シミュレータ未対応
=> 利便性やCIでのテスト実行を考えxcframework化
● Swiftから使えない
=> modulemapとumbrella headerを作成
● 既にMercariに組み込まれているTFLite のバイナリをMediaPipeが含んで
しまい、バイナリが重複する *
=> MediaPipe内のTFLiteバイナリを外からも利用できるように変更
MediaPipeをアプリに組み込む際の問題点

32. 32
TFLite バイナリ重複問題 - before

33. 33
TFLite バイナリ重複問題 - after

34. 34
load("@build_bazel_rules_apple//apple:ios.bzl", "ios_framework")
ios_framework(
name = "MediaPipe",
hdrs = glob([
"tflite/*.h", # MediaPipeの内部のtfliteをMediaPipeのframeworkから利用するため
"MediaPipe.h", # --- C++のインタフェースをあれするやつ
"MediaPipe-umbrella.h" # umbrellaヘッダ
]),
infoplists = ["Info.plist"], # --- 作り方がわからないのでどこかからコピペしたのを編集して作った
bundle_id = "xxxxxx",
bundle_name = "MediaPipe",
families = ["iphone", "ipad"],
minimum_os_version = "12.0",
deps = [
":MediaPipeLibrary",
"@ios_opencv//:OpencvFramework",
],
)
実際のBazelコード
詳細が気になった方向け (skip)

35. 35
サービスとして提供するための工夫

36. 36
社内でユーザテストを実施したところ以下の課題が挙がる
● 計算負荷が高すぎてモバイル端末が熱くなる
● アプリサイズの増加が大きすぎる
サービスとして提供するための技術的課題

37. 37
● テストユーザから「端末が熱い」という意見が多く寄せられる
● しばらく起動しているとカクつく
計算負荷が高すぎてモバイル端末が熱くなる

38. 38
体験の良さを保ちつつ 計算負荷を下げた
物体検出をさぼる
● 物体検出・追跡は重い処理
● 物体追跡のフレームレートを落とすと体感が著しく低下する
⇒ 毎フレーム物体追跡を行いつつ、物体検出は数フレームに1度に
特徴量抽出をさぼる
● カメラの撮影位置が変わってもアイテムの特徴量はあまり変わらない
● 物体検出後すぐはカメラが移動しておりブレがち
⇒ 物体検出された数フレーム後に一度だけ特徴量抽出

39. 39
パイプラインの処理を修正

40. 40
エナジーインパクトの違い

41. 41
この時点での追加リソース
● MediaPipe Library (5MB程度)
○ ただしTFLiteの分は既存のアプリに組込済なので微増
○ 端末ごとの最適化などがあるので、正確に増加量を計算するのは難しい
● 物体検出モデル (6MB) ←リアルタイム性を提供するため外せない
● 特徴量抽出モデル(8MB) ← 技術的にはやりたかったけど必須ではない
※アプリサイズの正確な見積もりは難しいが、+10MBには抑えたかった
アプリサイズの増加が大きい

42. 42
現時点での追加予定リソース
● MediaPipe Library (5MB程度)
○ ただしTFLiteの分は既存のアプリに組込済なので微増
○ 端末ごとの最適化などがあるので、正確に増加量を計算するのは難しい
● 物体検出モデル (6MB) ←リアルタイム性を提供するため外せない
● 特徴量抽出モデル(8MB)
アプリサイズの増加が大きい

43. 43
利点
● 推論速度が 2~30msec早くなる
● 写真情報が一切サーバーに送られない
欠点
● アプリサイズ +8MB
※計算負荷には大きな問題はなかった
特徴量抽出をモバイル端末で行う利点と欠点

44. 44
特徴量抽出をサーバーと端末でやる場合の違い
端末
サーバー
表示を待たされる感覚は
UIの工夫により解消
プロダクト版

45. 45
「かざして売れるかチェック」のしくみ
※実験段階

46. 46
「かざして売れるかチェック」のしくみ (現在)
※写真情報は
一切保管しない

47. 47
+5MB
95MB → 100MB
MediaPipe + Model によるアプリDLサイズの増加量

48. 48
おまけ

49. 49
● モバイルでのEdgeAI活用事例はまだ少ない
● 開発にはモバイルとAIの知識が両方必要
○ 両方できる人は探してもほとんどいない
今回はAIエンジニアのモバイルのフロントを勉強して実装
● 本当にEdgeでやる必要あるか
○ それ、サーバーでやってもよくないですか？
モバイル端末でのEdgeAIのこれから

50. 50
EdgeAIチームの活動 - IME
メルカリ分野・撮影した商品に特化した
ワードを補完する機能
キーボードの写真を撮影すると...
→ 「Apple」「Keyboard」「純正」
などのキーワードが補完される
Androidにて一部リリース中

51. 51
EdgeAIチームの活動 - Webで売れるかチェック
Mercariを使ったことのない人にも試してもらいたい！
● 同じ機能をスマホのブラウザから利用できるように
● 「メルカリステーション」にてテスト利用実施中
近日Webに一般公開される・・・かも？

52. 52
ML側の詳しいことは Mercari Gearsにてお話しています
MGLS #18 メルカリにおけるEdgeAI (1/4) ~ 4/4 をぜひご覧ください。
もっと詳しく知りたい方へ

53. 53
1. EdgeAIとは
=> 端末上でAIを動かす技術。メルカリではこれを利用しユーザの体験を
よりよくしていくことを目指している
2. 「かざして売れるかチェック」ができるまで
=> TFLite・MediaPipeを使って推論パイプラインを実装
3. サービスとして提供するための工夫
=> 計算負荷を減らして電池消費対策・アプリサイズ削減
まとめ

54. 54
補足資料

55. 55
物体検出と物体検出+追跡の違い

56. 56
● サンプルはBazelでiOSアプリごとビルドされている
frameworkとして配布されていない
● サンプル以上のことをしようとすると、カリキュレータの追加やパイプラインの変
更が必要になりMediaPipeのバイナリごとビルドし直す必要有
● サンプルはObjective-Cで作成されており、swiftから使われていない
● MediaPipeはシミュレータ未対応 → xcframework
MediaPipeのフレームワーク化

57. 57
量子化すると重みは具体的にどうなる？
※画像はイメージです
float32 float16 uint8

58. 58
TFLiteの量子化オプション
Technique Benefits Hardware
Dynamic range quantization
重みをuint8に量子化
4x smaller
2x-3x speedup
CPU
Full integer quantization
重みと活性化関数を uint8に量子化
4x smaller
3x+ speedup
CPU, Edge TPU,
Microcontrollers
Float16 quantization
重みをfloat16に量子化
2x smaller
GPU acceleration
CPU, GPU
サーバーで学習・推論するモデルは float32 で情報が保持されている