画像検索機能の構築例とポイントと課題感
これはなに？
自然言語で画像を検索する機能を実装する機会があったので、構築例としての備忘録です。
構成について
探している画像の特徴を自然言語で入力して検索を実施し、検索結果としてCloud Storageで公開した画像のリンクを返却して表示するという機能です。
以下2つのGoogle Cloudのサービスを使用して実装を行いました。
Cloud Run
Dockerコンテナを1つ用意し、Flaskでアプリサーバを構築しました。
画像検索は画像のディスクリプション情報と入力したプロンプトの類似度を測定し、近いものから検索結果として利用します。画像のディスクリプション情報はOpenAiのGPT-4o-miniを利用して画像を説明させることで情報量をかさ増しする工夫をしました。
Cloud Storage
検索対象の画像を保存しておきます。ストレージは外部に公開するように設定します。
コンポーネントごとの実装ポイントと課題感
フロントエンド
最終的にHTMLとCSSとJSを直書きしました。初期はReactのコンテナを別に用意し、AppサーバーとAPIベースでのやり取りを想定していましたが時間がなく割愛しました。
Appサーバー
最終的にFlaskを選択したが、初期はDjangoを検討。設定項目が煩雑な点と、今回の検証の目的が画像検索だった為、より簡易に実装できるFlaskに変更した経緯がある。
画像検索機能
機能の中核となる画像検索機能はLangChainとFaissを組み合わせてプロンプトによるベクトルデータベースを構築し、検索に利用する形で実装しました。機能はtext to imageですがやっていることは文章間の類似度比較に過ぎません。現在はDBを参照するまでで「生成」要素はないため、今後はRAG構成を展開しつつ、画像を生成する方向性があります。画像生成のRAG構成には以下3つの手法を検討中です。
- RAGによる画像生成時のプロンプトの補強
- マルチモーダルなRAGの構成として画像を直接読み込ませる
- OpenAIのモデルはファインチューニングできるそうなのでこれの検討
Cloud Storageの利用について
配信用の画像の保管と、URLを払い出すために利用します。
主に2点つまづきポイントがあったので、申し送りです。
- 画像について
使用を想定した画像にロックがかかっており、そのままでpillowで読み込み時にエラーとなった。これはロックを外すために一旦macで開いてpngで保存する形で回避した。 - 画像のサイズについて
使用を予定した画像は500KBから11MBまで幅広いサイズであった。大きいサイズのものはベクトル化に負荷をかけるだけでなく、読み込めないエラーの原因にもなるため、なるべく画像データは均一に前処理したものを利用するべき。※当たり前かもだけども改めて重要性を感じました。
Cloud Runの利用について
今回はGKEの利用を前提考えていましたが、時間もないため一旦検証文脈で速度優先でCloud Runとしました。クラウドのメリットである柔軟性と拡張性は最低限ですが、これをベースに様々なケースごとに最適な構成を考えていきたいです。
まとめ
今回は以上ですが、画像にまつわる生成AIに関するトピックはこちらの記事を適宜更新しようと思います。
Discussion