Intégrations

Pour des informations détaillées sur nos processus de formation, nos sources de données et nos évaluations, veuillez vous référer à nos rapports techniques sur arXiv pour jina-embeddings-v3 et jina-embeddings-v4.

jina-embeddings-v4 est notre dernier modèle multimodal universel (3,8 milliards de paramètres) prenant en charge le texte et les images avec un contexte de 32K, la recherche dense et la recherche à interaction tardive, et des performances de pointe sur les documents visuellement riches. jina-clip-v2 est une option plus légère (865 millions de paramètres) prenant en charge 89 langues avec une résolution d'image de 512x512 et des représentations Matryoshka. Les deux excellent dans les tâches de recherche texte-texte, texte-image et image-image.

Les modules jina-embeddings-v4 et jina-embeddings-v3 prennent tous deux en charge 89 langues et offrent d'excellentes performances multilingues. Parmi les 30 langues les plus utilisées figurent : l'arabe, le bengali, le chinois, le danois, le néerlandais, l'anglais, le finnois, le français, le géorgien, l'allemand, le grec, l'hindi, l'indonésien, l'italien, le japonais, le coréen, le letton, le norvégien, le polonais, le portugais, le roumain, le russe, le slovaque, l'espagnol, le suédois, le thaï, le turc, l'ukrainien, l'ourdou et le vietnamien. Le module jina-clip-v2 prend également en charge 89 langues pour les tâches multimodales.

La longueur du contexte varie selon le modèle : jina-embeddings-v4 prend en charge jusqu'à 32 000 tokens, tandis que jina-embeddings-v3 et jina-clip-v2 en prennent en charge jusqu'à 8 192. Un token peut aller d'un seul caractère à un mot entier. Ce contexte étendu permet une analyse documentaire complète et une meilleure compréhension du contexte pour les données textuelles volumineuses.

Il n'y a pas de limite stricte au nombre d'éléments par requête. L'API regroupe les entrées en interne par nombre de jetons pour une utilisation optimale du GPU. Vous pouvez envoyer autant de textes ou d'images que nécessaire dans une seule requête.

Pour jina-embeddings-v4, jina-clip-v2 et jina-clip-v1, vous pouvez utiliser url ou bytes dans le champ input de la requête API. Pour url, indiquez l'URL de l'image à traiter. Pour bytes, encodez l'image au format base64. jina-embeddings-v4 peut également encoder directement des documents PDF en fournissant une URL de PDF ou des octets PDF encodés en base64.

jina-embeddings-v4 est notre tout dernier modèle phare, atteignant l'état de l'art en matière de recherche de documents visuellement riches (ViDoRe) et sur des benchmarks multimodaux. Pour les tâches textuelles uniquement, jina-embeddings-v3 surpasse OpenAI et Cohere sur les benchmarks MTEB anglais et multilingue, tout en étant plus compact et plus efficace. Les deux modèles prennent en charge l'apprentissage par représentation Matryoshka (MRL), permettant une réduction de la dimensionnalité (jusqu'à 32 pour v3 et 128 pour v4) sans perte de performance significative.

La transition est simplifiée, car notre point de terminaison d'API correspond aux schémas JSON d'entrée et de sortie du modèle text-embedding-3-large d'OpenAI. Cette compatibilité garantit que les utilisateurs peuvent facilement remplacer le modèle OpenAI par le nôtre lorsqu'ils utilisent le point de terminaison d'OpenAI.

Les jetons sont calculés en fonction de la longueur du texte et de la taille de l'image. Pour le texte de la requête, les jetons sont comptabilisés de manière standard. Pour les images, les étapes suivantes sont suivies : 1. Taille des tuiles : Chaque image est divisée en tuiles. Pour jina-embeddings-v4, les tuiles mesurent 28 x 28 pixels, pour jina-clip-v2, 512 x 512 pixels, et pour jina-clip-v1, 224 x 224 pixels. 2. Couverture : Le nombre de tuiles nécessaires pour couvrir l'image d'entrée est calculé. Même si les dimensions de l'image ne sont pas parfaitement divisibles par la taille de la tuile, les tuiles partielles sont comptées comme des tuiles complètes. 3. Nombre total de tuiles : Le nombre total de tuiles couvrant l'image détermine le coût. Par exemple, une image de 600 x 600 pixels serait couverte par 22 x 22 tuiles (484 tuiles) dans jina-embeddings-v4, par 2 x 2 tuiles (4 tuiles) dans jina-clip-v2 et par 3 x 3 tuiles (9 tuiles) dans jina-clip-v1. 4. Calcul du coût : Pour jina-embeddings-v4, chaque tuile coûte 10 jetons, pour jina-clip-v2, chaque tuile coûte 4 000 jetons, tandis que pour jina-clip-v1, chaque tuile coûte 1 000 jetons. Exemple : Pour une image de 600 x 600 pixels : • Avec jina-embeddings-v4 • L’image est divisée en tuiles de 28 x 28 pixels. • Le nombre total de tuiles requises est de 22 (horizontales) x 22 (verticales) = 484 tuiles. • Le coût de jina-embeddings-v4 sera de 484 x 10 = 4 840 jetons. • Avec jina-clip-v2 • L'image est divisée en tuiles de 512 x 512 pixels. • Le nombre total de tuiles requises est de 2 (horizontales) x 2 (verticales) = 4 tuiles. • Le coût de jina-clip-v2 sera de 4 x 4 000 = 16 000 jetons. • Avec jina-clip-v1 • L'image est divisée en tuiles de 224 x 224 pixels. • Le nombre total de tuiles requises est de 3 (horizontales) x 3 (verticales) = 9 tuiles. • Le coût de jina-clip-v1 sera de 9*1000 = 9000 jetons.

