turbovec: Сжатие вкладок RAG в 16 раз с использованием TurboQuant на Rust

Возьмём реально используемый пайплайн обработки данных: десять миллионов документов, каждый из которых снабжён векторами модели OpenAI text-embedding-3-small размером 1536 измерений и сохраняется в формате float32. Ещё до добавления хотя бы одного байта метаданных объём самих векторов составляет 31 ГБ. При таком размере вопрос «Где это будет работать?» уже не кажется простым вопросом — это требует мощной облачной машины с большим объёмом памяти, скорее всего, принадлежащей кому-то другому, а также всех проблем, связанных с конфиденциальностью и эксплуатацией таких систем.

Если пропустить те же данные через инструмент turbovec с использованием 2 бит на измерение, объём сокращается примерно до 4 ГБ, что вполне помещается в оперативную память ноутбука с запасом. В оставшейся части статьи объясняется, почему это работает, в каких случаях этот инструмент является оптимальным, а в каких другие средства предпочтительнее.

Что такое turbovec

turbovec — это библиотека для векторных поисков на языке Rust с интерфейсами для Python, распространяемая под лицензией MIT; на момент написания этого текста у неё было примерно 950 звёзд на GitHub. Она реализует алгоритм TurboQuant, разработанный исследователями из Google Research и NYU, который был принят к публикации на конференции ICLR 2026.

Стоит упомянуть один важный момент: Google так и не опубликовала исходный код своего алгоритма, поэтому сообщество взяло это на себя. Проект RyanCodrai/turbovec направлен на векторный поиск, что является основным сценарием использования, тогда как отдельный проект hackimov/turboquant-kv применяет ту же идею для сжатия кэша KV у языковых моделей. Оба проекта являются независимыми open-source инициативами.

Другими словами, использование turbovec означает применение реализации алгоритма из Google Research, созданной сообществом, и на тестовых данных, которые сама команда FAISS использует, она превосходит FAISS от Meta, долгое время служивший стандартом для векторного поиска в памяти.

Как работает алгоритм

Как только вы его увидите, станет ясно, что метод на удивление прост. Он выполняется в четыре шага.

1. Разделение длины и направления

У каждого вектора-эмбеддинга есть модуль (его норма L2) и направление. Модуль извлекается и сохраняется в виде одного числа с плавающей точкой на каждый вектор, а остается направление длиной один единицы на высокомерномножественной сфере. Это может показаться незначительным, но всё последующее зависит от этого, поскольку векторы, находящиеся на поверхности сферы, можно обрабатывать с помощью геометрии.

2. Случайное вращение

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

Интуитивное объяснение: в высоких измерениях случайное вращение делает распределение каждой координаты предсказуемым. После вращения каждая координата каждого вектора следует известному, тесно сосредоточенному распределению Бета, которое при увеличении размерности приближается к гауссову. Распределение остается одинаковым независимо от входных данных. Юридические документы, отзывы о продуктах и медицинская литература статистически выглядят одинаково, поэтому данная схема не зависит от данных. Математики называют это сосредоточением меры на сфере, и это объясняет, почему не требуется этап обучения: вращение выполняет ту же работу, что и обученный кодовый справочник.

3. Выбор лучших категорий

Знание закона распределения каждой координаты позволяет заранее определить наилучший способ группировки значений. Двухбитная квантизация обеспечивает четыре группы для каждой координаты, а четырехбитная — шестнадцать. Этот метод называется скалярной квантизацией по формуле Ллойда-Макса; он позволяет ответить на простой вопрос: при известном законе распределения, где следует провести границы разделения, чтобы сделать среднюю погрешность округления максимально малой? При известности закона распределения ответ имеется в виде закрытой формулы. Кроме того, поскольку закон распределения после поворота одинаков для всех векторов, границы групп формируются на основе математических расчетов, а не данных.

4. Упаковка битов

Теперь каждая координата представляет собой небольшое целое число: от 0 до 3 при двухбитной квантизации или от 0 до 15 при четырехбитной. При плотной упаковке 1536-мерный вектор, занимавший 6 144 байта в формате float32, требует 384 байта при двухбитной квантизации или 768 байт при четырехбитной. Это соответствует сжатию в 16 и 8 раз соответственно.

Поиск без распаковки

Запросы никогда не декомпрессируют хранимые данные. Запрос сначала помещается в ту же область памяти, после чего сразу сравнивается с квантизированными кодами с использованием заранее подготовленных таблиц поиска. Внутренний цикл основан на инструкциях SIMD: для процессоров ARM используется NEON, для современных x86 — AVX-512BW, а в качестве альтернативы — AVX2.

Именно здесь библиотека, в отличие от алгоритма, демонстрирует свою ценность. Её реализованные вручную ядра SIMD обгоняют алгоритм FastScan библиотеки FAISS на 12–20 процентов на процессорах ARM и сопоставимы с ним или превосходят его на процессорах x86.

