What is an embedding?

You paste a support ticket into a “smart search” box: “customer cannot export CSV after SSO login.” The tool returns three old tickets and a runbook paragraph that actually help. It did not keyword-match every word. It matched meaning, roughly. Under the hood, both your query and those documents were turned into long lists of numbers. Those lists are embeddings.

Embeddings sound mystical until you treat them as a practical encoding: a model maps text (or images, audio, and more) into a vector space where “nearby” means “related for this model’s training objective.” They power semantic search, clustering, recommendations, and the retrieval half of RAG. They do not replace reading the source, validating SQL, or owning metric definitions. They are a similarity tool with failure modes you can learn.

This Key Terms deep dive is a one-shot plain-English guide for analytics and data people. You will leave able to explain embeddings in a meeting, know what cosine similarity is doing, and connect the idea to vector databases and RAG without drowning in linear algebra. For storage and indexes, see Getting up to speed on vector databases. For model basics, see What are LLMs?. For grounded answer patterns, the Practical AI series covers RAG in workplace terms.

What you’ll learn

What an embedding is in one breath, without pretending you derived the math
Why “closer vectors” is useful for search and clustering
How text becomes vectors, gets stored, and gets retrieved
Common workplace uses: semantic search, RAG, deduping, recommendations
Limits: bias, domain drift, junk in / junk near, not a knowledge base alone
A small worked sketch plus practice steps you can run this week

Embedding in one breath

An embedding is a vector (a list of floating-point numbers) produced by a model to represent a piece of content. OpenAI’s docs put it bluntly: text embeddings measure relatedness of text strings; the distance between two vectors measures how related they are for that embedding model. Similar meaning tends to land nearby. Unrelated text lands farther away. Dimension counts are often hundreds or thousands of numbers per item (exact size depends on the model).

You do not hand-author those numbers. You call an embedding model (API or local) with text in; you get a vector out. The same model should embed both your documents and your queries so they live in the same space. Mixing models without a plan is like measuring in inches and centimeters and arguing about the tape.

Rule of thumb: An embedding is a lossy map of meaning for similarity tasks. It is not a citation, a fact store, or a guarantee of truth.

The intuition (maps, not magic)

Imagine every support article pinned on a huge multi-dimensional map. Articles about SSO land in one neighborhood. Articles about CSV export land in another. A ticket about “SSO then export fails” may sit between them or near a known incident cluster. Retrieval finds neighbors of the query pin. That is the geometric story people mean by “semantic search.”

Two important caveats sit inside the metaphor:

The map is model-specific. Retrain or swap models and neighborhoods move. Re-embed when you change models.
Nearby is not “true.” Two wrong policies can be near each other. Marketing copy can sit near a legal definition. Humans still decide.

Concept diagram of text chunks mapped into an embedding vector space with a query vector retrieving nearest neighbors

From text to vectors to “search”

A typical analytics-adjacent pipeline:

Collect content: wiki pages, metric cards, tickets, PDF extracts (with care for privacy).
Chunk: split long docs so each vector represents a usable passage, not a 40-page blob.
Embed: send each chunk through the embedding model; store the vector plus metadata (source URL, product line, updated_at).
Index: put vectors in a vector database or similar index for nearest-neighbor lookup. Keyword search can sit beside it (hybrid).
Query: embed the user question; find top-k neighbors; return chunks (and maybe pass them to an LLM for a written answer).

Steps 3 and 4 are where “embeddings” and “vector databases” meet. The embedding is the representation. The vector store is the filing cabinet optimized for “find nearest.” Details of indexes (HNSW and friends) matter for scale; the product idea does not change. AMS covers the cabinet side in the vector databases post linked above.

Similarity in practice

Systems compare vectors with distance or similarity functions. Cosine similarity is common for text embeddings: it cares about angle more than raw length, which fits “direction of meaning.” Providers document which distance their models expect; follow their guide. You rarely implement this by hand in day-one prototypes, but you should know that “score 0.82” is not a universal truth meter. It is relative within a model and corpus.

What people use embeddings for at work

Use case	What embeddings do	What still needs humans or other systems
Semantic search	Rank passages by meaning, not only keywords	Permissions, freshness, source of truth labels
RAG retrieval	Pick context chunks for an LLM prompt	Grounding checks, citations, evals
Deduping / clustering	Group similar tickets or survey responses	Cluster labels, action rules
Recommendations	Find similar items or users in vector space	Business constraints, fairness, inventory
Anomaly hints	Flag texts far from a normal cluster	Investigation; outliers can be rare truths

Notice what is missing: “store the official revenue definition as a vector and trust the nearest neighbor as Finance.” Metric truth still wants a semantic layer, a metric card, or a governed table, not vibes-based geometry.

Infographic of workplace embedding uses: semantic search, RAG retrieval, clustering, and recommendations with a cauti…

Worked sketch: three metric blurbs

Suppose your wiki has three short definitions (toy text, not your real policy):

A: “Active customer: logged in at least once in the last 28 days.”
B: “Active customer: completed a paid order in the last 28 days.”
C: “Warehouse slotting: how we place SKUs in aisles for pick efficiency.”

