Contacter le service commercial

Oui. Jina est en pleine transition vers une marque de référence. Un peu comme Qwen est devenu Alibaba, GPT est devenu OpenAI, ou Kimi est devenu Moonshot. Nous allons progressivement faire évoluer l'identité juridique de l'entreprise de « Jina AI » à Elastic, permettant ainsi à Jina AI de se concentrer exclusivement sur les modèles de recherche fondamentale.

Des embeddings, des réordonnanceurs et des modèles de langage légers pour une recherche plus performante. Notre mission n'est pas encore accomplie : nous n'avons jamais caché notre ambition de devenir un fournisseur de modèles de recherche de renommée mondiale.

Oui. Les API Reader, Embedding et Reranker continueront d'être développées et maintenues. Chaque modèle publié sera également disponible sur les plateformes de distribution cloud. Vous pouvez continuer à utiliser nos services API comme auparavant. Seule exception : nous ne pouvons pas fournir nos services aux entités ou pays soumis aux contrôles américains à l'exportation.

Oui. Chez Elastic, Jina continuera de repousser les limites des modèles de recherche de base, et nous continuerons de publier des modèles à pondération ouverte.

Nous continuerons à publier sous licence CC-BY-NC 4.0, sauf changement de circonstances, ce qui est peu probable.

Oui. Chaque modèle que nous publierons sera étayé par un article rigoureux, et nous continuerons à soumettre nos travaux à des conférences de premier plan telles que ICLR, EMNLP, SIGIR, NeurIPS et ICML.

Il vous suffit de vous inscrire et de payer via notre site web ou la plateforme de téléchargement cloud appropriée, comme auparavant.

Actuellement, nos produits ne font pas partie des références Elastic ; vous devrez donc toujours effectuer votre paiement via notre site web pour accéder à ces services. Les modèles Jina seront prochainement disponibles via Elastic Inference Service.

Si vous possédez une licence Elastic payante, l'utilisation commerciale de nos modèles est très probablement déjà incluse. Vous pouvez les utiliser immédiatement. En cas de doute, veuillez contacter votre représentant commercial Elastic ou votre ingénieur commercial terrain ; ils se chargeront de nous le confirmer.

Étant donné que nous sommes en cours d'intégration avec Elastic, la marche à suivre sera bientôt plus claire. Pour l'instant, nous ne sommes pas en mesure de proposer des contrats de licence commerciale indépendants pour nos modèles.

Nous n'avons pas d'entité juridique en Chine et ne pouvons donc pas émettre de factures en chinois. Celles-ci sont émises par Jina AI GmbH, notre siège social en Allemagne.

Les contrats à durée déterminée ont toujours représenté une part mineure du modèle commercial de Jina AI ; la plupart de nos clients optent pour une tarification à l’usage. Bien que nous intégrions Elastic, nous n’établissons pas de nouveaux contrats pour le moment.

Contactez votre représentant commercial Elastic, et nous pourrons organiser une réunion entre vous, l'équipe Jina AI et Elastic pour en discuter.

L'API Reader est gratuite pour une utilisation basique : il suffit d'ajouter « https://r.jina.ai/ » au début de votre URL. Pour des limites de requêtes plus élevées, vous pouvez fournir une clé API ; le coût est alors calculé en fonction de la longueur du contenu. Consultez la question 16 pour plus de détails sur les limites de requêtes.

L'API Reader utilise un proxy pour récupérer n'importe quelle URL, rendant son contenu dans un navigateur pour extraire le contenu principal de haute qualité.

Oui, l'API Reader est open source et disponible sur le référentiel Jina AI GitHub.

L'API Reader traite généralement les URL et renvoie le contenu dans un délai de 2 secondes, bien que les pages complexes ou dynamiques puissent nécessiter plus de temps.

Le scraping peut être compliqué et peu fiable, en particulier avec des pages complexes ou dynamiques. L'API Reader fournit une sortie rationalisée et fiable de texte propre et prêt pour LLM.

L'API Reader renvoie le contenu dans la langue d'origine de l'URL. Il ne fournit pas de services de traduction.

