NeoMME Retriever : une carte pratique du rappel des candidats pour la récupération visuelle de documents

Pourquoi NeoMME compte maintenant pour la récupération d'images de pages

H Company a publié NeoMME le 3 septembre 2026 sous la forme d'une famille d'encodeurs multilingues et multimodaux de 260M et 800M. Cette publication mérite l'attention pour une raison pratique : NeoMME Retriever peut produire des embeddings denses et des embeddings à interaction tardive à partir de la même passe avant. Pour les équipes de récupération visuelle de documents, cela fait passer le modèle d'une curiosité de benchmark à une décision d'architecture.

La récupération d'images de pages recherche des pages rendues, pas seulement du texte extrait. Les preuves pertinentes peuvent se trouver dans un tableau, l'étiquette d'un diagramme, une annexe scannée, une note multilingue ou une mise en page où le contexte spatial change le sens. L'OCR reste important. Dans des PDF propres avec des identifiants exacts, il peut être la base de référence la plus forte. Mais une conception fondée uniquement sur l'OCR laisse de côté une catégorie de questions documentaires où l'image de la page elle-même porte le signal.

La frontière est l'endroit où les builders doivent faire preuve de discipline. Un encodeur de récupération récupère des pages. Il ne génère pas de réponses, ne prouve pas la fidélité du RAG visuel et ne supprime pas la nécessité d'évaluer un VLM ou un modèle de langage en aval. Les scores de récupération publiés peuvent guider la sélection, mais ils ne doivent pas être reformulés comme des affirmations sur l'exactitude des réponses. La même logique se retrouve dans l'article d'Optijara sur la comparabilité des benchmarks et les tests de pertinence : une métrique n'est utile que lorsque tout le monde s'accorde sur ce qu'elle mesure. Pour la planification de production, le test de réalité du déploiement de petits modèles d'Optijara formule le même point dans un autre contexte : mesurez l'artefact, l'exécution, le matériel et la charge de travail avant que l'architecture ne se fige.

La question pratique n'est pas de savoir si un index ANN peut stocker beaucoup de vecteurs. La question est de savoir si la recherche dense de première étape ramène assez souvent les bonnes pages pour que l'interaction tardive améliore l'ordre. Si l'ensemble de candidats est faible, le reranker améliore la mauvaise présélection.

L'architecture en langage clair : un encodeur, deux têtes de récupération

NeoMME utilise un Transformer bidirectionnel unique sur des tokens de texte et des patchs d'image bruts. Les documents de H Company décrivent des patchs de 32 par 32 pixels, un contexte de 16 384 tokens et l'absence de tour visuelle préentraînée séparée ou de modèle de langage causal dans le chemin de récupération. La carte du retriever 260M indique 263M paramètres, une taille cachée de 1 024, des embeddings denses de 1 024 dimensions avec des dimensions Matryoshka et des embeddings multi-vecteurs de 128 dimensions par token de texte ou patch d'image. La carte 800M indique 800M paramètres, une taille cachée de 1 792 et la même voie multi-vecteurs de 128 dimensions.

La tête dense est le moteur de recherche de candidats. Elle crée une représentation compacte qui peut être recherchée par similarité cosinus dans une infrastructure vectorielle familière. C'est généralement là que commencent les équipes de production, car cela s'intègre à l'indexation ANN, aux filtres de métadonnées, aux contrôles d'accès et aux journaux de récupération.

La tête à interaction tardive conserve un treillis plus détaillé de tokens ou de patchs. Les cartes de modèles décrivent des embeddings multi-vecteurs normalisés L2, scorés avec MeanMaxSim. Ce style de scoring peut mieux préserver les preuves locales qu'un seul vecteur dense lorsque la requête dépend d'une cellule de tableau, d'une légende, de l'étiquette d'un diagramme ou d'une petite région d'une page. Le piège est que les détails comptent. Le padding, le masquage, la normalisation, la précision des requêtes, la précision des documents et la fonction de scoring exacte peuvent modifier la qualité et le coût.

Il existe aussi des checkpoints Sentence Transformers séparés. Le modèle dense ST ne génère que des embeddings denses. Le modèle ST à interaction tardive ne génère que des embeddings multi-vecteurs. Ce n'est pas le même chemin opérationnel que le modèle Transformers par défaut, qui renvoie ensemble des embeddings denses et multi-vecteurs via NeoMMEForRetrieval. Si une évaluation mélange ces artefacts, le rapport doit le dire en langage clair.

Le goulot d'étranglement du rappel des candidats : ce que le reranking ne peut pas récupérer

