TL;DR: An embedding model turns a piece of text into a vector - a fixed-length list of numbers - such that texts with similar meaning get vectors that sit close together. Every semantic search box and every RAG pipeline stands on one of these models, and swapping it changes retrieval quality more than almost any other knob.
How it works
Feed the model "the cat sat on the mat" and it returns something like 1,024 floating-point numbers. Feed it "a kitten rested on the rug" and it returns a different 1,024 numbers - but ones that are measurably close to the first set, because the model was trained so that paraphrases, translations, and related passages land near each other in this space. The underlying embedding idea is general: the same trick works for images, audio, and code, which is how "search my photos for beach sunsets" works with no tags.
Training typically uses contrastive learning: show the model pairs that belong together (a question and its answer, a title and its article) and pairs that do not, and adjust it until the first kind ends up close and the second kind far apart. What counts as "belonging together" is baked in by the training data - which is why a model tuned on web prose can stumble on legal contracts, medical notes, or source code, and why domain fit beats leaderboard rank.
Choosing a model involves a few concrete trade-offs. Dimension count (commonly 256 to 3,072) trades storage and query speed against nuance. Maximum input length decides how large your chunks can be before text is silently truncated. Hosted APIs remove operations work but put a network call and a per-token price in your ingestion path; open-weight models run wherever you like, including entirely on your own hardware for private data. Public benchmarks such as MTEB are a reasonable starting shortlist, but a small evaluation set built from your own queries and documents is worth more than any leaderboard.
One operational rule matters above all: query vectors are only comparable to document vectors from the same model. Switching models - even to a newer version of the same family - means re-embedding the entire corpus. Plan for that from day one by keeping raw text and making re-indexing a routine pipeline run rather than an emergency.
Where it sits in the AI stack
The embedding model is the translation layer between raw content and the vector index. It runs twice: over every chunk at indexing time, and over every query at search time:
Everything a vector database stores came out of this model, so its choice quietly sets the ceiling for the whole retrieval stack.
Key tools and implementations
-
OpenAI embeddings
Widely used hosted embedding APIs with adjustable output dimensions.
-
Sentence-transformers
The standard open-source library for running embedding models locally, with hundreds of checkpoints.
-
Cohere Embed
Hosted embeddings with strong multilingual support and retrieval-tuned variants.
-
Open-weight families (BGE, GTE, Nomic)
Self-hostable models that keep private data on your own infrastructure.
Related entries
- Embedding A list of numbers capturing a piece of content's meaning, so similar things sit close together in vector space.
- Vector database A database that stores embeddings and finds nearest neighbors fast, powering semantic search and RAG.
- Semantic search Search that ranks results by meaning, using embeddings, so matches do not require the exact words.
- Chunking Splitting documents into smaller pieces so each one can be embedded and retrieved on its own.