У этого метода также есть теоретическое обоснование. В статье TurboQuant доказано, что уровень искажения остается в пределах примерно 2,7 раз от информационно-теоретического нижнего предела — предела скорости искажения по Шеннону. Проще говоря, информационная теория определяет, насколько можно сжимать данные, не теряя информации, а TurboQuant достигает уровня, в 2,7 раза близкого к этому пределу, без какой-либо дополнительной настройки. Никто не может добиться значительно лучших результатов при заданном бюджете битов, и это подтверждается формальным доказательством в статье.

Три случая, когда это оправдано

Достаточная память

Вернемся к первоначальным цифрам: 31 ГБ для формата float32 против 4 ГБ при использовании turbovec с 2 битами на элемент. Наличие такого небольшого объема памяти меняет возможности.

• Эту базу данных можно разместить рядом с приложением на одном сервере, без необходимости использования отдельной инстанции векторной базы данных.
• Разработчики могут запускать её на ноутбуках для локальных тестов.
• Более дешевые уровни памяти в облачных инстансах становятся доступными, что значительно снижает затраты.
• Весь индекс хранится в ОЗУ, без записи на диск и без разделения на части между узлами.

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

Конфиденциальность и изолированные сетевые конфигурации

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

• BadRAG достигает уровня успеха 98,2%, отравляя всего 0,04% корпуса данных с помощью тщательно созданных адверсарских документов.
• Vec2Text восстанавливает короткие оригинальные тексты из их векторных представлений, совпадая с ними с точностью 92% случаев.

Эмбеддинги не имеют криптографической защиты, поэтому любой, у кого есть права на чтение в хранилище векторов, может восстановить данные, которые там хранятся. Каждый запрос к облачному хранилищу векторов, каждая команда embed() в OpenAI и каждая операция upsert() в Pinecone — это момент, когда данные покидают вашу сеть.

Многие реальные решения уже полностью изолированы от внешней сети. В Университете Калифорнии в Сан-Диего система Onyx обслуживает 37 000 пользователей без необходимости в интернете, а компании Ramp, Thales, L3Harris и Astranis используют аналогичные решения. Слоган turbovec — «нет управляемых сервисов и данные не покидают ваш компьютер или VPC» — отлично соответствует этой категории. Если использовать вместе с локально размещенной моделью эмбеддингов, такой как BGE-M3 или BGE-large-en-v1.5, то получение данных не требует никаких внешних сетевых запросов.

Нет необходимости в обучающей базе

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

У TurboQuant вообще нет кодовой книги. Благодаря случайной ротации математические формулы работают независимо от формата входных данных. На практике это означает:

• Вставка данных в реальном времени происходит без проблем, без необходимости пакетного переобучения.
• Смена моделей эмбеддингов — от OpenAI до BGE и Voyage — не требует полной пересборки индекса с нуля.
• Индексы с несколькими арендаторами не нуждаются в индивидуальной калибровке.
• Проблема «холодного старта», при которой недостаточно векторов для создания качественной кодовой книги, исчезает.

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

Когда использовать что-то другое

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

• Поиск с высоким уровнем воспроизведения. HNSW с векторами полной точности остается золотым стандартом. turbovec снижает уровень воспроизведения на несколько пунктов в обмен на 16-кратное сжатие. Это приемлемо для большинства задач RAG, но проблематично, когда пропущенный результат имеет высокую ценность.
• Фильтрация метаданных и гибридный поиск. turbovec представляет собой лишь индекс без сопутствующей базы данных. Задачи вроде «найти векторы, близкие к X, ограниченные документами с меткой compliance, отредактированными после декабря 2025 года» требуют настоящей векторной базы данных, такой как Qdrant, Weaviate, Milvus или pgvector.
• Низномерные эмбеддинги (256 измерений или меньше). Согласно самому документу README, turbovec отстает от FAISS на 3–6 пунктов по показателю воспроизводимости для модели GloVe при d=200, поскольку при небольшом количестве измерений аппроксимация от типа Beta к Gaussian становится более слабой, и преимущества теории снижаются. Если в системе используются более старые или менее мощные модели эмбеддингов, FAISS является более надежным выбором.
• Масштаб миллиардов векторов. turbovec полностью сканирует каждый сжатый вектор. Это подходит до примерно 100 миллионов векторов. При большем количестве требуется дополнительная обработка с использованием метода IVF или графовой разбивки, которая отсутствует в turbovec.
• Предпочтение хостинговых сервисов. Командам, нуждающимся в управляемой базе векторов с API-ключом, turbovec окажется не подходящим инструментом, каким бы качественным ни было его программное решение.

Начало работы

Для поиска в памяти для 100 тыс. до 100 млн векторов с размером 384 и более, а также для команд, готовых использовать собственную инфраструктуру, вот практический способ. Установите с PyPI:

