TECHNIQUE
Retrieval & Grounding
Hybrid retrieval in this pool is mostly deployed as semantic/vector retrieval plus sparse/traditional signals, structured filters, reranking, and query/source scoping rather than standalone embedding search.
Run lexical, sparse, or traditional-signal retrieval/ranking alongside semantic or vector retrieval.
5 of 8 deployed operators in the pool cite this pattern.Use structured filters, metadata, ACLs, source scopes, or business fields around semantic retrieval.
7 of 8 deployed operators in the pool cite this pattern.Add a second-stage selector, reranker, ranker, or post-processor after initial retrieval.
6 of 8 deployed operators in the pool cite this pattern.Preprocess the query or use an agent to rewrite, classify intent, select sources, or construct the retrieval strategy before search.
4 of 8 deployed operators in the pool cite this pattern.Build or refresh an offline index, embedding store, memory corpus, or feature store before online retrieval.
8 of 8 deployed operators in the pool cite this pattern.Evaluate and tune retrieval with offline metrics, labeled examples, manual nearest-neighbor review, online experiments, or LLM judges.
4 of 8 deployed operators in the pool cite this pattern.No deployed operator in the pool presents hybrid retrieval as raw vector search alone; each adds at least one non-vector control such as sparse/traditional signals, metadata or ACL filters, source scoping, reranking, LLM selection, or human validation.
The shared deployment shape is offline corpus/index preparation followed by online query-time retrieval and selection.
Operators differ on what they add to semantic/vector retrieval.
APPROACH 01
Lexical, sparse, BM25, or traditional ranking signals are combined with semantic retrieval.
APPROACH 02
Structured filters, metadata fields, ACLs, or scoped document sets constrain retrieval.
APPROACH 03
LLMs or agents rewrite queries, select sources, or choose/rerank candidates.
Operators differ on where hybridization happens in the retrieval pipeline.
APPROACH 01
Hybridization happens during candidate generation by querying multiple retrieval systems and combining results.
APPROACH 02
Hybridization happens after candidate generation through reranking, LLM selection, or ranking models.
APPROACH 03
Hybridization keeps a human or user validation step in the loop for final acceptance.
Operators use different index shapes for different domains and modalities.
APPROACH 01
Unified workplace or enterprise search indexes span multiple apps and work artifacts.
APPROACH 02
Task-specific vector indexes target tables, images, jobs/feed items, or personal memories.
APPROACH 03
General RAG indexing pipelines are framed around private/internal document corpora with metadata preservation.
Embeddings alone are repeatedly called insufficient: operators add BM25/sparse/traditional signals, filters, or retrieval-strategy logic for exact match and product constraints.
Context breadth is an operational risk: operators report needing to trim retrieval/tool context, specialize retrieval agents, identify sources, or apply guardrails before retrieval.
Ingestion and content preparation remain quality bottlenecks: chunking, table extraction, media understanding, and document-format handling are explicitly engineered rather than assumed solved.
Permissions, safety, and final acceptance checks stay close to retrieval outputs for sensitive or high-impact use cases.
| Name | Kind | When | Maturity |
|---|---|---|---|
| OpenSearch hybrid (BM25 + dense) | service | existing Elasticsearch/OpenSearch infra gains dense fusion without a new store | established |
| Reciprocal rank fusion | pattern | merging sparse and dense result lists without training a fusion model | commodity |
| Vespa | service | native hybrid ranking profiles at high query volume | established |