Vector search is just a map of meaning.

“Nearby means similar.” That one line is the whole idea behind embeddings and vector databases — the machinery that lets Artificial Intelligence (AI) search your documents by meaning, not by keyword. Every team serving tech clients eventually hits the same question: when the AI answers from our files, how does it “find the right page”? This is the answer — and it's the quiet engine behind giving AI an open book¹.

How do you search by meaning, not keywords?

Keyword search is literal: it matches the words you typed. Ask it for “ways to cut churn” and it will sail right past the paragraph on “reducing customer attrition,” because not a single word overlaps. Searching by meaning fixes that, and the trick is surprisingly concrete. Every passage of text is turned into a long list of numbers called an embedding. The best way to picture that list, as one plain-English explainer puts it, is as co-ordinates in a very weird multi-dimensional space². Passages about similar things get similar coordinates and land near each other; unrelated ones land far apart. “Churn” and “customer attrition” end up next-door neighbors.

So what actually is an embedding?

No math required to use one. An embedding is a vector (list) of floating point numbers³ that a model assigns to a piece of text, and the rest is just distance: the distance between two vectors measures their relatedness³ — small distance, closely related; large distance, barely related. How much meaning hides in those numbers is easiest to see in a classic result from the research that popularised word embeddings: take the vector for “King,” subtract “Man,” add “Woman,” and you land on a vector that is closest to the vector representation of the word Queen⁴. Nobody taught the model about royalty or gender; that structure simply falls out of where words tend to appear. Note the honest word — it lands closest to “Queen,” not exactly on it. Meaning is a neighborhood, not a bullseye.

What's real?

• •This is how retrieval actually works in most Retrieval-Augmented Generation (RAG) systems. In the foundational RAG research, the model's external memory is a dense vector index of Wikipedia, accessed with a pre-trained neural retriever⁵ — embeddings plus nearest-point lookup, exactly the map above. And it earns its keep: a purpose-built dense retriever⁶ was shown to beat a strong keyword-search baseline by 9%-19% absolute in terms of top-20 passage retrieval accuracy⁶.
• •At scale, the “find the nearest points” step is approximate on purpose. Checking a question against millions of vectors exactly would be too slow, so vector databases use approximate nearest-neighbor (ANN) search. A widely used method, Hierarchical Navigable Small World (HNSW) graphs⁷, settles for the nearest matches rather than a guaranteed-exact scan and in return allows a logarithmic complexity scaling⁷ — near-instant search over huge collections. You almost always want the fast, 99%-right answer.
• •The embedding model is a real choice, and bigger isn't automatically better. Embedding models are benchmarked — the Massive Text Embedding Benchmark (MTEB) found that no particular text embedding method dominates across all tasks⁸, so the right model depends on your job. Its 2025 successor sharpens the point: the best-performing publicly available model⁹ across 250+ languages had only 560 million parameters⁹ — small, by today's standards.
• •It is not magic. A vector search only ever returns the nearest thing you gave it, so if your documents are chopped into clumsy pieces, the nearest piece can still be the wrong one. Anthropic notes that traditional RAG solutions remove context when encoding information, which often results in the system failing to retrieve the relevant information¹⁰. How you split and prepare the documents matters as much as the model — the same lesson as the open-book approach itself¹: retrieval quality is the whole game.

The “so what” — for anyone serving tech clients

• •When a client asks for “AI that knows our brand,” scope it as a retrieval project first — the same move as choosing grounding over training¹. The deliverable isn't a trained model; it's a well-built map: which documents go in, how they're chunked, and which embedding model reads them. That's a smaller, cheaper, more accurate quote than a training effort — and it's the one that survives contact with reality.
• •“Powered by a vector database” is not a differentiator — everyone's is. What you can promise, and charge for, is retrieval that actually returns the right passage: the document prep, the model choice, and a way to measure whether the top result is correct. That's the gap between a demo that finds the right page on stage and a system that finds it for every client, every time.