Votre assistant trouve cinq documents qui parlent de facturation. La procédure utile arrive quatrième, derrière un glossaire et une ancienne consigne. Si vous envoyez seulement les trois premiers au modèle de réponse, changer ce dernier ne fera pas apparaître la procédure manquante.
Voyage rerank-3 et rerank-3-lite, présentés le 30 septembre 2026, servent à reclasser des documents déjà récupérés avant de construire la réponse d’un RAG. Leur intérêt se mesure sur la place des bonnes sources, le temps ajouté et le coût des documents examinés.
L’annonce mérite un essai ciblé. Elle ne justifie pas, seule, de remplacer votre chaîne de recherche. Ce décryptage distingue les disponibilités, propose deux cas français et fournit un atelier Python téléchargeable avec son corpus fictif. Les calculs de l’atelier ont été vérifiés localement ; aucun benchmark des modèles Voyage n’a été exécuté pour cet article. Sources vérifiées le 5 octobre 2026.
Ce qui change avec rerank-3
Voyage présente cette génération comme une évolution de rerank-2.5, notamment pour les documents longs et le code. L’éditeur conserve l’interface d’appel et les prix des variantes correspondantes. Il publie une évaluation sur 95 jeux de données, avec plusieurs méthodes de recherche initiale et la métrique NDCG@10. Ces résultats sont ceux du fournisseur, pas des mesures sur votre documentation française. Annonce Voyage AI du 30 septembre.
Le changement est intéressant lorsque votre moteur retrouve déjà les bonnes sources mais les place trop bas. Vous pouvez alors comparer le classement actuel, rerank-2.5 si vous l’utilisez, rerank-3 et la variante lite sur les mêmes candidats. Garder ces entrées identiques permet d’attribuer les différences au classement, plutôt qu’à une modification simultanée des embeddings ou du découpage.
MongoDB a également présenté l’intégration dans son pipeline d’agrégation à l’occasion de MongoDB.local NYC. Les sous-titres complets du replay officiel de la keynote et de la conversation suivante, publié le 1er octobre, ont été lus. Ils donnent le contexte de plateforme ; les précisions sur rerank-3 viennent des annonces produit et des documentations recoupées. Cette lecture ne constitue pas une présence à l’événement. Annonce MongoDB.
Un reranker ne répare pas toutes les erreurs de recherche
Un RAG combine une recherche documentaire et une génération de réponse. Le reranking intervient entre les deux : il compare la question aux documents candidats et réordonne cette liste.
Trois diagnostics conduisent à trois actions différentes :
| Observation |
Vérification prioritaire |
Place du reranking |
| Le bon document est absent des candidats |
Indexation, filtres, découpage et recherche initiale |
Il ne peut pas récupérer une source qu’il ne reçoit pas |
| Le bon document est présent mais trop bas |
Rang, version, précision de la question |
C’est le cas à tester en priorité |
| Le bon document est transmis mais la réponse est fausse |
Lecture du contexte, consignes, citations |
Le classement seul ne suffit pas |
Avant de lancer un comparatif, examinez quelques erreurs réelles. Conservez les identifiants des passages récupérés, leur ordre et les sources finalement envoyées au générateur. Le guide d’observabilité LLM explique comment séparer ces étapes pour diagnostiquer les incidents.
API, intégration native et Europe : vérifier la bonne disponibilité
Un nom de modèle accessible dans une API ne garantit pas le même statut dans toutes les intégrations.
| Accès |
État documenté au 5 octobre |
Conséquence pratique |
| API Voyage historique |
rerank-3 et 3-lite figurent dans le guide courant |
Le tutoriel ci-dessous utilise cette API, avec une clé Voyage |
| API Atlas Embedding and Reranking |
Les deux modèles sont marqués Active depuis le 29 septembre ; 2.5 devient Legacy |
« Legacy » ne signifie pas retrait immédiat |
Étape native MongoDB $rerank |
Sa page conserve une mention Preview pour la série 3, avec MongoDB 9.0 et cluster dédié M10 minimum |
Vérifier la capacité effective du projet avant de prévoir une migration |
| Endpoint Atlas européen |
eu.ai.mongodb.com est en Public Preview |
La clé doit être rattachée à la Geography correspondante |
La politique de cycle de vie Atlas ne s’applique pas à l’API historique api.voyageai.com. La page de l’étape native exclut notamment les déploiements autogérés et Atlas Local. Elle conserve une formulation Preview alors que la page de cycle de vie marque les modèles Active : cette différence documentaire ne permet pas d’annoncer toute l’intégration en disponibilité générale.
Pour une équipe française, la région du cluster et le lieu de traitement de l’inférence sont deux paramètres distincts. Héberger la base en Europe ne suffit donc pas à qualifier le chemin suivi par une requête de modèle. Vérifiez endpoint, portée de la clé et service utilisé avant d’introduire des documents internes. L’atelier utilise des données inventées et ne démontre aucune propriété de résidence européenne. Geographies pour l’inférence Voyage.
Prix : compter les candidats examinés
Le tarif catalogue est de 0,05 dollar par million de tokens pour rerank-3 et 0,02 dollar pour rerank-3-lite. Le tableau courant affiche également 200 millions de tokens gratuits pour ces modèles ; vérifiez le solde et les conditions de votre compte plutôt que de supposer chaque essai gratuit. Tarification Voyage.
Le décompte inclut la question répétée pour chaque document, puis les tokens des documents :
tokens traités = tokens de la question × nombre de documents
+ somme des tokens des documents
Exemple purement arithmétique : une question de 100 tokens et 50 passages de 400 tokens représentent 25 000 tokens. Au catalogue, cela donne 0,00125 dollar avec rerank-3 ou 0,0005 dollar avec lite, hors crédits gratuits. Ce calcul ne prédit ni votre tokenisation réelle ni la latence.
Renvoyer trois résultats avec top_k=3 ne signifie pas que seuls trois documents sont évalués. Pour réduire le travail, il faut aussi maîtriser la liste envoyée. Mesurez donc séparément le nombre de candidats, leur longueur, les tokens réellement retournés par l’API et le nombre de passages conservés pour la réponse.
Deux cas français pour cadrer un premier essai
Facturation, cas fictif. Une équipe doit corriger deux factures déjà émises pour une commande. Le glossaire contient les mots exacts, une ancienne procédure parle de supprimer un brouillon, et la procédure actuelle décrit un avoir. La bonne annotation distingue le document qui répond à l’action demandée de ceux qui partagent seulement le vocabulaire. Les consignes de cet exemple sont inventées pour l’exercice.
Support technique, cas fictif. Le code ERR-42 existe dans deux versions d’un connecteur. La version 1 demande d’attendre ; la version 2 indique un fichier source absent. Un bon classement doit tenir compte de la version demandée. Un filtre explicite sur cette version peut toutefois résoudre le problème avant tout appel de modèle : comparez aussi cette correction simple.
Dans les deux cas, commencez par filtrer les droits d’accès. Un document interdit ne doit pas être envoyé à un service de reranking sous prétexte qu’il sera peut-être écarté ensuite. Ajoutez ensuite des questions sans réponse et des questions dont la source existe dans le corpus, mais manque parmi les candidats. Elles empêchent de confondre classement réussi et recherche complète.
Tutoriel : comparer sur des candidats figés
1. Vérifier l’atelier sans compte ni appel réseau
Téléchargez le script et le fichier JSON dans un même dossier. Python 3.10 ou supérieur suffit, sans bibliothèque supplémentaire.
python3 atelier_rerank.py --self-test
python3 atelier_rerank.py --output baseline.json
Le corpus comprend quatre questions : facture émise, version du connecteur, document absent des candidats et question sans réponse. L’ordre initial est construit manuellement pour illustrer les erreurs. Les valeurs du fichier baseline sont pédagogiques : elles ne décrivent aucun moteur de recherche réel.
Le test local vérifie les métriques, la correspondance entre indices retournés et identifiants de documents, ainsi que le rejet d’indices invalides. Une question sans document pertinent reçoit des métriques null. Une réponse connue mais absente des candidats reste un échec de rappel, même si le reranker trie parfaitement le reste.
2. Préparer les données à comparer
Pour un pilote métier, remplacez les exemples par des questions et passages autorisés. Faites annoter les réponses pertinentes avant de consulter les sorties des modèles : 0 pour inutile, 1 pour partiellement utile, 2 pour directement utile. Conservez les positifs connus dans l’annotation, y compris ceux absents des candidats.
Figez une version du corpus, du découpage et des listes candidates. Séparez les questions utilisées pour régler la méthode de celles réservées à l’évaluation. Quatre exemples suffisent à prendre en main le script, pas à décider une migration.
3. Lancer l’API lorsque l’accès est prêt
Configurez VOYAGE_API_KEY dans votre environnement via votre gestionnaire de secrets. Le mode live envoie les questions et passages à l’API Voyage historique et peut être facturé. Il ne s’active jamais par défaut.
python3 atelier_rerank.py --mode live --model rerank-2.5 --output ancien.json
python3 atelier_rerank.py --mode live --model rerank-3 --output nouveau.json
python3 atelier_rerank.py --mode live --model rerank-3-lite --output lite.json
Le script appelle POST https://api.voyageai.com/v1/rerank, conserve les indices de documents et demande trois résultats. Il désactive la troncature pour éviter qu’un texte trop long soit raccourci silencieusement. Une erreur d’API produit une ligne en échec avec des mesures absentes ; elle ne devient pas un mauvais score de pertinence. Référence de l’API.
Le guide courant annonce 1 000 documents maximum, 8 000 tokens pour la question, 32 000 pour chaque paire question-document et 600 000 tokens au total. Ce sont des plafonds, pas des tailles recommandées. Les limites de débit dépendent aussi de l’accès du compte. Guide des rerankers.
4. Lire les résultats sans fabriquer de gain
Comparez les mêmes questions avec les mêmes candidats. Le script calcule :
- Recall@3 : proportion des documents pertinents annotés présents dans les trois résultats.
- MRR@3 : inverse du rang du premier document pertinent, ou zéro s’il n’apparaît pas dans les trois premiers.
- NDCG@3 : qualité de l’ordre en tenant compte des notes de pertinence et de leur position.
Ces mesures ne jugent pas la réponse finale du RAG. Pour les questions sans réponse, examinez ensuite si votre application sait s’abstenir. Un score de pertinence élevé ne constitue pas, à lui seul, une preuve que le corpus contient la réponse.
Le rapport live prévoit aussi durée de l’appel, tokens traités et estimation au prix catalogue. Aucun résultat live n’est fourni ici. Pour mesurer une latence de production, répétez les requêtes dans les mêmes conditions, variez l’ordre des modèles et observez les percentiles sur un échantillon suffisant. Le temps d’un appel isolé ne permet pas d’annoncer une latence p95.
Décider : tester, conserver ou corriger la recherche
Le changement de nom dans l’API peut être rapide. L’effort sérieux porte sur les annotations, le diagnostic des erreurs, les contraintes d’accès et la validation du chemin réseau. Réservez une première session à ces préparatifs avant d’estimer un déploiement.
Testez rerank-3 si les sources utiles se trouvent régulièrement sous votre limite de contexte, particulièrement dans des documents longs ou une documentation technique. Comparez lite si le temps et le volume d’appels comptent fortement. Gardez l’existant si le gain est trop faible, incertain ou payé par une dégradation inacceptable de latence.
Si les bonnes sources manquent déjà parmi les candidats, travaillez d’abord l’indexation et les filtres. Si elles arrivent au générateur mais que la réponse reste fausse, évaluez également la réponse finale. Pour structurer les annotations, adaptez les principes de séparation et de versionnement du guide sur les jeux d’évaluation à vos questions documentaires.
Fixez vos critères avant le test : amélioration sur les erreurs ciblées, absence de régression sur les questions critiques, budget de temps et coût compatibles avec l’usage. Une nouvelle version mérite une comparaison reproductible. La décision doit venir de cette comparaison.
