Aggiornato all’8 settembre 2026. NeoMME è stato pubblicato il 3 settembre; prestazioni e integrazioni possono cambiare rapidamente.
NeoMME è una nuova famiglia di encoder multimodali e multilingue pensata per cercare informazioni dentro testo, immagini e pagine di documenti. H Company ha rilasciato modelli da 260 e 800 milioni di parametri, checkpoint con licenza Apache 2.0 e supporto in Hugging Face Transformers fin dal primo giorno. Il caso d’uso più interessante è il Visual RAG: trovare la pagina giusta osservandone direttamente l’immagine, senza ridurre ogni documento a solo testo estratto.
Non è un chatbot e non genera da solo la risposta finale. NeoMME trasforma query e documenti in rappresentazioni numeriche confrontabili. Un’applicazione recupera le pagine più pertinenti e può poi passarle a un modello generativo. Questa distinzione evita l’equivoco più comune: un retriever migliora ciò che entra nel contesto, ma non sostituisce il modello che scrive la risposta.
NeoMME: come funziona il nuovo encoder
Secondo la presentazione tecnica di H Company, NeoMME usa un unico Transformer bidirezionale per elaborare token di testo e patch ricavate dalle immagini. Molti sistemi multimodali combinano una torre visiva preaddestrata con un language model separato; qui la stessa architettura viene addestrata da zero con un obiettivo di masked discrete diffusion.
Il risultato è un encoder, non un decoder autoregressivo. Può rappresentare una domanda scritta, il testo di un documento oppure lo screenshot completo di una pagina. Tabelle, disposizione grafica, fotografie e altri segnali visuali rimangono disponibili durante la ricerca, invece di scomparire in una pipeline basata soltanto sull’OCR.
La famiglia comprende una versione compatta e una più grande. Il model card di NeoMME-260M-Retriever indica 263 milioni di parametri, contesto da 16.384 token e immagini fino a 2.048 pixel sul lato maggiore nella configurazione predefinita. Sono numeri gestibili, ma non significano che qualsiasi computer indicizzi milioni di pagine senza pianificazione.
Dense retrieval e late interaction nello stesso passaggio
NeoMME-Retriever produce due tipi di embedding con una sola inferenza. Il vettore dense riassume l’intero elemento in una rappresentazione compatta, utile per una prima ricerca veloce. I multi-vector conservano invece rappresentazioni più granulari di token e patch, permettendo un confronto late-interaction più preciso tra domanda e zone della pagina.
Una pipeline può usare il dense retrieval per ridurre rapidamente l’archivio e applicare il punteggio più costoso soltanto ai candidati migliori. Non è obbligatorio scegliere un solo metodo per sempre. Questo disegno rende NeoMME interessante per PDF tecnici, cataloghi, contratti, slide, manuali e archivi nei quali la posizione visiva contiene informazione.
| Elemento | NeoMME-260M-Retriever |
|---|---|
| Parametri dichiarati | 263 milioni |
| Contesto | 16.384 token |
| Input | Testo o immagine di pagina |
| Output retrieval | Dense e multi-vector |
| Licenza | Apache 2.0 |
| Uso principale | Ricerca documentale e Visual RAG |
Prestazioni: cosa significano i numeri pubblicati
Nel report, i modelli da 260M e 800M si collocano sulla frontiera di Pareto di ViDoRe v3 rispetto a qualità nDCG@10 e dimensione. In un test a 2.048 x 2.048 pixel su GPU NVIDIA L40S, il modello 260M codifica circa 51 pagine al secondo, quasi il doppio del throughput attribuito a ColModernVBERT nelle stesse condizioni.
Gli autori dichiarano inoltre che pooling gerarchico e quantizzazione asimmetrica possono ridurre lo spazio dell’indice late-interaction da circa 1,5 MB a 6 kB per pagina, conservando oltre il 95% dell’nDCG@10 di riferimento. È una riduzione notevole, ma deve essere riprodotta sul proprio corpus: risoluzione, batch, GPU, lingua e tipo di pagina cambiano velocità e qualità.
Il paper di NeoMME riporta 0,523 nDCG@10 per il retriever 260M e 0,556 per l’800M su ViDoRe v3. Queste metriche confrontano l’ordine dei risultati rilevanti; non misurano direttamente correttezza della risposta generata, assenza di allucinazioni o qualità dell’OCR.
Quando NeoMME può essere utile
Il primo caso è un archivio nel quale l’estrazione testuale perde struttura: fatture con tabelle, report pieni di grafici, schede prodotto, documenti scansionati, slide e manuali illustrati. Indicizzare la pagina come immagine permette di recuperarla anche quando la risposta dipende da layout e contenuto visuale.
Il secondo è la ricerca multilingue. Una singola architettura elabora lingue e modalità diverse, semplificando sistemi che altrimenti richiederebbero encoder separati. Prima della produzione va comunque testata la qualità sulle lingue effettive, soprattutto su scansioni degradate, caratteri piccoli e domini specialistici.
Il nostro articolo su Qwen 3.8-27B per uso locale riguarda un modello generativo che può scrivere e ragionare. NeoMME occupa un punto diverso della pipeline: seleziona le fonti visuali da fornire al generatore. I due componenti possono quindi essere complementari.
Limiti e prova pratica
NeoMME non elimina automaticamente OCR, metadati e controlli di accesso. Un sistema può aver bisogno del testo per citazioni precise, filtri, evidenziazione e audit. Deve inoltre associare ogni embedding alla pagina originale e impedire che una query recuperi documenti non autorizzati.
L’indice multi-vector può ancora diventare grande su milioni di pagine, anche dopo la compressione. Vanno misurati tempo di indicizzazione, RAM o VRAM, spazio, latenza della ricerca e qualità dopo quantizzazione. Un benchmark utile include domande reali e valuta recall dei primi risultati, non soltanto una demo riuscita.
La comparazione GPT-6 Astra vs GPT-5.6 Sol mostra perché anche il generatore finale va scelto per costo e latenza. Un buon retriever può ridurre il contesto inviato al modello più caro, ma una pagina recuperata male non viene corretta magicamente da un LLM più potente.
NeoMME è una parola chiave appena nata, ma il progetto risponde a un problema concreto: rendere il Visual RAG più compatto e integrabile. Il valore reale emergerà quando sviluppatori indipendenti riprodurranno i risultati su documenti diversi. Oggi è soprattutto un candidato credibile da mettere alla prova, non un sostituto universale di ogni pipeline documentale.
