BM25 vs Embeddings vs Rerankers: Search Stack in 2026

A good search stack works like a funnel. Cheap methods collect a broad candidate set first; expensive methods refine a much smaller set later. Problems often begin when teams replace exact-text search with embeddings instead of combining the two.

Start with filters and BM25, a strong exact-text ranking method. Add dense retrieval to find semantic matches, then merge both result lists with Reciprocal Rank Fusion (RRF) or a similar method. Rerank the shortlist with a cross-encoder. Use an LLM only for a tiny final set where its quality gain justifies the extra latency and cost.

Last reviewed: 2026-08-10. The stack is ranked by recall, ranking gain, policy correctness, p95 latency, and cost on real query slices, not by one universal candidate count.

StageDefaultJob
FilteringStructured filtersEnforce tenant, permissions, product, language, time, and availability.
Lexical retrievalBM25Exact names, IDs, error codes, legal terms, and high-precision tokens.
Dense retrievalEmbeddingsSynonyms, paraphrases, fuzzy intent, and semantic recall.
FusionReciprocal Rank Fusion or weighted retriever compositionMerge sparse and dense candidates without pretending scores are comparable.
RerankingCross-encoderReorder a latency-bounded shortlist with query-document interaction.
Final precisionLLM reranker or answer modelResolve nuanced relevance only after the list is small.
EvaluationRecall@k, nDCG, MRR, click labels, human labelsProve each stage improves the previous one.

Use-case defaults

Product surfaceGood defaultWhy
Documentation searchBM25 plus embeddings plus cross-encoderExact API names and semantic questions both matter.
RAG retrievalHybrid retrieval plus reranker plus citation checksMissing evidence is usually worse than slow generation.
Product searchLexical filters plus hybrid retrieval plus business featuresAvailability, price, popularity, and exact facets matter.
Support searchHybrid retrieval plus freshness and ticket metadataSimilar wording and current policy both matter.
Internal knowledge baseBM25 baseline, then dense retrieval from query logsStart measurable before adding model cost.
Legal or compliance searchLexical baseline plus strict filters, then careful semantic expansionFalse positives and false negatives both have high cost.

Why BM25 still belongs in the stack

Embeddings find text with similar meaning, but they do not reliably replace exact matching. Error codes, function names, product SKUs, legal phrases, and people’s names often carry intent through their exact spelling. BM25 remains a strong baseline because it rewards terms the user actually typed.

Dense retrieval adds recall when users do not know the exact vocabulary. The choice is not between BM25 and embeddings. Use BM25 for lexical recall, embeddings for semantic recall, and fusion to combine them.

When to add a reranker

Add a cross-encoder when relevant documents enter the candidate set but rank too low. Choose the candidate count from measured recall and latency; top 50 is a useful experiment, not a universal threshold.

Do not add an LLM reranker before a cross-encoder unless the candidate set is tiny. The relevance judgment also has to be subtle enough to justify the cost. LLM reranking can help, but it is more expensive and slower. Measure it against a cheaper reranker.

Evaluation sequence

  1. Label real queries across important intents, languages, permissions, and failure costs. Start small, then expand until the slices and uncertainty support the decision.
  2. Measure BM25 alone.
  3. Add dense retrieval and measure recall delta.
  4. Add fusion and measure nDCG and Recall@k.
  5. Add cross-encoder reranking and measure Precision@1 and nDCG.
  6. Add LLM reranking only if it improves quality after cost and latency are included.
  7. Watch production metrics: zero-result rate, reformulation rate, click-through, answer correction, p95 latency, and cost.

Deeper reading

References