マルチモーダル Embeddings：本番導入前に各モダリティをテストする

マルチモーダル Embeddings：本番導入前に各モダリティをテストする

対象読者: テキスト、画像、動画、ビジュアルドキュメントを対象とする検索、RAG、レコメンデーション、またはエージェントシステムを構築する上級実務者。

マルチモーダル Embeddings は、複数の検索パイプラインを1つのベクトル空間に統合できます。しかし、評価まで1つのスコアに統合するわけではありません。あるモデルが総合ベンチマークで首位になっていても、短い動画イベント、正確な用語、チャートのラベル、または本番システムに必要なページ内の局所的な証拠を取りこぼす可能性があります。

本番運用におけるルールはシンプルです。テキスト、画像、動画、ビジュアルドキュメントの結果を分けて保持すること。それぞれに適している場合は、dense、sparse、hybrid retrieval を比較すること。エンコーダーが見ていないものを測定すること。そして、すべてのモデル変更をインデックス移行として扱うことです。

5日間のうちに発表された3本の論文が、この境界を特に明確にしています。UEmbed は1回の処理で dense と sparse の表現を生成します。Douyin の DME は、検索に必要な証拠を保持するコンパクトなベクトルを学習します。ReLoop-UME は、rationale token を生成せずに再帰的な深さを追加します。いずれもより強い検索性能を報告していますが、その失敗パターンは異なる運用上のリスクを示しています。

マルチモーダル Embeddings とは？

マルチモーダル Embeddings は、異なる入力タイプを、共有空間内で比較できるベクトルに変換します。テキストクエリで写真を検索したり、動画をテキスト説明にマッチさせたり、スクリーンショットから視覚的に類似したドキュメントページを検索したりできます。

この共有インターフェースが有用なのは、検索システムがすべての候補に対して生成モデルを実行する代わりに、近似最近傍検索を利用できるためです。一方で、意味のある違いも隠れてしまいます。テキストには正確な語彙シグナルがあります。画像には局所的なオブジェクトと関係性があります。動画にはイベントのタイミングとフレーム選択が加わります。ビジュアルドキュメントには、レイアウト、OCR、表、チャート、ページコンテキストが組み合わさっています。

現在のシステムは、それぞれの制限によってこうした違いを示しています。Google の Gemini Embedding 2 documentation は、テキスト、画像、動画、音声、PDF を1つの空間にマッピングしますが、1本の動画につき最大32フレームまでしか処理せず、動画の音声トラックは処理しません。PDF は1リクエストにつき6ページに制限されています。Qwen3-VL-Embedding-2B model card は、32K コンテキストでテキスト、画像、スクリーンショット、動画、混合入力をサポートし、64から2,048までの次元数を設定できます。

これらの機能は評価計画への入力であり、特定のコーパスに対してすべてのモダリティが同等に機能する証拠ではありません。

3本の新しい論文が実際に測定したもの

これらの論文は、同じ検索上の制約における異なる部分を最適化しています。つまり、すべてのクエリを低速な生成タスクに変えることなく、識別に十分な証拠を保持することです。

これらの数値は著者らの実験によるものです。同一の本番環境で得られた結果ではなく、ハードウェア、データ、モデル規模、serving stack が統制されているかのように比較すべきではありません。

UEmbed：1回の処理で dense と sparse retrieval

UEmbed は、decoder-only multimodal model に16個の学習可能な special token を追加します。各トークンは、別々の vocabulary partition に対する sparse weight を予測し、最終的な end-of-sequence state が dense vector を提供します。著者らは、公開データで学習した 2B、4B、9B のバリアントを公開しています。

UEmbed-9B は、MMEB-V2 で dense retrieval 71.8、sparse retrieval 71.0 を報告しています。hybrid の結果は、dense retrieval と比べてテキストで0.3ポイント、ビジュアルドキュメントで0.5ポイント向上し、画像と動画ではほとんど変化しません。この結果から導ける推論は限定的です。learned sparse signal は、正確な用語やドキュメントテキストが重要な場合に dense retrieval を補完できます。しかし、hybrid search がすべてのモダリティを改善することを示しているわけではありません。

制限は実務的なものです。学習データは英語と中国語に偏っており、論文では cross-lingual sparse generalization が弱いと報告されています。また、sparse representation には vocabulary artifact も残ります。動画では dense と sparse の性能差が大きく、論文には inverted-index の効率に関する完全な調査がありません。

UEmbed repository は、2026年8月4日に確認した時点で公開から数日しか経っていませんでした。コミットは2件、スターは6個、fork は0件、release はありませんでした。これらの数値は成熟度を示すものであり、モデル品質を示すものではありません。実装はまだ初期段階であるため、本番チームはインターフェースや serving の変更を想定すべきです。

