Как правильно выбрать эмбеддинг для проекта

Эмбеддинги (иначе говоря, векторные представления) — это способ представления абстрактных данных в виде набора чисел (в виде векторов, как вы могли уже понять), близкие значения которых связаны семантически и математически ^[1] и с которыми может работать модель искусственного интеллекта ^[2].

Разберемся какие модели лучше других подходят для кодирования слов. Параллельно с этим разберём принципы, на которые нужно опираться при выборе эмбеддинг-модели, пощупаем русские BERT-модели и внесём ясность про системные требования, контекстное окно и размер батча.

---

1. Типы эмбеддингов и области применения

Перво-наперво рассмотрим базовую информацию по эмбеддингам: ниже представлены наиболее общие категории классификации эмбеддингов.

Типы эмбеддингов по уровню агрегации:

Самый простой нейросетевой тип – модели вроде word2vec. Их часто ставят в один ряд с bag-of-words и N-gramы. Это неудивительно, ведь две самые популярные архитектуры word2vec (CBOW и Skip-gram) по сути предсказывают слова на основе контекста или наоборот — контекст по слову. 

Применений у эмбеддингов столько, сколько задач вы сможете придумать. Но если говорить о том, что встречается чаще всего, это семантический поиск (когда поиск происходит по смыслу, а не по ключевым словам), кластеризация и группировка текстов, скажем, для анализа постов в соцсетях или экспертных комментариев.

А также отбор признаков и классификация, reranking результатов поиска и, конечно, обнаружение дубликатов и плагиата.

В этой статье мы сделаем упор на BERT-подобные модели. Это семейство построено на архитектуре трансформеров, которые можно грубо разделить на три категории. 

• encoder‑only (текст → вектор);

• decoder‑only (текст → текст, авторегрессивная генерация);

• encoder‑decoder (оба режима поддерживаются).

Классические эмбеддеры чаще всего относятся к encoder‑only (BERT, SBERT), однако современные LLM-эмбеддеры, такие как Qwen3‑Embedding ^[3], построены на архитектуре decoder‑only (большие языковые модели) и входят в число лидеров MMTEB/MTEB: Qwen3‑Embedding‑8B на момент выхода набирал 70.58, сейчас выше KaLM‑Gemma3‑12B (72.32). Так что, при выборе эмбеддера, прежде всего смотрите на результаты на бенчмарках и предметную область задачи.

2. Языковая поддержка моделей

Язык — первый критерий выбора эмбеддинг-модели. Наибольшее распространение имеют:

Мультиязычные модели – обучаются на 50+ языках. Для примера:

distiluse-base-multilingual-cased-v2 ^[4](50+ языков), LaBSE ^[5] (109 языков), Qwen3-Embedding ^[3] (>100 языков), BGE-M3 ^[6] (>100 языков), серия multilingual-e5 ^[7] (~94 языка, а instruct-версия поддерживает 100 языков).

Специализированные русскоязычные модели – дообучены на русских корпусах (Wikipedia, новости). Самые популярные — от Sber и DeepPavlov:

• ai‑forever/sbert_large_nlu_ru ^[8] — большая модель (427M параметров) для NLU и sentence‑embeddings. Лицензия MIT.

• DeepPavlov/rubert‑base‑cased ^[9] — 180M параметров, 12 слоёв, 768 hidden. Лицензия Apache‑2.0.

• ai‑forever/ru‑en‑RoSBERTa ^[10] — ruRoBERTa‑large, дообученная на 4M англо‑русских пар, поддерживает английские префиксы и русский текст (MIT).

• DeepPavlov/rubert‑base‑cased‑sentence ^[11] — тот же RuBERT, но дообученный на SNLI/XNLI для получения качественных sentence‑embeddings «из коробки».

Из перечисленных моделей для задач семантического поиска по русскоязычным текстам чаще всего сравнивают sbert_large_nlu_ru и rubert-base-cased . Последний, как базовый бенчмарк, хотя для получения качественных sentence-векторов лучше сразу использовать его специализированную версию rubert-base-cased-sentence.

