Migration des embeddings Jina v2 vers v3

• Lors de l'utilisation de late_chunking=True, le nombre total de tokens (sommé sur tous les segments dans input) par requête est limité à 8192, la longueur maximale de contexte autorisée pour v3.
• Lors de l'utilisation de late_chunking=False, cette limite de tokens ne s'applique pas, et le total des tokens n'est restreint que par la limite de débit de l'API Embedding.

Pour activer le late chunking, passez late_chunking=True dans vos appels API.

Vous pouvez voir l'avantage du late chunking en recherchant dans un historique de conversation :

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."
]
Copier

Si nous demandons What's a good restaurant? avec Embeddings v2, les résultats ne sont pas très pertinents :

Avec v3 et sans late chunking, nous obtenons des résultats similaires :

Cependant, nous constatons une amélioration marquée des performances en utilisant v3 et le late chunking, avec le résultat le plus pertinent (un bon restaurant) en tête :

Comme vous pouvez le voir, même si la meilleure correspondance ne mentionne pas du tout le mot "restaurant", le late chunking préserve son contexte d'origine et le présente comme la meilleure réponse. Il encode "restaurant" dans le nom du restaurant "Bella Italia" car il comprend sa signification dans le texte plus large.

tagÉquilibrez l'efficacité et les performances avec les Matryoshka Embeddings

Le paramètre dimensions dans Embeddings v3 vous donne la possibilité d'équilibrer l'efficacité du stockage avec les performances à un coût minimal. Les embeddings Matryoshka de v3 vous permettent de tronquer les vecteurs produits par le modèle, réduisant les dimensions autant que nécessaire tout en conservant les informations utiles. Les embeddings plus petits sont idéaux pour économiser de l'espace dans les bases de données vectorielles et améliorer la vitesse de récupération. Vous pouvez estimer l'impact sur les performances en fonction de la réduction des dimensions :

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

response = requests.post(url, headers=headers, json=data)
Copier

tagFAQ

tagJe découpe déjà mes documents avant de générer les embeddings. Le late chunking offre-t-il un avantage par rapport à mon propre système ?

Le late chunking offre des avantages par rapport au pré-découpage car il traite d'abord l'ensemble du document, préservant les relations contextuelles importantes dans le texte avant de le diviser en segments. Cela produit des embeddings plus riches en contexte, ce qui peut améliorer la précision de la récupération, en particulier dans les documents complexes ou longs. De plus, le late chunking peut aider à fournir des réponses plus pertinentes lors de la recherche ou de la récupération, car le modèle a une compréhension holistique du document avant de le segmenter. Cela conduit à de meilleures performances globales par rapport au pré-découpage, où les segments sont traités indépendamment sans contexte complet.

tagPourquoi v2 est-il meilleur en classification par paires que v3, et devrais-je m'en inquiéter ?

La raison pour laquelle les modèles v2-base-(zh/es/de) semblent plus performants en classification par paires (PC) est principalement due à la façon dont le score moyen est calculé. Dans v2, seul le chinois est considéré pour les performances PC, où le modèle embeddings-v2-base-zh excelle, conduisant à un score moyen plus élevé. Les benchmarks de v3 incluent quatre langues : chinois, français, polonais et russe. En conséquence, son score global apparaît plus bas par rapport au score chinois uniquement de v2. Cependant, v3 égale ou surpasse toujours les modèles comme multilingual-e5 dans toutes les langues pour les tâches PC. Cette portée plus large explique la différence perçue, et la baisse de performance ne devrait pas être une préoccupation, en particulier pour les applications multilingues où v3 reste très compétitif.

tagv3 surpasse-t-il vraiment les modèles bilingues v2 dans leurs langues spécifiques ?

En comparant v3 aux modèles bilingues v2, la différence de performance dépend des langues et des tâches spécifiques.

Les modèles bilingues v2 étaient hautement optimisés pour leurs langues respectives. Par conséquent, dans les benchmarks spécifiques à ces langues, comme la classification par paires (PC) en chinois, v2 peut montrer des résultats supérieurs. C'est parce que la conception de embeddings-v2-base-zh était spécifiquement adaptée à cette langue, lui permettant d'exceller dans ce domaine restreint.

Cependant, v3 est conçu pour un support multilingue plus large, gérant 89 langues et étant optimisé pour une variété de tâches avec des adaptateurs LoRA spécifiques aux tâches. Cela signifie que bien que v3 puisse ne pas toujours surpasser v2 dans chaque tâche spécifique pour une langue donnée (comme PC pour le chinois), il tend à avoir de meilleures performances globales lorsqu'il est évalué sur plusieurs langues ou sur des scénarios plus complexes et spécifiques aux tâches comme la récupération et la classification.

Pour les tâches multilingues ou lors du travail sur plusieurs langues, v3 offre une solution plus équilibrée et complète, tirant parti d'une meilleure généralisation entre les langues. Cependant, pour les tâches très spécifiques à une langue où le modèle bilingue était finement ajusté, v2 pourrait conserver un avantage.

En pratique, le bon modèle dépend des besoins spécifiques de votre tâche. Si vous ne travaillez qu'avec une langue particulière et que v2 était optimisé pour celle-ci, vous pouvez encore voir des résultats compétitifs avec v2. Mais pour des applications plus générales ou multilingues, v3 est probablement le meilleur choix en raison de sa polyvalence et de son optimisation plus large.

tagPourquoi v2 est-il meilleur en résumé que v3, et dois-je m'en inquiéter ?

v2-base-en est plus performant en résumé (SM) car son architecture était optimisée pour des tâches comme la similarité sémantique, qui est étroitement liée au résumé. En revanche, v3 est conçu pour prendre en charge un plus large éventail de tâches, particulièrement dans les tâches de récupération et de classification, et est plus adapté aux scénarios complexes et multilingues.

Cependant, cette différence de performance en SM ne devrait pas être une préoccupation pour la plupart des utilisateurs. L'évaluation SM est basée sur une seule tâche de résumé, SummEval, qui mesure principalement la similarité sémantique. Cette tâche seule n'est pas très informative ni représentative des capacités plus larges du modèle. Puisque v3 excelle dans d'autres domaines critiques comme la récupération, il est probable que la différence de résumé n'aura pas d'impact significatif sur vos cas d'utilisation réels.