アバナードが語る「エッジAI」の世界と試行錯誤のリアル【EdgeAIの基礎知識・活用事例付き】
アーカイブ動画
なぜ今、エッジAIに注目が集まるのか
アバナード株式会社
マネージャー リベル ジャンノエル氏
最初に登壇したのは、マイクロソフトとアクセンチュアのジョイントベンチャー アバナードで、Microsoft Azure基盤上IoTシステムの開発やエッジコンピューティングを活用するAIプロジェクトに携わっているリベルジャンノエル氏。
ジャンノエル氏は、まず今エッジAI(EdgeAI)がなぜ注目されているのか、その背景を説明した。近年、クラウドが一般化し、ハードウェアが進化したことで、IoT市場が拡大。その結果、エッジコンピューティングを使った、さまざまなIoTのユースケースが増加してきているのだという。
AIの進化においても、IoTやクラウドの浸透が大きい。AIの精度向上・利活用に必要なビッグデータやデータ基盤が整ってきたからだ。その結果、AIのユースケースも増えてきた。ジャンノエル氏は、AIエッジコンピューティングのマーケット調査事例を紹介し、次のように見解を述べた。
「AIエッジコンピューティングの市場規模は、毎年20〜30%で成長しています。この流れは、今後10年は続くでしょう。その結果、クラウドはより大きな市場になると考えています」(ジャンノエル氏)
エッジAIとは?基礎知識からメリット・デメリットまで解説
IoT分野における「エッジ(Edge)」は、ネットワークの境目を意味する。「エッジコンピューティング」とは、スマートフォンなどのデバイスが物理的に近い場所でデータの収集や処理、分析などを実現することだ。
ジャンノエル氏は、マイクロソフトが提供するサービス「Azure IoT Edge」を活用した実装事例も紹介した。以下図の左側が工場で稼働するロボットで、右側のIoT Hubがクラウド。中央はPCやRaspberry Piだ。同サービスを使えばクラウドを使うことなく、エッジデバイス上で危険予知などの監視や処理が実行できる。
一方、AIは人間の能力と行動を模倣する機械(ソフトウェア)であり、従来のように人がプログラミングすることなく、自動でタスクを実行する。機械学習やディープラーニングはAIに内包される概念であり、機械学習は主に「教師あり学習」「教師なし学習」「強化学習」の3種類に大別される。
機械学習においては、データを収集することがプロセスのスタートであり、「教師あり学習」前処理、学習、評価といったサイクルを繰り返すことで、精度を高めていく。ジャンノエル氏は、次のようにポイントを話した。
「大量のデータを集めたとしても、データの詳細が分からなければ、品質の高いAIを作成することはできません。そのため、アノテーションなどの前処理工程が重要となってきます」(ジャンノエル氏)
ジャンノエル氏は実際、どのような流れや仕組みでAIを作成していくのか。AIモデルについても、野鳥の画像認識を例に説明した。
モデルは、入力、隠れ層(Hidden)、出力という3つのレイヤーから構成され、各ノードがお互いにつながっている。人間の脳の神経回路構造を数学的に表現したニューラルネットワークに似ており、AIモデルを使って画像認識を行うとほぼ正解となる。
そしてエッジAIとは、AIのサブセットであり、ネットワークの端のデバイス上でAIのアルゴリズムやモデルを実行することを指す。従来はクラウド上でAI処理を行っていたものを、エッジでAI処理することでクラウド通信を減らし、リアルタイムに分析結果を返すことができる。
エッジAIのメリットとしては、エッジデバイス上で処理を実行するため、プライバシーが保護される、処理スピードが早い、通信費用が削減されることなどが挙げられる。
●エッジAIのメリット
1.データのプライバシー保護
2.リアルタイム性の向上
3.コストの削減
4.ネットワーク帯域の有効活用
一方デメリットは、クラウドに対してメモリやストレージといったリソースが制限される、ハードウェアのアップグレードが必要なケースが生じることなどである。
●エッジAIのデメリット
1.計算リソースの制限
2.ハードウェアのアップグレードの必要性
3.データの保存場所の制限
4.セキュリティリスク
カメラとAIモデルなどの技術を活用し、顧客の興味を可視化
アバナード株式会社
シニアコンサルタント 浦野 哲郎氏
続いて登壇したのは、Microsoft Azureを用いたシステム開発に多く携わるシニアコンサルタントの浦野哲郎氏。エッジAIを実際に活用した「興味分析」「みまもりくん」のソリューション例、それらを支えるAI技術の解説を行った。
1つ目のソリューション例として紹介されたのは、「顧客の興味の可視化」だ。例えば、量販店においては、商品配置や広告が効果的に顧客の興味を引いているのかどうか分からないという課題がある。そこで、顧客の興味をヒートマップなどで可視化する取り組みを行った。主に使った技術は以下である。
・ 顔の向き認識
・ 目線認識
・ 立ち止まり検知
・ 動作検知
興味の可視化においては、顧客の購入プロセスを「目に留まる」「足を止める」「手に取る」という3段階に分け、それぞれのプロセスのデータを蓄積することで進めていった。
例えば「目に留まる」では、カメラを使用して顧客の視線と顔の向きを検知することで、商品への興味推定を行う。カメラと顧客の距離が離れると情報量が少なくなるため、「棚単位でカメラを設置するなどの点に留意した」と、浦野氏は語っている。
視線検知では「GazeML」という技術を使い、まずは顔を検知する。その後、目を検知し、さらには黒目と白目の角度から視線を推定する。
顔の向き検知では「head-pose-estimation」なる技術を利用。こちらも最初は顔を検知、その後、鼻、目、顎など68つのポイントをランドマークとして抽出することで、顔の向きを算出していく。
浦野氏は、自宅で検証を行ったデモ動画も紹介した。左の画像が視線検知、右の画像が顔の向き検知であり、どちらも先述したフローで検知が行われていることがわかる。
さらに浦野氏は、アフターコロナの世界を想定したマスク着用での検証も実施している。結果は正面向きでは検知できるが、横向きになると鼻や顎、輪郭といった顔のランドマークポイントが取得しにくくなり、検知できないことがわかった。
続いては、「足を止める」プロセスだ。足を止めたタイミングや止めている時間といったデータを、先と同じくカメラ画像から収集する。
用いた技術は「DeepSort」という機械学習モデル。まずは人を検知する、続いて人の移動履歴から移動方向を推定する。さらには服装など個人の特徴を算出し、これらの情報を基に対象人物にIDを付与し、トラッキングを行う。
最後のプロセス「商品を手に取る」では、カメラを使用してデータを取得する。得た画像から、人の姿勢やポーズを判定して空間の座標を求める。
得た空間座標は、あらかじめ定義しておいた棚の座標をマッピングし、どの商品を見て、検討して最終的に手に取ったのかといった行動を分析していく。
利用する技術は、「ワールド座標変換」ならびに「3D Human Pose Estimation」だ。前者の技術で人がフロアのどこにいるかを特定。後者の技術では、2Dカメラの映像から人の骨格座標と奥行きを推定。3Dとして人の体の関節位置を推定する。
3つのプロセスを経て得られたデータから、興味のレベルを定義。さらには画像から年齢や性別などを予測し、それぞれの棚にどのような属性の人たちが、どれだけの割合で興味を持っているのかを、Power BIで可視化する。
浦野氏は、これらの取り組みを次のように振り返った。
「このように可視化されたグラフを活用することで、サービス提供者は配置した商品が狙い通りに興味を持たれているかを確認することができます。異なっている場合には、再配置を検討する活用を想定しています」(浦野氏)
迷子を見つけ出すエッジAIソリューション「みまもりくん」
続いては、迷子になった子どもを見つけるソリューション「みまもりくん」だ。利用方法は至って簡単。スマホアプリもしくは専用端末を使い、子どもの写真を事前に撮影し、名前や連絡先を登録するだけだ。
店内のカメラが子どもの位置を常に把握し、行動履歴としてアプリに適宜通知する。同時に、子どもが好む場所なども提示する機能を搭載している。
フロアのどこに子どもがいるか探すのは、ワールド座標変換技術を使う。さらには画像内の人の範囲や向きを認識するために、ディープラーニングモデルのPoseNetを使い、骨格推定を行う。
個人の特定は、個人の再識別(Person Re-Identification)を利用する。顔・身長・服装・到達できるエリアなどの情報から個人を推定したスコアを基に、マルチモーダル判断ロジックが最終的に対象人物であるかどうかを推定する。
浦野氏は同ソリューションのポイントを、次のように語る。
「このソリューションでは、個人を特定することが重要です。そのため、一つひとつの技術の推定精度は低くとも、組み合わせることで個人を特定していきます。例えば、服装や身長、顔の特徴といった条件のかけ合わせです」(浦野氏)
扱う対象が動画となるため、すべてのデータをクラウドに送り分析することは、パフォーマンスやネットワークの観点から現実的ではない。そこでエッジAIを活用しているという。
個人特定のフローにおいては、最初に撮影した個人の画像がクラウドにアップされて、特徴量を取得する。その特徴量をエッジ上のデータベースに同期し、推定を行う。つまり、AIの利用はあくまでエッジ上で行い、その推定結果を再びクラウドに送信している。
浦野氏は社内を店舗と見立てて行った実証実験のデモ動画も紹介し、セッションを締めた。
エッジAIを実装する際のアンチパターンと解決ポイント
アバナード株式会社
ディレクター 関野 学氏
続いては、IT業界20年以上のキャリアを誇り、アバナードではIoT+AIやエッジAIを活用したアーキテクチャ設計などに携わる関野学氏が登壇。エッジAIプロジェクトにおけるアンチパターンや勘所を解説するとともに、活用事例を紹介した。
1つ目のアンチパターンは、「AIの精度にフォーカスしすぎてしまい、ハードウェアの制約を満たせない」ケースだ。関野氏は次のように語る。
「ニューラルネットワークのサイズはGPUのメモリと関係するため、注意する必要があります。AIの精度と性能はトレードオフの関係にあることを、しっかり押さえておきましょう」(関野氏)
実際、精度の高いAIが作成できたにも関わらず、動作しないことはよくあるという。AIや演算スピードに合致したエッジデバイスを選択することも重要だ。例えば、演算は毎秒行うのか、10秒毎なのか、それとも30秒毎なのかといったことで変わってくるからだ。
推論を複数行う場合には、それぞれのモデルが利用できるメモリの上限を制約する。あるいは、複数のエッジデバイスを用意する手法もあるという。その他に、そもそもDNN(Deep Neural Network)のような重い処理が必要なのか。OpenCVなどの軽いライブラリで代用できるかどうかを検討することも必要だと語った。
2つ目のアンチパターンは、「学習や検証データの品質や量に対する意識の低さ」である。エッジAIを作成するためには、データが必要だ。一方でデータの量が不足していたり、クオリティが低かったりすると、AIモデルの学習精度は低くなる。結果として、エッジAIシステムのパフォーマンス低下につながる。
Data Augmentationなどで増やすことには限界があるため、対策としては純粋なデータの量をしっかりと確保すること。かつ、正しくアノテーションすることで、クオリティの高いデータを用意することが重要だと解説された。
3つ目のアンチパターンは、「AIモデルを作ったままの状態で、いつまでも使い続けること」である。状況は日々変化しているため、リリース後は定期的にAIの精度をチェックする必要がある。精度が下がっている場合は、再度新しいデータで再び学習できるような仕組みを検討しておくことが重要だと語った。
TensorFlow、Paper With Code、OpenCVを活用する
モデルの選択については、「TensorFlow」といったライブラリや、さまざまなタスクに対して、トレーニング済みのモデルが公開されている「Model Zoo」。これらのサービスを利用し、自分が行うタスクと照らし合わせながら、最適なモデルを選んでいく。
さらに関野氏は、各種タスクに対してベストな成果を出すモデルや、実際に活用できるコードも掲載された論文が閲覧できる「Paper With Code」というサービスも紹介した。ただし、「商用利用の際はライセンスに注意する必要がある」と補足した。
AIの精度を左右するデータの収集については、主に以下3つの手段がある。
1.公開されているデータセット
2.自分自身でデータを取得する
3.データを生成する
こちらも関野氏はモデルと同様、公開されているデータセットを活用することを推奨。こちらも商用利用可能かどうかなど、ライセンスに注意する必要があると説明した。
「自分でデータを取得して、Data Augmentation(データ拡張)を行っても限界があるからです。シミュレータなどでデータを生成することもできますが、リアルとのギャップがあるので注意が必要です」(関野氏)
また、Data Augmentationは闇雲に行うと逆に精度を下げてしまうケースがあるため、そのような変換は避けるべきだという注意点もある。
続いて、モデルの速度や精度、ハードウェアやクラウドといったデバイスとの関係性における考慮事項が説明された。端的にいえば、Raspberry PiやJetsonといった軽量なハードウェアでは、準じてモデルも小規模となる。
一方でエッジデバイスではなく、クラウドでAIを使うことも可能だ。その際はデバイスもモデルもある意味無限に使えるが、ジャンノエル氏が説明したように、レイテンシや使用する帯域幅といった問題を考慮する必要がある。
活用事例として、OpenCVなどのライブラリを利用した画像処理が紹介された。例えば、以前は目の不自由な人が使用している白杖の検知は、ディープラーニングを使って行っていた。しかし、似たような形状のビニール傘との判別が難しく、ニューラルネットワークの性能を上げたり、データ量を増やしたりなどの取り組みを行ったものの、満足のいく精度は得られなかった。
そこで発想を変え、AIだけで判定するのではなく、事前に画像処理を行うこととした。その際にOpenCVのライブラリを活用した。画像解析技術を組み合わせたことによって、精度は飛躍的に高まったという。
関野氏は、エッジAIを活用したスマートストアの今後の可能性と利用技術についても紹介した。以下図のCXは顧客体験、WXは従業員体験である。
例えば「➁顧客エンゲージメント」や、「③誰もが安心快適な店舗に」といった活用は、まさに浦野氏が紹介した内容でもある。さらには欠品検知やヘルプ要請など、従業員の現場負担の軽減にも寄与する。
関野氏は最後に次のように述べ、セッションをまとめた。
「エッジAIは楽しく、奥深いと考えています。デバイスという目に見えるものに携わることができ、AI、ハード・ソフトウェア、クラウドなどの実装に必要な技術領域が広い。自然とフルスタックエンジニアに成長できます。将来性のある分野なので、わくわくしています」(関野氏)
【Q&A】参加者からの質問に登壇者が回答
セッション後は、イベントを聴講した参加者からの質問に登壇者が回答した。
Q.環境による性能差への対策は?
関野:どのような環境でどのような差が生まれるのか、事前に調べておきます。例えば店舗では、朝昼夕といった時間帯で光のトーンが変わりますし、電球と太陽光でも異なってきます。このような異なる環境の中で、どれだけ認識精度を保つことができるのかは、OpenCVなども活用して許容するコントラストを決めたり、調整したりしています。
Q.人物特定はフレームアウトや数時間後のフレームインでも認識されるのか
浦野:短時間でのフレームアウトは問題ありません。数時間後に再登場するシーンについては、特徴量をどこに保存しているかなど実装の条件によります。基本的な考えとしては、時間が経過しても認識できる仕様となっています。
Q.エッジデバイスに格納されたデータを定期的にクラウドにアップすることは可能か
ジャンノエル:実際よくあるニーズですし、考えられる手法です。ただ、なぜそもそもクラウドにデータを送らなかったのか、帯域幅やネットワークコストを考慮する必要があります。ただし、ネットワークがあまり使われていない夜間などにデータを圧縮し、クラウドに送るといった手法は考えられます。
時間内に回答できなかった質問に対しても、後日に登壇者が回答した。Q.Azure Cognitive Services を IoT Edge Runtime(Azure Stack Edge) で使用するより DeepStream の方がいいと考える理由は何でしょうか
IoT Edge Runtime+Azure Stack Edge Pro(with GPU)にCognitive Servicesでコンテナ化したAIサービスをエッジ上に配置することは簡単です。複数のモジュールを乗せられるため複雑なユースケースを対応できます。クラウドから一括でデバイスの管理と運用ができることは大きなメリットです。 デモ紹介のLive Video AnalyticsエッジモジュールはDeepStreamのパイプライン管理モジュールのような仕組みを提供していたが、このEdgeモジュールは使えなくなったため映像パイプライン処理の管理は自前で作成するか、他の技術を導入するか検討する必要があります。
DeepStreamは単品であるサーバー上で配置できます。 配置先のハードウェア面で選択可能なGPUの種類が多く、GStreamerをもとに作られているのでオープンソースのプラグインを導入することも可能です。その分、運用やAIモデルの学習と配置管理は大きな負担になります。 GStreamerのおかげで画像処理のためにできるだけ処理パイプラインを最適化しているため、画像処理が多い、あるいは高いFPSで推論したい場合に、このアーキテクチャーに目を向けて検討します。
IoT Edge Runtime+Stack Edge+Cognitive Servicesの組み合わせをNVIDIAのテクノロジースタックに置き換えると、例えばDeepStream+Jetson+Metropolisをまとめて検討したほうがおすすめです。 Azure IoT Edge+DeepStream+Jetsonのようなハイブリッドな技術基盤も検討すべきです。
Q.Deep Streamでできる代表的な事例としては、「画像識別による意思決定」といったところでしょうか?そのほかあれば教えていただけますか。
個人的に知っている限り、DeepStreamは画像処理と画像認識のタスク処理パイプラインに特化しています(Gstreamerをもとに作られている)。
画像ストリームを効率的にパイプラインの中に管理しているの比較的に少ないリソースを使って画像処理を行います。
いくつかの実装例はDeepStream SDKのサイトに提供されています(主に画像処理)。
https://docs.nvidia.com/metropolis/deepstream/dev-guide/text/DS_ref_app_github.html
映像に限らず、他のセンサーデータのストリームも取り扱える(例:音声データ)、そしてGstreamerの拡張プラグインを使っていくつかのタスクを処理パイプラインに埋め込むこともできます(例:音声認識)。
それぞれのプラグインの特徴を使って、どんなパイプラインを作れるかをまず検討すべきです。
https://docs.nvidia.com/metropolis/deepstream/dev-guide/text/DS_plugin_Intro.html
DeepStreamフレームワークに提供されない処理は個別で開発し、DeepStreamのパイプラインの中に導入することも可能です。
Q.興味レベルと実際の購入との相関も分析されているのでしょうか?
紹介したソリューション例の興味分析機能をもとで回答すると、仮にこのような購買プロセスのファネルを定義できます。
(①目に留まる>②足を止める>③手に取る>④購入する)
・④のデータはPOS・レジのシステムに格納されています。特定できる商品に対するどのぐらい販売されたかわかります。場合によってお客様も特定できます(ポイントカード利用)。
・①~③は同じ現場のシーンであり、同じお客様と思ってデータを蓄積できます。このデータは特定できる商品はどのぐらい興味持たれたかを表現します。お客様の招待がわかりません。
別々でこの二つのデータソースを分析することがもちろん可能であり、場合によって店舗が知りたいことに対する充分な情報になります。
例えば、次のような分析が可能:
・一般的に、特定できる商品はどのぐらい興味持たれて、何割は実際の購入につながったか
・一般的に、購入にならなかった商品はどんなステージにこの商品に対する興味失われたか
この状況だと、①~③のシーンと④のシーンに両方のアクションを起こしたお客様は同じ人を確実に判定できないため、ユースケースによって「興味を持ったお客様」と「購入をしたお客様」が同じ人であることを特定したければ既存のデータは不十分です。 この情報ギャップを埋めるために、一つの可能性としてみまもり君に紹介した物体追跡技術を使うことができるが、このセットアップを実現するために必要なカメラ台数と計算能力が大きく変わります。
Q.実店舗等での実証ではエッジデバイスでちゃんとデータを取得/AI認識できているか否かの判断など、どの程度モニタリングされましたか?期間中はずっと人が張り付いて確認されていましたか?
一つの機能に絞って説明させてください。複数のカメラをまたいで同じお客様を判定するために物体追跡技術とReIDの仕組みをみまもり君のソリューション例に紹介しました。 歩きながらカメラ1の視野からカメラ2の視野に入ったお客様はカメラ1からアサインされたIDとカメラ2からアサインされたIDが異なることをログ上で確認できました。 ログ管理をすることによって、個人の再認識に問題があるとわかることができて、対策を取れました。
このログ情報はエッジデバイスからクラウドに同期するおかげで、この分析は場所関係なく実現できます。 この問題分析を行うために、どんな情報をログとして取得する必要があることも重要なステップです。 映像の実データをこのままクラウドに送信できるか、または小売り店舗のシナリオだとプライバシー保護のためにエッジ側でログデータのマスキングしてからクラウド同期するか、こういう大事な点をケースバイケースで検討する必要があります。
Q.興味の可視化技術は、スーパーなどで発生する万引きの事前防止にも利用できそうですか?
技術的も倫理的も課題豊富なユースケースですが、技術的の観点だけで考えると不審な行動の判定や検知は実に難しいタスクです。たしかに行動検知を実現するために興味分析やみまもり君のソリューション例に紹介した技術の組み合わせが使われるでしょう。(この一覧に限らず:ワールド座標変換、動作検知、物体追跡、ポーズ推定、顔や視線検知)。
これらのAI画像処理技術だけでなく、カメラだけでなく他のセンサーも使ってより正確な判定ができるように検討する必要があるかと思います。
おそらく完全自動も考えづらいため、HITL(ヒューマン・イン・ザ・ループ)的な仕組みを設計し、対応性の高めるため人間がシステムの中に組み込まれるようにするでしょう。
Q.他の方も質問されていますが、環境による精度差に対してどのような対策をされていますか?
「物理的な現場」の意味も、デバイスとしての「実行環境」の意味でも精度差が生じると説明しました。
実行環境の件を解決するために、できるだけ同じハードウェアを使ったほうが管理しやすいです。例えばハイスペックエッジデバイスに要件を満たす精度で実行されるAIモデルを小型エッジデバイス上に実行させる場合、HWのスペックにフィットするためにモデルの圧縮技術を使ってもいいがもともとの精度を再現しない可能性があります。サービス提供者としてHWの要件を固めると一定精度が担保しやすいです。もし推論環境はスマホである場合、デバイス毎のにAIモデルの精度検証する上に、要件を満たさない機種のためにモデルのチューニング(学習)を検討することも可能です。
物理的な現場の意味だと、店舗Aと店舗Bに同じエッジAIソリューションを設置してもなぜかある店舗に精度がよくない場合があります。原因を特定してから、現場に合わせてハードウェアとソフトウェアのチューニングを行うことはよくあります。カメラの例でいうと、カメラの設定もある程度設定できる、できない場合にエッジデバイス側にこのカメラの映像ストリームの前処理を推論処理の前段階に挟むことも考えられます。もう一つの対策方法は精度が低い現場のセンサーからデータを取得して、このデータをもとにAIモデルの再学習するとより良い制度を得られる見込みです。予想外または変動のある状況(場所、時間帯、天気など)様々な要素があって、もともとAIモデルが学習しなかったパターンがあるので誤検知が発生します。この誤検知ケースの永続化と事後分析は大事なステップです。
多数のモデルの配置先の管理、誤検知のデータ収集と継続的な再学習、この二つの運用作業をささえるためにMLOpsの概念を取り入れることが不可欠かと思います。
Q.幼稚園バス,置き去りにもみまもり君は使えますでしょうか?
みまもり君に使われている技術は主にRGBカメラの画像処理です。 バス車内にカメラとエッジデバイスを設置して、みまもりくんと同様な概念と技術を再利用したソリューションを想像できます。(主に物体認識技術を活用する)
ただしそのままだとどのぐらいの精度が出るかは完全に不明です。もともとのみまもりくんソリューションが設計されている現場がことなるため、AIモデルの精度を高めるためにバス車内の映像データを使ってモデルの再学習を行うとよりいい精度の期待ができるでしょう。
最後、RGBカメラでけでなく、このタスクのためにもっと適切なセンサー技術はないか、あるいはカメラ+その他センサー技術の抱え合わせでさらに良い精度を得られないか検討してもいいかと思います。センサー技術に合わせて導入コストも運用コストを同時に検討すべきです。
例えば真っ暗な駐車場だった場合に通常のカメラセンサーだけで車内監視できなくなるので、IRカメラあるいは人感センサーも検討すべきかと思います。そういう検証はAvanadeの中でもあって、公開される一例のリンクを紹介させてください。
https://note.com/avakansai/n/nf277aa0ebdb0
回答を深めるために5月末のこのTECHPLAYイベントも参考になるかと思います。
https://techplay.jp/event/901189
Q.興味分析のところで、消費者の目的意識が違うと、行動の意味も変わるかと思いますが、そういう部分も考慮されていたりするのでしょうか?例えば、何か明確に買いたいものがあって、それを探している場合、立ち止まって見ていても、目当てのものを探してる探しているだけで、 その棚のものに興味を持って立ち止まって見ている人とは行動が変わると思いますが、そういった識別もされてるのでしょうか?
紹介した興味分析のような仕組みは消費者一人一人の分析より、平均的な行動パターンや主なペルソナを抽出・メトリック化するためによく使われています。消費者のエクスペリエンスを最適化するためにこれらのメトリックを使って店舗の中に実験をおこして、効果をははかりながら繰り返し改善していきます。
消費者の外観や行動の記録データをもとに、行動のパターンをグルーピングすることはできるが、それぞれ行動の意味にを把握するために独特な行動パターンでない限りほかのデータを加える必要があるかと思います(例:消費者アンケート、ポイントカードやオンラインショッププロファイルとの連携)。
消費者の購入意図は確かに外観だけで理解することが難しいです(ベテランの店員だったとしても)。 ただしこの意図は消費者の外観や行動に現れる要素、監視できるヒントがあればその分析の可能性があります。例えば動線分析と棚の前の興味分析の抱え合わせで、別々で得られたデータからより正確な行動パターンを集計できる可能性があるかもしれません。
Q.AIのソフトウェアテストはどのように実施されてますでしょうか
AIプロジェクトのために必要なものが複数あります。各項目に対してテストできる項目を何種類まとめます。
・AI学習と評価スクリプト:AIモデルを学習するモジュールはもともとコードでできている場合、最低限にコードの単体テスト、要件次第静的解析やシンタックスチェックのテストをする(例:Pythonだとpytest, pylint, mypy)
・AIモデルを利用するプログラム(推論側):どんなソフトウェア開発プロジェクトにあるテスト活動はここに適用される上、サービスのコードとAIモデルの結合を検証するテストも入れるべき
・モデル学習処理を支えるモジュール:(例としてデータ前処理、後処理、配置スクリプトなど)これらのモジュールはデータ処理やAI学習パイプライン、または配置パイプラインにも利用されるため、カスタムコードである限り最低限に仕様を担保する単体テストを作る
・データ:ソフトウェアではないがデータはAIモデルの仕様にもっとも影響するものであり、データを検証する仕組みも導入するとより良い精度のモデルを作る(例:責任あるAIの概念を基づくデータ品質確認)
・セキュリティ検証:実装したコードや使ったOSSや外部レポジトリからのモジュールは安全であることを確認するためにコードの脆弱性(外部モジュールも含む)をスキャンするテストも入れるとよりセキュアなAIサービスを提供できる
・いきなり本番環境に最新版AIを配置しない:段階的な配置戦略をちゃんと決めて品質担保のプロセスを通してからリリースする(ソフトウェア開発同様な考え)
たくさんの項目になるので、できるだけ自動で行うべきかと思います。そのためMLOps概念の導入によって、上記のテストはコードパイプライン、学習パイプライン、データ処理パイプラインを自動化し、総合的に管理できるようになります。