Далее мы рассмотрим их, а также более современные мультиязычные альтернативы.

Большинство популярных моделей из семейства sentence‑transformers (например, all‑MiniLM‑L6‑v2 ^[12], all‑mpnet‑base‑v2 ^[13]) заточены преимущественно под английский язык.

Для русского или мультиязычных сценариев они работают хуже, поэтому лучше сразу смотреть в сторону специализированных русских (ai‑forever/sbert_large_nlu_ru, DeepPavlov/rubert‑base‑cased-sentence, ru‑en‑RoSBERTa) или мультиязычных (LaBSE ^[5], BGE‑M3 ^[6], multilingual‑e5 ^[7]).

3. Размерность эмбеддингов (dimension)

Размерность вектора, который на выходе дает эмбеддер, определяет как качество результата, так и требования к деплою. Увеличивается объем хранимой информации и размер самой модели в том числе. С другой стороны, чем выше размерность, тем больше нюансов может уловить модель. 

Типичные размерности:

Примерные паттерны влияния на память ^[16] и скорость:

• Вектор 384 dim (float32) для 1 млн документов занимает ≈ 1.5 ГБ.

• Вектор 1024 dim (float32) для 1 млн документов занимает ≈ 4.1 ГБ.

• При поиске (FAISS) скорость падает с ростом размерности, но современные библиотеки (HNSW, IVF) хорошо масштабируются до 1024–2048 dim.

Кстати говоря, возвращаясь к теме языковой поддержки, важно заметить, что мультиязычные модели (например, LaBSE ^[5], BGE‑M3 ^[6], Qwen3) обычно имеют размерность 768–4096 — это выше, чем у многих моделей, заточенных чисто под английский язык (384–768). Бо́льшая размерность даёт лучшую кросс‑языковую семантику, но требует больше памяти и более мощного GPU (особенно при работе с длинными контекстами).

По своему опыту ^[17] скажу, что для русского языка размерности 384–768 часто достаточно для большинства бизнес-задач. Если вы работаете с очень тонкими смысловыми различиями (юридические или медицинские тексты) — выбирайте 1024+.

4. Скорость и стоимость работы

Как и при работе с LLM, первый вопрос, который приходит в голову — через какое API делать инференс? Сколько денег потрачу на заветные токены? Рассмотрим основных зарубежных API-провайдеров эмбеддинг-моделей.

4.1 Облачные API

Обратите внимание ^[18], что Hugging Face ^[19]— это хаб для моделей с открытыми весами (включая многие из рассматриваемых), но проприетарные модели на HF не выложены и доступны только через собственные API. В то же время HF Inference Endpoint ^[20] позволяет развернуть любую открытую модель как сервис, что удобно для локального контроля.

Шпаргалка с примерным расчётом.

1M токенов ≈ 750 000 слов (для английского) ≈ 3–4 МБ текста. Векторизация 300-страничной книги через OpenAI 3‑small стоит менее $0.01 (около 120 000 токенов).

4.2 Локальный инференс

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

Для экспериментов и точечных обработок массивов данных можно использовать Google Colab, а также их расширение в VS Code.

• Лёгкие модели (all‑MiniLM, 22M параметров) работают на любом CPU со скоростью сотни токенов в секунду.

• Средние модели (rubert‑base‑cased, 180M) требуют 4–8 ядер CPU или бюджетного GPU (GTX 1060).

• Тяжёлые модели (sbert_large_nlu_ru, 427M) предпочтительно запускать на GPU с 8+ ГБ VRAM.

Для обработки до 10 000 запросов в день локальная машина с одной видеокартой (RTX 3060 12GB) экономически оправдана. Для высоких нагрузок (миллионы документов в день) нужны мощные GPU или облачные решения (см. предыдущий раздел).

5. Требования к железу и локальный деплой

Если же вам не подходят по каким-либо причинам облачные решения, то как и сказано чуть ранее, есть доступный локальный деплой. Рассмотрим же, что необходимо для запуска. 

5.1 Как формируются требования

Системные требования зависят от трёх основных факторов:

1. Количество параметров модели – определяет объём памяти для весов.

