Эмбеддинги для RAG

Embeddings для RAG в 2026: hosted vs self-hosted, multilingual retrieval, query/document modes, storage cost и как выбирать модель без leaderboard-mania.

Embeddings в RAG в 2026 полезно понимать не как “ещё один leaderboard с самыми большими баллами”, а как retrieval representation layer. Именно embedding-модель решает, какие тексты будут казаться поиску похожими по смыслу, а какие нет. Если этот слой подобран плохо, ни reranking, ни сильная генеративная модель уже не спасут retrieval полностью.

Главный practical сдвиг: выбирать embeddings теперь лучше не по абстрактному “кто первый на MTEB”, а по четырём вопросам:

hosted или self-hosted;
multilingual или English-first;
cheap-and-fast или max-quality;
сколько реально стоят indexing и storage на вашем объёме данных.

Эмбеддинг можно представить как координаты текста в карте смыслов. Запрос и документ попадают в близкие точки, если говорят об одном и том же. Чем лучше карта, тем чаще поиск находит действительно нужные куски, а не просто слова “похожие на тему”.

Не выбирайте embeddings только по бенчмарку или размеру вектора. Для RAG важнее, как модель ведёт себя на ваших документах, в вашем языке и при вашем бюджете indexing + search.

Профиль	Обычно подходит
Быстрый managed старт	OpenAI embeddings
Сильная multilingual-поддержка	Cohere embeddings, multilingual E5, BGE-M3
Self-hosted / privacy-first	multilingual E5, BGE-M3 и другие open models
Очень большой индекс	более компактные vectors или hosted retrieval path

1. Что embeddings реально делают в RAG

Embedding-модель не отвечает пользователю напрямую. Она кодирует:

документы;
чанки;
иногда отдельные titles / summaries / metadata;
запрос пользователя.

После этого retrieval layer уже работает по vector similarity. Это значит, что embedding-модель определяет:

что система сочтёт “похожим”;
насколько хорошо ловятся синонимы;
как ведёт себя поиск на коротких queries;
как retrieval работает на русском и смешанном контенте;
насколько чувствительна система к шумным chunk-ам.

Именно поэтому embeddings лучше думать как про модель поиска, а не просто как про служебный preprocessing step.

2. Hosted vs self-hosted embeddings

В 2026 это один из самых важных выборов.

Подход	Когда полезен	Цена выбора
Hosted embeddings	нужен быстрый запуск, меньше infra, стабильный API	платите провайдеру, данные уходят наружу
Self-hosted embeddings	важны privacy, контроль, offline pipeline, высокая batch throughput	нужен runtime, обновления и собственная infra

Hosted path удобен, если вы уже используете managed retrieval или OpenAI/Cohere stack. Self-hosted path логичен, когда:

документы нельзя выносить наружу;
индекс очень большой;
нужен постоянный mass re-index;
важна полная воспроизводимость retrieval layer.

3. Multilingual retrieval важнее, чем кажется

Для русского, смешанного RU/EN и вообще multi-lingual corpora ошибка выбора модели особенно болезненна. English-first embeddings могут выглядеть “нормально” на простых примерах, но разваливаться на:

падежах;
синонимах;
длинных русских формулировках;
transliteration / mixed-language docs;
support-кейсах с короткими пользовательскими вопросами.

Практически это значит:

если у вас много русского, не берите random English-only embedding by default;
multilingual модели обычно безопаснее;
quality надо мерить на ваших RU queries, а не по общему ощущению.

Без техники

{ "title": "Плохо", "content": "Выбрали embedding по общему хайпу, а потом удивляемся, что запрос `как оформить возврат` не подтягивает документ `refund policy` и наоборот." }

С техникой

{ "title": "Лучше", "content": "Сначала собираем RU/EN test set, потом сравниваем 2-3 модели по retrieval recall и noise, и только после этого фиксируем embedding layer." }

4. Query/document modes тоже имеют значение

Некоторые embedding families различают:

query encoding;
document / passage encoding.

Это особенно важно для семейств вроде E5, где форматы query: и passage: не декоративны, а реально влияют на retrieval quality.

Если команда игнорирует этот режим и кодирует всё одинаково, retrieval может деградировать без видимой причины.

Поэтому practical правило такое:

Читайте, есть ли у модели разные режимы для query и document.
Фиксируйте единый способ encoding в indexing pipeline.
Не меняйте embedding preprocessing “между делом” без полной переиндексации.

5. Размер вектора влияет не только на качество

Люди часто смотрят на embedding dimension как на суррогат “мощности”. Это слишком грубо.

Что реально меняет размер вектора:

storage footprint;
стоимость vector DB;
память индекса;
latency nearest-neighbor search;
стоимость пересоздания индекса.

Больший vector не автоматически означает лучший retrieval для вашего домена. Иногда более компактная модель с лучшей multilingual/generalization profile оказывается operationally выгоднее.

