Embedding-модели для русского RAG: выбор и проверка поиска

Что именно выбирать для русского RAG?

Embedding-модель превращает текст вопроса и фрагменты документов в векторы для поиска; это не генеративная модель, которая пишет итоговый ответ. Выбор стоит делать на собственном корпусе: русские договоры с похожими пунктами, инструкции с разными редакциями и каталоги с точными артикулами предъявляют разные требования. Для начала составьте одинаковый набор обезличенных документов и вопросов, затем сравните кандидатов по найденным релевантным фрагментам, не по впечатлению от отдельного ответа. В официальном протоколе Qdrant этому соответствует размеченный набор вопросов и релевантных doc_id s5.

Здесь четыре конкретных, опубликованных варианта: BAAI/bge-m3, intfloat/multilingual-e5-large, Qwen/Qwen3-Embedding-0.6B и ai-sage/Giga-Embeddings-instruct-480M-0826 s1 s2 s3 s4. Карточки и веса доступны на закреплённых ревизиях, но поддержка русского языка в карточке не доказывает качество на ваших документах. Лицензионные метки артефактов: MIT у BGE-M3, E5 и Giga, Apache-2.0 у Qwen3; перед промышленным применением проверяйте действующие условия репозитория, зависимости и права на документы отдельно s1 s2 s3 s4. Открытые веса не обещают бесплатного размещения или неограниченного использования любого набора данных.

Чем отличаются четыре кандидата?

• BGE-M3: автор описывает плотный, разреженный и multi-vector режимы; плотный вектор — 1024 измерения, заявлена работа с вводом до 8192 токенов. Это кандидат, если нужно отдельно испытать dense и hybrid-поиск; не приравнивайте его sparse-веса к готовому BM25 без проверки конфигурации хранилища. Карточка говорит, что дополнительная инструкция к запросу для BGE-M3 не требуется s1.
• multilingual-E5-large: карточка указывает 1024 измерения, в примере ограничивает длину до 512 токенов и требует точные префиксы query: для вопроса и passage: для документа, в том числе при вводе не на английском. Если забыть префикс при индексации, это уже другой эксперимент; переиндексируйте документы перед сравнимым тестом s2.
• Qwen3-Embedding-0.6B: в карточке указана возможность размерности до 1024 и инструкция к вопросу вида Instruct: ... с новой строкой Query: ...; документный фрагмент подаётся без инструкции. Это отдельная 0.6B-модель, не 4B/8B и не Qwen3 Reranker. Пример карточки использует max_length=8192, хотя сводная строка заявляет контекст 32K; не переносите максимум семейства в конкретный пример запуска без дополнительной проверки s3.
• Giga Embeddings instruct 480M 0826: автор указывает вектор 1024, mean pooling и нормализацию; к вопросу добавляет Instruct: ... и Query: ..., к документу — нет. Авторский пример Sentence Transformers использует trust_remote_code=True: такой код сначала нужно изучить и закрепить ревизию; один факт наличия весов не подтверждает совместимость с вашим API/runtime s4 s8.

Размерность вектора определяет форму индекса, не минимальный объём RAM/VRAM. Длина входа в документации также не равна обещанию, что длинный договор будет найден целиком. Разбивайте документы по смысловым границам, храните идентификаторы исходных фрагментов, проверяйте обрезание токенизатором и записывайте настройки перед сопоставлением. Если поменяли модель, префиксы, инструкцию, нормализацию или размерность, заново получите векторы документов; иначе вопрос и индекс перестанут соответствовать одному эксперименту.

Как повторить проверку на русских документах?

1. Зафиксируйте данные. Подготовьте обезличенный корпус с неизменными doc_id и chunk_id. Ручным чтением разметьте вопросы и все подходящие фрагменты, отдельно отметьте запросы с артикулами/номерами, сокращениями и несколькими релевантными ответами. Qdrant различает оценку релевантности выдачи, точность приблизительного ANN-индекса и качество конечного RAG-ответа; здесь измеряем только первую s5.
2. Запишите для каждой модели режим. Используйте закреплённый SHA из источников и соответствующий путь генерации векторов из карточки: BGE-M3 dense отдельно от его sparse-режима; E5 с парой префиксов; Qwen3 и Giga с документами без инструкции и вопросами с инструкцией. Для Giga не включайте выполнение пользовательского кода над корпоративным корпусом до анализа репозитория и закрепления ревизии s1 s2 s3 s4 s8.
3. Индексируйте одинаковые фрагменты. Для каждого кандидата создайте независимую коллекцию с размерностью его фактического вывода и одинаковыми doc_id, правилами нарезки, числом кандидатов и фильтрами доступа. Проверьте на одном нейтральном вопросе, что векторы получены, имеют ожидаемую длину, а выдача возвращает ID исходных фрагментов. Это контроль формы данных, не проверка семантического качества s5. Для работы с коллекцией есть локальный гайд Qdrant.
4. Сравните выдачу. Для каждого вопроса сохраните первые пять chunk_id и оцените Recall@5 = количество релевантных фрагментов в топ-5 / число всех релевантных размеченных фрагментов; затем усредните по одному и тому же набору вопросов. Если один документ разбит на несколько кусков, заранее решите, оцениваете ли chunk_id или doc_id: Qdrant предупреждает, что при свёртке нескольких чанков к одному документу следует сохранять первое, наиболее высокое место документа s5. В Sentence Transformers InformationRetrievalEvaluator также принимает словарь релевантных документов и поддерживает наборы precision_recall_at_k и ndcg_at_k s7.
5. Сравните ошибки и затраты. Сохраните ревизию модели, runtime, CPU/GPU, формат весов, память процесса и задержку на одинаковом размере пакета; без собственного прогона никаких чисел памяти и скорости здесь нет. Проверьте, не проваливаются ли артикулы при хорошей средней семантической выдаче. При необходимости проведите отдельный тест dense+sparse и слияния RRF, которое описывает Qdrant s6. Не приписывайте улучшение одной модели при одновременной смене индекса, сегментации и reranker.

Когда результат ещё не означает готовый RAG?

Даже найденный релевантный фрагмент не гарантирует, что генеративная модель процитирует его верно. Проверяйте источники в ответе отдельно; следующая проверка — протокол оценки качества RAG. Если в пилоте важны права доступа, исключайте запрещённые документы до выдачи и проверяйте результат под разными ролями; высокое Recall@5 само по себе не доказывает безопасность. Для сочетания смыслового поиска с точными совпадениями откройте гайд по гибридному поиску s6.

Следующий шаг: составьте размеченные русские вопросы и ожидаемые doc_id по протоколу проверки поиска, затем замерьте Recall@5 отдельно для каждой закреплённой модели. Это даст решение по вашему корпусу, не общий «топ лучших» без воспроизводимых условий s5.