2. Длина контекста – память активаций растёт квадратично O(n²) в классическом self‑attention.

3. Batch size – большие батчи требуют больше активаций, но увеличивают пропускную способность.

Формула объёма памяти для весов (в гигабайтах):

Пример

Модель с 180M параметров в FP16 → 180M × 2 / (1024³) ≈ 0.34 ГБ (только веса). Плюс активации (зависят от длины) и оверхед PyTorch (~200–500 МБ).

5.2 Таблица системных требований для популярных моделей

Ниже представлены требования для ранее рассмотренных решений. В целом, практически все модели можно разделить на категории, представленные в таблице, так что для понимания она более чем достаточна (цифры — ориентировочные).

Примечание: BGE‑M3 имеет около 568 миллионов параметров (базируется на XLM‑RoBERTa‑large), а не 1.2B, как иногда ошибочно указывают. Это всё равно требовательная модель из‑за длинного контекста (8192).

5.3 Код локального деплоя для русских моделей

Для получения качественных sentence‑embeddings «из коробки» лучше использовать модели, специально обученные для этой цели. Например, DeepPavlov/rubert-base-cased-sentence доступна через библиотеку sentence-transformers:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("DeepPavlov/rubert-base-cased-sentence")

sentences = ["Привет, как дела?", "Что ты думаешь о новых эмбеддингах?"]
embeddings = model.encode(sentences)
print(embeddings.shape)  # (2, 768)

Для более тяжёлой модели sbert_large_nlu_ru можно использовать тот же интерфейс (она также совместима с sentence-transformers). Если же вы используете обычный AutoModel для rubert-base-cased, то для получения вектора предложения необходимо применять пулинг (например, mean pooling) — но помните, что эта модель не оптимизирована под STS, и качество может быть ниже, чем у специализированной версии.

Советы по ускорению:

• Используйте FP16: model.half() и подавайте входные тензоры в torch.float16.

• Включите torch.backends.cudnn.benchmark = True.

• Для пакетной обработки берите batch_size = 32–128, взависимости от GPU. Много GPU – больше batch_size/

6. Контекстное окно (max context length)

Этот параметр, по большому счёту, недооценён. Как и в GPT-подобных моделях, длина контекстного окна является одним из ключевых качеств BERT-моделей, наравне с размерностью выходного вектора, ведь оба параметра влияют на семантику и, как следствие, на качество полученного эмбеддинга.

Классические BERT-модели имеют жёсткое ограничение в 512 токенов (примерно 300–400 слов для русского языка). Если ваш документ длиннее, эмбеддинг либо обрежется, либо потребует чанкинга (разбиения на куски и усреднения).

Новые модели с расширенным окном:

Что делать, если модель с коротким окном, а текст длинный?
Разбивайте текст на перекрывающиеся чанки (например, по 200–300 слов, перекрытие 10–20%), эмбеддите каждый чанк, затем усредняйте или берите максимальное значение по элементам (max‑pooling).

7. Специализация моделей под задачи

Не все эмбеддинговые модели одинаково хороши для любых задач. Ориентируйтесь на бенчмарки. К основным я бы отнёс MTEB и ruMTEB.

7.1 MTEB и ruMTEB

MTEB (Massive Text Embedding Benchmark) — стандартный набор задач для оценки эмбеддеров: semantic textual similarity (STS), retrieval, clustering, classification, reranking. Актуальные таблицы результатов и сравнение моделей смотрите на официальном лидерборде:
MTEB Leaderboard на Hugging Face ^[22] | GitHub репозиторий ^[23]

• Qwen3‑Embedding‑8B ^[15] занимал первое место в многязычном MTEB на момент выхода (70.58 балла), однако позже появились модели с более высокими показателями (например, KaLM‑Gemma3‑12B с 72.32). Сейчас Qwen3 — один из лидеров.

• BGE‑M3 ^[6] (59.56 на MTEB) и Jina‑v4 (66.49 на MMTEB) также входят в число сильных моделей, но уступают лидерам.

