RAG and Knowledge Engineering
Hybrid Search — Stack
Hybrid search › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
The choice is between running one engine that does both and running two and fusing yourself, and the deciding factors are operational as much as they are about quality.
- Single-engine or two-engine topology. One engine removes a consistency problem and constrains your options for each arm; two engines give the best of each and double the ingestion, the deletion path and the predicate surface.
- Unit alignment. Whether both arms can be made to index exactly the same units with the same identifiers, which is what makes fusion meaningful and deduplication cheap.
- Fusion support. Whether the engine implements rank fusion natively, exposes raw per-arm ranks and scores for your own rule, or only returns a merged list you cannot inspect.
- Analyser control on the lexical arm. Tokenisation, case folding, stemming and the handling of identifiers, which is the whole reason the arm exists.
- Learned sparse support, if the lexical arm is to be more than term frequency — including whether the engine can store and query term weights produced by a model.
- Predicate parity. Whether the same entitlement and attribute filters can be expressed and executed identically in both arms.
- Parallelism and latency composition, including whether the engine issues the arms concurrently and what it does when one of them is slow.
- Per-arm observability. Whether a result can be attributed to the arm and rank that produced it without instrumenting the client.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Search engines with both lexical and vector retrieval (Elasticsearch, OpenSearch, Vespa, Apache Solr) | One system, one ingestion path, aligned units and native fusion | Vector scale and index tuning are weaker than dedicated engines; heap and shard sizing become the constraint |
| Vector engines with built-in sparse or keyword retrieval (Qdrant, Weaviate, Milvus) | Keeping a vector-first deployment while adding term matching | Lexical features are usually simpler than a real search engine's; check analyser control before relying on it |
| Two engines with client-side fusion (a vector store alongside a lexical index) | Getting the strongest arm of each kind and full control of the rule | Two ingestion paths, two deletion paths and two places for the predicate to differ |
| Relational full-text plus a vector extension (PostgreSQL text search with pgvector) | Modest corpora where everything already lives in one database | Both arms are adequate rather than good; fusion is yours to write in SQL |
| Learned sparse retrieval models (SPLADE-family representations) as the lexical arm | Vocabulary mismatch and exact-term matching in one representation | Needs an engine that stores learned term weights, and an encoding pass over the corpus like the dense arm |
| Managed retrieval services that expose a hybrid mode (hosted search and retrieval APIs) | Teams who want a single call and no fusion decisions | The rule and the weights are the vendor's and may change; per-arm diagnostics are usually unavailable |
| Fusion in a retrieval framework (LangChain and LlamaIndex ensemble retrievers) | Composing arbitrary retrievers quickly during development | Fusion happens in application code on fully materialised lists; latency and depth are yours to manage |