pip install turbovec

В проектах на Rust вместо этого используется crate:

cargo add turbovec

Для базового использования требуется несколько строк для создания и запроса к индексу:

from turbovec import TurboQuantIndex

# Build the index
index = TurboQuantIndex(dim=1536, bit_width=4)
index.add(document_embeddings)
# Search
scores, indices = index.search(query_embedding, k=10)
# Persist
index.write("kb.tq")
loaded = TurboQuantIndex.load("kb.tq")

Это вся площадь поверхности для простого случая.

Выбор ширины бита

Это наиболее важная настройка, и выбор между вариантами довольно прост.

• 2 бита: сжатие в 16 раз по сравнению с float32, более значительная разница в точности восстановления данных и более высокая чувствительность к размеру векторов.
• 4 бита: сжатие в 8 раз; точность восстановления практически совпадает с FAISS для векторов размером 1536 и 3072 избыточных измерений от OpenAI. Оба варианта достигают значения 1,0 при k от 4 до 8.

Разумным стандартным значением являются 4 бита. Переход на 2 бита следует делать только после измерения реального давления на память и оценки влияния на точность восстановления данных для ваших собственных запросов.

Выбор типа индекса

Существует два варианта. TurboQuantIndex обращается к векторам по их позиции, что делает процесс простым и немного быстрее, когда идентификаторы следуют порядку вставки. IdMapIndex позволяет использовать собственные идентификаторы типа uint64 и удалять записи за константное время, поэтому он предпочтителен, когда ключи берутся из базы данных или документы удаляются.

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

from turbovec import IdMapIndex
import numpy as np

index = IdMapIndex(dim=1536, bit_width=4)
index.add_with_ids(vectors, np.array([1001, 1002, 1003], dtype=np.uint64))
scores, ids = index.search(query, k=10)  # returns your IDs
index.remove(1002)  # O(1) by ID

Модели встраивания

Для поиска в изолированной среде модель встраивания должна работать локально, поскольку вызов API OpenAI сводит на нет преимущества в плане конфиденциальности. Хорошо протестированы два варианта:

• BGE-M3 с turbovec. Мощная мультиязычная модель, работающая локально, и отличный стандартный вариант для международных баз знаний.
• BGE-large-en-v1.5 с turbovec. Работает только с английским языком, меньше по размеру и быстрее, и является хорошим стандартным вариантом для английской документации.

Если конфиденциальность не является строгим требованием, модели text-embedding-3-small (1536 измерений) или text-embedding-3-large (3072) от OpenAI хорошо работают с turbovec. Просто помните, что утечки данных происходят при вызове модели в облаке, а не при работе с индексом.

Интеграция с фреймворками

turbovec обеспечивает первоклассную интеграцию с LangChain, LlamaIndex и Haystack:

pip install turbovec[langchain]
pip install turbovec[llama-index]
pip install turbovec[haystack]

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

Ограничения, которые следует учитывать

• Одна машина, работа в памяти. Распределенного режима нет, поэтому горизонтальное масштабирование означает шардинг на уровне приложения.
• Полный обзор. Каждый сжатый вектор сканируется при каждом запросе. SIMD позволяет сохранять высокую скорость до примерно 100 миллионов векторов, а при большем количестве требуется использование метода IVF или графового слоя.
• Зависимость от оборудования. Прирост производительности на 12–20 процентов был зафиксирован на чипах серии Apple M. У старых чипов ARM или x86 без технологии AVX-512 прирост меньше, хотя они все равно превосходят FAISS в большинстве конфигураций.
• Показатель воспроизведения при низком количестве измерений. При менее чем 256 измерениях FAISS показывает заметное преимущество. Метод наиболее эффективен при 768 и более измерениях, которые генерируют современные модели вкладок.

Более общая картина

turbovec занимает узкую нишу: поиск векторов в памяти, корпуса среднего размера, собственная инфраструктура и размерности, которые выдают современные модели эмбеддингов. Он не пытается заменить Qdrant или Pinecone. Это более низкоуровневый строительный блок там, где иначе использовался бы FAISS, с лучшим сжатием и без необходимости обучения.

История создания, пожалуй, является более интересной частью. Статья четырех авторов из Google Research была принята на конференцию ICLR 2026; авторы не опубликовали код, и два разработчика из сообщества независимо создали реализации — одну для сжатия KV-кэша, другую для поиска векторов. Реализация для поиска векторов превосходит существующие решения на собственных тестовых данных этих решений.

Путь от академического алгоритма к его внедрению в сообществе и созданию библиотеки производственного уровня, превосходящей стандартные инструменты, будет повторяться, поскольку темпы появления научных результатов растут быстрее, чем поставщики могут их превратить в готовые продукты. turbovec — один из примеров таких решений. Понимание того, как они работают и в каких ситуациях применимы, полезно для всех, кто сегодня разрабатывает системы поиска.