Для русского языка существует ruMTEB — расширение с 7 категориями задач (23 датасета). В нём представлена новая модель ru‑en‑RoSBERTa ^[10], которая показывает сильный baseline (61.77), однако уступает лучшим зарубежным аналогам, таким как E5‑mistral ^[24] (67.18) и mE5‑instruct ^[25] (66.03 по ruMTEB).

Авторы отмечают, что ru‑en‑RoSBERTa «достигает результатов наравне с SOTA моделями» в русскоязычных задачах.

7.2 Таблица: Модель – лучшие задачи

Для задач семантического поиска по русскоязычным текстам хорошим выбором будет sbert_large_nlu_ru или rubert-base-cased-sentence. Для мультиязычных сценариев отдавайте предпочтение моделям типа BGE‑M3, multilingual‑e5 или Qwen3.

8. Квантование эмбеддингов: снижение размера без большого урона качеству

Квантование — это уменьшение битности весов или самих эмбеддингов. Веса любой модели хранят в себе числа с плавающей точкой, причём высокой точности (FP16) с 16 битами на число.

Квантование, за счёт перехода на другие форматы (int8, int4, fp8), позволяет: Уменьшить занимаемую память в 2–8 раз. Одновременно с этим ускорить инференс, что позволит запустить более сильную модель на ограниченном железе.

При квантовании теряется точность модели ^[26], но как показывает практика, зачастую несущественным образом, да и вышеперечисленные плюсы нивелируют неточность.

Инструменты для квантования моделей:

• bitsandbytes ^[27] (4‑bit, 8‑bit для трансформеров)

• ONNX Runtime ^[28] (CPU‑оптимизация)

• TensorRT ^[29] (NVIDIA)

• GGUF ^[30] – для LLM, но некоторые эмбеддеры на базе BERT также поддерживаются

Квантование также можно осуществить уже для самих эмбеддингов, таким образом, после получения float32-векторов их можно сжать до int8 или даже бинарных векторов.

Согласно блогу Hugging Face ^[26], при 8‑битном квантовании качество поиска (метрика NDCG@10) сохраняется на уровне ≈99.3% от исходного, а размер уменьшается в 4 раза. Бинарные эмбеддинги дают 32‑кратное сжатие, а после rescoring сохраняют около 96% качества. Потеря может составлять от 3.5% до 25% в зависимости от модели и задачи.

Пример квантования эмбеддингов через numpy:

import numpy as np

embeddings_fp32 = np.random.randn(1000, 768).astype(np.float32)

#8битное квантование с сохранением диапазона
min_val, max_val = embeddings_fp32.min(), embeddings_fp32.max()
scale = (max_val - min_val) / 255
embeddings_int8 = ((embeddings_fp32 - min_val) / scale).astype(np.uint8)

#Обратно
embeddings_recovered = embeddings_int8.astype(np.float32) * scale + min_val

Важно: Всегда проверяйте деградацию качества на вашей задаче. Для высокоточных систем (юридика, медицина) лучше оставить FP16 или хотя бы INT8.

9. Лицензирование и открытость весов

При выборе модели для коммерческого проекта обязательно проверьте лицензию.

Внимание: В отличие от распространённого мнения, Jina Embeddings v4 распространяется не под CC‑BY‑NC‑4.0, а под Qwen Research License — это также некоммерческая лицензия. Всегда проверяйте актуальный LICENSE в карточке модели на Hugging Face.

ВАЖНО: Перед загрузкой модели с Hugging Face всегда смотрите файл LICENSE или описание в карточке модели. Для коммерческого проекта предпочтительны MIT / Apache‑2.0.

10. Сравнение моделей для семантического поиска и мультиязычных задач

Когда вы выбираете модель для семантического поиска, бенчмарки лишь вершина айсберга. Не меньшее значение имеют поддержка языка, лимит контекста, возможность развернуть модель локально и лицензия.

Обратите внимание: баллы MMTEB и ruMTEB снимаются на разных наборах задач, так что напрямую сравнивать строки по одной цифре нельзя — смотрите на то, какой бенчмарк релевантен именно для вашей задачи.

Для семантического поиска по документам выбор упирается в нужный язык, длину текстов и доступное железо.

