TechPlayのEdge AI Deep Dive講演のまとめ
こんにちは!ソフトウェアエンジニアリング部門のジャンノエルです。所属しているアバナードのチームと主にIoTとAIプロジェクトに取り組んでいます。
先月4月13日、Edge AIに関するTechPlayイベントを共同で講演しました。この登壇では、Edge AIの概要を説明しながら視聴者に興味を持たれたいくつかのポイントについても触れたいと思います。
講演は終了していますが、イベントページはこちらです。
https://techplay.jp/event/895243
Edge AIとは何か
Edge AIは、AIのサブセットで、ネットワークの端のデバイス上でAIアルゴリズムやモデルを実行することを指します。これにより、常にインターネット接続が必要でないか、クラウドにデータを送信することなくリアルタイムの意思決定やデータ処理が可能になります。 Edge AIデバイスの例としては、スマートフォン、スマートカメラ、ドローン、IoTデバイス、PCやサーバーなどがあります。
エッジデバイス上で処理されることにより、データのプライバシー保護が確保され、データ処理が高速になり、データ通信やクラウドの費用が削減され、ネットワーク帯域幅が有効活用されます。
一方、エッジデバイスの制限として、クラウドに比べて計算リソースが制限されており、適切なハードウェアが必要であること、データの保存場所が限定されているため、データのバックアップや共有が難しいこと、そしてセキュリティリスクが高いことが挙げられます。
エッジAIは、物体認識、音声認識、異常検知、予知保全など、さまざまな用途に活用することができます。また、医療、運輸、製造、小売などの業界で、効率化やコスト削減のために活用することができます。
Edge AIの構築を始めるための一つの方法
Azureのようなクラウドプラットフォームに提供されるサービスやフレームワークを活用して、より早く実装できます。
Azure IoT Edgeを使用すると、「Azure Cognitive Services」「Azure Stream Analytics」「Azure Functions」などのAzureクラウドワークロードをコンテナ化し、Raspberry Piから産業用ゲートウェイまで、さまざまなデバイス上でローカル実行させることができます。
「Azure Cognitive Services」から提供されるAI搭載済みコンテナはいくつかあるので、詳しくはこのリンクにご参考ください。
Azure IoT Edge は、 ビジネスロジックを標準のコンテナーにパッケージ化して IoT ソリューションをスケールアウトし、それらのコンテナーを任意のデバイスにデプロイして、クラウドから監視できます。エッジ↔クラウドの双方向通信も可能です。
これから紹介するEdge AIソリューションのように、IoTプラットフォームを使うことによって、開発・配置・管理・スケール化をしやすくなります。使ってみたい方にこのチュートリアルをおすすめします。
Edge AIソリューションの一例
今日ご紹介するのは、みまもりくんというソリューション例です。ショッピングモールや遊園地などの広い場所で、子供やお年寄りなど迷子になった人(POI=person of interest、対象人物)を見つけることを主な目的としています。これは、カメラや映像解析技術を多用し、エッジにAIを配置したソリューションです。
ソリューションのメインフローの概要です:
写真と簡単な情報(名前、年齢、サイズ)を使って、POIは施設に入る直前にシステムに記録される。
施設に入ってから、介助者が注意していたのに、気づいたらPOIの場所がわからなくなった、という事件が発生する。
その場合、スマートフォンアプリのみまもりくんを使って、地図上でPOIの最新の位置を知ることができる。
それでも足りない場合は、ワンタップで店員に助けを求めることができ、スマートフォンやスマートウォッチなどな端末経由スタッフはPOIの最新位置と写真が入った通知を受け取るイメージである。
この簡単なフローから細かいことを削除させていただいたが、実はさらに、データプライバシーや法的要件に関連するフローを追加で対応する必要があります。
ここでは、このシナリオを実現するための技術を紹介します。
Edge + AI:処理のリアルタイム性確保および、演算リソース最適化のため、各Edge上にてAI処理を動作させる。デプロイや更新なども可能なようにAzure IoT Edgeソリューションをベースとする。
Cloud ⇔ Edgeデータ同期:アプリで設定した対象の画像をクラウド上で特徴量取得、本特徴量をEdge上のDBに同期。Edge上でAIを用いて推定した最終推定結果をクラウドに送信。
モバイルアプリ開発(Angular + Ionic):モバイルアプリは今後のマルチプラットフォーム化を見据えて、マルチプラットフォームに対応したフレームワークを採用。
マルチモーダル判断ロジック:下記のさまざまな、推定処理のスコアをもとに、対象人物である可能性を導く。
推定処理の一覧を紹介します。
ワールド座標変換:画像の中のある地点の座標を取得し、フロア平面の座標に変換する仕組みを実装。人物がフロアのどこにいるかを特定する。(ARマーカー事前設定)
骨格推定:カメラ画像から、人物の骨格推定を行う。人の向きや画像内の人の範囲を認識。(PoseNetと呼ばれるモデルを利用)
個人の再識別(Person Re-ID):各個人を識別するための特徴量の取得。各個人の全体画像をもとに人を識別するためのAnnotationおよびその特徴量を取得。
顔識別:顔が取得できる場合は、顔情報をもとにランドマークなどから特徴量を取得。マスクをしたままの特徴量を取ることで、マスク状態の顔識別を目指す。
身長推定:カメラ画像上の対象人物の大きさと、カメラの画角、およびワールド座標の関係から身長の推定を行う。
各体パーツごとのヒストグラム分析:各体のパーツ(服が存在する部分)のヒストグラム(色相・彩度・明るさなどの分布)を取得(ヒストグラムを特徴量として取得)
最終地点から現在地点の移動可能性:最後に対象人物がいたとされる地点から、今回の対象地点までの距離をもとに移動可能か判定(走っても時間内に到達できないなど)
重要点なのは、マルチモーダルアプローチの使用です。それぞれの手法を単独で行うと、十分な推論結果が得られませんが、複数の手法を併用することで、全体としてより高い精度が得られます。群衆の中でPOIを探す場合、以下のようなプロセスパイプラインを作成し、可能性を絞り込むことができます。
このパイプラインでは、AIと従来の画像処理技術をミックスしています。骨格推定、個人の再識別、顔識別のような技術は、AIモデルを使用して予測を出力します。一般的にエッジコンピューティングは、センサーの性能よりも優れた計算能力を提供しますが、同時に実行できるAIモデルの数、精度、処理速度の間で妥協しなければならない点があります。
私たちのソリューションでは、分散型エッジコンピューティングアーキテクチャを採用し、AIワークロードの一部は、メインのエッジデバイスからLAN経由で到達する専用のエッジデバイスに展開されることになりました。
このソリューションアーキテクチャのデメリットの1つは処理速度でした。1台のEdgeデバイスに複数のカメラストリームが入り、このソリューションを実装するためのGPUアクセラレーションを搭載したEdgeデバイスの数は限られていました。
ハードウェアの強い制約がある場合、ソフトウェア側のスケールダウンで補うことができます。やったことは、各カメラフィードを5fpsで処理する代わりに、1~2fpsにスケールダウンすることで、1台のEdgeデバイスで4台のカメラを相互利用できるようにした、ということです。このスピードは、今回のシナリオでは十分でしたが、別のコンテキストでは、精度を制限する要因になる可能性があります(例えば、高速で移動するPOI)。
複数のAIモデルを動かすためのハードウェアを相互利用することも課題です。それは、使用するAIフレームワークによって管理することができます。AIモデルは、もともと専用基盤で動作させることを前提としているため、必要以上なGPUメモリやリソースを事前に確保しておく傾向があります。フレームワーク設定や実行環境の実験を行うことで、必要な数のリクエストに対応し、GPUとメモリーのリソース消費を抑えることができるよう、ソリューションを微調整することができました。
その結果、メインフローに説明しいてように、みまもりくんアプリのユーザーには、同行していたPOIが迷子になったと気づいた十数秒後、POIの最終的な位置が通知されるようになりました。
追加検討事項
このようなソリューションを構築する場合、以下のような罠に陥りがちです。よりスムーズなリリースを実現するために、ぜひ念頭に置いてください。
最初はAIの精度を重視しすぎて、Edgeにデプロイしたら精度の高いAIがハードウェアの制約を満たせなくなることに気づきがちです。特に制約のある実行環境では、すべてがバランスの問題なので、ターゲットとなる実行環境向けのAIを構築することを優先したほうがよいでしょう。
AI学習におけるデータの質と量の重要性を過小評価しないでください。これはAIモデルの精度に直結するため、データの準備に十分な時間やコストを割く必要があります。場合によっては、この活動だけでプロジェクトリソースの80%を占めることもあります。すぐに使えるデータセットやデータ補強のテクニックは、この問題に役立つかもしれません(例:Googleデータセット検索、Azureオープンデータセット、Kaggleデータセット、など)。
すべてのAIモデルは陳腐化するということを忘れないでください。AIモデル学習時に達成した精度は、現場で使用すると時間とともに低下していきます。そこで、リリース後もこの指標を継続的にチェックし、できれば現場からの新鮮なデータを使ってAIモデルの再トレーニングを容易にする仕組みが必要になります。MLOpsは、この問題に対する一つの答えになり得るものです。
アプリケーションに統合するためにすぐに使えるソフトウェアライブラリを提供しているのと同じように、AIモデルもすぐに使えるものがいくつかあります(オープンソースまたはプロプライエタリ)。独自のモデルを開発するのではなく、そのようなモデルの1つをベースにするのがよいでしょう。作りたいAIモデルのタスクを定義してから、同じタスクが既存のモデルですでに処理されているかどうか、また公開ベンチマークでの精度を「TensorFlow Model Zoo」や「Papers With Code」のウェブサイトで確認します。多数のユースケースでは、基礎的なモデルを使用することが望ましいです。
最後に
この投稿で、Edge AIとは何か、どのような考察が必要なのか、あるいはこの分野に携わることに興味を持っていただけたなら幸いです。私たちはすでにAIの時代に生きており、技術的なエコシステムは今ほど豊かなものはなく、驚くほどのスピードで改善され続けています!
この分野で多くのオポチュニティーや発見があることに感謝しつつも、ITという業界はまだまだ正しいやり方を学ばなければならないと個人的には思っています。30年前のソフトウェア開発の産業化と同じように、AI開発についてITはまだまだ進化していかなければなりません。
最後になりましたが、このブログを書くにあたって、AOAI(Azure OpenAI)サービスのGPT4モデルに助けられ、この記事の一部を書きました。AOAIのGPT4モデルは、Azureのサブスクリプションさえあれば、データとプライバシーを保護しながら編集速度を向上させることができる優れものだと思います。
Microsoft、Azure、Azure Cognitive Services、Stream Analytics、Functions、Azure IoT Edge は、米国 Microsoft Corporation の米国及びその他の国における登録商標または商標です。
Raspberry Pi は、英国 Raspberry Pi Ltd の英国及びその他の国における登録商標または商標です。