Mis à jour le 8 septembre 2026. NeoMME a été publié le 3 septembre ; performances et intégrations peuvent évoluer rapidement.
NeoMME est une nouvelle famille d’encodeurs multimodaux et multilingues conçue pour rechercher dans du texte, des images et des pages complètes. H Company publie des modèles de 260 et 800 millions de paramètres, des checkpoints sous licence Apache 2.0 et une intégration immédiate dans Hugging Face Transformers. Son usage le plus intéressant est le Visual RAG : retrouver la bonne page en analysant directement son image, sans réduire chaque document au seul texte extrait.
Ce n’est pas un chatbot et il ne génère pas seul la réponse finale. NeoMME transforme requêtes et documents en représentations numériques comparables. Une application récupère les pages pertinentes puis peut les transmettre à un modèle génératif. Un retriever améliore donc le contexte fourni, mais ne remplace pas le modèle qui rédige la réponse.
Comment fonctionne NeoMME
Selon la présentation technique de H Company, NeoMME emploie un Transformer bidirectionnel unique pour les tokens textuels et les patches d’image. Beaucoup de systèmes multimodaux associent une tour visuelle préentraînée à un language model séparé. Ici, l’architecture complète est entraînée depuis zéro avec un objectif de masked discrete diffusion.
Le résultat est un encodeur, pas un décodeur autorégressif. Il peut représenter une question écrite, le texte d’un document ou la capture complète d’une page. Tableaux, mise en page, photographies et autres signaux visuels restent disponibles pendant la recherche au lieu de disparaître dans une pipeline limitée à l’OCR.
La famille comprend une version compacte et une plus grande. La fiche de NeoMME-260M-Retriever indique 263 millions de paramètres, un contexte de 16 384 tokens et des images allant par défaut jusqu’à 2 048 pixels sur le côté le plus long. Ces dimensions restent accessibles, sans garantir qu’un ordinateur quelconque indexera des millions de pages sans planification.
Dense retrieval et late interaction en un passage
NeoMME-Retriever produit deux types d’embeddings lors d’une seule inférence. Le vecteur dense résume l’élément et permet une première recherche rapide. Les multi-vecteurs conservent des représentations plus fines des tokens et patches, afin de calculer une late interaction plus précise entre la question et les régions de la page.
Une pipeline peut utiliser le dense retrieval pour réduire rapidement l’archive, puis réserver le calcul plus coûteux aux meilleurs candidats. Ce dessin intéresse les PDF techniques, catalogues, contrats, présentations, manuels et archives où la position visuelle transporte une information.
| Élément | NeoMME-260M-Retriever |
|---|---|
| Paramètres déclarés | 263 millions |
| Contexte | 16 384 tokens |
| Entrée | Texte ou image de page |
| Sortie retrieval | Dense et multi-vecteur |
| Licence | Apache 2.0 |
| Usage principal | Recherche documentaire et Visual RAG |
Performances : lire correctement les chiffres
Le rapport place les versions 260M et 800M sur la frontière de Pareto de ViDoRe v3 pour la qualité nDCG@10 et la taille. Dans un test en 2 048 par 2 048 pixels sur GPU NVIDIA L40S, le modèle 260M encode environ 51 pages par seconde, soit près du double du débit attribué à ColModernVBERT dans les mêmes conditions.
Les auteurs indiquent aussi que pooling hiérarchique et quantification asymétrique réduisent l’index late-interaction d’environ 1,5 Mo à 6 ko par page tout en conservant plus de 95 % du nDCG@10 de référence. Cette réduction doit être reproduite sur le corpus réel : résolution, batch, GPU, langue et type de page modifient vitesse et pertinence.
Le papier NeoMME rapporte 0,523 nDCG@10 pour le retriever 260M et 0,556 pour le 800M sur ViDoRe v3. Ces métriques évaluent le classement des résultats pertinents, pas directement la justesse d’une réponse générée, les hallucinations ou la qualité OCR.
Dans quels cas NeoMME est utile
Le premier cas est une archive dont l’extraction textuelle détruit la structure : factures avec tableaux, rapports remplis de graphiques, fiches produit, documents scannés, slides et manuels illustrés. Indexer l’image de page permet de la retrouver lorsque la réponse dépend de la mise en page.
Le deuxième cas est la recherche multilingue. Une architecture unique traite plusieurs langues et modalités, ce qui simplifie les systèmes employant autrement des encodeurs séparés. Il faut néanmoins tester les langues réellement servies, surtout sur scans dégradés, petits caractères et domaines spécialisés.
Notre article sur Qwen 3.8-27B en local concerne un modèle génératif qui écrit et raisonne. NeoMME intervient ailleurs : il sélectionne les sources visuelles envoyées au générateur. Ces composants peuvent donc fonctionner ensemble.
Limites et test pratique
NeoMME ne supprime pas automatiquement l’OCR, les métadonnées ou les contrôles d’accès. Le texte reste utile pour les citations exactes, filtres, surlignages et audits. Chaque embedding doit rester relié à la page d’origine, et une requête ne doit jamais récupérer un document interdit à l’utilisateur.
Un index multi-vecteur peut rester volumineux sur des millions de pages malgré la compression. Il faut mesurer durée d’indexation, mémoire, stockage, latence et qualité après quantification. Un test crédible utilise des questions réelles et mesure le rappel parmi les premiers résultats.
La comparaison GPT-6 Astra ou GPT-5.6 Sol rappelle que le générateur final doit lui aussi être choisi selon coût et latence. Un bon retriever réduit le contexte envoyé au modèle cher, mais un LLM puissant ne répare pas une page qui n’a jamais été récupérée.
NeoMME est un mot-clé tout récent, mais il vise un besoin concret : rendre le Visual RAG plus compact et intégrable. Sa valeur durable apparaîtra lorsque des équipes indépendantes reproduiront les résultats sur d’autres documents. Pour l’instant, c’est un candidat crédible à tester, pas le remplaçant universel de chaque pipeline documentaire.
