Updated September 8, 2026. NeoMME was released on September 3; performance and integrations may evolve quickly.
NeoMME is a new family of multimodal, multilingual encoders built to search across text, images and complete document pages. H Company released 260-million and 800-million-parameter models, Apache 2.0 checkpoints and day-zero support in Hugging Face Transformers. Its most compelling use case is Visual RAG: locating the right page by processing its image instead of reducing every document to extracted text alone.
It is not a chatbot and does not generate the final answer by itself. NeoMME turns queries and documents into comparable numerical representations. An application retrieves the most relevant pages and can then send them to a generative model. That distinction matters: a retriever improves what enters the context, but it does not replace the model that writes the response.
How the NeoMME encoder works
According to H Company’s technical introduction, NeoMME uses one bidirectional Transformer for text tokens and image patches. Many multimodal systems join a separately pretrained vision tower to a language model. This architecture is instead trained from scratch with a masked discrete-diffusion objective.
The result is an encoder rather than an autoregressive decoder. It can represent a written question, document text or a full-page screenshot. Tables, spatial layout, photographs and other visual signals remain available during retrieval rather than disappearing inside a text-only OCR pipeline.
The family offers a compact and a larger version. The NeoMME-260M-Retriever model card lists 263 million parameters, a 16,384-token context and images up to 2,048 pixels on the longest side by default. Those are relatively manageable figures, but they do not imply that any computer can index millions of pages without capacity planning.
Dense retrieval and late interaction in one pass
NeoMME-Retriever emits two embedding types from one inference pass. A dense vector summarizes the whole item compactly and supports a fast first-stage search. Multi-vector output preserves more granular representations of tokens and patches, enabling a more precise late-interaction score between the question and regions of a page.
A pipeline can use dense retrieval to narrow a large archive and apply the more expensive score only to its best candidates. Teams do not have to commit permanently to one retrieval method. This design is relevant to technical PDFs, catalogues, contracts, slide decks, manuals and archives where visual position carries meaning.
| Item | NeoMME-260M-Retriever |
|---|---|
| Declared parameters | 263 million |
| Context | 16,384 tokens |
| Input | Text or page image |
| Retrieval output | Dense and multi-vector |
| License | Apache 2.0 |
| Main use | Document retrieval and Visual RAG |
Performance: interpreting the published results
The report places both 260M and 800M versions on the ViDoRe v3 Pareto frontier for nDCG@10 quality and model size. In a 2,048-by-2,048-pixel test on an NVIDIA L40S GPU, the 260M model encodes roughly 51 pages per second, about twice the reported throughput of ColModernVBERT under matched conditions.
The authors also report that hierarchical pooling and asymmetric quantization reduce late-interaction index storage from around 1.5 MB to 6 kB per page while retaining more than 95% of baseline nDCG@10. The reduction is substantial, but production teams must reproduce it on their corpus. Resolution, batch size, GPU, language and page type all influence speed and relevance.
The NeoMME paper reports 0.523 nDCG@10 for the 260M retriever and 0.556 for the 800M version on ViDoRe v3. These metrics assess the ranking of relevant results. They do not directly measure generated-answer accuracy, hallucination rates or OCR quality.
Where NeoMME may be useful
The first target is an archive where text extraction loses structure: invoices with tables, reports full of charts, product sheets, scanned records, slides and illustrated manuals. Indexing the page as an image can retrieve it when the answer depends on layout and visual content.
The second is multilingual search. One architecture processes different languages and modalities, simplifying systems that would otherwise use separate encoders. Teams should still evaluate the languages they actually serve, particularly with degraded scans, small type and specialist terminology.
Our article on Qwen 3.8-27B for local use covers a generative model that writes and reasons. NeoMME occupies a different place in the pipeline: it selects visual sources for the generator. The two types of model can therefore be complementary.
Limitations and a useful evaluation
NeoMME does not automatically remove the need for OCR, metadata or access controls. A system may still require text for exact quotations, filters, highlighting and audits. Every embedding must remain linked to its source page, and retrieval must never expose documents the requesting user is not allowed to read.
A multi-vector index can remain large across millions of pages even after compression. Measure indexing time, memory, storage, query latency and quality after quantization. A useful benchmark uses real questions and grades recall among the first results rather than celebrating one successful demonstration.
The GPT-6 Astra vs GPT-5.6 Sol comparison illustrates why the final generator also needs a cost and latency decision. A strong retriever can reduce the context sent to an expensive model, but a more capable LLM cannot reliably repair a page that was never retrieved.
NeoMME is a newly created search term, but the project addresses a real problem: making Visual RAG more compact and easier to integrate. Its lasting value will become clearer when independent developers reproduce the results on different document collections. Today it is a credible candidate to evaluate, not a universal replacement for every document pipeline.
