A text embedding turns a piece of text into a list of numbers, so that texts with similar meaning end up with similar numbers. That one idea is what lets software search by meaning instead of by exact words.
What an embedding is
An embedding is a vector, a fixed-length list of numbers such as a few hundred or a few thousand values. A model produces it from the text. You can picture each text as a point in a space with that many dimensions, where texts about similar things sit near each other and unrelated texts sit far apart. The individual numbers are not human-readable, and only the distances between vectors carry meaning.
How similarity is measured
The usual measure is cosine similarity, which compares the direction of two vectors and ignores their length. A score near 1 means the vectors point the same way, and a score near 0 means they are unrelated. Some systems use dot product or Euclidean distance instead. If the vectors are scaled to the same length first, several of these measures give the same ranking, which echoes the scaling point in normalization vs standardization.
Where embeddings are used
Semantic search finds documents that match the meaning of a query, even when the words differ. Recommendation systems find items close to ones a user liked. Clustering groups similar texts without labels. And retrieval-augmented generation, usually shortened to RAG, uses embeddings to fetch the passages most relevant to a question before a language model answers it. You can see that pattern in my Knowledge-Base Search (RAG) project.
How search over embeddings works
At its core, searching embeddings is a nearest-neighbor problem: embed the query, then find the stored vectors closest to it. That is the same idea as k-nearest neighbors. Comparing a query against every stored vector gets slow at scale, so large systems use approximate nearest-neighbor indexes, often inside a vector database, which trade a little accuracy for a lot of speed.
Chunking matters
Long documents are usually split into smaller chunks before embedding, because one vector for a whole document blurs many topics together. Chunks that are too small lose context, and chunks that are too large dilute the match. There is no universal size, so test a few on your own questions and check whether the right passage comes back.
Limits to know about
- Vectors from different embedding models are not comparable, so you cannot mix them in one index.
- A model trained on general text may handle specialized vocabulary, such as legal or medical terms, less well.
- Similar does not mean true: a close match is relevant text, not verified fact.
- Changing the model means re-embedding everything you have stored.
Looking at embeddings
Because embeddings have many dimensions, people often reduce them to two for plotting, using methods like principal component analysis. Treat such plots as a rough view, since squeezing hundreds of dimensions into two loses information.
A quick checklist
- Are you using one embedding model for both the stored texts and the queries?
- Have you tested different chunk sizes on real questions?
- Do you evaluate retrieval by checking whether the right passage comes back?
- Do you know the cost of re-embedding if you change models?
- Are you treating a close match as relevant, not as proven true?
FAQ
What is a text embedding in simple terms?
It is a list of numbers that represents the meaning of a piece of text, so that texts with similar meanings have similar lists.
What is cosine similarity?
It is a score for how closely two vectors point in the same direction. Values near 1 mean very similar, and values near 0 mean unrelated.
Do I need a vector database to use embeddings?
Not for small collections. A simple in-memory comparison works for thousands of items, and a vector database or approximate index becomes useful as the collection grows.
