An embedding is a list of numbers that captures the meaning of a piece of text. Two passages about the same topic produce vectors that sit near each other; unrelated passages sit far apart. That single property — meaning as distance — is what makes semantic search and RAG possible.
Why it matters in production
Your embedding model sets the ceiling on retrieval quality. If it maps "cancel my subscription" and "how do I unsubscribe" to distant vectors, no amount of downstream cleverness recovers the match. Everything after retrieval — reranking, prompting, generation — can only work with what the embedding step surfaced.
The common mistake
Two mistakes recur. First, mixing embedding models: vectors from model A are not comparable to vectors from model B, so re-embedding your whole corpus is mandatory when you switch — a migration people forget to plan for, much like a model migration. Second, embedding the wrong unit of text. Embed a 5,000-word page as one vector and you get a blurry average that matches everything and retrieves nothing precisely; that is why chunking exists.
How we actually use it
We pick an embedding model, lock it, and treat re-embedding as a deliberate migration event. We embed at chunk granularity, store the vectors in a vector database, and validate that "questions we expect to answer" actually retrieve the passages that answer them — measured, not assumed, following the same discipline we describe in how RAG works in production.