

私たちは、埋め込みモデルファミリーの第5世代である jina-embeddings-v5-text をリリースします。これにより、1B 未満のパラメータを持つ多言語埋め込みモデルの品質と効率の限界を押し広げます:
- jina-embeddings-v5-text-small (677M パラメータ):MMTEB で 67.0、MTEB English で 71.7
- jina-embeddings-v5-text-nano (239M パラメータ):MMTEB で 65.5、MTEB English で 71.0
small モデルは 32K 詞元のコンテキスト(nano は 8K)、4 つのタスク固有 LoRA アダプター(検索、テキストマッチング、分類、クラスタリング)、および 1024 から 32 までの Matryoshka 次元圧縮をサポートしています。239M パラメータの nano モデルは、2 倍のパラメータを持つモデルの検索品質に匹敵します。
前世代と比較すると、v5-text-small は検索において jina-embeddings-v4 (3.8B) と同等の性能を持ちながらサイズは 5.6 倍小さく、同等のパラメータ数を持つ jina-embeddings-v3 (572M) をすべてのタスクで上回っています。
| 機能 | v5-text-small | v5-text-nano |
|---|---|---|
| ベースモデル | Qwen3-0.6B-Base | EuroBERT-210m |
| パラメータ数 | 677M | 239M |
| 埋め込み次元 | 1024 | 768 |
| コンテキスト長 | 32,768 | 8,192 |
| 言語 | 119 (Qwen3 トークナイザー) | 15+ (EuroBERT トークナイザー) |
| プーリング | Last-token | Last-token |
| LoRA アダプター | 4 (検索、テキストマッチング、分類、クラスタリング) | |
| Matryoshka 次元 | 32-1024 | 32-768 |
| MMTEB スコア | 67.0 | 65.5 |
| MTEB English | 71.7 | 71.0 |
| ライセンス | CC BY-NC 4.0 |
v5-text-small は MMTEB(9 タスクタイプ、131 タスクの平均)で 67.0 を達成し、次点である 1B 未満モデル(指示付き Qwen3-0.6B、64.3)を +2.7 ポイント 上回りました。239M パラメータの nano モデルは 65.5 を記録し、2 倍のパラメータを持つモデルを凌駕しています。v5-text-small が 71.7(7 タスクタイプ、41 タスクの平均)で 1B 未満のすべての多言語モデルをリードし、次いで KaLM-mini-v2.5 (71.3) と v5-text-nano (71.0) が続きます。239M の nano モデルは、半分以下のサイズで 494M の KaLM と同等の性能を達成しています。v5-text-small は、5 つの検索ベンチマーク(MTEB Multilingual、MTEB English、RTEB、BEIR、LongEmbed)全体で最高のタスクレベル平均(63.28)を達成しました。これは 4B 未満のモデルの中で、jina-embeddings-v4 (3.8B, 63.62) に匹敵する性能を持ちながら、5.6 倍小さいサイズです。
jina-embeddings-v5-small (0.6B パラメータ、ランク #8) は MTEB Multilingual v2 において 1B パラメータ未満で最強の埋め込みモデルであり、すべての指標で Qwen3-Embedding-0.6b を上回っています。jina-embeddings-v5-nano (0.2B パラメータ、ランク #11) はそのサイズを大きく上回る性能を発揮しており、このパラメータクラスでこれに近いモデルは存在しません。tagアーキテクチャ

v5-text は、平均プーリングの代わりにラストトークン・プーリングを使用するデコーダーのみのバックボーンを採用しています。各トランスフォーマー層には 4 つの軽量 LoRA アダプターが注入され、検索、テキストマッチング、分類、クラスタリングを個別に処理します。ユーザーは推論時に適切なアダプターを選択します。検索の場合、クエリには「Query:」、ドキュメントには「Document:」というプレフィックスが付与されます。コンテキスト長は small が 32K 詞元(nano は 8K)で、v3 から 4 倍に増加しました。
tagはじめに
tagElastic Inference Service
v5-text を本番環境で最も速く使用する方法です。Elastic Inference Service (EIS) は、スケーリング機能を内蔵したマネージドな埋め込み推論を提供するため、インフラストラクチャを管理することなく、Elastic デプロイメント内で直接埋め込みを生成できます。
PUT _inference/text_embedding/jina-v5
{
"service": "elastic",
"service_settings": {
"model_id": "jina-embeddings-v5-text-small"
}
}
セットアップの詳細については、EIS のドキュメントを参照してください。
tagJina Embedding API
詞元単位の従量課金制で提供されるホスト型 API です。タスク選択、次元圧縮、バッチ処理を標準でサポートしています。GPU は不要です。
curl https://api.jina.ai/v1/embeddings \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_API_KEY" \
-d '{
"model": "jina-embeddings-v5-text-small",
"task": "retrieval.query",
"dimensions": 1024,
"input": ["What is knowledge distillation?"]
}'
API キーの取得は jina.ai/embeddings から行えます。
tagHugging Face + sentence-transformers
推論を完全に制御し、ローカル環境で実行します。重みは Hugging Face で公開されており、sentence-transformers とすぐに統合可能です。
from sentence_transformers import SentenceTransformer
import torch
model = SentenceTransformer(
"jinaai/jina-embeddings-v5-text-small-retrieval",
model_kwargs={"dtype": torch.bfloat16},
)
query_emb = model.encode("What is knowledge distillation?", prompt_name="query")
doc_embs = model.encode(["Knowledge distillation transfers...", "Venus is..."], prompt_name="document")
similarity = model.similarity(query_emb, doc_embs)
tagvLLM
本番環境のワークロード向けに高スループットなサービングを実現します。vLLM は last-token pooling を使用して v5-text をネイティブにサポートしています。
from vllm import LLM
from vllm.config.pooler import PoolerConfig
model = LLM(
model="jinaai/jina-embeddings-v5-text-small-retrieval",
dtype="float16",
runner="pooling",
pooler_config=PoolerConfig(seq_pooling_type="LAST", normalize=True),
)
outputs = model.encode(["Query: climate change impacts"], pooling_task="embed")
llama.cpp や MLX を介した最適化されたローカル推論のために、各タスクアダプターの LoRA 重みはベースモデルにマージされ、スタンドアロンの重みファイルとして出力されます。これが、各タスク(検索、テキストマッチング、分類、クラスタリング)ごとにリポジトリが分かれている理由です。それぞれに完全にマージされた重みが含まれているため、推論時に LoRA のオーバーヘッドなしで直接読み込むことができます。
tagllama.cpp (GGUF)
CPU またはエッジデバイスで量子化されたモデルを実行します。各モデルに対して、F16 から IQ1_S まで 14 種類の GGUF 量子化バリエーションを提供しています。
llama-server -hf jinaai/jina-embeddings-v5-text-small-retrieval-GGUF:Q4_K_M \
--embedding --pooling last -ub 32768
tagMLX
MLX を介した Apple Silicon でのネイティブ推論。すべてのタスクアダプターで、フル精度、4-bit、8-bit 量子化が利用可能です。
import mlx.core as mx
from tokenizers import Tokenizer
from model import JinaEmbeddingModel
import json
with open("config.json") as f:
config = json.load(f)
model = JinaEmbeddingModel(config)
weights = mx.load("model-4bit.safetensors") # または model.safetensors, model-8bit.safetensors
model.load_weights(list(weights.items()))
tokenizer = Tokenizer.from_file("tokenizer.json")
texts = ["Query: What is machine learning?"]
embeddings = model.encode(texts, tokenizer)
Hugging Face からダウンロード: jinaai/jina-embeddings-v5-text-small-retrieval-mlx(テキストマッチング、分類、クラスタリングのアダプターも利用可能)。
tagトレーニング
両モデルとも、より大規模な学習済みベクトルモデルである Qwen3-Embedding-4B から蒸留されています。Small バージョンは Qwen3-0.6B-Base をバックボーンとして使用し、Nano バージョンは EuroBERT-210m を使用しています。トレーニングでは、以下の 2 つの補完的なシグナルを組み合わせています:
- ベクトルモデルの蒸留: コサイン類似度損失を使用して 4B の教師モデルから蒸留します。学生モデルは、命令形式の提示詞を必要とせずに、教師モデルのベクトル空間を近似することを学習します。これは、ラベル付きデータが不足している言語やタスクで特に効果的です。
- タスク固有の対照学習損失(
InfoNCE): ハードネガティブマイニングとバッチ内ネガティブサンプルを用いた、ラベル付きのクエリとドキュメントのペアに対する損失です。蒸留されたバックボーンを固定した後、各タスクカテゴリに対して個別の LoRA アダプターをトレーニングします。
アブレーション研究の結果、この組み合わせ手法は、どちらか一方の手法よりも一貫して優れた結果を出すことが示されています。MTEB の英語検索タスクにおいて、この組み合わせ手法は 60.1 nDCG@10 を達成しました。これに対し、蒸留のみでは 58.6、対照学習のみでは 54.3 となりました(いずれも同一バックボーンを使用)。
また、トレーニング中に GOR (Generalized Orthogonal Regularization) を適用しました。これはベクトル成分をより均一に分散させるよう促すものです。これにより標準的なベンチマークスコアが劇的に向上するわけではありませんが、バイナリ量子化をほぼロスレスにすることができ、メモリ制約のあるデプロイメントにおいて極めて重要な特性となります。
トレーニングから得られた注目すべき観察結果をいくつか挙げます:
- 蒸留と対照学習は、当初予想していなかった形で補完し合っています。
- 損失の混合からコンポーネントを一つでも取り除くと、全体的なパフォーマンスが低下します。
- タスク固有の LoRA アダプターは、無視できる程度のパラメータオーバーヘッドで、マルチタスク学習を上回る性能を発揮します。
- GOR 正則化によりバイナリ量子化がほぼロスレスになることは、フル精度のわずかな向上よりも、デプロイメントにおいて重要です。
tag結論
ベクトルモデルは、大規模なシステム内部のツールチェーンコンポーネントとしてますます使用されるようになっています。大模型 エージェントは、エージェントワークフローの一部として、検索、メモリ、分類のためにベクトルモデル API を呼び出します。OpenClaw や OpenViking といったプロジェクトは、ベクトルモデルをスタンドアロンの検索エンドポイントとしてではなく、エージェントのコンテキスト管理のための主要なインフラストラクチャ層として扱っています。この状況下では、呼び出しあたりの推論コストとレイテンシがベンチマークスコアと同等に重要であり、コンパクトなモデルが自然な選択肢となります。
小型のベクトルモデルへの傾向は、より広範なシフトを反映しています。オンデバイス検索、ブラウザベースの検索、エッジデプロイメントのすべてにおいて、限られたメモリバジェットに収まるモデルが求められています。Matryoshka 次元のサポートにより、再トレーニングなしで、単一のモデルが高精度検索と超高速な近似検索の両方を提供できるようになります。GGUF 量子化による 1-2 ビットへの圧縮を組み合わせることで、本番環境のベクトル検索サービスの実質的なメモリフットプリントは一桁削減されます。
現在、私たちは jina-embeddings-v5-multimodal に取り組んでおり、同じアーキテクチャを視覚やクロスモーダル検索に拡張しています。初期の成果から、テキスト性能を低下させることなく、ビジョンエンコーダーを微調整済みのテキストベクトルモデルにアライメントさせることが可能であることが示唆されています。続報をお待ちください。






