NeoMME-800M-Retriever
by Hcompany
An 800M page and text retriever that returns a dense vector and late-interaction vectors from one pass
Hcompany/NeoMME-800M-RetrieverDeploy NeoMME-800M-Retriever
Single-tenantMixpeek has no managed extractor for this model. On a single-tenant deployment you upload the weights and a custom plugin serves them next to the rest of your pipeline.
Overview
NeoMME-800M-Retriever searches document pages and text with one small encoder. Give it a page screenshot or a passage and a single forward pass returns two things: one 1,792-dimension dense vector, scored by cosine similarity, and a set of 128-dimension vectors (one per text token or image patch), scored with late interaction. You can index the cheap dense vector, the more accurate multi-vector form, or both. H company released it in August 2026 under Apache-2.0, fine-tuned from their NeoMME-800M encoder.
The card reports 0.5560 nDCG@10 on ViDoRe V3 with late interaction and 0.4391 with the dense vector, and 0.5126 against 0.3686 on BEIR-15 text retrieval. The gap between the two columns is the price of the single vector.
At 800M parameters it sits well below the 4B to 8B page retrievers at the top of ViDoRe V3, which is the point: it is sized to encode a large archive on modest hardware, and the scores tell you what that trade costs.
Architecture
One shared bidirectional Transformer encoder for text and page images, with no separate vision tower: images are cut into 32 by 32 pixel patches, up to 2,048 pixels on the longest side by default, and processed in the same sequence as text. Hidden size is 1,792, the vocabulary 131,072 tokens and the context 16,384 tokens. The multi-vector head emits 128 dimensions per token or patch and is scored with MeanMaxSim. The dense embedding is a mean pool at 1,792 dimensions, trained with a Matryoshka objective so it can be cut to 1,024, 512, 256 or 128. Training combined a late-interaction and a Matryoshka dense contrastive loss.
Mixpeek SDK Integration
# The dense output is one vector per page, which is the shape the documents upsert
# endpoint takes. Encode each page with NeoMME-800M-Retriever as its card shows,
# keep dense_embeddings (1,792 floats, or a Matryoshka prefix such as 1,024), and
# upsert into a namespace whose vector index is declared at that width.
import requests
requests.post(
"https://api.mixpeek.com/v1/namespaces/ns_your_namespace/documents/upsert",
headers={"Authorization": "Bearer API_KEY"},
json={
"collection_id": "col_your_collection",
"documents": [{
"document_id": "report-2025-p14",
"vectors": {"neomme_dense": page_vector}, # the name of your index
"payload": {"source_key": "s3://docs/report-2025.pdf", "page": 14},
}],
},
)Capabilities
- Dense and late-interaction embeddings from a single forward pass
- Page screenshots and text in one encoder, multilingual
- Dense vector truncatable to 1,024, 512, 256 or 128 dimensions (Matryoshka)
- Apache-2.0 license; separate Sentence Transformers checkpoints for dense or late-interaction fine-tuning
Use Cases on Mixpeek
Benchmarks
| Dataset | Metric | Score | Source |
|---|---|---|---|
| ViDoRe V3 | nDCG@10 (late interaction) | 0.5560 | Model card: Hcompany/NeoMME-800M-Retriever (self-reported) |
| ViDoRe V3 | nDCG@10 (dense) | 0.4391 | Model card (self-reported) |
| ViDoRe V1 | nDCG@5 (late interaction) | 0.8744 | Model card (self-reported) |
| BEIR-15 | nDCG@10 (late interaction) | 0.5126 | Model card (self-reported) |
| BEIR-15 | nDCG@10 (dense) | 0.3686 | Model card (self-reported) |
Performance
We have not measured encoding latency or memory. A dense vector at 1,792 float32 dimensions is 7 KiB; the multi-vector form is 512 bytes per token or patch, so its size per page grows with the page's resolution.
Common Pipeline Companions
Frequently Asked Questions
What is the difference between NeoMME's dense and late-interaction embeddings?
The dense embedding is one 1,792-dimension vector per page or passage, compared by cosine similarity, so it is small and fits any vector index. The late-interaction embedding keeps a 128-dimension vector for every token or image patch and matches query tokens against them individually. On the card's ViDoRe V3 numbers that scores 0.5560 nDCG@10 against 0.4391 for dense, at the cost of storing many vectors per page.
Can I make NeoMME's dense vectors smaller?
Yes. The dense head was trained with a Matryoshka objective, so the first 1,024, 512, 256 or 128 dimensions still work as an embedding. Truncate queries and documents to the same width, and expect some loss in accuracy the smaller you go.
How does NeoMME-800M compare with larger page retrievers?
It scores lower. The card reports 0.5560 nDCG@10 on ViDoRe V3 with late interaction, while the 4B to 8B retrievers at the top of that leaderboard report around 0.63 to 0.67 on their own cards. It is roughly a tenth the size of the 8B models, so the choice is between accuracy and the cost of encoding a large archive.
Does Mixpeek run NeoMME-800M-Retriever?
Not as a built-in extractor. The dense vector fits Mixpeek's bring-your-own-vectors path today: encode with NeoMME yourself, upsert one vector per page into a namespace, and search it with a retriever that takes a query vector. The multi-vector form needs a single-tenant Enterprise deployment, where a custom plugin can declare feature_type multi_vector.
Specification
Research Paper
NeoMME: A Single-Tower Multimodal-Native Multilingual Foundation Encoder (arXiv 2609.01657)
arxiv.orgBuild a pipeline with NeoMME-800M-Retriever
Add this model to a processing pipeline alongside other extractors. Combine with retrieval stages for end-to-end search.
Run it on your own data, free