EVIE Visual Document Retrieval: Budget the Index First
On September 8, 2026, Tencent published the final EVIE-4.5B and EVIE-8B visual document retrievers, along with training code, evaluation tooling, and a compression pipeline. The headline claim is benchmark leadership, but the more useful change is operational: EVIE-4.5B can shorten its embeddings at runtime and compress each page to 32 or 64 vectors. That turns visual RAG from a model-ranking exercise into an index-budget decision.
The timing matters because a second project reached the same bottleneck from a different direction. Five days earlier, H Company released NeoMME, a smaller multilingual multimodal encoder whose retriever also compresses late-interaction indexes. Meanwhile, Sentence Transformers added a common MultiVectorEncoder interface for this model family. The trend is broader than one launch: visual document retrieval is becoming deployable infrastructure, and storage economics now belong in the model-selection checklist.
Reader value: This guide shows how to compare EVIE and similar visual retrievers by page-vector footprint, retrieval quality, and serving constraints—not by one leaderboard number.
Why visual RAG indexes grow so quickly
Traditional text RAG usually extracts text, chunks it, and stores one dense vector per chunk. Visual document retrieval takes a different path. It embeds a rendered page directly, preserving charts, tables, spatial layout, typography, and other information that OCR pipelines can flatten or lose.
The strongest visual retrievers often use late interaction. Instead of collapsing a page into one vector, they retain many vectors and compare every query token with the most relevant page token. Hugging Face's MultiVectorEncoder guide explains the bargain clearly: token-level matching preserves more information, but it produces a much larger index.
For a rough uncompressed estimate, use:
index bytes = pages × vectors per page × dimensions × bytes per value
That formula excludes metadata, vector-database overhead, replication, and temporary build storage. It is still the right first test. If the raw vectors already break the storage budget, the system will not become cheaper after operational overhead arrives.
EVIE makes both multiplicative terms adjustable. Its Prefix-MRL representation allows EVIE-4.5B to truncate a single 2,048-dimensional projection to 1,024, 512, 256, 128, or 64 dimensions at runtime. Its Hierarchical Agglomerative Clustering, or HAC, reduces roughly 750 page vectors to 64 or 32 centroids. One knob shortens every vector; the other keeps fewer vectors.
EVIE's useful result is a cost curve
Tencent's EVIE repository reports a ViDoRe V3 nDCG@10 score of 66.02 for EVIE-4.5B at 2,048 dimensions. Truncating to 128 dimensions lowers the reported score to 65.27, while 64 dimensions reaches 64.51. These are vendor-reported results, not independent production measurements, but they expose something a single rank cannot: the slope of quality as the index shrinks.
The HAC results make the tradeoff more concrete. Tencent reports these production-oriented configurations for one million pages:
| EVIE configuration | Vectors per page | Payload per page | Reported index size | ViDoRe V3 nDCG@10 |
|---|---|---|---|---|
| 64 dimensions, HAC 32 | 32 | 4 KiB | 3.81 GiB | 59.58 |
| 64 dimensions, HAC 64 | 64 | 8 KiB | 7.63 GiB | 62.06 |
| 128 dimensions, HAC 32 | 32 | 8 KiB | 7.63 GiB | 61.40 |
| 2,048 dimensions, uncompressed | about 750 | about 2.93 MiB | about 2.79 TiB | 66.02 |
The last row is a simple BF16 payload estimate from Tencent's stated dimensions and approximate token count, not a published EVIE SKU. It illustrates the decision. Moving from the full representation to the smallest HAC configuration cuts raw vector payload by roughly three orders of magnitude, while the vendor's ViDoRe V3 score falls by 6.44 points.
That does not mean the smallest index is automatically best. It means teams can now buy retrieval quality with explicit storage. The correct choice depends on how much a missed page costs, how many pages must be indexed, and whether a second-stage reranker can recover precision.
NeoMME confirms that compression is the category problem
H Company's NeoMME release approaches the same problem with smaller 260M- and 800M-parameter encoders. NeoMME-Retriever produces both dense and late-interaction embeddings in one pass. The company reports that its 260M model processes about 51 high-resolution pages per second on an NVIDIA L40S.
More importantly, H Company reports reducing a late-interaction page representation from roughly 1.5 MB to 6 kB using hierarchical token pooling and asymmetric quantization. That is a claimed 255-fold compression while retaining more than 95% of baseline nDCG@10.
EVIE and NeoMME are not directly comparable from those numbers. Their models, datasets, compression methods, and evaluation protocols differ. The shared signal is architectural: both teams treat token count and vector width as first-class deployment variables. Accuracy remains necessary, but an unbounded index is no longer an acceptable default.
The ecosystem is moving in the same direction. Sentence Transformers 6.0 introduced MultiVectorEncoder for ColBERT-style late interaction, including visual document models. A common interface lowers integration friction and makes it easier to run the same corpus-level tests across checkpoints rather than copying a model card into an architecture decision.
Choose an index budget before a model
Start with a service-level objective, not a leaderboard. Write down four constraints:
- Corpus size now and in 12 months.
- Maximum index bytes per page, including replication.
- Acceptable retrieval miss rate on business-critical queries.
- Maximum page-encoding and query latency on your actual hardware.
Then allocate a raw-vector budget. A ten-million-page archive with a 10 kB payload target has about 95 GiB of raw embeddings before database overhead and replication. EVIE's 64-dimension HAC-64 configuration fits that raw budget at roughly 76 GiB; the full 2,048-dimensional representation does not come close.
Do not select the compression level globally on day one. Stratify the corpus. Annual reports, invoices, scanned forms, engineering diagrams, and slide decks fail differently. Tables may benefit from more retained visual tokens than clean forms. Multilingual scans may expose weaknesses hidden by an English-heavy aggregate score.
A practical evaluation should record quality against bytes:
| Test | Measure |
|---|---|
| Retrieval | Recall@k and nDCG on real queries |
| Compression | Bytes per indexed page after serialization |
| Encoding | Pages per second and peak GPU memory |
| Search | p50 and p95 latency at target corpus size |
| Failure analysis | Misses by document type, language, and layout |
| Operations | Build time, replication cost, and re-index duration |
Plot quality on the vertical axis and total stored bytes on the horizontal axis. The best configuration is usually near the knee of that curve, not at its most accurate or smallest endpoint.
A safer deployment pattern
Use compressed visual retrieval as a candidate generator, not the final authority. Retrieve a wider first-stage set, then rerank the page images or extracted evidence with a more expensive model. This makes aggressive compression easier to tolerate because the first stage only needs to preserve the relevant page in the candidate pool.
Keep a small uncompressed evaluation shard. When a compressed index misses a known-relevant page, compare it with the full representation. That separates model weakness from compression loss. Without this control, teams often blame the retriever for an error introduced by their own index settings.
Version the index configuration alongside the model:
{
"model": "tencent/EVIE-4.5B",
"embeddingDimensions": 128,
"compression": "hac",
"vectorsPerPage": 32,
"valueType": "bf16",
"evaluationSet": "visual-search-prod-v3"
}
The exact schema is yours, but the principle is not optional. A model name alone no longer identifies the retrieval system. Dimension, token compression, precision, page rendering, and benchmark revision all change the result.
Limitations and open questions
Tencent's numbers are self-reported, and the EVIE repository says a formal paper with architectural ablations is still forthcoming. The released code and weights improve inspectability, but they do not replace independent replication. ViDoRe is a useful benchmark family, yet its maintainers distinguish single-model retriever evaluation from end-to-end pipeline evaluation. Production RAG quality also depends on query generation, filtering, reranking, and answer grounding.
Storage figures can be misleading when they exclude vector-database metadata, graph indexes, replicas, and backups. Page resolution changes token counts and encoding cost. Compression can also fail unevenly: a small average quality drop may conceal severe regressions on one language or document class.
Finally, visual retrieval does not eliminate OCR. Teams may still need extracted text for citations, accessibility, exact string matching, compliance review, or answer generation. The useful architecture is often hybrid: visual retrieval for candidate recall, text extraction for verification, and a reranker for final ordering.
The Bottom Line
EVIE's most important contribution is not first place on a leaderboard. It is an explicit quality-versus-index curve. Prefix-MRL and HAC let developers trade dimensions and page tokens for storage instead of accepting one fixed representation.
NeoMME and Sentence Transformers show that this is becoming an ecosystem concern, not a Tencent-specific feature. Before adopting any visual retriever, set a bytes-per-page target, evaluate real failure modes at several compression points, and keep an uncompressed control. In visual RAG, the model that wins a benchmark can still lose the deployment if its index cannot be afforded, rebuilt, or searched on time.