Si vous rencontrez des problèmes de blocage, veuillez contacter notre équipe d'assistance pour obtenir de l'aide et une résolution.

Bien qu'elle soit principalement conçue pour les pages Web, l'API Reader peut extraire le contenu des PDF affichés au format HTML sur des sites Web comme arXiv, mais elle n'est pas optimisée pour l'extraction PDF générale.

Oui, Reader peut ajouter des légendes aux images des pages web grâce à l'en-tête `x-with-generated-alt`. Cela permet d'ajouter des balises alt descriptives aux images qui en sont dépourvues, facilitant ainsi la compréhension du contenu visuel par les assistants linguistiques. La synthèse vidéo est prévue dans les prochaines versions.

Non, l'API Reader ne peut traiter que le contenu provenant d'URL accessibles au public.

Si vous demandez la même URL dans les 5 minutes, l'API Reader renverra le contenu mis en cache.

Malheureusement non.

Oui, vous pouvez soit utiliser le support PDF natif du Reader (https://r.jina.ai/https://arxiv.org/pdf/2310.19923v4), soit utiliser la version HTML d'arXiv (https:// r.jina.ai/https://arxiv.org/html/2310.19923v4)

Reader sous-titre toutes les images à l'URL spécifiée et ajoute « Image [idx] : [caption] » comme balise alt (si elles en manquent initialement). Cela permet aux LLM en aval d'interagir avec les images dans le raisonnement, la synthèse, etc.

L'API Reader est conçue pour être hautement évolutive. Il est automatiquement mis à l'échelle en fonction du trafic en temps réel et le nombre maximal de requêtes simultanées est désormais d'environ 4 000. Nous le maintenons activement comme l'un des produits principaux de Jina AI. N'hésitez donc pas à l'utiliser en production.

Veuillez trouver les dernières informations sur les limites de taux dans le tableau ci-dessous. Notez que nous travaillons activement à l'amélioration de la limite de débit et des performances de l'API Reader, le tableau sera mis à jour en conséquence.

ReaderLM-v2 est notre tout dernier modèle de langage léger (SLM) permettant de convertir du HTML brut en Markdown ou JSON propre. Il offre une qualité trois fois supérieure à la version 1 et peut extraire des données structurées à l'aide d'un schéma JSON ou d'instructions en langage naturel. Vous pouvez l'utiliser directement via l'API Reader avec l'en-tête x-respond-with: readerlm-v2, ou le déployer depuis les places de marché cloud (AWS, Azure, GCP).

Utilisez l'en-tête `x-json-schema` avec une définition de schéma JSON, ou l'en-tête `x-instruction` avec des instructions en langage naturel. Ces deux fonctionnalités sont compatibles avec ReaderLM-v2 pour extraire des champs spécifiques (prix, titres, dates, etc.) de n'importe quelle page web et les convertir au format JSON structuré.

Non. Notre service ne cherche pas à contourner les mécanismes de défense des sites web, les systèmes anti-robots ou les contrôles d'accès. Si un site web détecte notre service comme provenant d'un robot et bloque la requête, cette décision est respectée. Nous fonctionnons comme un client web standard et n'utilisons aucune technique visant à échapper aux systèmes de détection.

Non. Le passage d'une version gratuite à une clé API payante ne donne pas accès à des sites web supplémentaires et ne permet pas de contourner les restrictions des sites. La différence entre les versions réside principalement dans les limites de débit et l'optimisation des performances. Une clé API payante offre un débit de requêtes plus élevé et un traitement plus rapide, mais elle ne permet pas d'accéder aux sites web qui bloquent notre service.

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 32 Ko, la recherche dense et la recherche en 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 de type Matriochka. 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 jetons, tandis que `jina-embeddings-v3` et `jina-clip-v2` en prennent en charge jusqu’à 8 192. Un jeton 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 intégrer directement des documents PDF en fournissant une URL 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-clip-v2 et jina-clip-v1 peuvent intégrer à la fois des images et des textes. L'intégration de modèles sur d'autres modalités sera annoncée 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 à analyser, `text-matching` pour la similarité sémantique, `classification` pour la classification de texte et `separation` pour les tâches de clustering.

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

Le découpage tardif est une technique qui consiste à intégrer d'abord l'intégralité du document à l'aide de modèles à contexte long, puis à extraire les représentations vectorielles des segments à partir des tokens. Contrairement au découpage classique (segmentation puis intégration), le découpage tardif 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 tr/min, 100 000 TPM, 2 requêtes simultanées
Payant : 500 tr/min, 2 millions de TPM, 50 requêtes simultanées
Premium : 5 000 tr/min, 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.

La tarification de l'API Reranker est alignée sur celle de notre API Embedding. Elle commence avec 10 millions de jetons gratuits pour chaque nouvelle clé API. Outre ces jetons gratuits, différents packages sont disponibles à l'achat. Pour plus d'informations, veuillez consulter notre section Tarifs.

jina-reranker-v3 est notre tout dernier outil de reclassement phare, doté d'une architecture novatrice par listes, offrant des performances de pointe en matière de recherche multilingue avec une longueur de contexte de 131 000 caractères. jina-reranker-m0 est notre outil de reclassement multimodal permettant de classer des documents visuels dans différentes langues. jina-reranker-v2-base-multilingual est un encodeur croisé prenant en charge plus de 100 langues, avec appels de fonctions et récupération de code. jina-colbert-v2 utilise l'interaction tardive pour 89 langues, avec des tailles d'embeddings configurables par l'utilisateur.

Oui, tous nos outils de réordonnancement (jina-reranker-v3, jina-reranker-m0, jina-reranker-v2-base-multilingual et jina-colbert-v2) sont open source et disponibles sous licence CC-BY-NC 4.0. Vous êtes libre d'utiliser, de partager et d'adapter ces modèles à des fins non commerciales.

Oui, tous nos outils de réévaluation prennent en charge la recherche multilingue. `jina-reranker-v3` et `jina-reranker-v2-base-multilingual` prennent en charge plus de 100 langues. `jina-reranker-m0` prend en charge le classement visuel multilingue des documents. `jina-colbert-v2` prend en charge 89 langues.

La longueur du contexte varie selon le modèle :

jina-reranker-v3 : 131 072 jetons (requête + tous les documents combinés) avec troncature automatique
jina-reranker-m0 : 10 000 jetons
jina-reranker-v2-base-multilingual : 1 024 jetons avec découpage automatique pour les documents longs
jina-reranker-v1-* : 1 024 jetons avec découpage automatique
jina-colbert-v2 : 8 192 jetons

Pour les réorganisateurs v1/v2, les requêtes sont automatiquement tronquées et les documents longs sont découpés en segments avec un regroupement maximal entre les segments.

Il n'y a pas de limite stricte au nombre de documents par requête. À l'instar de notre API Embeddings, l'API Reranker regroupe les entrées en interne par nombre de jetons afin d'optimiser l'utilisation du GPU. Vous pouvez envoyer autant de documents que nécessaire en une seule requête.

La latence varie de 100 millisecondes à 7 secondes, en fonction en grande partie de la longueur des documents et de la requête. Par exemple, le reclassement de 100 documents de 256 jetons chacun avec une requête de 64 jetons prend environ 150 millisecondes. L'augmentation de la longueur du document à 4 096 jetons augmente le temps à 3,5 secondes. Si la longueur de la requête est augmentée à 512 jetons, le temps augmente encore à 7 secondes.

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.

Si vous êtes intéressé par un reranker affiné et adapté à des données de domaine spécifiques, veuillez contacter notre équipe commerciale. Notre équipe répondra à votre demande dans les plus brefs délais.

La taille d'image minimale acceptable pour le modèle jina-reranker-m0 est de 28x28 pixels.

jina-reranker-v3 utilise une architecture novatrice de classement par liste qui évalue tous les documents simultanément en une seule passe, permettant ainsi la comparaison entre documents. Les systèmes de classement ponctuels traditionnels (comme la version 2) évaluent chaque document indépendamment par rapport à la requête. Le classement par liste atteint une précision supérieure en tenant compte de la pertinence relative au sein de l'ensemble des candidats.

Bien que certains de nos modèles de réordonnancement 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) des GPU de notre infrastructure d'inférence. Le traitement de séquences très longues exige une quantité importante de mémoire ; nous optimisons donc 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.

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

