Why Production Search Uses Both

Keyword retrieval and vector retrieval — and why neither alone is enough

Part of the series: How Search Understands Meaning

Sparse retrieval = exact hearing.

Dense retrieval = contextual understanding.

One hears the words. The other understands the meaning.

Modern retrieval systems combine both. That’s hybrid retrieval — and it’s how production systems actually work.

Quick recap

Part 3 covered keyword retrieval and vector retrieval individually.

Hybrid search is what happens when both systems run together inside the same retrieval pipeline.

Why either signal alone fails

Consider the query:

“iPhone 13 Pro battery issue”

Pure keyword search finds exact matches. It may miss:

• “battery draining fast”
• “power cuts out overnight”

Pure vector search finds semantic meaning. It may retrieve:

• iPhone 14 battery problems
• Apple charging accessories
• Related devices that are semantically close but factually wrong

Both fail differently — and production systems cannot afford either failure mode.

Running both together

Hybrid retrieval runs two signals in parallel:

Query
 ├── Sparse retrieval  → exact term matches
 └── Dense retrieval   → semantic matches
          ↓
      score fusion
          ↓
      ranked results

The result: better recall from dense retrieval, better precision from sparse retrieval, combined into a single ranked list.

That’s the structure. The interesting part is what happens at score fusion.

When sparse and dense disagree

This is where hybrid systems get genuinely complex.

Consider the query:

“Apple charger”

Keyword retrieval and vector retrieval

Sparse retrieval prioritises exact keyword matches — results containing “Apple” and “charger.”

Dense retrieval prioritises semantic similarity — results about charging accessories, power adapters, cables, and related Apple products.

Now the system must decide: which signal to trust more?

There is no universal answer. It depends on the query, the domain, and the data. Some queries need precision — a user searching for a specific product SKU (stock keeping unit) does not want semantic drift. Other queries need semantic range — a user asking “why does my phone die so fast” is not going to use the exact words that appear in the relevant document.

The engineering challenge is not generating more results. It is deciding which retrieval signal deserves more trust for a given query.

How systems make that decision

Three common approaches:

Weighted scoring

Assign a weight to each signal.

Final score = (α × sparse score) + (β × dense score)

Tune α and β based on your domain.

A customer support system might weight exact keyword matches higher. A research tool might weight semantic similarity higher. This is common in production systems where business context matters.

Reciprocal Rank Fusion (RRF)

Instead of combining raw scores — which live on different scales — RRF combines rankings. Each result gets a score based on its rank in the sparse list and its rank in the dense list. The formula discounts lower-ranked results without needing to normalise scores across systems. This works well when you do not know beforehand which signal should dominate.

Reranking models

A third pass: after sparse and dense retrieval, a cross-encoder model re-scores the top N candidates by reading the query and each result together. This is slower but more accurate. Covered in Part 5.

This is not automatically better

Combining sparse and dense retrieval helps — but only if chunking, embeddings, weighting, and ranking logic are tuned correctly.

Hybrid retrieval is not “vector search and BM25 duct-taped together.”

A poorly chunked index will still return irrelevant passages. Mis-calibrated weights will let one signal drown out the other. Weak embeddings will make dense retrieval as brittle as keyword search.

The combination creates headroom for better results — it does not guarantee them.

Where hybrid search matters most

The payoff is largest in systems where users expect exactness and understanding at once:

• RAG (retrieval-augmented generation) systems
• Enterprise search
• E-commerce product search
• Developer documentation
• Customer support retrieval

In each case, users will sometimes search with precise terms. Sometimes with intent. Sometimes with neither. A single retrieval strategy cannot handle all three.

Takeaway

Keyword search and vector search are not competitors.

They are complementary signals — each strong where the other is weak.

Production retrieval systems do not trust a single signal. They combine signals, fuse rankings, and rerank results.

That is what makes them work in practice.

What’s next

Hybrid retrieval improves what the system finds.

But retrieval is only the first step. The next challenge is deciding which result should come first — and doing it accurately, not just approximately.

That’s where reranking enters.

Series

• Part 1 — How Machines Measure Meaning
• Part 2 — Semantic Search vs Similarity Search
• Part 3 — Vector Search vs Keyword Search (BM25)
• Part 4 — Why Production Search Uses Both
• Part 5 — Reranking: The Second Brain of Search (next)