Декодерные модели эмбеддингов, такие как Qwen3-Embedding, NV-Embed и E5-Mistral, вытесняют энкодерные архитектуры благодаря способности работать с длинным контекстом и понимать инструкции. Однако за это приходится платить: модель 7-8B в fp16 занимает память, её forward-pass увеличивает задержку, а главное — векторы высокой размерности (до 4096) взрывают стоимость хранения. Для корпуса в 100 млн чанков с размерностью 1024 (fp32) только сырые векторы занимают 409 ГБ, а с учётом HNSW-графа — ещё больше.

Статья на Habr предлагает системный подход к сжатию эмбеддингов, разделяя три независимые оси: дистилляцию (сжатие самой модели), квантизацию (снижение точности чисел) и MRL (усечение размерности). Автор фокусируется на двух последних, так как они не требуют GPU и работают с уже полученной матрицей векторов. Для оценки деградации предлагается метрика recall@10 — доля пересечения top-10 результатов по сжатым и исходным fp32-векторам.

Методrecall@10Байт/векторСжатиеГБ на 1М векторов
fp32 (baseline)1.000040961x4.096
fp160.998420482x2.048
int80.996410244x1.024
int40.94785128x0.512
binary (без rescore)0.669612832x0.128

Результаты экспериментов на Qwen3-Embedding-0.6B (1024 dim, корпус 5500 документов, 500 запросов) показывают, что квантизация int8 практически не снижает recall (около 0.997), int4 даёт 0.96, а binary — резкий обрыв до ~0.4, что автор называет «точкой невозврата». MRL-усечение от 1024 до 128 измерений даёт плавное падение recall от 1.0 до 0.8, позволяя подобрать компромисс под бизнес-задачи. Продуктовая квантизация (PQ) также рассмотрена, но живёт на стороне хранилища.

Сжатие векторов может быть выполнено тремя независимыми способами: дистилляция, квантизация и MRL (Matryoshka Representation Learning).

Для практического применения автор подготовил скрипт compress_experiment.py, который на CPU проводит все замеры, и Colab-ноутбук с полным пайплайном. Это позволяет разработчикам прогнать те же тесты на своих данных, не тратя GPU-часы на эксперименты.