Gratuite : 100 RPM, 100 000 TPM, 2 requêtes simultanées
Payante : 500 RPM, 2 millions de TPM, 50 requêtes simultanées
Premium : 5 000 RPM, 50 millions de 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 mêmes limites s’appliquent aux API Embeddings et Reranker.

Oui, la même clé API est valable pour tous les produits de recherche de Jina AI. Cela inclut les API de lecture, d'intégration, de reclassement, de classification et de réglage fin, 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, vos entrées ni vos sorties pour entraîner nos modèles d'embeddings, de reranking ou tout autre modèle. Vos données restent votre propriété. Nous sommes conformes aux normes SOC 2 de type I et de type II.

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 jetons, 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.

DeepSearch est une API LLM qui effectue une recherche, une lecture et un raisonnement itératifs jusqu'à ce qu'elle trouve une réponse précise à une requête ou atteigne sa limite de budget de jetons.

Contrairement à OpenAI et Gemini, DeepSearch se concentre spécifiquement sur la fourniture de réponses précises par itération plutôt que sur la génération d'articles longs. Il est optimisé pour des réponses rapides et précises issues de la recherche sur le Web profond plutôt que pour la création de rapports complets.

Vous avez besoin d'une clé API Jina. Nous offrons 10 millions de jetons gratuits pour les nouvelles clés API.

