Semantic Search

The Solution: Understanding Meaning, Not Words

Semantic search uses embeddings — dense vector representations of text meaning — to find content by concept rather than by exact keyword. An embedding model reads a piece of text and outputs a list of numbers (often 384, 768, or 1536 of them) that encodes its meaning. Texts about similar ideas land close together in this high-dimensional space, while unrelated texts land far apart. Searching for "headache remedy" finds "migraine treatment" because both map to nearby vectors, even though they share no words at all.

How it works

The pipeline has two phases. First, an offline indexing phase: every document in your collection is run through the embedding model once and the resulting vectors are stored in a vector database like Pinecone, Qdrant, or pgvector. Second, an online query phase: when a user searches, their query is embedded with the same model, and you compare the query vector against the stored document vectors. The standard comparison is cosine similarity — the cosine of the angle between two vectors, ranging from 1 (identical direction) to 0 (unrelated) to -1 (opposite). The documents with the highest similarity are returned as the top-k results. For large collections you do not compare against every vector exactly; an ANN (approximate nearest neighbor) index such as HNSW makes retrieval fast at the cost of occasionally missing a true match.

When to use it, and the tradeoffs

Reach for semantic search when users phrase things in their own words, when synonyms and paraphrases matter, or when you need cross-lingual matching. It is also the retrieval backbone of RAG systems that feed context to an LLM. But it is not free of pitfalls. Embeddings blur exact details: a query for product code "X-450" or a specific person's name may rank a vaguely related document above the exact one, because keyword precision is exactly what embeddings smooth over. The fix in practice is hybrid search — blend semantic scores with a keyword signal like BM25 so you get both meaning and exact-match precision. Two more rules of thumb: you must embed queries and documents with the same model, and long documents should be split into smaller chunks before embedding, since a single vector cannot faithfully represent ten pages of mixed topics.

Worked example. Imagine a support knowledge base of 3 articles: A = "Resetting your password", B = "Updating your billing card", C = "Recovering a locked account". A user types "I forgot my login". Keyword search finds nothing — none of the articles contain the word "forgot" or "login". Semantic search embeds the query and gets cosine scores like A = 0.81, C = 0.74, B = 0.22. It returns A and C at the top because "forgot my login" is semantically close to "resetting your password" and "locked account", and correctly pushes the unrelated billing article to the bottom.

Where Is This Used?

• Knowledge Base Search: Finding relevant support articles even when users describe problems in their own words
• Documentation Search: Surfacing the right API reference page from a conceptual question
• Product Discovery: "Comfy shoes for long walks" finds "ergonomic footwear" and "orthopedic sneakers"
• Cross-Lingual Search: A query in English finds semantically matching documents written in Russian or French
• Common Pitfall: Embedding Blind Spots: Embedding models struggle with rare proper nouns, product codes, and very recent terminology — hybrid search (semantic + keyword BM25) handles these edge cases better

Try It Yourself!

Try the interactive demo below to compare keyword search vs semantic search and see how meaning-based matching finds what keywords miss.