NVIDIA NeMo en tête avec son pipeline de récupération agentique

L'équipe de NVIDIA NeMo Retriever a récemment propulsé son pipeline de récupération agentique au sommet du classement ViDoRe v3, obtenant la première place avec un score NDCG@10 de 69.22. Ce même pipeline a également décroché la deuxième place sur le classement BRIGHT, avec un score de 50.90, un benchmark reconnu pour sa rigueur en matière de raisonnement.

Un pipeline agentique pour une récupération plus intelligente

Dans le domaine en constante évolution de la récupération d'informations par intelligence artificielle, de nombreuses solutions sont souvent spécialisées, conçues pour exceller dans des tâches spécifiques et restreintes. Cependant, les applications d'entreprise dans le monde réel nécessitent des systèmes capables de s'adapter à une variété de défis, allant de l'analyse de mises en page visuelles complexes à l'exécution de raisonnements logiques approfondis. C'est pourquoi NVIDIA a misé sur la généralisation dans la conception de son pipeline, qui adapte dynamiquement sa stratégie de recherche et de raisonnement aux données disponibles, offrant ainsi des performances de pointe sur des benchmarks variés sans nécessiter de modifications architecturales sous-jacentes.

La motivation : pourquoi la similarité sémantique ne suffit pas

Depuis des années, la récupération dense basée sur la similarité sémantique est la norme pour trouver des informations. Cependant, à mesure que les applications de la récupération se développent, la recherche de documents pertinents va au-delà de la simple similarité sémantique. Une recherche de documents complexe nécessite des compétences en raisonnement, une compréhension des systèmes du monde réel et une exploration itérative. Les LLMs sont excellents pour penser et raisonner, mais ne peuvent pas traiter des millions de documents à la fois. À l'inverse, les récupérateurs peuvent facilement trier des millions de documents, mais possèdent des compétences en raisonnement limitées. La récupération agentique comble cet écart en créant une boucle active et itérative entre le LLM et le récupérateur.

Comment ça fonctionne : la boucle agentique

Le pipeline de récupération agentique de NVIDIA repose sur une architecture ReACT. Plutôt qu'une seule requête "unique", l'agent recherche, évalue et affine itérativement son approche. L'agent utilise des outils intégrés comme think pour planifier son approche et final_results pour sortir les documents exacts nécessaires pour une requête donnée, en plus d'un outil retrieve (query, top_k) pour explorer le corpus. Grâce à cette boucle, nous avons observé l'émergence naturelle de modèles de recherche réussis :

• Génération de meilleures requêtes : L'agent ajuste dynamiquement ses requêtes de recherche en fonction des nouvelles informations découvertes.
• Reformulation persistante : Il reformule continuellement les requêtes jusqu'à ce qu'une information utile soit trouvée.
• Décomposition de la complexité : Il traduit des requêtes complexes en plusieurs requêtes plus simples avec des objectifs clairs.

Enfin, pour synthétiser les découvertes itératives, l'agent appelle un outil final_results pour sortir les documents les plus pertinents, classés par leur pertinence par rapport à une requête donnée. Comme filet de sécurité, par exemple lorsque l'agent atteint le nombre maximum d'étapes ou la limite de longueur de contexte, le pipeline revient à la Fusion de Rang Réciproque (RRF), qui évalue les documents en fonction de leurs rangs à travers toutes les tentatives de récupération dans la trajectoire de l'agent.

Ingénierie pour la vitesse et l'échelle

Les flux de travail agentiques sont notoirement lents et gourmands en ressources. Pour rendre ce pipeline viable pour une évaluation à l'échelle du classement, NVIDIA a dû repenser la communication entre l'agent LLM et le récupérateur. Au départ, le récupérateur était exposé à l'agent via un serveur Model Context Protocol (MCP) — un choix naturel, puisque le MCP est conçu précisément pour donner aux LLMs accès à des outils externes. Mais en pratique, cette architecture imposait un coût cumulatif sur la vitesse des expériences. Chaque exécution nécessitait de démarrer un serveur MCP séparé, de charger le bon corpus de données dans la mémoire GPU et d'orchestrer le cycle de vie du client et du serveur. Chacune de ces étapes était une opportunité de mauvaise configuration silencieuse ou de blocage du serveur sous des demandes à fort volume. Les allers-retours réseau ajoutaient de la latence à chaque appel de récupération, et le fardeau cognitif global de la gestion de la configuration à deux processus rendait beaucoup plus difficile pour d'autres équipes d'adopter et d'itérer sur le pipeline.

Pour résoudre ce problème, NVIDIA a remplacé le serveur MCP par un récupérateur singleton thread-safe qui vit dans le processus. Le singleton charge les modèles et les embeddings de corpus une seule fois, protège tous les accès avec un verrou réentrant et expose la même interface retrieve() à un nombre arbitraire de tâches d'agents concurrentes — atteignant le principal avantage d'un serveur MCP (accès partagé et sécurisé à un récupérateur résidant sur GPU depuis plusieurs threads) sans encourir de surcharge de sérialisation réseau ou nécessiter un processus serveur séparé. Ce changement architectural unique a éliminé toute une classe d'erreurs de déploiement et a considérablement amélioré à la fois l'utilisation du GPU et le débit des expériences.

