ハイブリッド学習時代にそなえる、定量データ解析AIのためのエッジデバイス活用パターン

Deep Learning / Machine Learning Edge Computing Mobile App
このエントリーをはてなブックマークに追加 follow us in feedly

まえがき

R&Dチームの徳田(@dakuton)です。本ブログの副編集長を兼任しています。普段の業務では機械学習などを用いて定量データの解析を行っています。 今年の6月に、Androidのイベント(ABC 2018 Spring)でエッジデバイス(主にモバイル)に関する機械学習の動向についてお話させていただきました。 今回はこちらのアップデート版として、ここ数ヶ月での取り組みについて軽く紹介したいと思います。

エッジ学習の利用目的と課題

利用目的

主に以下の3点です。

  1. クラウド側にかかる計算リソースの分散
  2. ネットワーク転送コストの高いデータ送信を回避(音声データなど)
  3. プライバシー保護

課題

たとえば3に関して、米国においてApple WatchでECG(心電図)が取れるよう準備中との情報もありますが、クラウドでの処理は技術的な面以外での障壁があります。 バイタルデータというのはセンシティブな情報であり、クラウドによるデータ収集を行わずとも予測実行できることが好ましい一方で、ECG(心電図)データはユーザーごとに個別の信号データを用いた学習・推論を必要とします。

現時点でもCore MLやFirebase ML Kitなどのように、エッジ向け機械学習を実現するフレームワークも登場してはいますが、画像・テキストデータ向けに学習済みモデルの推論を行うために用意されている(エッジ側でのweight更新は行わない)ものであり、上記のようなプライベートデータに対する学習を行いたいケースでの使い勝手はまだ良くありません。

クラウド/エッジ両方でのServing構成例

クラウド/エッジそれぞれでのハイブリッド学習・推論を行うための環境として、以下図のような構成でModelの分散Servingを行う環境を構築しました。データの種別や解析量に応じてクラウド/エッジ(ブラウザ)に振り分けようというのが本構成のねらいです。

既存ModelとしてKerasを用いて時系列データ予測を行うModelを作成していたため、本紹介ではKerasを用いていますが、後述のとおりそれ以外のフレームワークでもServing環境を作成することは十分可能です。

f:id:optim-tech:20181203202301p:plain

コンポーネントごとの役割と実装方法は以下のとおりです。

Prediction Builder

特定の予測Modelテンプレートからハイパーパラメータ探索を実施したModelを生成します。Kerasの場合、ハイパーパラメータ探索には例えばhyperasを用いるとシンプルに実現できます。

Prediction Serving

Builderで作成したModelを実行します。エッジ(ブラウザ)実行用Modelの変換もここで受け持っています。 ModelServerの先駆けでもあるTensorFlow Servingだとデータ交換にはgRPC(or RestfulAPI)を利用することができますが、TensorFlowモデルを動かすところに寄りすぎているため、一旦はFlaskを用いてJSONベースのREST APIだけ作成しています。

なお、ユーザー数が増えた場合の処理スケーリングにあたってはバックエンドの待ちうけ部分にMessage Brokerをおき、Dockerコンテナ等のServing環境として作成しFrontendからの要求を実行するようにすべきですが、ここはなくても動かすことは可能なので図からは外しています。

Prediction Handler

解析したいデータの通信量を抑えたい場合や、プライバシー観点上Serving側に直接データを送信したくない場合はTensorFlow.jsでブラウザ実行用に変換したModelをダウンロード・インポートし、エッジ側で学習・推論を実行させます。 エッジ側での処理がまかないきれない場合は一般的なModel Servingと同様、Serving側にデータを送信して推論結果を得ます。

その他の構成例

  • ONNXにおける機械学習フレームワークの相互運用性を活用して、TensorFlow/Keras以外のフレームワークについてはMXNet向けのModel ServerとONNX.jsを組み合わせることで似たような構成をつくることが可能とみています。
  • モバイル向けでのエッジ実行には利用できませんが、クラウドとエッジのストリーミング分散学習について言えば、UberのMichelangeloとHorovodを利用した例が挙げられます。
  • エッジ側を逐次学習に割り当てない(推論専用として利用する)のであれば、KubeflowのData Pipelineに則った構成が今後増えると予想しています。(概念としては整理されていますが、それを実現する要素としてはまだ不足分がみられます)

おわりに

ブラウザ上での学習・推論についてはまだまだ実行速度として課題が残るものの、TensorFlow 2.0のTensorFlow.jsアップデートではWebGPUやWeb Assembly対応など高速化が予定されており、パフォーマンス改善が期待できます。

また、学習より前の段階として、エッジで収集したデータのクレンジングについても対処が必要となるため、こちらはKubeflowの対処状況をみながら検討したいと考えています。

オプティムでは、クラウドだけでなくエッジデバイスを駆使したデータエンジニアリングにより社会課題を解決したい人を募集しています。興味のある方いましたらぜひよろしくお願いします。 www.optim.co.jp