Нужна максимальная точность на MMTEB и есть бюджет на GPU — смотрите KaLM‑Gemma3‑12B или Qwen3‑Embedding‑8B; для русского сегмента  ruMTEB — E5‑mistral или mE5‑instruct.

Баланс мультиязычности и требований к железу — BGE‑M3 или mE5‑instruct.

Преимущественно русскоязычный корпус при ограниченных ресурсах — ru‑en‑RoSBERTa (retrieval) или sbert_large_nlu_ru (STS/similarity).

Не стоит собирать sentence-вектор самостоятельно из rubert-base-cased через mean pooling. Качество будет на порядок ниже, чем у моделей, специально обученных под sentence-embeddings.

Таблица сравнения моделей для семантического поиска

Примечания

*KaLM: лицензия tencent-kalm-embedding-community (на базе Gemma).

**E5‑mistral: база Mistral поддерживает длинный контекст, но авторы рекомендуют не более 4096 токенов на вход.

10.1 Где и зачем применять семантический поиск по документам

Частое применение эмбеддинг-моделей это семантический поиск по документам: когда система находит нужный документ не по ключевым словам, а по смыслу и контексту запроса. Понимает синонимы, перефразировки и семантически близкие формулировки.

Ниже приведена таблица реальных кейсов внедрения автоматизации работы с документами в российских и зарубежных компаниях. В колонке «Кейс» отмечены проекты IDP (интеллектуальная обработка документов) и чистого семантического поиска.

Важный нюанс: часть кейсов ниже — это на самом деле интеллектуальная обработка документов (IDP/OCR): распознавание сканов, извлечение полей, сверка реквизитов. Это смежная, но всё же другая задача, чем vector search на эмбеддингах. Примеры именно чистого semantic search / RAG — ТяжМаш, Gambit Lab, «Жижи» (см. таблицу ниже).

IDP распознаёт сканы и извлекает поля, а семантический поиск ищет по смыслу уже оцифрованного текста. Рекомендуемые модели в таблице — ориентир для вашего проекта. Если вы внедряете готовое IDP-решение, выбор эмбеддинга на вашей стороне не требуется.

Если посмотреть на отрасли в сборе, вырисовывается довольно чёткое разделение. Банки и госсектор берут IDP. У промышленности, нефтегаза и крупных B2B-продуктов другая картина. Документы там уже в цифровом виде, и нужно прежде всего искать по смыслу в многотысячных архивах.

Для большинства русскоязычных проектов спокойно хватает sbert_large_nlu_ru или rubert-base-cased-sentence. Если в корпусе несколько языков или документы длиннее 2000 токенов — смотрите в сторону BGE-M3или multilingual-e5-instruct.

Что ещё стоит знать по отраслям — то, что в таблицу не попало:

• Банки и финансы — это прежде всего платёжки, счета и договоры плюс постоянные комплаенс-проверки. Если в документах попадается латиница и иностранные термины, используйте multilingual-e5-instruct.

• Страхование — головная боль ^[31] не в том, чтобы отсканировать полисы, а в том, чтобы потом находить среди них нужные пункты и сравнивать формулировки. Если страховщик работает с международными перестраховщиками — без BGE-M3 (там >100 языков) будет сложно.

• Ритейл — товарные накладные, счета-фактуры, акты, ветеринарные сертификаты, ЕГАИС. Если сеть распространена по СНГ, берите multilingual-e5-instruct. Если чисто российский ритейл —  rubert-base-cased-sentence справится.

• Госструктуры — межведомственный документооборот и огромные архивы, почти всегда внутри закрытого контура. Зато и эффект заметный. По данным ДИТ Москвы ^[32], платёжки стали обрабатывать почти в два раза быстрее живого оператора.

• Промышленность — регламенты, ISO 9001/HACCP, журналы учёта. Если техописания регулярно уходят за 50 страниц, BGE-M3 с его 8192 токенами контекста может выручить.

• Нефтегаз — контракты с иностранными поставщиками? Опять берём мультиязычную модель multilingual-e5-instruct. Для чисто русского языка — ru-en-RoSBERTa.

