Разрабатывая AI-консультантов и ассистентов на базе RAG-архитектуры, работающих с корпоративными базами знаний на русском языке, мы столкнулись с вопросом: какие открытые эмбеддинг-модели дают лучший баланс качества семантического поиска на русском и скорости работы. Особенно это актуально, когда запросы и документы русскоязычные, но внутри часто попадаются фрагменты кода (например, SQL или Python) и англоязычной терминологии.

Мы прогнали 9 open-source эмбеддинг-моделей через несколько тестов, включающих проверки:

• Умение распознать тематику близких по значению русских слов (омонимы);

• Умение искать схожие тексты на русском языке;

• Способность искать схожие тексты на русском языке вперемешку с примерами SQL-кода.

AI-консультант в корпорациях и зачем RAG

Интерес к AI со стороны корпоративного сектора растёт. Компании запускают пилоты и пытаются добиться экономически эффективных бизнес-кейсов применения LLM в разных сценариях. При этом любая крупная компания сразу поставит достаточно жёсткие требования к вопросам безопасности и персонализации (использование доменных и корпоративных знаний). Дообучение (fine-tuning) LLM — штука дорогая и долгая, поэтому архитектура RAG становится неплохим решением, когда LLM необходимо снабдить вашими данными, документами и знаниями. В RAG мы не вшиваем знания в веса модели, а «подкладываем» LLM нужные куски ваших документов перед генерацией ответа на запрос пользователя.

Выделю пару сценариев применения AI в архитектуре RAG, с которыми мы сталкивались:

• AI-консультант по регламентам, нормативам и общим вопросам внутри компании (отпуск, больничный, закупки, командировки и прочее);

• AI-ассистент для инженеров ИТ-поддержки и пользователей.

Почему от retrieval зависит всё

Одна из ключевых частей RAG-архитектуры — retrieval-процесс, векторный поиск по базе знаний, чтобы снабдить основную LLM подходящим контекстом из ваших корпоративных документов. Если retrieval подберёт нерелевантные или слишком общие фрагменты корпоративной информации, качество ответа значительно снизится. LLM «на выходе» будет ровно настолько полезна, насколько релевантный контекст ей принесёт retrieval.

В retrieval-процессе критичны три составляющих:

1. Эмбеддинг-модель — создаёт векторы с определённой размерностью.

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

3. Стратегия извлечения: выборка top-k подходящих найденных документов, использование тегирования, rerank-процесс после поиска, дописывание запроса пользователя для повышения качества, применение hybrid (BM25+dense).

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

Какие модели мы тестировали и почему именно они

Мы сознательно ограничились открытыми энкодерами, которые:

• легко поднимаются on-premise;

• поддерживаются в LangChain/LlamaIndex;

• мультиязычные либо сильные в русском языке;

• различаются по семействам и размерности (384–1024d), чтобы увидеть разницу «скорость и качество». Теоретически, чем выше размерность, тем богаче представление текста, но на практике всё иначе.

Для тестирования мы определили такой список эмбеддинг-моделей: 

Занимаемый объём модели (размер контейнера + кеш) указал для понимания и сравнения.

Коммерческие модели (OpenAI/Cohere и пр.) мы сознательно исключили (условие «open-source + on-prem»). А другие узкоспециализированные/тяжёлые энкодеры по опыту хуже по скорости/доступности в корпоративном контуре.

Разминочный тест на понимание богатого русского языка

Перед большими прогонами на датасетах мы сделали мини-проверку «на нюанс языка»: набор фраз про лук (овощ vs оружие) и команду (приказ vs бригада). Такой тест не про статистику — он про интуитивную «чуткость» к контексту на русском. Многие энкодеры в общем-то «сильны», но спотыкаются о слова-омонимы.

Мы создали векторы в Qdrant для следующих фраз:

• «Лук был порезан на тонкие куски и залит уксусом»

• «Срезал тонкую ветку и сделал лук и стрелы»

• «Если тонко нарезать и кушать лук каждый день — будешь худым»

• «Маринованный лук в рецепте добавляет тонкий вкус французской кухни»

• «Он срезал мимо мишени, так как его лук был очень тонкий»

И каждую модель попросили найти близкие по векторам фразы (cosine similarity) на запросы:

• «Что мне приготовить на завтрак?»

• «Попасть в яблочко трясущейся рукой невозможно»

• «Что надо для здорового образа жизни?»

То же самое проделали с фразами про «команду»:

• «Необходимо выполнить команду reset и перезагрузить мастер-систему»

• «Спортивная команда выполнила все необходимые нормативы и вышла на старт беговой дорожки»

• «По требованию генерального директора наша команда выполнила проект в необходимые сроки»

• «После перегрузки системы выполнить следующую команду start»

• «Для выполнения генеральной уборки в самолёте приехала целая команда специалистов»

И далее получили результаты поиска близких векторов на запросы:

