先週、Sentence Transformers v5.4のリリースノートを眺めていたら、思ったよりでかいアップデートが入っていて思わず手が止まった。
テキストだけだったembeddingのAPIが、画像・音声・動画にも対応したらしい。
しかも既存のAPIを変えずに、だ。
今まで画像検索とかマルチモーダルな処理を組もうとすると、CLIPを別途ロードして、テキスト用のembedding処理と別ルートで管理して…という感じで、コードが分岐しがちだった。
それが `model.encode()` に画像URLやPILオブジェクトをそのまま渡せるようになったので、ルートを統一できる。
たとえばこんな感じで使える。
インターフェースは完全に同じ。
テキストを渡してたところに画像URLを渡すだけ。
この「既存APIを壊さずに拡張する」設計、個人開発でも参考にしたくなる。
今のプロジェクトで商品画像と説明文をセットで検索させたい場面があって、ずっと後回しにしていた。
そのユースケースがそのまま動きそうで少しテンションが上がった。
ただ、喜んでいられない部分もある。
Qwen3-VL-2Bを動かすには最低でも8GB VRAMが必要で、8Bモデルだと約20GBかかるとドキュメントに書いてあった。
CPUだと「extremely slow」と明記されている。
これは個人開発の環境だとなかなか厳しい。
自分のマシンはGTX 1080Tiで11GBあるので2Bはギリギリ試せるかもしれないが、本番環境をどこに置くかは考えないといけない。
クラウドのGPUインスタンスはコストが跳ね上がるし、ここはLLMのAPIコストと同じ悩みだなと思った。
画像が絡まないユースケースなら、引き続きテキスト特化の軽量モデルを使う方が合理的だと思う。
CLIPモデルはCPUでも動くと書かれているので、まずそこから試すのが現実的な入り口になりそう。
v5.4ではembeddingだけでなく、rerankerもマルチモーダル対応している。
RAGパイプラインでrerankerを使っているなら、ここも影響を確認しておく価値がある。
リトリーブしてきたドキュメントが画像混じりの場合、今まではテキスト部分だけでrerankerにかけるか、そもそも諦めるかという選択肢しかなかった。
それが「テキストクエリ vs 画像ドキュメント」という組み合わせでスコアリングできるようになった。
ビジュアル系ドキュメントの検索精度が上がる可能性があるので、RAGを組んでいる人は一度チェックしてみるといいと思う。
ただ、現時点ではモデルのrevisionを明示的に指定しないとロードできないという注意点がある。
PRがマージされるまでの一時的な制約らしいが、本番コードに入れるときはそこだけ覚えておきたい。
自分はまず手元のGPUでQwen3-VL-2Bを動かして、既存のテキスト検索と精度を比べてみるところから始めるつもりだ。
インターフェースが統一されているなら、A/Bで比較するコストも下がるはずなので。
テキストだけだったembeddingのAPIが、画像・音声・動画にも対応したらしい。
しかも既存のAPIを変えずに、だ。
自分のコードのどこが変わるか
今まで画像検索とかマルチモーダルな処理を組もうとすると、CLIPを別途ロードして、テキスト用のembedding処理と別ルートで管理して…という感じで、コードが分岐しがちだった。
それが `model.encode()` に画像URLやPILオブジェクトをそのまま渡せるようになったので、ルートを統一できる。
たとえばこんな感じで使える。
from sentence_transformers import SentenceTransformer
model = SentenceTransformer(
"Qwen/Qwen3-VL-Embedding-2B",
revision="refs/pr/23"
)
img_embeddings = model.encode([
"https://example.com/image1.jpg",
"https://example.com/image2.jpg",
])
# shape: (2, 2048)インターフェースは完全に同じ。
テキストを渡してたところに画像URLを渡すだけ。
この「既存APIを壊さずに拡張する」設計、個人開発でも参考にしたくなる。
今のプロジェクトで商品画像と説明文をセットで検索させたい場面があって、ずっと後回しにしていた。
そのユースケースがそのまま動きそうで少しテンションが上がった。
VLMベースのモデルはGPU要件がかなり重い
ただ、喜んでいられない部分もある。
Qwen3-VL-2Bを動かすには最低でも8GB VRAMが必要で、8Bモデルだと約20GBかかるとドキュメントに書いてあった。
CPUだと「extremely slow」と明記されている。
これは個人開発の環境だとなかなか厳しい。
自分のマシンはGTX 1080Tiで11GBあるので2Bはギリギリ試せるかもしれないが、本番環境をどこに置くかは考えないといけない。
クラウドのGPUインスタンスはコストが跳ね上がるし、ここはLLMのAPIコストと同じ悩みだなと思った。
画像が絡まないユースケースなら、引き続きテキスト特化の軽量モデルを使う方が合理的だと思う。
CLIPモデルはCPUでも動くと書かれているので、まずそこから試すのが現実的な入り口になりそう。
rerankerのマルチモーダル対応も見逃しやすい
v5.4ではembeddingだけでなく、rerankerもマルチモーダル対応している。
RAGパイプラインでrerankerを使っているなら、ここも影響を確認しておく価値がある。
リトリーブしてきたドキュメントが画像混じりの場合、今まではテキスト部分だけでrerankerにかけるか、そもそも諦めるかという選択肢しかなかった。
それが「テキストクエリ vs 画像ドキュメント」という組み合わせでスコアリングできるようになった。
ビジュアル系ドキュメントの検索精度が上がる可能性があるので、RAGを組んでいる人は一度チェックしてみるといいと思う。
ただ、現時点ではモデルのrevisionを明示的に指定しないとロードできないという注意点がある。
PRがマージされるまでの一時的な制約らしいが、本番コードに入れるときはそこだけ覚えておきたい。
自分はまず手元のGPUでQwen3-VL-2Bを動かして、既存のテキスト検索と精度を比べてみるところから始めるつもりだ。
インターフェースが統一されているなら、A/Bで比較するコストも下がるはずなので。