Ce que fait exactement le modèle
Nemotron 3.5 Rerank 8B BF16 est un modèle de réordonnancement (reranking) développé par NVIDIA, publié le 20 octobre 2026. Sa fonction spécifique est d'évaluer la pertinence d'un document par rapport à une requête textuelle, en renvoyant une unique valeur numérique (logit) pour chaque paire requête-document. Il ne génère pas de texte, ne crée pas d'embeddings et ne répond pas directement aux questions ; son rôle est de réordonner une liste de candidats obtenus précédemment par un système de recherche dense.
Le modèle est multimodal : il accepte comme document du texte, une image de page ou une combinaison des deux. Cela le distingue des rerankers purement textuels et le positionne comme composant clé dans les pipelines de RAG (Retrieval-Augmented Generation) qui manipulent des documents visuellement riches, tels que des PDF contenant des tableaux, des graphiques ou des infographies. L'architecture combine un encodeur visuel basé sur Pixtral avec une tour de langage bidirectionnelle basée sur Ministral3, ce qui lui permet de traiter simultanément l'information textuelle et visuelle du document.
Le score sert à ordonner des documents candidats par rapport à une requête ; il ne constitue ni une réponse rédigée ni une preuve que le document choisi contient la bonne information. Un logit ne doit pas être interprété automatiquement comme une probabilité calibrée. La valeur prend son sens dans l’usage de classement prévu et dans l’évaluation correspondante. Cette distinction permet d’intégrer le reranker à une chaîne de recherche sans lui attribuer la validation des faits ou la justesse de la réponse que produirait ensuite un autre modèle.
Capacités et exemples par tâche
Le modèle est conçu pour trois types d'entrée de document : texte seul, image seule, et texte+image. En pratique, cela permet de l'utiliser dans des scénarios où l'information pertinente est distribuée entre le texte extrait d'un PDF et les images de ses pages. Par exemple, si une requête demande une donnée spécifique qui apparaît dans un tableau, le reranker peut évaluer à la fois le texte OCR extrait et l'image originale de la page pour déterminer lequel représente le mieux la réponse.
La fiche officielle fournit un exemple d'utilisation où un document contenant du texte et une image de NeMo Framework est comparé à un document de biologie. Le modèle attribue des scores plus élevés aux documents liés à NeMo, qu'ils contiennent du texte seul, une image seule ou les deux, et des scores plus bas au document de biologie. Cela démontre sa capacité à capturer la pertinence sémantique dans plusieurs modalités.
Le texte extrait et l’image d’une page peuvent fournir des informations complémentaires, mais leur présence conjointe ne garantit pas un meilleur classement pour chaque document. L’exemple de NeMo et de biologie illustre le comportement sur les entrées présentées ; il ne mesure pas à lui seul la fiabilité en production. Une évaluation propre doit examiner si les documents pertinents sont effectivement favorisés pour les requêtes du corpus visé. Les résultats restent liés à ces requêtes et à ces données, plutôt qu’à une supériorité générale de toute entrée multimodale.
Benchmarks et méthodologie publiée
La fiche officielle indique que le modèle a été évalué sur deux benchmarks principaux : ViDoRe V3 pour la récupération de documents visuels et MIRACL-VISION pour la récupération visuelle multilingue. La métrique rapportée est NDCG@10. Cependant, la fiche ne publie pas les scores numériques spécifiques à ce checkpoint, ce qui ne permet pas de le comparer directement à d’autres modèles.
Pour la récupération de texte, le modèle a été évalué dans 34 langues, dont l’anglais, l’espagnol, le français, l’allemand, le chinois et le japonais. Pour la récupération d’images, l’évaluation a couvert 18 langues. En l’absence de scores numériques publics, les performances relatives du modèle ne peuvent être établies qu’au moyen de tests propres à chaque usage.
La couverture linguistique et la présence de noms de benchmarks décrivent le périmètre d’une évaluation, sans donner automatiquement un résultat utilisable pour chaque langue. L’absence de scores détaillés empêche un classement chiffré rigoureux entre candidats sur cette seule base. Pour choisir, il faut des critères de pertinence et des requêtes représentatives, puis comparer les classements dans les mêmes conditions. Une mesure locale peut éclairer cette décision tout en conservant sa portée limitée : elle ne reproduit pas nécessairement tous les benchmarks annoncés et ne valide pas tous les domaines.
Benchmarks mentionnés dans la fiche officielle
Résumé des ensembles d'évaluation cités par NVIDIA pour ce modèle.
| Benchmark | Type | Langues | Métrique | Score publié |
|---|---|---|---|---|
| ViDoRe V3 | Récupération visuelle de documents | 8 publics, 2 privés | NDCG@10 | Non publié |
| MIRACL-VISION | Récupération visuelle multilingue | 18 | NDCG@10 | Non publié |
| Évaluation texte | Récupération textuelle | 34 | Non spécifiée | Non publiée |
Prix et exigences de déploiement
Le modèle est distribué sous la licence OpenMDW-1.1, qui permet son usage commercial et non commercial, sous réserve des termes de ladite licence. Il n'existe pas d'API commerciale officielle publiée par NVIDIA pour ce modèle spécifique, de sorte que le coût principal est l'infrastructure GPU nécessaire à son exécution. Les poids du modèle sont disponibles publiquement sur Hugging Face.
En ce qui concerne les exigences matérielles, la fiche officielle spécifie la compatibilité avec les architectures NVIDIA Ampere (A100 80GB), Hopper (H100 80GB) et Blackwell (GB200 186GB). Le modèle utilise la précision bfloat16, ce qui réduit la consommation de mémoire par rapport à float32, mais nécessite toujours des GPU haute performance. Pour l'inférence, un environnement avec CUDA et Flash Attention 2 est recommandé pour optimiser la vitesse.
Les poids accessibles et l’autorisation d’usage sous licence ne suppriment pas les ressources nécessaires à l’inférence. Le coût du déploiement doit inclure le calcul et l’intégration du composant dans la chaîne existante. La compatibilité avec une architecture matérielle ne suffit pas à déterminer une latence pour chaque taille de lot ou document. Un essai sur le matériel prévu reste nécessaire pour dimensionner l’installation. Il faut également distinguer un déploiement propre des conditions d’un éventuel service tiers, sans attribuer à NVIDIA un tarif ou un service non établi pour ce checkpoint.
Exigences matérielles et logicielles
Configuration minimale recommandée selon la documentation officielle.
| Composant | Exigence | Notes |
|---|---|---|
| GPU | NVIDIA A100 80GB, H100 80GB ou GB200 186GB | Architectures Ampere, Hopper ou Blackwell |
| Précision | bfloat16 | Nécessite un support natif du GPU |
| Bibliothèques | Transformers 5.20.0, vLLM 0.32.0 | Flash Attention 2 recommandé |
| Système d'exploitation | Linux | Support Windows ou macOS non documenté |
Limites, sécurité et alternatives
La limite la plus significative documentée est le contexte maximal de 32 768 jetons, partagé entre le texte et l'image. Si la combinaison des deux dépasse cette limite, il est nécessaire de tronquer le texte ou de réduire la résolution de l'image. Par défaut, le côté le plus long des images est limité à 1 120 pixels, bien qu'il puisse être étendu à 1 540 pixels. Cette restriction peut affecter les performances sur des documents très longs ou avec des images haute résolution.
En matière de sécurité, la fiche officielle avertit que le modèle ne garantit pas toujours un classement significatif pour une requête donnée. De plus, il est recommandé d'examiner tout code distant (trust_remote_code) avant de l'exécuter, car il peut contenir une logique non vérifiée. Aucune vulnérabilité spécifique n'a été documentée, mais comme pour tout modèle d'IA, il est de la responsabilité du développeur de mettre en place des contrôles de sécurité appropriés.
Le contexte partagé impose de considérer ensemble le texte et l’image qui représentent un document. Lorsque les entrées doivent être réduites, il faut vérifier ce qui est conservé et si l’information pertinente reste accessible à la tâche de classement. Une requête techniquement acceptée ne prouve pas que tous les détails utiles ont été pris en compte. La revue du code distant répond à une autre exigence : comprendre ce qui sera exécuté. Elle ne doit être confondue ni avec une garantie de pertinence du classement ni avec une certification de sécurité de l’ensemble du système.
Critères pratiques de choix
La décision d'utiliser Nemotron 3.5 Rerank 8B BF16 doit se baser sur plusieurs facteurs : le besoin de reranking multimodal, la disponibilité d'un matériel GPU adéquat, et la capacité d'intégrer le modèle dans le pipeline existant. Si le corpus est purement textuel, un reranker textuel plus léger pourrait suffire et être plus économique. Si le corpus inclut des documents visuellement riches, ce modèle offre un avantage clair en pouvant évaluer à la fois le texte et l'image.
Pour les équipes qui n'ont pas accès à des GPU haute performance, l'option de déployer ce modèle localement peut ne pas être viable. Dans ces cas, il faut envisager l'utilisation d'APIs de tiers offrant du reranking multimodal, bien que cela introduise des coûts d'API et de possibles restrictions de confidentialité. Le choix final doit équilibrer précision, coût, latence et exigences de conformité.
Le choix d’un reranker multimodal dépend de la place réelle des informations visuelles dans le corpus et des contraintes d’exploitation. Un corpus textuel peut justifier l’examen d’une solution plus légère ; des pages où tableaux et mise en page portent l’information peuvent motiver un essai multimodal. Cette orientation ne détermine pas le vainqueur avant la comparaison. La décision doit rapprocher qualité du classement, temps de traitement, coût et confidentialité dans le même scénario. Un compromis acceptable pour un corpus ne devient pas une recommandation universelle pour tous les documents.
Processus de décision pour implémenter le reranker
Étapes recommandées pour évaluer la viabilité de Nemotron 3.5 Rerank 8B BF16.
- 011. Évaluer si le corpus contient des documents visuellement riches (images, tableaux, graphiques).
- 022. Vérifier la disponibilité du matériel GPU compatible (A100, H100 ou GB200).
- 033. Réaliser des tests de performance avec des données propres pour mesurer NDCG@10 et la latence.
- 044. Comparer avec des alternatives textuelles ou des APIs de tiers en termes de coût et de précision.
- 055. Auditer le code distant et les exigences de sécurité avant le déploiement en production.
Poursuivre l’exploration
Corrections et transparence
Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.
Proposer une correction