08 - Embeddings¶

Embeddings represent content as numeric vectors so that semantically similar items can be compared mathematically.

They are a foundation for semantic search, clustering, recommendations, deduplication, and RAG retrieval.

Core mental model¶

An embedding model transforms an input into a vector:

"How do I reset my password?"
        |
        v
embedding model
        |
        v
[0.12, -0.31, 0.88, ...]

Another sentence with similar meaning should map to a nearby region of vector space:

"I forgot my password and need a new one"

The exact numbers are not meaningful to humans. Their relative positions are.

Why embeddings are useful¶

Keyword search looks for matching terms. Embedding search tries to capture meaning.

Example:

Query:
"car will not start"

Document:
"vehicle ignition troubleshooting"

The two texts may share almost no exact words, but a good embedding model can still place them close together.

Similarity¶

A similarity function compares vectors. Common approaches include cosine similarity, dot product, and Euclidean distance.

You do not usually manipulate vector dimensions manually. The important application concept is:

query embedding
       |
compare against stored embeddings
       |
rank nearest items

Semantic search pipeline¶

A simplified search system:

Documents
   |
chunk / prepare
   |
embedding model
   |
store vectors + metadata

User query
   |
embedding model
   |
vector similarity search
   |
Top matching documents

This becomes one of the core building blocks of RAG.

Embeddings are not summaries¶

An embedding does not contain readable compressed text that can later be decoded back into the original document.

Think of it as a coordinate useful for comparison, not as compressed document storage.

You still need to store the original content or a reference to it.

Embeddings are model-specific¶

Vectors from different embedding models generally should not be mixed in the same index.

If you change embedding model, documents usually need to be re-embedded.

This means embedding-model choice becomes part of your data architecture.

Dimensions¶

Embedding vectors may contain hundreds or thousands of numeric dimensions.

More dimensions do not automatically mean better retrieval. Quality depends on the model, domain, data, and evaluation.

Chunking matters¶

Suppose you embed an entire 100-page manual as one vector. A query about a small paragraph may not match well because the vector represents the document as a whole.

Instead, content is often split into smaller units:

Manual
  |
  +--> chunk 1 -> vector
  +--> chunk 2 -> vector
  +--> chunk 3 -> vector

Chunking strategy strongly influences retrieval quality and will be covered more deeply in RAG.

Metadata still matters¶

Vector similarity alone is not enough for many applications.

Example document record:

{
  "id": "doc-123",
  "team": "payments",
  "version": "7.2",
  "language": "en",
  "embedding": [0.12, -0.31, 0.88]
}

A search can combine semantic similarity with filters:

semantic match
AND team = payments
AND version = 7.2

This is often safer and more accurate than pure vector search.

Similarity does not mean truth¶

The nearest vector is simply the most similar item among those searched. It does not guarantee that the document:

answers the question,
is correct,
is current,
is authorized for the user.

Retrieval results still need application-level filtering and evaluation.

Example: internal documentation search¶

Suppose a developer asks:

"Why is our build failing after the Java upgrade?"

The application could embed the query and retrieve chunks from:

Java migration guide,
build troubleshooting notes,
Maven/Tycho documentation,
previous incident summaries.

The retrieved text can then be passed to an LLM to synthesize an answer.

query
  |
embedding
  |
semantic retrieval
  |
relevant text
  |
LLM
  |
answer

Other use cases¶

Clustering¶

Group semantically related documents or support tickets without predefined labels.

Recommendations¶

Find products, articles, jobs, or content similar to what a user has interacted with.

Deduplication¶

Detect near-duplicate content even when wording differs.

Classification support¶

Compare an input embedding with known category examples or centroids.

Vector databases¶

A vector database or vector-capable search engine stores embeddings and performs efficient nearest-neighbor search.

The important foundation concept is not which product to use. It is the responsibility split:

embedding model -> creates vectors
vector store     -> indexes and searches vectors
application      -> filters, validates, retrieves original content
LLM              -> optionally reasons over retrieved content

Hybrid search¶

Semantic search and keyword search solve different problems.

A strong retrieval system may combine:

keyword/BM25 score
        +
vector similarity
        +
metadata filters
        +
reranking

This is called hybrid retrieval and will matter later in RAG.

Evaluation¶

Never assume semantic search is good because example queries look impressive.

Create a small retrieval evaluation set:

query -> expected relevant documents

Then measure whether the correct documents appear near the top.

Developer takeaway¶

Embeddings turn semantic similarity into something software can search and rank.

They are powerful, but they do not replace source documents, permissions, metadata, keyword search, or evaluation. Treat them as one retrieval signal inside a larger system.