画像解像度がビジュアルドキュメント検索に与える影響

従来のコンピュータービジョンモデルは、一般的に人間の視覚認識を模倣することに重点を置いています。jina-embeddings-v4は、異なるアプローチを採用しています。画像とテキスト処理を組み合わせて、人々が視覚的に提示された情報をどのように読んで解釈するかを理解します。単にテキストをデジタル化するOCRプログラムとは異なり、インフォグラフィック、チャート、図、表など、テキストと視覚要素の両方が意味を持つ複雑な視覚資料を実際に解析します。これらの文書を「視覚的にリッチな文書」と呼んでいます。

OCRとテキストの向量模型を使用するだけでは、重要な情報を見逃してしまいます。画像とキャプションのペアで学習された従来の向量模型を使用しても、テキストのセマンティクスを抽出することはできません。また、表のような場合、テキストの意味を知り、テキスト要素間の空間的な関係を処理して適切に処理する必要があります。視覚的に認識する方法で処理する必要があるため、visual document retrievalと呼ばれています。

図2: JinaVDRベンチマークコレクションからの、画像としてレンダリングされた表。単語間の空間的な関係は、表の意味を理解するために非常に重要です。

しかし、物事を理解するためには見ることができなければならず、それは向量模型でも同じです。画質が重要になります。

図3: パターソン・ギムリンフィルムからのフレーム。ビッグフットでしょうか？ぼやけたクマでしょうか？ゴリラの着ぐるみを着た男でしょうか？画質が悪いと判断が難しくなります。

画質の差は、写真がピンぼけしている、照明条件が悪い、動きによってぼやける、非可逆圧縮アルゴリズムが詳細を破壊するなど、多くの原因から生じます。しかし、視覚的にリッチなドキュメントは、通常「デジタル生まれ」です。スクリーンショット、プレゼンテーションスライド、光沢のあるPDFなど、何らかのプレゼンテーションまたは公開プロセスによって画像にレンダリングされたデータで構成されています。実際紙のページをスキャンしたものもありますが、適切に作成されていれば、それらの画像は現実世界の写真に蔓延しているような問題の影響を受けません。

図4: 画像の解像度を変更した場合の効果。最小のテキストが最も速く失われ、向量模型が単なるぼかしであるテキストを理解できるとは期待できません。解像度が十分に低い場合は、視覚的なコンテンツも失われます。

視覚的にリッチなドキュメントの場合、主な入力品質の問題は画像解像度です。小さすぎると、検索に必要な情報が失われます。大きすぎると、正確な処理を損なう偽のディテールでモデルがあふれてしまいます。入力をjina-embeddings-v4に適切なサイズにすることで、コストを節約し、検索結果を改善できます。

この記事では、jina-embeddings-v4が画像をどのように処理するか、また、画像解像度が視覚的にリッチなドキュメントを検索する能力に与える影響について見ていきます。この記事のアイデアを自分で適用したい場合は、結果を再現したり、独自のデータをテストしたりするためのコードをHugging FaceのJinaVDRリポジトリで提供しています。

tagVisual Language Models

jina-embeddings-v4は、Qwen2.5-VL-3B-Instruct VLMを拡張したvisual language model（VLM）です。この画像埋め込みへのアプローチは、単一モダリティの画像またはテキストモデル、およびjina-clip-v2のようなCLIPスタイルのモデルとは異なります。

図5は、jina-embeddings-v4モデルアーキテクチャの概略図です。バックボーンモデルは、従来のトランスフォーマーベースの向量模型と似ていますが、デュアル出力モードをサポートしている点が異なります。デュアル出力モードとは、デコーダーの最終層を平均プーリングすることによって生成される単一ベクトル（高密度ベクトル）埋め込みと、入力と同じサイズの射影層によって生成されるマルチベクトル（遅延インタラクション）出力です。

jina-embeddings-v4とその2つの出力モードの詳細については、リリースのお知らせとテクニカルレポートを参照してください。

図5: バージョン4テクニカルレポートからのjina-embeddings-v4のアーキテクチャ。

テキストの場合、その入力は従来のテキスト向量模型と同じです。テキストはトークン化され、トークンはルックアップテーブルからのベクトルに置き換えられます。これらのトークンベクトルがモデルへの入力として機能します。

VLMの革新は、画像の処理方法にあります。従来の画像向量模型がテキスト向量模型に接続されていますが、平均プーリングによって画像埋め込みを生成する代わりに、その最終層がテキスト向量模型への入力になります。まるで一連のトークンベクトルのように。

図6: jina-embeddings-v4がテキストと比較して画像をどのように処理するか。

