Cohere released Embed 5, семейство моделей эмбеддингов. В него вошла модель с акцентом на качество, Embed 5 Pro (embed-v5.0-pro), и более легкая модель, Embed 5 Fast (embed-v5.0-fast). Обе модели принимают на вход текст и изображения, поддерживают более 100 языков и используют общее пространство эмбеддингов.

В релизном посте Cohere упоминаются «визуально насыщенные документы», включая PDF, и производительность модели на них заслуживает внимания. Насколько мы понимаем, для оценки результатов ViDoRe V3 они тестировали поиск по PDF в условиях, напоминающих OCR; по их словам, в рамках ViDoRe V3 «оценки состояли из результатов распознавания текста, подготовленных авторами ViDoRe».

Тем не менее, модели Cohere Embed 5 также напрямую принимают изображения страниц. Для поиска по изображениям страниц PDF мы обычно рекомендуем использовать визуальные модели с поздним взаимодействием (late-interaction), чтобы избежать парсинга и извлечения текста. Мы не думали, что плотные эмбеддинги смогут конкурировать с поздним взаимодействием, но провели тест из любопытства и выяснили, что Embed 5 Pro, представляющая целое изображение страницы PDF в виде одного плотного вектора, обошла несколько моделей с поздним взаимодействием на пяти публичных англоязычных корпусах ViDoRe V3.

Это означало, что нашему сообществу пригодится готовое руководство по запуску моделей Cohere для масштабируемого поиска по PDF в Qdrant, поэтому вот статья об этом:)

Если вы хотите сразу перейти к руководству, отправляйтесь к разделу «Это могло быть обычным письмом».

Особенности поиска по PDF

Во многих PDF ответы содержатся в графиках, таблицах и диаграммах. Классический путь извлечения текста с помощью OCR (превращение изображения в текст) для последующего текстового поиска может привести к потере информации, скрытой в сложных визуальных макетах, поскольку взаимосвязи между словами на странице могут не пережить обработку OCR.

Для таких документов рекомендуется использовать визуальные модели с поздним взаимодействием, такие как ColPali и ColQwen. Они сохраняют вектор для каждого небольшого патча изображения и оценивают каждый токен запроса по наиболее подходящему фрагменту. Это обеспечивает детализацию и избавляет от проблем с разметкой OCR, но также приводит к появлению около тысячи векторов на страницу.

Существуют известные приемы для уменьшения количества векторов в представлении страницы:

Наш учебник по поиску по PDF рассматривает пулинг в сочетании с переранжированием: усреднение векторов патчей по строкам или столбцам сокращает количество векторов на этапе первичного поиска в 20–30 раз.
MUVERA преобразует список векторов токенов с поздним взаимодействием произвольной длины в один вектор фиксированной (но очень большой) длины, который аппроксимирует многовекторную оценку. Этот вектор используется для первичного поиска, за которым следует переранжирование с использованием исходных многовекторов.

Позднее взаимодействие сложно масштабировать не только из-за проблемы с размером. MaxSim — метрика сходства, используемая моделями с поздним взаимодействием — не может напрямую работать с HNSW (индексом векторного поиска), из-за чего для миллиардов точек приходится использовать подходы, подобные MUVERA.

Поэтому сценарием мечты для реального масштабирования было бы использование одного плотного вектора для поиска по визуально насыщенным документам. Но насколько это осуществимо?

Плотные модели приближаются к цели

Мы заинтересовались, увидев фразу «визуально насыщенные документы» в посте Cohere.

Мы протестировали Embed 5 на ViDoRe V3 пяти публичных англоязычных корпусах: учебниках по информатике, финансовых отчетах, отчетах о труде ЕС, технических регламентах ВВС США и фармацевтических документах FDA. В сумме они содержат 12 969 изображений страниц и 1 489 англоязычных вопросов.

Результаты запуска ViDoRe от Cohere используют RCP-nDCG. Это ценный подход для устранения ложноотрицательных результатов в публичных бенчмарках, который может стать будущим оценки поиска; однако мы по привычке используем стандартный показатель nDCG по всему корпусу для сравнения с опубликованными результатами ViDoRe.

Результаты запуска ViDoRe от Cohere используют . Это ценный подход для устранения ложноотрицательных результатов в публичных бенчмарках, который может стать будущим оценки поиска; однако мы по привычке используем стандартный показатель nDCG по всему корпусу для сравнения с опубликоваными результатами ViDoRe.

