Hybrid search
Also: hybrid retrieval, keyword plus vector search
What is Hybrid search?
Hybrid search combines keyword (lexical) matching with embedding-based semantic matching in one retrieval step, so results catch both exact terms like part numbers and differently worded questions.
What Hybrid search means
Hybrid search runs two retrievers on every query. A lexical index (BM25 in OpenSearch, Elasticsearch or PostgreSQL full-text search) scores documents on exact and near-exact word matches. A vector index scores them on embedding similarity. The two result lists are merged, commonly with reciprocal rank fusion or a weighted score, and often passed to a reranker for a final ordering.
Each side covers the other's blind spot. Vectors find "my card got blocked" when the document says "card suspended", but they are poor at identifiers, acronyms, product codes and rare proper nouns. Keywords nail "ERR-4031" or "Section 12(3)" but miss paraphrase. In our experience a large share of production retrieval misses on vector-only systems are exact-term queries.
Hybrid search is not the same as running two searches and showing both lists; the fusion step and the shared filters (tenant, permissions, date) are what make it a single system. It is also not a substitute for good chunking: both retrievers are searching the same chunks.
Who it really matters to
- CTO / Head of Engineering: Adding a lexical index to a vector-only pipeline is one of the cheapest, highest-yield fixes for retrieval misses.
- Support manager: Customers search by order numbers, error codes and product names, precisely the queries pure semantic search handles worst.
- Product manager: Hybrid search changes which questions the assistant can answer at all, which shows up directly in resolution rates.
- Data lead: Fusion weights and filters are tunable and measurable, so retrieval quality can be improved against a golden set rather than by feel.
Why it exists
Vector-only retrieval became the default because it demos well on natural-language questions. In production, users type SKUs, invoice numbers, statute references and acronyms, and embeddings treat those as noise. Hybrid search exists to stop the system failing on exactly the queries that matter most to operational staff. The trade-off is a second index to keep in sync, a fusion step to tune, and slightly higher query latency. For most business corpora that cost is small next to the alternative of confident answers built on the wrong document.
Where it is applied
- Support assistant for a SaaS product that must resolve both "why is billing failing" and "what does error 402-B mean"
- Loan-policy search at an NBFC where staff query by circular number and by plain-language situation
- Spare-parts lookup for a logistics fleet by part code or by description of the fault
- Clinical guideline retrieval by drug name, ICD code or symptom description
- Course-content search where students ask in their own words and instructors search by module ID
Is Hybrid search a skill?
Technique / practiceA retrieval engineering practice, usually implemented in OpenSearch or PostgreSQL. It is standard in every Eazyware Retrieval & Knowledge Engineering build and tuned against a golden question set.
Eazyware service that covers it: Retrieval & Knowledge Engineering. Starting prices are on the pricing page.
Frequently asked questions
Does hybrid search make retrieval slower?
Slightly. Two index lookups plus fusion typically add tens of milliseconds, which is negligible next to model generation time. The reranking step, if used, costs more than the hybrid fusion itself.
Can we do hybrid search in PostgreSQL alone?
Yes. PostgreSQL full-text search plus pgvector gives you both retrievers in one database, with fusion done in SQL or application code. It is a sensible starting point for corpora that are not enormous.