L'ingénierie du contexte a un problème de récupération : découvrez rerank-3 et la fonction native de reranking

Toute équipe qui développe des agents d'IA découvre une vérité fondamentale : sans les bonnes informations, un agent ne peut pas répondre à une question ou effectuer une action de manière fiable.

Alors que les fenêtres de contexte des Large Language Models s'agrandissaient, il était tentant de supposer qu'il suffisait de fournir plus d'informations à un agent pour améliorer sa précision. En pratique, un contexte plus large rend les agents plus lents et plus coûteux, tout en réduisant leur précision en noyant les signaux utiles dans des informations non pertinentes.

C’est pourquoi le succès d’un agent repose désormais sur l’ ingénierie contextuelle, la pratique consistant à sélectionner, organiser et présenter à un agent uniquement les informations dont il a besoin pour accomplir une tâche efficacement.

Et l'essentiel de ce travail se déroule lors de la récupération. La question n'est pas de savoir quelle quantité vous pouvez inclure dans le contexte. Il s’agit de savoir quels dix éléments sur dix millions vous choisissez.

La plateforme de données intelligente de MongoDB associe les modèles d’intégration et de reranking de pointe de Voyage AI à une plateforme pour créer, exploiter et faire évoluer des systèmes de récupération complexes. Avec le lancement aujourd’hui de la série Rerank 3 et de $rerank dans l’aggregation pipeline, les développeurs peuvent améliorer la qualité et le classement du contexte récupéré dans le même système où se trouvent leurs données opérationnelles. Il en résulte un moyen plus simple de créer des systèmes de récupération qui fournissent aux agents le contexte dont ils ont besoin pour agir.

La pile de récupération

Une récupération efficace exige un système coordonné pour trouver des informations utiles, déterminer ce qui est le plus important et le transmettre efficacement à l'agent.

La stratégie détermine la manière dont le système recherche ses données. La recherche par mots-clés permet de faire ressortir des termes exacts, tandis que la recherche vectorielle trouve un contenu conceptuellement similaire. Les filtres et les approches hybrides ajoutent de la précision et du contrôle, en veillant à ce que seul le contexte pertinent soit récupéré.

Les modèles déterminent à quoi ressemble la pertinence pour vos données. Un modèle de plongement plus robuste aide la recherche vectorielle à identifier de meilleurs candidats en comprenant la similitude conceptuelle et l’intention de la Requête. Un réordonnanceur permet à la récupération initiale d’optimiser le rappel, puis de séparer les correspondances les plus fortes du définir de candidats.

Le bon moteur réunit ces technologies disparates, en tenant les données à jour et les Requête efficaces pendant l'exécution du système en production.

Sans une plateforme unifiée pour la gestion de la récupération, le travail devient vite compliqué. Vous pouvez utiliser un fournisseur pour les plongements, un autre pour le reranking et plusieurs fournisseurs de bases de données pour vos données opérationnelles, de recherche et vectorielles. Cela signifie davantage d'intégrations, de tâches de synchronisation et d'appels d'API à gérer. Cela peut également créer des problèmes silencieux : votre index de recherche vectorielle peut utiliser une version de modèle d’embedding tandis que votre application en utilise une autre, ce qui nuit à la pertinence sans provoquer d’erreur explicite.

Figure 1. Le pipeline de récupération déconnecté.

MongoDB réunit ces éléments sur une seule plateforme. Elle prend en charge les stratégies de recherche dont les développeurs ont besoin, notamment la récupération textuelle, vectorielle, hybride et filtrée, et les associe aux modèles d’intégration et aux rerankers de pointe de Voyage AI. Automated Embedding synchronise les vecteurs à mesure que les données changent, tandis que le rerank natif permet aux développeurs d’affiner les résultats dans la même aggregation pipeline. Le résultat est une requête unique capable d’effectuer des recherches dans des données opérationnelles, d’appliquer la stratégie de récupération adéquate, de reclasser les résultats et de renvoyer le contexte dont un agent a besoin.

Figure 2. Le pipeline de récupération unifié alimenté par MongoDB.

Les modèles

