Как уменьшить размер embeddings через truncate_dim без потери контроля качества

1. Зафиксируйте базовый результат поиска на исходной размерности и контрольные IDs.
2. Получите два набора vectors от одной модели: полный и усечённый.
3. Проверьте реальные размеры и одинаковый порядок исходных документов.
4. Измерьте Recall@k и p95 для двух схем на копиях индекса.
5. Только после приемлемого качества переносите всю коллекцию в новую схему.

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

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

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("sentence-transformers/all-mpnet-base-v2")
docs = ["Returns are allowed for 14 days.",
        "Delivery is possible on weekdays."]
full = model.encode(docs)
with model.truncate_embeddings(truncate_dim=16):
    short = model.encode(docs)
print("original", full.shape, "short", short.shape)
assert full.shape[0] == short.shape[0]
assert short.shape[1] == 16

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

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

На входе два документа о возврате и доставке. Ожидаемая структура — две строки в обоих массивах и 16 координат у short. Само по себе это не подтверждает, что вопрос о возврате найдёт нужный документ при 16 измерениях: качество нужно проверить отдельными запросами.

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

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

Сокращение числа координат действительно уменьшает объём представления одного документа, но риск потерять полезную информацию зависит от обучения модели. У Matryoshka-модели префиксы вектора специально оптимизируют для разных длин, у обычного checkpoint такой гарантии нет. В API демонстрационный all-mpnet-base-v2 лишь показывает механизм truncate_embeddings; не объявляйте 16 измерений производственным решением. Нельзя хранить полные и обрезанные вектора в одном поле индекса, если схема требует фиксированную размерность. Даже когда backend принимает разные поля, вопросы надо кодировать до той же длины, что и документы. Объём экономии считайте вместе с индексом, метаданными и копиями, а не как обещание общего уменьшения базы в 48 раз.

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

Сформируйте таблицу baseline для нескольких значений размерности — исходной, средней и минимальной — но только для модели, которую реально планируете использовать. На ста вручную размеченных вопросах сравните hit@1, recall@10 и частоту потери редких артикулов. Если у короткого вектора неожиданно ухудшилось качество, возвратитесь к большей длине или выберите специализированную Matryoshka-модель с проверенной карточкой. Переключайте индекс атомарно после подготовки контрольного набора; нельзя изменить размерность работающего поля и предположить, что старые записи автоматически преобразуются. Храните model ID, truncate_dim и метрику на стороне пишущего и читающего приложения. Для русского корпуса использованный английский пример не служит доказательством качества, поэтому языковую оценку проводите отдельно.

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