DME：検索に必要な証拠を保持するようベクトルを学習する

Douyin Multimodal Embedding technical report は、学習を2段階に分けています。まず大規模な contrastive pretraining によって、広範な共有空間を作ります。次に、学習時のみの latent reasoning と cross-conditional reconstruction によって、コンパクトな embedding が対応する対象に関する細粒度の証拠を保持するよう促します。

報告された MMEB-V2 スコアは、2B モデルで stage-one pretraining 後に70.9のベースラインから72.5へ、evidence-grounded latent reasoning 後に73.8へ、reconstruction 後に74.8へ上昇しています。9B モデルは78.4を報告しています。論文では、内部 offline set で相対2.92%の向上、online A/B test の内部 Lifetime metric で0.1%の向上も報告されています。

著者らは、これらの本番結果を Douyin 内部で測定しました。論文は、証拠を保持する学習によって、generative serving のオーバーヘッドなしに industrial retrieval が改善すると推論しています。しかし、読者は報告書だけから内部データセット、metric の定義、トラフィック構成、デプロイ条件を独立に再現できません。したがって実務的な解釈は限定されます。reconstruction は有用な学習目的になり得ますが、online の数値は他の環境へそのまま移せる予測ではありません。

ReLoop-UME：深さ方向に計算を追加する

ReLoop-UME は、中間トークンを生成せずに、モデルが retrieval-specific な計算をさらに実行できるかを検証します。positive と negative の例が分離する middle-to-late region を特定し、その parameter-shared block を4回再利用して、5つの学習可能な retrieval register を通じて証拠を伝達します。

MMEB-V2 では、論文の比較において2Bモデルが全体で63.2を報告し、VLM2Vec-V2 の58.0、UME-R1 の60.1を上回っています。7Bモデルは65.9を報告しています。単一の H20 GPU では、著者らはサンプルあたり201ミリ秒を測定しています。これは UME-R1 より44.9倍高速、PLUME より1.5倍高速ですが、非再帰型の VLM2Vec-V2 ベースラインより1.3倍低速です。

総合的な改善には警告が隠れています。ReLoop-UME-2B は論文の動画スライスで40.5を記録し、PLUME の44.1を下回っています。7B の結果も動画では UME-R1 に遅れを取っています。この手法は8フレームをサンプリングします。論文自身の制限事項にも、再帰によってサンプリングから漏れた証拠は復元できず、temporal-boundary smoothing によって短いイベントを見逃す可能性があると記載されています。

なぜ1つのベンチマーク平均では不十分なのか

MMEB-V2 は VLM2Vec-V2 とともに導入され、78のデータセットを対象としています。その内訳は画像36、動画18、ビジュアルドキュメント24です。この広さはモデル開発に有用です。しかし、これらのタスクの平均は、本番ワークロードとはほとんど関係のない重み付けを適用する可能性があります。

同じ総合スコアを受け取る3つのシステムを考えてみましょう。

1つ目には語彙の精度とスクリーンショット理解が必要です。2つ目は時間的なカバレッジが成否を分けます。3つ目には、ページ内 OCR、レイアウト、修飾語の正確性が必要です。これらの失敗を平均すると、きれいな数値と悪い意思決定が生まれます。

再現可能なマルチモーダル embedding 評価

既知の関連証拠を含む、固定したコーパスのスナップショットとクエリセットから始めます。元のソースオブジェクト、embedding 入力、relevance judgment を一緒に保持してください。そうしなければ、エンコーダーの失敗と ingestion の失敗を区別できなくなります。

1. メトリクスを選ぶ前にモダリティ別スライスを作る

テキスト、画像、動画、ビジュアルドキュメント用に別々のスライスを作成します。さらに、重要な挙動ごとに分割します。

すべての例に coverage field を追加します。ソースの証拠がエンコーダーに届いたかを記録してください。欠落したフレーム、切り取られたチャートの凡例、除外された PDF ページを embedding のエラーとして採点してはいけません。

2. 完全な検索パイプラインを比較する

同じ relevance judgment に対して、少なくとも次の候補をテストします。

hybrid baseline は重要です。UEmbed の結果は、改善がすべてのモダリティではなく、テキストとビジュアルドキュメントに集中していることを示しているからです。text baseline も重要です。キャプション、OCR、構造化メタデータは、native multimodal vector より安価に index でき、デバッグしやすく、正確な用語に対して優れている可能性があります。