Il génère une réponse finale basée sur toutes les connaissances accumulées, plutôt que de simplement abandonner ou de renvoyer une réponse incomplète.

Non. Bien qu'il utilise un processus de recherche itératif pour améliorer la précision, l'évaluation montre qu'il atteint un taux de réussite de 75 % aux questions du test, ce qui est nettement meilleur que la référence de 0 % (gemini-2.0-flash) mais pas parfait.

Cela varie considérablement : les requêtes peuvent prendre entre 1 et 42 étapes, avec une moyenne de 4 étapes basées sur les données d'évaluation. Cela représente 20 secondes. Les requêtes simples peuvent être résolues rapidement, tandis que les questions de recherche complexes peuvent impliquer de nombreuses itérations et jusqu'à 120 secondes.

Oui, l'API officielle DeepSearch sur deepsearch.jina.ai/v1/chat/completions est entièrement compatible avec le schéma API OpenAI, en utilisant « jina-deepsearch-v1 » comme nom de modèle. Il est donc très facile de passer d'OpenAI à DeepSearch et de l'utiliser avec des clients locaux ou tout client compatible OpenAI. Nous recommandons vivement Chatwise pour une expérience fluide.

Les limites de débit varient selon le niveau de clé API, allant de 10 à 30 tr/min. Il est important d'en tenir compte pour les applications avec des volumes de requêtes élevés.

DeepSearch encapsule les étapes de réflexion dans des balises XML ... et fournit ensuite la réponse finale, en suivant le format de streaming OpenAI mais avec ces marqueurs spéciaux pour la chaîne de pensées.

Oui. Jina Reader est utilisé pour la recherche et la lecture sur le Web, offrant au système la possibilité d'accéder et de traiter efficacement le contenu Web.

Oui, l'utilisation des tokens de DeepSearch sur les requêtes complexes est sans doute élevée : en moyenne 70 000 tokens contre 500 pour les réponses LLM de base. Cela montre la profondeur de la recherche, mais a également des implications financières.

Le système est principalement contrôlé par le budget de jetons plutôt que par le nombre d'étapes. Une fois le budget de jetons dépassé, il entre en mode Beast pour la génération de la réponse finale. Consultez reasoning_effort pour plus de détails.

Les références sont considérées comme si importantes que si une réponse est jugée définitive mais manque de références, le système continue la recherche plutôt que d'accepter la réponse.

Oui, mais avec des étapes de recherche approfondies. L'exemple de « qui sera président en 2028 » montre que l'on peut répondre à des questions spéculatives grâce à de multiples itérations de recherche, même si l'exactitude de telles prédictions n'est pas garantie.