これは、大きな画像は長いテキストと同じ問題を向量模型に抱えていることを意味します。入力が長くなるほど、計算コストとエンコード時間が長くなり、多くの場合、役に立たない埋め込みが生成されます。小さな画像は逆の問題を抱えています。1つのパッチに詰め込まれる情報が多すぎると、埋め込みプロセスで減衰し、単一ベクトルの埋め込みで失われます。マルチベクトル埋め込みの場合、一致の強度が低下します。モデルに提供される情報の量と、関連情報を正確に抽出する能力の間にはトレードオフがあります。

しかし、テキストのサイズを変更することはできません。画像のサイズは変更できます。

tagjina-embeddings-v4での画像の前処理

画像をjina-embeddings-v4に送信すると、28x28ピクセルのパッチに分割されます。これは、パッチの数が画像のサイズにほぼ比例することを意味します。Jina APIを使用する場合、サポートされる最大サイズは602,112ピクセルですが、ダウンロードする場合は、モデルコードでユーザーが設定できるパラメータです。

VLMアーキテクチャは、モデルがサポートできる28x28の画像パッチの数が、サポートできるテキストのトークンの数と等しいことを意味します。これにより、画像サイズの上限は約20メガピクセルに設定されます。

tag画像解像度に関する実験

ViDoRe v1およびv2スイート、そしてJinaVDRベンチマークスイートの一部を用いて、jina-embeddings-v4で異なる画像解像度を評価しました。シングルベクトルおよびマルチベクトルの両方の出力について検討しました。モデルのmax_pixelsパラメータを最大19,267,584ピクセル（つまり5,376x3,584）までの範囲の値に調整することで、異なる画像解像度からの埋め込みが生成されます。画像がすでにmax_pixelsの値よりも小さい場合は、変更されません。

tagViDoRe v1

表1は、個々のViDoRe v1ベンチマークにおける5つの解像度に対するシングルベクトル（密なベクトル）の埋め込み検索結果（平均nDCG@5スコア）を示しています。ViDoRe v1には9,633,792ピクセルを超える画像がないため、それまでの値のみを報告しています。

**Figure 8**: ViDoRe v1ベンチマークスイートからのドキュメントの例。

Benchmark Dataset	301,056 px	602,112 px	1,204,224 px	2,408,448 px	4,816,896 px	9,633,792 px
Max embedding vector size in tokens	384	768	1,536	3,072	6,144	12,288
`arxivqa_test_subsampled`	0.83487	0.84529	0.84537	0.83785	0.83439	0.83469
`docvqa_test_subsampled`	0.47366	0.50715	0.52421	0.51075	0.50287	0.50258
`infovqa_test_subsampled`	0.84404	0.87510	0.87890	0.87978	0.87672	0.87710
`shiftproject_test`	0.77524	0.81494	0.83988	0.84427	0.84127	0.84196
`syntheticDocQA_artificial_intelligence_test`	0.93809	0.96786	0.96655	0.97155	0.97024	0.97024
`syntheticDocQA_energy_test`	0.86865	0.89540	0.89847	0.91172	0.91286	0.91286
`syntheticDocQA_government_reports_test`	0.91708	0.93417	0.93865	0.92309	0.91609	0.91609
`syntheticDocQA_healthcare_industry_test`	0.93865	0.96428	0.96024	0.96542	0.95417	0.95286
`tabfquad_test_subsampled`	0.94298	0.94853	0.94502	0.94505	0.94505	0.94612
`tatdqa_test`	0.58622	0.64832	0.65867	0.65985	0.65395	0.65498
AVERAGE	0.81195	0.84010	0.84560	0.84493	0.84076	0.84095

より高い解像度が低い解像度と同点の場合、そのベンチマークには低い解像度よりも大きい画像が存在しなかったため、サイズ変更は行われなかったことを意味します。

表1からわかるように、最高の解像度が必ずしも最適とは限りません。9.6メガピクセルは、4.8メガピクセルを超える画像が存在しないテストを除き、他のテストでは最高の解像度を下回る結果となりました。これは、サイズ変更が行われなかったため、同じスコアが得られたためです。平均して最高のパフォーマンスを示したのは1.2メガピクセルであり、異なるベンチマークで最も多くの最高スコアを獲得した解像度は2.4メガピクセルでした。

各ベンチマークで最高のスコアを取り、それらを平均すると、0.84905になります。これは、1.2メガピクセルのスコアよりもわずか0.345％優れているだけです。

表2に示すように、マルチベクトル埋め込みを使用すると、検索スコアが大幅に向上します。マルチベクトルマッチングは、通常、シングルベクトルマッチングよりも優れたパフォーマンスを発揮します。ただし、異なる解像度のパフォーマンスはほぼ同じです。

