Hybrid search combines multiple retrieval methods so one weak signal does not decide what a user sees. Keyword search protects exact terms. Vector search finds semantic similarity. Graph retrieval follows explicit relationships. Filters, fusion, and reranking turn those candidate lists into one evidence set.
The value is not “more AI.” It is better coverage across the kinds of questions people and agents actually ask: product codes and policy names, paraphrased concepts, time and permission constraints, and multi-hop relationships between people, projects, decisions, and systems.
The short answer
A production hybrid search pipeline typically runs this sequence:
understand the query and establish user identity
choose eligible sources and retrieval methods
run keyword, vector, structured, or graph retrieval in parallel
apply tenant, permission, freshness, and type filters
merge the ranked candidate lists
rerank the strongest candidates for the task
diversify, deduplicate, and assemble evidence
return results or generate an answer with citations
Keyword and vector search are the common baseline. Graph retrieval should be added when the question depends on relationships or paths, not simply because graph technology is available.
Why one retrieval method is not enough
Every retrieval method has a different blind spot.
A lexical engine can precisely match ERR_AUTH_4017, “Policy FIN-22,” or a customer name. It can miss a passage that describes the same idea using different words.
A vector engine can connect “reduce customer churn” with “improve renewal retention.” It can underweight exact identifiers, dates, rare names, and short technical strings.
A graph can answer “Which projects depend on this service?” or “Who approved the exception linked to this account?” It cannot replace the source passages that explain the decision or support a generated claim.
Hybrid search treats these differences as complementary. Microsoft describes hybrid search as parallel full-text and vector queries over the same request, merged into one ranked result set. Exact terminology often favors keyword retrieval, while conceptual similarity favors vectors. Microsoft: hybrid search overview
The three retrieval modes
Keyword retrieval: exact language and field-aware precision
Keyword retrieval usually relies on an inverted index. Terms map to the documents or chunks that contain them, and a ranking function such as BM25 rewards matches based on term frequency, document length, and how rare a term is in the corpus.
Keyword search is strong for:
product SKUs, ticket numbers, error codes, and policy IDs
names, dates, quoted phrases, and legal terminology
domain vocabulary that embeddings may not represent well
field-specific queries such as title, owner, status, or region
filters, facets, sorting, and explicit Boolean logic
It is weaker when the query and source use different words. “Parental leave” may need to find a passage titled “family care absence.” A purely lexical system can miss the connection unless synonyms, query expansion, or curated vocabulary covers it.
Vector retrieval: concepts and paraphrases
Vector retrieval represents the query and content as embeddings. Approximate nearest-neighbor algorithms find vectors that are close under a similarity measure.
Vector search is strong for:
natural-language questions
paraphrases and synonyms
conceptual similarity across inconsistent vocabulary
discovery when the user does not know the exact source wording
multilingual or cross-domain retrieval when the embedding model supports it
It is weaker for exact identifiers and can produce “thematically similar” results that do not answer the question. An embedding also compresses meaning: it does not preserve every date, number, negation, or authority signal.
Pinecone’s hybrid-search guidance makes the trade-off explicit: semantic search can miss exact keyword matches, while lexical search can miss synonyms and paraphrases. Its documentation also warns that dense and sparse scores have different ranges and must not be mixed without normalization or a rank-fusion strategy. Pinecone: hybrid search
Graph retrieval: relationships and paths
Graph retrieval begins with nodes and edges: customer → contract → renewal owner, incident → service → repository, policy → exception → approver. The query identifies or retrieves seed entities, then traverses relationships that encode business meaning.
Graph retrieval is strong for:
multi-hop questions
dependency and impact analysis
ownership, approval, and organizational relationships
entity disambiguation
expanding a search from one known object to related evidence
enforcing or explaining relationship-aware policies
It is weaker when the graph is incomplete, stale, or overly generic. A graph edge may say that a decision “relates to” a project without explaining the decision. Graph retrieval should usually return source-backed objects and passages, not substitute opaque edges for evidence.
Neo4j’s GraphRAG tooling includes vector-plus-Cypher retrieval patterns: similarity search can identify relevant nodes, then a graph query can expand or format connected information. That pattern captures the right division of labor—semantic discovery for seeds, explicit graph logic for relationships. Neo4j GraphRAG user guide
Hybrid search is a pipeline, not a toggle
Many products expose a “hybrid” checkbox, but production quality depends on at least five design stages.
1. Query understanding
The system should identify the likely query class:
exact lookup:
FIN-22,Order 88319, a quoted phraseconceptual question: “How do we handle risky renewals?”
entity question: “Who owns Acme?”
relationship question: “Which launch depends on the delayed API?”
time-sensitive question: “What changed this quarter?”
mixed question: “What does FIN-22 say about the Acme exception?”
Query classification does not need to eliminate retrieval methods. It can determine candidate counts, weights, filters, source routing, and whether graph expansion is justified.
2. Candidate generation
Run retrieval methods independently so each can optimize for recall. A practical baseline may retrieve:
top 50 lexical results
top 50 dense-vector results
top 20 structured or graph results
Candidate depth should be tuned to the corpus and latency budget. If each retriever returns only five items, fusion cannot rescue evidence ranked sixth. If each returns thousands, reranking becomes slow and noisy.
3. Eligibility filtering
Apply tenant, user, group, source, content type, status, geography, and time constraints. Permission filtering must happen before sensitive content reaches downstream rerankers or language models.
Filtering can occur before retrieval, during the index query, or immediately after candidate generation. The implementation varies, but the security contract should be fail-closed and observable.
4. Fusion
Fusion combines lists produced by algorithms with incompatible score scales.
Two common methods are:
Weighted score combination: normalize scores and calculate a weighted sum. This offers explicit control but depends on good calibration.
Reciprocal rank fusion (RRF): combine items based on their position in each list. This avoids score normalization and rewards results that rank well across methods.
In RRF, each result contributes roughly 1 / (rank + k) from every list where it appears. A document ranked near the top of both lexical and vector results gains more combined support than one appearing in only one list.
Microsoft’s RRF documentation notes that BM25, vector similarity, hybrid fusion, and semantic reranking use different score ranges. RRF merges ranks rather than pretending those raw scores are directly comparable. Microsoft: RRF scoring
5. Reranking and context assembly
Fusion improves candidate ordering; it does not understand the full task. A semantic reranker or cross-encoder can score query-document pairs more precisely over the top candidate window.
After reranking, the system should:
remove duplicate chunks from the same passage
recover parent or adjacent context when needed
prefer current and authoritative sources
preserve exact-match evidence for identifiers
diversify across sources when one document dominates
identify conflicting versions
assemble a token-bounded evidence set
Elastic’s hybrid-search guidance distinguishes score combination from RRF and supports semantic reranking after hybrid retrieval. The important operating principle is to keep each stage traceable: candidate lists, fusion contributions, reranker scores, and final selection. Elastic: hybrid search overview
Where graph retrieval belongs
Graph retrieval can enter the pipeline in several places.
Graph-first routing
If a query contains a known entity or relationship pattern, use the graph to identify the relevant objects, then retrieve supporting passages from those objects.
Example: “Which customers depend on Service A?” The graph identifies customer-service relationships; document retrieval adds contracts, incident reports, or account notes as evidence.
Vector-first expansion
Use vector search to find conceptually relevant seed nodes or documents, then traverse a bounded set of relationships.
Example: “Which past decisions are similar to this pricing exception?” Vector search identifies similar exceptions; the graph expands to approvers, customers, products, and outcomes.
Graph as a ranking feature
Use relationship signals to rerank candidates: ownership proximity, project membership, source authority, recency of collaboration, or dependency depth.
Personalization should remain permission-aware. A close relationship is not permission to expose a private object.
Graph as a constraint
Use the graph to restrict eligibility or route the query. An agent working on Project A may search only objects connected to that project unless the user explicitly broadens scope.
Index design for hybrid retrieval
Hybrid search begins at ingestion. Each retrievable object needs representations appropriate to the workload.
A useful chunk record can include:
stable document, version, and chunk IDs
original text and normalized text
title, headings, and source path
dense embedding
sparse or lexical representation
entity IDs and graph links
content type, language, dates, and status
authority and freshness metadata
tenant and access-control principals
parent and adjacent chunk references
Do not embed every field into one vector and discard the original structure. Exact dates, owners, versions, and permissions belong in filterable fields. Relationship identifiers belong in explicit graph or structured fields. The vector should represent semantic content, not become the only index.
One index or several?
A single multi-field index simplifies consistency and latency. Separate indexes allow independent models, scaling, and tuning but require stable identifiers and careful synchronization.
Pinecone documents both patterns: a single index containing dense and sparse representations, or separate dense and sparse indexes merged client-side. The right choice depends on data shape, score-control requirements, and operational complexity. Pinecone: hybrid search
For graph retrieval, a separate graph store is common, but the graph and search index must share canonical object IDs. Otherwise, expansion returns objects that cannot be joined back to current, permission-aware source evidence.
Query examples and the winning signals
“ERR_AUTH_4017 after SSO migration”
Keyword retrieval should dominate the error code and SSO terms. Vector retrieval can add conceptually related troubleshooting. Graph retrieval may connect the error to the authentication service, runbooks, and recent incidents.
“How do we retain customers who are likely to churn?”
Vector retrieval helps with paraphrases such as renewal risk and retention. Keyword retrieval preserves exact product or segment terms. Graph retrieval can connect accounts to owners, recent incidents, and renewal dates.
“Who approved the Acme pricing exception and what evidence did they use?”
Graph or structured retrieval identifies the exception and approver relationship. Keyword search protects the customer and exception name. Vector retrieval finds supporting rationale. Final citations should point to the decision record and source evidence.
“What changed in the security policy after the June incident?”
Time and version filters are critical. Keyword and vector retrieval find the policy and incident language. Graph relationships can connect incident, policy revision, authors, and affected systems.
Common hybrid search mistakes
Calling vector plus keyword “done”
Parallel retrieval is only candidate generation. Without filtering, fusion, reranking, authority, and evaluation, the system may still select wrong or unauthorized evidence.
Adding raw scores
BM25 and cosine similarity do not share a natural scale. Raw addition lets one signal dominate for mathematical rather than relevance reasons.
Tuning one global weight
Queries vary. Exact-ID lookups should lean lexical; conceptual questions may lean vector; relationship questions may need graph expansion. Start with a robust default, then evaluate routing or adaptive weights by query class.
Using graph expansion without limits
Unbounded traversal creates noisy neighborhoods and latency. Limit edge types, direction, depth, time, authority, and candidate count.
Applying permissions after reranking
Sensitive content may already have reached a third-party reranker, cache, or model. Enforce eligibility before downstream content processing.
Evaluating only answer quality
A fluent answer can conceal missing or incorrect evidence. Measure each stage separately.
How to evaluate hybrid search
Build a labeled set from real queries and segment it by query class. Include:
exact identifiers and rare terms
paraphrases and vague natural language
mixed exact-and-concept queries
relationship and multi-hop questions
time-sensitive and version-sensitive questions
permission-boundary cases
no-answer and conflicting-source cases
Candidate recall
Did at least one relevant item appear in each retriever’s candidate set? Compare lexical-only, vector-only, graph-assisted, and hybrid recall.
Ranking quality
Measure metrics such as MRR, nDCG, precision at k, and recall at k. Inspect whether fusion helps across query classes instead of only improving the average.
Eligibility correctness
Every unauthorized item should be excluded. Test group changes, revocations, tenant boundaries, and missing policy data.
Evidence utility
For RAG, measure whether the final evidence set is sufficient, nonredundant, current, authoritative, and correctly cited.
Operational performance
Track latency by stage, index freshness, cost per query, reranker load, graph traversal size, and timeout behavior. A slower retriever should have a fallback policy rather than block every query.
A practical rollout path
Phase 1: lexical plus vector baseline
Use shared stable IDs, permission filters, RRF or a well-calibrated fusion method, and a reproducible query set. Preserve full traces.
Phase 2: reranking and authority
Add semantic reranking, source authority, version awareness, deduplication, and context assembly. Tune candidate depth and latency.
Phase 3: query-class adaptation
Adjust weights, retrieval methods, or candidate counts for exact, conceptual, and mixed queries. Do this only when the labeled set proves a consistent difference.
Phase 4: graph-assisted retrieval
Add bounded graph routing or expansion for questions that require relationships. Evaluate it as a separate contribution and keep source citations attached.
Phase 5: continuous repair
Turn failed searches, user reformulations, missing citations, and support escalations into labeled cases. Release retrieval changes as versioned candidates with rollback.
Search results and AI answers need different finishing steps
A human-facing result page may benefit from facets, snippets, highlighting, sorting, and several plausible options. An AI answer needs a much smaller evidence package with exact citations and enough surrounding context to support each material claim.
Use the same candidate infrastructure, but evaluate the finishing layer separately. For search UX, measure whether users can recognize and reach the right source. For RAG, measure whether the selected passages are sufficient for a grounded answer. A ranking that works well for ten visible results can still create a poor three-chunk context window, especially when duplicate passages crowd out source diversity.
The system should also preserve the path back to the original object. Hybrid retrieval can operate on chunks and graph nodes, but users and auditors need the document, record, version, and permission-aware URL behind them.
Final takeaway
Hybrid search is not keyword search with an embedding added. It is an evidence-retrieval architecture that gives exact language, semantic meaning, explicit relationships, permissions, authority, and ranking separate roles.
Begin with lexical and vector retrieval because they cover complementary failure modes. Fuse ranks carefully. Rerank and assemble evidence explicitly. Add graph retrieval when relationships genuinely decide the answer. Then evaluate each stage so the team knows whether a failure came from recall, eligibility, fusion, reranking, or generation.
That is how hybrid search becomes a dependable knowledge layer for people and agents rather than a black box that sometimes finds a plausible paragraph.
Retrieval mode decision table
Query signal | Keyword | Vector | Graph | Recommended blend |
|---|---|---|---|---|
Exact code, SKU, or policy name | Strong | Weak to medium | Weak | Keyword first, then rerank |
Concept or paraphrase | Weak | Strong | Medium | Vector plus keyword fusion |
Ownership, dependency, or approval path | Medium | Medium | Strong | Graph-constrained hybrid retrieval |
Recent incident with named systems | Strong | Medium | Strong | Keyword recall plus bounded graph expansion |
Broad exploratory question | Medium | Strong | Medium | Multi-channel recall with query-class reranking |
Frequently asked questions
What is hybrid search?
Hybrid search combines multiple retrieval signals—commonly lexical and vector search—and fuses or reranks their candidates before presenting results or building AI context.
Does hybrid search always need a knowledge graph?
No. Keyword plus vector retrieval is a strong baseline. Add graph retrieval when relationship paths, ownership, provenance, or bounded expansion materially improve the task.
Can raw keyword and vector scores be added together?
Usually not safely. Their scales and distributions differ. Reciprocal rank fusion or a learned reranker provides a more stable starting point.
Where should permission filtering happen?
Before unauthorized candidates can reach reranking, previews, generation, caches, or traces. Authorization is an eligibility rule, not a relevance feature.
How should hybrid search be evaluated?
Measure recall, ranking quality, eligibility correctness, evidence usefulness, latency, freshness, and the downstream task outcome by query class.
Where Dokki fits
Dokki is a useful destination for the knowledge and decisions that hybrid retrieval should surface. Teams can keep documents, structured tables, provenance, and agent-produced outputs in one workspace, then evaluate retrieval against real recurring missions rather than a generic benchmark.
Sources
_Last verified: July 21, 2026._