encode_query() と encode_document() が用意され、検索向けの「クエリ用」「文書用」プロンプトを自動で使ってくれる
Hugging FaceのSentence Transformersといえば、もともとは文章をベクトル化して検索や類似度計算に使うライブラリとして有名でした。
たとえば「この問い合わせに似た文章を探したい」「意味の近い文をまとめたい」「RAGで関連文書を拾いたい」といった用途でよく使われます。
今回紹介する記事は、そのSentence Transformersがマルチモーダル対応になった、という話です。
マルチモーダルとは、簡単に言うと複数種類のデータを扱うこと。この記事では主に、
を同じライブラリ、同じ発想で扱えるようになったと説明しています。
これはかなり大きいです。
なぜなら現実の情報って、文章だけでは完結しないからです。商品検索なら画像が欲しいし、動画検索ならシーンの説明が効くし、RAGでも「PDFの本文だけ」ではなく「スクリーンショットや図表」まで見たい場面がある。
つまり、検索や推薦の世界が、ようやく現実に追いついてきた感じがあります。これは面白いです。
記事の中心は、次の2種類です。
これは、異なる種類の入力を同じ意味空間に埋め込むモデルです。
「埋め込む」とは、テキストや画像を、機械が比較しやすい数字の列（ベクトル）に変換することです。
たとえば、
を近い場所に置ければ、「この文章に合う画像はどれ？」という検索ができます。
こちらは、候補の関連度を1件ずつ丁寧に採点するモデルです。
Embedding modelより遅いけれど、関連性の判断は一般に強いです。
たとえば検索で100件拾ってきたあと、「本当に一番合うのはどれ？」を見直すのに向いています。
個人的には、この役割分担がすごく大事だと思います。
速いけど雑な一次検索と、遅いけど賢い最終判定を分けるのは、現場ではかなり王道です。
記事では、使いたいモダリティに応じて extras を入れる方法が紹介されています。
sentence-transformers[image]sentence-transformers[audio]sentence-transformers[video]GPUの目安も書かれていて、VLMベースのモデル、たとえば Qwen3-VL-2B は少なくとも約8GBのVRAMが必要とのこと。8B版なら約20GBくらい見ておいたほうがよさそうです。
ここは正直、かなり現実的な注意点です。
「マルチモーダルってロマンあるよね」で終わらず、ちゃんと重いと明言しているのが好感触でした。CPUでも動かせるけれど、かなり遅いので、実際には text-only や CLIP 系のモデルのほうが向く場面も多そうです。
encode() できるのが気持ちいい記事では、モデルの読み込みはいつものSentence Transformersと同じです。
from sentence_transformers import SentenceTransformer
model = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B")
ここで驚くのは、そのあとです。
model.encode() が、テキストだけでなく画像URLも受け付けます。
つまり、画像をわざわざ別の前処理パイプラインに通さなくても、かなり自然に扱えるわけです。
この「いつものAPIの延長線上でできる」というのが、実は一番強いポイントだと思います。
新機能って、性能よりもまず「使い方が面倒じゃないこと」が普及の鍵になりがちなので。
記事では、テキスト埋め込みと画像埋め込みの類似度を計算しています。
たとえば、
のような組み合わせで比べると、ちゃんと意味の近いもの同士のスコアが高くなっています。
ここで大事なのは、異なるモダリティ同士のスコアは1.0に近づきにくいという点です。
記事ではこれを modality gap と呼んでいます。
要するに、textとimageは同じ空間に入っていても、もともと別の種類の情報なので、完全にぴったり重なるわけではない、ということです。
でも、ここで重要なのは絶対値ではなく順位です。
「一番近い候補が上に来る」ことが大切なので、類似度の数値そのものが低めでも検索は十分機能します。
この説明はかなり親切でした。初心者が「0.67しかないじゃん、失敗？」と思いやすいので、そこを先回りしているのがいいです。
encode_query() と encode_document() が便利Retrieval、つまり検索用途では、encode_query() と encode_document() が推奨されています。
これは何をしているかというと、モデルによっては
を使い分けるからです。
たとえばチャットモデルに「役割」を与えるのに似ています。
検索でも、質問側と文書側は同じ文章でも意味合いが違うので、別の前提を与えたほうがうまくいくことがあります。
記事では、これらの関数が内部で encode() の薄いラッパーとして動き、適切な prompt や task を自動で設定してくれると説明しています。
この設計はかなり実務向きです。
個人的には、こういう「うっかりミスを減らしてくれるAPI」は本当にありがたいです。検索系って、ちょっとした前処理の違いで精度がガクッと変わるので。
Embedding modelは検索の一次通過向きですが、Rerankerはもっと厳密に関連度を見ます。
記事では CrossEncoder として使う例が紹介されています。
from sentence_transformers import CrossEncoder
model = CrossEncoder("Qwen/Qwen3-VL-Reranker-2B")
そして、クエリに対して複数の候補を並べると、
のような混在した候補をちゃんと順位付けできます。
ここが今回のかなり面白いところです。
画像だけ、文章だけ、画像＋文章が同じ土俵で競える。
検索エンジンというより、まるで「内容を理解して順番をつける審査員」が増えた感じです。
しかも model.modalities や model.supports() で、どのモダリティや組み合わせに対応しているか確認できます。
こういう「このモデル、何ができるの？」をプログラムから調べられるのは実用的ですね。
predict() でペアごとのスコアも出せるRerankerには rank() だけでなく predict() もあります。
これは、決め打ちのペアに対して関連スコアを返してくれるものです。
たとえば、
のような組み合わせを入れると、それぞれにスコアが返ります。
この機能は、検索だけでなく判定タスクにも使えそうです。
たとえば「この説明文はこの画像に合っているか？」みたいなチェックですね。
用途がぐっと広がります。
記事の後半では、定番の構成として
という流れが紹介されています。
これはもう、検索やRAGの世界では鉄板です。
Embeddingだけだと速いけれど少し雑、Rerankerだけだと正確だけど遅い。
だから両方を組み合わせる。
この分業が、マルチモーダルでもそのまま通用するのはかなり嬉しい進化だと思います。
特に、画像を含む検索は「なんとなく似ている」を拾うのが難しいので、一次検索と最終判断を分ける設計はかなり相性がいいはずです。
記事では、対応入力形式や設定についても触れています。
画像URL、ローカルファイル、PIL Imageなど、複数の入力型を受けられるのはかなり便利です。
また、モデル側がサポートしているモダリティを確認できるようになっているのも、地味だけど重要です。
マルチモーダル対応って、見た目は派手でも「このモデルは本当に音声までいけるの？」みたいな確認が必要になりがちなので、こういう機能は実装者に優しいです。
率直に言うと、これは「単に対応しました」以上の意味があります。
Sentence Transformersは、もともと検索・類似度・RAGの標準ライブラリとしてかなり広く使われてきました。
そこにマルチモーダルが入ると、今まで別々だった世界がかなり自然につながるんです。
たとえば、
こういうものが、同じ思想で扱えるようになる。
これは実務ではかなり大きいです。
個人的には、AIの進化って「単に賢くなる」だけでなく、実装の手間が減るときに一気に広がると思っています。
今回の更新はまさにそれで、APIの統一がそのまま普及力につながるタイプの進化です。
Sentence Transformers v5.4のマルチモーダル対応は、かなり本質的なアップデートです。
テキストだけだった検索・埋め込み・再ランキングの世界が、画像や音声、動画まで広がりました。
しかも難しい新APIを覚え直すというより、既存の encode() や CrossEncoder の延長で使えるのが強い。
この「いつもの使い心地のまま、できることだけ増える」感じが、かなり良いです。
検索やRAGをやっている人にはもちろん、画像検索やマルチモーダルAIに興味がある人にも、かなり面白い内容だと思います。
今後は「文章ベースの検索」だけでなく、「見た目や音まで含めた検索」が、もっと普通になっていくのではないでしょうか。
参考: Multimodal Embedding & Reranker Models with Sentence Transformers