The invisible foundation
Every RAG system, every semantic search engine, every classification pipeline built on embeddings depends on one component that rarely gets the attention it deserves: the embedding model.
The embedding model converts text into dense vectors that capture meaning. The quality of those vectors determines how well your retrieval works, how accurately your classifier performs, and how relevant your search results are. A great language model paired with a poor embedding model will produce mediocre results — because the model only sees what retrieval surfaces.
Your RAG system is only as good as your embedding model. The language model can't reason over documents it never sees.
What makes a good embedding model
Semantic fidelity
The most important quality: similar meanings should produce similar vectors, and different meanings should produce different vectors. This sounds obvious but varies dramatically across models. Some models encode surface-level similarity (matching keywords), while others capture deeper semantic relationships (matching concepts).
Dimensionality vs. cost trade-off
Higher-dimensional embeddings capture more information but cost more to store and search. Modern models offer embeddings from 384 to 3072 dimensions. For most production use cases, 768–1024 dimensions offer the best balance. Going higher provides diminishing returns; going lower saves significant storage cost with modest quality loss.
Domain alignment
General-purpose embedding models are trained on diverse internet text. If your domain uses specialized vocabulary — medical, legal, financial, technical — a general model may not represent domain-specific terms well. This is where domain-specific models or fine-tuned embeddings make a noticeable difference.
Multilingual capability
If your content spans multiple languages, you need an embedding model trained for cross-lingual retrieval. Not all "multilingual" models are equally capable; performance varies significantly across language pairs.
Choosing an embedding model in 2026
The embedding model landscape has matured. Here's a practical categorization:
API-based options — Models from OpenAI, Cohere, Voyage, and others offer strong general-purpose performance with zero operational overhead. Best for teams that want simplicity and don't need fine-tuning.
Open models — Models like BGE, GTE, E5, and Nomic offer comparable quality with self-hosting flexibility and fine-tuning capability. Best for teams with domain-specific needs or data sovereignty requirements.
Specialized models — Domain-specific embedding models trained on medical, legal, or scientific text. Worth evaluating if your domain is narrow and performance on general benchmarks doesn't predict your task well.
Fine-tuning embeddings: when and how
Fine-tuning an embedding model on your domain data can improve retrieval quality by 10–20% on domain-specific queries. The improvement is most noticeable when your domain vocabulary differs significantly from general web text.
What you need: a set of (query, positive_document, negative_document) triplets from your domain. Typically 5,000–10,000 triplets produce meaningful improvement. The queries should represent what your users actually search for, the positive documents should be the ones that genuinely answer those queries, and the negative documents should be "hard negatives" — documents that are superficially similar but don't actually answer the query.
The training is computationally modest compared to language model fine-tuning. A single GPU can fine-tune most embedding models in a few hours.
Common embedding pitfalls
Ignoring input length limits
Every embedding model has a maximum input length. Text beyond this limit is silently truncated, which means the embedding doesn't represent the full content. For documents longer than the limit, you need a chunking strategy that preserves meaningful units of information.
Using the wrong similarity metric
Some models are designed for cosine similarity; others for dot product. Using the wrong metric degrades retrieval quality. Check the model documentation and match your vector database's distance function accordingly.
Not refreshing embeddings
When you switch embedding models — even to a newer version from the same provider — all existing embeddings become incompatible. You need to re-embed your entire corpus. Budget for this when planning model upgrades.
Embedding queries and documents the same way
Some embedding models are asymmetric: they expect different prefixes or formatting for queries vs. documents. Using the wrong mode reduces retrieval quality. Read the model's documentation and use the appropriate encoding for each.
Evaluation methodology
To evaluate embedding quality for your use case:
- Collect a set of 200+ real queries from your application
- For each query, identify the 1–5 documents that should be retrieved (human-annotated)
- Run retrieval with your embedding model and measure Recall@10 and MRR
- Compare across candidate embedding models
- Evaluate both in-domain queries and edge cases
This evaluation takes a day to set up and an hour to run per model — a tiny investment that prevents months of working with the wrong embedding model.
The teams that get the most out of their AI systems are the ones that treat embedding quality as a first-class concern, not an afterthought.