01The problem: words can hide meaning

Classic keyword search (the kind behind BM25 and TF-IDF) ranks documents by how much their exact words overlap with your query. It is fast and precise when you know the right term — but it is brittle. Search for “how do I lower my heart rate?” and a perfect article titled “reducing your pulse” can score zero, because it never repeats your words. This is the vocabulary-mismatch problem: the same idea, expressed differently, slips through the net.

Semantic search attacks this from the other side. Instead of comparing the words, it compares the meaning. It does that by encoding both the query and every document into vectors — lists of numbers — positioned so that texts with similar meaning land near each other, whether or not they share any vocabulary. Retrieval becomes a geometry problem: find the document vectors closest to the query vector. Meta’s Dense Passage Retrieval (DPR) showed that a learned vector retriever can beat strong keyword baselines like BM25 on open-domain question answering.

• Keyword / sparse retrieval matches on shared terms — precise, but blind to synonyms and paraphrase.
• Semantic / dense retrieval matches on meaning encoded as vectors — it finds relevant docs that share no keywords.
• “Vector search” is the mechanism; “semantic search” is the capability it delivers.

02Embeddings: turning meaning into coordinates

An embedding is a dense vector — a list of floating-point numbers — produced by a model so that it captures the meaning of a piece of text (or an image, or audio). The guiding rule is simple: similar meanings map to nearby points in the vector space. The idea goes back to word vectors like Word2Vec (2013) and GloVe (2014), which learned a single static vector per word; modern contextual models such as BERT, and sentence/passage encoders like SBERT, extended this to whole sentences and documents whose meaning depends on context.

Once text is vectors, “closeness” needs a number. The usual measure is cosine similarity — the angle between two vectors — which runs from about −1 (opposite) through 0 (unrelated) to 1 (same direction). Many providers normalise vectors to length 1, in which case ranking by cosine similarity, dot product, or Euclidean distance all agree. Real embedding models are high-dimensional (often hundreds to thousands of numbers per vector), but the principle is identical to the 2-D picture you can play with next.

• An embedding = a dense vector that places a text by its meaning; nearby vectors mean similar meaning.
• Cosine similarity scores how aligned two vectors are — higher means more semantically similar.
• Query and document vectors must come from the same model and dimension to be comparable.

03Watch a query find its neighbours

Below is a tiny corpus of a dozen documents, each plotted as a point on a 2-D embedding plane — an illustrative stand-in for the high-dimensional space a real model would use. Pick a query (or type your own from the suggested words). The query gets “embedded” — placed on the plane — and the closest documents by cosine similarity light up. Then flip the toggle to Keyword to see which documents a literal exact-word match would have returned. Watch how semantic mode surfaces relevant documents that share no words with your query.

• In semantic mode, the nearest neighbours are scored by cosine similarity — meaning, not spelling.
• In keyword mode, only documents that literally contain one of your query words match — paraphrases score zero.
• The 2-D plane and scores here are illustrative; real systems use many-dimensional vectors, but the geometry is the same.

04Bi-encoders, cross-encoders & reranking

How the query and a document get compared is the design decision that makes semantic search both fast and accurate. There are three building blocks. Switch between them to see how each trades speed for precision — and why production systems usually combine them.

The standard pattern ties them together: a fast bi-encoder retrieves the top-k candidates from the full corpus, then a cross-encoder reranks just those for precision. This retrieve-then-rerank pipeline gets the recall of vector search with the accuracy of pairwise scoring — without ever running the expensive model over every document.

05Making it work at scale

Comparing a query against millions of vectors one by one would be too slow, so production systems use Approximate Nearest Neighbor (ANN) indexes — structures like HNSW — that find the nearest vectors in sub-second time by trading a sliver of recall for a large speed gain. Vector databases and search engines (Pinecone, Weaviate, Elasticsearch, OpenSearch) build on exactly this.

Two more practical levers matter. Hybrid search fuses dense (semantic) scores with sparse (keyword/BM25) scores, so you get meaning-based recall and exact-term precision — useful when product codes, names, or rare terms must match literally. And some models embed queries and documents asymmetrically (for example Cohere’s search_query vs search_document input types, or E5’s query: / passage: prefixes) to better match short questions against longer passages.

Finally, which embedding model? The neutral way to compare is the Massive Text Embedding Benchmark (MTEB), which evaluates models across many task types — retrieval, reranking, clustering, classification, semantic textual similarity — over many datasets and languages, with a public leaderboard. Pick for your task (retrieval fit matters more than a single aggregate score), date any “best model” claim, and remember that query and document vectors must come from the same model and dimension to be comparable.

• ANN indexes (e.g. HNSW) make million-scale vector search fast by approximating nearest neighbours.
• Hybrid search blends semantic recall with keyword precision for the best of both.
• Compare embedding models on MTEB by the task you actually care about, not a single headline number.

06Check your understanding

07Take it with you & go deeper