H Company presenta NeoMME, una famiglia di encoder multimodali open source

I ricercatori di H Company hanno rilasciato NeoMME il 3 settembre 2026, una famiglia di encoder multimodali e multilingue da 260 M e 800 M di parametri, addestrati da zero e pubblicati sotto licenza Apache 2.0. Le varianti di recupero ottimizzate si collocano sulla frontiera di Pareto per la dimensione del modello del benchmark di recupero di documenti visivi ViDoRe v3, secondo quanto riferito dal team.

Secondo il post di rilascio, molti recenti recuperatori di documenti visivi sono adattati da modelli generativi preaddestrati di visione‑lingua, in cui un encoder di visione preaddestrato separatamente produce caratteristiche visive che un proiettore mappa nello spazio di ingresso di un modello linguistico causale. Recupero, classificazione e etichettatura di token non generano testo in modo autoregressivo, scrivono gli autori, quindi tali compiti non richiedono un decoder causale né il relativo overhead di parametri e calcolo. NeoMME, invece, elabora token di testo e patch di immagine grezze attraverso un unico Transformer bidirezionale condiviso e non si basa su alcuna torre di visione, encoder di testo o decoder di testo preaddestrati.

Il post confronta il design con due precedenti sforzi di encoder: ModernBERT, che ha introdotto miglioramenti di efficienza negli encoder testuali bidirezionali, e ModernVBERT, che ha applicato un encoder testuale in stile ModernBERT al recupero di documenti visivi mantenendo una torre di visione SigLIP2 preaddestrata separata. Gli autori scrivono di aver voluto eliminare l’overhead di trasportare i componenti di un modello visione‑lingua all’interno di un encoder.

Architettura e Preaddestramento da Zero

Entrambe le dimensioni di NeoMME condividono la stessa architettura. Gli input testuali utilizzano embedding di token fattorizzati, mentre le immagini vengono suddivise in una griglia di patch non sovrapposte da 32 × 32 e proiettate mediante una piccola rete multilayer perceptron; entrambe entrano poi nello stesso encoder Transformer. Le immagini mantengono il loro rapporto d’aspetto e le dimensioni, così il modello può dedicare più token a una pagina di documento ad alta risoluzione e ricca di informazioni rispetto a un’immagine più piccola. La lunghezza di contesto è di 16 384 token, sufficiente per fino a due immagini standard 3840 × 2160 4K UHD. La maggior parte degli strati utilizza attenzione a finestra scorrevole simmetrica, mentre ogni sesto strato e lo strato finale usano attenzione globale. Lo stack include inoltre attenzione a query raggruppate, normalizzazione query‑key, attenzione gated, embedding posizionali rotazionali 2D e MLP con attivazione squared‑ReLU. Per il testo, il team ha addestrato da zero un tokenizzatore BPE con un vocabolario di 131 072 token su testi multilingue, codice, matematica e trascrizioni di immagini generate automaticamente.

NeoMME è preaddestrato da zero come denoiser testuale a diffusione mascherata discreta. Per gli esempi solo testuali, il tasso di corruzione viene campionato uniformemente tra 0 e 1, e ogni token testuale idoneo viene mascherato indipendentemente a quel tasso. Gli esempi multimodali usano tassi di corruzione tra 0,3 e 1, lasciando le patch di immagine visibili mentre il modello ricostruisce il testo mascherato; gli autori scrivono che una mascheratura intensa costringe il modello a imparare descrizioni ancorate all’immagine anziché affidarsi a scorciatoie puramente linguistiche. Il preaddestramento mescola testo multilingue, codice, matematica, immagini naturali e immagini di documenti, e ogni modello elabora circa 524 miliardi di token di input impacchettati, inclusi 290 miliardi provenienti da esempi solo testuali. Evidenziando che questo budget testuale è piccolo rispetto ai 2 trilioni di token di addestramento di ModernBERT, gli autori scrivono di aver scelto l’ottimizzatore NorMuon per migliorare l’efficienza dei dati.

Messa a Punto del Recupero e Risultati dei Benchmark

Per valutare il backbone su un compito a valle, il team lo ha messo a punto per il recupero di documenti visivi utilizzando la metodologia pagina‑immagine introdotta da ColPali. Invece di recuperare frammenti di testo estratti, NeoMME‑Retriever classifica screenshot di pagine di documento, evitando la pre‑elaborazione OCR e preservando layout, grafici, tabelle e tipografia. Il recuperatore aggiunge due teste addestrate congiuntamente al backbone: una testa densa che media le hidden state in un vettore normalizzato, e una testa di late‑interaction che proietta ogni token di testo o patch di immagine in un vettore normalizzato a 128 dimensioni, mantenendo corrispondenze dettagliate tra token di query e regioni dell’immagine. Un singolo forward pass restituisce entrambe le rappresentazioni. Gli autori raccomandano gli embedding di late‑interaction in generale, e una pipeline di recupero denso seguita da ri‑ranking di late‑interaction per corpora molto grandi.