You embed A, B, and C. A and B should sit nearer each other than either sits to C, because both discuss “active customer,” even though they disagree on the rule. A query “What is an active customer?” should retrieve A and B near the top. That is useful: you surface the conflict. It is also dangerous: an LLM asked to “answer from context” might blend A and B into a fluent hybrid that Finance never approved.

Pseudo-flow (not a production client):

# Pseudocode: embed docs and a query, rank by cosine similarity
docs = {
  "A": "Active customer: logged in at least once in the last 28 days.",
  "B": "Active customer: completed a paid order in the last 28 days.",
  "C": "Warehouse slotting: how we place SKUs in aisles for pick efficiency.",
}

doc_vecs = {k: embed(text) for k, text in docs.items()}
q = embed("What is an active customer?")

ranked = sorted(
  doc_vecs.keys(),
  key=lambda k: cosine_similarity(q, doc_vecs[k]),
  reverse=True,
)
# Expect something like ["A", "B", "C"] or ["B", "A", "C"]
print(ranked)

What you should do with the result: open A and B, resolve the definition in a metric card, and point search metadata at the winning source. Embeddings helped you find the fight. They did not win it.

Chunking, metadata, and hybrid search

Bad chunking creates bad neighbors. If you embed an entire handbook as one vector, queries about one policy get a diluted average of everything. If you chunk too small, you lose the sentence that held the exception. Practical defaults: split on headings, keep a few hundred to a couple thousand tokens per chunk depending on model limits, and store parent titles in metadata so you can show “from: Revenue policy / Refunds.”

Metadata filters matter as much as vectors. Restrict to product=mobile or doc_type=metric_card before or after vector search so you do not retrieve a deprecated PDF. Hybrid search (keyword + vector) helps on SKUs, error codes, and exact metric names where pure semantics get cute and miss the string ARR_GROSS.

Limits and failure modes

Similarity ≠ permission. Nearest neighbor can surface docs the user should not see if you skip ACL filters.
Stale vectors. Content updated, embeddings not refreshed: search returns yesterday’s policy with today’s title.
Domain shift. General models may map your internal jargon poorly until you choose better models, fine-tune (rare for embeddings at many companies), or improve document text.
Polysemy. “Python” the language vs snake vs project codename can collide without metadata.
Adversarial or junk text. Garbage in still embeds somewhere; retrieval can rank confident nonsense if that is what you indexed.
Over-trust in RAG. Retrieved chunks can be wrong; the LLM may still sound sure. Pair with evals from the Practical AI series.

How embeddings relate to LLMs (and how they differ)

Large language models generate tokens. Embedding models map inputs to fixed vectors for comparison. Some vendors offer both. Many systems use a smaller specialized embedding model for retrieval and a larger generative model for answers. Do not assume the chatbot “has embeddings” of your private wiki unless you built a retrieval pipeline. Training memorization is not the same as your vector index.

Fine-tuning a generative model also is not the same as embedding your docs. Fine-tuning changes generation behavior; embeddings power lookup. The next Key Term in this batch (fine-tuning vs RAG) separates those paths cleanly.

Common mistakes

One giant chunk per PDF and wondering why retrieval is mushy.
Re-embedding only half the corpus after a model upgrade.
No metadata filters, so legal drafts rank next to customer FAQs.
Treating similarity scores as probabilities of truth.
Indexing secrets (API keys, private tickets) into a shared vector store.
Skipping hybrid search when users query exact IDs and codes.
Expecting embeddings to fix conflicting metric definitions without governance.

How to practice

Write a 60-second explanation of embeddings for a non-ML stakeholder. Use the map metaphor once. Avoid “AI understands.”
Pick ten internal doc titles. Guess which pairs should be nearest. If you have a search tool with semantic mode, check whether reality matches. Note surprises.
Read your vector DB or search vendor’s note on distance metrics and embedding model versions. Write down the model name your org uses.
Add a freshness field to any retrieval prototype: show updated_at next to each hit. Make staleness visible.
For any AI-written SQL that came from “docs search,” still run the AMS AI SQL checks. Retrieval does not certify joins.

Quick recap

Embeddings turn content into vectors so related items can be found by proximity.
Same embedding model for docs and queries; re-embed when the model changes.
Chunking, metadata, and hybrid search decide whether neighbors are useful.
Use cases: semantic search, RAG retrieval, clustering, recommendations.
Similarity is not truth, permission, or a metric definition. Keep humans and governance in the loop.

Once you see embeddings as a similarity layer, a lot of AI product demos get less mysterious. The hard work moves back where analytics people already live: clean sources, clear definitions, permissions, and evals.

Sources

Further reading and references used for this article:

OpenAI, vector embeddings guide: https://platform.openai.com/docs/guides/embeddings
OpenAI API embeddings resource reference: https://platform.openai.com/docs/api-reference/embeddings
AMS: Vector databases, What are LLMs?, Practical AI series, How to check AI-written SQL, Learn