Выбор модели эмбеддингов — самый недооценённый этап построения RAG. Пока команды спорят о том, какую LLM поставить в генератор, именно векторное представление определяет, найдёт ли система нужный пункт договора или подставит в контекст случайный абзац. Для русских документов долго приходилось выбирать между качеством и приватностью: облачные embedding-API давали приемлемый результат, но отправлять туда техрегламенты, кадровые приказы и коммерческие договоры нельзя. BGE-M3 снимает этот компромисс — модель весит около 2 ГБ, работает на одной GPU и уверенно держит русский язык.

Что даёт bge-m3 на русских корпусах

Модель от BAAI обучена более чем на 100 языках, поддерживает контекст до 8192 токенов и не требует служебных префиксов вида query: / passage:, которые легко перепутать при интеграции. Это заметно упрощает жизнь: один и тот же энкодер обслуживает и индексацию, и поисковый запрос. На бенчмарке ruMTEB модель уступает FRIDA от SberDevices в задачах классификации, но в поиске по длинным неоднородным документам выигрывает за счёт длины контекста и гибридных режимов. Для корпусов, где смешаны русский, английский и терминология на латинице (ГОСТы, артикулы, названия ПО), это критично.

Три представления в одном проходе

BGE-M3 отдаёт сразу три типа векторов. Dense-вектор размерности 1024 отвечает за семантику и перефразировки. Sparse-вектор — обучаемые лексические веса, фактически улучшенный BM25, который ловит точные совпадения: номера приказов, ФИО, индексы, аббревиатуры. Multi-vector в стиле ColBERT хранит эмбеддинг каждого токена и даёт позднее взаимодействие — он же хорошо работает как второй этап ранжирования.

Практический вывод: не нужно выбирать между «векторным» и «ключевым» поиском. Все три сигнала берутся с одного инференса и объединяются через Reciprocal Rank Fusion в Qdrant, Milvus или pgvector.

Как развернуть локально

Базовый сценарий — библиотека FlagEmbedding или sentence-transformers:

from FlagEmbedding import BGEM3FlagModel
model = BGEM3FlagModel("BAAI/bge-m3", use_fp16=True)
out = model.encode(chunks, return_dense=True,
                   return_sparse=True, return_colbert_vecs=False)

На одной современной GPU с fp16 реально индексировать 1000–2000 чанков в минуту, то есть корпус на 100 тысяч страниц обрабатывается за пару часов. Для CPU-контуров есть ONNX-экспорт с int8 — качество падает на 1–3 пункта Recall, зато снимается требование к видеокарте. Обязательно нормализуйте dense-векторы и фиксируйте версию модели в метаданных индекса: обновление весов без переиндексации ломает поиск.

Чанкинг, метаданные, реранкинг

Хотя модель принимает 8192 токена, для поиска лучше резать документы на фрагменты по 400–800 токенов с перекрытием 10–15%. Длинный чанк размывает вектор и снижает точность попадания. К каждому фрагменту прикрепляйте метаданные: раздел, дату, тип документа, гриф доступа — фильтры по ним часто дают больше прироста, чем смена модели. Схема ранжирования: dense + sparse → RRF → топ-50 → реранкер bge-reranker-v2-m3 → топ-5 в контекст LLM.

Как проверять качество

Не ориентируйтесь только на публичные бенчмарки: ruMTEB измеряет классификацию и кластеризацию, а не качество поиска. Соберите golden set из 150–300 реальных вопросов сотрудников с эталонными фрагментами и считайте Recall@10, MRR и nDCG@10. Сравнивайте минимум три конфигурации: multilingual-e5-large, FRIDA и bge-m3 в гибридном режиме. Такой замер занимает день, но экономит месяцы переделок.

Как мы можем помочь

Мы в АПС разворачиваем приватные контуры RAG целиком: подбираем модель эмбеддингов под ваш корпус, настраиваем чанкинг и гибридный поиск, собираем golden set и доводим метрики до целевых, а затем подключаем LLM и интеграции с 1С и CRM. Если хотите оценить, что даст bge-m3 на ваших документах, — Обсудить проект и пришлите небольшой обезличенный срез корпуса.