Keyword and semantic search both score relevance the same way: as an inner product between a query vector and a document vector. The methods differ only in what those vectors represent.

BM25, the standard keyword ranking function, represents a document as a sparse vector with one dimension per vocabulary word. Its weights encode three priors: rare words discriminate more, repetition saturates, and focused documents beat long ones. An inverted index makes this fast by skipping the zero dimensions, so a query touches only the terms it contains.

Semantic search uses dense vectors produced by an embedding model. The dimensions are learned semantic directions, not vocabulary terms. Query and document vectors are scored by dot product or cosine similarity, measuring how far their meanings align.

The keyword basis preserves exact token identity. The dense basis preserves meaning. Neither preserves both. The two representations are complementary: one preserves words, the other meaning. That single fact explains the failure pattern of each method.

Exact identifiers favor keyword search. An error code like ERRCONNRESET, an SKU, or a product code matches perfectly in a sparse vector but washes out in embedding space, where rare token identity is flattened into learned directions.

Long descriptive queries favor semantic search. The query 'automobile repair' lands near the document 'car maintenance' in a dense basis, while a keyword search sees no shared tokens.

Short keyword queries and domain jargon favor lexical search, especially when the embedding model has not been tuned on that domain. Conceptual intent and paraphrase favor semantic search. An untuned model's failures are opaque; BM25's are interpretable and adjustable with two parameters, and it needs no training.

The practical rule: when the query is an identifier or jargon, rely on the keyword path. When the query describes a concept, rely on the vector path. When the query mixes both, you need both paths. The two methods fail on opposite classes, which is what makes them complementary rather than redundant.

Production systems run both retrievers in parallel and fuse the results. Hybrid search is the production default for retrieval-augmented generation (RAG) systems that supply documents to AI models.

The scores cannot be summed directly. BM25 scores are unbounded, while cosine similarity lies between −1 and 1. Adding them would let the unbounded side dominate the blend.

Reciprocal Rank Fusion ignores scores entirely. It adds 1/(k + rank) across both ranked lists, so a document ranked near the top of both lists beats one that is first in only a single list. It needs no tuning, which is why Elasticsearch ships it built in.

Weighted score normalization is the alternative. It scales both scores to a 0–1 range and blends them, which gives finer control but requires tuning for each collection. The choice between them depends on whether you need zero-configuration robustness or fine-grained control.

Fusion works for the same reason ensembles work. Both retrievers estimate the same relevance ordering, and their errors fall on different kinds of query. A document that ranks well in both lists is more likely relevant than one that ranks well in only a single list.

The canonical pipeline has two stages. The recall stage runs keyword and vector search in parallel, fetches the top 100–1,000 candidates, and fuses them. The precision stage uses a cross-encoder reranker that reads query and document together, catching negation and fine dependencies that separately embedded vectors flatten, and selects the final 5–10 passages for an AI model's context window. This is the retrieval architecture behind AI assistants that answer from documents, the same loop that powers agent workflows like those explored in Loop Engineering.

The two stages have different goals. Recall maximizes coverage. Reranking maximizes precision.

A reranker cannot recover documents the first stage missed. Retrieval quality sets the ceiling for the whole pipeline.

Hybrid search is not automatically better than the stronger single path. A weak retrieval path can pollute the fused list and degrade accuracy. Treat adding vector search as adding an estimator, never as migrating off BM25. When fused results disappoint, diagnose which method's failure class the bad queries belong to before touching fusion weights.