Recommended
More Related Content
Similar to 20210511 grass roots_ml_design_patterns_two_phase_predictions
Similar to 20210511 grass roots_ml_design_patterns_two_phase_predictions (20)
More from hitoshim
More from hitoshim (6)
20210511 grass roots_ml_design_patterns_two_phase_predictions
- 1. #19 Two-Phase Predictions 2021.5.11 Machine Learning Design Patterns 読書会 mukai
- 2. Problem ◻ モバイル機器や小型コンピュータのようなエッジデバイスで （比較的大きくて複雑な）モデルの推論を行いたい ◻ エッジデバイスの制約 常にインターネットに接続されているわけではない 大きなサイズのモデルは搭載できない 推論を行う頻度も多くはできない 推論に時間を掛けることもできない（低レイテンシー） ◻ 量子化にもトレードオフ モデルのサイズとレイテンシーの削減方法の一つとして量子化があり、 TensorFlow Lite が利用可能であるが、性能とはトレードオフ
- 3. Solution ◻ 問題を２つのフェーズ（パート）に分ける フェーズ１：シンプルな推論をエッジで行う フェーズ２：より複雑な推論はクラウドで行う ※問題が２つのフェーズに分解できることが前提 例）Google Home フェーズ１）音声が「 OK Google」かどう かの二値分類のみ行う フェーズ２）音声の 意味を理解する推論 を行う 音声が OK Google でない 場合は何もしない ＜その他の例＞ ・工場での機械の異常検知 １）機械からの異音の検知 ２）異音が機械の異常によるものかど うかの判別 ・絶滅危惧動物の特定と追跡 １）カメラ画像に絶滅危惧動物が写っ ているかどうかの検知 ２）動物の種類を判別
- 4. 実施例 ◻ 楽器の音の認識 楽器以外の音も含む約9000個の音のデータセット（from Kaggle）を例として ■ 41種類の音のラベル（うち18種類が楽器の音） ■ 音の入力に対して、楽器の音であれば、楽器の種類を出力する 以下の２つのフェーズに分ける ■ フェーズ１：楽器の音かどうかの二値分類（エッジ） ■ フェーズ２：楽器の種類の判別（クラウド） 音の入力を画像として処理 ■ 音をスペクトログラムに変換 サックスの音のスペクトログラム画像 縦軸： 周波数 横軸：時間
- 5. フェーズ１）エッジ側モデルの構築 ◻ 楽器の音かどうかの二値分類を行うモデル 要件：小さいサイズ、オフライン、高速な推論 ◻ MobileNetV2 のアーキテクチャを転用（転移学習）して構築 Keras では、MobileNetV2が組み込み済みで、ダイレクトに使える。 ImageNet で学習済みのMobileNetV2の最終層（ボトルネック層）より手 前までの部分を転用（転移学習）。係数は固定。 最終層を、Global Average Pooling と全結合層で置き換えて、 楽器の音かどうかを判別する 0〜1の値を1つ出力する。 ※性能を更に追求する場合には、 Progressive Fine Tuning やハイパーパラメータ探索をしてもよい。
- 6. フェーズ１）エッジ側モデルの構築 ◻ 学習したモデルをTensorFlow Lite形式に変換 係数を8ビット表現に置き換えるなどの量子化が行われサイズが約 1/4になる TensorFlow Liteに変換するコード例 TF Lite 形式のファイルにモデルを保存し、 推論の際にはこのファイルを読み込んで用いる。 ＜エッジにはどんなモデルが良いのか？＞ ・量子化などによるサイズ削減に伴う精度低下を考えると、経験則的 には、よりシンプルで、複雑でないモデルが良い。 ・多クラス判別よりも二値分類の方が好ましい。決定木や線形回帰な どの複雑でないモデルを可能であれば選択する。 ・それができない場合には、 Coral Edge TPUやJetson Nanoといっ た専用のハードウェアを検討してみてもよい。 ※エッジデバイスが、インターネットに常に接続されているわけでない場合は、オフライン 時は音声データを一時的に溜め込み、オンラインになった際に、 クラウドに送信してもよい。
- 7. フェーズ２）クラウド側モデルの構築 ◻ 楽器の種類を判別するモデル 特に制約は無いので、ユースケースに応じて様々な形を取りうる。 ■ Google Home の場合は、音声をテキストに変換するモデル、音声の内容を理解する自然言語処理のモデル、 ユーザーの属性や過去の履歴に応じた更にレコメンデーションを行うモデルの計３モデルを使っている。 ◻ VGGのアーキテクチャを転用（転移学習）して構築 Google AI Platform, AWS SageMakerなど任意のクラウドプラットフォームを利用可能 ImageNet で学習済みのVGG19を転用。 係数は固定。 最終層を、Global Average Pooling と全結合層で置き換えて、 楽器の種別を判別する18 次元の One-Hot Vector を出力する。 ※性能を更に追求する場合には、 Progressive Fine Tuning やハイパーパラメータ探索をしてもよい。
- 8. Trade-Offs and Alternatives ◻ インターネット接続が全く期待できない場合 スタンドアローンの Single-Phase モデル ■ Two-Phase Predictions は適用できない。 ■ オフライン版のモデル（性能は劣るがサイズを小さくしたもの）も併せて作成し、ユーザー にオプションとして提供する。 ■ 出来る限り性能を落とさないように、学習の段階から推論時の量子化をエミュレートして学 習を行う（量子化認識トレーニング ）のがよい。 ＜スタンドアローンSingle-Phase モデルの例＞ Google 翻訳：ダウンロードしてオフラインでも利用可能。 オフライン版でも性能が出せるにようになってきた。 Google Bolo： 英語学習用のリーディングアシスタ ントアプリ（アプリ名： Read Along） ユーザーの英語読み上げ音声を認識し、学習を 補助する。途上国などでの利用を想定して、完全 にオフライン完結のアプリ。
- 9. Trade-Offs and Alternatives ◻ インターネット接続はあるが最低限の場合 よく使われる機能はオフラインにする or クラウド側モデルの結果を後にも 再利用できるようキャッシュしておくなどの対応をする。 ■ Two-Phase Predictions ではあるが、フェーズ１の機能を限定的にする。 ＜部分的にオフラインの例＞ Google Maps のオフライン地図 Fitness アプリ 利用頻度の高い万歩計などの機能は、オフライ ンでも利用できるようにしておき、オンライン時に 過去の履歴の参照やレコメンデーションなどの フル機能を提供するなど。 よく使われる運転ルート表示の機能はオフラインでも 提供するが、歩行ルートや自転車ルートの表示機能は オンライン時に提供するなど。
- 10. Trade-Offs and Alternatives ◻ 同時に沢山の推論を行う必要がある場合 全てクラウドで処理するには負荷が大きい ■ エッジ側で事前の選別を行い、クラウド側の処理負荷を抑える。 ■ エッジデバイスでも複雑な推論を行いたいというよりは、 クラウド側の過度な負荷を避けるために Two-Phase Predictions を利用する例 ＜例＞ 工場でのセンサ値の異常検知 フェーズ１） エッジセンサー側でも 異常検知処理を行う 異常と疑わしき場合だけ クラウドにデータ送信 （定期的にやってくるセンサ値を全 てクラウドに送信するのは クラウド側の負荷大なので） フェーズ２） 複数箇所からのセンサ データを全て使って 異常の判定
- 11. Trade-Offs and Alternatives ◻ モデルの継続的な評価（Continuous Evaluation）を行う場合 データが常にクラウドに送られているわけでないので、推論のデータセットを定期的 にデバイス上に保存する。 ■ 再学習の必要性を定期的に評価する。 もしくは、エッジ側モデルの複製を（クラウド上にも）作成する。 ■ それを定期的に評価する。 ■ Google 翻訳などエッジとクラウドで似たようなタスクを行うケースが好ましい。
- 12. まとめ ◻ Problem 大きくて複雑なモデルの推論をエッジデバイスでも行いたい ◻ Solution 問題を２つのフェーズに分ける ■ フェーズ１）シンプルな推論をエッジ側では行う ■ フェーズ２）必要に応じて、より複雑な推論をクラウド側で行う ただし、問題がそのように切り分けられる場合 ◻ Trade-Offs and Alternatives エッジ側のインターネット接続が期待できない場合は、スタンドアロン版や 機能限定版の提供を検討する。 クラウド側の過度な負荷を避けるために本パターンを適用する（エッジ側で 事前選別する）こともできる。