Benchmark Dataset	301,056 px	602,112 px	1,204,224 px	2,408,448 px	4,816,896 px	9,633,792 px
Max embedding vector size in tokens	384	768	1,536	3,072	6,144	12,288
`arxivqa_test_subsampled`	0.87456	0.88881	0.88736	0.88531	0.88899	0.89052
`docvqa_test_subsampled`	0.55344	0.61284	0.61123	0.59941	0.59087	0.59229
`infovqa_test_subsampled`	0.88777	0.92646	0.93376	0.94007	0.93459	0.93533
`shiftproject_test`	0.86224	0.90563	0.93547	0.92847	0.92240	0.92240
`syntheticDocQA_artificial_intelligence_test`	0.99631	0.99131	0.99500	0.99262	0.99262	0.99262
`syntheticDocQA_energy_test`	0.95216	0.96524	0.96524	0.96893	0.96762	0.96762
`syntheticDocQA_government_reports_test`	0.95934	0.97085	0.97524	0.98024	0.96655	0.96655
`syntheticDocQA_healthcare_industry_test`	0.97893	0.97893	0.99631	0.98524	0.98393	0.98393
`tabfquad_test_subsampled`	0.95386	0.95732	0.95611	0.95379	0.95379	0.95379
`tatdqa_test`	0.70547	0.78534	0.79516	0.80422	0.80552	0.80727
AVERAGE	0.87241	0.89827	0.90509	0.90383	0.90069	0.90123

シングルベクトルの埋め込みと同様に、1.2メガピクセルの解像度が平均スコアが最も高く、2.4メガピクセルが最も多くの個々のデータセットで最高のスコアを獲得した解像度です。すべてのベンチマークにおける最高のスコアの平均は0.90853であり、1.2メガピクセルの解像度の平均スコアは0.344％低く、シングルベクトルの場合とほぼ同じです。

tagViDoRe v2

ViDoRe v2は、ViDoRe v1よりもはるかに詳細でカラフルな画像を使用しており、最適な解像度が高くなる可能性を示唆しています。

ViDoRe v2ベンチマークスイートでjina-embeddings-v4からのマルチベクトル埋め込みをテストしました。結果は表3に示されています。シングルベクトルの結果も同様ですが、スコアが低いため、ここでは省略します。

Benchmark Dataset	150,528 px	301,056 px	602,112 px	1,204,224 px	2,408,448 px	4,816,896 px	9,633,792 px
Max embedding vector size in tokens	192	384	768	1,536	3,072	6,144	12,288
`esg_reports_v2`	0.40444	0.54013	0.52005	0.51916	0.49953	0.52664	0.51442
`biomedical_lectures_v2`	0.58760	0.60479	0.6184	0.60748	0.60748	0.60748	0.60748
`economics_reports_v2`	0.47666	0.50399	0.54216	0.54998	0.54998	0.54998	0.54998
`esg_reports_human_labeled_v2`	0.42171	0.56940	0.61227	0.57307	0.61108	0.63858	0.64921
AVERAGE	0.47260	0.55458	0.57322	0.56242	0.56702	0.58067	0.58027

この場合、平均して最高のパフォーマンスを示すのは4.8メガピクセルの解像度であり、9.6メガピクセルの平均パフォーマンスはほぼ同じです。それにもかかわらず、4つのベンチマークのうち3つでは、最高の解像度は低い解像度よりもパフォーマンスが低く、4.8メガピクセルを超える画像がないテストは1つだけでした。

tag高解像度ベンチマーク

ViDoRe v1とViDoRe v2は、ネイティブ解像度が類似した画像で構成されているため、処理が難しい非常に高解像度の画像を含むJinaVDRスイートから2つのベンチマークを選択し、同じマルチベクトル埋め込みテストを実行しました。

1つはeuropeana-de-newsベンチマークで、17世紀から20世紀のドイツの新聞の高解像度スキャンが含まれています。もう1つはwikimedia-commons-mapsベンチマークで、主にデジタル時代以前の印刷された地図の非常に高解像度のスキャンが含まれています。

**Figure 10**: (左) 18世紀の印刷物からの4000x2968ピクセルの地図。`wikimedia-commons-maps`に含まれています。(右) *Hamburger Nachrichten*新聞の1819年4月26日付の第一面。4324x4738ピクセルでスキャンされ、`europeana-de-news`に含まれています。

表4に示すように、結果は大きく分かれています。

ベンチマークデータセット	301,056 px	602,112 px	1,204,224 px	2,408,448 px	4,816,896 px	9,633,792 px	19,267,584 px
トークン内の最大埋め込みベクターサイズ	384	768	1,536	3,072	6,144	12,288	24,576
`europeana-de-news`	0.46319	0.59457	0.66802	0.66550	0.66407	0.63948	0.65208
`wikimedia-commons-maps`	0.23671	0.34421	0.42835	0.52268	0.53464	0.53464	0.53588
平均	0.34995	0.46939	0.54819	0.59409	0.59936	0.58706	0.59398