6. Как выбирать embedding-модель без leaderboard-mania

Самый рациональный путь:

Шаг 1. Соберите mini-eval set

Хотя бы:

20-50 типовых запросов;
known-good chunks;
no-answer cases;
hard synonym / paraphrase queries;
multilingual queries, если они есть.

Шаг 2. Мерьте retrieval, а не впечатление

Нужно смотреть хотя бы на:

retrieval recall@k;
precision / noise;
no-answer behavior;
citation usefulness downstream;
latency and cost of indexing.

Шаг 3. Сравнивайте не больше 2-4 моделей

Обычно достаточно:

одного hosted baseline;
одного multilingual open model;
ещё одной модели под ваш privacy/cost profile.

7. Что чаще всего работает в production

Hosted / managed path

Если нужен быстрый и предсказуемый запуск, hosted embeddings полезны тем, что:

не надо поднимать отдельный inference runtime;
проще batch indexing;
легче интегрироваться с managed retrieval stacks.

Self-hosted multilingual path

Если важны privacy и multilingual retrieval, open families вроде multilingual E5 и BGE-M3 часто выглядят pragmatic choice:

хороший multilingual coverage;
нормальный retrieval baseline;
можно держать у себя;
проще контролировать re-index economics.

Не over-optimize слишком рано

Для небольшого knowledge base часто важнее:

хороший chunking;
metadata filters;
reranking;
no-answer policy;

чем идеальный embedding leaderboard winner.

8. Частые ошибки

смешивать embeddings разных моделей в одном индексе;
менять preprocessing без полной переиндексации;
игнорировать query/document modes;
мерить только общий benchmark score;
тестировать только на английских примерах, если реальный трафик русский;
гнаться за max-quality model, забыв про storage и indexing cost.

Плюсы

Хорошая embedding-модель заметно улучшает retrieval ещё до reranking
Multilingual models помогают держать один retrieval layer для RU/EN корпусов
Hosted path ускоряет запуск, self-hosted path даёт больше контроля
Компактные модели иногда выигрывают по total cost, даже если benchmark score чуть ниже

Минусы

Один leaderboard score почти никогда не отвечает на вопрос `подойдёт ли нам`
Неправильный query/document mode тихо ломает retrieval
Большой vector size увеличивает storage и infra cost
Смена embedding-модели почти всегда требует полной переиндексации

Минимальный hosted embedding flow

from openai import OpenAI

client = OpenAI()

chunks = [
    "Возврат товара возможен в течение 14 дней.",
    "Для возврата нужен чек или номер заказа.",
]

response = client.embeddings.create(
    model="text-embedding-3-small",
    input=chunks,
)

vectors = [item.embedding for item in response.data]
print(len(vectors), len(vectors[0]))

Минимальный self-hosted multilingual flow

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("intfloat/multilingual-e5-large")

docs = [
    "passage: Возврат товара возможен в течение 14 дней.",
    "passage: Для возврата нужен чек или номер заказа.",
]
query = "query: как вернуть покупку"

doc_vectors = model.encode(docs, normalize_embeddings=True)
query_vector = model.encode([query], normalize_embeddings=True)[0]

scores = doc_vectors @ query_vector
print(scores)

Проверьте себя

1. Что важнее всего при выборе embedding-модели для RAG?

{ "text": "Только место на leaderboard", "correct": false, "explanation": "Нет. Важнее retrieval quality на ваших данных, языке и operational constraints." } { "text": "Как модель ведёт себя на вашем retrieval dataset, языке и бюджете", "correct": true, "explanation": "Верно. Именно это определяет реальную пользу embeddings в production." } { "text": "Только размер вектора", "correct": false, "explanation": "Размер важен для storage и latency, но сам по себе не гарантирует качество." }

2. Когда self-hosted embeddings особенно логичны?

{ "text": "Когда важны privacy, offline indexing и контроль над infra", "correct": true, "explanation": "Да. Это типичный повод уйти в open/self-hosted path." } { "text": "Когда хочется просто меньше читать документацию", "correct": false, "explanation": "Hosted path обычно как раз проще по операционке." } { "text": "Когда не хотите переиндексировать при смене модели", "correct": false, "explanation": "Наоборот, смена embedding-модели обычно требует полной переиндексации." }

3. Какая тихая ошибка часто ломает retrieval?

{ "text": "Использовать query/document режимы модели правильно", "correct": false, "explanation": "Это как раз полезная практика." } { "text": "Игнорировать различие между query и passage encoding", "correct": true, "explanation": "Да. Для некоторых embedding families это заметно ухудшает retrieval quality." } { "text": "Ограничить сравнение 2-4 моделями на своих данных", "correct": false, "explanation": "Это как раз прагматичный способ выбора." }

Источники

Что такое RAG