Embeddings: Turning Meaning into Searchable Geometry
📑 On this page
- A concrete example: account recovery
- From an item to a vector
- How the geometry is learned
- Similarity measures
- Embeddings are model-specific
- What should be embedded
- Metadata remains essential
- Embeddings beyond search
- The limits of “near”
- Bias and representation
- Privacy considerations
- Evaluate retrieval, not pretty clusters
- Operational versioning
- Hybrid search
- Knowledge check
- The one idea to remember
Keyword search asks whether two pieces of text contain matching terms. Semantic search asks whether they express related meaning.
Embeddings make that second question computationally practical.
An embedding is a learned numerical vector that places related items near one another in a high-dimensional space.
The vector is not a human-readable definition. It is a compact representation useful for comparison, retrieval, clustering, recommendation, and classification.
A concrete example: account recovery
A customer types: “I cannot get back into my profile.”
The help centre contains an article titled “Reset your password and restore account access.” Exact-word matching may miss it. An embedding model can place the query and article near each other because their learned meanings are related.
The system compares the query vector with stored article vectors and returns the closest approved results.
From an item to a vector
An embedding model accepts an input such as:
- a sentence,
- a document chunk,
- an image,
- a product,
- a user action sequence,
- or source code.
It returns an ordered list of numbers. A real vector may contain hundreds or thousands of dimensions. Individual dimensions usually do not map neatly to labels such as “sports” or “formal”; meaning is distributed across the representation.
How the geometry is learned
During training, the model sees relationships among examples. Depending on the objective, it learns to move related items closer and unrelated items farther apart.
Pairs might come from:
- query and clicked result,
- caption and image,
- question and answer,
- neighbouring passages,
- or human similarity labels.
The resulting geometry reflects the training data and objective, not a universal map of meaning.
Similarity measures
Systems commonly compare vectors with:
- cosine similarity,
- dot product,
- or Euclidean distance.
Cosine similarity emphasizes direction rather than raw magnitude. Dot product can combine direction and magnitude. The appropriate measure depends on how the embedding model was trained and normalized.
Use the model provider's recommended comparison rather than choosing by habit.
Embeddings are model-specific
Vectors produced by different embedding models do not normally share a coordinate system. Even two versions from the same family may be incompatible.
When changing models, re-embed the stored collection or run an explicit migration. Mixing old and new vectors can silently damage retrieval while every record still looks structurally valid.
What should be embedded
Embedding quality depends on the unit being represented.
For documents, a whole book is too broad for a specific question, while a single sentence may omit necessary context. Useful chunks often align with sections, paragraphs, procedures, or table regions.
Include meaningful titles or headings when they clarify the chunk, but avoid repeated navigation text that makes unrelated pages appear similar.
Metadata remains essential
Similarity alone cannot answer every condition. Store metadata alongside each vector:
- source identifier,
- document title,
- section,
- language,
- publication date,
- product,
- tenant,
- permissions,
- and status.
A search can first filter to documents the user may access, then rank the remaining candidates by similarity.
Embeddings beyond search
The same representation can support:
- clustering related feedback,
- finding duplicate tickets,
- recommending similar products,
- matching candidates to jobs,
- detecting unusual items,
- and using vectors as features in another model.
Each use needs separate evaluation. A vector suitable for general text similarity may not capture the distinctions that matter in medical coding or legal precedent.
The limits of “near”
Nearby does not mean factually equivalent, safe, current, or authorized.
Two articles may be semantically similar but apply to different countries. A query about stopping a medication may retrieve text about starting it because the vocabulary overlaps. A deprecated procedure may be closer than the current one.
Metadata filters, reranking, source quality, and downstream validation remain necessary.
Bias and representation
Embedding spaces can reproduce associations present in training data. They may underperform for languages, dialects, names, or domains with weak representation.
Test retrieval by subgroup and task category. Do not rely only on an average similarity score. Inspect which relevant items are absent and which harmful associations appear.
Privacy considerations
An embedding is not automatically anonymous. Vectors can preserve sensitive relationships, and an attacker may infer information through access patterns or model-specific attacks.
Apply the same controls used for source data:
- purpose limitation,
- tenant isolation,
- encryption,
- retention,
- deletion,
- access logging,
- and data minimization.
Deleting a document should also remove its vectors, cached results, and derived indexes according to policy.
Evaluate retrieval, not pretty clusters
Build a representative query set with known relevant results. Measure:
- recall at a chosen result count,
- ranking quality,
- irrelevant-result rate,
- performance by language or category,
- latency,
- and behavior on no-answer queries.
Human reviewers should judge whether retrieved items actually help complete the user task. An embedding demo with a few handpicked examples is not a production evaluation.
Operational versioning
Track:
- embedding model and version,
- preprocessing rules,
- chunking version,
- vector dimension,
- normalization,
- creation time,
- and source content version.
Without this lineage, teams cannot explain why a search result changed or safely rebuild an index.
Hybrid search
Semantic and keyword search solve different problems. Embeddings are strong for paraphrases and concepts. Keywords are strong for exact identifiers, names, error codes, and quoted phrases.
Hybrid systems combine both scores and may rerank the candidates with a stronger model. This often performs better than insisting that one retrieval method handle every query.
Knowledge check
- What relationship does an embedding vector represent?
- Why should vectors from different models not be mixed?
- What role does metadata play in semantic search?
- Why does vector similarity not guarantee factual equivalence?
- How would you evaluate an embedding-based search system?
The one idea to remember
Embeddings turn learned relationships into geometry so systems can compare items by meaning. Their value depends on the model, chunking, similarity method, metadata, permissions, evaluation set, and operational versioning around the vectors.