Hybrid search vs vector search: why pure vector RAG quietly fails

When teams first experiment with vector search, the results feel magical. You search for "automobile maintenance" and the system effortlessly retrieves documents talking about "car repair" and "oil changes", even though the exact words differ. This semantic capability led many to believe traditional keyword search was dead.

In production, however, pure vector search exhibits an infuriating flaw: it is terrible at exact matches. If a user searches for an error code like `ERR_AUTH_TIMEOUT_504`, a medical catalog number like `XR-892-A`, or a specific executive name, embedding models often dilute those distinct character tokens across broad semantic dimensions. The vector search returns general articles about authentication or timeouts, completely missing the exact technical doc detailing that specific error code.

This phenomenon occurs because embedding models are trained on general linguistic semantics rather than verbatim lexical equality. When exact precision matters, vector search alone fails.

BM25 (Best Matching 25) is the industry-standard probabilistic ranking function that powered search engines like Lucene, Elasticsearch, and Google for decades. It scores documents based on term frequency (how often a word appears in a document) inverted by document frequency (penalizing common words like "the" or "is").

BM25 is unbeatable for exact terms, acronyms, code identifiers, phone numbers, and unique product names. It requires no GPU compute, indexes gigabytes of text in seconds, and executes in single-digit milliseconds.

The limitation of BM25 is vocabulary mismatch: if a user searches for "affordable lodging" and a listing only uses the phrase "budget hotels", BM25 will return zero results.

Hybrid search does not attempt to create a single magic algorithm; it runs both BM25 and vector search in parallel and combines their results.

The challenge in hybrid search is score normalization: BM25 returns arbitrary positive unbounded float scores (e.g. 18.4), while vector search returns cosine similarity floats between 0.0 and 1.0. Directly adding these numbers together leads to one search method dominating the other.

The standard production solution is Reciprocal Rank Fusion (RRF). Instead of looking at raw scores, RRF evaluates the rank position of each document in both result sets using the formula `Score = 1 / (60 + Rank)`. A document that finishes in the top 3 of either search — or consistently places in the top 10 of both — gets boosted to the top of the final output.

A common architectural anti-pattern is deploying an Elasticsearch cluster for keyword search alongside a Pinecone or Qdrant cluster for vector search. Managing two separate search clusters requires two indexing pipelines, two backup regimes, and complex synchronization logic to prevent index drift.

For 95% of applications, you can achieve elite hybrid search within PostgreSQL alone. PostgreSQL natively supports full-text search with `tsvector` and `tsquery` (using BM25-like BM25/TF-IDF ranking), alongside vector similarity search via the `pgvector` extension.

You can write a single SQL query that executes a full-text search and a vector similarity query simultaneously, applies Reciprocal Rank Fusion in a Common Table Expression (CTE), and returns the fused results in less than 50 milliseconds.

• Never rely on vector search alone for code, medical, legal, or product catalog search
• Implement Reciprocal Rank Fusion (RRF) to combine sparse lexical and dense semantic results
• Consolidate search infrastructure inside PostgreSQL (using pg_trgm/tsvector and pgvector) before adding separate cluster overhead
• Add a lightweight reranking step (like Cross-Encoders or Cohere Rerank) to the top 20 hybrid results for maximum precision