In plain terms
Classic search looks for the words you typed. Type “laptop won't turn on” and it misses the article titled “Troubleshooting a notebook that fails to boot”. Semantic search compares what the two texts mean and finds it, because “laptop” and “notebook”, “won't turn on” and “fails to boot” sit close together in meaning.
Why it matters
People rarely phrase a question the way the answer was written. Semantic search closes that gap, which is why it improves help centres, internal knowledge search and product discovery, and why it is the default retrieval method for RAG. It has a known weakness: it is poor at exact identifiers such as part numbers, error codes and names.
Example
A law firm's document search is switched from keywords to semantic. A lawyer searching “clauses that let the buyer walk away if financing falls through” now finds provisions headed “Conditions precedent” and “Termination for failure of funding”, neither of which contains her words.
Most often confused with
Semantic Search vs. Keyword search
Keyword search is precise and literal: ideal for a product code or a name, blind to synonyms. Semantic search is flexible and approximate: good with natural questions, unreliable with exact strings. Most production systems run both and merge the results, which is called hybrid search.
Under the hood
Implementation: an embedding model converts documents (split into chunks) and queries into vectors; a vector index returns the nearest chunks. Quality depends on the embedding model's fit to your language and domain, on chunking, and on whether queries and documents are of similar form; short questions against long documents often benefit from query expansion or from models trained for asymmetric search. Multilingual embedding models allow a query in one language to retrieve documents in another. Evaluate on your own queries: public benchmark rankings do not reliably predict performance on specialised content.