Perplexity выпустила две late interaction модели для поиска по страницам PDF без OCR

Perplexity выложила на Hugging Face коллекцию pplx-embed-v2 и в ней две модели pplx-embed-v2-late. Они работают по принципу late interaction и ищут по страницам документов как по картинкам. Страница целиком, с таблицами, графиками и версткой, превращается в эмбеддинги, и этап распознавания текста (OCR) из пайплайна уходит. Блог Qdrant от 13 октября 2026 года сразу называет слабое место релиза: у визуального ретривера Perplexity есть проблема с размером, и команда Qdrant заявляет, что её решила. В доступном фрагменте материала детали решения не приводятся, поэтому ниже разделены установленные факты и разумные предположения.

Зачем искать по странице, а не по тексту

Число в финансовом отчёте без строки, столбца и единицы измерения ничего не значит. График без подписей тоже. Классический пайплайн вытаскивает из PDF текст через OCR, режет его на фрагменты и индексирует. Структура при этом разваливается: ячейка таблицы оказывается оторвана от заголовка столбца, подпись оси от самой оси.

Perplexity предлагает другой путь. Модель получает изображение страницы и кодирует его целиком. Таблица остаётся таблицей, а график графиком. Запрос ищет совпадение в странице так, как её видит человек. Для корпусов с отчётами, презентациями и техническими спецификациями это снимает целый слой ошибок: не нужно настраивать OCR под разные шрифты, языки и сканы.

Где возникает проблема размера

Late interaction устроено иначе, чем обычный поиск по одному вектору на документ. В схемах вроде ColBERT и ColPali страница представляется набором векторов, а релевантность считается сопоставлением каждого вектора запроса с лучшим вектором страницы (MaxSim). Точность выше, но хранить приходится не один вектор на страницу, а много. Это общий принцип класса моделей, а не данные из релиза. Конкретные размерность и число векторов на страницу в доступном тексте не указаны.

Именно поэтому заголовок о «проблеме размера» читается как проблема объёма мультивекторного индекса. Это вывод, а не цитата. На корпусе в миллионы страниц разница между одним вектором и сотнями на страницу означает разницу в памяти, стоимости серверов и задержке поиска. Qdrant давно поддерживает мультивекторное хранение, так что его интерес к теме понятен. Как именно команда уменьшила размер, нужно смотреть в полной версии поста.

Что известно на сегодня

• Разработчик: Perplexity, коллекция pplx-embed-v2 на Hugging Face
• Модели: две late interaction модели pplx-embed-v2-late
• Вход: изображение страницы документа
• Что кодируется: таблицы, диаграммы, раскладка
• OCR: не требуется
• Источник разбора: блог Qdrant, 13 октября 2026 года
• Не раскрыто в фрагменте: размерность эмбеддингов, число векторов на страницу, результаты бенчмарков, лицензия, метод сжатия

Что проверить перед внедрением

Не стоит переносить продакшен-поиск на визуальные эмбеддинги, пока не посчитаны несколько вещей.

1. Сколько векторов модель выдаёт на страницу и сколько памяти займёт ваш корпус при такой плотности. Умножьте число страниц на размер мультивектора и сравните с бюджетом. 2. Как ведёт себя качество на ваших документах. Возьмите 50–100 реальных запросов к таблицам и графикам и сравните выдачу с базовым вариантом OCR плюс текстовые эмбеддинги. 3. Поддерживает ли ваша векторная база мультивекторы и MaxSim нативно. Иначе придётся строить пересчёт самостоятельно. 4. Какой метод сжатия применён и что он делает с качеством. Любое уменьшение индекса нужно проверять на тех же запросах, а не доверять средним цифрам.

Если корпус небольшой, а таблицы и диаграммы в нём главные, визуальный ретривер можно пробовать уже сейчас. Если страниц миллионы, решающим будет не качество, а то, насколько удалось сжать индекс.