Le zero-shot nécessite des étiquettes sémantiques pendant la classification et aucune pendant l'apprentissage, tandis que le few-shot nécessite des étiquettes pendant l'apprentissage mais pas la classification. Cela signifie que le zero-shot est plus adapté aux besoins de classification flexibles et immédiats, tandis que le few-shot est plus adapté aux catégories fixes et spécifiques à un domaine qui peuvent évoluer au fil du temps.

num_iters contrôle l'intensité de l'entraînement : les valeurs plus élevées renforcent les exemples importants tandis que les valeurs plus faibles minimisent l'impact des données moins fiables. Il peut être utilisé pour mettre en œuvre l'apprentissage en fonction du temps en donnant aux exemples récents un nombre d'itérations plus élevé, ce qui le rend utile pour faire évoluer les modèles de données.

Les classificateurs publics peuvent être utilisés par toute personne disposant du classifier_id, en utilisant son propre quota de jetons. Les utilisateurs ne peuvent pas accéder aux données de formation ou à la configuration, et ne peuvent pas voir les demandes de classification des autres, ce qui permet un partage sécurisé des classificateurs.

La méthode Few-shot nécessite 200 à 400 exemples d'entraînement pour surpasser la classification Zero-shot. Bien qu'elle atteigne finalement une plus grande précision, elle a besoin de cette période d'échauffement pour devenir efficace. Zero-shot fournit des performances cohérentes immédiatement sans données d'entraînement.

Oui - l'API prend en charge les requêtes multilingues utilisant jina-embeddings-v3 et la classification multimodale (texte/image) utilisant jina-clip-v2 ou jina-embeddings-v4, avec prise en charge des images encodées en URL ou en base64 dans la même requête.

Zero-shot prend en charge 256 classes sans limite de classificateur, tandis que few-shot est limité à 16 classes et 16 classificateurs. Les deux prennent en charge 1 024 entrées par requête et 8 192 jetons par entrée.

Le mode Few-shot permet une mise à jour continue via le point de terminaison /train pour s'adapter aux modèles de données changeants. Vous pouvez ajouter progressivement de nouveaux exemples ou classes lorsque la distribution des données change, sans reconstruire l'intégralité du classificateur.

L'API utilise l'apprentissage en ligne en un seul passage : les exemples de formation mettent à jour les pondérations du classificateur mais ne sont pas stockés par la suite. Cela signifie que vous ne pouvez pas récupérer les données de formation historiques, mais cela garantit la confidentialité et l'efficacité des ressources.

Commencez par un modèle à zéro coup pour obtenir des résultats immédiats et lorsque vous avez besoin d'une classification flexible avec des étiquettes sémantiques. Passez à un modèle à quelques coups lorsque vous avez 200 à 400 exemples, que vous avez besoin d'une plus grande précision ou que vous devez gérer des données spécifiques à un domaine/sensibles au temps.

Oui, vous pouvez choisir entre jina-embeddings-v3 pour la classification de texte (particulièrement adapté au multilingue), jina-clip-v2 pour la classification multimodale (89 langues), ou jina-embeddings-v4 pour la classification multimodale multilingue universelle.

L'utilisation de l'API Segmenter est gratuite. En fournissant votre clé API, vous pouvez accéder à une limite de débit plus élevée et votre clé ne sera pas facturée.

Sans clé API, vous pouvez accéder à l'API Segmenter à une vitesse limite de 20 RPM.

Avec une clé API, vous pouvez accéder à l'API Segmenter à une vitesse limite de 200 RPM. Pour les utilisateurs payants premium, la limite de vitesse est de 1 000 RPM.

Non, votre clé API n'est utilisée que pour accéder à une limite de débit plus élevée.

Oui, l'API Segmenter est multilingue et prend en charge plus de 100 langues.

Les requêtes GET sont uniquement utilisées pour compter le nombre de jetons dans un texte, ce qui vous permet de l'intégrer facilement comme compteur dans votre application. Les requêtes POST prennent en charge davantage de paramètres et de fonctionnalités, telles que le renvoi des N premiers/derniers jetons.

