Vector Search vs Keyword Search for RAG Pipelines

TLDR: Keyword search matches exact terms and wins on identifiers, names, and error codes. Vector search matches meaning and wins on paraphrase, synonyms, and questions asked in different words. Neither dominates, so production RAG systems usually run both and fuse the results, a pattern called hybrid retrieval. This guide explains both mechanisms, when each wins, how to fuse them, and how to detect the queries each one silently loses.

Every RAG pipeline makes one retrieval decision before any model is involved: what has to match between the question and the document. Keyword search requires shared words. Vector search requires shared meaning. The choice decides which questions your pipeline can answer, and the two fail in opposite directions, which is why the comparison is a decision framework rather than a ranking. If your retrieval corpus is the live web, both capabilities arrive through You.com in one Web Search API call, but if you index your own corpus, you own this decision.

What Is Keyword Search?

Keyword search ranks documents by how well their terms match the query terms, weighted by how rare each term is in the corpus. The dominant scoring function is BM25, a term-frequency formula refined over decades of information retrieval. A keyword system reading the query "OAuth 2.0 refresh token expiry" finds documents containing those exact tokens, in rough proportion to how many times each appears.

Its strength is exactness. Identifiers, product codes, function names, and error strings survive keyword search perfectly, because the match is literal. Its weakness is vocabulary mismatch: a document saying "sign-in tokens expire" and a query saying "login session timeout" share no words, and BM25 cannot bridge the gap. The dense retrieval study that followed the RAG era, Dense Passage Retrieval for Open-Domain Question Answering, showed exactly this split: neural retrievers overtook BM25 on natural questions, while exact-term queries remained the keyword system's home ground.

What Is Vector Search?

Vector search embeds the query and the documents with the same embedding model and returns the closest vectors by distance. The model is the matching layer, so a document can match a query with no shared words, as long as the embeddings land near each other.

Its strength is paraphrase tolerance. "How do I stop my app logging everyone out" finds the document about session token expiry because the model learned the two phrasings sit close. Its weakness is precision on unusual literal strings: an embedding of "error 0x80070057" is not meaningfully near the embedding of "invalid parameter" even when the document about the error code is the right answer, and rare identifiers embed badly precisely because they are rare. Our vector database guide covers the storage and index layer underneath.

Which One Wins for Which Query?

Split your expected queries by type and the answer falls out, because the two mechanisms fail on complementary query shapes.

Exact identifiers such as error codes, API names, and part numbers: keyword. The literal match is the whole job, and embeddings are unreliable on rare strings.
Natural language questions where users describe a problem in their own words: vector. The words will not match the documentation's words.
Mixed queries that name a product and describe a symptom: both, fused. The product name is a keyword signal, the symptom description is a semantic signal, and either system alone drops one of the two.
Multi-language corpora: vector, if the embedding model covers the languages, because keyword search across vocabularies has no bridge at all.

A useful audit exercise: sample real user questions, label each as identifier-like, paraphrase-like, or mixed, and count. The distribution tells you what your retrieval owes its users, and most corpora turn out mixed, which is why hybrid retrieval is the production default.

How Does Hybrid Retrieval Work?

Hybrid retrieval runs both systems on the same query and merges their ranked lists. The standard merge is reciprocal rank fusion, which scores each document by the sum of one over a constant plus its rank in each list, so a document ranked high in both lists beats a document ranked first in only one.

def reciprocal_rank_fusion(rankings: dict, k: int = 60) -> list:
    # rankings: {"keyword": [doc_id, ...] in rank order,
    #            "vector":  [doc_id, ...] in rank order}
    scores = {}
    for system, docs in rankings.items():
        for rank, doc_id in enumerate(docs, start=1):
            scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)
    return sorted(scores, key=scores.get, reverse=True)

fused = reciprocal_rank_fusion({
    "keyword": ["doc-a", "doc-b", "doc-c"],
    "vector": ["doc-c", "doc-a", "doc-d"],
})
# doc-a and doc-c rank high in both lists, so they surface
# above doc-b, which only the keyword system found

The fused list is what feeds the model. The same pattern generalizes to three or more retrievers, including a reranker as a later stage, and the RAG paper that popularized the architecture, Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, built its retrieval on a learned dense retriever whose authors explicitly compared against and combined with term-based baselines. Our RAG pipeline guide places the fusion step in the full architecture, including where a cross-encoder reranker goes after fusion.

What Breaks, and How Do You See It?

The vector-only identifier miss. A user pastes an error code, the embedding places it near nothing useful, and the answer is a confident hallucination built on irrelevant context. Detection: log queries that look like identifiers, meaning high density of digits, symbols, and long tokens, and check their retrieval scores. A vector-only system will show weak scores on exactly that class, and a keyword side rail fixes it.

The keyword-only paraphrase miss. The user describes the symptom in conversational language, the documentation uses formal language, and keyword search returns nothing on point. Detection: track queries with zero results above threshold and read them. A pile of zero-hit queries that a human can answer by reading the docs is a vocabulary mismatch, and it is the specific problem vector retrieval was adopted to solve.

Fusion weights tuned on the wrong corpus. The constant in reciprocal rank fusion and any per-system weights are corpus properties. A setting copied from one domain can suppress the system that matters in yours. Detection: hold out a labeled query set, and evaluate fused retrieval while varying weights. The optimum is visible in the data, and it moves when the corpus moves, so re-run the sweep after major ingestion changes.

The stale synonym file. Keyword systems with hand-curated synonym expansion stop matching when product vocabulary changes and nobody updates the file. Detection: log synonym expansions that fire, and audit which fired in the last quarter on renamed terms. A dead expansion list is silent until a product rename makes every query about the new name miss.

Related Guides

FAQ

Is vector search better than keyword search? Neither is better outright. Vector search wins on paraphrase and natural questions, keyword search wins on identifiers and exact terms. Production systems usually run both and fuse the results, because the two fail on opposite query shapes.

What is hybrid retrieval? Running keyword and vector search on the same query, then merging the two ranked lists, usually with reciprocal rank fusion. It costs a second retrieval call per query and recovers the queries each single system would have lost.

When is keyword search enough on its own? When queries and documents share vocabulary by construction, such as internal tools where users query exact identifiers, or when the corpus is small enough that missing paraphrase is tolerable. Zero-hit query logs are the evidence to check before adding a vector system.

Do search APIs already do this? Mature web search systems combine term matching with semantic signals internally, which is part of why a web search API answers conversational queries that a homegrown keyword index misses. When the corpus is the web, the fusion problem is the search engine's, not yours.