La leçon centrale est directe : le rappel dense@K fixe le plafond du reranking en aval. L'interaction tardive peut réordonner les pages retenues, mais elle ne peut pas sauver une page pertinente qui n'atteint jamais la présélection.

Prenons une recherche hypothétique dans un rapport annuel. Un utilisateur demande une divulgation de risque précise. La réponse apparaît une seule fois, en petits caractères dans un tableau d'annexe. Un embedding dense de page peut récupérer la section narrative sur les risques et plusieurs pages visuellement similaires, tout en manquant la page d'annexe à K égal à 20. Le reranker à interaction tardive peut affiner ces 20 pages, mais la page du tableau reste invisible. Augmenter K peut la faire apparaître. Cela ajoute aussi du travail de reranking, des mouvements mémoire et peut-être davantage de pages à inspecter pour un VLM en aval.

C'est pourquoi les équipes doivent séparer le rappel des candidats@K, le nDCG@10 du reranker, l'exactitude des réponses et la qualité des citations. Les fusionner dans un seul score RAG masque le mode d'échec. Si l'exactitude des réponses s'améliore après avoir augmenté K, le gain peut venir du rappel des candidats plutôt que d'un meilleur générateur. Si la qualité des réponses se dégrade après compression, la régression peut se situer dans la récupération, le classement ou la synthèse de réponse.

La taille de l'ensemble de candidats est une vraie variable de conception. Un K faible peut garder les systèmes rapides tout en plafonnant discrètement le rappel. Un K élevé améliore la probabilité que la bonne page atteigne le reranker, mais il peut augmenter la latence de l'interaction tardive, les lectures d'index, la pression GPU ou CPU et le bruit de contexte en aval. La bonne valeur dépend du corpus. Le mélange de langues, la densité de mise en page, la qualité des scans, la fréquence des tableaux et les petits caractères comptent tous. La carte d'évaluation de Vaani d'Optijara utilise une habitude similaire : garder les tranches visibles au lieu de laisser des scores agrégés masquer les cas inconfortables.

La Page-to-Candidate Recall Map : un flux d'évaluation pratique

Le cadre recommandé pour une récupération visuelle de style NeoMME est une Page-to-Candidate Recall Map. Son rôle est simple. Elle associe chaque requête aux pages qui devraient être atteignables, à l'étape qui les trouve ou les manque et aux contrôles de réponse qui dépendent de la récupération.

Commencez par les artefacts. Fixez le checkpoint NeoMME exact, la configuration du processeur, la révision de bibliothèque, l'outil de rendu, la taille d'image, les identifiants de pages et le format de stockage. Ne supposez pas qu'une version stable ultérieure de la bibliothèque se comporte comme la page de documentation actuelle. Construisez des jugements de pertinence au niveau page, puis stratifiez-les. Un PDF anglais propre né numérique, un tableau multilingue, un scan pivoté et une page d'annexe dense ne doivent pas être moyennés ensemble avant que quelqu'un n'examine les ratés. Gardez un ensemble de réserve et inspectez les échecs manuellement. Les petits caractères, les mises en page presque dupliquées, les en-têtes, les pieds de page et les longs tableaux sont les endroits où les démos soignées diffèrent souvent du comportement en production.

Comparez ensuite les routes. La récupération par texte OCR reste une base de référence sérieuse pour les PDF propres, les termes exacts, les identifiants et la revue de conformité. La récupération NeoMME dense uniquement teste le rappel large des candidats. L'évaluation tardive uniquement, lorsque faisable, montre le coût et la qualité de l'appariement détaillé. La présélection dense plus le reranking tardif teste la route hybride probable. Mesurez le rappel des candidats@K et le nDCG@10 avant la génération de réponse. Ajoutez ensuite la latence par étape, les octets d'index, le temps de prétraitement, l'exactitude des réponses à partir des pages récupérées et la fidélité des citations.

Ce que disent les mesures publiées, et ce qu'elles n'incluent pas

La publication de H Company rapporte un nDCG@10 ViDoRe v3 de 0,523 pour NeoMME Retriever 260M et de 0,556 pour NeoMME Retriever 800M. La page de l'article liée répète ces valeurs rapportées par les auteurs et indique que le modèle 260M dépasse les modèles évalués strictement sous 800M paramètres sur ce benchmark. Les anciens chiffres ViDoRe v1 et v2 utilisent nDCG@5 dans les tableaux des cartes de modèles, ils ne doivent donc pas être comparés avec le nDCG@10 de v3 comme si la métrique et le cadre étaient identiques.

