Qdrant quantization: как сжать векторы и проверить качество поиска

Что именно сжимает Qdrant quantization?

Для локального поиска по документам схема такова: embedding-модель создаёт dense-векторы, Qdrant индексирует их и возвращает близкие точки, а локальная LLM формирует ответ по найденным фрагментам. Квантизация касается представления векторов внутри поиска Qdrant, не весов LLM в GGUF и не исходного текста документов. В self-hosted сценарии заранее определите одну модель эмбеддингов, её версию, размерность и одинаковый способ получения вектора документа и запроса. s1 s2

Qdrant предлагает scalar, binary, product и TurboQuant; простой первый кандидат — scalar int8. Он преобразует компонент исходного float32-вектора в 8-битное представление: размер сжатого представления компонента меньше вчетверо, но оригиналы продолжают существовать. Это не обещает сокращения диска или RAM всей коллекции вчетверо: у неё есть HNSW, payload, индексы, служебные данные и кеш. Вендор описывает снижение погрешности на своих наборах, но это не измерение Modelium и не гарантия для русскоязычного корпуса. s1 s3 s4

Binary и product могут сжать сильнее, но выбор зависит от размерности и распределения ваших векторов; документация отдельно рекомендует для binary rescoring оригиналами. Не ставьте их вместо scalar только потому, что у метода больше заявленный коэффициент: сравнивать нужно качество своей поисковой задачи и цену дополнительного чтения исходников. s1

Как подготовить честный контрольный набор?

Используйте локальный тестовый Qdrant с изолированным портом и обезличенными документами, не меняйте рабочую коллекцию. Сохраните версию сервера, конфигурацию dense-векторов (размерность, distance), модель и ревизию embeddings, одинаковые point ID и payload. Подготовьте набор реальных для задачи запросов и для каждого ожидаемые ID релевантных фрагментов; добавьте короткий запрос, длинный запрос и выборку с типовым filter, если фильтрация действительно используется. Отдельно фиксируйте состояние и нагрузку сервера. s2 s6 s8

Создайте две тестовые коллекции с одними данными, структурой и режимом индексации: docs_control без quantization и docs_int8 с scalar. В конфигурации новой коллекции по документации Qdrant задайте те же vectors.size и vectors.distance, а для второй дополнительно "quantization_config":{"scalar":{"type":"int8","quantile":0.99,"memory":"pinned"}}. Здесь size должен совпасть с реальной размерностью вашей embedding-модели; пример Qdrant 768 не является требованием для всех моделей. quantile:0.99 — документированный параметр примера, не универсально лучший результат. Для memory:pinned заранее проверьте доступную RAM под сжатую копию. s1 s2 s3

Если оцениваете уже существующую отдельную тестовую коллекцию, официальная документация описывает PATCH /collections/{collection_name} с quantization_config, но без повторного объявления векторов. Изменение конфигурации не применяйте к рабочему адресу и не принимайте один ответ API за завершение перестройки: дождитесь готовности коллекции, сверяйте число точек и выполните контрольный запрос. Лучше держать отдельную нетронутую контрольную коллекцию, чтобы сравнить также расходы хранения, а не только режим запроса. s1 s7

Как сравнить качество выдачи при одинаковых запросах?

Отправляйте запросы через POST /collections/{collection_name}/points/query с одинаковыми вектором запроса, limit, фильтром, HNSW-параметрами и окружением. Для контроля на docs_int8 документация позволяет установить "params":{"quantization":{"ignore":true}}, чтобы искать без сжатой копии; результаты сохраняйте отдельно от результатов docs_control. Для сценария со сжатием явно установите "params":{"quantization":{"ignore":false,"rescore":true,"oversampling":2.0}}: rescore пересчитывает кандидатов по исходным векторам, а oversampling увеличивает их пул перед пересортировкой. Для scalar значение rescore по умолчанию может быть выключено, поэтому явно фиксируйте режим, а не сравнивайте неуказанные defaults. s1 s8

Для каждого запроса запишите ID топ-k, оценку релевантности и задержку: доля релевантных ID в топ-k — отдельная оценка по вашей ручной разметке; overlap@k с точным контрольным списком — только проверка совпадения с контролем, не доказательство полезности документа для пользователя. Не смешивайте эти две величины. Сравните минимум режим без квантизации, scalar без пересортировки и scalar с rescoring при тех же запросах; если сравниваете latency, задайте сопоставимую конкуренцию, повторения и температуру кеша. Числовой прирост не заявлен: Modelium такой эксперимент не проводил. s1 s8

При фильтрации повторите тот же filter для обеих коллекций. Если извлечение нужного источника ухудшилось, попробуйте oversampling и rescore, проверьте размерность и одинаковость записанных векторов, а затем оцените конечный ответ RAG с цитатой; сам ответ LLM может ошибаться даже при одинаковом топ-k. Разграничение доступа проверяйте отдельно: метка в payload и клиентский фильтр сами по себе не заменяют авторизацию. Гайд по фильтрам описывает отдельный отрицательный тест. s1 s8

Как измерить память и задержку без ложной «экономии ×4»?

На Qdrant v1.18+ используйте GET /collections/docs_control/memory и тот же путь для docs_int8. Разделяйте Disk, RAM (закреплённые данные) и Cached (вытесняемые страницы ОС), смотрите компоненты Vectors, индексы и payload, а не только общее число процесса. Это оценки: в документации прямо отмечены неучтённые аллокации; Cached может меняться при давлении на память и после прогрева. Запишите версию, размер двух коллекций, состояние индекса и объём page cache вместе с нагрузкой. s4

С Qdrant v1.19 настройка memory позволяет независимо размещать оригиналы, HNSW и квантизованные векторы: pinned закрепляет поддерживаемую структуру в RAM, cached использует прогретый page cache, cold не прогревает данные заранее. Оригинальные dense-векторы нельзя просто поставить в pinned по этому интерфейсу; если оригиналы cold, а сжатая копия pinned, рескоринг читает оригиналы и может увеличить задержку. Старые флаги on_disk и always_ram не исчезли из исторических установок, но не следует приписывать им семантику v1.19 без проверки версии. s3 s5

Сравнивайте несколько одинаковых прогонов, медиану и хвост задержки при зафиксированных данных и ресурсе узла. Если выигрыш памяти ценой худшей выдачи или неприемлемого хвоста задержки, вернитесь к контрольному варианту; не отключайте rescore до проверки релевантности. Для продакшена планируйте отдельное окно, резервную копию и обратимый перенос трафика между коллекциями — не экспериментируйте с единственной рабочей копией. s1 s4 s5

Следующий шаг: составьте размеченный набор запросов по методике оценки RAG, проведите на отдельных коллекциях сравнение ID и релевантности топ-k, RAM/кеша/диска и задержки, затем принимайте решение по собственным порогам задачи. Modelium не проводил этого теста и не публикует выдуманных измерений. s1 s4 s8