Коротко

Qdrant 1.19, выпущенный 5 августа 2026 года, разрешил хранить исходные векторы сразу в 4-битном формате TurboQuant. Для RAG-систем это потенциально заметное снижение дискового следа: у массива векторов теоретическая разница между `float32` и 4 битами составляет восемь раз. Но это не означает восьмикратного сокращения всей базы и тем более автоматической экономии без потери качества поиска.

Главный практический вывод: новую схему стоит проверять как отдельную конфигурацию retrieval-слоя — на собственной коллекции, эталонных запросах и реальной нагрузке. Экономия на диске полезна только тогда, когда качество выдачи и задержка остаются в согласованном коридоре.

Что именно появилось в Qdrant 1.19

В релизе добавлены несколько функций, которые важны не только разработчику, но и владельцу инфраструктурного бюджета:

  • TurboQuant 4-bit стал типом основного хранилища векторов: можно не держать рядом полную копию исходных `float32`-векторов;
  • компоненты коллекции получили единый выбор стратегии памяти `cold`, `cached` или `pinned`;
  • появился глобальный API квот;
  • для разреженного поиска добавлена статистика IDF на уровне запроса, что полезно при разделении данных по арендаторам;
  • улучшены пакетные чтения, работа с `io_uring`, хранение через `mmap` и телеметрия ресурсов внутри cgroup.

Отдельно в релизе исправлена уязвимость обхода пути при работе со снимками в S3. Поэтому обновление нельзя рассматривать только как эксперимент с экономией: командам, использующим S3-снимки, следует оценить патч и по линии безопасности.

Откуда берётся экономия

Обычный плотный embedding размерности 1536 в `float32` занимает 1536 × 4 байта, то есть 6144 байта без учёта индекса, идентификатора и метаданных. В 4-битном представлении один компонент требует половину байта, поэтому сырой массив такого вектора занимает около 768 байт.

Модельный пример:

  • 10 млн векторов;
  • размерность 1536;
  • исходный формат `float32`;
  • без учёта HNSW, payload, WAL, реплик, служебных структур и резервных копий.

В этом примере сырой массив составляет примерно 61,4 ГБ в `float32` и 7,7 ГБ при 4-битном хранении. Разница существенная, но это нижний слой расчёта. Полная коллекция будет больше: граф индекса, фильтры, текстовые поля, версии сегментов, репликация и снимки никуда не исчезают.

Поэтому корректная метрика — не «восемь раз дешевле», а стоимость рабочего набора данных на один миллион документов при заданных recall, p95 задержки и количестве реплик.

Почему 4 бита не равны бесплатному ускорению

TurboQuant использует преобразование векторов перед квантованием, чтобы уменьшить ошибку. Оригинальная работа описывает близкую к оптимальной скорость искажения без обучения кодовой книги. Реализация Qdrant адаптирует этот подход к реальным embedding-коллекциям и поддерживает несколько битностей.

Но у компрессии есть обмен:

  • меньше данных читается с диска и помещается в память;
  • добавляется вычисление преобразования и сравнения квантованных представлений;
  • приближённые расстояния могут изменить состав top-k;
  • результат зависит от распределения конкретной embedding-модели и типа запросов.

Независимая техническая дискуссия вокруг TurboQuant также содержит критические сравнения с более ранними подходами DRIVE/EDEN. Для бизнеса это полезное напоминание: теоретическое преимущество алгоритма и хороший публичный benchmark не заменяют проверку на собственных документах.

Где функция особенно полезна

Наиболее понятные сценарии:

  • каталог товаров с миллионами карточек и несколькими embedding-представлениями;
  • архив обращений, договоров или технических документов, где объём индекса растёт быстрее числа пользователей;
  • мультиарендный RAG, в котором каждому клиенту выделяется логический сегмент и важны квоты;
  • локальный контур с ограниченным объёмом NVMe или RAM;
  • резервные и периферийные узлы, где полный `float32`-слой слишком дорог.

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

Как проверить без риска для production

Практичный пилот занимает не замену текущей коллекции, а параллельное сравнение:

1. Зафиксировать версию embedding-модели и выгрузить репрезентативный срез коллекции.
2. Создать отдельную 4-битную коллекцию, не изменяя production.
3. Подготовить набор запросов с релевантными документами: типовые, редкие, короткие, длинные и содержащие профессиональную лексику.
4. Измерить Recall@k, MRR или nDCG, а для итогового RAG — долю ответов с корректной ссылкой на источник.
5. Сравнить размер коллекции, RAM рабочего набора, время построения, p50/p95 задержки и пропускную способность.
6. Проверить фильтры по правам доступа и мультиарендность отдельно от семантической близости.
7. Если качество top-k ухудшилось, испытать извлечение большего числа кандидатов и reranker.
8. Провести тест восстановления снимка и отката до включения новой схемы в production.

Минимальный набор должен включать не только «красивые» запросы. Нужны отрицательные примеры, близкие по смыслу документы разных версий и вопросы, на которые в базе нет ответа.

Как считать экономику

В расчёт стоит включить:

  • диски основного узла и реплик;
  • резервные копии и сетевой трафик снимков;
  • RAM или page cache;
  • время переиндексации и миграции;
  • стоимость reranker, если он нужен для компенсации потери recall;
  • инженерное время на тестирование и мониторинг;
  • стоимость ошибки выдачи в конкретном процессе.

Если 4-битная коллекция позволяет перейти на меньший сервер, сократить число NVMe-дисков или держать больше клиентов на одном кластере без нарушения SLO, эффект легко переводится в деньги. Если же база мала, а reranker становится обязательным и дорогим, выгода может исчезнуть.

Что взять руководителю

Qdrant 1.19 делает компрессию частью архитектуры хранения, а не только ускорителем поверх полной копии векторов. Это важный шаг для локальных RAG-систем с растущим индексом.

Но решение следует принимать по четырём цифрам: размер коллекции, Recall@k, p95 задержки и стоимость восстановления. Начните с параллельной коллекции и измеримого теста. Векторный слой любит худеть, но бизнесу всё равно нужна контрольная примерка.