Sul benchmark ViDoRe v3, il post riporta un nDCG@10 di 0,523 per NeoMME‑Retriever‑260M, il punteggio più alto tra i modelli valutati con meno di 800 M di parametri e a 0,002 da ColQwen2.5, usando circa 14 volte meno parametri. NeoMME‑Retriever‑800M raggiunge 0,556, a 0,009 da Vultron Retriever Flash di dimensioni simili, e entrambi i modelli si trovano sulla frontiera di Pareto per la dimensione del modello del benchmark. La tabella comparativa del post indica i punteggi dei concorrenti come provenienti da MTEB e i punteggi di NeoMME come valutazioni proprie del team. Sui benchmark più vecchi ViDoRe v1 e v2, che utilizzano nDCG@5, il post segnala che il modello da 260 M supera ColModernVBERT e il doppio più grande ColSmol‑500M, mentre il modello da 800 M supera ColPali v1.3 con 3,6 volte meno parametri.

La scheda modello per NeoMME‑260M‑Retriever elenca 263 M di parametri, una dimensione hidden di 1 024, pesi BF16 e embedding densi a 1 024 dimensioni con punti di troncamento Matryoshka a 128, 256, 512 e 1 024 dimensioni, oltre all’output multivettoriale a 128 dimensioni. La scheda riporta anche i risultati di recupero testuale su BEIR‑15, dove il retriever da 260 M ottiene 0,4881 nDCG@10 con late interaction e il modello da 800 M ottiene 0,5126.

Compressione, Throughput di Indicizzazione e Disponibilità

Poiché lo storage di late‑interaction scala linearmente con il numero di vettori di embedding, le pagine ad alta risoluzione risultano costose da indicizzare: una pagina 2048 × 2048 genera 4.200 vettori con NeoMME‑Retriever, circa 2,1 MB in float32, e il post segnala una media misurata di circa 1,5 MB per documento su ViDoRe v3. Il team ha combinato il pooling gerarchico di token, che raggruppa vettori di documenti simili e memorizza la media di ciascun cluster, con la quantizzazione asimmetrica, che conserva gli embedding dei documenti in precisione int8 o binaria mantenendo gli embedding di query in tempo reale a precisione più alta. Su ViDoRe v3, il post riporta che un fattore di pooling di 10 con query e documenti int8 riduce lo storage a 39 kB per pagina, una riduzione di 39×, mantenendo oltre il 99 % del nDCG@10 di base. Un’impostazione più aggressiva, fattore di pooling 8 con query int8 e documenti binari, utilizza 6 kB per pagina, 255 volte meno, e conserva oltre il 95 % della qualità di recupero.

Il team ha inoltre misurato il throughput di codifica usando tensori di immagine pre‑processati, con batch size calibrati separatamente per ciascun modello e dimensione dell’immagine. Con un input 2048 × 2048 su una singola GPU NVIDIA L40S, NeoMME‑Retriever‑260M codifica circa 51 pagine al secondo, quasi il doppio delle 26 pagine al secondo di ColModernVBERT, e il post riporta che entrambe le dimensioni di NeoMME‑Retriever sono più veloci degli altri modelli confrontati a risoluzioni di input più piccole.

Tutti i checkpoint di NeoMME sono rilasciati sotto licenza Apache 2.0 con un’implementazione day‑zero in Hugging Face Transformers, e una demo di generazione aumentata dal recupero visivo è disponibile come Hugging Face Space. Per la messa a punto, il team fornisce checkpoint separati per dense e late‑interaction compatibili con Sentence Transformers v6, che attualmente supporta una sola testa di recupero per modello; addestrare entrambe le teste insieme richiede la classe NeoMMEForRetrieval con un Trainer personalizzato.

Il rapporto tecnico allegato, di Aurélien Lac e Tony Wu, è stato inviato a arXiv il 31 agosto 2026, nella categoria information retrieval. Nei ringraziamenti del post, gli autori descrivono NeoMME come un progetto secondario realizzato con tempo e risorse di calcolo limitati, e ringraziano H Company per aver supportato il lavoro e fornito la potenza di calcolo utilizzata per l’addestramento.