Один вектор на страницу в топ-группеСреднее по 5 публичным англоязычным корпусам · Больше — лучше0204060ColEmbed-3B-v2Многовекторный67.5Embed 5 Pro1 вектор / страница65.8Jina-v4Многовекторный65.2ColQwen2.5Многовекторный61.2Nomic-7B1 вектор / страница59.3ColPaliМноговекторный54.8nDCG@10

И вау, кажется, Embed 5 Pro опережает несколько моделей с поздним взаимодействием (данные обучения не опубликованы, так что мы, возможно, случайно тестируем здесь на обучающей выборке, но если нет, то ваууу!).

Это отличная новость для продакшна: с одним плотным вектором всё становится намного, намного удобнее — загрузил страницу, получил один вектор, и никаких проблем с OCR. Этот вектор отлично укладывается в обычный поиск HNSW, избегая проблемы асимметрии MaxSim и сохраняя изображение страницы в качестве входных данных.

Великолепно, заверните 14 штук прямо сейчас

Для масштабных продакшн-пайплайнов каждый сохраненный килобайт имеет значение, так как в больших масштабах они суммируются.

Полноразмерный вектор Embed 5 по умолчанию имеет размерность 2048. При хранении в формате float32 это составляет 8 КБ на страницу, но это Embed 5, используемый, так сказать, на «полную мощность».

Cohere разрабатывала эти модели с расчетом на «оптимизацию под потребности продакшна». Семейство Embed 5 поддерживает представления Matryoshka (MRL): первые N чисел вектора сохраняют большую часть его «смысла». Cohere рекомендует использовать 1024 размерности Matryoshka в формате int8 в качестве значения по умолчанию для продакшна: 1 КБ на вектор при качестве, которое они описывают как близкое к максимальной точности.

Можно ли еще сильнее ужать данные?

Для минимального потребления памяти они советуют использовать бинарные векторы в качестве быстрой предварительной фильтрации перед переранжированием с более высокой точностью. Давайте посмотрим, как далеко мы можем в этом зайти.

Мы можем объединить MRL с 1-битной бинарной квантизацией, сохраняя лишь информацию о том, больше или меньше нуля значение каждого измерения. Для полноразмерного вектора Embed 5 требуемый объем памяти сокращается с 8 КБ до 256 байт — в 32 раза.

При таком сильном сжатии чисел мы теряем информацию. Но что если сжимать запрос не так агрессивно, как документы?

Благодаря нашей асимметричной квантизации мы можем сохранить разрядность запроса на уровне 8 бит на число, в то время как векторы страниц остаются 1-битными.

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

В то же время, давайте не будем ограничивать нашу жадность и поэкспериментируем с MRL, объединив его с асимметричной квантизацией. Вы можете пойти еще дальше и поэкспериментировать с заменой Pro на Fast в запросах, следуя последнему тренду на легкие сменные модели запросов для инференса (мы тоже в тренде, загляните в Constella).

Мы используем сжатые векторы для поиска короткого списка кандидатов, а затем переранжируем этот полученный список с помощью полных векторов, как и советует Cohere. Сжатые копии остаются в оперативной памяти; полные векторы хранятся на диске до тех пор, пока не понадобятся для переранжирования.

Протестировано с Qdrant 1.19.2 и qdrant-client 1.20.0.

Подключитесь к Qdrant Cloud и загрузите изображение одной страницы:

Создайте коллекцию:

Загрузите страницу:

Выполните поиск:

Здесь под словом «сохраненное» понимается доля от полного качества ранжирования с 2048-мерными float32: среднее значение nDCG@10, равное 65,85, является нашей 100% базовой линией. Все результаты сжатия получены с использованием страниц Pro и запросов Pro на тех же 5 корпусах, если не указано иное.

Здесь под словом «сохраненное» понимается доля от полного качества ранжирования с 2048-мерными float32: среднее значение nDCG@10, равное 65,85, является нашей 100% базовой линией. Все результаты сжатия получены с использованием страниц Pro и запросов Pro на тех же 5 корпусах, если не указано иное.

Согласно нашим измерениям, чем короче сохраненный вектор, тем сильнее помогал запрос более высокой точности. Интуиция подсказывает, что меньшее количество измерений делает знаки с одинаковым весом более грубыми, поэтому сохранение силы запроса в каждом измерении приносит больше пользы.

