VoyageAI by MongoDB: rerank-2.5-lite

rerank-2.5-lite est le membre léger de la version 2.5 des modèles de reclassement de Voyage AI. Le fabricant le décrit comme un modèle généraliste équilibrant latence et qualité de pertinence, avec le suivi de consignes en langage naturel et une prise en charge multilingue. Son entrée est une requête et des textes candidats ; sa sortie est un ordre affiné de ces candidats avec des scores de pertinence.

Une décision de pertinence légère au deuxième stade

Le modèle Lite traite conjointement chaque paire requête-document comme un encodeur croisé. Il peut suivre une recherche initiale par embeddings ou lexicale et affiner les passages sélectionnés par cette étape. Cela diffère de la préparation d’un index d’embeddings réutilisable : le modèle de reclassement examine ensemble la requête et le texte du document envoyés pour la décision de pertinence actuelle.

Pour une recherche d’aide interactive, envoyez les explications candidates susceptibles de répondre à la question de l’utilisateur. Conservez assez de chaque passage pour transmettre le comportement et ses conditions, et préservez l’association entre l’indice d’entrée et l’élément source. Un ensemble ciblé de candidats aide à rendre la tâche de reclassement claire tout en laissant les éléments récupérés exploitables pour l’affichage ou une réponse ultérieure.

Les consignes expriment les priorités de l’utilisateur

Comme rerank-2.5, Lite accepte des consignes en langage naturel avant ou après la requête. Les exemples du fabricant les utilisent pour mettre en avant des parties de documents, sélectionner un type de source privilégié ou ajouter du contexte à un mot ambigu. Une application peut fournir une préférence de pertinence permanente, ou la question actuelle peut en inclure une plus précise.

Une requête d’assistance illustrative peut demander quel passage explique une erreur, avec une consigne privilégiant les étapes de dépannage aux descriptions générales du produit. Une recherche documentaire peut demander le libellé d’origine d’une politique plutôt qu’une discussion de celle-ci. Décrivez les éléments attendus et gardez la consigne concise. Les consignes influencent les scores de pertinence ; préparez les restrictions strictes de version, de date ou d’autorisation lors de la sélection des candidats au lieu de considérer une préférence de pertinence comme un filtre garanti.

Lire le classement et retourner le passage source

La sortie est triée par pertinence décroissante. Chaque résultat comprend l’indice du document d’origine et un score à virgule flottante ; le réglage facultatif return-documents retourne aussi le texte d’entrée correspondant. L’option top-k détermine le nombre de premiers résultats retournés, tandis que son omission retourne le classement de tous les candidats envoyés.

Utilisez ces indices pour retrouver le passage source et son identifiant. Un candidat reclassé peut devenir un résultat de recherche ou un élément probant pour l’étape RAG suivante, mais la sortie est un classement du texte fourni plutôt qu’une réponse réécrite. Évaluez si les premiers passages satisfont à la question et à la consigne de pertinence, y compris dans les langues et types de documents réellement présents dans la collection.

Limites et budget pratique des candidats

L’édition 2.5 Lite a un maximum documenté de 8 000 tokens pour la requête et une limite de 32 000 tokens pour la requête et chaque document individuel. Elle est distincte de l’ancien modèle rerank-2-lite et de son contexte plus petit. Il est possible d’envoyer au plus 1 000 documents, et l’entrée totale est limitée à 600 000 tokens selon la formule : les tokens de la requête multipliés par le nombre de candidats, plus la somme des tokens des documents candidats.

Pour une utilisation sensible à la latence, la FAQ du fabricant recommande rerank-2.5-lite avec au maximum 200 000 tokens au total par requête. Il s’agit d’une recommandation pratique sous le maximum annoncé, et non d’une autre fenêtre par document. Une requête ou une consigne plus longue est comptée une fois pour chaque paire requête-document ; le nombre de candidats et la longueur de la requête influencent donc tous deux le total.

La troncature est activée par défaut et raccourcit les entrées requête/document trop longues pour les faire tenir ; sa désactivation retourne une erreur pour une requête ou une paire trop longue. Préparez délibérément des candidats compacts contenant la réponse afin que les éléments utiles ne restent pas au-delà d’une limite tronquée. Sélectionner moins de résultats de sortie avec top-k ne retire pas les autres candidats fournis du calcul des tokens. Examinez les passages sources retournés et affinez la préparation des entrées selon les questions réelles auxquelles l’interface de recherche doit répondre.