• «Что делать, если система перезагрузилась?»

• «Наша команда участвовала в забеге на 5 км?»

• «Сколько человек нужно, чтобы здесь навести порядок и чистоту?»

• «Кто в вашей команде отвечает за сроки?»

Результаты просматривали вручную по каждой модели, получили такой расклад:

Итоги разминки:

• «Отлично» — bge‑m3, distiluse, gte_multilingual (лучше других разводят значения векторов).

• «Хорошо/Середнячок» — e5‑base, местами rubert.

• «Слабо» — minilm, gte‑base, arctic (много ошибались, путали тематики).

Этот чек даёт предварительное ожидание перед «боевыми» наборами.

Методология тестирования

Мы собрали два датасета, эмулирующие корпоративные базы знаний:

1. FAQ по возможностям Битрикс24. Мы собрали 120 вопросов-ответов с сайта вендора. Небольшие тексты по 300–500 символов, без технических деталей, все на русском языке с редкими терминами на английском.

2. Справочник по SQL. Собрали 200 небольших статей по 500–1000 символов; каждая статья включает текст описания на русском языке и примеры SQL-запросов.

С получением эталонного результата нам сильно помог GPT-5. С его помощью мы подготовили:

• По 100 запросов, наиболее подходящих для тестирования моделей в разрезе текстов наших баз знаний;

• По 3 наиболее релевантных по cosine-схожести ответа из наших баз знаний, что мы приняли за эталонный результат от «наиболее умной» LLM.

Получив по 5 наиболее схожих текстов от каждой исследуемой эмбеддинг-модели по всем запросам, мы сравнили результаты с эталоном от GPT-5. Создали свою бальную систему, поощряющее наличие эталонных текстов в топ-3 результатов  и их правильное ранжирование. По итогу получили такие метрики:

1. Recall@5 — доля 3х эталоных текстов, попавших в топ‑5 результатов от каждой модели.

2. Сумма баллов за схожие тексты по всем запросам (своя бальная система).

3. Среднее время формирования эмбеддинга запроса.

4. Среднее время поиска по соответствующей коллекции в Qdrant .

Нюансы конфигурации коллекций векторов и поиска по ним

Подготовленные базы знаний были векторизованы каждой эмбеддинг-моделью и сохранены в виде коллекций в векторную базу данных Qdrant.

Из технических нюансов стоит отметить параметры HNSW (Hierarchical Navigable Small World), влияющие на построение индекса и поиск ближайших соседей:

• m — количество рёбер (соседей), которые хранятся у каждой точки в графе. Чем больше m, тем выше recall и стабильнее ранжирование, но больше занимаемого места и дольше процесс индексации. Для всех коллекций мы указали m = 16.

• ef_construct — управляет числом кандидатов, рассматриваемых при построении графа (качество связей и скорость построения). В наших тестах (≈200 векторов на коллекцию) влияние ef_construct не очень заметно, но мы выровняли параметры, чтобы сравнение моделей было в схожих условиях: MiniLM (96), intfloat-small (96), distiluse (100), intfloat-base (128), gte-base (128), gte-multilingual (128), rubert (128), arctic (140), bge-m3 (160).

• full_scan_threshold — порог, ниже которого Qdrant делает полный перебор всех векторов в коллекции. Для всех коллекций мы указали full_scan_threshold = 2000.

• normalize_embeddings — L2-нормализация эмбеддингов. Чтобы cosine и dot давали эквивалентное ранжирование.

О префиксах (query/document)

Префиксы нужны, чтобы сообщить модели контекст, в какой роли используется указанный текст — это запрос пользователя (query) или документ (document/passage). Часть retrieval-моделей обучалась на парах «запрос—документ», поэтому без префикса они могут «перепутать роли» и ухудшить точность поиска. Если модель обучалась не на query-document парах (например, на общих sentence-similarity задачах), префиксы обычно не требуются.

В нашем тестировании мы используем префиксы в следующих моделях:

• E5 и Arctic: query: для запроса, passage: для документа;

• GTE: query: для запроса, document: для документа;

• MiniLM, Distiluse, RuBERT, BGE-m3: без префиксов.

Итоги теста №1 (поиск по русскоязычному FAQ)

База знаний: русскоязычный FAQ (вопросы-ответы о возможностях Битрикс24), русский язык с редким использованием терминов на английском.

Пример текста из базы знаний:
«Вопрос: Можно ли пригласить в задачу внешнего пользователя? Ответ: Да, работа с задачами в Битрикс24 доступна не только для команд внутри компании, но и для внешних пользователей. Приглашайте гостей по email — они могут отслеживать задачу и оставлять комментарии.»

Запросы: русский язык с возможными терминами на английском

Пример запроса:
«Как CRM реагирует, если один и тот же клиент создаёт лиды через сайт и мессенджер одновременно?».

