Всем привет! Подскажите, пожалуйста, для поиска использую e5 с векторами

1024 float32
Качество поиска фича similarity между запросом и документом супер растит, но соответственно векторы довольно большие выходят. Подумал о квантизации e5 в int8, но пока не тестил. Подскажите, пожалуйста, может кто-нибудь сталкивался. Лучше взять квантованную сильную модельку либо маленькую неквантованную. Скажем multilingual e5 против rubert-tiny-2 как будут работать по качеству? Сильно ли оно просядет при квантизации e5 в int8 и сильнее ли, чем выдают более слабые модельки?

так-то ещё есть вариант старого-доброго PCA

А новые векторы, то есть как только запрос пришёл и мы его векторизовали, можно проскорить обученным pca быстро?

ну да

Дефолтным pca из sklearn?)

да хоть бы и так

Если у вас есть обучающие данные (тысячи пар запрос+релевантный документ), то как вариант, можно вместо PCA (который полностью unsupervised) обучить supervised сжималку нужной вам размерности (один линейный слой, прицепленный поверх замороженной E5), которая бы оптимизировала, скажем, MultipleNegativesRankingLoss косинусной близости всех пар запрос-документ в батче. У меня похожая штука хорошо работала в несколько другой задаче (но тоже на сравнение векторов).

А вообще, из текста вопроса не 100% понятно, какую именно проблему вы пытаетесь решить: размер эмбеддингов, из которых вы делаете поисковый индекс (и тогда есть смысл их жать разными способами) или размер модели, эти эмбеддинги извлекающей (ибо rubert-tiny-2 делалась как раз ради того, чтобы сам энкодер был маленький).

С временем инференса особо проблемы нет, а вот с размером векторов есть. Векторный поиск пока не делал, кандидаты вбрасываются эластиком а косинусная близость подаётся в бустинг как фича. И вот перенос векторов по сети из базы в сервис ранжирования выполняется очень долго из-за того, что кандидатов много, и векторы весят много. Большие издержки на перенос по сети. Поэтому есть задача, не утратив качество фичи сходства уменьшить размер векторов, между которыми будет считаться сходство.

С твоей точки зрения это будет работать лучше, чем PCA?

С моей точки зрения, это может работать лучше, чем PCA, если повезёт. Ну и в целом, когда есть достаточно много размеченных данных, обычно supervised методы работают лучше, чем unsupervised.

Спасибо!

Векторы большие это вы про постоянные симиляри 0.8 и разница в сотых между результатами?

Если основная проблема - с перегоном векторов по сети, то можно сделать product quantisation, когда каждый фрагмент вектора заменяется на id наиболее похожего фрагмента из словаря. Если, допустим, брать фрагменты длины 16 и кодировать их в uint16, (то есть словарь до размера 2^16), то 1024-мерный вектор можно описать 64 такими айдишками. Если словарь очень большой, то такое сжатие будет весьма точным. А размер словаря в вашем случае может быть большим, ибо его-то по сети гонять не надо.

Есть ли готовые реализации такого? Звучит интересно

Шапы и фича импортанс этих симилярити в топе относительно других и не такие уж они и константные. У меня в поиске мб несколько релевантных доков. Важно их наверх отранжировать, поэтому мб не так критично

Для е5 надо по формуле симилярити скоре считать, иначе все результаты будут около 0.8. https://t.me/natural_language_processing/71739

Интересно, как вы эту формулу вывели? Чисто интуитивно?

на форуме hf чел написал

Я знаю реализацию в пакете navec. Возможно, есть что-то ещё более оптимизированное.

Скорее всего еще на сериализацию и десериализацию время тратиться?

Походу в faiss это тоже реализовано https://www.pinecone.io/learn/series/faiss/product-quantization/