Vous pouvez envoyer jusqu'à 64 000 caractères par demande.

La fonction de découpage segmente les documents longs en morceaux plus petits en fonction d'indices structurels communs, garantissant une segmentation précise du texte en morceaux significatifs. Il s'agit essentiellement d'un (gros !) modèle d'expression régulière qui segmente le texte en fonction de certaines caractéristiques syntaxiques qui correspondent souvent à des limites sémantiques, telles que les fins de phrases, les sauts de paragraphe, la ponctuation et certaines conjonctions. Il ne s'agit pas d'un découpage sémantique. Cette (grosse) expression régulière est aussi puissante qu'elle peut l'être dans les limites des expressions régulières. Elle équilibre complexité et performances. Bien qu'une véritable compréhension sémantique ne soit pas possible avec les expressions régulières, elles se rapprochent bien du contexte grâce à des indices structurels communs.

Si l'entrée contient des jetons spéciaux, notre API Segmenter les placera dans le champ « special_tokens ». Cela vous permet de les identifier facilement et de les gérer en conséquence pour vos tâches en aval, par exemple en les supprimant avant d'introduire le texte dans un LLM pour éviter les attaques par injection.

Outre les langues occidentales, le découpage fonctionne également bien avec le chinois, le japonais et le coréen.

Cette fonctionnalité est actuellement en version bêta et coûte 1 million de jetons par modèle optimisé. Vous pouvez utiliser votre clé API existante de l'API Embedding/Reranker si elle dispose de suffisamment de jetons, ou créer une nouvelle clé API incluant 10 millions de jetons gratuits.

Vous n'avez pas besoin de fournir de données d'entraînement. Décrivez simplement votre domaine cible (le domaine pour lequel vous souhaitez que les intégrations affinées soient optimisées) en langage naturel, ou utilisez une URL comme référence, et notre système générera des données synthétiques pour entraîner le modèle.

Environ 30 minutes.

Les modèles affinés et les données synthétiques sont stockés publiquement dans le hub de modèles Hugging Face.

Le système utilise l'API Reader pour récupérer le contenu de l'URL. Il analyse ensuite le contenu pour résumer le ton et le domaine, qu'il utilise comme lignes directrices pour générer des données synthétiques. Par conséquent, l’URL doit être accessible au public et représentative du domaine cible.

Oui, vous pouvez affiner un modèle pour une langue autre que l'anglais. Le système détecte automatiquement la langue des instructions de votre domaine et génère des données synthétiques en conséquence. Nous vous recommandons également de choisir le modèle de base approprié pour la langue cible. Par exemple, si vous ciblez un domaine allemand, vous devez sélectionner « jina-embeddings-v2-base-de » comme modèle de base.

Non, notre API de réglage fin ne prend en charge que les modèles Jina v2.

À la fin du processus de réglage fin, le système évalue le modèle à l'aide d'un ensemble de tests retenu et rapporte les mesures de performances. Vous recevrez un e-mail détaillant les performances avant/après sur cet ensemble de tests. Vous êtes également encouragé à évaluer le modèle sur votre propre ensemble de tests pour garantir sa qualité.

Le système génère des données synthétiques en intégrant l'instruction du domaine cible que vous fournissez au raisonnement des agents LLM. Il produit des triplets négatifs durs, essentiels à la formation de modèles d’intégration de haute qualité. Pour plus de détails, veuillez vous référer à notre prochain document de recherche sur Arxiv.

Actuellement non. Notez que cette fonctionnalité est toujours en version bêta. Le stockage public des modèles affinés et des données synthétiques dans le hub de modèles Hugging Face nous aide, ainsi que la communauté, à évaluer la qualité de la formation. À l’avenir, nous prévoyons de proposer une option de stockage privé.

Étant donné que tous les modèles affinés sont téléchargés sur Hugging Face, vous pouvez y accéder via SentenceTransformers en spécifiant simplement le nom du modèle.

Veuillez vérifier votre dossier spam. Si vous ne le trouvez toujours pas, veuillez contacter notre équipe d'assistance en utilisant l'adresse e-mail que vous avez fournie.