Voyage rerank-3-lite est l’édition axée sur la latence de la série Rerank 3 de Voyage. Il reçoit une requête textuelle et des documents candidats, évalue conjointement chaque paire requête-document et retourne les scores de pertinence dans l’ordre du classement. Il sert de deuxième étape de recherche : un système de récupération par plongements ou par mots-clés trouve les candidats, puis Lite affine leur ordre. Le résultat est un classement à utiliser dans la recherche ou un flux de génération augmentée par récupération.
Ce qui change dans Rerank 3 Lite Le fournisseur souligne une meilleure récupération sur les longs documents et le code par rapport à rerank-2.5-lite. Les deux éditions Rerank 3 conservent le suivi des consignes et la même classe de contexte de 32K, tandis que Lite est conçu pour les applications sensibles à la latence. Cela en fait un candidat pratique pour la recherche interactive dans une base de connaissances, la récupération de documents de soutien et la recherche de code lorsque les utilisateurs ont besoin de résultats pertinents rapidement. Choisissez-le selon les exigences de qualité et de temps de réponse de la collection réelle, plutôt que de supposer qu’une édition plus petite signifie une fenêtre de contexte plus petite.
Guider la pertinence avec la requête Des consignes en langage naturel peuvent accompagner la requête pour expliquer ce qui est pertinent. Gardez la question et la préférence de pertinence concises et cohérentes. Pour une recherche de soutien logiciel, utilisez « Trouver la procédure de réinitialisation d’un appareil; privilégier les consignes pour la révision matérielle indiquée. » Pour un nom de produit ambigu, incluez la catégorie de produit afin que les sens sans rapport ne dominent pas. Une préférence dans la requête guide le score sémantique; utilisez les métadonnées explicites de la collection pour choisir le bon produit, la version du document ou la portée d’accès avant de constituer la liste de candidats.
Préparer une liste restreinte de candidats textuels Les documents d’entrée sont des chaînes de caractères. Extrayez du texte lisible du contenu source et conservez les titres, les en-têtes, les identifiants et le contexte environnant utiles. Maintenez une correspondance stable entre chaque position d’entrée et l’enregistrement original. Pour un article de dépannage, incluez le symptôme et la procédure pertinente, plutôt qu’une simple phrase isolée. Pour la recherche de code source, incluez la fonction et l’information voisine nécessaire pour la distinguer de fonctions portant un nom semblable. Retirez la navigation répétitive ou le texte passe-partout lorsqu’ils prennent la place du passage utile.
Le modèle de reclassement ne peut réordonner que les documents qu’il reçoit. Si la première recherche ne récupère jamais l’article pertinent, cette étape ne peut pas retrouver ce candidat manquant. Examinez la liste restreinte et l’ordre final lorsqu’un résultat semble erroné. Lorsqu’un long document couvre plusieurs sujets, séparez les sections cohérentes et conservez leurs références au document parent afin de pouvoir choisir une section pertinente sans perdre sa source.
Limites de contexte et de requête Le guide actuel du fabricant précise un maximum de 8 000 jetons pour la requête et un maximum combiné de 32 000 jetons pour la requête et chaque document individuel. Il permet jusqu’à 1 000 documents candidats et un budget total de requête de 600 000 jetons, calculé comme le nombre de jetons de la requête multiplié par le nombre de documents, plus tous les jetons des documents. Une longue requête consomme donc de l’espace dans chaque paire et contribue plusieurs fois au budget global. Comptez le texte soumis avec le segmenteur en jetons approprié au modèle plutôt que de traiter les caractères, les mots et les jetons comme interchangeables.
Par exemple, une requête de 500 jetons avec 100 documents de 4 000 jetons chacun représente 450 000 jetons d’entrée selon cette formule. Cela illustre la budgétisation, et non une taille de liste recommandée ni un résultat de vitesse mesuré. L’option de troncature documentée est activée par défaut; le texte trop long peut être raccourci avant l’attribution des scores. Préparez délibérément les sections importantes pour que la troncature ne retire pas le passage même que vous devez trouver.
Lire et utiliser le résultat Les résultats sont triés du score de pertinence le plus élevé vers le plus faible. Chaque résultat identifie la position d’entrée originale du document, ce qui permet à l’application d’y joindre son titre, son identifiant d’enregistrement et sa source. Le paramètre top_k contrôle le nombre de candidats classés retournés; sans lui, tous les candidats sont retournés. L’interface REST du fabricant peut aussi retourner le texte des documents. Conservez les identifiants d’origine avec les résultats sélectionnés lorsque vous affichez une page de recherche ou transmettez des éléments à une étape de génération de réponse.
Un score de pertinence exprime la correspondance d’un candidat avec la requête; il n’établit pas l’exactitude des affirmations du candidat. Comparez les premiers éléments à la véritable question de l’utilisateur, y compris les exclusions et les différences de versions de documents. Si tous les candidats sont non pertinents, il existe tout de même un premier élément au classement. Déterminez comment votre application traite ce cas à l’aide de requêtes représentatives de la collection.
Mettre à niveau et choisir l’édition Le fabricant décrit rerank-3-lite comme une mise à niveau de rerank-2.5-lite avec une sémantique d’API inchangée et des scores calibrés selon la distribution du prédécesseur correspondant. Conservez la correspondance existante des enregistrements et l’étape de récupération, puis comparez l’ordre obtenu sur des requêtes significatives avant de vous fier à un seuil de score établi. Utilisez Lite pour une expérience de recherche où le temps de réponse compte; utilisez l’édition rerank-3 axée sur la qualité comme comparaison lorsque la pertinence de candidats difficiles est la priorité principale.
", "aboutText": "Voyage rerank-3-lite est l’édition axée sur la latence de la série Rerank 3 de Voyage. Il reçoit une requête textuelle et des documents candidats, évalue conjointement chaque paire requête-document et retourne les scores de pertinence dans l’ordre du classement. Il sert de deuxième étape de recherche : un système de récupération par plongements ou par mots-clés trouve les candidats, puis Lite affine leur ordre. Le résultat est un classement à utiliser dans la recherche ou un flux de génération augmentée par récupération.\n\nCe qui change dans Rerank 3 Lite\nLe fournisseur souligne une meilleure récupération sur les longs documents et le code par rapport à rerank-2.5-lite. Les deux éditions Rerank 3 conservent le suivi des consignes et la même classe de contexte de 32K, tandis que Lite est conçu pour les applications sensibles à la latence. Cela en fait un candidat pratique pour la recherche interactive dans une base de connaissances, la récupération de documents de soutien et la recherche de code lorsque les utilisateurs ont besoin de résultats pertinents rapidement. Choisissez-le selon les exigences de qualité et de temps de réponse de la collection réelle, plutôt que de supposer qu’une édition plus petite signifie une fenêtre de contexte plus petite.\n\nGuider la pertinence avec la requête\nDes consignes en langage naturel peuvent accompagner la requête pour expliquer ce qui est pertinent. Gardez la question et la préférence de pertinence concises et cohérentes. Pour une recherche de soutien logiciel, utilisez « Trouver la procédure de réinitialisation d’un appareil; privilégier les consignes pour la révision matérielle indiquée. » Pour un nom de produit ambigu, incluez la catégorie de produit afin que les sens sans rapport ne dominent pas. Une préférence dans la requête guide le score sémantique; utilisez les métadonnées explicites de la collection pour choisir le bon produit, la version du document ou la portée d’accès avant de constituer la liste de candidats.\n\nPréparer une liste restreinte de candidats textuels\nLes documents d’entrée sont des chaînes de caractères. Extrayez du texte lisible du contenu source et conservez les titres, les en-têtes, les identifiants et le contexte environnant utiles. Maintenez une correspondance stable entre chaque position d’entrée et l’enregistrement original. Pour un article de dépannage, incluez le symptôme et la procédure pertinente, plutôt qu’une simple phrase isolée. Pour la recherche de code source, incluez la fonction et l’information voisine nécessaire pour la distinguer de fonctions portant un nom semblable. Retirez la navigation répétitive ou le texte passe-partout lorsqu’ils prennent la place du passage utile.\n\nLe modèle de reclassement ne peut réordonner que les documents qu’il reçoit. Si la première recherche ne récupère jamais l’article pertinent, cette étape ne peut pas retrouver ce candidat manquant. Examinez la liste restreinte et l’ordre final lorsqu’un résultat semble erroné. Lorsqu’un long document couvre plusieurs sujets, séparez les sections cohérentes et conservez leurs références au document parent afin de pouvoir choisir une section pertinente sans perdre sa source.\n\nLimites de contexte et de requête\nLe guide actuel du fabricant précise un maximum de 8 000 jetons pour la requête et un maximum combiné de 32 000 jetons pour la requête et chaque document individuel. Il permet jusqu’à 1 000 documents candidats et un budget total de requête de 600 000 jetons, calculé comme le nombre de jetons de la requête multiplié par le nombre de documents, plus tous les jetons des documents. Une longue requête consomme donc de l’espace dans chaque paire et contribue plusieurs fois au budget global. Comptez le texte soumis avec le segmenteur en jetons approprié au modèle plutôt que de traiter les caractères, les mots et les jetons comme interchangeables.\n\nPar exemple, une requête de 500 jetons avec 100 documents de 4 000 jetons chacun représente 450 000 jetons d’entrée selon cette formule. Cela illustre la budgétisation, et non une taille de liste recommandée ni un résultat de vitesse mesuré. L’option de troncature documentée est activée par défaut; le texte trop long peut être raccourci avant l’attribution des scores. Préparez délibérément les sections importantes pour que la troncature ne retire pas le passage même que vous devez trouver.\n\nLire et utiliser le résultat\nLes résultats sont triés du score de pertinence le plus élevé vers le plus faible. Chaque résultat identifie la position d’entrée originale du document, ce qui permet à l’application d’y joindre son titre, son identifiant d’enregistrement et sa source. Le paramètre top_k contrôle le nombre de candidats classés retournés; sans lui, tous les candidats sont retournés. L’interface REST du fabricant peut aussi retourner le texte des documents. Conservez les identifiants d’origine avec les résultats sélectionnés lorsque vous affichez une page de recherche ou transmettez des éléments à une étape de génération de réponse.\n\nUn score de pertinence exprime la correspondance d’un candidat avec la requête; il n’établit pas l’exactitude des affirmations du candidat. Comparez les premiers éléments à la véritable question de l’utilisateur, y compris les exclusions et les différences de versions de documents. Si tous les candidats sont non pertinents, il existe tout de même un premier élément au classement. Déterminez comment votre application traite ce cas à l’aide de requêtes représentatives de la collection.\n\nMettre à niveau et choisir l’édition\nLe fabricant décrit rerank-3-lite comme une mise à niveau de rerank-2.5-lite avec une sémantique d’API inchangée et des scores calibrés selon la distribution du prédécesseur correspondant. Conservez la correspondance existante des enregistrements et l’étape de récupération, puis comparez l’ordre obtenu sur des requêtes significatives avant de vous fier à un seuil de score établi. Utilisez Lite pour une expérience de recherche où le temps de réponse compte; utilisez l’édition rerank-3 axée sur la qualité comme comparaison lorsque la pertinence de candidats difficiles est la priorité principale.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "c68d4d2d48caae2b02910c49670cbc10f4a73e889b258d733203188ff3d2144a", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "fr-ca", "methods": [ { "html": "voyageai/rerank-3-liteVoyage rerank-3-lite attribue des scores aux documents textuels candidats et les reclasse selon une requête, en privilégiant la réactivité de la recherche. Il prend en charge les consignes de pertinence et une fenêtre requête-document de 32 000 jetons, utile après la récupération vectorielle ou par mots-clés dans les flux de recherche et de RAG.
Cette description présente les capacités du modèle. Les entrées, sorties et options disponibles dans Ailoot pour la méthode sélectionnée figurent ci-dessous.
Voyage rerank-3-lite est l’édition axée sur la latence de la série Rerank 3 de Voyage. Il reçoit une requête textuelle et des documents candidats, évalue conjointement chaque paire requête-document et retourne les scores de pertinence dans l’ordre du classement. Il sert de deuxième étape de recherche : un système de récupération par plongements ou par mots-clés trouve les candidats, puis Lite affine leur ordre. Le résultat est un classement à utiliser dans la recherche ou un flux de génération augmentée par récupération.
Ce qui change dans Rerank 3 Lite Le fournisseur souligne une meilleure récupération sur les longs documents et le code par rapport à rerank-2.5-lite. Les deux éditions Rerank 3 conservent le suivi des consignes et la même classe de contexte de 32K, tandis que Lite est conçu pour les applications sensibles à la latence. Cela en fait un candidat pratique pour la recherche interactive dans une base de connaissances, la récupération de documents de soutien et la recherche de code lorsque les utilisateurs ont besoin de résultats pertinents rapidement. Choisissez-le selon les exigences de qualité et de temps de réponse de la collection réelle, plutôt que de supposer qu’une édition plus petite signifie une fenêtre de contexte plus petite.
Guider la pertinence avec la requête Des consignes en langage naturel peuvent accompagner la requête pour expliquer ce qui est pertinent. Gardez la question et la préférence de pertinence concises et cohérentes. Pour une recherche de soutien logiciel, utilisez « Trouver la procédure de réinitialisation d’un appareil; privilégier les consignes pour la révision matérielle indiquée. » Pour un nom de produit ambigu, incluez la catégorie de produit afin que les sens sans rapport ne dominent pas. Une préférence dans la requête guide le score sémantique; utilisez les métadonnées explicites de la collection pour choisir le bon produit, la version du document ou la portée d’accès avant de constituer la liste de candidats.
Préparer une liste restreinte de candidats textuels Les documents d’entrée sont des chaînes de caractères. Extrayez du texte lisible du contenu source et conservez les titres, les en-têtes, les identifiants et le contexte environnant utiles. Maintenez une correspondance stable entre chaque position d’entrée et l’enregistrement original. Pour un article de dépannage, incluez le symptôme et la procédure pertinente, plutôt qu’une simple phrase isolée. Pour la recherche de code source, incluez la fonction et l’information voisine nécessaire pour la distinguer de fonctions portant un nom semblable. Retirez la navigation répétitive ou le texte passe-partout lorsqu’ils prennent la place du passage utile.
Le modèle de reclassement ne peut réordonner que les documents qu’il reçoit. Si la première recherche ne récupère jamais l’article pertinent, cette étape ne peut pas retrouver ce candidat manquant. Examinez la liste restreinte et l’ordre final lorsqu’un résultat semble erroné. Lorsqu’un long document couvre plusieurs sujets, séparez les sections cohérentes et conservez leurs références au document parent afin de pouvoir choisir une section pertinente sans perdre sa source.
Limites de contexte et de requête Le guide actuel du fabricant précise un maximum de 8 000 jetons pour la requête et un maximum combiné de 32 000 jetons pour la requête et chaque document individuel. Il permet jusqu’à 1 000 documents candidats et un budget total de requête de 600 000 jetons, calculé comme le nombre de jetons de la requête multiplié par le nombre de documents, plus tous les jetons des documents. Une longue requête consomme donc de l’espace dans chaque paire et contribue plusieurs fois au budget global. Comptez le texte soumis avec le segmenteur en jetons approprié au modèle plutôt que de traiter les caractères, les mots et les jetons comme interchangeables.
Par exemple, une requête de 500 jetons avec 100 documents de 4 000 jetons chacun représente 450 000 jetons d’entrée selon cette formule. Cela illustre la budgétisation, et non une taille de liste recommandée ni un résultat de vitesse mesuré. L’option de troncature documentée est activée par défaut; le texte trop long peut être raccourci avant l’attribution des scores. Préparez délibérément les sections importantes pour que la troncature ne retire pas le passage même que vous devez trouver.
Lire et utiliser le résultat Les résultats sont triés du score de pertinence le plus élevé vers le plus faible. Chaque résultat identifie la position d’entrée originale du document, ce qui permet à l’application d’y joindre son titre, son identifiant d’enregistrement et sa source. Le paramètre top_k contrôle le nombre de candidats classés retournés; sans lui, tous les candidats sont retournés. L’interface REST du fabricant peut aussi retourner le texte des documents. Conservez les identifiants d’origine avec les résultats sélectionnés lorsque vous affichez une page de recherche ou transmettez des éléments à une étape de génération de réponse.
Un score de pertinence exprime la correspondance d’un candidat avec la requête; il n’établit pas l’exactitude des affirmations du candidat. Comparez les premiers éléments à la véritable question de l’utilisateur, y compris les exclusions et les différences de versions de documents. Si tous les candidats sont non pertinents, il existe tout de même un premier élément au classement. Déterminez comment votre application traite ce cas à l’aide de requêtes représentatives de la collection.
Mettre à niveau et choisir l’édition Le fabricant décrit rerank-3-lite comme une mise à niveau de rerank-2.5-lite avec une sémantique d’API inchangée et des scores calibrés selon la distribution du prédécesseur correspondant. Conservez la correspondance existante des enregistrements et l’étape de récupération, puis comparez l’ordre obtenu sur des requêtes significatives avant de vous fier à un seuil de score établi. Utilisez Lite pour une expérience de recherche où le temps de réponse compte; utilisez l’édition rerank-3 axée sur la qualité comme comparaison lorsque la pertinence de candidats difficiles est la priorité principale.
POST /v1/reranktextrerank| Champ | Type | Exigence | Valeurs et limites | Par défaut |
|---|---|---|---|---|
Champdocuments | Typearray | ExigenceObligatoire | Valeurs et limites | Par défaut— |
Champmodel | Typestring | ExigenceObligatoire | Valeurs et limites voyageai/rerank-3-lite | Par défaut— |
Champprovider | Typeschema | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champquery | Typestring | ExigenceObligatoire | Valeurs et limites | Par défaut— |
Champsession_id | Typestring | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champtop_n | Typeinteger | ExigenceFacultatif | Valeurs et limites Minimum: 1 | Par défaut— |
Champtrace | Typeschema | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champuser | Typestring | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champdocuments[].text | Typestring | ExigenceFacultatif | Valeurs et limites | Par défaut— |
Champdocuments[].image | Typestring | ExigenceFacultatif | Valeurs et limites | Par défaut— |
text_rerank · Obligatoire : query, documents array with minItems1
| Paramètre | Contrat |
|---|---|
Paramètrecontent_type | Contratapplication/json |
Paramètrerequired | Contratmodel, query, documents |
Paramètrematerial_types | Contrattext |
Paramètreoptional_controls | Contratprovider, session_id, top_n, trace, user |
Paramètremultimodal_input_binding | Contratnull |
Cycle de vie : synchronous
Envoyez l’identifiant exact du modèle et conservez la réponse native complète.
Les tarifs n’ajoutent pas d’options de requête. Les paramètres pris en charge figurent dans la méthode sélectionnée.
Associez chaque coût aux conditions indiquées. Utilisez un seul tarif pour chaque ensemble de configurations alternatives.
| Configuration | Barème tarifaire | Unité de facturation | Coût |
|---|---|---|---|
| ConfigurationTarifs de base des jetons | Barème tarifaireTarif de base | Unité de facturation— | Coût Entrée · Jetons en entrée — / 1K jetons Sortie · Jetons en sortie — / 1K jetons Entrée · Lecture du cache — / 1K jetons Entrée · Écriture dans le cache — / 1K jetons Entrée · Écriture dans le cache, 1 h — / 1K jetons |
| ConfigurationUltra | Barème tarifaire— | Unité de facturation/ 1K jetons | Coût Entrée $0.00004 / 1K jetons |
Ailoot réserve un montant estimé avant une requête. Après le résultat, le montant final est débité selon l’utilisation mesurée. Pour le streaming, le montant final à débiter est calculé à partir du relevé final d’utilisation. Fonctionnement de la réservation et du débit →
{\n "documents": [\n "Paris is the capital of France.",\n "Berlin is the capital of Germany."\n ],\n "model": "voyageai/rerank-3-lite",\n "query": "What is the capital of France?",\n "top_n": 3\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_REQUEST_FILE:?Set your actual JSON request file}"\nexport AILOOT_REQUEST_FILE\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads(Path(os.environ['AILOOT_REQUEST_FILE']).read_text(encoding='utf-8'))\nif not isinstance(p,dict): raise SystemExit('Request must be a JSON object')\np['model']='voyageai/rerank-3-lite'\nPath('request.json').write_text(json.dumps(p,ensure_ascii=False),encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/rerank \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nprint(json.dumps(json.loads(Path('result.json').read_text()),ensure_ascii=False,indent=2))\nPY_RESULT\njson
Conservez chaque réponse, fichier et partie de contenu renvoyés dans leur intégralité.
Chaque indice de résultat réel, chaque relevance_score fini et l’objet de document d’origine sont conservés. Les indices correspondent au tableau des documents d’origine. Le JSON d’origine complet est stocké et retourné uniquement après le règlement.
Conservez l’opération d’origine et la réponse complète ou partielle; ne rejouez pas la demande POST.
| Champ | Type |
|---|---|
Champmodel | Typestring |
Champid | Typestring |
Champprovider | Typestring |
Champresults[].index | Typeinteger |
Champresults[].relevance_score | Typenumber |
Champresults[].document.text | Typestring |
Champresults[].document.image | Typestring |
Champusage.search_units | Typeinteger |
Champusage.total_tokens | Typeinteger |
Champusage.cost | Typenumber |
| Réponse | Condition | Étape suivante |
|---|---|---|
Réponse400 · invalid_request_error | ConditionChamp requis, représentation ou valeur invalide | Étape suivanteCorrigez le champ de demande indiqué. |
Ailoot Ultra voyageai/rerank-3-lite
Utilisez les chemins de méthode indiqués ci-dessus.