VoyageAI by MongoDB: rerank-3-lite

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 chaque paire requête-document conjointement et renvoie des scores de pertinence dans l’ordre du classement. Il intervient au deuxième stade de la recherche : un moteur de récupération par embeddings ou mots-clés trouve les candidats, puis Lite affine leur ordre. Le résultat est un classement à utiliser dans un workflow de recherche ou de génération augmentée par récupération.

Ce qui change dans Rerank 3 Lite Le fournisseur met en avant une meilleure récupération sur les documents longs 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 32K, tandis que Lite est conçu pour les applications sensibles à la latence. Il constitue ainsi un candidat pratique pour la recherche interactive dans une base de connaissances, la récupération de documents d’assistance et la recherche de code lorsque les utilisateurs ont besoin rapidement de résultats pertinents. Choisissez-le selon les exigences de qualité et de temps de réponse de la collection réelle, sans supposer qu’une édition plus petite possède 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 compte comme pertinent. Gardez la question et la préférence de pertinence concises et cohérentes. Pour une recherche d’assistance logicielle, utilisez « Trouvez la procédure de réinitialisation d’un appareil ; donnez la priorité aux instructions correspondant à la révision matérielle indiquée. » Pour un nom de produit ambigu, ajoutez sa catégorie afin que les autres sens ne dominent pas. Une préférence dans la requête guide le score sémantique ; utilisez des métadonnées explicites de collection pour sélectionner le produit, la version documentaire ou le périmètre d’accès corrects avant de constituer la liste des candidats.

Préparer une présélection de candidats textuels Les documents d’entrée sont des chaînes. Extrayez le texte lisible des sources et conservez les titres, les en-têtes, les identifiants et le contexte environnant utiles. Gardez une correspondance stable entre chaque position d’entrée et le dossier original. Pour un article de dépannage, incluez le symptôme et la procédure pertinente, pas seulement une phrase isolée. Pour la recherche de code source, incluez la fonction et les informations voisines nécessaires à sa distinction de fonctions aux noms similaires. Supprimez la navigation répétitive ou le contenu passe-partout lorsqu’il évince le passage utile.

Le modèle de reclassement ne peut réordonner que les documents qu’il reçoit. Si la recherche initiale ne récupère jamais l’article pertinent, cette étape ne peut pas retrouver le candidat manquant. Examinez à la fois la présélection et l’ordre final lorsqu’un résultat semble erroné. Lorsqu’un long document couvre de nombreux sujets, séparez les sections cohérentes et conservez leurs références au document parent pour pouvoir sélectionner une section pertinente sans perdre sa source.

Contexte et limites de requête Le guide actuel du fabricant indique un maximum de 8 000 tokens pour la requête et un maximum combiné de 32 000 tokens pour la requête et chaque document individuel. Il autorise jusqu’à 1 000 documents candidats et un budget total de requête de 600 000 tokens, calculé comme le nombre de tokens de la requête multiplié par le nombre de documents, plus tous les tokens des documents. Une longue requête consomme donc de la place dans chaque paire et contribue plusieurs fois au budget agrégé. Comptez le texte soumis avec le tokenizer du modèle approprié plutôt que de traiter caractères, mots et tokens comme interchangeables.

Par exemple, une requête de 500 tokens avec 100 documents de 4 000 tokens chacun représente 450 000 tokens d’entrée selon cette formule. Cela illustre le calcul du budget, pas une taille de présélection recommandée ni une mesure de vitesse. L’option documentée de troncature est activée par défaut ; les textes trop grands peuvent être raccourcis avant l’attribution des scores. Préparez volontairement les sections importantes pour que la troncature ne supprime pas précisément le passage recherché.

Lire et utiliser le résultat Les résultats sont triés par score de pertinence décroissant. Chaque résultat identifie la position d’entrée originale du document, ce qui permet à l’application d’y rattacher son propre titre, identifiant de dossier et source. Le paramètre top_k contrôle le nombre de candidats classés renvoyés ; sans lui, tous les candidats sont renvoyés. L’interface REST du fabricant peut aussi renvoyer le texte du document. Conservez les identifiants d’origine avec les résultats sélectionnés lors de l’affichage d’une page de recherche ou de la transmission d’éléments à une étape de génération de réponse.

Un score de pertinence exprime à quel point un candidat correspond à la requête ; il n’établit pas l’exactitude des affirmations du candidat. Comparez les éléments les mieux classés à la question réelle de l’utilisateur, y compris les exclusions et différences de versions documentaires. Si tous les candidats sont sans pertinence, un premier du classement existe malgré tout. Décidez comment l’application traite ce cas à partir de requêtes représentatives de la collection.

Mettre à niveau et choisir l’édition Le fabricant présente rerank-3-lite comme une mise à niveau de rerank-2.5-lite, avec une sémantique API inchangée et des scores calibrés sur la distribution de son prédécesseur correspondant. Conservez la correspondance des dossiers existante 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 ; prenez l’édition rerank-3 axée sur la qualité comme comparaison lorsque la pertinence sur des candidats difficiles est prioritaire.