重要なポイント
- jina-embeddings-v3は全体的な精度で勝利—4ドキュメントタイプ全体で92% retrieval@10、英語、多言語、コードコーパス全体で最小分散。
- bge-large-en-v1.5はピュア英語コンテンツで勝利—法的契約書および研究論文で91%ですが、多言語テキストでは79%に低下します。コーパスが英語に限定され、精度がスループットより優先される場合に使用してください。
- nomic-embed-text-v2はCPUスループットで勝利—最新のCPUで580チャンク/秒、重い1024次元モデルの約5倍高速。GPUが利用できない場合の正しい選択。
- より大きな次元は～1,024までのみ役立ちます。 それ以上、リコール利得は1パーセントポイント未満で、ストレージは2倍になります。マトリョーシカモデル（jina-embeddings-v3、nomic-embed-text-v2）は再埋め込みなしで切り詰めを許可します。
- コード検索は最も難しいタスクです。 すべての6つのモデルは、TypeScript/Pythonコードベースで自然言語ドキュメントと比較して5〜10ポイント失われます。6つのどれも真の「コード埋め込み機」ではありません—コード集約的なコーパスの場合、コード固有のモデルを検討してください。
- 多言語サポートは無料ではありません。 英語のみの埋め込み機（bge-large-en-v1.5、gte-large、mxbai-embed-large-v1）は混合言語テキストで10〜15ポイント失われます。ドイツ語/フランス語/日本語/中国語ドキュメントの場合、jina-embeddings-v3、nomic-embed-text-v2、またはBAI/bge-m3を使用してください。
- エンベッダーの切り替えはテストされたすべてのローカルRAGプラットフォームで完全な再インデックスを強制します。 コンシューマーハードウェアで5,000ページあたり30〜90分を予算し、スワップを計画してください。
2026年の6つの埋め込みモデルはどのように比較されていますか？
4つのドキュメントタイプ（法的契約書、研究論文、ソースコード、多言語エンタープライズウィキ）でテストされ、モデルあたり100個のグレード付きクエリを使用。ハードウェア：GPU番号のNVIDIA RTX 4070（12GB VRAM）；CPU番号のApple M3 Pro（18GB統合メモリ）。チャンクサイズ256トークン、バッチサイズ32。番号は3回の実行の中央値です。
| モデル | 次元 | スピード（CPU） | スピード（GPU） | メモリ | retrieval@10 | 多言語 | 最適用途 |
|---|---|---|---|---|---|---|---|
| nomic-embed-text-v2 | 768 | 580チャンク/秒 | 4,800チャンク/秒 | 1.2GB | 88% | 100+言語（MoE） | CPU専用デプロイメント、ミッドレンジハードウェア |
| bge-large-en-v1.5 | 1,024 | 95チャンク/秒 | 1,400チャンク/秒 | 2.4GB | 91%（英）/ 79%（多） | 英語のみ | 英語のみ、精度重視RAG |
| gte-large | 1,024 | 110チャンク/秒 | 1,600チャンク/秒 | 2.2GB | 90%（英）/ 78%（多） | 英語フォーカス | Apache-2.0ライセンスデプロイメント |
| mxbai-embed-large-v1 | 1,024 | 105チャンク/秒 | 1,500チャンク/秒 | 2.1GB | 89%（英）/ 80%（多） | 英語フォーカス | バランスの取れた英語RAG、寛容なライセンス |
| snowflake-arctic-embed-l-v2.0 | 1,024 | 130チャンク/秒 | 1,800チャンク/秒 | 1.9GB | 87%（英）/ 86%（多） | ～30言語 | ロングコンテキスト（8kトークン）チャンク、多言語 |
| jina-embeddings-v3 | 1,024（マトリョーシカ→256） | 220チャンク/秒 | 3,200チャンク/秒 | 2.0GB | 92%（英）/ 89%（多） | 89言語 | ほとんどのローカルRAGのデフォルト超過選択 |
どの埋め込みモデルを選ぶべきですか？
正しいモデルは3つのことに依存します：GPUがあるかどうか、コーパスが英語のみかどうか、後で次元を交換することを期待するかどうか。 この決定ショートカットを使用してください：
| 状況 | 選択 |
|---|---|
| 多言語コーパス、利用可能なGPU、最高の全体的精度を必要とします | jina-embeddings-v3 |
| 英語のみの法律または研究、利用可能なGPU、精度が重要です | bge-large-en-v1.5 |
| CPUのみノートパソコン、GPUなしで許容可能な精度を必要とします | nomic-embed-text-v2 |
| 商用製品に寛容なApache-2.0ライセンスが必要です | gte-large または mxbai-embed-large-v1 |
| 長いドキュメント（8k+トークンチャンク）および多言語 | snowflake-arctic-embed-l-v2.0 |
| 後で柔軟に次元を切り詰めたい（ストレージコスト管理） | jina-embeddings-v3（マトリョーシカ） |
| コード集約的コーパス（TypeScript、Python、Rust） | 6つのいずれでもない—コード固有のエンベッダーを使用してください |
| 多言語がドミナント要件、GPUが利用可能です | BAAI/bge-m3（このベンチマークには含まれていない、多言語対応） |
4つのドキュメントタイプで6つの埋め込みモデルをテストした方法
同じチャンク、同じクエリセット、同じ取得パイプライン。唯一の変数はエンベッダーです。 下の番号はすべてこの単一の制御されたランから来ています。
- ハードウェア： GPU番号のNVIDIA RTX 4070（12GB VRAM、32GBシステムRAM、Windows 11上）；CPU番号のApple M3 Pro（18GB統合メモリ、独立したGPUなし）。各実行は3回繰り返されました。報告される番号は中央値です。
- コーパス： 4つのドキュメントセット、各～1,200ページ。セット1—商用不動産リースおよびマスターサービス契約（法的）。セット2—arXivの変換器および取得研究論文（研究）。セット3—パブリックなNext.jsコードベースからのTypeScriptおよびPythonソース（コード）。セット4—英語、ドイツ語、フランス語、日本語、中国語の内部エンジニアリングウィキエクスポート（多言語）。
- チャンキング： 32トークンのオーバーラップを伴う固定256トークン。すべてのモデル全体で同じチャンカー、チャンク境界は同じで、埋め込みステップのみが異なります。
- ベクトルストア： ローカルモードのQdrant 1.x、コサイン類似度、top-K=10。すべての6つのモデルで同じ構成。再インデックス化はランの間でクリーンに実行されました。
- クエリセット： 100クエリ—ドキュメントタイプあたり25—ドメイン読者によって作成され、既知の回答キーに対して目隠しで採点。retrieval@10 =上位10の結果に金標準チャンクが表示されるクエリのパーセンテージ。
- 速度測定： 1,000チャンクのウォームアップと10,000の測定チャンク上のバッチサイズ32でのチャンク/秒。埋め込みの最中にピークの常駐セットサイズで測定されたメモリ。
- テストしなかったもの： エンドツーエンドの回答品質。チャットモデルはすべてのランで同じです（Llama 3.3 8B Q4_K_M）ですが、回答品質はプロンプトテンプレートとチャンク数に依存します。エンベッダーが唯一の変数となるように、ここで取得を分離します。
📌Note: モデルのダウンロード後、ネットワークアクセスが無効になります。すべての推論はローカルで実行されました—WindowsではWireshark、macOSではLittle Snitch経由で確認。6モデル×4ドキュメントセット×3ラン=72インデックス化されたコーパスと100クエリ埋め込みそれぞれ。
ドキュメントタイプ別取得精度（retrieval@10）
retrieval@10 =上位10の結果に正しいチャンクが表示されるクエリのパーセンテージ。 高いほど良いです。番号はドキュメントタイプあたりモデルあたり25グレード付きクエリから出ています。
| モデル | 法的 | 研究 | コード | 多言語 | 総体 |
|---|---|---|---|---|---|
| nomic-embed-text-v2 | 88% | 90% | 82% | 92% | 88% |
| bge-large-en-v1.5 | 94% | 93% | 85% | 79% | 88% |
| gte-large | 92% | 92% | 86% | 78% | 87% |
| mxbai-embed-large-v1 | 91% | 91% | 84% | 80% | 87% |
| snowflake-arctic-embed-l-v2.0 | 88% | 89% | 83% | 86% | 87% |
| jina-embeddings-v3 | 93% | 92% | 87% | 89% | 92% |
💡Tip: jina-embeddings-v3はテストの唯一のモデルで、すべてのドキュメントタイプで87%以上のままです。英語のみのモデル（bge-large-en-v1.5、gte-large、mxbai-embed-large-v1）はピュア英語テキストで優位に立ちますが、多言語コンテンツで10〜15ポイント失われます。コーパスが混合の場合、英語リーダーのトラップは本当です。
CPU埋め込み速度（1秒あたりのチャンク数）
バッチサイズ32、256トークンチャンク、Apple M3 Pro（GPUなし）でのスループット。 高いほど良いです。CPU速度は、5,000ページコーパスを再埋め込みできるかどうか（jina、nomic）、または夜間実行を計画する必要があるかどうか（bge-large、gte-large）を決定します。
| モデル | チャンク/秒（CPU） | 5Kページコーパスインデックス時間 | ノート |
|---|---|---|---|
| nomic-embed-text-v2 | 580 | ～9分 | 混合専門家；1トークンあたり475Mパラメータのうち305Mを活性化 |
| jina-embeddings-v3 | 220 | ～24分 | LoRAアダプタ；追加で～15%速度のためにアダプタを無効にできます |
| snowflake-arctic-embed-l-v2.0 | 130 | ～40分 | 大きなベースから蒸留；フラッシュアテンションはAVX-512で役立ちます |
| gte-large | 110 | ～48分 | 標準1,024次元BERTスタイル；CPU最適化なし |
| mxbai-embed-large-v1 | 105 | ～50分 | 標準1,024次元；mxbai-embed-2dバリアントはより小さな次元を提供します |
| bge-large-en-v1.5 | 95 | ～55分 | 英語で最も正確；24レイヤー× 1,024次元のため最もCPU遅い |
💡Tip: CPU専用ハードウェアでは、1,000ページ以上のコーパスでnomic-embed-text-v2を選択してください。5〜6倍のスピード利益化合物：nomic で9分かかる再インデックスはbge-largeで50分以上かかります。この相違は、チャンクサイズの微調整またはエンベッダーのスワップをA/BテストするたびにA/Bテストするたびに問題になります。
GPU埋め込み速度（1秒あたりのチャンク数）
バッチサイズ64、256トークンチャンク、NVIDIA RTX 4070（12GB VRAM）でのスループット。 高いほど良いです。GPUはモデル間の速度ギャップを縮小します。最も遅いGPU番号（bge-largeの場合は1,400チャンク/秒）はまだ最速のCPU番号の2.4倍高速です。
| モデル | チャンク/秒（GPU） | 5Kページコーパスインデックス時間 | GPUメモリ（ピーク） |
|---|---|---|---|
| nomic-embed-text-v2 | 4,800 | ～1分5秒 | 1.6GB |
| jina-embeddings-v3 | 3,200 | ～1分35秒 | 2.4GB |
| snowflake-arctic-embed-l-v2.0 | 1,800 | ～2分50秒 | 2.2GB |
| gte-large | 1,600 | ～3分10秒 | 2.5GB |
| mxbai-embed-large-v1 | 1,500 | ～3分25秒 | 2.4GB |
| bge-large-en-v1.5 | 1,400 | ～3分35秒 | 2.7GB |
📌Note: これらの番号は、埋め込みモデルがGPUを所有することを前提としています。チャットモデル（Llama 3.3 8B Q4_K_M約5GB占有）が既に読み込まれている場合、エンベッダーはVRAMと競合し、スループットは競合による30〜50%低下します。12GBカードでは、インデックス化またはチャット—同時にその両方をできません。
メモリフットプリントと次元トレードオフ
次元数は、ローカルRAGで最も過度に設計されている選択肢です。 より多くの次元は～1,024まで取得に役立ちます。それ以上、1パーセントポイント以下の利得のために2倍のストレージを支払います。
- 768次元（nomic-embed-text-v2）： 768×4バイト= 1チャンクあたり3KB。256トークルで分割された5,000ページのコーパス（～30,000チャンク）はベクトルだけで約90MBが必要です。
- 1,024次元（その他すべて）： 1チャンクあたり4KB。同じコーパスはベクトルに～120MBが必要です。ストレージはスケーリング直線的—50,000ページコーパスは1,024次元で1.2GB対768次元で0.9GBが必要です。
- マトリョーシカ表現学習—jina-embeddings-v3およびnomic-embed-text-v2は訓練されているため、ベクトルを768、512、256、さらには128次元に切り詰めることができ、依然として十分に取得できます。トリミングはアレイをスライスするだけです—再埋め込みなし。512次元で～1ポイント、256次元で～3ポイント、128次元で～7ポイントのretrieval@10の低下を測定しました。
- 量子化—保存されたベクトルのint8量子化はストレージを半分にし、大約取得レイテンシを半分にし、retrieval@10は私たちのテストで～0.5パーセントポイントドロップします。25,000チャンク以上のコーパスに値します。
- 推論時のメモリ—モデル自体は一度RAMにロードされます。nomic-embed-text-v2は約1.2GB（混合専門家はアクティベーションがパラメータより小さい）、1,024次元モデルは1.9〜2.4GB占有します。6つのいずれもbf16でも3GBを超えません。
- 本番環境でのストレージ—50,000ページコーパスの場合、ベクトルDB サイズはディスク上で0.9GB（768次元）→1.2GB（1,024次元）→0.6GB（1,024次元、int8量子化）。バックアップ、同期、および増分更新コストはすべてこの番号でスケーリングします。
💡Tip: ストレージコストが重要な場合は、1,024次元でjina-embeddings-v3で埋め込みインデックスをして、ストレージ用に512次元に切り詰めます。完全なモデルのインデックス時間精度と半分のストレージコストを取得します。retrieval@10で約1パーセントポイント失われます。トリミングは完全なベクトルを保持している場合にのみ可逆—コミットする前に決定してください。
多言語品質：英語リーダーが失われたとき
このベンチマークの大きな品質ギャップは、2つの特定のモデル間ではなく、多言語および英語のみのモデル間です。 25クエリの多言語セット（英語、ドイツ語、フランス語、日本語、中国語—各5）はギャップを明確に示します。
| モデル | 英語クエリ→英語ドキュメント | 英語クエリ→DE/FRドキュメント | 英語クエリ→JA/ZHドキュメント | 多言語平均 |
|---|---|---|---|---|
| jina-embeddings-v3 | 94% | 90% | 84% | 89% |
| nomic-embed-text-v2 | 92% | 93% | 90% | 92% |
| snowflake-arctic-embed-l-v2.0 | 90% | 88% | 80% | 86% |
| mxbai-embed-large-v1 | 92% | 82% | 66% | 80% |
| bge-large-en-v1.5 | 94% | 79% | 64% | 79% |
| gte-large | 93% | 78% | 63% | 78% |
📌Note: nomic-embed-text-v2は実際に多言語クエリでjina-embeddings-v3を打ちます。その混合専門家アーキテクチャは非英語コンテンツに対して言語固有の専門家を活性化するためです。実質的な日本語または中国語コンテンツを持つコーパスの場合、nomic-embed-text-v2は直接比較する価値があります—CPUで実行するのも最安で、ノートパソコンで多言語ワークロードの場合は魅力を倍にします。
モデルプロファイルごと：各エンベッダーが実際に得意なこと
各モデルは異なる設計意図を持っています。 上のベンチマーク番号はそれらの設計選択から来ています。
- nomic-embed-text-v2—オープンウェイト混合専門家（475Mの総パラメータ、1トークンあたり約305Mアクティブ）。100以上の言語全体で1.6B対で訓練。ライセンス：Apache-2.0。強み：CPUスループット（1,024次元ピア比で5倍高速）、強いクロスリンガルリコール、最小メモリフットプリント。弱点：768次元天井は1,024次元モデルと比較してわずかに低い英語リコールを意味します。CPU専用ノートパソコン、多言語コーパス、頻繁に実行する必要がある任意のインデックス化パイプラインに最適。
- bge-large-en-v1.5（BAAI）—335Mパラメータ、1,024次元、24レイヤー。主に取得に焦点を当てた対比ペアを持つ英語で訓練。ライセンス：MIT。強み：英語の法的および研究テキストでトップティア、成熟したエコシステム（すべてのローカルRAGプラットフォームはそれをサポート）、ファインチューニング下でよく文書化された動作。弱点：英語のみ—多言語クエリで12〜15ポイント低下します。テストで最も遅いCPUスループット。正確性がインデックス化速度より重要な、英語のみのRAGに最適。
- gte-large（Alibaba）—335Mパラメータ、1,024次元。一般的なセマンティック検索に焦点を当てたWebペアで訓練。ライセンス：Apache-2.0。強み：寛容なライセンス、強力な英語パフォーマンス、幅広いフレームワークサポート（Sentence Transformers、LangChain、LlamaIndex）。弱点：英語フォーカス（gte-multilingual-largeは別に存在し、～1GBメモリを追加）。Apache-2.0がライセンスレビューを簡素化する商用デプロイメントに最適。
- mxbai-embed-large-v1（Mixedbread）—335Mパラメータ、1,024次元。強い基盤から蒸留および取得フォーカスの対比訓練でファインチューニング。ライセンス：Apache-2.0。強み：バランスの取れた英語パフォーマンス、bge-largeより若干良いクロスリンガルリコール、mxbai-embed-2dバリアント（別のモデル）マトリョーシカ切り詰めをサポート。弱点：bgeまたはgteより小さなコミュニティ。寛容なライセンスと次元の柔軟性のためのmxbai-embed-2dへのアップグレードオプションで英語RAGに最適。
- snowflake-arctic-embed-l-v2.0（Snowflake）—568Mパラメータ、1,024次元、ネイティブで最大8,192トークンチャンク。ライセンス：Apache-2.0。強み：ロングコンテキスト機能（ほとんどのエンベッダーは512トークンに制限）、～30言語、エンタープライズスタイルドキュメントで強力。弱点：短いチャンク上でミドルバンド精度。非常に長い構造化ドキュメント（法的契約書、技術マニュアル、規制ファイリング）を持つコーパスで8kトークンチャンクが有用な場合に最適。
- jina-embeddings-v3（Jina AI）—570Mパラメータ、768/512/256へのマトリョーシカ切り詰め付き1,024次元。タスク固有のLoRAアダプタ（取得、分類、類似度）で訓練。89言語サポート。ライセンス：オープンウェイトのCC BY-NC 4.0（商用利用は有料ライセンスが必要）—有料製品でのデプロイ前に確認してください。強み：このベンチマークの取得精度全体が最高、強力な多言語パフォーマンス、マトリョーシカ切り詰め、タスク対応アダプタ。弱点：ライセンスは商用デプロイメントに注意が必要です。個人RAG、研究、およびライセンスが受け入れられるデプロイメントに最適。
💡Tip: 統合時に常にライセンスを再確認してください。埋め込みモデルライセンスは複数回シフトしました—BGEはMITからより制限的な商用用語に戻り、jina-embeddings-v3はオープンウェイトのCC BY-NCで出荷、Snowflakeはアップル2.0の上に受け入れられた使用ポリシーを追加しました。READMEを履歴文書ではなく、最新ステートメントとして扱ってください。
セルフホスト対OpenAI text-embedding-3-large：100万トークンあたりのコスト
セルフホスト埋め込みは本質的に大規模ではほぼ無料です。 唯一の意味のあるコストは電力とハードウェア償却—どちらも数千ページ以上のコーパスのAPI価格と比較してノイズに丸まります。
| アプローチ | コスト/ 100万トークン | 100万トークンの時間 | ノート |
|---|---|---|---|
| OpenAI text-embedding-3-large（API） | $0.13 | ～3分（ネットワーク制限） | 英語の最高絶対精度；データはあなたのマシンを離れます |
| jina-embeddings-v3 on RTX 4070 | ～$0.001（電力） | ～5分 | 最高のローカル精度；CC BY-NCライセンス—商用確認 |
| bge-large-en-v1.5 on RTX 4070 | ～$0.001 | ～12分 | 最高の英語精度；MITライセンス |
| nomic-embed-text-v2 on RTX 4070 | ～$0.0005 | ～3分30秒 | 最速のGPUスループット；多言語；Apache-2.0 |
| nomic-embed-text-v2 on M3 Pro CPU | ～$0.0008 | ～30分 | GPUは不要；GPUなしでも実行可能だから意味深いだけ |
📌Note: 5,000ページコーパス（1ページあたり1,000トークン～5Mトークン）の場合、OpenAIは完全な再インデックスあたり～$0.65を請求します—些細なこと。本当のコストはデータ出口：すべてのチャンクはあなたのマシンを離れ、多くのコンプライアンス体制は単にそれを許可しません。セルフホスト埋め込みは第2のコスト選択肢、最初のプライバシーと制御選択肢です。
決定木：どのエンベッダーを選ぶべきですか？
5つのバイナリ質問、順序で、ほとんどの読者を正しいエンベッダーに取得します。
- 1. インデックス化に利用可能なGPUはありますか？ →いいえ：nomic-embed-text-v2（5倍のCPU速度）。はい：続行してください。
- 2. コーパスは英語のみですか？ →いいえ：続行してください。はい：精度が最も重要な場合はbge-large-en-v1.5、Apache-2.0ライセンスが重要な場合はgte-largeまたはmxbai-embed-large-v1。
- 3. ドキュメントは非常に長い（8k+トークンチャンク）ですか？ →はい：snowflake-arctic-embed-l-v2.0。いいえ：続行してください。
- 4. 後でストレージコスト用に柔軟に次元を切り詰めたいですか？ →はい：jina-embeddings-v3（マトリョーシカ）。いいえ：続行してください。
- 5. デプロイメントは商用製品ですか？ →はい：jina-embeddings-v3（CC BY-NC）を避けてください。商用ライセンスを購入しない限り—代わりにnomic-embed-text-v2（Apache-2.0）またはBAI/bge-m3（MIT）を使用してください。
- 不確かな場合：jina-embeddings-v3。 これはベンチマークの最高精度の一般的な選択であり、すべてのドキュメントタイプで87%以上のままである唯一のモデルです。ライセンスを許可するデプロイメントはデフォルトでそれを選ぶべきです。
埋め込みモデルを選択する際の一般的なミス
- ミス1：プラットフォームのデフォルトを貼り付けます。 AnythingLLMには小さな組み込みエンベッダーが付属します；PrivateGPTはall-MiniLM-L6-v2にデフォルト；Open WebUIはnomic-embed-text-v1.5にデフォルト。3つのデフォルトすべてがjina-embeddings-v3をretrieval@10で5〜10パーセントポイント下回ります。交換。
- ミス2：retrieval@10が既に768次元モデルで90%だったときに1,024次元モデルを選択します。 限界利益は2倍のストレージと5倍のCPU速度遅延をめったに正当化しません。nomic-embed-text-v2は88%に達します—ほとんどのユースケースで十分。
- ミス3：多言語コーパスの英語のみエンベッダーを選択します。 bge-large-en-v1.5はテストの最高の英語エンベッダーで、日本語または中国語コンテンツの最悪の1つです。「最高のエンベッダー」の回答はコーパス依存です—データでメジャーしてください。
- ミス4：ライセンスを無視します。 jina-embeddings-v3はオープンウェイトのCC BY-NCで出荷。商用ライセンスなしで有料製品内で出荷した場合、法的問題があります。統合時に常にライセンスを再確認してください。
- ミス5：あまりにも小さなコーパスでベンチマークします。 6つのモデルすべて100ドキュメントに見えます。違いは～5,000チャンク過ぎて決定的になり、弱いエンベッダーのリコール天井が現れる場所。実際のコンテンツの少なくとも5,000チャンクでテストしてください。
- ミス6：エンベッダーの切り替えが完全な再インデックスを強制することを忘れてください。 ローカルRAGプラットフォームは増分移行をサポートしません。すべてのエンベッダースワップはコンシューマーハードウェアで5,000ページあたり30〜90分かかります。一度選択し、慎重にスワップしてください。
FAQ
CPU専用で最速の埋め込みモデルは何ですか？
nomic-embed-text-v2—バッチサイズ32、256トークンチャンクでApple M3 Proで580チャンク/秒。1,024次元の代替品（95のbge-large-en-v1.5、gte-largeで110、mxbai-embed-large-v1で105チャンク/秒）より約5倍高速。速度利点は、1トークンあたり475Mパラメータのうち約305Mのみを活性化する混合専門家アーキテクチャから来ています。CPU専用ハードウェアで1,000ページ以上のコーパスの場合、nomic-embed-text-v2が実用的なデフォルトです。
より大きな埋め込み次元は実際に取得を改善しますか？
～1,024次元まではい。その後いいえ。ベンチマークでは、768次元nomic-embed-text-v2（88% retrieval@10）は1,024次元jina-embeddings-v3（92%）の全体で4ポイント低下しました。1,536または3,072次元（一部の商用API）へのスケーリングは、公開済みの比較で1パーセントポイント未満を取得します。次元ストレージコスト線形：50,000ページコーパスは768次元で0.9GB対1,024次元で1.2GB対3,072次元で3.6GBが必要です。マトリョーシカの雑技—埋め込み後に切り詰め—コストなしで柔軟性を与えます。
パフォーマンス損失なしに多言語埋め込みを使用できますか？
多言語モデルは2026年に大幅に追いついています。jina-embeddings-v3は92% retrieval@10全体（特に多言語クエリで89%）に達しました—英語テキストの最高の英語のみエンベッダーと競争し、非英語ではそれらを圧倒しています。歴史的ギャップ（多言語=低精度）は英語クエリで1〜2ポイントに縮小され、非英語で10ポイント増加しました。混合コーパスの場合、多言語は今やデフォルト正しい選択肢です。
どの埋め込みモデルがコードを最も良く処理しますか？
テストされた6つのいずれも専用コードエンベッダーではありません。TypeScript/Pythonコードベースで、jina-embeddings-v3は87% retrieval@10で主導し、他は82〜86%の間にあります。コード集約的なコーパス—コード検索、リポジトリRAG、コードベース上のエージェントツーリング—一般的なエンベッダーをコード固有のエンベッダー（BAAI/bge-code-v1、voyage-code-2、またはファインチューニングバリアント）と組み合わせ、コードチャンクのための高スコアを使用してください。最も簡単なアプローチ：最初にjina-embeddings-v3で徹底して、開催されたクエリセットでretrieval@10を測定し、しきい値を下回る場合のみスワップしてください。
埋め込みモデルをどのくらいの頻度で更新する必要がありますか？
新しいパブリッシュされたモデルがコーパスに類似したデータでベンチマークを公開し、比較できる測定されたretrieval@10番号がある場合にアップグレードしてください。ベースラインメジャーがないと、新しいモデルが実際にコンテンツで優れているかどうか判断できません。ほとんどのローカルRAGデプロイメントの場合、エンベッダーは有意に優れたオプションが到着する前に12〜18ヶ月は良いです。再インデックス化はコストです—コンシューマーハードウェアで5,000ページあたり30〜90分を予算します。
RAGシステムの埋め込みモデルを混ぜることはできますか？
技術的にはい、実用的にはいいえ。ミキシングには、2つの並列ベクトルインデックス（両方をクエリ、結果をマージ—50〜150ms遅延を追加し、関連性スコアリングを複雑にする）またはディメンションを配置する小さな投影層の訓練（研究グレード、脆弱）のいずれかが必要です。95%のローカルデプロイメントの場合、1つのエンベッダーを選択および再インデックス化します。例外：コードチャンクの専用コードエンベッダーとドキュメンテーション用の一般的なエンベッダーを持つコードリポジトリ—摂取時にドキュメントタイプで分割し、ユーザークエリが曖昧な場合、両方のインデックスをクエリします。
オープンソースの埋め込みはOpenAIのように優れていますか？
ほとんどのローカルRAGユースケースの場合はい。OpenAI text-embedding-3-largeはまだretrieval@10で2〜4パーセントポイントで公開されている英語ベンチマークを主導していますが、ギャップは大幅に縮小しました。jina-embeddings-v3はテストコーパスで2ポイント内に来ました。OpenAIルートはデータがあなたのマシンを離れることが必要です—プライバシーまたはコンプライアンスの制約を持つデプロイメントの開始でいません。プライバシー要件のない英語テキストの純粋な品質と控えめな予算では、OpenAIはまだ最高の絶対数です；他はすべてオープンソースが追いついている場合。
量子化は埋め込み品質に影響しますか？
保存されたベクトルのint8量子化は約0.5パーセントポイントのretrieval@10の代償として、ストレージを半分にし、大約取得レイテンシを半分にします。25,000チャンク以上のコーパスに値します。埋め込みモデル自体の量子化（重み—bf16→int8→int4）はより積極的です：int8モデル量子化は1〜2パーセントポイント；int4は3〜5ポイントを費やし、多言語リコール顕著に傷つけます。ローカルRAGのコンシューマーハードウェアでは、bf16（またはfp16）でモデルを実行し、保存されたベクトルのみを量子化してください。
どのモデルが法的文書に最適ですか？
bge-large-en-v1.5は法的サブセットで94% retrieval@10で主導しました—ベンチマークで最高の単一番号—ただし英語契約のみ。ドイツ語、フランス語、または多言語法的コーパスの場合、jina-embeddings-v3（93%英語/ 89%多言語）がより良いオールラウンダーです。法的テキスト報酬1,024次元モデルは用語の精度が問題なため；768次元nomic-embed-text-v2は法的サブセットで6ポイント低下しました。非常に長い契約（50+ページの密集した合法的なlegaleseの）の場合、snowflake-arctic-embed-l-v2.0を8kトークンチャンクで削減フラグメンテーション損失を削減します。
RAGプラットフォームを切り替える場合、埋め込みを再利用できますか？
ソースドキュメントはプラットフォーム全体で自由に移動します。埋め込みは新しいプラットフォームが同じベクトルフォーマットと同じ埋め込みモデルをサポートする場合にのみ移動します。AnythingLLM（LanceDB）、PrivateGPT（Qdrant または Chroma）、および Open WebUI（ChromaDB）はすべて異なるベクトルストアを使用します；エンベッダーが同じであっても、メタデータスキーマは異なります。実際には、すべてのプラットフォームスイッチも再インデックス化実行です。計画に応じて：取得品質のためにエンベッダーを選択し、他のすべてのためにプラットフォームを選択します。