Jina Embeddings v2 から v3 への移行

• late_chunking=True を使用する場合、(input のすべてのチャンクを合計した）トークンの総数はv3で許可される最大コンテキスト長の8192に制限されます。
• late_chunking=False を使用する場合、このトークン制限は適用されず、トークンの総数は Embedding APIのレート制限 によってのみ制限されます。

late chunking を有効にするには、APIコールで late_chunking=True を渡します。

チャット履歴を検索することで、late chunking の利点を確認できます：

history = [
    "Sita, have you decided where you'd like to go for dinner this Saturday for your birthday?",
    "I'm not sure. I'm not too familiar with the restaurants in this area.",
    "We could always check out some recommendations online.",
    "That sounds great. Let's do that!",
    "What type of food are you in the mood for on your special day?",
    "I really love Mexican or Italian cuisine.",
    "How about this place, Bella Italia? It looks nice.",
    "Oh, I've heard of that! Everyone says it's fantastic!",
    "Shall we go ahead and book a table there then?",
    "Yes, I think that would be a perfect choice! Let's call and reserve a spot."
]
コピー

Embeddings v2 で What's a good restaurant? と尋ねた場合、結果はあまり関連性がありません：

v3 で late chunking を使用しない場合も、同様の結果が得られます：

しかし、v3 と late chunking を使用すると、最も関連性の高い結果（良いレストラン）が上位に来るという顕著な性能向上が見られます：

ご覧のように、上位の一致には「restaurant」という単語が全く含まれていませんが、late chunking によって元のコンテキストが保持され、正しい上位の回答として提示されています。より大きなテキスト内での意味を理解するため、「restaurant」をレストラン名「Bella Italia」に符号化しています。

tagMatryoshka Embeddings で効率性とパフォーマンスのバランスを取る

Embeddings v3 の dimensions パラメータにより、最小限のコストで保存効率とパフォーマンスのバランスを取ることができます。v3 の Matryoshka embeddings では、モデルが生成するベクトルを切り捨て、有用な情報を保持しながら必要な分だけ次元を削減できます。小さな埋め込みは、ベクターデータベースの容量を節約し、検索速度を向上させるのに理想的です。次元の削減量に基づいてパフォーマンスへの影響を推定できます：

data = {
    "model": "jina-embeddings-v3",
    "task": "text-matching",
    "dimensions": 768, # デフォルトは1024
    "input": [
        "The Force will be with you. Always.",
        "力量与你同在。永远。",
        "La Forza sarà con te. Sempre.",
        "フォースと共にあらんことを。いつも。"
    ]
}

response = requests.post(url, headers=headers, json=data)
コピー

tagFAQ

tag埋め込みを生成する前に文書をチャンク分割していますが、Late Chunking は独自のシステムと比べて利点がありますか？

Late chunking は、文書全体を最初に処理してからチャンクに分割するため、プリチャンキングよりも利点があります。テキスト全体の重要なコンテキスト関係を保持し、より文脈的に豊かな埋め込みを生成します。これにより、特に複雑な長文書での検索精度が向上します。さらに、モデルが文書を分割する前に全体的な理解を持っているため、検索や取得時により関連性の高い応答を提供できます。これは、チャンクが独立して処理され、完全なコンテキストを持たないプリチャンキングと比較して、全体的なパフォーマンスの向上につながります。

tagなぜv2はv3よりもペア分類で優れているのか、そして心配する必要がありますか？

v2-base-(zh/es/de) モデルがペア分類（PC）でより良いパフォーマンスを示しているように見える主な理由は、平均スコアの計算方法にあります。v2では、embeddings-v2-base-zh モデルが優れている中国語のみがPC性能の対象となり、より高い平均スコアとなっています。v3のベンチマークには中国語、フランス語、ポーランド語、ロシア語の4言語が含まれています。その結果、v2の中国語のみのスコアと比較すると、全体的なスコアは低く見えます。ただし、v3は依然としてPC タスクにおいて multilingual-e5 のようなモデルと同等かそれ以上のパフォーマンスを示しています。この広範な対象範囲が認識される差を説明しており、特に v3 が競争力を維持している多言語アプリケーションでは、パフォーマンスの低下を懸念する必要はありません。

tagv3は本当にv2のバイリンガルモデルの特定言語を上回るのですか？

v3とv2のバイリンガルモデルを比較する場合、パフォーマンスの差は特定の言語とタスクに依存します。

v2のバイリンガルモデルはそれぞれの言語に高度に最適化されていました。その結果、中国語のペア分類（PC）など、それらの言語に特化したベンチマークでは、v2がより優れた結果を示す場合があります。これは、embeddings-v2-base-zh の設計がその言語に特化していたため、その狭い範囲で優れた性能を発揮できたためです。

しかし、v3は89言語をサポートし、タスク固有のLoRAアダプターで様々なタスクに最適化された、より広範な多言語サポートを目的として設計されています。つまり、v3は特定の言語の個々のタスク（中国語のPCなど）では常にv2を上回るわけではありませんが、複数の言語にわたる評価や、検索や分類などのより複雑なタスク固有のシナリオでは、全般的により良いパフォーマンスを示す傾向があります。

多言語タスクや複数の言語を扱う場合、v3は言語間のより良い一般化を活用した、よりバランスの取れた包括的なソリューションを提供します。ただし、バイリンガルモデルが細かく調整された言語固有のタスクでは、v2が優位性を保持する可能性があります。

実際には、適切なモデルはタスクの具体的なニーズによって異なります。特定の言語のみを扱い、v2がその言語に最適化されている場合、v2でも競争力のある結果が得られる可能性があります。しかし、より一般的な、または多言語アプリケーションの場合、その汎用性と広範な最適化により、v3がより良い選択となる可能性が高いでしょう。

tagなぜv2はv3より要約が優れているのか、そしてこれを心配する必要がありますか？

v2-base-en は要約に密接に関連する意味的類似性などのタスクに最適化されたアーキテクチャを持っているため、要約（SM）でより良いパフォーマンスを示します。対照的に、v3は検索や分類タスクを中心により広範なタスクをサポートするように設計されており、複雑な多言語シナリオにより適しています。

ただし、SMでのこのパフォーマンスの差はほとんどのユーザーにとって懸念する必要はありません。SM評価は、主に意味的類似性を測定するSummEvalという1つの要約タスクのみに基づいています。このタスク単独ではモデルの幅広い機能を示す情報としては十分ではありません。v3は検索など他の重要な分野で優れているため、要約の違いは実際の使用ケースに大きな影響を与えることはないでしょう。