Как квантовать embeddings в int8 через SentenceTransformer.encode

1. Сгенерируйте эталонные float32 embeddings на обезличенном корпусе.
2. Для того же списка вызовите encode с precision="int8".
3. Сверьте число записей, размерность, dtype и объём payload.
4. На размеченных вопросах сравните recall и позиции правильных документов.
5. Если качество удовлетворяет требованиям, меняйте схему хранения на копии индекса.

Подготовьте изолированное окружение и установите зафиксированный пакет: pip install "sentence-transformers==6.1.0". Библиотека потребует подходящих зависимостей и свободной памяти под выбранные веса; установка пакета не скачивает заранее любую модель. Перед тестом напечатайте установленную версию и зафиксируйте имя checkpoint. Не отправляйте в примеры клиентские имена, закрытые документы или ключи доступа.

Готовый шаблон

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("sentence-transformers/all-MiniLM-L6-v2")
texts = ["Returns are allowed for 14 days.",
         "Delivery is available on weekdays."]
fp = model.encode(texts, precision="float32")
q8 = model.encode(texts, precision="int8")
print(fp.shape, fp.dtype, fp.nbytes)
print(q8.shape, q8.dtype, q8.nbytes)
assert fp.shape == q8.shape

Запускайте первый раз на очень маленьком обезличенном наборе. Для каждой строки и документа сохраняйте стабильный ID: иначе невозможно выяснить, почему нейросеть выбрала конкретную запись. Если вывод отличается от ожидаемой формы, сначала проверьте состав входа, затем конфигурацию модели и только после этого настройки ранжирования. Не маскируйте ошибки ручной подстановкой заранее «правильного» ответа.

Конкретный вход и ожидаемый результат

Вход — два англоязычных фрагмента. Ожидается одинаковое число строк и координат, но различный dtype и nbytes массивов. Размер индекса в production не равен этим двум nbytes: он дополнительно зависит от структуры поиска и метаданных. Численные координаты int8 не нужно сравнивать с float32 как будто они в одной шкале.

Проверяйте структуру отдельно от смысла. Массив верного размера не означает хорошего поиска, а высокий score не удостоверяет факт в документе. Сохраните реальные выводы программы и сопоставьте их с заранее размеченными эталонными ID. При переносе на другой корпус обновите проверочные данные; простая замена входного предложения в коде не доказывает обобщения метода.

Разбор метода и ограничений

Квантование выходного embedding экономит место при хранении, но меняет числовое представление. Некоторые интеграции vector database ожидают float32 и не принимают int8 напрямую: проверьте контракт конкретного backend прежде, чем писать байты в индекс. Особенно опасно использовать int8 на стороне документа и float32 на стороне вопроса без предусмотренного механизма сравнения или рескоринга. Не путайте этот параметр с квантованием весов нейросети: загрузка самой модели и её потребление памяти от precision="int8" в encode не превращаются автоматически в 8-битный inference. Документация допускает также бинарные варианты, но переход к ним ещё сильнее меняет схему поиска, поэтому отдельного теста не избежать.

Дополнительный сценарий проверки

Для честной оценки используйте достаточно большой и репрезентативный корпус при калибровке и проверке динамического диапазона, особенно если тексты разных тематик. Сопоставьте размер сериализованных данных, размер индекса, Recall@10 и время p95 на одной машине. Простое отношение fp.nbytes/q8.nbytes не учитывает сетевую сериализацию и служебные таблицы. Подготовьте план отката: исходный float32 корпус, версия checkpoint, правила получения int8 и возможность пересобрать индекс. Добавьте отрицательные вопросы и редкие артикула: сокращение представления может менять порядок близких соседей. Если качество стало хуже порога, не компенсируйте проблему выдуманным коэффициентом similarity. Проверяйте рекомендации автора модели и конкретную функцию квантования для случаев, где важен общий диапазон калибровки.

Критерии принятия