turbovec: Стиснення ембеддингів RAG у 16 разів за допомогою TurboQuant у Rust
TurboVec переносить TurboQuant від Google у Rust та зменшує розмір індексів RAG embedding у 16 разів без необхідності тренування. Де він кращий за FAISS та коли інший інструмент підходить краще.
Джерела: turbovec for RAG: A Practical Guide to Faster, Smaller Vector Search
Візьмемо реальний конвейер обробки даних, який вже використовується на практиці: десять мільйонів документів, кожен з яких містить ембеддинги моделі OpenAI text-embedding-3-small з розмірністю 1536 та зберігається у форматі float32. Ще до додавання жодного байта метаданих самі вектори займають 31 ГБ. При такому обсязі запитання „Де це буде працювати?“ вже не є простою розмовною фразою – це означає потребу у потужній хмарній машині з великим обсягом пам’яті, яка, ймовірно, знаходиться у когось іншого, а також усі проблеми, пов’язані з конфіденційністю та експлуатацією.
Якщо обробляти ці самі дані за допомогою turbovec із 2 бітами на розмірність, обсяг скоротиться приблизно до 4 ГБ, що цілком поміщається у RAM ноутбука з великим запасом. У решті цієї статті пояснюється, чому це працює, коли цей інструмент є оптимальним, а коли краще використовувати інший.
Що таке turbovec
turbovec — це векторний індекс на мові Rust із інтерфейсами для Python, ліцензований під MIT; на момент написання цього тексту він мав приблизно 950 зірок на GitHub. Він реалізує TurboQuant — алгоритм векторної квантації, розроблений дослідниками з Google Research та NYU, який був прийнятий на конференцію ICLR 2026.
Варто знати одну деталь: Google так і не оприлюднив код власного алгоритму, тому до справи долучилася спільнота. Проєкт RyanCodrai/turbovec спрямований на векторний пошук, що є сценарієм пошуку інформації, тоді як окремий проєкт hackimov/turboquant-kv застосовує ту саму ідею для стиснення кешу KV у мовних моделях. Обидва це незалежні проєкти з відкритим кодом.
Іншими словами, використання turbovec означає використання реалізації алгоритму Google Research, створеної спільнотою, і на тестових даних, які сама команда FAISS використовує, він перевершує FAISS від Meta, який довгий час був стандартом для пошуку векторів у пам’яті.
Як працює алгоритм
Як тільки ви його побачите, метод виявиться дивовижно простим. Він виконується у чотирьох кроках.
1. Розділення довжини та напрямку
Кожен ембеддинг має модуль (його норму L2) та напрямок. Виймаємо модуль та зберігаємо його як одне число типу float для кожного вектора, а те, що залишається, — це напрямок довжиною одиниця на високорозмірній сфері. Це може здатися дрібницею, але все, що йде далі, залежить від цього, оскільки вектори, розташовані на поверхні сфери, можна обробляти за допомогою геометрії.
2. Випадкове обертання
Далі кожен вектор множиться на ту саму випадкову ортогональну матрицю, яка генерується один раз шляхом розкладання матриці Гаусса у формат QR. Саме цей крок на перший погляд здається чимось на кшталт магічного трюку.
Інтуїція полягає у наступному: у високих вимірах випадкове обертання робить розподіл кожної координати прогнозованим. Після обертання кожна координата кожного вектора підкоряється відомому, щільно концентрованому розподілу Бета, який при зростанні кількості вимірів наближається до розподілу Гаусса. Розподіл залишається однаковим незалежно від вхідних даних. Юридичні документи, відгуки про продукти та медична література статистично виглядають схожими, тому ця схема не залежить від даних. Математики називають це концентрацією міри на сфері, і це пояснює, чому не потрібен жоден етап навчання: обертання виконує ту саму роботу, яку б інакше виконав навчений кодовий справочник.
3. Виберіть найкращі групи
Знання закону розподілу кожної координати дозволяє заздалегідь визначити найкращий спосіб групування значень. Двобітна квантація створює чотири групи на координату, а чотирибітна — шістнадцять. Цей метод називається скаларною квантацією Lloyd-Max та відповідає на просте запитання: при відомому законі розподілу, де слід розмістити межі групування, щоб середній похибка округлення була якомога нижчою? Коли закон розподілу відомий, відповідь має закриту формулу. А оскільки розподіл після обертання є ідентичним для всіх векторів, групи визначаються математикою, а не вашими даними.
4. Збирання бітів
Тепер кожна координата є невеликим цілим числом: від 0 до 3 при двобітній квантації або від 0 до 15 при чотирибітній. При щільному збиранні 1536-вимірний вектор, який займав 6 144 байти у форматі float32, потребує 384 байти при двобітній квантації або 768 байтів при чотирибітній. Це 16-кратне та 8-кратне стиснення відповідно.
Пошук без розпакування
Запити ніколи не розпаковують збережені дані. Запит спочатку переміщується у ту саму область, а потім безпосередньо порівнюється з квантованими кодами за допомогою заздалегідь створених таблиць пошуку. Внутрішній цикл використовує інструкції SIMD: NEON для ARM, AVX-512BW для сучасних процесорів x86 та AVX2 як альтернативу.
Саме тут бібліотека, на відміну від алгоритму, демонструє свою ефективність. Її власні SIMD-ядра працюють на 12–20 відсотків швидше за FastScan від FAISS на процесорах ARM та дорівнюють або перевершують його швидкість на процесорах x86.
За цим методом також стоїть теоретичний результат. У статті TurboQuant доведено, що рівень спотворення залишається в межах приблизно 2,7 разів від теоретичного нижнього порогу — обмеження швидкості спотворення за Шенноном. Простіше кажучи: теорія інформації визначає, наскільки можна стиснути дані, не втративши інформації, а TurboQuant досягає рівня, близького до цього обмеження в 2,7 рази, без будь-якої підготовки. Ніхто не може досягти значно кращих результатів за заданим бюджетом бітів, і це підтверджується формальним доведенням у статті.
Три ситуації, коли це корисно
Пам’ять, яка підходить
Повернімося до початкових цифр: 31 ГБ у форматі float32 проти 4 ГБ за допомогою turbovec з використанням 2 бітів. Наявність такого невеликого індексу змінює можливості.
- Його можна розмістити поруч із програмою на одному сервері, без окремої інстанції бази даних векторів.
- Розробники можуть використовувати його на ноутбуках для локальних тестів.
- Дешевші рівні пам’яті у хмарних інстанціях стають доступними, що значно знижує витрати.
- Весь індекс залишається в RAM, без запису на диск та без розділення на частини між вузлами.
Для колекцій у діапазоні від 100 тис. до 100 млн векторів, який охоплює більшість баз знань, сайтів документації, архівів підтримки та каталогів продуктів, це і є різниця між необхідністю проектування з урахуванням векторного індексу та розглядом його як звичайного об’єкта Python.
Приватність та схеми із ізольованим середовищем
Процеси отримання інформації створюють серйозну проблему приватності. Два типи атак це ілюструють:
- BadRAG досягає рівня успішності 98,2%, отруюючи лише 0,04% корпусу даних ретельно підготовленими адверсарськими документами.
- Vec2Text відновлює короткі оригінальні тексти з їхніх ембеддингів, знаходячи їх з точністю у 92% випадків.
Ембеддинги не мають криптографічного захисту, тому будь-хто, хто має право на читання у сховищі векторів, може відновити інформацію, яка була вбудована. Кожен виклик хмарного сховища векторів, кожен запит embed() до OpenAI та кожен запит upsert() до Pinecone — це момент, коли дані виходять за межі вашої системи.
Багато реальних рішень вже повністю ізольовані від зовнішнього інтернету. У UC San Diego система Onyx обробляє дані 37 000 користувачів без необхідності підключення до Інтернету, а компанії Ramp, Thales, L3Harris та Astranis використовують схожі рішення. Слоган turbovec — «жодних керованих послуг та жодних даних, що виходять за межі вашого пристрою чи VPC» — чудово підходить до цієї групи. Поєднавши його з локально розміщеним моделлю ембеддингів, такою як BGE-M3 чи BGE-large-en-v1.5, отримання даних не вимагає жодних зовнішніх мережевих викликів.
Немає кодової книги для навчання
Ця перевага є структурною та легко недооцінюється. Класична квантизація продуктів, тобто PQ у 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. Тільки для англійської мови, менша та швидша, і є хорошим стандартним варіантом для англійської документації.
Якщо конфіденційність не є обов’язковою вимогою, моделі OpenAI text-embedding-3-small (1536 вимірів) або text-embedding-3-large (3072) добре працюють з 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 — це один із прикладів такого підходу. Розуміння того, як він працює та де знаходиться у контексті сучасних систем пошуку, є корисним для кожного, хто розробляє такі системи сьогодні.
Пов’язана література
- GraphRAG проти Vector RAG: Чому пошук за векторами зазнає невдач у масштабах — Vector RAG має проблеми з ізоляцією фрагментів, міждокументовим міркуванням та масштабуванням. Дізнайтеся, як GraphRAG вирішує ці проблеми за допомогою створення спільнот та резюме, та коли варто обирати кожен з підходів.