Also known as: meaning-based search, neural search, vector search
Semantic search is the umbrella term for retrieval that goes beyond surface keyword matching to capture meaning — most often via dense embeddings, but also via learned-sparse models, query rewriting, and reranking.
Semantic search is the umbrella term for retrieval systems that find documents based on meaning rather than surface keyword overlap. A semantic search system retrieving “How do I reset my password?” will surface a document titled “Recovering forgotten login credentials” — even though the two strings share no content words.
The term is loose by design. It covers everything from full neural retrieval pipelines to hybrid lexical-plus-dense stacks to query-expansion systems backed by classical BM25 . What unites them is that the system is doing more than substring matching.
Three architectural patterns dominate:
In practice production semantic search is almost always hybrid — dense plus sparse, fused at the rank level, then reranked . See hybrid search .
Vector search is an implementation; semantic search is a goal. You can do semantic retrieval without vectors and vector search that is not really semantic.
The reason this matters: semantic systems and classical IR have different failure modes. Classical IR misses paraphrases. Semantic systems hallucinate similarity — embedding two unrelated paragraphs near each other because they share generic vocabulary. Knowing which side you’re on tells you which failures to expect.
RAG pipelines lean on semantic search for first-pass — given a user’s natural-language question, find documents that mean something related, not documents that quote the question. Then chunking , reranking , and finally generation. Without semantic first-pass the LLM never gets a chance to ground; with semantic first-pass plus a reranker you get the precision needed for citations to land on the right span.
Probably less than it does now. The term emerged when keyword search was the dominant alternative; “semantic” was the differentiator. By 2025-2026 every consumer search product uses some flavor of meaning-based retrieval, and the term has been diluted by marketing. What’s actually load-bearing in a modern stack is more granular: dense retriever, sparse retriever, reranker, query rewriter, faithfulness model. “Semantic search” is the umbrella for the union; over time it’ll fade in favor of those component names.
The historically robust phrasing is first-pass retrieval for the candidate-generation stage — neutral on whether the implementation is dense, sparse, or hybrid. That’s the term you’ll see in production architecture documents that have to outlast a marketing cycle.
Vector search is one implementation, the most common today, but not the only one. Learned-sparse retrieval (SPLADE, uniCOIL) is also semantic — its term expansions go beyond surface words. Reranker-driven pipelines and LLM-based query rewriting count too. The unifying property is that meaning, not just tokens, drives retrieval.
Roughly: when the system can match a query to a relevant document that shares no surface tokens. BM25 with synonym lists is borderline. BM25 alone is not semantic. Dense retrieval is. The boundary is fuzzy because hybrid stacks blur the categories — and that's mostly fine.
No — semantic first-pass is necessary but not sufficient. Bi-encoder embeddings give you 'roughly relevant' candidates; getting the actually-most-relevant document to position 1 takes a cross-encoder reranker that sees query and document jointly. Semantic search and reranking compose.
