AWS Lambda で動く、プロンプトライクな物体検出システム

「十分に発達した科学技術は、魔法と見分けがつかない。」とアーサー・C・クラークは言い、「テクノロジーは自転車のようなもの」とスティーブ・ジョブズは言ったそうです。

まるで思春期のように成長する AI は、さながら「魔法のようなもの」になりつつある昨今ですが、「それに乗ってどこへ行くのか ?」という内なるジョブズの囁きもまた、無視できないわけです。

私たちのワガママは下記のような限界に達していたのです。

1. プロンプトライクで検出対象を柔軟に表現できること
2. 検出矩形は正確な座標で取得できること
3. CPU で軽快に動くこと

この極まった要望の実現のため、ペダルの付いた魔法である SAM と CLIP を採用することにしました。

SAM は非常に優れたセグメンテーション技術です。私たちは「特になんの指示をすることもなく」、部屋画像の中から物体を切り出すことに成功しました。残った課題は、切り出された画像たちが、私たちの興味のあるものなのかどうか ? という問いでした。

このコンビネーションは一撃で魔法のような成果をもたらしませんでしたが、十分な「調整」の余地を与えてくれました。SAM のパラメータを調整することで納得感のある画像の切り出しをテストし、CLIP のプロンプトを調整することで欲しいラベルの分類をテストする。以上の流れが、手元の CPU マシン (なんならコンテナ上) で、1 分もかからず終了するのです。「この魔法のハンドリングは確かに難しいが、乗り手のセンス次第でどこまでもいける。」内なるジョブズがニヤリと笑った瞬間でした。

システム全体は Python でできるだけコンパクトにしました。「切り出し画像を検索して、商品と結びつける」ような工夫を添えても、一連の動作はコンテナ上の 1 プロセスで完了するシンプルさもあります。

そして重要な関心事は「パラメータの調整」や「フィルタの条件」そして「プロンプトの調整」だけに絞り込むことができます。私はこの調整群を yml にとりまとめ、それら一群を「モデル」と呼びました。本当の生成モデルではなく、単なる yml の集合をモデルと指すことに、もはやためらいはありませんでした。

livingroom.yml (サンプル)

./categories/coffee_maker.yml (livingroom が参照する特定のクラスのサンプル)

開発者は常に自由なモデルを開発できます。なぜならいくつかの yml ファイルを作成し、それらを格納するディレクトリを切るだけで、全く別の意図に対応する検出システムになるからです。例に示したように、livingroom.yml は tv,tire,pc を拒絶し、desk,chair,table を認識します。もし仮に「コーヒーメーカーもお願い！」と言われたとしても、coffe_maker.yml にあるような英文を用意して組み込むだけで、分類クラスは拡張されるのです。私の実装した main.py はそれら yml にしたがって、SAM を起動し、CLIP に明け渡すだけです。

私は最初のモデル＝単なる yml ファイルを搭載した python スクリプトを、非常に簡易な AWS Lambda ワークフローにデプロイしました。誰しもが一度は実装したことがありそうな、何の変哲もない Amazon S3 トリガーの Lambda コンテナです。内心「無理かも」と思っていたのですが、わずか 1 分の後に、たったメモリ 4 GB の Lambda マシンが私の不安をかき消しました。

SAM や CLIP といった CPU 動作する画像系の AI モデルのユースケースとして、RoomClip の物体検出システムの紹介をしました。
CLIP プロンプトを中心に画像ラベリングをしつつ、前処理として対象画像の矩形選択は SAM で行う、という実装となります。細やかな調整が必要なため、性能は直ちに発揮されませんが、Lambda でも軽快に動作するところが大きな特徴となります。

執筆現在は、手広く汎用な検出モデルだけでなく、例えば洗面所や玄関にだけに特化したものなど、様々な調整を施したモデル (= yml ファイル群) を作り検証しています。実際のところ、いうほど上手くいかないケースもたくさんあります。しかし、部屋画像に表れる「ユーザーさんの日々の創造的な営み」に、私たち IT エンジニアの知恵と工夫が応えられるように、日々精進してまいります。