Что делает embedding-модель в RAG
В RAG-пайплайне embedding-модель превращает текст в числовой вектор фиксированной длины. Этот вектор затем сохраняется в векторной базе данных, а при запросе пользователя тот же механизм кодирует запрос и находит ближайшие документы по косинусному сходству или L2-дистанции.
Качество retrieval напрямую зависит от того, насколько хорошо модель различает семантически близкие и далёкие фрагменты. Ошибка на этапе выбора embedding-модели не компенсируется ни промптом, ни LLM: если нужный документ не попал в топ-k, генеративная модель его просто не увидит.
Размерность вектора: компромисс между точностью и стоимостью
Размерность (dimension) — количество чисел в векторе. Типичные значения: 384, 768, 1024, 1536, 3072.
Что влияет на практике:
| Размерность | Плюсы | Минусы |
|---|---|---|
| 384–768 | Меньше памяти, быстрее поиск, дешевле хранение | Может терять тонкие семантические различия |
| 1024–1536 | Хороший баланс для большинства задач | Умеренные требования к ресурсам |
| 3072+ | Максимальная выразительность | Дороже хранение, медленнее brute-force поиск, не всегда даёт прирост качества |
Важно понимать: размерность сама по себе не гарантирует качество. Модель на 768 измерений, обученная на релевантных данных, может превосходить модель на 1536 измерений, обученную на шуме.
Практическое правило: если вы используете ANN-индекс (HNSW, IVF), стоимость хранения и поиска растёт линейно с размерностью. Для базы в 10 миллионов документов разница между 768 и 1536 измерениями — это удвоение RAM для индекса.
Языковая поддержка
Embedding-модели делятся на:
- Англоязычные — обучены преимущественно на английском корпусе. Для русского текста дают деградацию качества, которая может быть незаметна на коротких запросах, но критична на длинных документах.
- Мультиязычные (multilingual) — обучены на параллельных или многоязычных корпусах. Поддерживают десятки языков, включая русский.
- Специализированные под конкретный язык — редкость, но встречаются для китайского, корейского, арабского.
Для русскоязычного RAG мультиязычная модель — минимальное требование. При этом стоит проверять качество именно на русском: некоторые мультиязычные модели хорошо работают на европейских языках, но проседают на русском из-за дисбаланса в обучающих данных.
Бенчмарки: MTEB и его ограничения
Основной публичный бенчмарк для embedding-моделей — MTEB (Massive Text Embedding Benchmark). Он оценивает модели по нескольким задачам: retrieval, classification, clustering, semantic similarity, summarization.
Для RAG наиболее релевантна задача Retrieval — именно она измеряет, насколько хорошо модель находит нужные документы по запросу.
Ограничения MTEB:
- Бенчмарк использует англоязычные датасеты. Высокий общий скор не гарантирует качество на русском.
- Задачи retrieval в MTEB используют относительно короткие документы. Если ваш корпус — длинные технические мануалы или юридические тексты, результаты могут отличаться.
- Лидерборд обновляется, и модели, которые были топовыми полгода назад, могут уступать новым.
Что делать: если есть возможность, соберите небольшой тестовый набор из вашего реального корпуса (50–200 пар «запрос → релевантный документ») и прогоните кандидатов на нём. Это даёт более надёжный сигнал, чем любой публичный бенчмарк.
Максимальная длина входного текста
Каждая embedding-модель имеет ограничение на количество токенов на входе. Типичные значения:
- 256 токенов — старые модели, мало для большинства задач
- 512 токенов — стандарт для многих моделей
- 8192 токена — современные модели с длинным контекстом
Если документ длиннее лимита, его нужно разбивать на чанки до эмбеддинга. Качество чанкинга (размер чанка, перекрытие, стратегия разбиения) влияет на retrieval не меньше, чем сама модель.
Модели с длинным контекстом (8192 токенов) позволяют использовать более крупные чанки, что полезно для документов, где смысл распределён по нескольким абзацам. Но они обычно медленнее и дороже в инференсе.
Стоимость инференса и хранения
При выборе модели стоит учитывать не только качество, но и операционные расходы:
Инференс (кодирование):
- Локальный инференс на GPU: скорость зависит от размера модели. Модели на 100–300M параметров кодируют тысячи документов в секунду на одной потребительской GPU.
- API-провайдеры: стоимость обычно считается за 1000 токенов. Для больших корпусов это может стать заметной статьёй расходов.
Хранение векторов:
- Один вектор размерностью 768 в формате float32 занимает 3072 байта.
- 10 миллионов документов × 768 × 4 байта ≈ 28.7 ГБ только на векторы, без учёта индекса.
- Квантизация векторов (например, до int8 или binary) снижает требования к памяти в 4–32 раза, но может немного снизить качество поиска.
Поиск:
- Brute-force поиск по 10M векторов размерностью 768 на CPU занимает секунды — неприемлемо для интерактивных запросов.
- ANN-индексы (HNSW, IVF-PQ) снижают задержку до миллисекунд, но требуют дополнительной памяти и времени на построение.
Типичные ошибки при выборе
1. Выбор по общему скору MTEB без проверки на retrieval
Модель может быть лучшей в classification, но посредственной в retrieval. Для RAG смотрите именно на retrieval-метрики.
2. Игнорирование языка
Англоязычная модель на русском тексте может давать формально работающий, но семантически бедный retrieval. Запросы будут находить документы по поверхностному совпадению слов, а не по смыслу.
3. Слишком крупные чанки для модели с коротким контекстом
Если модель принимает 512 токенов, а вы режете документы на чанки по 2000 токенов, всё лишнее просто отбрасывается. Модель видит только начало чанка.
4. Смешивание разных моделей для индексации и запроса
Embedding-модель должна быть одной и той же при индексации документов и при кодировании запроса. Разные модели живут в разных векторных пространствах, и косинусное сходство между их векторами бессмысленно.
5. Игнорирование инструкции (instruction prefix)
Некоторые современные модели (например, семейства E5, GTE) требуют добавления инструкции-префикса к тексту перед кодированием. Для запроса это может быть
"query: ", для документа — "passage: ". Если префикс пропущен, качество падает.Как организовать выбор: пошаговый подход
- Определите язык и домен. Русский технический корпус, английский юридический, мультиязычный — требования разные.
- Отфильтруйте кандидатов по MTEB retrieval. Берите топ-10–20 моделей с поддержкой нужного языка.
- Проверьте максимальную длину входа. Убедитесь, что она совместима с вашей стратегией чанкинга.
- Соберите тестовый набор. 50–200 пар «запрос → релевандный документ» из реального корпуса.
- Прогоните кандидатов. Оцените Recall@k и MRR на вашем наборе.
- Оцените операционные расходы. Размер модели, скорость инференса, стоимость хранения векторов.
- Проведите A/B на реальном пайплайне. Иногда модель, которая чуть хуже на бенчмарке, лучше работает в связке с вашим LLM и промптом.
Инференс embedding-моделей через vLLM
Для продакшн-систем с высоким потоком запросов embedding-модели можно обслуживать через vLLM. Фреймворк поддерживает embedding- и retrieval-модели (включая семейства E5-Mistral, GTE, ColBERT) и обеспечивает непрерывный батчинг, что существенно повышает пропускную способность по сравнению с наивным последовательным кодированием.
Это особенно актуально, когда нужно переиндексировать большой корпус или обрабатывать поток запросов в реальном времени.
Когда стоит дообучать модель
Если ни одна публичная модель не даёт приемлемого качества на вашем домене, есть два пути:
- Fine-tuning на контрастивных парах. Нужны данные вида (запрос, позитивный документ, негативный документ). Даже несколько тысяч пар могут дать заметный прирост.
- Matryoshka representation learning. Позволяет использовать векторы меньшей размерности без потери качества — полезно, если нужно снизить стоимость хранения.
Дообучение имеет смысл, когда у вас есть размеченные данные и стабильный поток запросов, на котором можно измерить эффект. Для прототипа лучше начать с готовой модели.
Проверка результата после внедрения
После выбора и внедрения модели отслеживайте:
- Recall@k — доля релевантных документов, попавших в топ-k результатов.
- MRR (Mean Reciprocal Rank) — насколько высоко в выдаче стоит первый релевантный документ.
- Latency p95 — время кодирования запроса и поиска в векторной базе.
- Качество ответов LLM — конечная метрика. Если retrieval работает хорошо, но LLM всё равно галлюцинирует, проблема в промпте или контекстном окне, а не в embedding-модели.
Мониторинг этих метрик позволяет вовремя заметить деградацию: например, когда характер запросов пользователей смещается и модель перестаёт справляться.
