Glossary · Data & RAG
Embeddings
An embedding is a list of numbers that represents the meaning of text or other data, positioning similar items close together in a high-dimensional space so software can compare them.
An embedding is a list of numbers that represents the meaning of text, an image, or other data, positioning similar items close together and dissimilar ones far apart in a high-dimensional space. Embeddings let software compare content by meaning, and they are the foundation of vector search and RAG.
- An embedding turns meaning into a vector so software can compare content numerically.
- Similar meanings produce nearby vectors; unrelated meanings produce distant ones.
- Embeddings are the foundation of vector search and RAG.
- Index-time and query-time embeddings must come from the same model.
- Changing the embedding model forces a full, and often costly, re-index.
Also known as: vector embedding, text embedding
An embedding is a list of numbers that represents the meaning of text or other data, positioning similar items close together in a high-dimensional space so software can compare them.
Run a sentence through an embedding model and you get a vector: say 1,536 numbers. Sentences that mean similar things produce vectors that sit near each other; unrelated sentences produce vectors far apart. Meaning becomes arithmetic.
How embeddings work
An embedding model is trained so that semantic similarity maps to geometric closeness. Feed it a chunk of text and it returns a fixed-length vector; the number of values, the dimensions, is set by the model. Because similar meanings land close together, you can measure how related two pieces of content are by comparing their vectors, typically with cosine similarity.
That single property is what powers vector search and, through it, retrieval-augmented generation. Index every document as an embedding, embed an incoming query with the same model, and finding relevant material becomes finding nearby vectors. The critical constraint is that constant: index-time and query-time embeddings must come from the same model, because different models place meaning in different coordinate systems that cannot be compared.
Why embeddings matter for enterprise AI adoption
Embeddings are the quiet foundation under most useful enterprise AI. Every semantic search box, every grounded assistant, every "find me the policy that covers this" feature is comparing embeddings underneath. Get them right and retrieval feels like understanding; get them wrong and the whole pipeline above them retrieves the wrong passages no matter how good the model on top is.
They also carry an operational cost that teams routinely miss. Because switching embedding models means re-embedding the entire corpus, the choice of model is a longer-lived commitment than it looks, and the re-index is a real migration with real compute cost. Planning for that up front (rather than discovering it when relevance collapses after a well-meaning model upgrade) is part of running retrieval like production infrastructure instead of a demo.
Common mistakes with embeddings
The first mistake is treating an embedding-model change as a configuration tweak. It is a full re-index; skip it and you compare fresh queries against stale vectors, and relevance silently degrades. The second is chasing dimensions: assuming a larger vector is always better, when past a point it only adds storage and latency for no retrieval gain.
The third is never measuring. Embeddings sit invisibly under search, so a quietly bad embedding choice looks like a model problem or a prompt problem, and teams tune the wrong layer. Put retrieval into an evaluation harness so the embedding layer is measured on recall like anything else.
Related terms
- Vector search: comparing embeddings to retrieve by meaning.
- Retrieval-augmented generation: the pipeline embeddings feed.
- Model Context Protocol: a way to expose embedding-based retrieval to a model.
How Chokmah approaches embeddings
We treat the embedding layer as infrastructure, not a setting. In a workflow sprint we choose an embedding model against measured recall on the client's own documents, size storage and latency for the dimensions that model produces, and write the re-index into the plan so a future model change is budgeted rather than feared. Because retrieval quality is invisible until it fails, we baseline it early and keep it in the evaluation harness.
Sources
- MIT NANDA, The GenAI Divide: State of AI in Business 2025, July 2025. https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf
Related terms
- Vector searchVector search retrieves information by comparing numerical embeddings for semantic similarity, finding passages that mean the same thing as a query rather than sharing its exact keywords.
- Retrieval-augmented generation (RAG)Retrieval-augmented generation (RAG) is a technique that fetches relevant passages from your own documents and supplies them to a language model as grounding before it generates an answer.
- Model Context Protocol (MCP)The Model Context Protocol (MCP) is an open standard that defines how AI applications connect to external tools and data through one uniform interface instead of many bespoke integrations.
Where it shows up in our work
Frequently asked questions
An embedding is a way of turning a piece of text (or an image, or audio) into a list of numbers that captures its meaning. Content with similar meaning gets similar numbers, so a computer can measure how related two things are by comparing their lists. It is how software moves from matching exact words to comparing ideas, which is what makes semantic search and grounded AI answers possible.
Dimensions are how many numbers are in the list: a 1,536-dimension embedding is a list of 1,536 values. More dimensions can capture finer distinctions but cost more to store and compare, and beyond a point add little. The dimension count is fixed by the embedding model you choose, so it is a property to plan storage and latency around rather than a dial you tune per document.
Embeddings are only comparable if they come from the same model. Different models place meaning in different coordinate systems, so a query embedded with model B cannot be meaningfully compared against documents embedded with model A. To switch models you must re-embed every document in the index. For a large corpus that is real compute time and cost, which is why an embedding-model change is a planned migration, not a quick swap.
The vectors themselves do not change, but their usefulness can degrade. If the meaning of your terms shifts, if you add a large body of new-domain content the old model represents poorly, or if you upgrade the model without re-indexing, retrieval quality falls. Treating embeddings as a set-and-forget artefact is the trap; they are part of a pipeline that needs the same measurement and maintenance as any other.
Put the concept to work
We install working agentic workflows, not vocabulary. Book a free AI Reality Check.