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 conjointement chaque paire requête-document et renvoie des scores de pertinence dans l’ordre du classement. Il intervient à la deuxième étape de la recherche : un système 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 pour la recherche ou dans un processus 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. C’est donc un candidat pratique pour la recherche interactive dans les bases de connaissances, la récupération de documents d’assistance 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, sans supposer qu’une édition plus petite signifie une fenêtre de contexte plus petite.

Guidez la pertinence par 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 ; privilégiez les consignes correspondant à la révision matérielle indiquée. » Pour un nom de produit ambigu, incluez la catégorie du produit afin que des sens sans rapport ne dominent pas. Une préférence dans la requête guide la notation sémantique ; utilisez les métadonnées explicites de la collection pour sélectionner le bon produit, la version du document ou le périmètre d’accès avant de constituer la liste des candidats.

Préparez une sélection de candidats textuels Les documents d’entrée sont des chaînes de caractères. Extrayez du texte lisible des contenus 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 d’origine. Pour un article de dépannage, incluez le symptôme et la procédure pertinente, et pas uniquement une phrase détachée. Pour la recherche de code source, incluez la fonction et les informations voisines nécessaires pour la distinguer de fonctions aux noms similaires. Supprimez les éléments de navigation ou textes standard répétitifs 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 recherche initiale ne récupère jamais l’article pertinent, cette étape ne peut pas retrouver ce candidat manquant. Examinez la sélection et le classement final lorsqu’un résultat paraît incorrect. Lorsqu’un document long couvre de nombreux sujets, séparez des sections cohérentes et conservez leurs références au document parent afin de sélectionner une section pertinente sans perdre sa source.

Limites de contexte et de requête Le guide actuel du concepteur 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 requête longue consomme donc de l’espace dans chaque paire et contribue plusieurs fois au budget total. Comptez le texte soumis avec le tokenizer du modèle approprié, sans considérer les caractères, les mots et les 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 budget, et non une taille de sélection recommandée ou une vitesse mesurée. L’option de troncature documentée est activée par défaut ; les textes trop longs peuvent être raccourcis avant la notation. Préparez délibérément les sections importantes afin que la troncature ne supprime pas précisément le passage à faire correspondre.

Lisez et utilisez le résultat Les résultats sont triés par score de pertinence décroissant. Chaque résultat indique la position d’entrée d’origine du document, ce qui permet à l’application de lui associer son titre, son identifiant de dossier et sa source. Le paramètre top_k contrôle le nombre de candidats classés renvoyés ; en son absence, tous les candidats sont renvoyés. L’interface REST du concepteur peut aussi renvoyer le texte du document. 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 l’adéquation d’un candidat à la requête ; il n’établit pas l’exactitude des affirmations de ce candidat. Comparez les éléments les mieux classés à la question réelle de l’utilisateur, en tenant compte des exclusions et des différences de version des documents. Si tous les candidats sont hors sujet, un élément reste malgré tout premier du classement. Décidez comment votre application traite ce cas à l’aide de requêtes représentatives de la collection.

Mise à niveau et choix de l’édition Le concepteur décrit 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 du prédécesseur correspondant. Conservez la correspondance existante des dossiers 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 recherche où le temps de réponse compte ; comparez-le à l’édition rerank-3 axée sur la qualité lorsque la pertinence sur les candidats difficiles est prioritaire.