Метрики оценки: баллы (основной), Recall@5, среднее время эмбеддинга и поиска (в секундах).

Выводы первого теста:

• Для классической корпоративной FAQ-базы E5-семейство и BGE-m3 — безусловные фавориты.

• Если нужна максимальная скорость и работа на CPU — e5-small почти не уступает по качеству, а время задержки существенно ниже.

• Хорошо проявила себя Distiluse: на промежуточных замерах она показывала результат выше «тяжёлой» BGE-m3, и показатель Recall у неё по итогу на хорошем уровне.

Итоги теста №2 (поиск по русскоязычному SQL-учебнику)

База знаний: русский язык + фрагменты SQL-кода в каждом тексте.

Пример текста из базы знаний:
"Функция COUNT() позволяет подсчитывать количества строк, игнорируя значения NULL. Пример: SELECT COUNT(*) AS cnt FROM employees WHERE salary > 50000; Функция AVG() — вычисляет среднее значение по колонке. Пример: SELECT AVG(salary) FROM employees;”.

Запросы: русский язык с возможными терминами на английском,

Примеры запросов: 
«Чем отличается INNER JOIN от LEFT JOIN?»;
«Как объединить результаты из двух таблиц в один список?»

Метрики: баллы (основной), Recall@5, среднее время эмбеддинга и поиска (в секундах).

Выводы второго теста:

• Когда в документах соседствуют русский текст и SQL-код, устойчивее всего ведёт себя e5-base; gte_multilingual и e5-small — топ по балансу качество/скорость;

• Bge-m3 близко по качеству, но ощутимо медленнее по созданию эмбеддинга.

• Остальные модели себя не проявили.

Итоги теста №3 (поиск по SQL-учебнику на сложные запросы)

Мы решили протестировать поиск по SQL-базе знаний, когда в самом запросе используется SQL-код.

Например такого запроса:
«Чем INNER JOIN отличается от LEFT JOIN в запросе SELECT o.id, u.email FROM orders o LEFT JOIN users u ON u.id = o.user_id; с точки зрения результатов и производительности?»

Вывод третьего теста:

• Мы оценили небольшое количество подобных "сложных" запросов, но результаты отличаются от предыдущего теста.

• Когда в самих запросах мы используем SQL-код, все модели проявили себя достаточно плохо, recall@5 низкий у всех. И для решения подобных задач одного векторного поиска для retrieval мало.

• Но стоит отметить, что по нашей бальной системе e5‑base и gte_multilingual остались в топе. 

Итоги нашего сравнения моделей

1. Универсальный выбор под RU‑FAQ и RU+SQL-код:
   Intfloat/multilingual‑e5‑base — лучший общий баланс: стабильно топ‑1/топ‑2 на двух больших тестах, высокий Recall@5, умеренные временные метрики поиска и формирования эмбединга.

2. Если критична скорость и стоимость ресурсов:
   Intfloat/multilingual‑e5‑small — близкое качество, но время формирование эмбеддингов в разы быстрее; отлично для массовой индексации и дешёвого CPU.

3. Если сложный поиск на русском языке, где нельзя упустить “игру смыслов”:
   BAAI/bge‑m3 и более легкая sentence-transformers/distiluse-base-multilingual-cased-v2 лучше различают смысловые оттенки и контекст; минус bge‑m3 — достаточно медленная во всем.

4. Если нужен мультиязычный компромисс и хорошее поведение на «хардовых» SQL:
   Alibaba‑NLP/gte‑multilingual‑base — была топ‑1 в «hard SQL» и регулярно держится в верхней группе, при этом достаточно быстрая.

5. Модели, которые в наших условиях себя не проявили: RuBERT, MiniLM, Arctic, GTE‑base — стабильно ниже по суммарным баллам/Recall@5 на всех тестах. Возможные причины:

• RuBERT- на базе BERT, обучена не для retrieval

• MiniLM - очень лёгкий, емкости часто не хватает для нюансов русского языка и для смешанных случаев RU+код.

• Arctic - «enterprise-ориентированный» энкодер, который сильнее на англоязычных документах и деловых текстах.

• GTE‑base - фактически англоязычный энкодер.

Что выбрать для retrieval?

Всё зависит от сценария использования RAG, размера базы знаний, языка и важности точности ответа. Retrieval-этап — ключевой элемент RAG-архитектуры, и выбор правильной эмбеддинг-модели напрямую определяет качество ответов LLM.

Если не знаете, с чего начать, универсальным стартом для корпоративного RAG будет связка E5-base + база Qdrant. На уровне индексации базы знаний желательно настроить chunking (200–500 слов с overlap 10–20 % без потери смысла) и сохранять метаданные для фильтров, нормализовать эмбеддинги (L2) и использовать одну и ту же метрику (cosine) при индексации и при поиске, чтобы векторная база и эмбеддинг-модель были «согласованы».

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