Kognita
All posts
Engineering2026-06-19·8 min read

Vector embeddings explained for non-ML engineers

No linear algebra, no neural network diagrams. Just an intuition for what an embedding actually is, why 'similar things end up close together' is the whole trick, and how that powers semantic search.

You keep hearing that embeddings power semantic search, RAG, and recommendations. You do not need a machine-learning background to understand them. You need one idea: turn meaning into coordinates, then use distance to measure similarity.

Start with a map

Imagine plotting cities on a grid by two numbers: how far north and how far east each one is. Now cities near each other on the map are near each other in real life. You've encoded a real-world relationship into coordinates, and "closeness on the map" now means something.

An embedding does the same thing for meaning. It takes a piece of text, whether a word, a sentence, or a paragraph, and assigns it a list of numbers (its coordinates). The trick that makes it useful: text with similar meaning gets similar coordinates. "How do I reset my password?" and "I forgot my login credentials" land near each other, even though they share almost no words.

The only twist versus a city map is the number of dimensions. Instead of 2 numbers (north, east), an embedding uses hundreds or thousands; 1024 is common. You can't picture 1024 dimensions, and you don't need to. The rule is identical: close together means similar.

What a real embedding looks like

Ask an embedding model to encode a sentence and you get back something like this, a fixed-length list of numbers:

embed("How do I reset my password?")
# → [0.021, -0.114, 0.087, ..., 0.003]   (1024 numbers)

Every sentence you embed with the same model produces a list of the same length. That consistency is what lets you compare any two texts: encode both, then measure how close their number-lists are.

Measuring "closeness"

The standard measure is cosine similarity. Ignore the math; the intuition is all you need:

  • Score near 1.0 → the two texts mean almost the same thing.
  • Score near 0 → unrelated.
  • Score below 0 → roughly opposite.

So semantic search is just:

  1. Ahead of time, embed every document in your knowledge base and store the numbers.
  2. When a user searches, embed their query.
  3. Return the documents whose numbers are closest to the query's numbers.

That's it. No keyword matching. The user can phrase the question however they like, in whatever words, and still find the right document, because you're comparing meaning, not spelling.

Why this beats keyword search

Traditional search matches words. If your document says "vehicle" and the user searches "car," keyword search returns nothing. Embeddings don't care about the exact words; "car" and "vehicle" sit right next to each other in coordinate space, so the match happens naturally.

This is why embeddings handle:

  • Synonyms: "slow" finds "high latency"
  • Paraphrasing: "how much does it cost" finds "pricing details"
  • Typos and phrasing: "nearist neighbor" still lands close to "nearest neighbour"

Where embeddings fall short

Being honest about the weaknesses saves you a lot of debugging later. Because embeddings compress meaning, they blur precision:

  • Exact identifiers: an error code like E_CONN_TIMEOUT or a specific SKU can get lumped in with vaguely similar strings.
  • Negation: "safe for pregnancy" and "not safe for pregnancy" look deceptively close.
  • Rare proper nouns: uncommon names get pulled toward more common neighbours.

This is exactly why production systems pair embeddings with old-fashioned keyword search (BM25) in a hybrid approach: embeddings catch meaning, keyword search catches the exact tokens embeddings smear over.

The one decision that matters

You don't train embeddings yourself; you call a model that already knows how to produce them. Your one real choice is which model, and it comes down to three trade-offs:

  • Quality: how well it separates related from unrelated text on your kind of content.
  • Dimensions: more numbers per embedding can mean more nuance, but more storage and slower search.
  • Cost and latency: you'll embed every document once and every query forever, so this adds up.

Pick a well-regarded general-purpose model to start. You can always re-embed later if your content is specialised.

The whole idea in one sentence

An embedding turns text into coordinates so that similar meanings end up close together. Once meaning is just distance, search becomes measuring how near two things are. Everything else in semantic search is an optimisation on top of that one idea.