Généralisation contre spécialisation à travers les benchmarks

Une observation courante dans l'évaluation moderne de la récupération est que les solutions hautement optimisées pour un type de tâche spécifique connaissent souvent un écart de performance lorsqu'elles sont appliquées à un domaine complètement différent. NVIDIA a obtenu la deuxième place sur le classement BRIGHT avec un NDCG@10 de 50.90. La solution numéro un sur ce classement, INF-X-Retriever, atteint un impressionnant 63.40. Cependant, pour tester l'adaptabilité inter-domaines, NVIDIA a évalué le pipeline INF-X (couplé avec le même modèle d'embedding nemotron-colembed-vl-8b-v2 utilisé dans leur pipeline agentique) sur ViDoRe v3, un ensemble de données axé sur des documents d'entreprise visuellement riches et diversifiés. Sur cette tâche différente, sa performance s'est établie à un NDCG@10 de 62.31, inférieur au score de récupération dense de 64.36. En d'autres termes, INF-Query-Aligner ne surpasse pas la base de récupération dense sur ViDoRe v3.

En revanche, le même pipeline agentique de NVIDIA (associant Opus 4.5 avec nemotron-colembed-vl-8b-v2) a atteint la première place sur ViDoRe v3 avec un score de 69.22. Cela met en évidence une force fondamentale de leur approche : la généralisation. Plutôt que de s'appuyer sur des heuristiques spécifiques à un ensemble de données ou sur un réécrivain/aligner de requêtes, la boucle agentique de NVIDIA adapte naturellement sa stratégie à l'ensemble de données en question, qu'il s'agisse de nécessiter un raisonnement logique en plusieurs étapes ou de déchiffrer des mises en page visuelles complexes.

Études d'ablation : modèles ouverts contre modèles fermés

NVIDIA a mené des études d'ablation approfondies pour comprendre le compromis entre les modèles fermés de pointe et les alternatives à poids ouverts :

• Choix du modèle : Sur ViDoRe v3, remplacer Opus 4.5 par le modèle ouvert gpt-oss-120b a entraîné une légère baisse de précision (de 69.22 à 66.38 NDCG@10) et a nécessité beaucoup moins d'appels de récupération. Sur BRIGHT, l'écart était plus large, indiquant que les tâches de raisonnement plus profond bénéficient encore fortement des modèles de pointe comme Opus 4.5.

• Embeddings : Associer l'agent avec des embeddings spécialisés (nemotron-colembed-vl-8b-v2 pour ViDoRe et llama-embed-nemotron-reasoning-3b pour BRIGHT) a donné les meilleurs résultats, prouvant qu'un récupérateur de base solide offre un plafond plus élevé pour que l'agent atteigne.

Il est également intéressant de noter que l'agent peut réduire l'écart entre des modèles d'embedding plus forts et plus faibles. Par exemple, sur ViDoRe, l'écart entre le plus fort nemotron-colembed-vl-8b-v2 et le plus faible llama-nemotron-embed-vl-1b-v2 est d'environ 8.5 en récupération dense, mais lorsqu'il est associé à l'agent gpt-oss-120b, l'écart se réduit à environ 4. De même, llama-embed-nemotron-reasoning-3b est environ 19 points meilleur que llama-nemotron-embed-vl-1b-v2 sur BRIGHT, mais l'avance se réduit à environ 7.5 lorsqu'il est couplé avec l'agent gpt-oss-120b.

Le coût de l'autonomie et les prochaines étapes

Il n'y a pas de repas gratuit. La récupération agentique est plus coûteuse et plus lente que la récupération dense standard. En examinant nos résultats sur ViDoRe v3, l'agent prend en moyenne 136 secondes par requête et consomme environ 760k tokens d'entrée et 6.3k tokens de sortie par requête. (Remarque : la latence séquentielle est mesurée sur un seul GPU A100 avec un seul appel API Claude concurrent — c'est-à-dire sans rechercher plusieurs requêtes en même temps — pour refléter le temps de recherche réel dans des cas d'utilisation du monde réel).

Cependant, nous croyons que la récupération agentique est une approche hautement viable pour des requêtes complexes et à enjeux élevés. Nos prochaines étapes immédiates se concentrent sur la réduction des coûts : nous recherchons activement des moyens de distiller ces motifs de raisonnement agentique en agents plus petits et spécialisés à poids ouverts. En ajustant des modèles plus petits pour orchestrer la boucle de réflexion et de récupération de manière native, nous visons à offrir une précision de niveau Opus à une fraction de la latence et du coût.

Construisez votre propre pipeline agentique

Bien que nos exécutions en tête du classement aient exploré des combinaisons comme Claude Opus et gpt-oss aux côtés de nos modèles d'embedding de recherche, la véritable force de cette architecture réside dans sa modularité. Pour des déploiements prêts pour la production, nous vous encourageons vivement à essayer d'associer votre agent de choix avec notre robuste modèle d'embedding commercial llama-nemotron-embed-vl-1b-v2. Pour explorer ces modèles, plonger dans les outils et commencer à construire vos propres flux de travail de récupération hautement généralisables.