What Embeddings Are

Why Embeddings Exist

Suppose a user asks, "How do I rotate an API credential?" The document says, "Regenerate the access key and update dependent services." A pure keyword search may struggle because "rotate" and "regenerate" are different words. Embeddings help because they can place related ideas near each other.

Real-Life Analogy: Google Maps for Meaning

Think of embeddings like a map. Restaurants are near other restaurants. Hospitals are near health services. Airports are near travel locations. If you search for "food near me," the map does not match only the word "food"; it understands related places.

Embeddings create a similar map for meaning. "Password reset," "credential rotation," and "access key regeneration" may live near each other because they are conceptually related.

Mental Model

A vector is just a list of numbers. In simple examples, we can imagine two or three dimensions. In real embedding models, vectors often have hundreds or thousands of dimensions.

"reset password"      -> [0.82, 0.10, 0.44]
"change credentials"  -> [0.79, 0.13, 0.41]
"quarterly revenue"   -> [0.05, 0.91, 0.22]

The first two vectors are close because the meanings are related. The revenue vector is far away because it talks about a different topic.

Technical Explanation

An embedding model reads input and returns a fixed-length numeric vector. Fixed length matters because every chunk and query must live in the same vector space to be compared.

Similarity

Similarity is how we measure closeness between vectors. Common approaches include cosine similarity, dot product, and Euclidean distance.

same direction      -> high similarity
opposite direction  -> low similarity
unrelated direction -> weak similarity

Dense vs Sparse Intuition

Embeddings are often called dense vectors because most dimensions contain some value. Traditional keyword systems such as TF-IDF or BM25 are sparse because most vocabulary dimensions are zero for a document.

Architecture View

documents
  -> chunks
  -> embedding model
  -> vectors + metadata in vector store

user question
  -> same embedding model
  -> query vector
  -> similarity search
  -> top chunks
  -> grounded answer

Practical Example

The course project stays dependency-light, so this chapter uses a tiny local vector example to teach similarity. It is not a replacement for a real embedding model, but it makes the mechanics visible.

from math import sqrt

def cosine(a, b):
    dot = sum(x * y for x, y in zip(a, b))
    left = sqrt(sum(x * x for x in a))
    right = sqrt(sum(y * y for y in b))
    return dot / (left * right)

query = [0.80, 0.12, 0.40]
chunk = [0.78, 0.11, 0.42]
print(round(cosine(query, chunk), 3))

In real systems, the embedding model creates the vectors. Your job as an engineer is to choose the model, store vectors correctly, evaluate retrieval, and know when similarity is misleading.

Production Considerations

Common Mistakes

Interview-Level Understanding

A strong answer sounds like this: "Embeddings represent text as vectors so semantically related chunks can be found by similarity. In RAG, we embed chunks at index time and embed the query at runtime. But vector similarity is only a candidate-generation step; we still need metadata filters, reranking, citations, freshness controls, and evals."

Mini Assignment

Choose five pairs of sentences from your domain. Label each pair as exact match, semantic match, related but unsafe, or unrelated. Then explain whether sparse, dense, or hybrid retrieval should handle each pair and why.