AI & Development
Embedding models convert text into numerical vectors for semantic search, RAG, and clustering. Learn how to choose the right model, understand its
An embedding model converts text - a word, a sentence, a paragraph, or a document - into a dense numerical vector. This vector captures the semantic content of the text in a way that allows mathematical operations on meaning: texts with similar meaning have vectors that are close together in the high-dimensional embedding space, and texts with different meaning have vectors that are far apart. This simple property is the foundation of semantic search, retrieval-augmented generation, text clustering, duplicate detection, and a host of other AI applications.
Embedding models vary across several dimensions that determine their fit for a given use case. Embedding dimension is the length of the output vector - 768, 1536, 3072, or more dimensions. Higher dimensions can encode more information but cost more to store and compare. Maximum input length determines how long a piece of text can be embedded in a single call - embedding models have their own context limits, typically ranging from 512 to 8192 tokens. Texts longer than the limit must be chunked before embedding.
Quality is the most important dimension and the hardest to assess without testing. Embedding quality is usually measured by performance on retrieval benchmarks (MTEB is the standard). However, benchmark performance on general text does not always correlate with performance on your specific domain and language. Evaluating candidate models on a sample of your actual data before committing is the right practice.
OpenAI's text-embedding-3-small and text-embedding-3-large are the most widely used API-based embedding models. text-embedding-3-small (1536 dimensions, priced very low) provides strong quality for most general-purpose applications. text-embedding-3-large (3072 dimensions) provides higher quality at higher cost and storage requirements. Both support Matryoshka Representation Learning, which allows you to truncate the embedding vectors to smaller sizes (256, 512, 1024 dimensions) with a proportional reduction in quality - useful for optimizing storage at scale.
Cohere's embed-v3 family offers strong multilingual support (100+ languages) and a specific embedding mode for query vs. document embedding, which improves retrieval quality for asymmetric search (short query, long document). This is the right choice for multilingual RAG applications.
For self-hosted or privacy-sensitive applications, sentence-transformers models (BAAI/bge-m3, intfloat/e5-large-v2) run locally and offer strong quality competitive with API-based models of similar size. Running embedding models locally eliminates API cost and data privacy concerns.
Many embedding tasks are symmetric - you embed both the query and the documents using the same model with the same parameters, and search for nearest neighbors. But retrieval search is typically asymmetric: a short query is being matched against longer documents. Some embedding models - particularly Cohere's - offer separate encoding modes for queries and documents, optimizing each for the asymmetric retrieval case. Using a model that supports asymmetric encoding for RAG retrieval consistently improves recall compared to symmetric embedding.
Once you have embedded a large document collection, changing the embedding model requires re-embedding the entire collection. This is expensive in both compute and time. Choosing an embedding model that is stable (unlikely to change in ways that break compatibility), widely supported (available across providers if you need to change inference providers), and appropriate for your expected scale is a decision with long-term consequences.
The risk of embedding model deprecation is real: OpenAI deprecated its older embedding models, requiring applications to re-embed their data. Building an abstraction layer that makes the embedding model swappable, and maintaining a migration script for re-embedding, protects you from being stranded on a deprecated model. The cost of this abstraction is minimal; the value when a migration is eventually needed is substantial.