Semantic search definition

Semantic search finds results by meaning rather than by matching exact keywords, which is why a query can return the right document even when that document never uses the words typed. In Sanity, the GROQ function text::semanticSimilarity() does this ranking, and it is only valid inside score(), which captures the concept's central constraint: semantic search orders results by closeness in meaning, but it does not enforce that a result meets a condition.

How does semantic search actually work?

Semantic search works by turning text into numbers that encode meaning, then measuring distance between those numbers. The standard pipeline has three steps. First, at index time, an embedding model encodes each document, or each chunk of a document, into a vector, a long list of numbers positioned in a high-dimensional space. Second, at query time, the same model encodes the search query into a vector using the same rules. Third, the system returns the nearest neighbors, the documents whose vectors sit closest to the query vector by a distance measure such as cosine similarity. Results are often reranked afterward by a second, slower model that scores query and document together for a more careful judgment of relevance.

This returns sensible answers because embedding models are trained so that texts with similar meanings land near each other in the vector space, whether or not they share vocabulary. Sentence-BERT (Reimers and Gurevych, 2019) is a well known example of a model built specifically to produce sentence embeddings that can be compared this way.

There is an older, second sense of the term worth knowing, because it still appears in academic literature. Some authors use semantic search to mean retrieval over richly structured knowledge sources such as ontologies, RDF, OWL, Schema.org markup, and knowledge graphs, where meaning comes from explicit relationships rather than from learned vectors. Google's Knowledge Graph, launched in 2012, is the best known production example of that sense. The embedding sense dominates current usage.

What is the difference between semantic search and keyword search?

Semantic search ranks by similarity of meaning, while keyword search ranks by the presence and frequency of literal query terms, usually with a classical algorithm such as BM25. Keyword search treats tokens as discrete units, not as meaning, so it misses synonyms that share no lexical root, and it cannot interpret a phrase like "something like X." Semantic search handles both, because the vector for "cozy knit sweater" sits near the vector for a product described as "soft wool pullover."

The inverse is also true, and many explanations skip it. Semantic search is weaker than keyword search on exact identifiers: SKUs, error codes, version numbers, part numbers, and proper nouns. When a user types a precise string, literal matching is the correct behavior, and similarity scoring can rank a near-miss above the exact hit. Neither approach is strictly better than the other. They fail in opposite directions, which is why production systems commonly combine them.

Is semantic search the same as vector search?

Semantic search and vector search are used interchangeably, but they are not the same thing. Vector search is the mechanism, nearest-neighbor lookup over embeddings, which works just as well for images, audio, and video as it does for text. Semantic search is the goal, retrieval by meaning. You can pursue that goal with embeddings, with ontologies and knowledge graphs, or with a hybrid of several signals. Vector search is one implementation of semantic search, and semantic search is one thing you can build with vector search.

Semantic search is also not the same as retrieval-augmented generation (RAG). RAG is a system pattern: retrieve relevant content, then condition a generative model on what came back. Semantic search is one retrieval strategy that RAG systems commonly use, alongside keyword matching, structured queries, and graph traversal. As Sanity's context engineering field guide puts it, vector search and RAG are not the same as good retrieval, they are one ingredient.

When should you not use semantic search on its own?

Semantic search should not be used on its own when a result has to satisfy a hard condition, because semantic search ranks, not filters. A vector query can put the most meaning-relevant products at the top of the list, but it cannot guarantee that every result is in stock, under $150, published rather than draft, or visible to the current user's permissions. Similarity is a score, not a predicate.

Structured query languages such as GROQ, SQL, and GraphQL are the mirror image. You write the predicate, you get exactly what you asked for, and it falls over when a user says "the cozy one" or anything else that lives in vibes rather than fields. Hybrid retrieval is the honest answer for most content-first search problems: keyword matching for literal strings, embeddings for semantic ranking, and structured predicates for the constraints that have to hold.

Layering helps measurably. Anthropic reported in its contextual retrieval work that contextual embeddings cut top-20 retrieval failures by 35 percent, that adding contextual BM25 took the reduction to 49 percent, and that adding a reranking step brought it to 67 percent. Those figures describe improvements over a baseline RAG setup on Anthropic's evaluations, not a general statement that semantic search is 67 percent better than anything else, but the direction is instructive: more signals, better retrieval.

How does semantic search work in Sanity?

Semantic search in Sanity runs through Dataset Embeddings, a Content Lake feature enabled per dataset, and the GROQ function text::semanticSimilarity(), which converts a search term into a vector and ranks documents by proximity to their embeddings. The function is only valid inside score(), so it contributes to ordering rather than to the result set, which mirrors the ranks-not-filters property of semantic search generally. The older Embeddings Index API and text::embedding() are deprecated, and Sanity publishes a migration guide to the current path.

The practical value is that all three retrieval signals live in one query. Filters on fields such as _type, category, price, and stockLocation determine what is eligible, then a score clause can blend a BM25 keyword match on the title, boosted two times, with semantic similarity across the whole document, then order by _score descending. The result is a small, ranked list that satisfies the structural constraints and the vibe at the same time.

As the intelligent backend for companies building AI content operations at scale, Sanity treats index freshness as part of the content pipeline rather than as glue code you maintain. Incremental indexing, re-embedding on change, deletion handling, and backfills after schema changes are a real project when retrieval lives in a separate vector database. You do not need Sanity for any of this, of course. PostgreSQL with pgvector and full-text search can do it, Elasticsearch can, Algolia is built for the structured-plus-relevance case, and Pinecone with a metadata filter layer can too.

One honest caveat from Sanity's own production observations: embeddings are opt-in and off by default, and the heavy majority of retrieval traffic through Sanity Context is structured rather tha

Last updated: September 10, 2026