L'introduction aujourd'hui de rerank-3 et rerank-3-lite offre une précision améliorée sur toutes les tâches, avec les gains les plus importants sur les longs documents et le code. rerank-3 surpasse Cohere Rerank v4.0 Pro de 2,72 % et Qwen3-Reranker-8B de 3,02 % dans l'ensemble. Si vous utilisez rerank-2.5 aujourd'hui, la mise à niveau est une simple modification du nom du modèle. Même API, même prix.

rerank-3 améliore la pertinence, quelle que soit la manière dont le définir de candidats initial est récupéré. Le tableau ci-dessous présente l’augmentation de la précision pour plusieurs méthodes de récupération courantes de premier niveau.

Tableau 1. Comparaisons de la précision.

Le moteur

MongoDB est le moteur d'extraction opérationnel qui sous-tend tout cela, et chaque stratégie s'exécute nativement par rapport aux mêmes données que votre application écrit déjà. La recherche lexicale permet de détecter les identifiants, les codes d'erreur et les noms de produits exacts. La recherche vectorielle saisit les concepts et les paraphrases. La recherche hybride les combine, et les filtres de métadonnées maintiennent le jeu de candidats suffisamment restreint pour rester rapide. Rien de tout cela ne nécessite de déplacer des données dans un système distinct ou de maintenir deux copies synchronisées.

Automated Embedding prend en charge la partie qui tombe généralement en panne. Les vecteurs sont générés et actualisés au niveau du champ en temps quasi réel, et la consommation de jetons et l'intégrité de l'index sont visibles dans l'UI d'Atlas. Il n'y a pas de tâche d’intégration à gérer, et aucun risque de décalage entre la version du modèle sur laquelle votre index a été construit et celle utilisée pour vos Requête.

$rerank, disponible dès aujourd’hui, ajoute l’étape de classement final à cette même pipeline. Il s’agit d’une étape sans index qui peut prendre l’ensemble de candidats produit par l’étape précédente et lui attribuer un nouveau score avec rerank-3 ou rerank-3-lite. Pas de fournisseur séparé, pas d’appel d’API externe, pas d’étape de réassemblage dans le code d’application ; c’est important lorsqu’un agent effectue plusieurs appels de récupération par tâche plutôt qu’un seul.

Figure 3. $rerank en action.

Gravité : À quoi cela ressemble quand cela fonctionne

Gravity construit un réseau publicitaire qui optimise la publicité pour l'ère de l'IA. La pertinence n'est pas un luxe, c'est le produit. Leur problème n'était pas le rappel. Les modèles de plongement et de réordonnancement antérieurs retournaient des scores de pertinence regroupés de manière trop étroite, de sorte que Gravity ne pouvait pas séparer avec confiance une correspondance forte d'une faible.

« La chose la plus importante que nous avons découverte lors de nos benchmarks a été la capacité de Voyage AI à être discriminatoire envers les candidats qui ne sont pas un bon profil et à vraiment promouvoir ceux qui le sont », a déclaré Leo Martinez, cofondateur et CTO de Gravity. Le passage à Voyage AI a réduit la latence de récupération d'environ 50 % et a amélioré la précision à mesure que le volume des demandes augmentait.

Combler The Gap

La qualité de la recherche n'est qu'une couche de ce que MongoDB construit pour les agents. MongoDB 9.0 et Atlas Infinite constituent la couche de performance et de répartir élastique, absorbant le trafic en rafale généré par les charges de travail des agents. Atlas Agent moteur est la couche de mémoire et de gouvernance, qui offre aux agents un contexte persistant et des garde-fous pour toutes les sessions ; la recherche est optimisée par Atlas Vector Search et Voyage AI. Un agent décide ce qu'il doit récupérer avant de décider ce qu'il doit faire. Une infrastructure plus rapide associée à une mauvaise récupération signifie simplement agir plus tôt sur la mauvaise chose.

Une récupération efficace ne nécessite plus une architecture complexe. L'intégration automatisée se charge des embeddings, $rerank s'occupe de la hiérarchisation, et les deux s'exécutent sur vos données opérationnelles directement dans MongoDB. Les modèles sont également disponibles de manière autonome via l'API Atlas Embedding and Reranking.