TL;DR
An embedding turns a piece of text into a vector — a list of numbers — such that similar meanings produce similar vectors. Cosine similarity measures how close two vectors point. Together they let you rank text by meaning, not by shared words. This is the engine that decides what's "relevant."
What an embedding is
An embedding is a list of numbers — a vector — that represents the meaning of a piece of text. The model that produces them was trained so that similar meanings produce similar vectors, and unrelated meanings produce dissimilar ones.
The platform uses a small, fast, local model, Xenova/all-MiniLM-L6-v2, which
outputs a 384-dimensional vector for any short text. You don't need the math — just
the property:
Texts that mean similar things land near each other in 384-D space. Texts that mean different things land far apart.
That's the whole engine.
Analogy
Imagine placing every sentence as a pin on an enormous map, where location encodes meaning rather than geography. "Cancel my subscription" and "stop my plan" land on the same street; "the capital of France" is in another country. Embeddings draw that map; similarity measures the distance between pins.
Cosine similarity in one paragraph
How do we measure "near"? The standard answer is cosine similarity: the cosine of the angle between two vectors. It ignores their magnitudes and measures only their direction.
- Two vectors pointing the same way → cosine = 1.0 (max similarity).
- Two perpendicular vectors → cosine = 0.0 (unrelated).
- Two opposite vectors → cosine = −1.0 (anti-correlated).
For the model we use, real scores fall in roughly the 0.2–0.85 range: two paraphrases of one sentence might score 0.85; a sentence and an unrelated one, around 0.1.
Try it yourself
The demo embeds a query and three candidate sentences with the same model the platform uses at ingest. Click Find closest — the ranking depends on meaning, not on word overlap.
Try candidates that share words but not meaning ("I refunded the cup of coffee I bought" vs. "How do I get a refund on my order?"). Word overlap doesn't dominate — meaning does.
Common mistake
Expecting embeddings to behave like keyword search. They rank by meaning, so they shine on paraphrases ("cancel" ≈ "stop my plan") but can miss exact tokens like "error code E-104" or "section 3.2", where the literal string is the point. Pairing embeddings with keyword search is exactly what Module 4's hybrid retrieval is for.
Key takeaways
Key takeaways
- An embedding is a vector whose position encodes a text's meaning.
- Cosine similarity scores how closely two vectors point (1.0 = identical meaning).
- Ranking by meaning beats word overlap for paraphrases and synonyms.
- Embeddings can miss exact tokens — Module 4 fixes that with hybrid search.
Go deeper: why the embedding model is fixed in the pipeline
In the lab the embedding model is shown fixed (annotation 4), not as a dropdown. That's deliberate, and it's a real production rule:
- Vectors are only comparable within one model. A query vector can only be matched against chunk vectors produced by the same model. Mixing models compares coordinates from two different maps — the numbers line up by accident, not by meaning.
- Swapping the model = re-embedding everything. Changing it isn't a per-query toggle; it means re-running ingest over the entire knowledge base so old and new vectors don't get compared. That's why you choose the model before you ingest.
- Choosing a model is a real decision. Dimensions (more = richer but slower and larger to store), speed, domain fit, and cost all trade off. A small local model like MiniLM is great for a lab; a larger hosted model may win on a specialized corpus.
Next lesson assembles chunking + embeddings into the full ingestion pipeline that builds your searchable index.