3. 品質、カバレッジ、コストを同時に測定する

メトリクスは1つの平均だけでなく、スライスごと、および分布として報告します。

有効なサマリーでは、重要な最悪スライスを見える状態に保ちます。たとえば、weighted aggregate が改善し、かつ保護対象のスライスが regression budget を超えない場合にのみ候補を昇格させます。

text promote = aggregate_gain > 0 and text_regression <= budget.text and image_regression <= budget.image and video_regression <= budget.video and visual_doc_regression <= budget.visual_doc and p95_latency <= budget.latency

予算はプロダクト上の意思決定です。この構造により、動画検索プロダクトで画像中心のベンチマークが動画の失敗を埋め合わせることを防げます。

*まず各検索レーンを評価し、その後に共通の runtime、移行、リリースゲートを適用します。*

4. embedding space をバージョン管理する

embedding model のバージョンは、保存データ形式の一部です。Google の migration guide では、`gemini-embedding-001` と `gemini-embedding-2` は互換性のない空間を生成するため、アップグレードには既存データ全体の re-embedding が必要だと説明されています。一方の空間の query vector を、もう一方の document vector と直接比較することはできません。

5. 切り替え前に本番クエリを shadow する

offline evaluation は既知のケースを制御します。shadow traffic は、ユーザーに見える結果を変更せずに、実際の分布をテストします。両方の候補リスト、latency、空の結果、各不一致に関連するスライスまたは入力タイプをログに記録します。段階的な rollout の前に、不一致を確認してください。

クリックだけを relevance truth として使わないでください。position bias と現在の ranker が、ユーザーがクリックできる対象を形作っています。サンプリングした人手による judgment、下流タスクの成功、行動シグナルを組み合わせてください。

本番運用のための意思決定フレームワーク

生の視覚的または時間的な証拠が relevance を変え、テキスト表現ではその証拠が失われる場合は、マルチモーダル embedding model を使用します。コーパスの大半が文章で、正確な識別子が支配的である場合、または信頼できるキャプションと OCR がすでに有用なシグナルを捉えている場合は、より単純な text または hybrid pipeline を維持します。

preprocessing をテストする前に、より大きなモデルを選ばないでください。フレーム選択、ページ分割、OCR、query instruction、negative example が結果を左右することがあります。Open-source の活動状況から実装上の摩擦を把握できる場合はありますが、品質ベンチマークではありません。2026年8月4日時点で、Qwen3-VL-Embedding repository には32件のコミットと55件の open issue があり、最近の issue には serving endpoint と representation mismatch が含まれていました。これらは調査すべき engineering signal であり、モデルを採用または却下する理由ではありません。

証拠が支持すること

論文は、3つの具体的な結論を支持しています。

第一に、コンパクトなマルチモーダルベクトルは、変更されていない単一の forward pass よりも多くの retrieval-specific computation を保持できます。DME は学習時のみの objective を追加し、ReLoop-UME は再帰的な深さを追加し、UEmbed は dense と sparse の view を同時に導出します。

第二に、representation mechanism は失敗パターンを変えます。sparse retrieval には語彙と cross-lingual のリスクがあります。再帰的な深さには学習コストと latency コストがあります。embedding model が実行される前に、動画は sampling による欠落の影響を受け続けます。

第三に、本番の証拠はローカルでなければなりません。著者らは有用なベンチマーク結果とシステム結果を測定しましたが、あなたのコーパス、クエリ構成、latency budget、index migration、誤った検索結果のコストを測定した論文はありません。

有用な結論は運用上のものです。マルチモーダル Embeddings は、各モダリティが独自の検索テストとカバレッジテストに合格した後にのみ採用してください。共有ベクトル空間は serving を簡素化できます。しかし、評価は意図的に不均一なままにすべきです。

FAQ

テキストと画像の embedding は同じ index を使うべきですか？

モデルがそれらのモダリティを互換性のある1つの空間に配置するよう学習されており、cross-modal retrieval がタスクの一部である場合は、同じ index を共有できます。lexical retrieval、モダリティ固有のフィルター、異なる更新頻度、独立した rollback が重要な場合は、別々の field または index を維持してください。1つのレイアウトが優れていると仮定せず、実際の relevance judgment で score fusion をテストしましょう。

モデルを変更するとき、データを re-embed する必要がありますか？

通常は必要です。異なるモデルまたは互換性のないバージョンの embedding space は、安全に比較できません。versioned replacement index を構築し、コーパスを re-embed し、両方の index に対して query を shadow し、新しい index がモダリティ別の品質および latency gate を通過するまで古い index を保持してください。

Claim checks

Sources