• B2B-продукты — кейсы вроде «Жижи» (10 млн документов, 15 тысяч пользователей) упираются не в точность модели, а в инфраструктуру: нужны GPU-кластер и правильный расчёт размерности (для sbert_large_nlu_ru это 1024 dim).

• Техдокументация и docs-as-code — почти всегда на русском, и тут главное не перегрузить систему. rubert-base-cased-sentence спокойно работает даже на CPU, и для внутренних порталов с документацией это часто идеальный вариант.

10.2 Как выбрать модель для вашего проекта

В разделе 10.1 мы разобрали отраслевые кейсы из российской практики. Здесь отобраны типовые сценарии семантического поиска в корпоративных базах, техподдержке, юриспруденции, медицине и других сферах.

Таблица ниже содержит сценарий, типовую задачу, пример внедрения с результатом и рекомендуемую модель. В колонке «Кейс и результат» сначала указано кто внедрил и что сделал, затем измеримый эффект, если он есть в открытых данных.

Колонка «Рекомендуемая модель» выступает в качестве ориентира, а не единственно верной модели.

Выбор модели здесь упирается в язык, длину документов и латентность. Русский моноязычный контент с короткими статьями — rubert-base-cased-sentence на CPU часто хватает.

Несколько языков, юриспруденция, длинные EMR — смотрите на BGE-M3или multilingual-e5-instruct.

Для документов за 2000+ токенов вроде патентов или техописаний — BGE-M3(8192) или Qwen3-Embedding (32768).

---

11. Пошаговый план для выбора модели

Финальному внедрению должна предшествовать серия коротких экспериментов на репрезентативной выборке, так называемый Proof of Concept(POC). Размер выборки — от 500 до 5000 примеров. Меньше — нельзя оценить дисперсию метрики, больше — POC превращается в отдельный проект.

Ниже описаны шесть шагов, когда выбор касается эмбеддинговой модели под конкретный проект.

Шаг 1. Сбор требований

На этом шаге нужно зафиксировать числовые целевые показатели и ограничения инфраструктуры. Без них сравнение моделей превращается в субъективное понравилось/не понравилось.

Целевая метрика выбирается исходя из задачи. Основные варианты:

• Recall@k — доля релевантных документов среди первых k результатов выдачи. Для RAG обычно смотрят Recall@10 и Recall@100. Метрика чувствительна к порогу релевантности, поэтому разметка для её подсчёта делается руками.

• NDCG@k (Normalized Discounted Cumulative Gain) — та же идея, что и у Recall, но с весами по позиции. Документ на первой позиции важнее, чем на пятой. Удобно, когда релевантность многоуровневая («полностью подходит / частично / не подходит»).

• MRR (Mean Reciprocal Rank) — средняя обратная позиция первого релевантного ответа. Хороша, когда пользователю достаточно одного правильного попадания.

• Spearman ρ — ранговая корреляция Спирмена, основная метрика для задач STS(семантическое текстовое сходство). Измеряет, насколько хорошо модель сохраняет порядок пар по смысловой близости относительно ручной разметки.

• F1 — гармоническое среднее precision и recall, используется, когда эмбеддинги идут на вход классификатора или кластеризатора.

Инфраструктурные ограничения фиксируются в виде двух чисел: максимальной латентности на p95 (то есть 95 % запросов должны укладываться в это значение) и бюджета по памяти — VRAM на GPU или RAM на CPU. Процентиль p95, а не среднее, используют потому, что пользователи запоминают худшие времена ответа, а не типичные.

Язык и объём определяют выбор семейства. Русскоязычный контент на 100 тысяч документов это один класс моделей, мультиязычный класс на 10 миллионов документов — уже совсем другой.

Дополнительно стоит зафиксировать требования к длине контекста, подсчитать среднюю длину документа в токенах и наличию GPU в продакшене. Это сразу отсечет часть кандидатов.

Шаг 2. Отбор 3–5 кандидатов

На этом шаге мы берём модели, которые подходят под зафиксированные на Шаге 1 ограничения по языку, длине контекста и размеру.

