What Is EVE Preview 4.5B? Tencent's OCR-Free Document Retriever
Tencent's EVE Preview 4.5B retrieves document pages as images using ColBERT-style late interaction, skipping OCR entirely for tables and charts.
What is EVE Preview 4.5B?
EVE Preview 4.5B is a visual document retriever from Tencent, a 4.5 billion parameter model that finds relevant pages in a document collection by looking at them as images rather than converting them to text first. Instead of running OCR on a PDF, chopping it into text chunks, and hoping the layout survives the conversion, EVE encodes both the document page (as raw pixels) and the user’s text query into sets of small vectors, then compares them directly. It reportedly ranked first on visual document retrieval benchmarks, outperforming larger models in the process.
TL;DR
- EVE Preview 4.5B is Tencent’s OCR-free document retriever that matches text queries against document page images instead of extracted text.
- It uses a ColBERT-Paligemma (ColPali-style) architecture, meaning a single shared backbone encodes both the query and the image into many small token-level vectors instead of one summary vector per document.
- The model emits compact 128-dimensional vectors, which keeps index sizes small enough for large-scale deployment, reportedly fitting a million pages under roughly 180 GB.
- It scores how well a page answers a question but does not extract the actual answer, it’s a retrieval step meant to hand off the winning page to a separate reader model.
- In testing on an invoice image and a dense academic references page, the model correctly scored the right page higher, including matching a single citation buried among many.
- It’s designed for messy real-world documents, financial filings, scanned forms, invoices, and multilingual technical reports, where OCR typically mangles tables and charts.
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
Why does OCR break document retrieval?
Traditional document search pipelines convert PDFs and scans into plain text before indexing them. That conversion step is where information gets lost. Tables lose their row and column structure. Charts turn into meaningless strings or vanish outright. Visual hierarchy, like which number is a header versus a total, disappears once everything becomes a flat block of text.
This matters most for exactly the documents people actually need to search: financial filings, invoices, scanned forms, and technical reports full of tables and figures. A retrieval system built on OCR output inherits every mangled table and garbled chart from that conversion step, no matter how good the underlying language model is downstream.
EVE’s approach is to skip the OCR conversion entirely. It treats a document page as an image and searches directly against that image, preserving the layout and visual structure that OCR would otherwise destroy.
How does EVE’s ColBERT-Paligemma architecture work?
EVE is built around a single shared backbone, currently based on a model referred to as ColBERT 3.5, that processes both the text query and the document image through the same set of weights. This is a key detail: it isn’t two separate encoders bolted together, it’s one network used twice.
On the query side, text (something like “total amount due”) is broken down and passed through the backbone, producing one vector per word or token. On the document side, the raw image, pixels and all, goes through the same backbone, producing one vector per visual patch of the page. Instead of collapsing an entire page into a single summary vector, the page stays represented as a collection of many small vectors, each tied to one region of the image.
At query time, the system runs a max-similarity (“MaxSim”) comparison between the query’s token vectors and the page’s patch vectors, then sums up the best matches. This late-interaction style scoring means a single well-matched detail, like one line item in a table or one citation in a long reference list, can drive a high relevance score even if the rest of the page is irrelevant to the question.
The name “ColPali” (referenced in EVE’s design as ColBERT-Paligemma) comes from combining two prior ideas: ColBERT, a text retrieval technique that keeps per-token vectors around for late interaction instead of squashing a document into one embedding, and PaliGemma, a vision-language model that first applied that same late-interaction idea to document images. EVE swaps in a stronger backbone and compresses the resulting vectors down to a native 128 dimensions, which keeps the index footprint small without sacrificing the per-patch granularity that makes the retrieval accurate.
What does EVE actually output?
It’s worth being precise about what EVE does and doesn’t do. Given a page image and a question, it returns a relevance score, a number indicating how well that page matches the query. It does not extract or generate the answer itself.
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
In a demonstrated test using an invoice image, EVE was asked two questions: the total amount due and the price of a specific part. It returned scores of roughly 15.19 and 14.12 for the two questions, both high because the invoice image did in fact contain answers to both. But the model’s output was just the score, not the dollar figure or the part price. Finding the right page is EVE’s job. Reading the exact answer off that page is left to a separate reader model.
This is intentional. In a full retrieval pipeline, EVE is the search step: point it at a large set of scanned pages, invoices, or reports, and it surfaces the page most likely to contain the answer. That page image then gets passed to a vision-language reader model (a model like a general-purpose VLM capable of reading text and tables from images) which pulls out the specific number or fact. Retrieval finds the needle, the reader model reads it. Together, that two-stage setup forms a document RAG (retrieval-augmented generation) system that works directly off images instead of OCR-extracted text.
Is EVE accurate on hard retrieval cases?
Based on demonstrated testing, EVE performed well even on cases designed to be difficult. Beyond the invoice test, it was tried against a dense page of academic references, the kind of page packed with dozens of citations in small text. The query asked which specific paper introduced a particular technique (“page attention”), a detail buried in one citation among many others on the page.
EVE scored this correctly, matching the query to the reference page even though the answer was a single line among a crowded list. That’s a meaningful test because it shows the model isn’t just doing broad topic matching, it’s picking out a specific, narrow detail from a visually dense page. That kind of fine-grained matching is exactly what the token-level late-interaction design is meant to enable: the query’s vectors don’t need the whole page to be relevant, they just need to find their best match somewhere in the page’s patch vectors.
Why does the compact vector size matter for real deployments?
Retrieval systems live or die on whether they can scale to real document collections, which often means millions of pages. A retriever that produces rich, accurate scores but bloats your index to an unusable size isn’t practical.
EVE’s vectors are compressed to a native 128 dimensions per token or patch. That’s small enough that, per the model’s reported figures, an index covering a million document pages fits under roughly 180 GB. For teams building retrieval over large scanned archives, financial filing databases, or multilingual document sets, that index size is what makes deploying a late-interaction, multi-vector retriever feasible instead of purely theoretical.
How do you run EVE locally?
EVE Preview 4.5B can be run on a single GPU. In one demonstrated setup, the model loaded in bfloat16 precision and used roughly 10 GB of VRAM, tested on an Nvidia RTX A6000. The setup involved a standard Python environment, installing the model’s dependencies, and enabling bidirectional attention (a setting the model needs to properly encode document images alongside text). From there, encoding a document image and a set of text queries into token vectors, then computing MaxSim scores between them, is a relatively short script.
This puts EVE within reach of a single well-specced workstation GPU rather than requiring a multi-GPU server, which matters for teams wanting to prototype an OCR-free retrieval pipeline before committing to production infrastructure.
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
Frequently Asked Questions
What does EVE Preview 4.5B actually do?
It retrieves the most relevant document page for a given text query by comparing image-based visual representations of pages against the query, without converting the document to text via OCR first.
Does EVE replace the need for a reader model?
No. EVE only scores and ranks pages by relevance. Extracting the actual answer, like a specific dollar figure or citation, requires passing the retrieved page to a separate vision-language reader model.
Why is skipping OCR an advantage for document search?
OCR conversion tends to destroy table structure, mangle charts, and lose visual layout cues. By encoding document pages directly as images, EVE preserves that structure and can match queries against visual details that OCR would have discarded.
What is ColBERT-Paligemma or ColPali?
It’s the architectural approach EVE follows: a shared backbone produces per-token vectors for both text queries and image patches (following ColBERT’s late-interaction idea), applied to document images (an approach pioneered by PaliGemma-based models). EVE uses a stronger backbone and compresses vectors to 128 dimensions.
How much hardware do you need to run EVE locally?
In a demonstrated test, the model loaded in bfloat16 and used approximately 10 GB of VRAM on an Nvidia RTX A6000, suggesting it’s runnable on a single modern GPU rather than requiring multi-GPU infrastructure.