Oui, jina-embeddings-v4, jina-clip-v2 et jina-clip-v1 peuvent encoder à la fois des images et des textes. Des modèles d'embeddings couvrant davantage de modalités seront annoncés prochainement !

Pour toute question concernant le réglage fin de nos modèles avec des données spécifiques, veuillez nous contacter pour discuter de vos besoins. Nous sommes ouverts à l’exploration de la manière dont nos modèles peuvent être adaptés pour répondre à vos besoins.

Oui, nos services sont disponibles sur les marketplaces AWS, Azure et GCP. Si vous avez des besoins spécifiques, veuillez nous contacter à sales AT jina.ai.

Le paramètre task dans jina-embeddings-v3 et jina-embeddings-v4 active les adaptateurs LoRA spécifiques à la tâche pour des performances optimales. Utilisez retrieval.query pour les requêtes de recherche, retrieval.passage pour les documents à indexer, text-matching pour la similarité sémantique, classification pour la classification de texte et separation pour les tâches de clustering.

jina-embeddings-v4 prend en charge la recherche dense (vecteur unique) et à interaction tardive (vecteurs multiples) via le paramètre output_type. L'interaction tardive préserve des informations plus fines au niveau des tokens, ce qui améliore la précision de la recherche pour les requêtes complexes. jina-colbert-v2 est un modèle dédié à l'interaction tardive.

Le late chunking est une technique qui consiste à encoder d'abord l'intégralité du document à l'aide de modèles à contexte long, puis à extraire les embeddings des segments à partir des représentations au niveau des tokens. Contrairement au découpage naïf (segmentation puis encodage), le late chunking préserve le contexte inter-segments, améliorant ainsi la recherche pour les applications RAG. Activez-le via le paramètre late_chunking dans jina-embeddings-v3.

Bien que certains de nos modèles d'intégration soient conçus pour traiter des contextes plus longs, l'API peut imposer des limites inférieures en raison des contraintes de mémoire vidéo (VRAM) du GPU dans notre infrastructure d'inférence. Le traitement de séquences très longues exige une quantité importante de mémoire, et nous optimisons notre configuration de service afin d'équilibrer débit, latence et coût pour la plupart des cas d'utilisation. Si vous avez besoin d'une prise en charge étendue des contextes, veuillez contacter notre équipe commerciale pour discuter des options de déploiement dédiées.

Le modèle jina-embeddings-v4 est basé sur le modèle Qwen2-VL, distribué sous licence de recherche Qwen. Cette licence autorise uniquement la recherche et une utilisation non commerciale ; nous ne pouvons donc pas commercialiser jina-embeddings-v4. Par conséquent, l'accès au modèle est gratuit via notre API. jina-embeddings-v4 peut sembler plus lent que d'autres modèles pour deux raisons : premièrement, il est nettement plus volumineux que jina-embeddings-v3, ce qui implique un temps de calcul plus important par requête ; deuxièmement, l'impossibilité de commercialiser ce modèle nous oblige à limiter le débit de l'API afin de maîtriser les coûts d'infrastructure. Les utilisateurs ne doivent donc pas s'attendre à un débit élevé ou de niveau production avec l'API jina-embeddings-v4. Pour les charges de travail de production nécessitant un débit plus élevé, nous recommandons d'utiliser jina-embeddings-v3 ou de déployer jina-embeddings-v4 sur votre propre infrastructure via Hugging Face.

Les limites de débit dépendent du type de votre clé API :

Gratuit : 100 RPM, 100 000 TPM, 2 requêtes simultanées
Payant : 500 RPM, 2 millions de TPM, 50 requêtes simultanées
Premium : 5 000 RPM, 50 millions de TPM, 500 requêtes simultanées

De plus, une limite de débit de 10 000 requêtes par adresse IP et par période de 60 secondes est appliquée afin de prévenir les abus. Si vous avez besoin de limites supérieures, veuillez contacter notre équipe commerciale.

