WHY BOTHER WITH EMBEDDINGS IN 2026
Embedding is the conversion of text into a vector of numbers so that semantically similar pieces end up close in space. This vectorization underpins all semantic search and the entire retrieval component of RAG. Change the encoder — and the quality of output, latency, and infrastructure cost change. This is not the component where 'any model will do': the difference between a successful and unsuccessful choice on a real corpus easily yields 10-20 percentage points of recall@10.
At the same time, the market has settled over the past two years. The race for dimensionality has slowed, MTEB is no longer the sole benchmark (people are already openly overfitting to it), and practitioners have shifted to three questions: corpus language, latency budget, and whether a reranker is needed. Let's go through them in order.
HOW TO READ BENCHMARKS AND NOT BE DECEIVED
The main mistake of a newcomer is choosing a model based on a line in the MTEB leaderboard. The problem is that many recent models were trained with an eye on these same datasets, and the number on the benchmark poorly transfers to your domain. Legal texts, support chat logs, and code behave completely differently.
What to really look at:
- Task. Retrieval, clustering, classification, and STS — different sub-tables. For RAG you are interested specifically in retrieval.
- Language. The average MTEB score is mainly English. For Russian, look for MTEB(rus) or multilingual slices.
- Your own evaluation. Collect 100-300 «question — correct document» pairs from your corpus and measure recall@k on them. Half a day's work pays off many times over.
Fresh releases of encoders and rerankers are conveniently tracked in the REDDYX catalog — there you can see what actually works in production, not just what's being hyped on Twitter.
COMPARISON OF MAIN EMBEDDING MODELS 2026
Below are the models that actually appear in production. I give MTEB numbers roughly (according to community measurements they fluctuate by a couple of points from revision to revision), so focus on the order, not the second decimal place.
| Model | Type | Dimension | Languages | Where it excels |
|---|---|---|---|---|
| BGE-M3 | Open | 1024 | 100+ | Multilingual, dense+sparse+ColBERT in one model |
| multilingual-e5-large | Open | 1024 | 100+ | Reliable default, excellent Russian |
| Qwen3-Embedding (0.6B / 4B / 8B) | Open | до 4096 | 100+ | MTEB top, instructions, flexible dimension |
| Voyage-3 | Proprietary API | 1024 (Matryoshka) | Multi | Retrieval quality, domains (code, finance) |
| OpenAI text-embedding-3-large | Proprietary API | до 3072 | Multi | Ease of integration, stability |
| Cohere Embed v3 | Proprietary API | 1024 | Multi | compression-aware, int8/binary out of the box |
Key shift in 2026: open models have caught up with proprietary ones on most retrieval tasks. Qwen3-Embedding-8B, according to community measurements, shares the MTEB top with paid APIs, while BGE-M3 remains a workhorse precisely because of its three modes at once — dense vector for speed, sparse for lexical match, and ColBERT multi-vector for accuracy.
RUSSIAN LANGUAGE: WHAT ACTUALLY WORKS
For a Russian-language corpus, the situation is simpler than it seems. There are few purely Russian SOTA encoders, so they take strong multilingual ones:
- multilingual-e5-large — the safest default. It captures Russian well, is stable, easy to host. Don't forget the prefixes
query:andpassage:— without them quality drops noticeably. - BGE-M3 — when you need a multilingual corpus (Russian + English + code) and hybrid search in one package.
- Qwen3-Embedding-4B — if you're willing to run a larger model for quality and you like the instruction mode (you can set the task via text).
Separately about Cyrillic: check tokenization. Some older models split Russian words into too small subwords, causing long documents to hit the context limit faster than expected. On e5 and BGE-M3 this is fine.
WORKING EXAMPLE: VECTORIZATION AND SEARCH
Minimal but honest pipeline on an open model without external APIs. We compute embeddings locally and search by cosine similarity.
from sentence_transformers import SentenceTransformer
import numpy as np
model = SentenceTransformer("intfloat/multilingual-e5-large")
docs = [
"passage: RAG объединяет поиск по базе знаний с генерацией ответа LLM.",
"passage: Reranker переупорядочивает кандидатов после первичного поиска.",
"passage: Косинусная близость измеряет угол между векторами.",
]
query = "query: что делает реранкер в RAG"
# нормализуем — тогда dot product == косинус
doc_emb = model.encode(docs, normalize_embeddings=True)
q_emb = model.encode(query, normalize_embeddings=True)
scores = doc_emb @ q_emb
top = np.argsort(scores)[::-1]
for i in top:
print(round(float(scores[i]), 3), docs[i][:60])Pay attention to the prefixes query:/passage: — for the E5 family this is not cosmetics, but part of the protocol. For BGE-M3 prefixes are not needed, but you can enable sparse mode and combine scores. In production, these vectors go to Qdrant, pgvector, or Milvus, not to NumPy — but the logic is the same.
RERANKER: MAIN LIFEHACK 2026
If you have a limited budget — don't chase the bulkiest encoder. Take a fast bi-encoder for initial selection of top-50-100 candidates, and put a cross-encoder reranker on top. This is architecturally correct and almost always gives a greater quality gain per unit cost.
Why it works: bi-encoder encodes query and document independently, losing some interaction between words. Cross-encoder (e.g., bge-reranker-v2-m3 or Qwen3-Reranker) processes the 'query+document' pair together and evaluates relevance more accurately — but it's expensive, so it's applied only to a small shortlist.
- First stage: dense search, cheap, covers thousands of documents.
- Second stage: reranker on top-50, expensive per item, but few items.
- Result: recall@5 often jumps by 10-15 percentage points without changing the base encoder.
DIMENSIONALITY, MATRYOSHKA, AND STORAGE SAVINGS
A 3072-dimensional float32 vector is 12 KB per document. For 10 million chunks that becomes 120 GB just for the index. Hence two trends in 2026:
- Matryoshka embeddings. The model is trained such that the first N dimensions already carry the main meaning. You can trim 1024→256 with minimal quality loss and cut storage by 4×. Supported by Voyage, OpenAI-3, Qwen3.
- Quantization. int8 cuts memory by 4× with typically less than a couple percent recall loss; binary cuts by 32× for coarse pre‑filtering followed by rerank. Cohere and Qdrant support this out of the box.
Practical recipe for large corpora: binary vectors for instant pre‑filtering, then rescoring with full or int8 vectors on the shortlist. RAM savings are dramatic, quality hardly suffers.
HOW TO CHOOSE FOR YOUR USE CASE: SHORT ALGORITHM
- Startup, MVP, needed yesterday: OpenAI text-embedding-3-small or Voyage — minimal infrastructure, pay per API.
- Russian/multilingual, own server: multilingual-e5-large or BGE-M3 + bge-reranker-v2-m3.
- Maximum quality, GPU available: Qwen3-Embedding-8B + Qwen3-Reranker.
- Huge corpus, saving: Matryoshka + int8/binary quantization, hybrid dense+sparse.
- Domain (code, legal, medical): first measure on your own eval; sometimes a specialized medium model beats a large generic one.
And I’ll repeat the main point: make your own mini‑benchmark of 100‑300 pairs. Any table, including this one, is just a starting point, not a verdict.
Frequently Asked Questions
Which embedding model is best for Russian language in 2026?
For a Russian corpus, a reliable default is multilingual-e5-large (don’t forget the query:/passage: prefixes). If the corpus is mixed or you need hybrid search — BGE-M3. For maximum quality with a GPU available — Qwen3-Embedding-4B/8B.
Is a reranker needed if I already have a good embedding model?
Almost always yes. A cross‑encoder reranker on top of the top‑50 candidates usually adds +10‑15 percentage points to recall@5 and is cheaper than moving to a larger encoder. This is the best way to boost RAG quality per unit cost.
Are open embeddings worse than proprietary APIs?
In 2026 the gap on retrieval tasks has practically disappeared. BGE‑M3, E5 and Qwen3‑Embedding compete with paid APIs. Proprietary solutions win mainly through ease of integration and specific domains, not absolute quality.
What vector dimension to choose?
For most tasks, 768-1024 is enough. If the corpus is large — use Matryoshka models and truncate to 256-512 with int8 quantization: memory drops significantly, quality hardly suffers.