Конкретные кандидаты под типовые сценарии:

Для мультиязычного поиска по документам (русский + английские термины, документы на нескольких языках): BGE-M3 с поддержкой >100 языков и контекстом до 8192 токенов, multilingual-e5-instruct (100 языков, контекст 512).

Qwen3-Embedding-8B является более точным, но требовательным вариантом, и ru-en-RoSBERTa русскоязычный базовый вариант с поддержкой английского.

Для чисто русскоязычного поиска (документы, FAQ, внутренняя документация): sbert_large_nlu_ru, rubert-base-cased-sentence, ru-en-RoSBERTa.

Если требования к памяти жёсткие, начинайте с rubert-base (180M параметров, уверенно крутится на CPU).

Примечание. Не берите в POC модели разного класса размера без поправки на это. Сравнение 8B-модели с 180М-моделью без учёта инфраструктуры некорректно.

Шаг 3. Прогон качества

Качество меряется на размеченных датасетах. Для русского языка основные источники — наборы из бенчмарка ruMTEB ^[33].

Прогон делается одной библиотекой — удобнее всего sentence-transformers ^[34]. Она даёт единый интерфейс кодирования, нормализации и расчёта метрик, поэтому результаты разных моделей будут сопоставимы. Если в проекте есть собственная разметка, то обязательно добавляйте её в evaluation. Бенчмарки не всегда отражают специфику вашего домена.

Шаг 4. Замер производительности

Качество — половина картины. Вторая половина — сколько стоит это качество на вашем железе. Замеры делаются на том же оборудовании, где модель будет крутиться в продакшене, или максимально близком к нему.

Стандартный набор измерений:

• Латентность при трех размерах батча: 1 (онлайн-обслуживание единичного запроса), 32 (типовой батч для поиска) и 128 (пакетная индексация). Для каждого замера — p50, p95, p99.

• Пиковое потребление памяти — оцени сколько требуется VRAM для GPU и как загружен CPU.

• Пропускная способность — сколько векторов в секунду отдаёт установка при разных размерах батча.

Для инференса можно использовать optimum ^[35]. Чистый PyTorch-инференс в проде почти всегда плохая идея, разница в производительности до 2–3 раз и НЕ в его пользу.

Шаг 5. Тестирование квантования

Про квантование мы уже говорили. Это снижение точности весов модели: с FP32 до FP16 или INT8. Цель здесь уменьшить размер модели и ускорить инференс ценой небольшой потери качества.

Для лёгких моделей (sbert_large_nlu_ru, rubert-base) смысла в INT8 часто нет: они и так влезают в память, а ускорение инференса перекрывается накладными расходами на квантованный runtime. С INT8 имеет смысл экспериментировать начиная с моделей уровня BGE-M3 (500M+) и крупнее.

Шаг 6. Принятие решения

На выходе POC у вас таблица вида «модель × метрики качества × latency × память». Принятие решения это взвешенный выбор между точностью и стоимостью инфраструктуры. Стандартный подход:

1. Отбросить модели, которые не укладываются в жёсткие ограничения (латентность, VRAM, бюджет). Обычно это сужает выбор до 1–2 кандидатов.

2. Среди оставшихся выбрать модель с лучшим значением целевой метрики из Шага 1.

3. Если разница между двумя финальными моделями в метрике меньше ошибки ^[36] измерения (обычно 1–2 %), выбрать более лёгкую.

Примечание про переобучение под выборку. Если размеченная выборка маленькая (< 500 примеров) или специфичная, результат POC может не воспроизвестись на полном корпусе. Для валидности рекомендуется либо увеличить выборку, либо провести кросс-валидацию – разбить выборку на 3–5 фолдов и прогнать все модели на каждом.

---

Заключение

Надеюсь, я помог вам подобрать лучшую эмбеддинг модель для вашего проекта. В свое время я тратил несколько часов только для сбора информации про эмбеддеры доступные для деплоя.

Для тех, кто сейчас не планирует внедрять эмбеддинг, но подумывает об этом — сохраняйте себе эту статью в закладках. Еще увидимся!