# Semantic Search vs Keyword Search: Key Differences

> Choosing between semantic search and keyword search starts with the questions people ask. An engineer searching for PAY-409 needs the exact error code. Someone describing checkout failures after payment authorization may need a runbook that uses entirely different terminology. The same knowledge base must often serve both requests.

- Canonical URL: https://www.puppygraph.com/learn/semantic-search-vs-keyword-search
- Published: 2026-11-13
- Author: Hao Wu

Choosing between semantic search and keyword search starts with the questions people ask. An engineer searching for `PAY-409` needs the exact error code. Someone describing checkout failures after payment authorization may need a runbook that uses entirely different terminology. The same knowledge base must often serve both requests.

This article compares how the two approaches retrieve information, where their architectures and operating costs differ, and how to measure their usefulness. It also explains when hybrid search helps and where explicit relationships add context beyond a document's wording.

## What is semantic search?

Semantic search retrieves information using representations of meaning and context. Its goal is to connect a request with relevant content even when their vocabulary differs. In the checkout example, a useful result might discuss transaction finalization even though the user described a payment succeeding and an order failing.

A common implementation converts documents and queries into numerical vectors called embeddings. A trained model places related text near one another in a shared representation space. The search system compares the query vector with stored document vectors and retrieves nearby candidates. The [Sentence Transformers semantic search documentation](https://www.sbert.net/examples/sentence_transformer/applications/semantic-search/README.html) describes this process and distinguishes short-question-to-passage retrieval from finding similar sentences.

The model must fit the task. A representation that works for finding duplicate questions may be less effective at finding a long troubleshooting procedure from a short symptom description. Domain terminology and the languages in the corpus also belong in the evaluation.

Semantic search is broader than dense vector retrieval. Learned sparse models can expand and weight vocabulary terms while retaining an inverted index. The [2021 SPLADE paper](https://arxiv.org/abs/2107.05720) describes this combination. This article uses dense retrieval as the main architectural comparison because its embedding and index requirements make the differences concrete.

Semantic retrieval also stands apart from answer generation. A search interface can return ranked passages and source links without composing an answer. Adding a language model to summarize those passages introduces another component whose output needs evaluation.

## What is keyword search?

Keyword search, also called lexical search, matches query terms against indexed content. An inverted index maps each term to the documents containing it, allowing the engine to find matching documents without scanning every document's full text. [Lucene's index documentation](https://lucene.apache.org/core/9_12_1/core/org/apache/lucene/index/package-summary.html) describes these term dictionaries and posting lists.

Keyword search already supports linguistic processing. An analyzer can lowercase tokens, reduce word variants through stemming, and apply synonym rules. Elastic's [text-analysis documentation](https://www.elastic.co/docs/manage-data/data-store/text-analysis) explains how these transformations let different surface forms match. A maintained synonym rule could connect an internal abbreviation with its expanded name.

Matching and ranking are separate steps. BM25 ranks lexical matches using term frequency, the rarity of terms across the collection, and document-length normalization. Repetition has diminishing influence rather than increasing the score without bound. These factors appear in [Lucene's BM25 implementation](https://lucene.apache.org/core/9_12_1/core/org/apache/lucene/search/similarities/BM25Similarity.html).

For an identifier such as `PAY-409`, preserve a field suitable for exact matching alongside analyzed prose. Tokenization may alter punctuation or split an identifier into pieces. Elastic's [term-query documentation](https://www.elastic.co/docs/reference/query-languages/query-dsl/query-dsl-term-query) distinguishes exact indexed-term lookup from analyzed full-text queries.

The practical benefit is control: engineers can inspect indexed tokens, configure field weights, and express required terms. The limitation is vocabulary coverage. If a runbook and query share no useful terms after analysis and expansion, a lexical retriever has little evidence connecting them.

## Semantic search vs keyword search: key differences

The central difference is the evidence used to identify a relevant candidate. Lexical retrieval works from terms and their statistics. Dense semantic retrieval works from learned representations. Neither signal establishes whether a document is current, authorized, or applicable to a particular deployment.

| **Dimension** | **Semantic search, using dense retrieval** | **Keyword search, using lexical retrieval** |
| --- | --- | --- |
| Matching signal | Similarity between learned query and document representations | Overlap between indexed and query terms after analysis |
| Useful query shape | Symptom descriptions, paraphrases, and conceptual questions | Error codes, names, distinctive terminology, and specified phrases |
| Vocabulary mismatch | Can bridge differences captured by the model | Needs shared terms or configured expansion |
| Typical failure | Retrieves a related topic that misses an exact requirement | Misses a relevant document expressed in different vocabulary |
| Debugging evidence | Retrieved neighbors, model behavior, and judged examples | Tokens, matched fields, term statistics, and query clauses |
| Main tuning choices | Model, passage boundaries, similarity metric, and candidate depth | Analyzers, synonyms, field weights, and query structure |
| Representation changes | A new embedding space generally requires re-embedding the corpus | Changed index-time analysis generally requires reindexing |

Consider two hypothetical runbooks: one documents `PAY-409` in the payment service; the other explains failures while finalizing orders. The code lookup should preserve the specific identifier. The symptom query should allow the second document to compete even if it lacks the user's exact words. These are intended behaviors to test, not guaranteed rankings.

This distinction also explains why neither approach is inherently more accurate. A broad conceptual match can be useful during investigation and distracting during a known-item lookup. Relevance depends on what the user is trying to accomplish.

## Semantic search vs keyword search: architecture comparison

Both architectures need content ingestion, document identity, metadata, updates, and a serving path. Their main difference is how they prepare searchable representations and select candidates.

**Lexical indexing and serving.** Documents pass through parsing and field-specific analysis before their tokens enter an inverted index. At request time, the engine analyzes the query, finds matching posting lists, and scores candidates. Titles, body text, and error-code fields can have different treatments. Preserve the original text for display rather than reconstructing snippets from normalized tokens.

**Dense indexing and serving.** Documents are divided into appropriate retrieval units, such as passages, then encoded and indexed as vectors. At request time, a compatible query encoder produces the vector used for similarity search. Precomputing document representations avoids running a joint language-model comparison against every document for each request, a motivation developed in the [Sentence-BERT paper](https://arxiv.org/abs/1908.10084).

For the checkout runbooks, preserve section titles and service names with each passage. A paragraph describing a recovery procedure may be ambiguous once separated from the heading that identifies its environment. Evaluate passage boundaries using complete troubleshooting questions, and retain a link back to the surrounding document so readers can inspect prerequisites. The unit being ranked should contain enough context to judge whether the procedure applies.

Vector retrieval can use exhaustive comparisons or an approximate nearest-neighbor index. HNSW, for example, organizes vectors in a navigable proximity graph to find nearby candidates efficiently. Its edges describe proximity in the vector space; they do not encode application relationships such as one service depending on another. The [HNSW paper](https://arxiv.org/abs/1603.09320) describes this index structure.

![Semantic search vs keyword search: architecture comparison](https://o6xswp5m6ilbks2z.public.blob.vercel-storage.com/blog-learn-c61db62496a6ab916af2ebbe.png)

Figure: Keyword and dense semantic search build different representations of the same documents. Hybrid search can combine their candidates, while source identity, content updates, and access controls remain shared responsibilities.

**Filtering and lifecycle.** Store source IDs and revisions so edits and deletions reach every representation. Keep tenant, environment, and visibility constraints separate from similarity scores. Applying a restrictive filter only after selecting a small vector candidate set can discard most results while missing eligible documents outside that set. Microsoft's [vector-filter documentation](https://learn.microsoft.com/en-us/azure/search/vector-search-filters) explains this recall trade-off.

These responsibilities remain even when one search platform manages both indexes. Shared infrastructure can simplify deployment, but the application still needs consistent identifiers, eligibility rules, and document versions across the retrieval paths.

## Semantic search vs keyword search: performance and accuracy

Measure relevance and serving performance separately. A low-latency response full of unsuitable documents is a failed search; a useful response that arrives too late may also fail the user's workflow.

**Relevance quality.** Build an evaluation set from representative requests: exact codes, service names, vague symptoms, abbreviations, and questions with no useful answer in the corpus. Label relevant documents before comparing systems. For checkout troubleshooting, include nearby but incorrect results, such as a runbook for a different environment that repeats the same error message.

Precision at a chosen cutoff measures how much of the returned set is relevant. Recall at that cutoff measures how much of the known relevant material was found. NDCG accounts for graded relevance and position, rewarding useful documents near the top. These distinctions are covered in [Stanford's CS276 evaluation lecture](https://web.stanford.edu/class/cs276/handouts/lecture8-evaluation_2014-six-per-page.pdf).

**Approximation quality.** ANN recall measures how well an approximate index recovers neighbors from an exact vector search. It is different from relevance recall: perfectly recovering the model's nearest neighbors can still return unsuitable documents. Elastic's [kNN documentation](https://www.elastic.co/docs/solutions/search/vector/knn) describes the candidate-search trade-off between speed and nearest-neighbor recall.

**End-to-end latency.** Measure query encoding, retrieval, filtering, optional reranking, and response assembly under realistic concurrency. Record tail latency as well as the median. Keep corpus size, hardware, candidate counts, and filter selectivity comparable; otherwise a timing comparison may reflect different workloads more than different retrieval methods.

A lexical-only baseline avoids the query-embedding inference step. Dense retrieval introduces that step but can use an efficient ANN index afterward. Consequently, index lookup time alone cannot establish which system responds faster. Likewise, adding a reranker to one system and omitting it from the other changes both the compute budget and the relevance comparison.

Use a tuned lexical system as the baseline. The [2021 BEIR benchmark paper](https://arxiv.org/abs/2104.08663) found BM25 to be a robust baseline in its zero-shot evaluations and highlighted generalization challenges for learned retrieval. That historical finding supports maintaining a serious baseline; it does not establish which current model will win on your documents.

Report results by query category as well as overall. An average improvement can hide a regression on exact error-code lookups, even when those lookups are the most operationally important requests.

## Semantic search vs keyword search: cost and scalability

Both approaches can serve large collections. Their costs depend on document volume, update rate, traffic, filtering, and the relevance target. Dense retrieval adds an embedding workload, while lexical retrieval still requires indexing, storage, replicas, and operational tuning.

**Initial preparation.** A lexical pipeline parses and analyzes content. A dense pipeline also runs document encoding and builds its vector index. Passage size matters: splitting every runbook into more overlapping passages increases the number of vectors and the amount of text processed. Choose boundaries that preserve troubleshooting context, then measure retrieval quality before increasing overlap.

**Storage and memory.** Raw vector storage is approximately the number of vectors multiplied by dimensions and bytes per component. As an illustrative calculation, one million 768-dimensional vectors stored as 32-bit floats require 3,072,000,000 bytes, or about 3.07 GB, for the vector values alone. IDs, metadata, source text, index structures, and replicas add overhead. The [Faiss index reference](https://github.com/facebookresearch/faiss/wiki/Faiss-indexes) documents this dimensional storage relationship and the different footprints of compressed and uncompressed indexes.

**Serving.** Dense retrieval needs query encoding unless an appropriate cached representation is available. Reranking adds inference over candidate pairs. Increasing candidate depth may improve the opportunity to find relevant material, but also increases work downstream. Budget for the complete request, including model hosting or API charges, rather than comparing index-storage prices alone.

**Changes over time.** Re-embed content whose encoded text changes. When adopting an incompatible embedding model, plan a corpus migration and enough temporary capacity to evaluate the new representation before switching traffic. Lexical systems have their own migration costs when index-time tokenization or field design changes. In either system, test deletions and permission updates alongside ordinary content edits.

Scaling the index also leaves other capacity questions to answer. Can ingestion process a burst of revised runbooks within the freshness target? Can the query encoder handle peak traffic without queueing? Does reranking become the limiting stage after retrieval accelerates? Size and monitor these stages separately. Adding search replicas will not fix an overloaded external model endpoint, and faster embedding generation will not repair an inefficient filter strategy.

Cost comparisons become useful when they hold a service objective constant: relevance on the same evaluation set, a latency target at expected traffic, and an acceptable freshness delay. The cheaper design is the one that meets those requirements with less total operating work.

## When to use semantic search vs keyword search

**Start with keyword search for known-item retrieval.** Error codes, API names, configuration keys, and named documents provide distinctive lexical evidence. A developer who enters `PAY-409` has already supplied a valuable constraint. Preserve it, and improve analysis or field configuration before assuming the system needs a new retrieval model.

**Evaluate semantic search when users describe needs indirectly.** Support questions and exploratory research often use vocabulary different from the documents. A request about checkout failing after a payment succeeds may need material on order finalization. Here, the benefit to test is whether users find useful evidence without knowing the system's internal terminology.

**Treat mixed requests as mixed requirements.** A query such as `PAY-409 after payment authorization` contains both an identifier and a symptom. Keep the code as an explicit condition when the user requires it, while using the remaining language to rank useful explanations. Relaxing that condition should be a deliberate product decision.

**Separate retrieval failures from missing knowledge.** If the runbook does not exist, changing the ranking algorithm cannot supply it. If documents omit environment and version information, similarity cannot establish applicability reliably. Review unsuccessful queries to distinguish vocabulary mismatches, poor ranking, missing content, and missing metadata before selecting a remedy.

The choice can vary within one application. Exact lookup and exploratory discovery may share a corpus while using different query routes. Let observed query categories determine whether semantic retrieval should supplement lexical search broadly or serve a narrower set of requests.

## Combining semantic and keyword search with hybrid search

Hybrid search commonly retrieves lexical and vector candidates, then combines their rankings. For the checkout knowledge base, the lexical path preserves evidence from `PAY-409`, while the semantic path can contribute passages expressed in different troubleshooting vocabulary.

A practical workflow is:

1.  Identify required filters and exact constraints, then apply them consistently to both retrieval paths.
2.  Retrieve lexical and dense candidates, using compatible source IDs to identify the same passage across both lists.
3.  Merge candidates with a rank-fusion method or a calibrated combination of scores.
4.  Optionally rerank the merged set, consolidate repetitive passages, and return authorized excerpts with their sources.

Raw BM25 and vector-similarity scores are not interchangeable. Reciprocal rank fusion, or RRF, combines positions in ranked lists instead of assuming that their score scales are comparable. A document contributes `1 / (c + rank)` from each list in which it appears, where `c` is a ranking constant. Elastic's [RRF documentation](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/reciprocal-rank-fusion) describes the formula and candidate-window controls. Evaluate those settings against your query mix; fusion does not guarantee that an exact match retains first place.

A cross-encoder can then score each query and candidate together, considering their text jointly. Because this costs more than comparing precomputed vectors, it typically processes a shortlist. The [Sentence Transformers retrieve-and-rerank guide](https://www.sbert.net/examples/sentence_transformer/applications/retrieve_rerank/README.html) explains this division of work. Reranking can improve ordering, but it cannot recover a useful document absent from every candidate list.

Some follow-up questions require recorded relationships. After finding runbooks, an engineer may need to know which documented services lie along a dependency path from `checkout-api`, and through which intervening services. Answering that question requires service-dependency records associated with the retrieved documents.

[PuppyGraph](https://www.puppygraph.com/) is the first and only zero-ETL graph query engine that queries existing tables as a graph in place, providing a distributed engine for exploring relationships such as these service dependencies. It connects to SQL databases, data warehouses, and data lakes or lakehouses, including direct reads of Iceberg and Delta Lake. Users define a graph schema mapping tables to nodes and edges, then query with openCypher and Gremlin while the same tables remain available to SQL, without ETL into a separate graph database.

![Comparison of the best data lakehouse solutions](https://o6xswp5m6ilbks2z.public.blob.vercel-storage.com/blog-learn-4b2587a755bbd5c9068284ee.png)

Figure: PuppyGraph queries the existing tables in place, so graph and SQL queries share one copy of the data and no pipeline keeps a graph copy in sync.

The application can associate retrieved document IDs with that graph model and request dependency paths as additional context, while its search engine continues to manage lexical retrieval, embeddings, and rank fusion.

![Comparison of the best data lakehouse solutions](https://o6xswp5m6ilbks2z.public.blob.vercel-storage.com/blog-learn-5820007cae8f617f5bb57a14.png)

Figure: Companies that use PuppyGraph.

![Comparison of the best data lakehouse solutions](https://o6xswp5m6ilbks2z.public.blob.vercel-storage.com/blog-learn-4492653ad4ba877e25923f1c.png)

Figure: Engineering teams at PuppyGraph customers on what they use it for.

## Conclusion

Keyword search provides direct control over terms and identifiers. Semantic search can connect requests with relevant content expressed differently. Hybrid search combines those signals, with its value determined by evaluation on the queries people actually submit. Keep exact constraints, document freshness, and relationship context explicit as the system grows.

Try the forever-free [PuppyGraph Developer Edition](https://www.puppygraph.com/download-confirmation) and [book a demo](https://www.puppygraph.com/book-demo) with the team to see how openCypher and Gremlin queries follow relationships across warehouse and lakehouse tables, with no graph-specific ETL, adding service-dependency context to the documents your search system retrieves.