はじめに
昔作成した継続的画像認識モデル作成のためのアーキテクチャをSORACOMベースで考え直してみました。基本的にはSORACOM Fluxで画像認識をすれば事足りると思いますが、ユースケースに特化した画像認識モデルを作成したかったりするとLLMの出力に左右されてしまいますし、画像データはSORACOM内でずっと貯めておくことは難しくコストもそれなりなので、Google Cloud側で画像データを貯めることを前提としたアーキテクチャを考えてみました。試していないので、参考程度に。
SORACOM Fluxをかませることで、通知やダッシュボードはSORACOM内で完結することができるので、もし画像認識モデル構築をやめたくなってもGoogle Cloud側のリソースを破棄すればそのまま使用できることも可能です。
アーキテクチャ
以下はアーキテクチャの図です。簡単に説明すると、以下のような感じです。function構成は定義変更する可能性があるので、ふわっとした図にしています。
- ソラカメから画像データを取得
- SORACOM Fluxで画像データを転送
- Cloud Run functionsで画像データを保存
- スケジューラー起動で、Cloud Run functionsより画像データをVertex AIにインポート
- Vertex AIでモデルトレーニング
Cloud Run functions用にプログラミングが必要になりますが、今のAI時代だと簡単に実装が可能だと思います。その他の機能に関しては大体SORACOM側の機能で完結することができます。
インポートをスケジューラー起動にした理由ですが、データセットの中のデータを全てアノテーションしないとモデルトレーニングができないため（今はどうだろ？）、モデル更新サイクルを早めるためにスケジューラー起動でインポートするようにしました。
SORACOM Fluxをかませるなら、それで画像分類すればよいユースケースの方が多いですが、これは「特定用途に特化した画像認識モデル」を作成したい場合に有用です。LLMが前段で不要なデータをはじけるので、すべてをアノテーションする必要がなくなるため、省力化できます。もしかすると、それにより過学習状態になることも考えられますので、ある一定の利用ケースを絞った方が良いかもしれません。定期的にソラカメから画像データを取得するFaaS関数を、クラウド上で処理する前提の構成にするとよいと思いますが、そうするとマイルドさが減ってしまうと思うので、塩梅は考えどころですね。
おわりに
こんな感じで、Google Cloud側で画像データを貯めることを前提としたアーキテクチャを考えてみました。試していないので、参考程度に。
Discussion