La publication rapporte aussi environ 51 pages par seconde pour la configuration 260M à taille d'entrée image comparable de 2048 par 2048 sur un GPU NVIDIA L40S. Lisez cela strictement. Cela renvoie à des tenseurs prétraités avec des paramètres de batch calibrés. Cela n'inclut pas le rendu PDF, l'upload, l'indexation, le traitement des requêtes, la génération en aval, l'orchestration applicative, l'observabilité ou la revue humaine.

Les affirmations sur la compression demandent la même prudence. Le blog décrit le pooling hiérarchique de tokens et la quantification asymétrique réduisant le stockage de l'index à interaction tardive d'environ 1,5 Mo à environ 6 ko par page, soit 255 fois moins, tout en conservant plus de 95 pour cent du nDCG@10 de base sur ViDoRe v3. Il s'agit d'un résultat moyen spécifique sur les embeddings à interaction tardive, pas d'une empreinte totale de vector store. Les vecteurs denses, les métadonnées, les images de pages, la surcharge d'index, les sauvegardes, les journaux d'accès et les données de monitoring comptent toujours. Les mêmes documents évoquent une autre configuration de pooling et d'int8 autour de 39 ko par page avec plus de 99 pour cent de qualité conservée. Traitez-les comme des compromis séparés, pas comme des paramètres par défaut.

Compromis de routes : dense, interaction tardive et récupération visuelle hybride

Le dense uniquement peut suffire pour la navigation grossière, les pages quasi dupliquées ou la récupération de sujets larges. L'interaction tardive justifie son coût lorsque les preuves pertinentes sont locales, visuelles, tabulaires ou facilement diluées dans un seul vecteur dense. La récupération hybride est attractive parce qu'une passe d'encodage NeoMME peut produire les deux représentations. Pourtant, la route hybride ne fonctionne que lorsque la présélection de première étape est assez large pour que le reranker voie les bonnes pages.

Le budget de ressources doit être explicite. Si une équipe décide s'il faut exécuter la récupération localement, utiliser une inférence hébergée ou répartir les charges de travail, les questions ressemblent à celles du test de réalité du déploiement de petits modèles d'Optijara : artefact exact, exécution exacte, matériel exact, charge de travail exacte et conditions de rollback claires.

Checklist d'implémentation, erreurs courantes et réserves

Les erreurs courantes sont ordinaires, ce qui explique précisément pourquoi elles continuent de se produire. Les équipes traitent le nDCG du reranker comme l'exactitude des réponses. Elles réduisent K avant de mesurer le rappel des candidats. Elles confondent la compression des embeddings avec le coût total de stockage. Elles supposent que le support multilingue natif signifie une performance équilibrée dans toutes les langues. Elles sautent les bases de référence OCR texte. Elles ignorent le temps de rendu parce que le benchmark commence après le prétraitement. Elles oublient que des poids de modèle Apache 2.0 ne règlent pas les permissions documentaires.

Les réserves opérationnelles doivent figurer dans la revue de conception. La distribution des requêtes peut dériver. Les embeddings mis en cache peuvent devenir obsolètes après les mises à jour de documents. Les documents privés peuvent exiger des contrôles plus stricts de stockage, de rétention et d'accès. Les ensembles d'évaluation peuvent surreprésenter les pages propres. Un VLM en aval peut halluciner même lorsque la récupération est bonne, ou citer la mauvaise page même lorsque la bonne page est présente. La capacité multilingue native ne prouve pas la qualité des réponses en arabe, en langue à faibles ressources, manuscrites ou sans OCR pour un corpus donné.

{
  "model_family": "NeoMME Retriever",
  "retrieval_routes": ["ocr_text_baseline", "dense_only", "late_interaction", "dense_shortlist_plus_rerank"],
  "must_measure": ["candidate_recall_at_k", "ndcg_at_10", "per_stage_latency", "index_bytes", "answer_correctness", "citation_faithfulness"],
  "excluded_costs_to_add_back": ["pdf_rendering", "upload", "indexing", "metadata", "page_images", "generation", "observability"],
  "deployment_caveats": ["dense_recall_caps_reranking", "compression_is_workload_specific", "retrieval_is_not_answer_generation"]
}

Une prochaine expérience utile est petite et disciplinée : choisissez des documents représentatifs, fixez les artefacts, construisez des jugements au niveau page, balayez K, testez la compression séparément, puis reliez les pages récupérées aux contrôles de réponse et de citation. Si votre équipe a besoin d'aide, Optijara peut aider à construire cette carte d'évaluation avant que les choix d'architecture ne se transforment en coût de production.