Chaque modèle a une longueur de contexte maximale par entrée :

jina-embeddings-v4 : 32 768 jetons
jina-embeddings-v3 : 8 192 jetons
jina-embeddings-v2-* : 8 192 jetons
jina-clip-v1/v2 : 8 192 jetons
jina-colbert-v1/v2 : 8 192 jetons
jina-code-embeddings-* : 32 768 jetons

Les entrées dépassant la limite renverront une erreur, sauf si truncate: true est défini, ce qui tronque automatiquement à la longueur maximale.

Taille maximale des fichiers : Images : 5 Mo, PDF : 8 Mo. Les fichiers plus volumineux seront rejetés et un message d’erreur s’affichera.

Oui, la même clé API est valable pour tous les produits Search Foundation de Jina AI. Cela inclut les API Reader, Embeddings, Reranker, Classifier et de fine-tuning, avec des jetons partagés entre tous les services.

Oui, l'utilisation des jetons peut être surveillée dans l'onglet « Clé API et facturation » en saisissant votre clé API, ce qui vous permet d'afficher l'historique d'utilisation récent et les jetons restants. Si vous êtes connecté au tableau de bord de l'API, ces détails peuvent également être consultés dans l'onglet « Gérer la clé API ».

Si vous avez égaré une clé rechargée et souhaitez la récupérer, veuillez contacter le support AT jina.ai avec votre adresse e-mail enregistrée pour obtenir de l'aide. Il est recommandé de vous connecter pour conserver votre clé API en toute sécurité et facilement accessible.

Non, nos clés API n'ont pas de date d'expiration. Cependant, si vous pensez que votre clé a été compromise et souhaitez la retirer, veuillez contacter notre équipe d'assistance pour obtenir de l'aide. Vous pouvez également révoquer votre clé dans le tableau de bord de gestion des clés API.

Oui, vous pouvez transférer des jetons d'une clé premium vers une autre. Après vous être connecté à votre compte sur le tableau de bord de gestion des clés API, utilisez les paramètres de la clé que vous souhaitez transférer pour déplacer tous les jetons payants restants.

Oui, vous pouvez révoquer votre clé API si vous pensez qu'elle a été compromise. La révocation d'une clé la désactivera immédiatement pour tous les utilisateurs qui l'ont stockée, et tout le solde restant et les propriétés associées seront définitivement inutilisables. Si la clé est une clé premium, vous avez la possibilité de transférer le solde restant payé vers une autre clé avant la révocation. Notez que cette action ne peut pas être annulée. Pour révoquer une clé, accédez aux paramètres de clé dans le tableau de bord de gestion des clés API.

Cela est dû au fait que notre architecture sans serveur décharge certains modèles pendant les périodes de faible utilisation. La requête initiale active ou « réchauffe » le modèle, ce qui peut prendre quelques secondes. Après cette activation initiale, les requêtes suivantes sont traitées beaucoup plus rapidement.

Non. Nous n'utilisons jamais vos requêtes API, entrées ou sorties pour entraîner nos modèles d'embedding, de reranker ou tout autre modèle. Vos données vous appartiennent.

Des limites de débit s'appliquent par clé API :

Gratuit : 100 RPM, 100 000 TPM, 2 requêtes simultanées
Payant : 500 RPM, 2 M TPM, 50 requêtes simultanées
Premium : 5 000 RPM, 50 M TPM, 500 requêtes simultanées

Il existe également une limite de débit basée sur l'adresse IP de 10 000 requêtes par 60 secondes. Ces limites s'appliquent à toutes les API Jina (Embeddings, Reranker, Reader, etc.).

Il n'y a aucune limite de taille de lot pour les API Embeddings et Reranker. Vous pouvez envoyer autant d'éléments ou de documents que nécessaire par requête. Les deux API traitent les entrées par lots en interne, en fonction du nombre de tokens, pour une utilisation optimale du GPU.

Notre modèle de tarification est basé sur le nombre total de jetons traités, ce qui donne aux utilisateurs la possibilité d'attribuer ces jetons à un nombre illimité de phrases, offrant ainsi une solution rentable pour diverses exigences d'analyse de texte.

Nous offrons un essai gratuit aux nouveaux utilisateurs, comprenant dix millions de jetons utilisables avec tous nos modèles, grâce à une clé API générée automatiquement. Une fois la limite de jetons gratuits atteinte, les utilisateurs peuvent facilement acheter des jetons supplémentaires pour leurs clés API via l'onglet « Acheter des jetons ».

Non, les jetons ne sont pas déduits pour les demandes ayant échoué.

Les paiements sont traités via Stripe, prenant en charge diverses méthodes de paiement, notamment les cartes de crédit, Google Pay et PayPal, pour votre commodité.

Oui, une facture sera émise à l'adresse e-mail associée à votre compte Stripe lors de l'achat de tokens.