Perplexity releases two late interaction models for searching PDF pages without OCR

Perplexity has posted the pplx-embed-v2 collection on Hugging Face, and it includes two pplx-embed-v2-late models. They work on the late interaction principle and search document pages as images. The whole page, with its tables, charts and layout, is turned into embeddings, and the text recognition (OCR) step drops out of the pipeline. A Qdrant blog post dated October 13, 2026 immediately names the release's weak spot: Perplexity's visual retriever has a size problem, and the Qdrant team says it has solved it. The available excerpt does not describe the solution, so what follows separates established facts from reasonable assumptions.

Why search by page instead of by text

A number in a financial report means nothing without its row, column and unit of measurement. A chart without labels is the same. A classic pipeline extracts text from a PDF with OCR, splits it into chunks and indexes them. That breaks the structure: a table cell ends up detached from its column header, an axis label from the axis itself.

Perplexity proposes a different approach. The model takes an image of the page and encodes all of it. A table remains a table, and a chart remains a chart. The query looks for a match in the page the way a person sees it. For corpora of reports, presentations and technical specifications, this removes a whole layer of errors: there is no need to tune OCR for different fonts, languages and scans.

Where the size problem comes from

Late interaction works differently from ordinary search with one vector per document. In schemes such as ColBERT and ColPali, a page is represented as a set of vectors, and relevance is computed by matching each query vector against the best-matching page vector (MaxSim). Accuracy is higher, but you have to store many vectors per page rather than one. This is a general principle of the model class, not data from the release. The available text does not give the specific dimensionality or the number of vectors per page.

That is why a headline about a "size problem" reads as a problem with the volume of a multi-vector index. This is an inference, not a quotation. On a corpus of millions of pages, the difference between one vector and hundreds per page translates into differences in memory, server cost and search latency. Qdrant has long supported multi-vector storage, so its interest in the topic is understandable. For exactly how the team reduced the size, you will need to read the full version of the post.

What is known so far

• Developer: Perplexity, the pplx-embed-v2 collection on Hugging Face
• Models: two late interaction models, pplx-embed-v2-late
• Input: an image of a document page
• What is encoded: tables, charts, layout
• OCR: not required
• Source of the analysis: Qdrant blog, October 13, 2026
• Not disclosed in the excerpt: embedding dimensionality, number of vectors per page, benchmark results, license, compression method

What to check before adopting it

Do not move production search to visual embeddings until you have worked out a few things.

1. How many vectors the model produces per page, and how much memory your corpus will take at that density. Multiply the number of pages by the size of the multi-vector and compare the result with your budget. 2. How quality holds up on your own documents. Take 50–100 real queries about tables and charts and compare the results with a baseline of OCR plus text embeddings. 3. Whether your vector database supports multi-vectors and MaxSim natively. If not, you will have to build the rescoring yourself. 4. Which compression method is used and what it does to quality. Any reduction in index size should be tested on the same queries, rather than relying on average figures.

If your corpus is small and tables and charts are what matter most in it, you can try a visual retriever right now. If you have millions of pages, the deciding factor will be not quality but how far the index can be compressed.