新聞データは、地図データと同じ解像度を必要としないことは明らかです。これはおそらく、地図のテキストが画像全体のサイズに比べて非常に小さく、検索が機能するためには実際に読み取り可能である必要があるためです。新聞のスキャンが最適なサイズよりも大きい場合、パフォーマンスは変動し、低下します。

平均値はどちらにとっても最適ではありません。これは、問題を解決するための正しい解像度が1つではないことを示唆しています。この発見が、私たちが次に行ったことの動機となっています。

tagマルチ解像度ベクトルモデル

jina-embeddings-v4のVLMアーキテクチャは、画像の個々のパッチをテキストのトークンと同様に扱うため、高解像度のパッチを低解像度のパッチで拡張するのは簡単です。モデルがサポートする最大値を超えない限り、それはより多くの入力データを意味するだけです。低解像度がより高解像度よりも優れたセマンティクスをもたらす場合は、それらを含めるだけで、最適な解像度を気にする必要はありません。

この仮説をテストするために、3つの解像度の組み合わせを検討しました。

	Mix 1	Mix 2	Mix 3
トークンの総数の最大値	2,880	5,234	12,096
解像度	150,528 px<br>301,056 px<br>602,112 px<br>1,204,224 px	50,000 px<br>90,000 px<br>160,000 px<br>250,000 px<br>360,000 px<br>490,000 px<br>602,112 px<br>900,000 px<br>1,204,224 px	150,528 px<br>301,056 px<br>602,112 px<br>1,204,224 px<br>2,408,448 px<br>4,816,896 px

これは、Mix 1をテストしたときに、各画像を4つの異なる解像度（150,528 px、301,056 px、602,112 px、1,204,224 px）にリサイズし、それぞれを個別にマルチベクター埋め込みに処理してから、クエリマッチングを行う前に結果を連結したことを意味します。Mix 2とMix 3も同様ですが、解像度が異なります。表6にまとめたViDoRe v2ベンチマークですべての3つの組み合わせを試しました。

ベンチマークデータセット	最適な単一解像度	Mix 1	Mix 2	Mix 3
トークン内の最大埋め込みベクターサイズ	—	2,880	5,234	12,096
`esg_reports_v2`	0.54013	0.58354	0.59252	0.56567
`biomedical_lectures_v2`	0.61840	0.61678	0.61714	0.61638
`economics_reports_v2`	0.54998	0.54997	0.55534	0.55049
`esg_reports_human_labeled_v2`	0.64921	0.67726	0.68057	0.66734
平均	0.58943	0.60689	0.61139	0.59997

すべてのViDoRe v2ベンチマークで、Mix 2はMix 1とMix 3よりも優れており、より高い解像度を追加するよりも、より異なる解像度を生成する方が優れた結果を生み出すことを示唆しています。4つのベンチマークのうち2つでは、すべての解像度の組み合わせが最適な単一解像度よりも優れており、残りの2つでは、Mix 1のみがパフォーマンスが劣りますが、それほど大きな差はありません。

これらの結果は、すべてのデータに最適な解像度の組み合わせは1つではないものの、最適なソリューションを見つけるには、適切な解像度の組み合わせを特定することが正しい方向であることを示しています。

tag結論

視覚的に豊富な素材を処理する場合、jina-embeddings-v4にとって画像解像度は非常に重要です。重要な問題の1つは、テキストが読みやすいサイズになっている必要があることです。あなたが読めないものは、AIも読めません。テキストが重要な場合は、読み取る必要があります。

ただし、解像度が高すぎると、埋め込みモデルが画像パッチをまとまりのある全体に組み立てることが難しくなります。また、コストもかかります。解像度が高いほど、処理が増え、マルチベクター埋め込みの場合は、ストレージが増え、マッチングが遅くなります。

複数の解像度を使用し、すべての出力に対して遅延インタラクションスタイルのスコアリングを適用することは、サイズが異なる視覚的に豊富な画像を処理するのに適した方法です。ただし、これにより処理コストとストレージコストが増加し、非常に大きな解像度の場合と同様に、検索が遅くなります。

ニューラル検索を改善するために、この洞察を運用化する方法を検討しています。モデルの欠点を調査し、それらを改善する方法を考案するために、トレーニングデータとテストデータを常に多様化しようとしています。さまざまな種類の素材に対する、ここで説明したような解像度とマルチ解像度技術の影響を調査しています。

また、ここで説明したような複数解像度技術が画像のノイズの影響を軽減し、より堅牢な検索を生み出すかどうかを調べる実験も行っています。

さらに、各画像に最適な解像度を事前に自動的に決定することも可能です。最適な解像度を確実に検出できれば、ユーザーのパラメーターを1つ減らしながら、全体的な結果を改善し、埋め込みをよりアクセスしやすく、使いやすくすることができます。