В результате быстрого бенчмаркинга мы нашли отличный компромисс: 512 измерений, 1-битные страницы и 8-битный запрос, при этом топ-20 кандидатов переоцениваются с помощью полных векторов. Это сохраняет 99,2% качества полных векторов при 64 байтах на страницу в оперативной памяти, что в 128 раз меньше по сравнению с полным вектором float32.

Используя уровни памяти из Qdrant 1.19, мы храним исходные векторы как холодные на диске и закрепляем небольшие бинарные векторы в оперативной памяти, как описано в нашем руководстве «Когда ваша коллекция не помещается в оперативную память». Оперативная память — это самая дорогая часть инфраструктуры и та часть, от которой зависит быстрый поиск, поэтому именно ее мы и оптимизируем здесь; наши размеры учитывают только векторы, а не индекс или полезную нагрузку.

Получение векторов для переоценивания с диска замедляет работу, но считываются только полные векторы кандидатов (20 штук на шаррд). Эти операции чтения также проходят через кэш страниц ОС, поэтому со временем полные векторы, затронутые переоцениванием, также занимают свободную оперативную память; ОС возвращает эту память, когда она требуется чему-то другому.

Это могло быть просто письмом

Для поиска по PDF-файлам без OCR мы обычно используем позднее взаимодействие (late interaction). Embed 5 Pro предоставляет нам конкурентоспособную альтернативу с одним вектором на корпусах ViDoRe V3, а в сочетании с функциями Qdrant это позволяет экономить еще больше ресурсов, используемых для поиска по PDF в больших масштабах:

Давайте прикинем «на салфетке»: для 10 миллионов страниц PDF несжатые векторы ColPali float32 заняли бы около 4,8 ТБ, полные векторы Embed 5 float32 — около 76 ГБ, а поисковые векторы по нашему рецепту — около 610 МБ в оперативной памяти с сохранением 99,2% качества ранжирования Embed 5 на 5 протестированных корпусах, что все еще выше результата ColPali на диаграмме.

Дисклеймер: 610 МБ — это объем оперативной памяти на старте; полные векторы, считываемые для переоценивания, со временем также заполняют кэш страниц ОС. Рецепт также хранит на диске около 95 ГБ полных и сокращенных векторов float. ColPali тоже можно сжимать; это расчеты байтов векторов без учета индекса и полезной нагрузки, где 1 КБ = 1024 байта.

Бонус: Cohere Rerank 5 (Pro & Fast)

Небольшую часть сэкономленных на оперативной памяти денег следует потратить на то, чтобы подарить мне маску для сна с логотипом Cohere, потому что Rerank 5 вышла как раз тогда, когда я заканчивал эту статью, и здорово подставила меня, заставив проверять, что она добавит в пайплайн.

Поиск по изображениям находит страницы без OCR. Если вы уже используете OCR и вас это устраивает, Rerank 5 может стать хорошим подспорьем для дальнейшего повышения качества ваших конвейеров на основе OCR, поскольку Rerank 5 принимает текст, а не изображения.

Мы проиндексировали текст OCR из ViDoRe V3 (его поле markdown) с помощью Embed 5 Pro, выполнили поиск и переоценили топ-20 страниц с помощью Rerank 5 Pro.

Среднее значение nDCG@10 по тем же 5 корпусам выросло с 66,8 до 73,2, а при использовании в текстовом поиске нашего рецепта на 64 байта — с 66,2 до 71,7.

Заключение

Мы выполняли поиск по изображениям страниц с помощью одного вектора Embed 5 Pro на страницу, а затем объединили Matryoshka, асимметричное квантование и переоценивание по полным векторам для сокращения объема оперативной памяти, необходимого для поиска.

С помощью Qdrant Cloud Inference мы можем напрямую отправлять изображение страницы в виде URI данных base64 в Qdrant Cloud. Qdrant вызывает Cohere и сохраняет вектор в рамках одного запроса, поэтому клиентскому коду не нужен отдельный шаг эмбеддинга, что избавляет от лишнего круга запросов от вашего приложения к Cohere.

Помимо асимметричного квантования, TurboQuant — это еще один вариант сжатия, который стоит протестировать; об этом рассказано в нашем посте про EmbeddingGemma 2 и руководстве по квантованию.

Используйте наш рецепт в своих производственных пайплайнах поиска по PDF, пишите нам о том, как он работает у вас, и спите спокойно, пока мы следим за релизами за вас!